Jetico vs Comodo

[Hipgnosis]

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.

[adam777]

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 :)

[Hipgnosis]

adam777,

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

[cprtech]

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.

[Melih-Comodo]

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

[Stem]

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.

[RejZoR]

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 :)

[timcan]

-{ Quote: "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. " }-
Hi Stem,this quote is from cpf help file:-{ Quote: "Comodo Personal Firewall, although designed for personal use, includes an industrial strength stateful inspection firewall, acting at OSI Layers 2, 3 and 4 to filter incoming and outgoing network traffic. Such an advanced filter keeps track of each and every packet sent/received and performs intelligent analysis on critical protocols such as TCP, UDP, FTP etc." }-

[Stem]

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.

[Melih-Comodo]

-{ Quote: "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 :)" }-


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

[Melih-Comodo]

-{ Quote: "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." }-

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

[Melih-Comodo]

-{ Quote: "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." }-

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

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

[Stem]

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.

[rdsu]

-{ Quote: "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.

[Melih-Comodo]

-{ Quote: "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

[Stem]

-{ Quote: "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." }-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"

-{ Quote: "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)." }-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.

-{ Quote: "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." }-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

[Melih-Comodo]

-{ Quote: "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

[Stem]

-{ Quote: "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." }-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

[Stem]

-{ Quote: "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." }-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.

[Melih-Comodo]

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

[Stem]

-{ Quote: "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." }-As already stated by myself, inbound /returned packet need a rule, or are dropped. (REF:post#18)

[Melih-Comodo]

-{ Quote: "As already stated by myself, inbound /returned packet need a rule, or are dropped. (REF:post#18)" }-

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

[Stem]

-{ Quote: "If you look at the pop ups they are a special pop up informing the user about Firefox acting as a server" }-Act as a server indicates "allow inbound connections", Or are you now changing terminology.

-{ Quote: "“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 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

[Melih-Comodo]

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/default.asp?url=/library/en-us/NetXP_d/hh/NetXp_d/303tdi_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

[Stem]

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:
-{ Quote: "CPF performs FULL stateful inspection on TCP/UDP protocols i.e. it keeps states of each TCP/UDP connection(syn/ack numbers)" }-

You also state
-{ Quote: "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.-{ Quote: "“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." }-" }-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.


-{ Quote: "CPF network engine IS aware of loopback packets at its network monitor and handles them accordingly." }-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.


-{ Quote: "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 did not suggest that all ports where left open, it is your statement that suggests this, which I took as true:-
-{ Quote: "“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." }-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?

-{ Quote: "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." }-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

[Melih-Comodo]

Stem

I do apologise if I offended you by asking you to read about TDI, but please understand that I did not mean to offend you as its very difficult to gauge the level of understanding/knowledge of a person on newsgroups.

The last thing I want is a pis*** contest! So let me try get to the basics of how all this has started.

You sent the first reply to this thread stating the below:

"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........."

Then you tried to do some testing to prove this above point, but you did not test the network level SPI we have and you tried to test application layer SPI (which we don't use). And you came to the "wrong conclusion" above without me saying even a word! You came to this conclusion by your own knowledge and testing! Only after you posted this wrong conclusion did I post my response!

Then you went on to state:

"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."

As you now know, this is not the case! And again you came to the wrong conclusion! (again no help from me!)

So CPF does use SPI (at network level) and CPF does have the ability to block unsolicitied inbound connection attempts!

Melih

PS: look forward to the GRC results re: your statement about leaving all ports open.

[Stem]

-{ Quote: ""I have on a second occasion loaded up Comodo (latest version). I have found that comodo does not include an SPI," }-This statement is correct on the application layer. From your info on the fact your firewall is using 2 firewalls, then I will check this, once I am given satisfactory answers to my questions (in my last post (repeated below))

-{ Quote: "PS: look forward to the GRC results re: your statement about leaving all ports open." }-As already stated, this was inferred from your statment below in response to my posted alert,
:--{ Quote: "“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." }-

=======================================================

Please answer the questions I put forward in my last post, and stop going around in circles. To reiterate:

1/ Is this statement correct:-
-{ Quote: "CPF performs FULL stateful inspection on TCP/UDP protocols i.e. it keeps states of each TCP/UDP connection(syn/ack numbers)" }-
2/ Is this statement correct:-
-{ Quote: "“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." }-

3/ and my question with ref to your statement
-{ Quote: "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." }-How can this provide better security, when all application rules default to "Allow all"

Another question as arisen from my re-installing Comodo concerning the outbound filtering of the application rules (or lack of). It is not possible to block an outbound connection within the application rules, this needs to be done in the "network rules". So question

4/ What outbound TCP/IP filtering is performed at the application user rules, i.e. Why does a "block outbound to IP" application rule get bypassed.

[Phant0m]

Hi Stem

Melih-Comodo wouldn’t falsely advertise capabilities/features in his firewall product, especially with vultures wanting a good story and with the knowledge and know-how to experiment on this obvious addictive and promising freeware firewall product.

I cannot say much on this product as I hadn’t had the pleasure to download/install and use.

I don’t believe it is question of SPI existing but its strength and implementation design in this product, and from what I had read posted by Melih-Comodo and yourself it appears to me that you are unfamiliar with a couple of features and conditions.

Regarding the DNS situation, and if I understand Melih-Comodo correctly, the ‘Application Monitor’ kicks in and prompt for non-configured / not-remembered applications, if you permit DNS with an application, supply the temp-range for source ports. Now create a DNS rule in ‘Network Monitor’, again supply temp-range for source ports and use packet direction ‘Outgoing’ only and ensure this DNS rule is above the ‘Master’ block all rule, or any blocking rules that would interfere with DNS packets. Now if I have understood correctly the Comodo Firewall should handle inbound automatically for DNS packets after correctly doing DNS rule (with specifications ‘Outbound’ only) in ‘Network Monitor’, the end results should be unsolicited inbound over DNS should be detected and blocked by the Stateful-like analysis over UDP protocol.

[Melih-Comodo]

-Your question about UDP:

UDP is a connectionless protocol. All of us know that there is no state machine for it in any of the specifications. But although the protocol itself is stateless, we can still keep track of incoming/outgoing packets in the firewall’s internal state table to reduce the possibility of unsolicited UDP datagrams. When we refer to stateful UDP inspection, we mean this type of analysis. “Stateful UDP Inspection” is not even a new term and used by many other firewall vendors including Checkpoint.

-Your question:
"How can this provide better security, when all application rules default to "Allow all" "

Application based access rights are used ONLY for outbound network protection. Application firewalls can only be used for this purpose. So this has nothing to do with unsolicited packets. Here are some advantages:

1- Fault tolerance : When some part of the system fails, other parts should continue to operate.
2- Stateful inspection is required to protect TCP/IP stack itself,
3- Enables you to control the traffic “passing through you”, thus providing the ability to operate as a gateway,

By allowing an application with right to connect any “TCP/UDP out”, or “TCP/UDP In” right, you are not opening any port to the world or you are not being vulnerable to unsolicited data reception. Because when we speak of unsolicited data, we refer to *packets*. And packets are analyzed where they belong to i.e. at OSI Layer 3 a.k.a network layer.

Applications generate *streams*,it is the TCP/IP stack which creates packets from those streams. So it is not meaningful to base network filtering

Stem, everything started with your statement below. Everything else (including the FTP issue you raised and we explained for your understanding which you don't seem to raise any issues with anymore) is afterthoughts (including all the latest answers i am posting above).


The main issue started with your statement about CPF and SPI, however your statement did not say Comodo does not have Application layer SPI, it clearly said: "I have found that comodo does not include an SPI," (This is the main point you raised which caused this hours of writing back and forth, which is now getting to be too time consuming for me, this is the main issue we are discussing!). So Stem you have to accept that your statement was plain wrong and you should have qualified it in order to make sure you don't give the wrong impression to other users who might listen to what you are writing. I am not even sure if you knew, at the time of you writing that statement, that there could be SPI at both application and Network layer, but lets give you the benefit of the doubt. Because if you knew that there could be SPI at both levels then you would have said no SPI at application layer and you are yet to test the network level (as you admit you have not tested the network layer). If you ask me, you did not know that could be the case! Thats why you made that blanket statement which was totally wrong!

I don't think we are getting anywhere on this and you continue to make some very blanket statements that I know for fact are blatently wrong. It is becoming obviously clear to me that you don't have the necessary knowledge or skillset to fully test a firewall. So I suggest you share whatever you find with professional people like grc or people who do firewall leak tests and let them qualify how CPF fairs.

This marks the end of the topic for me.

Thanks
Melih

[Phant0m]

-{ Quote: "
3/ and my question with ref to your statement
How can this provide better security, when all application rules default to "Allow all"
" }-


See post #17 again, http://www.wilderssecurity.com/showpost.php?p=748762&postcount=17 ...... explained fully there for yea..

[Melih-Comodo]

-{ Quote: "See post #17 again, http://www.wilderssecurity.com/showpost.php?p=748762&postcount=17 ...... explained fully there for yea.." }-

Thanks for the explanations Phantom, the knowledge is the power ;)

Melih

[Stem]

So the answer to my question 1 is no, you cannot have "Full statefull inspection on UDP",...well that only took,..how many posts.

As you will not give a direct answer to my other questions, well,.....
Melih-Comodo, if you cannot/will not answer questions on a forum, then why visit,....A thread on a forum may start with a statement, be it correct or not, but the rest of the thread need not be referred back to that statement, other questions will/do arrise, simply going around in circles back to one part of the thread without answering questions that arrise, well,....As you should note, my statement about the SPI was made in post #6 which you did not reply to, you replied to my post #9 in which I was attempting to find out how Comodo was working.
Your attemps of insult in post 24/29, well,...I am happy you have left the thread.

hello Phant0m,
Has you have jumped in, and refered me to post 17, then maybe you can give some insight into this:-
-{ Quote: "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." }-This statement is what brought up my question 4, if the application firewall is giving that layer of defence, then why is it unable to block outbound TCP to remote IP (user application rule).

[Stem]

-{ Quote: "Regarding the DNS situation, and if I understand Melih-Comodo correctly, the ‘Application Monitor’ kicks in and prompt for non-configured / not-remembered applications, if you permit DNS with an application, supply the temp-range for source ports. Now create a DNS rule in ‘Network Monitor’, again supply temp-range for source ports and use packet direction ‘Outgoing’ only and ensure this DNS rule is above the ‘Master’ block all rule, or any blocking rules that would interfere with DNS packets. Now if I have understood correctly the Comodo Firewall should handle inbound automatically for DNS packets after correctly doing DNS rule (with specifications ‘Outbound’ only) in ‘Network Monitor’, the end results should be unsolicited inbound over DNS should be detected and blocked by the Stateful-like analysis over UDP protocol." }-There is already a "network rule" to allow "all outbound" by default. My questions on the DNS where concerned with the Application rules, as an "allow all" inbound was required due to the fact there is no "local port" rule entry in the application rules. Even creating a application rule "allow inbound UDP_remote DNS server_remote port 53" causes Comodo to show an alert for the inbound, and when accepting the inbound, this rule is changed to "Allow inbound UDP_all remote IP_all remote ports".

[djg05]

The problem with this thread is that people like me are being blinded with science and at the end have no real idea of who is right or wrong.

It seems both are getting entrenched with their own ideas of how to test this f/w.

For a free f/w Melth is putting in a lot of time to explain the workings, though no doubt this will have some benefit to other related products Comodo have.

Stem is very fixed in what constitutes a good f/w. Perhaps some knowledgeable third party could step in to see where the differences lie.

Because there is an area of doubt I am reluctant to install it on my system.

Anyone want to volunteer their services.

[Stem]

Hi djg05,
Yes unfortunately, a simple explanation was not forthcoming.

I think a basic description of the workings of this firewall from its default installation and rules creation would be:-

There is an Application firewall, this is where you allow or block applications to the internet.
There is also a network firewall, this could be described as a sort of router, with default rules of "Allow all out" and "block inbound connections" (this is basically how a router works) So if an inbound connection is required, such as when using torrent / P2P clients, you place a rule at the network firewall to allow the inbound (as you would port forward in a router)

So really, basically that is what it is.

Of course there is all the "leakproof" and "stealth" that was referred to, but that was not part of my query

Hope this helps

EDIT:
Dont worry about the chatter made in the thread, I was just trying to get some straight answers, install the firewall and give it a try,....

I will be re-installing later to try with nmap/others

(if only I knew what I was doing HAHA)

[Mrkvonic]

Hello,
I will Comodo a try, see how it fares.
Mrk

[RejZoR]

I found that this is the exact reason why eMule won't work with Comodo FW if in stealth mode (TCP filtering and dropping of ICMP Echo requests). Result is LowID, but if you remove this network filtering emule will get HighID, but you won't be stealthed at all and TCP packets will not be filtered.

[Phant0m]

From what has been said, I do believe Application Filtering layer does handle permissions, allow or deny application rules, the question is how different is their implementation. If you haven’t already, try reading CPF helpfile that should be available after install, if you still find it difficult then ask Melih-Comodo to share some light on what you don’t understand yet (and without supplying statements implying what CPF doesn’t do or doesn’t have).

And as I had said previously, if I understood correctly what has been said here regarding CPF SPI implementation, It does not matter if the rules aren’t restrictive for the outbounds, the SPI at the Network layer still occurs.

Let’s say I created no specifications regarding source ports and destination port 53udp, DNS packet sent - srcIP=192.168.0.1, dstIP=128.176.12.3, srcPort=1052, dstPort=53

And example of one condition would be if the source port information wasn’t used when sending a DNS packet back, the stateful-like analysis over UDP protocol in CPF would drop this unsolicited DNS inbound packet.


Regards

[Stem]

Phant0m,
Would you be so kind as to reply to my question in post #32,.. you may actually have to install the firewall to give a correct answer.

[Phant0m]

Not planning on installing CPF anytime soon, still somewhat fresh from my perspective…

‘Originally Posted by Melih-Comodo
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.’

Exactly what all hadn't you followed in Melih-Comodo post?

'This firewall is not interested in any TCP flags or ICMP replies. This is mostly necessary to provide a good outbound defense.’ -- this? or all above?

[Stem]

-{ Quote: "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 part, as it refers to a layer of defense on the application layer, I am trying to understand what this defense is,....I know it gives block/allow all TCP/IP, but it is unable to to block outbound connections,... ie Block outbound TCP to remote IP port any. This has to be done at the network layer.

Throughout this thread I have been trying to find out what the application rules are intended for, as it appears they are not for blocking the outbound connections. I never got as far as checking the blocking of ports, as you cannot place local ports into the application rules.

[RejZoR]

Well port stealthing and dead silence of your PC is also crucial for security.
Whats the point of outbound protection when your PC is happily replying to every thing that gets bombarded on your ports? Actually it's the best if they can't even get status of your ports (Destination Unreachable).
Kerio had massive problems with this, thats why i never used it regardless of being free or with nice interface. I hope Sunbelt changed that.
On the other hand former Sygate and ZoneAlarm never had problems with stealthing, though ZA also has problems with eMule. Mainly massive memory and CPU consumption.

[djg05]

-{ Quote: "Hi djg05,
Yes unfortunately, a simple explanation was not forthcoming.

(if only I knew what I was doing HAHA)" }-

Thanks Stem

Just wondering if this is the sort of thing you are referring to

Comodo Forums (http://forums.comodo.com/index.php?topic=193.0)

Not that I use any Torrent stuff - just out of interest

[Phant0m]

From what Melih-Comodo has posted in post #17, CPF contains the two basic layers of protection, Application Filtering, Network Filtering.

In order they are work is based on the direction of packets,

|Outgoing packet| ->>> |Application firewall| -> |Network firewall+ SPI|

|Incoming packet| ->>> |Network firewall + SPI| -> |Application firewall|

Using Outgoings for an example; if Application rules aren’t made, or made to permit the packets don’t beyond and to the next stage (Network Filtering). If the application rule exists and permits, then it goes to the next stage (Network Filtering) where yet rules to permit the type of outgoing packets must exists before it goes out to Internet.

For Incomings; Network rule must exists for the incoming packets, and before it can go to the next stage of filtering (Application filtering). When Network rule exists the next stage (Application Filtering) applies before reaching the application.

[Stem]

-{ Quote: "Just wondering if this is the sort of thing you are referring to

Comodo Forums (http://forums.comodo.com/index.php?topic=193.0)

Not that I use any Torrent stuff - just out of interest" }-Hi djg05, this is actually refering to my post concerning the blocking of a remote IP.

I was at one point thinking that the application rules would limit/control the outbound, and the network rules would control the inbound. But I am now thinking that all filtering would be best at network level, with the default allow all in/out at application layer.
I normally pick up the workings of a firewall quickly, I could fully understand Jetico in about half an hour.
I will find time later to have another play.

[Mrkvonic]

-{ Quote: "Well port stealthing and dead silence of your PC is also crucial for security.
Whats the point of outbound protection when your PC is happily replying to every thing that gets bombarded on your ports? Actually it's the best if they can't even get status of your ports (Destination Unreachable).
Kerio had massive problems with this, thats why i never used it regardless of being free or with nice interface. I hope Sunbelt changed that.
On the other hand former Sygate and ZoneAlarm never had problems with stealthing, though ZA also has problems with eMule. Mainly massive memory and CPU consumption." }-

Amen!
Mrk

[Stem]

-{ Quote: "From what Melih-Comodo has posted in post #17, CPF contains the two basic layers of protection, Application Filtering, Network Filtering.

In order they are work is based on the direction of packets,

|Outgoing packet| ->>> |Application firewall| -> |Network firewall+ SPI|

|Incoming packet| ->>> |Network firewall + SPI| -> |Application firewall|

Using Outgoings for an example; if Application rules aren’t made, or made to permit the packets don’t beyond and to the next stage (Network Filtering). If the application rule exists and permits, then it goes to the next stage (Network Filtering) where yet rules to permit the type of outgoing packets must exists before it goes out to Internet.

For Incomings; Network rule must exists for the incoming packets, and before it can go to the next stage of filtering (Application filtering). When Network rule exists the next stage (Application Filtering) applies before reaching the application." }-
But from this example, the same question still arrises,...
O.K. I will explain again,....
An outbound packet is being sent to IP 111.222.333.444,..I have in place an application rule to block inbound/outbound to IP 111.222.333.444. Should not the application firewall block this outbound packet. (As it does not, it has to be blocked at the Network layer/rules)

[Phant0m]

If it isn't much troubles, can you provide some window captures of the rules settings?

[Stem]

-{ Quote: "If it isn't much troubles, can you provide some window captures of the rules settings?" }-I dont currently have the firewall installed, but this can be confirmed on the Comodo forum, as this question as been asked, and the reply was to block at network layer, the thread is here (http://forums.comodo.com/index.php?PHPSESSID=7af229dcbbf2cd4d9c47fa5e6b6e8c00&topic=193.0)
But it appears this does not work correctly (acording to the poster)

EDIT, I will re-install and post pics if this will help

[Phant0m]

Regarding the Network Firewall, and the thread you sent me to linking to the CPF forum.

Security -> Network Monitor - > add rule
Action = Block
Protocol = IP
Direction = Out
Source IP = ANY
Remote IP = 111.222.333.444
IP Protocol = Any (or IP protocol specifications, TCP for instance)

[waters]

Works great with emule,high id, and bitcomet,if you use the 2 rules posted on their forum.Fully stealth

[Stem]

-{ Quote: "Regarding the Network Firewall, and the thread you sent me to linking to the CPF forum.

Security -> Network Monitor - > add rule
Action = Block
Protocol = IP
Direction = Out
Source IP = ANY
Remote IP = 111.222.333.444
IP Protocol = Any (or IP protocol specifications, TCP for instance)" }-Yes this is a network rule that is needed to block the in/out,
I am talking about application rules, which will not block the outbound

[Phant0m]

Yea I know,

The problem here is, it seems that the firefox allow rule is overriding or still carrying out the task which a block rule was designed to deny

-{ Quote: "Yes this is a network rule that is needed to block the in/out,
I am talking about application rules, which will not block the outbound" }-

[Stem]

-{ Quote: "Yea I know,

The problem here is, it seems that the firefox allow rule is overriding or still carrying out the task which a block rule was designed to deny" }-The rules are read from top to bottom

[Phant0m]

You should specify Outbound only; see if that makes any difference.

Plus are you restricting by ports also with this rule? Or just by destination IP address?

[Stem]

-{ Quote: "You should specify Outbound only; see if that makes any difference.

Plus are you restricting by ports also with this rule? Or just by destination IP address?" }-All ports (any), with block outbound, same result. But,..strange, I was creating a ruleset within the application rules for Firefox, but the new rule is placed randomly, either above or below the existing rules, with no way of changing the position of the rule, so there is no way of setting the priority of the rule within the application rules.

[Phant0m]

From all this, to me it appears like an incompletion or poorly thought of Application Filtering controls. It should not be difficult to create application rules to deny particular packets, and permit everything else…

[Stem]

-{ Quote: "From all this, to me it appears like an incompletion or poorly thought of Application Filtering controls. It should not be difficult to create application rules to deny particular packets, and permit everything else…" }-I hope you can now understand my question concerning the outbound defense on the application layer/rules.

EDIT,...
If I place a application rule Allow in/out "Not 65.175.38.194" I am prompted for this connection, all other connections o.k. But as the rule implies, it should not connect, so really I dont think it should prompt.
If I place a ruleset with outbound TCP: to remote port 80, then this is the only port it will connect to, and no prompts for other ports.

[Phant0m]

Yea apparently this does seem to be the case now..

Who knows though, perhaps something small we overlooking, hopefully Melih-Comodo can shed some light on this now.

[neonSurge]

-{ Quote: "I dont currently have the firewall installed, but this can be confirmed on the Comodo forum, as this question as been asked, and the reply was to block at network layer, the thread is here (http://forums.comodo.com/index.php?PHPSESSID=7af229dcbbf2cd4d9c47fa5e6b6e8c00&topic=193.0)
But it appears this does not work correctly (acording to the poster)

EDIT, I will re-install and post pics if this will help" }-

Well if you want to block all access to a simple IP address, then you should write a network rule. If you want to disable an *application's* access to an IP address then you need to create an application rule. This means while say AppA cant connect to the IP, AppB still can.

Joe

[Stem]

-{ Quote: "Well if you want to block all access to a simple IP address, then you should write a network rule. If you want to disable an *application's* access to an IP address then you need to create an application rule. This means while say AppA cant connect to the IP, AppB still can.

Joe" }-Hi joe, this is what we are discussing. It is possible to block an IP at the network level (all apps cannot access the IP), but it is not possible to place an application rule to block the IP for one app.

[neonSurge]

-{ Quote: "Yea apparently this does seem to be the case now..

Who knows though, perhaps something small we overlooking, hopefully Melih-Comodo can shed some light on this now." }-

Hi guys,

Here is the thing : Once you approve an application's connection with a popup, no matter if you select remember or not, default allow rules take effect until you close the application. If you want to test its outbound filtering, you need to close firefox and then restart it. When you restart the firefox, it may still show you some popups because of no rule situations. If you even temporarily allow, then it will override the blocking rule.

To be able to play with it more, you can disable "Basic popup logic"(which reduces number of popups) and "Monitor DNS Requests" at Security->Advanced section. Disabling DNS check is necessary because if Comodo asks for a DNS request, and if you approve, temporary rule will override.

This is the issue you face. You may be trying to block a single IP for an already approved(by answering a popup) application.

Hope this helps,
Joe

[Stem]

-{ Quote: "Here is the thing : Once you approve an application's connection with a popup, no matter if you select remember or not, default allow rules take effect until you close the application. If you want to test its outbound filtering, you need to close firefox and then restart it. When you restart the firefox, it may still show you some popups because of no rule situations. If you even temporarily allow, then it will override the blocking rule.

" }-Hi joe,
I created the block rule while firefox was not running, no popups when I started firefox. I could re-install and try again, but I have had the same results on 4 installations, trying different rulesets.
Take a quick look at my post#58 (the EDIT part)

[Phant0m]

Well hey there neonSurge, ok so answer the following question;

- for Stem to block specific access to particular IP address with specific application at Application filtering level and have it stick without being overwritten (by bad design for instance) or overruled (by a bad design for instance) by another and totally unrelated connection attempt.

It cannot be done with CPF current application filtering control design, I’m correct aren’t I?

[Stem]

-{ Quote: "It cannot be done with CPF current application filtering control design, I’m correct aren’t I?" }-I got blanked by Melih-Comodo for making such statements, please remember what you said earlier -{ Quote: ""(and without supplying statements implying what CPF doesn’t do or doesn’t have)."" }-

[Joliet Jake]

-{ Quote: "From what Melih-Comodo has posted in post #17, CPF contains the two basic layers of protection, Application Filtering, Network Filtering.

In order they are work is based on the direction of packets,

|Outgoing packet| ->>> |Application firewall| -> |Network firewall+ SPI|

|Incoming packet| ->>> |Network firewall + SPI| -> |Application firewall|

Using Outgoings for an example; if Application rules aren’t made, or made to permit the packets don’t beyond and to the next stage (Network Filtering). If the application rule exists and permits, then it goes to the next stage (Network Filtering) where yet rules to permit the type of outgoing packets must exists before it goes out to Internet.

For Incomings; Network rule must exists for the incoming packets, and before it can go to the next stage of filtering (Application filtering). When Network rule exists the next stage (Application Filtering) applies before reaching the application." }-


Then my Bit Torrent client should be working yet I cannot get any inbound connections.
Time to try out another firewall until this one is able to handle BT and games.

[Phant0m]

I asked a question, and didn't make a statement...

-{ Quote: "I got blanked by Melih-Comodo for making such statements, please remember what you said earlier "(and without supplying statements implying what CPF doesn’t do or doesn’t have)."" }-

[Phant0m]

You have no restriction to the application with the application rules right? What BitTorrent rules you currently made for the Network?

-{ Quote: "Then my Bit Torrent client should be working yet I cannot get any inbound connections." }-

[Stem]

-{ Quote: "I asked a question, and didn't make a statement..." }-Technicalities :P

[Joliet Jake]

-{ Quote: "You have no restriction to the application with the application rules right? What BitTorrent rules you currently made for the Network?" }-

Application Rule;
Range-0.0.0.0 - 255.255.255.255 port [the ports chosen for my BT client] TCP/UDP [IN/OUT] permission [ALLOW]

Network rules above the block rule;
Allow TCP in from IP [ANY] to IP [ANY] source port [ANY] remote port [the ports chosen for my BT client]
Allow UDP in from IP [ANY] to IP [ANY] source port [ANY] remote port [the ports chosen for my BT client]


I have tried the above rules with my IP in with the same result.

Here is an example of a log from Comodo;
Date/Time :2006-05-16 07:10:24
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 172.xxxxxxxxx, Port = 50001) (JJ's edit-one of the ports used by my BT client.)
Protocol: TCP Incoming
Source: 193.xxxxxxxxxxxx
Remote: 172.xxxxxxxxx:50001
TCP Flags: SYN
Reason: Network Control Rule ID = 3

(Network Control Rule ID = 3) is the last rule;
Block and log IP in from IP [ANY] to IP [ANY] where IPPROTO is [ANY]

[neonSurge]

-{ Quote: "Well hey there neonSurge, ok so answer the following question;

- for Stem to block specific access to particular IP address with specific application at Application filtering level and have it stick without being overwritten (by bad design for instance) or overruled (by a bad design for instance) by another and totally unrelated connection attempt.

It cannot be done with CPF current application filtering control design, I’m correct aren’t I?" }-

Hi,

Yes you can do it. Complex applications like firefox or internet explorer cause us to be confused. For the sake of simplicity, lets try a simple application like telnet.exe.

I have attached a screenshot.

[neonSurge]

This is the rules screen shot

[neonSurge]

-{ Quote: "Application Rule;
Range-0.0.0.0 - 255.255.255.255 port [the ports chosen for my BT client] TCP/UDP [IN/OUT] permission [ALLOW]

Network rules above the block rule;
Allow TCP in from IP [ANY] to IP [ANY] source port [ANY] remote port [the ports chosen for my BT client]
Allow UDP in from IP [ANY] to IP [ANY] source port [ANY] remote port [the ports chosen for my BT client]


I have tried the above rules with my IP in with the same result.

Here is an example of a log from Comodo;
Date/Time :2006-05-16 07:10:24
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 172.xxxxxxxxx, Port = 50001) (JJ's edit-one of the ports used by my BT client.)
Protocol: TCP Incoming
Source: 193.xxxxxxxxxxxx
Remote: 172.xxxxxxxxx:50001
TCP Flags: SYN
Reason: Network Control Rule ID = 3

(Network Control Rule ID = 3) is the last rule;
Block and log IP in from IP [ANY] to IP [ANY] where IPPROTO is [ANY]" }-

Your question is answered here:
http://forums.comodo.com/index.php/topic,189.msg1300.html#msg1300

Joe

[neonSurge]

-{ Quote: "Well hey there neonSurge, ok so answer the following question;

- for Stem to block specific access to particular IP address with specific application at Application filtering level and have it stick without being overwritten (by bad design for instance) or overruled (by a bad design for instance) by another and totally unrelated connection attempt.

It cannot be done with CPF current application filtering control design, I’m correct aren’t I?" }-

There are some options in Comodo that should be disabled before trying such things. "Advanced->Security->Basic popup logic", is one of them. Basic popup logic forces Comodo to allow/block more rights while answering a popup. I would also disable Monitor DNS Requests option not to see DNS popups per application.

Joe,

[Phant0m]

Well neonSurge, it shouldn’t be anything complex about it, blocking an application specific type of connection should be easy and shouldn’t require disabling 110 features located all throughout the firewall configurations… just to have application at application filtering level denied specific connection attempts.

Again the question of mine still goes unanswered; so it looks like everyone is clueless here so far and now it is time that I wait for response from Melih-Comodo on this…


Regards

[Joliet Jake]

-{ Quote: "Your question is answered here:
http://forums.comodo.com/index.php/topic,189.msg1300.html#msg1300

Joe" }-

Thank you.

JJ8)

[neonSurge]

-{ Quote: "Well neonSurge, it shouldn’t be anything complex about it, blocking an application specific type of connection should be easy and shouldn’t require disabling 110 features located all throughout the firewall configurations… just to have application at application filtering level denied specific connection attempts.

Regards" }-

Correct. I have created exactly the same rules as Stem. without touching anything. And it is blocking. Thats why i am trying to tell you play with your own configurations. Because it works for me.

Cheers,
J

[neonSurge]

And here is the log view

[neonSurge]

-{ Quote: "All ports (any), with block outbound, same result. But,..strange, I was creating a ruleset within the application rules for Firefox, but the new rule is placed randomly, either above or below the existing rules, with no way of changing the position of the rule, so there is no way of setting the priority of the rule within the application rules." }-

Hi Stem,

Yes what you describe is the issue. Application rules in Comodo are not like network rules. This means we can not make an assumption that the rules are being read from top to down. When you play with the rules, you will see that it tries to merge the overlapping rules into a single one. It is confusing. Why dont you post this issue in the Comodo forums and get the answers from one of the developers? They are quick to reply.

Joe

[Phant0m]

I still hadn’t had the pleasure to download/install and use.

Are you using Comodo on Win XP?

[Stem]

-{ Quote: "Hi Stem,

Yes what you describe is the issue. Application rules in Comodo are not like network rules. This means we can not make an assumption that the rules are being read from top to down. When you play with the rules, you will see that it tries to merge the overlapping rules into a single one. It is confusing. Why dont you post this issue in the Comodo forums and get the answers from one of the developers? They are quick to reply.

Joe" }-Hi joe,
I have already been blanked on this question. But at least I now have confirmation that there is no predictable layer of outbound defense at the application rules/layer for applications such as Firefox/IE

[neonSurge]

-{ Quote: "Hi joe,
I have already been blanked on this question. But at least I now have confirmation that there is no predictable layer of outbound defense at the application rules/layer for applications such as Firefox/IE" }-

Hi Stem,

Though i do not agree with you about the outbound defense capabilities of Comodo(i agree with the outbound defense definition at the site www.firewallleaktester.com. And Comodo 2 peforms the best on those tests), i will post a request to Comodo forums about this overlapping application rules issue. I believe this is a bug but not a feature of it. I will try to update this topic whenever i am replied.

Joe.

Edit : You can also follow the topic at http://forums.comodo.com/index.php/topic,212.0.html

[Stem]

-{ Quote: "Though i do not agree with you about the outbound defense capabilities of Comodo" }-This as I said is at the rules/layer (rules filtering), this as nothing to do with leaktests (application filtering), but I will re-word to "unpredictable outbound packet filter capablities at the application rules/layer"

[speedlever]

This has been very educational reading. I don't think this has been updated for a while. Have there been any changes worthy of note?

Did CPF fix this bug? Did CPF fix the Fast User switching issue?

Stem, does the current version of Jetico running as an application and not as a service trouble you?

I was sorry to see Stem and Mehli sorta get in a huff in the discussion. I found it to be interesting, even though I didn't understand it all.

[Stem]

Hello,..
-{ Quote: "This has been very educational reading. I don't think this has been updated for a while. Have there been any changes worthy of note?" }-I thought this thread was gone/dead (well I had forgotten about it)

-{ Quote: "Did CPF fix this bug?" }-The application rules problem as not yet been addressed. They appear more concerned with "Leaktest prevention"
-{ Quote: "Did CPF fix the Fast User switching issue?" }-I still keep an "eye", I have seen posts to say this is addressed on the next release (but cannot confirm)

-{ Quote: "Stem, does the current version of Jetico running as an application and not as a service trouble you?" }-No, not at all,...

-{ Quote: "I was sorry to see Stem and Mehli sorta get in a huff in the discussion. I found it to be interesting, even though I didn't understand it all." }-There was, unfortunately, a disagreement,... but this happens from time to time on any forum about any subject,... no sleep lost.

[speedlever]

Stem,

Let me ask about the application vs service issue. By running as an application, isn't there a period of time that your computer is vulnerable to attack when you first boot up? Perhaps I misunderstand how the firewall works, but that is sorta my understanding. I seem to recall ZA undergoing scrutiny some time back about possibly leaving the computer unprotected for a short while during the boot process.

Regarding the disagreement... sure, it happens. But in this case it also served to shut down an interesting and educational discussion. That was what I was lamenting.

FWIW, I run ZAF/Avast Free on my laptop and KIS 6.0 on my PC. But I'm looking to possibly replace ZAF.

XP/home and pro/sp2 for all.

[Stem]

-{ Quote: "Stem,

Let me ask about the application vs service issue. By running as an application, isn't there a period of time that your computer is vulnerable to attack when you first boot up? Perhaps I misunderstand how the firewall works, but that is sorta my understanding. I seem to recall ZA undergoing scrutiny some time back about possibly leaving the computer unprotected for a short while during the boot process." }-There as always been the issue of protection on startup/shutdown. My question on this would be:- The firewalls that "run as a service" have a need on boot to allow the possibility for DHCP, how many distinguish,.. how many allow only the DHCP? (I simply cut off my internet on shutdown/reboot)

-{ Quote: "Regarding the disagreement... sure, it happens. But in this case it also served to shut down an interesting and educational discussion. That was what I was lamenting." }-I was,.. and still am willing to continue,...

-{ Quote: "FWIW, I run ZAF/Avast Free on my laptop and KIS 6.0 on my PC. But I'm looking to possibly replace ZAF." }-Firewalls, AV`s,.. always end as "personal",.. It can be a case of "how they look",.. "reports",.. or "how they are on the users PC",... Its always a toucy subject. If you want my peronal opinion,.. PM me.

Regards,..

[Melih-Comodo]

-{ Quote: "Hello,..
I thought this thread was gone/dead (well I had forgotten about it)

The application rules problem as not yet been addressed. They appear more concerned with "Leaktest prevention"
I still keep an "eye", I have seen posts to say this is addressed on the next release (but cannot confirm)

No, not at all,...

There was, unfortunately, a disagreement,... but this happens from time to time on any forum about any subject,... no sleep lost." }-


We have a new beta out next tuesday (fingers crossed) that addresses fast user switch and other few issues.

Heated discussions are part and parcel of these forums :-) I really appreciate the good work Stem is doing for everyone though!

Melih

[speedlever]

Stem,

One quick follow-on question about a firewall running as an application vs service:
What is the firewall application or service doing if the PC has been booted to the log-in screen of XP but no one has logged in yet? (the screen where you choose which account you wish to use).

Thanks.

[Stem]

-{ Quote: "Stem,

One quick follow-on question about a firewall running as an application vs service:
What is the firewall application or service doing if the PC has been booted to the log-in screen of XP but no one has logged in yet? (the screen where you choose which account you wish to use).

Thanks." }-If the firewall is running as a service, then the TCP/IP filtering will be active (But can depend on the firewall settings / config). As an application startup, this will wait for loggin.

[speedlever]

Stem,

Would it seem logical that an application firewall would leave the PC vulnerable in that scenario?

Or maybe a better question: is a PC vulnerable at the signon screen? Can a virus/trojan attack a PC in that situation or do firewalls/AV programs protect even there?

[shaunwang]

-{ Quote: "Stem,

Would it seem logical that an application firewall would leave the PC vulnerable in that scenario?

Or maybe a better question: is a PC vulnerable at the signon screen? Can a virus/trojan attack a PC in that situation or do firewalls/AV programs protect even there?" }-

To your question is a PC vulnerable at the signon screen?

This depends on the program you install. There are some spyware/trojan makes use of this chance to communicate but please take note your computer svchost.exe need to make a request to a DHCP if there's any or to your router to establish a connection and assigning your computer an internet protocol (IP). From this point what I know is that during signon screen only winlongon.exe and userinit.exe is loaded active, therefore the change of getting it during signon screen is impossible.

The only way of getting a virus/trojan is user unintentionally install.

[speedlever]

shaunwang,

So what you're saying is that even if you're connected to an always on (cable) internet connection, a computer sitting at the XP logon screen is not vulnerable to external attack. Do I understand correctly?

Thanks for the information.

[Stem]

-{ Quote: "Would it seem logical that an application firewall would leave the PC vulnerable in that scenario?

Or maybe a better question: is a PC vulnerable at the signon screen? Can a virus/trojan attack a PC in that situation or do firewalls/AV programs protect even there?" }-Hi, I have set up to have a look. (I normally have DHCP / netBios etc disabled and harden the system with WWDC and sat behind a router).
Anyway:- DHCP / netBIOS enabled (wwdc blocks removed). Booted to logon screen. and showing:-
All pings replied to,
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds

So yes, there is the possibility of problems at this stage. Of course a fully patched OS goes a long way in preventing inbound attacks. But you do also have to consider the possibility of something on you PC would have the ability to connect out (or be connected in to).

I had Jetico installed. But this does not run untill after login


EDIT: I ran the same config with Comodo installed (the latest full version I have 2.1.1.1) Installed with default settings, and showing:-
All ports Filtered. This was during boot, and on the login screen.

[speedlever]

Interesting results, Stem.

I am mostly concerned about external attacks, believing my systems to be clean (I could be wrong, but haven't gotten any suspicious alerts from my existing FWs).

If we can extrapolate from your tests, it sounds like the FW running as a service offers protection during the boot process/while the signon screen is showing while a FW running as an application leaves the doorway open during that same period of time.

But doesn't that conflict with the information shaunwang posted? Or did I misunderstand one or the other?

...scratching my head a bit...

[Stem]

I think shaunwang is refering to active comms at login?, and mentions a router.

From my install/post, I am refering to a direct Internet connection, and the ports that are showing on a scan.

-{ Quote: "If we can extrapolate from your tests, it sounds like the FW running as a service offers protection during the boot process/while the signon screen is showing while a FW running as an application leaves the doorway open during that same period of time." }-Yes,... from a service installed firewall there can be the protection at boot/login, as shown with Comodo. This can sometimes cause problems with DHCP, as the comms can be blocked. With the Application install firewall, ports can show as open.
(basically, as I mentioned post#90)

[speedlever]

Very good info, Stem.

At home, I am behind a NAT router. But on the road with the wireless laptop, anything goes. That's the one I currently run ZAF on.

I think I would be more comfortable with a FW that runs as a service, based on the info disclosed in this thread.

Other than Jetico, I don't know which ones run as an application and which ones run as a service.

Or maybe this is not that big a deal. Hard for me to know.

ZAF I'm reasonably sure runs as a service
Comodo runs as a service but no Fast user switching
Jetico runs as an application
Outpost?
Tiny?
Look 'n Stop?
Kaspersky AH?
Kerio 4.x?

[Stem]

While you are behind a router, you are o.k.
The time between boot / login with a fully patched / updated windows is not a big risk, but possibly not somthing you or others would want.
You mention Comodo,.. there was a mention by Melih that the next version would be addressing the "user switch" problem (post#88 on this thread). Maybe worth a wait for this next version?

[speedlever]

Could be worth the wait. I'm in no hurry but am researching right now.

Thanks for your input.

[Melih-Comodo]

-{ Quote: "Could be worth the wait. I'm in no hurry but am researching right now.

Thanks for your input." }-

Well the wait is over.. :-)
http://forums.comodo.com/index.php/topic,1047.0.html
you can try this if you like...

Melih

[speedlever]

Thanks, Melih... but that link gives an error page for me.

Edit: OK. Now it's working.