Jetico vs 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.

 

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

As already stated, this was inferred from your statment below in response to my posted alert,
:-

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

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

1/ Is this statement correct:-

2/ Is this statement correct:-

3/ and my question with ref to your statement

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.

 

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.

 

-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

 

See post #17 again, https://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

 

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

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

 

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

 

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.

 

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)

 

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

 

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.

 

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

 

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.

 

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?

 

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.

 

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.

 

Thanks Stem

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

Comodo Forums

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

 

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.

 

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.

 

Amen!
Mrk

 

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)

 

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
But it appears this does not work correctly (acording to the poster)

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

 

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)