Some user blaming agains Comodo security...

I’m quoting a post of avast forums:

I’m far from being a firewall expert, but, has the writter any reason?
I mean, I got some BS letter as a reply today from the COMODO dev guys… is this serious?
Packet rules should be VERY rigid, whatever firewall you are using, isn’t Comodo weak on this point?

Thanks for your concern.

Message 1 By the way, I found a VERY interesting leak in COMODO yesterday. I was downloading CureIt! and it needs port 21 (FTP) and a very high port (somewhere around 64.000). I had it set to VERY HIGH security, which means it is supposed to let you know EVERY connection to EVERY remote port. It didn't recognize and/or warn me about the 64.000 range! So, it's either a bug, or COMODO itself is calling home through that range, which wouldn't surprise me. Too much 'snake oil' around this product if you ask me... Paul
Message 2 Hi, Nick!

I got some BS letter as a reply today from the COMODO dev guys. They are trying to say that this is not a remote address issue. The remote address ‘just spawns the ftp’ or something. According to them, this is not a remote connection issue. My logs show SYN flags from my computer to the addresses below on high ports, but this is not a remote connection issue… :=)

Here are the addresses that have to be allowed to download Dr.Web’s CureIt! Of course port 21 (ftp) but also:

  • ( port range 64000-65535

  • ( port range 64000-65535

  • ( port range 64000-65535

  • ( port range 64000-65535

  • If you allow ALL TCP Out to Any address, Any port you can download CureIt, but you won’t get an alert about high ports in COMODO.

  • If you restrict remote ports (21, 80, 90, 443, 5190) then you cannot download CureIt and you will see an Outbound Policy Violation log. No alerts however.

  • If you allow the addresses above, you can download CureIt, but you won’t get an alert about high ports in COMODO.

It’s very strange also that there are no application logs. Only Netmonitor (packet logs).

I think I’ve witnessed a very bad case of ‘snake oil’ here and I will never again recommend COMODO to anyone. And the lesson is clear: packet rules should be VERY rigid, whatever firewall you are using.


They didn’t say if they had “do not show alerts from application certified by Comodo” enabled or disabled.
I’m not sure i understand their post’s, but if i download something, I don’t get an alert from CPF because i use my browser and it is “certified” by Comodo (and me).
Or does he mean when he scan with CureIt?

I have “Do not show alerts from application certified by Comodo” disabled.

CureIt Download Webpage - set rule TCP/UDP Out Any to Log and will see “the problem”?!

If I want to download CureIt via IE, CPF will ask for the TCP listening port eg (1579), if I do not allow it (I have Alerts disabled by default), it will not download. In Firefox 2.0, CPF will ask nothing, it will allow random high port TCP In (60000 and up). Maybe it has something to do with TCP loopback or act as server setting, I do not know, I do not use use nor like Firefox, but the point is, that the firewall like Jetico will ask for that port. Also when I have TCP/UDP Out 1024-655535 blocked in the Network Monitor, CureIt will not download via Firefox.

If talking about bugs already, it is pity, that CPF even does not log everything, eg it does not log DHCP via svchost when it assigns IP, I had to improvise when creating my rules for it.

By the way, this is not about blaming, if someone mentions a bug in the software he uses, then it is because he wants it to be fixed, otherwise he would just move to other software. There is not a perfect software, but I consider software to be a perfect, when its developers are willing to listen to the users to improve it and to solve the issues, unlike the others.

I fully agree… It’s not a matter of blaming or not.
The problem is that I’m not an expert in firewalls or network communications.
So, I’ve posted here to listen from Comodo’s staff any answer to this question.
By the way, Paul posted in avast forum a way to reproduce the problem:

It would be nice to hear something from the programmers…

Yes the same issue we discussed,3647.msg27932.html#msg27932

It is about stateful FTP inspection. Yet i will reproduce the issue and see if we hit a bug in state engine or not. If there is such a case, it will definitely be fixed.


Many thanks Egemen!

If there is such a case, it will definitely be fixed.

This is why I love Comodo (R)

Here is the session data :

…220 Welcome to Dr.Web FTP service.
USER anonymous
s…331 Please specify the password.
230 Login successful.
200 Switching to Binary mode.
227 Entering Passive Mode (87,242,72,150,255,204)
SIZE /pub/drweb/cureit/cureit.exe
213 5227491
RETR /pub/drweb/cureit/cureit.exe
150 Opening BINARY mode data connection for /pub/drweb/cureit/cureit.exe (5227491 bytes)

1 - Host initiates an FTP connection to
2 - Host tells the ftp server so that it willl use passive mode
3 - Server accepts to use passive mode
4- Host initiates a connection to remote site over a port in this case between 64000-65535
5- CPF sees the attempt on Step 4 and checks its state table. It decudes that there has been a passive mode ftp connection attempt which belongs to the session established in Step 1 and approves it.

This is all about stateful session inspection. Let me explain how FTP works.

There are 2 modes in FTP protocol spec.:

1- Normal mode:

Step 1 - Host initiates a connection to ftp server on port 21
Step 2 - ftp server initiates a connection to the host on port 20(ftp-data)

In normal mode, non-stateful inspection firewalls have to allow incoming connections to port 20 to enable ftp operations. Otherwise ftp transfer will fail in the most of the cases.

CFW statefully knows these protocol characteristics and saves users from a big trouble.

2- Passive Mode(a.k.a Firewall Friendly Mode)

Since step 2 of normal mode usually can not be realised by non-stateful or semi-stateful inspection firewalls, passive mode is used by ftp clients to overcome this difficulty.

Step 1 - Host initiates a connection to ftp server on port 21
Step 2 - Host tells ftp server that it is going to use passive mode
Step 3 - Server assigns a port and listens
Step 4 - Host initiates a connection to the port in step 3

This mode does not require ftp server to initiate an FTP DATA(20) connection thus ftp protocol operates correctly if a firewall is installed.

Stateful FTP Inspection is mandatory to support normal mode FTP Clients. Otherwise users will have to allow incoming connections to FTP DATA(20) port. Thats why you will see port 20 to be allowed in many other firewalls when configuring ftp clients. CFW does this on behalf of users by means of state keeping.

When an FTP client enters the passive mode, a remote connection is established to the ftp server(The bold text above). Since CFW keeps the states, it knows that this connection belongs to the ftp session and statefully allows it without asking to the user. As previous posters have tested, disallowing it will make FTP transfer to fail.

So since this attempt belongs to a legitimate connection request(which means it belongs to the ftp session), it does not ask this to user. Asking the user would not matter but this is a design choice not to bother user about the protocol’s internal requirements. Afterall, this is a product for desktop users. In my opinion, even now CFW is asking some unnecessary questions.

CPF does not log every packet as well. Statefully allowed packets are not logged as you see in the packet sniffers. This is too much for a desktop user. Otherwise, you will see megabytes of logs everyday.

Hope this helps to make things clear.


Your position is now clear, and I hope that this incident is resolved. But I have one thing to say after reading your comment that CPF asks too many questions. Being an Independent Consultant at KL Forum for a certain period, I know now that users dislike strongly when sth is decided for them before. When a user sets up paranoid level of settings he won’t be angry about many alerts, believe me…

Thanks for the explanation egemen, I was hoping that it is something like that.
NickGolovko you are right, I deny everything automatic in my PC to have control.
I just like to know, what is going on, including asking for UDP loopback and so on.

2 egemen:

Thank you for your detailed explanation. I’m quite familiar with the ftp-protocol. I still wonder, though, why other stateful inspection firewalls (Jetico, Sygate, and others) ASK me about 64000-65535, and Comodo doesn’t… :wink:

As to your considerations of people seeing too many alerts and logs: this can hardly be an argument.
People who don’t want to see many alerts have possibilities abound on the Comodo firewall to limit these. First of all they can leave the default ‘Don’t ask me for applications certified by Comodo’ enabled, which will greatly decrease the number of alerts shown. If you use the default settings, you won’t get that many alerts either. They can also leave the security level on default, which will also minimize the number of alerts.

Besides, people who set Comodo to Very High Security are not the kind of people who hate alerts, and any complaints coming from them about ‘too many’ would be insane.

As to the megabytes of logs one would see by logging DHCP and Loopback: if the max log size is set to 5MB, so what? They won’t get more than 5MB on their computers, because old logs will be overwritten. Mine is set to 100MB and I don’t care. I want to have control over what goes on on MY machine, so I set Comodo to log EVERYTHING. I also want to have control over what Comodo itself does, because passing leaktests is not the only task of a firewall.

I set Comodo to ASK ME EVERYTHING (Very High Security), so I want to be asked EVERYTHING, and I don’t want Comodo to allow something silently, even if this is part of a standard protocol procedure, and a lousy, insecure procedure at that. This is mainly for practical reasons: a very quick setup of a very strong defence within the shortest possible time. In this case you just need ALL the details to make life easier afterwards. I hope this will be corrected in future editions of the firewall.

Here is an example of my COMODO rules:

This can only be accomplished if you use the ‘Very-High-Security’ settings and log EVERYTHING.

And as far as DHCP and Loopback are concerned: they SHOULD BE LOGGED.
DHCP is Inbound-and-Outbound traffic you allow, and the protocol CAN be abused, the server addresses spoofed, and so on. The allowed server addresses should therefore be restricted, just as is the case with DNS (which should be allowed only on an application basis, not globally).
Loopback: People who use proxies should be particularly careful with loopback. Malware can abuse loopback to get out via the proxy, so this function should not be automatically allowed and certainly logged if it has been allowed for some application. For now, there is no logging feature for this tricky function in the Comodo firewall.

And I wrote this before on this forum: there MUST be Application Logging. When you go to one site, as a rule you are automatically connected to 3-5 ip-addresses at once. I don’t want to see only the addresses (Netmonitor log), but I also want to be able to check whether it was really Firefox going there, or something else…

Paul Wynant
Moscow, Russia

Because they do not have stateful FTP inspection. With them, for example you have to define port 20 as a rule for normal ftp operations. Anyway.

All your other points are good candidate entries for our wishlist. You can always request them as features and we already promised our users that we will implement what they ask. For example, we can easily make application monitor to do static inspection on High + very high frequency mode(We can put this feature in upcoming 2.4).

Some of them(some logging related ones) are already implemented in our new application rules interface. Our users who follow the forums will immediately notice that we have been working on a new application rules interface, which is significantly different than the current one. It should be available after CFW 2.4 Multi language release.

Now we are working very ■■■■■■■ CFW 3.0 release to give our users a christmas present if we can. So please forgive me if i can not follow the discussion here any further.

Thank you all for the feedback.


Update : In CFW 2.4 Release, which is due to a couple of weeks, we have decided to put the features we talked about in this thread. So In high freq mode, CFW will ask for everything instead of doing advanced state analysis on behalf of the user. For high freq users, we believe this is a fair request

[b]Update : In CFW 2.4 Release, which is due to a couple of weeks, we have decided to put the features we talked about in this thread. So In high freq mode, CFW will ask for everything instead of doing advanced state analysis on behalf of the user. For high freq users, we believe this is a fair request[/b]
We look forward to it. ;D

Sounds like music to my ears… :slight_smile:

Paul Wynant
Moscow, Russia

This Comodo just gets better and better doesn’t it?! :BNC

I can’t wait :BNC

But please rename it instead of “high frequency”, “paranoid”. It will save the forum from a lot help topics. (:TNG)

They don’t have to rename it, they only have to add a step at the top called Paranoid… :wink:
Or add a big red button called “Don’t do this at home!” ;D