Jetico vs Comodo

I am currently using Jetico but have been hearing good things about the latest version of Comodo. Just wanted to get some thoughts from others on a comparison of these two. I know everyone's system is different and everyone has a preference based on their own critieria. With that being said, for those of you who have tried both of these firewalls, which of these do you like best and why. Pros/cons of each.

 

Well, i have been using both of them (sort of) and in my opinion Jetico is the definite winner.
After i've had some problems with Kerio i've decided to give them both a shot - Comodo was first in line.
After installing it (version 2.0), i immediately noticed it won't play very nice with KAV 6, which i already had installed - there was a huge numbers of popups, from both of them, which caused me to shut down some components of Comodo to cut the number a bit.
Having done so, i guess i've given up some protection Comodo had to offer, but considering the relatively high memory usage (especially comparing to Jetico), i knew Comodo was already on his way out so i didn't care...
As for Jetico - yes, it's a bit awkward to configure, but once you get a hang of it, nothing to complain about

 

adam777,

Thanks for the feedback. Exactly the type of information I was looking for.

 

I agree that Jetico is the better of the two. Jetico rules configuration definitely takes some getting used to, but it will bolster your machine's network security like Fort Knox, if set up properly.

Comodo I trialed for a few hours but gave up on it due to high mem usage causing some system instability, especially with my av (NOD32). The configuring of rules on the fly certainly needs some work too. It is not as quick and straight-forward as it should be to refine application rules, especially with regards to allowed ports and ip's. However, it could one day be a killer fw if the developers can work out those issues with it. It has potential to be the best on the market, but I would not recommend it in its current state.

Ultimately, i went back to Outpost Pro, since it affords me the best overall experience. Nice UI, logging, protection (especailly for outgoing traffic) is one of the best, and rules configuration is quite slick. Very low mem usage as well. The plug-ins is a nice feature too.

Basically, it comes down to what you are most comfortable with using. Taking advantage of the trial periods on different fw's is the best approach to take when trying to decide on what to use.

 

Guys

Memory usage issue for Comodo Firewall is being addressed. It currently runs around 25meg to 40meg. We were able to reduce this to around 15meg now. We are working on reducing it to single digit soon. So please bear with us as we are working on this. As to compatibility with other AV etc, its all being fixed. We have a new version out very soon which will address all these issues.

thanks
Melih
Comodo

 

I do like and use Jetico, mainly due to its SPI and packet filter abilities down to the TCP flag level.
I have on a second occasion loaded up Comodo (latest version). I have found that comodo does not include an SPI, so allowing inbound packets is required, which can give the possiblity of allowing unsolicited inbound connections. I did attempt to create defined rules, first, to allow DNS to my router, ie: allow in/out UDP to router IP remote port 53, but comodo allerted me to this UDP request (basically showing me a copy of the rule I had created) I allowed this, but on checking the rules after this request, I found that Comodo had placed a rule to allow UDP in/out to all remote IP`s on all ports. I found the same problems when attempting to restrict TCP comms.
For me, a firewall must be able to effectively filter TCP/IP packets (for me personally, this is the main point of installing a firewall) and give the user the ability to block unsolicited inbound connection attempts, Comodo does not, at this time, appear to do this.

 

Melih, what about installers? They seem to fail on me for various unknown reasons. Possibly because i use Windows Safety Live from time to time (disk and registry cleaner), but only Comodo installers gave me problems so far, so i don't know what to think of exactly. I liked Comodo FW interface very much though and can't wait to see memory usage improvements

 

Hi Stem,this quote is from cpf help file:

 

Thanks timcan for the info.
hmmm, I didnt look at the user manual/help file. But if comodo does in fact use SPI, then why do inbound TCP/IP rules need to be created. SPI would handle the inbound replies to the outbound connections. Firewalls with SPI have the ability to block inbound connection (SYN packets), but setting a block inbound within Comodo blocked all inbound (even the SYN ACK packet replies to the outbound).

I will try to find time later to re-install and test for the inbound packets with Comodo, to see if the packets are filtered.

EDIT
Have re-installed to check, but finding the rules implementation to be too problematic. a simple example is the DNS lookup, a simple rule to allow outbound DNS remote IP: remote port 53 just will not work correctly, Comodo keeps prompting for "remote IP: with various ports" the ports being shown appear to be the local ports in use, but it is not possible to place a rule within Comodo for local ports. I will leave this firewall alone, and check again a few versions down the road to see if there is an improvement. As it is at the moment, it only appears to work if all inbound/outbound are set to allow.

 

RejZor

We are re-doing the installer and already managed to reduce the mem usage and should have a new upgrade out very soon. Hopefully next upgrade will resolve the memory issue and lets see if we can cram the installer update into this (fingers crossed).

thanks
Melih

 

Stem

Thanks for giving Comodo personal firewall (CPF) a try. I would love to hear from you as exactly how you would want CPF to be improved for the functionality you are looking for. If you can pls explain in detail, then we will make sure to schedule a design time for this (subject to approval of the design team etc of course), so that you can have what you want as a firewall This is like Custom Made Personal Firewall , maybe we should change the name of CPF to CMPF

thanks for the feedback and look forward to your "custom order"

Melih

 

here are some discussions about this topic which could be helpful to you.

http://forums.comodo.com/index.php/topic,177.msg1066.html#msg1066

 

unfortunately the statement made by "egemen" (in the link provided) is incorrect, it is not possible as stated to keep full "stateful" of UDP as this is connectionless. The only possibility with UDP is for a "pseudo-stateful mechanism" to keep track of outbound UDP packets with a timeout for the returned inbound.
With the statefull of TCP, if this was correct within Comodo, then the firewall would/should be able to keep track of "Localhost loopback", and would need only the outbound rule created, but on my short run of Comodo I found that the inbound was requested/required, or the loopback was dropped.
"egemen" also states that there is only a limited "state keeping" of such protocols as FTP,... well as FTP is over TCP, then you cannot have full statefull of TCP.

 

Well viewed!

I would like to see the Melih reply about this.

 

Ok, here is what Egemen said:

CPF network engine IS aware of loopback packets at its network monitor and handles them accordingly.

CPF's network and application monitor are separate modules by design. While trying to understand stateful inspection engine, you need to analyze network monitor not the application monitor, which does not keep full state data about applications.

So why does CPF's application monitor ask questions about so called loopback connections? Again, this is a case for application monitor(which does not need any advanced state keeping since the lower layers already does so) and it is by design. CPF will raise popups for loopback connections to mitigate the risk of bypassing the frewall through a local proxy( or similar threats).

FTP is an application layer protocol, which also has its own protocol semantics so that some state keeping is necessary not to disrupt the protocol.

Underlying transport protocol is not mentioned while speaking of basic ftp analysis. In general, application layer protocols(Layer 4-5-6-7) should be considered independent of the underlying transport layer protocol. Because FTP can be over TCP or UDP, selection of which, should not affect the operation and semantics of the ftp protocol.


Melih

 

The main question was in connection to Statefull PACKET inspection. The SPI should be handling packets according to the user rules regardless of the application, and cannot understand why you are now referring to a "application monitor"

If a user rule is allowing the outbound loopback connection, should not the SPI process and allow this. It appears strange to me that confirmation of a user "allow rule" is needed.

FTP uses the "Telnet protocol"..control connection:file transfer:error checking all by TCP.
FTP over UDP is TFTP (trivial FTP) which I have not seen used within windows (not defined as TFTP), the last time I saw TFTP was a long time ago on a Unix or was it a Linux system. So are you saying FTP and TFTP are handled the same by the SPI within Comodo

 

I am assuming you mean Stateful Packet Inspication when you say SPI and not SPI = socket provider interface hence i will answer it accordingly

First, lets talk about how CPF works.

CPF has 2 different LAYERED parts : An application based firewall which is responsible for detecting which application is using what transport + network addresses(i.e. which of TCP/UDP orts, + IP addresses). This firewall is not interested in any TCP flags or ICMP replies. This is mostly necessary to provide a good outbound defense. But this type of protection is not enough to provide an adequate inbound defense because of the fact it sees the packets after TCP/IP protocol stack receives them. This means TCP/IP can not be protected enough against incoming attacks like flooding etc. This is where CPF’s second part, network firewall, comes into the scene. The network firewall sees the incoming packets, just after the underlying Ethernet miniport receives them i.e. before TCP/IP protocol. So the scenarios are shown below.

----------------------

Outgoing packet->Application firewall -> Network firewall,

Incoming packet -> Network firewall -> Application firewall

This is how layered filtering works in CPF. Now lets turn our attention to stateful inspection.


Application firewall does keep some information about incoming/outgoing requests. So in your case if you allow an outgoing connection, application monitor wont ask you about the replies to this connection(be it a loopback connection or not). If you believe it asks, please show us a demonstration so that we can test it to tell you what is happening. But we should not call this as a stateful inspection because it is a simple book keeping.

Real stateful inspection is meaningful and necessary to protect TCP/IP stack of the PC, which implies that the firewall must catch these packets before TCP/IP receives them. So it is done at network firewall level. When you allow an outbound connection at network monitor, the state machine will further analyze the incoming replies to this request with its internal state machine to see if packets are legitimate replies or hijacking attempts or etc.

So in your case, you are testing the application firewall to see how SPI works but it is not the best test for it. You should go ahead and test the network firewall if you want to play with it (if you want information as to how to do it pls let me know i will give few examples of how to test it). SPI has nothing to do with the application monitoring.

As you will see, CPF has a layered approach with protects you from both inbound/outbound threats by deploying both Network and Application Monitoring layers.

re: FTP:
FTP protocol has its own protocol semantics that should be kept in mind : When you ftp to a site on port 21, and say issue an LS command, the remote site will try to initiate a a connection to your host over port 20(ftp-data) port. Clearly, TCP state machine is not enough to understand this case if you do know how stateful inspection works.(That’s why enterprise firewalls like Trustix Enterprise Firewall or Checkpoint FW-1 NG claims they provide stateful FTP inspection). Without watching what ftp commands are being issued, you have no chance to see if you should allow remote ftp-data requests or not.

And that’s why we do not mention the underlying transport protocol, in this case TCP, while talking about ftp inspection. FTP is just an example. There are many other protocols that use TCP as their transport protocol but do require some sort of state keeping when TCP state machine wont suffice.


Hope this clarifies the issues you are raising. If you need more clarification mor than happy to provide them and its best to work thru examples. Eg: if you have any more questions, pls suggest an example and we can work on that example as an answer.

thanks for taking the time to investigate CPF Stem.

Melih

 

I have already posted examples of this, but to reiterate.
Place in the application rules for firefox (remove the allow all in/out rule created as default)
Allow out UDP remote IP 192.168.1.1 port 53
This is the rule for DNS to my router, but I am prompted for the return UDP packet. If I select allow/create rule....a rule is created
Allow in UDP remote IP range 0.0.0.0-255.255.255.255 port range 0-65535
I did manually create a rule to allow in UDP remote IP 192.168.1.1:53 for the return packet, but I was still prompted for the inbound, as the local port was shown, but it is not possible to place local ports into application rules, and when I select allow/create rule, my original allow in rule is replaced by "Allow in UDP remote IP range 0.0.0.0-255.255.255.255 port range 0-65535"

This is also the case if I create a rule to allow loopback
Allow out TCP remote IP 127.0.0.1 port any
I am prompted for the inbound, If I allow/create rule...a rule is created
Allow in TCP remote IP 0.0.0.0- 255.255.255.255 port range 0-65535

This is dangerous, creating such open rules, as an SPI (statefull) firewall sould process these inbound, and as you have just stated, "application monitor wont ask you about the replies"

Due to this I have not made any attempts to connect to the internet while comodo is installed, the PC`s comms have been limited to the localhost - router.

I did at one point place a "network rule" to allow all in/out to my router, but this did not help. As I have mentioned, connections only appear to work correctly if the application rule allows all in/out

 

Its actually looking to me that you are creating an application firewall on top of an already created TCP/IP filter, and attempting to handshake between the two.

 

Stem

For the sake of clarity, I will try to re-iterate some of your points to make sure that we are on the same page: (and you can modify it to reflect the issue you are referring to if not correct/full etc)

What you are saying is:
1) even though you set some rules to allow certain ports at network layer, you still get Prompted due to application layer.

2)you want to be able to allocate a port number specific to an application

3)And also you are saying that: if you Allow out TCP remote IP 127.0.0.1 port any I am prompted for the inbound, If I allow/create rule...a rule is created. Allowing in TCP remote IP 0.0.0.0- 255.255.255.255 port range 0-65535. Are you suggesting that if you allow the above rule, it then allows everything else?

4)Also what you are saying is: the network rule you set only works if you set the application rule. Eg: set ABC.exe to Allow and then set network rules for that application. Like two layered approach of first deciding which app, then deciding the network rules for that app?

5)anything I missed?

thanks
Melih

 

As already stated by myself, inbound /returned packet need a rule, or are dropped. (REFost#1

 

Stem

If you look at the pop ups they are a special pop up informing the user about Firefox acting as a server!

These popups are not “Incoming Connection” popups but “Act as a server" type popups (another sophisticated way of CPF differentiating between different alerts). It seems that before receiving the packets, firefox somehow trying to call “listen or accept” so that CPF raises "Act as a server" alert instead of "Incoming connection popup" alert. “Act as a server” case requires authorization from the user whether it is a reply or not because there is a chance for that port to remain open after the reply is received thus leading to an unauthorized open port. So CPF asks even if it is a reply.

Melih

 

Act as a server indicates "allow inbound connections", Or are you now changing terminology.

So after allowing loopback for Firefox, from the rule created by Comodo, all ports will will opened to all IP`s for inbound TCP.

I will stay with Jetico firewall, which can distinguish between "Listen" and "allow inbound", and only needs one set of firewall rules, and doesnt open all ports for loopback.

Bye

 

Lets talk about the example you have identified here: You are claiming that the inbound connection alert is happening because you state there is no SPI in CPF. The example you have given cannot be considered a simple “reply” in an SPI for a (network level SPI)! That is why we are showing the alert. So why is this not a simple reply and why are you showing the alert? Because firefox (at application layer) before receiving the reply tries to “act as a server” by calling probably “listen” or “accept” winsock calls and there is no IP address. Firefox effectlively says I am going to listen to TCP port 1034 but it has not provided any IP address (well its 0.0.0.0). So how do you know which IP address will it listen to on this port? The answer is you don’t know at this level (application layer) (you might know this after connection is established, but we choose to do SPI at network level rather than Application level). If you look at a graphic we attached for CPF, you will see that pop up has an IP addresss and the popup you have displayed has “no” IP address which goes to show the point that firefox has not provided any IP address. So why is that bad and why do we alert the user? Because the browser (in your case firefox) is saying, its listening at port 1034 and will accept connections on any “interfaces” which could theoretically be bad. So we have to alert the user! For further information about TDI I would recommend reading about Transport Driver Interface (here http://msdn.microsoft.com/library/d..._af260005-f147-404f-8883-d4b6328b09fe.xml.asp )

Stem, we don’t do SPI at application layer, it’s a choice we have made because we believe doing "SPI at network layer" is much more meaningful and provides better security. Hence please do not mix the application layer with network layer when doing your tests. Eg: Just test the network layer for SPI (we will be more than happy to provide you info as to how you can do tests on the network layer to test SPI).

And your other point about CPF leaving all ports open: (This is simply NOT True) : Since you assume all the filtering is done at application layer and you neglect CPF’s network firewall layer, you are having somewhat misguided deductions about leaving ports open. If you don’t initiate a connection, noone will be able to connect to your listening server unless you create a network firewall rule for this. If this were not the case, CPF would have failed on EVEN BASIC stealth tests. So NO! CPF does not leave everything open! And if what you claim is true, then a simple test would prove it wouldn’t it ;-) go to www.grc.com and test it and tell us all that CPF fail this test! We all know that CPF won’t fail ;-) Please then explain to us all, if as you suggest CPF leaves ports open, how come we pass that leak test? (actually we pass almost all leak tests)

I would strongly recommend you read about TDI in the above link.

Thanks
Melih

 

I have read for many years on TDI and TCP/IP. My questions / replies to you are based on your statements / replies.
First the statement that UDP is statefull:-
I am still waiting for an explanation of this that you linked me to in your post:

You also state

The "act as server" was an alert at application layer.

My "deductions" on your firewall are being "misguided" by you, not by my knowledge on this subject.

From the default rules given to all applications of: Allow UDP/TCP in/out from all IP`s all ports. This cannot be described as a "layer of defence" for TCP/IP. This is simply a "allow network access" or "allow all to the network rules" and see no point to this with the default "Allow all" rules in place, apart from blocking/Allowing an application to network access. Any attempt to create a ruleset on the application level, to filter any inbound "allow rules" from the network level always give alerts and default rules of "allow all" replace the "user" rules in place.

This forces an alert at "application level" and a rule of "allow all TCP in" is created, if not opening ports to the network, it is opening all to any "allow TCP in" at the network Level.

I did not suggest that all ports where left open, it is your statement that suggests this, which I took as true:-

Which would lead to a conclusion that if you accept "Act as server" then the port would be left open,...but the rule created when "act as server" was allowed, was to allow "All IP`s / ports" in, which would infer that all ports where left open. Are you now saying this statement you made is incorrect? and that a port is not left open, if so, then why the alert/warning and your explanation of this?

Other firewalls work at the "network" level, using application rules. I cannot see how you can state that your approach to this is "better security" when the application rules default to "allow all"

EDIT, further to this (I have re-installed to perform further checking), if I place an application rule to Block in/out to remote IP port any, this in fact does not block this comm/IP, a Network rule is required to block the IP. So further to what I stated, the application rules are of no actual use/protection, apart from allowing/blocking all