A while back Comodo firewall auto generated a ping.exe rule as Allow. I didn’t know what caused that so I changed the rule to Ask. Rule appeared to work fine since occasionally I would see the rule in my firewall log as blocked due to my not responding within the time-out period to the rule alert.
I was just reviewing my application rules and it appears that the ping rule I edited to Ask was changed to Allow. Now I am positive I did not change that application rule.
Does Comodo now override your custom application rules as it sees fit?
If you want Custom rules respected you need to set the Firewall from Safe Mode to Custom Mode.
In Safe it will continue to allow Safe Apps.
Unless your Custom Rule is above the All Apps rule and in this case above the System Apps rule too, I suspect
The Comodo system app rule would have allowed the ping.exe automatically if a system process generated it and would have never created the ping.exe application rule in the first place. Correct?
Am I to infer from what you said that the Comodo system app rule will override any subordinate application rule for the same system application process? From what you stated this appears to be the case.
I am running in Stealth Mode and have no “All Applications” rule; just “System Applications.” See attached screen shot. Note I have already moved the ping.exe rule above the “System Applications” rule.
I agree with Bad. If you’re running the firewall in ‘Safe Mode’ Ping.exe will be allowed to connect and a rule will not be generated. If you’re running in ‘Custom Policy’ mode, you will receive an alert, which has to be acknowledged and remembered for a rule to be created.
1. The Comodo system app rule would have allowed the ping.exe automatically if a system process generated it and would have never created the ping.exe application rule in the first place. Correct?
The default ‘Windows System Applications’ rule refers to the group with the same name in D+, so you can check the details of the group, to see which processes are allowed.
2. Am I to infer from what you said that the Comodo system app rule will override any subordinate application rule for the same system application process? From what you stated this appears to be the case.
The firewall rules are hierarchical. So, if there are two rules that govern the same process, the rule that first matches the request will be used and subsequent rules will be ignored.
“If you’re running the firewall in ‘Safe Mode’ Ping.exe will be allowed to connect and a rule will not be generated.”
There is a caveat to the above. Unless you have checked the box to Create Rules for Safe Apps.
But then you would have to Ping somewhere to generate the rule.
Perhaps you installed something Trusted that uses Ping to test connectivity?
But then how in the He double hockey sticks did it get changed from Ask to Allow ???
I too would keep an eye for a while, since it defies explanation for me at this point.
There is a caveat to the above. Unless you have checked the box to Create Rules for Safe Apps.
Yes, I have Create Rules for Safe Apps checked so that is why the ping .exe rule is being created. I have a theory as to why it is being created - see below. My concern however remains how an existing rule can be arbitraily modified by a Windows system process. This would imply that Comodo when in learning mode will override an existing application rule under certain conditions. This can be both a good and bad thing. It's good in that the creator process is deemed "safe" by Comodo, overriding an exisiting rule is OK. It is bad since Comodo is not infalible and there might be valid reason to override it's default processing.
I have seen the ping.exe rulle appear ever since I installed WIN 7. Prior to my changing the Comodo generated rule to “ask” and whenever I saw the rule created, I would delete it and magically it would later appear.
This rule and many other strange ones generated by Comodo appear to be related to WIN 7 updates; especially the multiple updates generated monthly. Other strange WIN 7 updates sourced rules Comodo has created are rules allowing temp setup.exe files to connect and the like. I wouldn’t be concerned about this except that the setup files were created on the first volume of my third internal hard drive which contains no OS files whatsoever! When I check that HDD for these setup files poof - they are gone…
The longer WIN 7 runs on my PC, the goophier it gets.
I am about ready to pitch Comodo firewall on WIN 7 and return to it’s MS firewall. I am convinced MS is attempting to lock out most third party system and secuirty software from WIN 7.
If you make a custom rule for ping.exe that will always ask outgoing traffic and moved that to a place above the “All Applications” rule you will have control even in Safe Mode.
I have, on one occasion, seen this event on a test machine. However, I didn’t investigate, as I typically allow Ping, Tracert and pathping out by default on my main system. The event was an ICMP Type 8 Code 0 which is an Echo Request, to the main MS block 65.52.0.0 - 65.55.255.255.
If you’re concerned about this event, simply block ping.exe from connecting, either to the block above or entirely. Incidentally, Windows 7 firewall allows ICMP4/6 out to Echo Request by default.
I don’t have an “All Applications” firewall. See the screen shot I posted above. The rules on top, Comodo Internet Security, Windows Updater, and System Applications are the only Comodo rules that existed from day one.
I have moved the ping.exe above the Systems Applications rule so well see what happens. If a “system application” was generating the ping.exe, my ping rule should trap it.
On second thought, I am going to move it above the Wiindows Update rule since that is where I think it is originating.
I went back in my firewall log history to determine where these ping.exe connects are directed to. The IP address are either 65.55.56.40(Microsoft) or 64.4.10.44(Hotmail).
Obviously WIN 7 internally generated these. As I commented previously, I strongly believe this has to to with WIN 7 update activity.
I view a generated application firewall rule to all ICMP outbound from Any to ANY for ping.exe to be a security risk. Bots use ping.exe to dial home. So I think the firewall has a problem. More so in my case since I have a global firewall rule that indeed does allow all output ICMP conditioned by selected ICMP inbound rules.
In any case, a user generated custom rule should never be overridden by firewall generated rules as happened in this instance.
65.55.56.40 is the address used by Windows for NTP (Network Time Protocol) on port 123
time.windows.com
IP Tracing and IP Tracking (time.windows.com)
time.windows.com IP address location & more:
Host of the IP: time.windows.com[Whois] [Reverse IP]
Host IP [?]: 65.55.56.40 [Whois] [Reverse IP]
IP country code: US
IP address country: United States
IP address state: Washington
IP address city: Redmond
IP postcode: 98052
IP address latitude: 47.6801
IP address longitude: -122.1206
ISP of this IP [?]: Microsoft Hosting
Organization: Microsoft Hosting
Local time in United States: 2011-08-13 14:28
Funny you mention time.windows.com, Boris. This morning I noticed an outbound connection in the firewall log for UDP port 123. Guess what the IP was? 64.55.56.40! Also depending on which Whois site you use, the IP shown for time.windows.com can be 64.55.56.40. So much for accurate domain identiy since most show 64.55.56.40 as Hotmail.
Do you have VirtualBox installed? If yes, it could be part of the explanation for the activity you noticed. At each start up, VirtualBox triggered a NTP connection to time.windows.com to synchronize time with the Host.
Take a look at my attached pic. MS keeps wanting to connect to to 64.4.10.44. I am sure that this is not time update related. MS is just trying to find any available open port to get into my PC.
May be the server is overloaded and responds too late and breaks stateful inspection; the firewall thinks it is unexpected traffic instead of expected.
I would by what your saying Eric except for that first ping.
I have never seen that behavior on WIN XP; a system generated ping before a time update request if that is what it is. Also this ping activity is erratic. This is the first time I saw it preceding a port 123 request for example.