Time Synchronization and Comodo's pseudo UDP SPI

Let's see if I have understood correctly a few things and maybe also able to help clear some concepts to others.

First the clock update preliminary information that are same with any firewall:
1. When starting the update from the systray clock, the svchost.exe sends an UDP packet from local port 123 to time server (default IP 207.46.130.100) port 123.
2. The time server responds to that packet by sending an UDP packet back containing the time value from remote port 123 to local port 123, svchost.exe.
Notice that the sent and received packets are not necessarily belonging to the same internet connection, but they are related in a sense that it is a request and a reply.

Step 1 in CPF needs to allow in Application Monitor svchost.exe to connect to timeserver IP, UDP port 123. Besides the default allow UDP out to any ip and port network rule allowance.

Now to step 2.
Most CPF users have the default Network Monitor rules of not allowing incoming connections unless running some server type applications.
It is not needed either with time synchronization. Thanks to Network Monitor's SPI, Stateful Packet Inspection.
The incoming reply connection is passed in despite the no explicit UDP incoming allowed rule.

Then CPF Application Monitor that is in my knowledge not implementing any SPI bookkeeping comes to play.
There needs to be a rule allowing svchost.exe allow incoming UDP for local port 123 to your computer IP (or your PC's hostname).
Notice that CPF application incoming rules are more limited than with firewalls like Sygate or Kerio 4 since these allow to specify the remote source server IP. But I see this not as a serious risk if any since normally only SPI matching incoming connections are passed in?

Though for low numbered ports one should not make any Network Monitor rules for passing them in. And unsoliticed connections that some apps require to open some ports. It is a bit bother when Comodo in low alert settings then allows Server access to most any applications. Not in very high level alert settings. They only need the loopback access in most cases.
So something to be carefull against not allowing inbound in network rules too much, in case some baddie is there waiting to accept unsolicited connections with full server rights. Otherwise I guess the default install for newbies is ok.

Kerio 4 has pseudo UDP SPI in application rules and thus no incoming rule is needed for this clock update example.
Older firewalls like kerio 2.1.5 or Sygate 5.5 have no pseudo UDP SPI. But they can be configured tight with rulebased rules.

Comodo has decided to be very uninformative how their firewall is actually really working, but above are the conclusions I have come to so far.
Hope this helps others besides me, if above is correct?

Jarmo

EDIT
Posted this also to Comodo forum, but here too since I value the community here a bit more

 

No comments I see. Guess I have to comment myself.

I started to actually like Comodo, since knowing now I think how it works.
Great potential for most users firewall.
A few things why I am now again back to my trusted kerio 2.1.5.

Somewhere while playing with Comodo component control, not sure how, I lost from my computer the feature of applications starting other applications. Some permanent changes were made to somewhere that should not had done.
Now I cannot use certain features like opening a link into browser by clicking email post link in Thunderbird. Or starting firefox either from trillian or yahoo.
That happened I think with Comodo 2.3 version.
The above thing is only a minor inconvinience though.

This morning I noticed Firefox was not opening some pages. Propably DNS. But it was not cause of my rules. I changed my network card's MAC address to get a new IP and that worked just fine. Foxie could browse well. Changed back to original IP, still no surfing, except when Comodo was allowed all or disabled.

It is, with so many features things can go wrong. Also from the user interacting, but I doubt that was the case.

It is so nice to have a solid packet filter like kerio 2.1.5. All working as expected. But also nice sometimes to experiment with others. And when I someday in the future will have to leave Windows XP, that of course means also goodbye to kerio 2.1.5.

 

Hi Jarmo P,
It as been a while since I took a long look at Comodo. But from the info in your first post, that was basically correct.
SPI (stateful) is made on TCP on the network rules, this handles the replies (stream). How deep the inspection is, I have never fully checked.

For the pseudo state, yes, UDP is connectionless, so only a pseudo state table can be kept. This is normally just a check on the packet sent (with relavent info) so that the returned packet is allowed. This would normally have a timeout (if the packet is not returned within a set time, then the packet is dropped).

As for your problems, is there not now a "reset" available within the later builds?

 

Thanks Stem for the reply.

No, I did not check the matter more about that connection problem but went back to kerio 2.1.5. There was though a setting to make the basic firewall settings, as default install was, back. Allowing also those Comodo certified trusted programs without asking, heh.

About that other thing, opening Firefox from other programs not happening. It is a permanent change to my computer. It could be some windows service maybe or then some registry change made perhaps. But those things are out of my knowledge to search, especially when this happens to be a Finnish language XP Home, so those services are also in finnish and thus not much fun trying to Google about them. It happened I think, but not absolutely sure with 2.3 version. So I went back to 2.4 to see if the new install would fix it.

But I don't want to bash Comodo more about this thing since it could be many other things too. My system has some stability problems relating to hardware, and a sudden reboot could have initiated this thing.

 

Hello Jarmo P,

I have been having a look at Comodo. (2.4.16.174)

There is no need to set rules to allow inbound on the application rules. You can place rules, as example for DNS, HTTP as outbound only and the returned packets are allowed.
There is an alert for firefox to act as server, but this can be misleading, as this is for the localhost comms. But, even with no outbound allowed to the localhost the alert is still shown, which means that the alert is actually that the application is listening on port.
I also notice that the problem with the application rules is back again, explanation: At one point, there was a problem with the application rules, as when you place a rule to block an IP it would be placed incorrectly within the rules priority, so that the rule was bypassed by an allow rule, what I mean is, you can place a rule to:
Block outbound TCP_ remote IP x_ remote port 80
then place a rule to:
Allow outbound TCP_ remote IP any_ remote port 80
These 2 rules are placed wherever Comodo wants them to go, so the allow rule can allow a connection to IP x. On further connections, if a component is added to the browser, the rules change place again, (and the user cannot place these rules in the order they want, Comodo will just keep moving them around)
I also had a quick look at the at some leaktests,.. I thought Comodo was supposed to intercept the PCFlankleaktest? This leak leaked.

 

Stem, that time update needs you to have allowed incoming udp 123 to your PC IP for svchost.exe? You may have allowed that in a popup and then it should work with no rule in place, but not normally. After reboot I mean.

For DNS, if I remember right, it needed only outbound to my ISP servers for every application.

And in some cases to allow localhost traffic too inbound either to 127.0.0.1 or in some early starting applications like Avira Antivir, also to 0.0.0.0. Otherwise the guard would not open. That was all incoming rights needed for programs like browsers. Skype I think was needed to allow incoming for that special one port to IP 0.0.0.0. But no need to open that port in network monitor. Not sure, but worked anyways for me.

I can tell only from memory, but for DHCP I had allowed incoming from my cable modem address to udp 68, for generic host process. Of course outbound to my isp server to port 67 for svchost.exe. All this just from my memory that could fail.

It seemed to me to be basically a sound firewall. No problems with the default low level alert settings for normal users that gives for applications full server rights. I though used the very high level setting and then always edited my rules to allow more when wanting. Allowing all inbound is ok since it is prohibited by the network rule, so only SPI matching connections are passed.

The only inconvinience I saw is that block all rule in the bottom in network rules. With that in place you won't get alerted for server access for programs like torrents and other server needing apps. It is not as convinient as with kerio etc. when you get asked. If one has not stupidly made in kerio a bottom block all rule like that. Especially as the Comodo log view is as it is, quite spartan. Also network rules should be able to be ticked on/off.

Just my comments,
Jarmo

EDIT

I did not test it, though when making tighter rules, I also did block some IP's and then for the same application allowed all, so a good question.

Aah, leaktests, I never got into them. Thanks for the information. Myself just happy with my old kerio 2.1.5 that sure does not pass much leaktests alone but is a really nice packet filter and running now the old and goldie PG free too that sure is not very powerfull against those either