A. THE BUG/ISSUE (Varies from issue to issue)
CIS no longer detects network communication from applications that can transmit low-level packets using third-party NDIS protocol stacks e.g. WinPcap Can you reproduce the problem & if so how reliably?:
Yes very reliably If you can, exact steps to reproduce. If not, exactly what you did & what happened:
1:set firewall mode to custom ruleset and alert frequency level to high.
2:install nmap and/or nping Download the Free Nmap Security Scanner for Linux/Mac/Windows
3:from the command line run nmap.exe -p 80 google.com or nping.exe --tcp -p 80 google.com
4:notice no firewall alert except an alert for nmap performing a dns lookup on udp port 53. One or two sentences explaining what actually happened:
low-level packets that are sent without using the windows tcp/ip networking protocol stack bypasses the firewall without detection. One or two sentences explaining what you expected to happen:
Prior to CIS version 6 (v5,v4,v3) an alert would be displayed indication that Windows Operating System was trying to connect to the internet because CIS couldn’t detect the real process making the request, see attached screenshot. I expected this alert to be displayed. If a software compatibility problem have you tried the advice to make programs work with CIS?:
N/A Any software except CIS/OS involved? If so - name, & exact version:
Nmap version 6.47 and nping version 0.6.47 with WinPcap version 4.1.3 Any other information, eg your guess at the cause, how you tried to fix it etc:
I think with the new packet filtering incorporated in newer releases, CIS ignores or no longer can detect transmitted low-level network packets.
Here is a video showing the behavior on CIS v5 - YouTube and here is what happens with CIS 8.2 - YouTube as seen in the video no alert is displayed as the raw packets are sent out over the network. B. YOUR SETUP Exact CIS version & configuration:
CIS version 8.2.0.4591 Proactive configuration. Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
HIPS=Safe Mode, Auto-sandbox=Disabled, Firewall=Custom ruleset, AV=not installed Have you made any other changes to the default config? (egs here.):
Alert frequency level set to high, enabled all firewall advanced settings: ipv6 filtering,loopback filtering,block fragmented IP traffic,Protocol analysis,anti-arp spoofing. Have you updated (without uninstall) from CIS 5, 6 or 7?:
No if so, have you tried a a a clean reinstall - if not please do?:
Yes Have you imported a config from a previous version of CIS:
No if so, have you tried a standard config - if not please do:
Yes OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Windows 7 SP1 x64,UAC=Disabled,admin account, real system no VM Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
a=N/A b=N/A
Here is a video showing the behavior on CIS v5 - YouTube and here is what happens with CIS 8.2 - YouTube as seen in the video no alert is displayed as the raw packets are sent out over the network.
Bump, this is a serious security bypass as being able to communicate over the network without an alert can lead to data exfiltration and other security risks.
CIS version 8.2.0.4591 still can’t detect low-level raw network packets that bypasses the native Windows TCP/IP stack using a custom third-party NDIS protocol driver.
From what I remember the old CIS V5 had an option in Firewall settings called “Monitor NDIS Protocols other than TCP/IP”. From CIS V6 onwards this option apparrently got removed from Firewall settings. I am not sure if it has anything to do with this Bug though.
Perhaps a Wish to bring back this option could be made?
Yep, but even with the option disabled, at least on windows 7, CIS was still able to detect low level packets. So I just assumed that CIS was always monitoring other NDIS Protocols regardless of the setting therefore removing such option from the firewall settings.
Comodo should bring back the Firewall’s ability to detected low level packets and also should bring back the option to enable or disable it, and make it enabled by default.
Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.
Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.
As much as I would like to get this fixed, I believe comodo will not fix this issue due to the way CIS is integrated and relies on the windows filtering platform for packet filtering. In addition, the only way an unknown application or malware can send packets that bypasses the windows networking stack, is to use a 3rd party NDIS protocol driver that is capable of sending raw packets (e.g. WinPcap) that is installed and running. If no such protocol driver is installed or running, the unknown application or malware would have to install and then load/start the driver, in which CIS would stop when said application is running in the sandbox, or user will be asked for permission to install/load driver via defense+/HIPS alerts. Even if such protocol driver is installed and running, an alert will be displayed for accessing the Windows Socket Interface.
@futuretech, that would not be new. There are similar issues (such as Bug 665) limited by MS filtering framework.
Some kind of analysis would rely on comparison with other products (Third-party Firewalls, Windows Firewall) in order to check if it can be resolved without too much efforts.
The only comparison I can make is that the last version of CIS that was able to detect raw packets was 5.12 which had and option called ‘Monitor NDIS protocols other than TCP/IP’ which really only applied when installed on windows xp, because on vista & 7 even with that option disabled, I would still get firewall alerts from “Windows Operation System” when I used nmap or nping which send raw packets with the Winpcap protocol driver.
So unless comodo is willing to ditch the windows filtering platform (WFP) and re-implement the network firewall filter that was used in 5.12 or re-add the aforementioned setting which when enabled, would load a different or secondary packet filter driver (but this would mean comodo would have to maintain two different firewall drivers, which I don’t think comodo would be willing to do) that can monitor other NDIS protocols, then I don’t see this ever being resolved.