In versions 5+ of Comodo firewall, I was always asked whether to allow or deny outgoing connection for an application that wasn’t defined in the rules yet (or if the existing app’s rules didn’t match anything yet).
In 8+, however, I’ve noticed that if I didn’t also add an “ask” rule at the end of some application rules, those outgoing connections (which were not matching the existing app rules), would be blocked.
Is the “architecture” of this part different now, so that if there’s no explicit “ask” rule at the end of each app rules, they will be blocked automatically?
I had to add “ask” under “System”, otherwise ping or traceroute would just give “general failure” as output in Command Prompt. (Which is quite the opposite to what it was like a few days ago, when I wasn’t even asked anything and those two worked anyway.)
Is it possible there are some settings/rules leftovers in some settings file or registry?
No, those are the last two rules. As for Global Rules, I ran the stealth wizard after installation, which also added one “all applications rule”, which I later removed. Basically it’s the same as on my “old” computer with 5.x (except that there’s no “ask” rules on that one).
I removed the “ask” rules. Then I was actually asked on first run of ping or traceroute (for System to allow or deny connection). But the subsequent use of ping or traceroute (even in another command prompt window) worked without a question (and I hadn’t chosen “Remember my answer”).
After a reboot, it was the same - first ping/traceroute triggered the question, then it worked without asking.
Alright, that’s the session rules in action then, when you answer an alert that rule will stay in effect until the session ends although I think you should just be able to close cmd.exe and then it should ask again (maybe another hidden cmd.exe used by another application is open in the background meaning the session doesn’t end until reboot or until that one is explicitly killed?)
Edit: You also seem to have “Alert Frequency” disabled which I think effectively means “Low” which would mean that once you answer one outgoing alert then the firewall will treat all outgoing traffic from that application with the same rule for the session.
Probably. And this puts us back to square one - which is why this is now treated under “System” (where the session might as well be the whole computer uptime until reboot), and not separate (.exe) processes.
I’m afraid I don’t know that, I messaged BuketB about it but have yet to hear back. I would also like that behavior to change, I don’t want hard coded groups that one can’t know what they contain.
You are missing an Allow Out Global rule. As for ping and tracert being marked as “System” is a design flaw in NDIS 6 and newer which CIS and other 3rd part firewalls use for their firewall driver component. Any application that communicates over the network using ICMP will have its traffic be identified as coming from System which is actually a symbolic name for ntoskrnl.exe (Windows NT Kernel & System). CIS since version 6 uses a NDIS 6 or newer compatible firewall driver, where as CIS v5 had a NDIS 5 compatible driver.
Why would I want an “Allow All Out” global rule? I have “Block & Log” instead. I remember the allow-all rule was put there after running the stealth wizard, and it was the same a couple of years ago on 5.x. Back then, no one on the forum was sure about why that rule was put there, so we figured it was a mistake; I deleted it, and it’s been running fine without it.
Thanks for the explanation about System. As for NDIS 6 - isn’t it already used on Windows 7 (where I can have separate rules for ping.exe etc.; or even separate for 64-bit and 32-bit versions, when running a 64-bit Win7)?
Because for traffic to be allowed it must pass both application and global rules and comodo will process rules based on the direction of the traffic. For outgoing traffic application rules are processed first, and once a rule is found to allow it then global rules are processed before its fully allowed.
Thanks for the explanation about System. As for NDIS 6 - isn't it already used on Windows 7 (where I can have separate rules for ping.exe etc.; or even separate for 64-bit and 32-bit versions, when running a 64-bit Win7)?
Yes support for NDIS 6.0 was introduced in Vista, Windows 7 supports NDIS 6.20, the newest version of NDIS is 6.50 which is available in Windows 10. CIS version. But here's the funny part, CIS 5.12 which used a NDIS 5.1 firewall driver is compatible on Vista/7/8, so CIS version 5.12 is the last version to correctly identify the application that communicates using ICMP.
Hmm, I’m aware of that, but isn’t it so that as soon as the first suitable rule is found, then that’s it, no further processing? Hence the allow-out doesn’t really make sense (especially if you want to be prompted about something new wanting to connect out, and decide on case-by-case basis)?
(For instance, under svchost.exe, the first rule I have is to allow UDP out where destination port is 53. The second rule is allow & log IP Out for the rest. Therefore, DNS requests are allowed but not logged, whereas all other svchost.exe outgoing connections are allowed & logged. And for svchost.exe, that’s all there is in this setup.)
Even if there is an “Allow” in the application rules, it still has to go past the global rules, however if there’s no block or allow rule for the traffic in question then global rules is considered not answering it and then it’s allowed out because application rules says it’s allowed.
So if You have an “Allow” application rule then for global rules “Allow” means to allow it “Block” means to block it anyway and no rule means it doesn’t care and the application rules can do whatever.
So personally I remove all “Allow all” rules from the global rules since they’re basically useless and sort of ruins the security.
For a more in-depth explanation of how the outgoing rules work you may take a look at this quote
I remember the allow-all rule was put there after running the stealth wizard, and it was the same a couple of years ago on 5.x. Back then, no one on the forum was sure about why that rule was put there, so we figured it was a mistake; I deleted it, and it’s been running fine without it.