Does every application rule need "ask" at the bottom now?

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?

No, there’s probably something specific in your configuration, mind exporting it and uploading it so I can take a look?

I believe these are the relevant ones:

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?

Do you have any other application rules below that for “All Applications” or similar?

Could you show a screenshot of your firewall settings?

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

Okay, and the firewall settings?

Here it goes…

Hmm, not sure then, and it gets blocked again if you remove those rules?

(Can’t replicate the issue btw)

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

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

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

I actually made a bug report for this issue but they said they won’t fix because “Ping” uses native windows sockets which in a way is correct but I’m not going to argue the issue further.
Edit: Now looking back it may also be an issue with the way CIS integrates with the Windows Filtering Platform (WFP)

Edit2: Ignore everything I said about NDIS, its a WFP issue as there is another bug/flaw that wasn’t an issue with CIS v5 but since v6 and newer is now a problem with regards to jumbo frames support.;msg762184#msg762184

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