Today, when an application that is acting as a server and has its own “allow” rule for incoming traffic – is not running, then you see in the CIS log that “Windows Operating System” blocked the incoming traffic.
This behavior is not good for the following reasons:
It can flood the log
The traffic reaches the OS, which can be vulnerable to applicative attack from the incoming traffic
Depending on the OS networking response pattern – it can expose the existence of the computer and possibly the OS type and possibly version
I believe it will be better if CIS will handle such traffic – hence CIS will enable users to have a rules section (or sub-section for the current applications rules section) instructing CIS how to handle incoming traffic for a process ONLY WHEN IT IS NOT RUNNING – e.g. block it by CIS (DROP action) or possibly redirecting traffic by a kind of CIS NATing or redirecting traffic to another, live, process (kind of a workflow) – and whatever you think users will need/wish to do with this traffic
These rules will of course not be applied/processed when the process is running.
1. What actually happened or you saw:
Today, when an application that is acting as a server and has its own “allow” rule for incoming traffic – is not running, then you see in the CIS log that “Windows Operating System” blocked the incoming traffic.
2. What you wanted to happen or see:
I believe it will be better if CIS will handle such traffic – hence CIS will enable users to have a rules section (or sub-section for the current applications rules section) instructing CIS how to handle incoming traffic for a process ONLY WHEN IT IS NOT RUNNING – e.g. block it by CIS (DROP action) or possibly redirecting traffic by a kind of CIS NATing or redirecting traffic to another, live, process (kind of a workflow) – and whatever you think users will need/wish to do with this traffic
These rules will of course not be applied/processed when the process is running.
3. Why you think it is desirable:
The current behavior is not good for the following reasons:
It can flood the log
The traffic reaches the OS, which can be vulnerable to applicative attack from the incoming traffic
Depending on the OS networking response pattern – it can expose the existence of the computer and possibly the OS type and possibly version
I believe the suggested feature will prevent the above undesired results of of the current behavior - as the the request (incoming or outgoing) will not reach the local OS, but either will be handled by CIS the way the user wish and hence elevate the security stand of the installation.
As noted, this option within CIS is (only) for systems already infected .
If your server is already infected, maybe you should clean it up. Otherwise, disable this setting.
Not true, in fact when you see a block event with Windows Operating System listed under application column it means the firewall blocked it from being sent to the OS. If the packet had made it the OS and there was no application listening on that given port, then Windows would send either a TCP packet with the RST (Reset) flag set to the sender or an ICMP Destination Unreachable - Port Unreachable (Type 3, Code 3) error message if the connection attempt was for a UDP port. This is all because the firewall filter driver resides in the kernel at the same layer where the OS kernel resides and hence filter packets at the kernel aka ring0.
3. Depending on the OS networking response pattern – it can expose the existence of the computer and possibly the OS type and possibly version
Due to above, Windows never sees the incoming connection request, so it will never know to send the appropriate response. To very this you could run a port scan against the port that you have made an allow incoming global rule for and seeing the results from the port scanner. You can use [url=http://nmap.online-domain-tools.com/]nmap online[/url] to check.
I believe it will be better if CIS will handle such traffic – hence CIS will enable users to have a rules section (or sub-section for the current applications rules section) instructing CIS how to handle incoming traffic for a process ONLY WHEN IT IS NOT RUNNING – e.g. block it by CIS (DROP action) or possibly redirecting traffic by a kind of CIS NATing or redirecting traffic to another, live, process (kind of a workflow) – and whatever you think users will need/wish to do with this traffic
These rules will of course not be applied/processed when the process is running.
Thank you!
Regards,
Eitan Caspi
Israel
Yep that’s exactly what comodo firewall does, it silently drops the packet without the sending host knowing it was blocked/filtered.