CIS FW driver and Wireshark npcap driver

Comodo Internet Security - CIS Firewall Help - CIS
1

When using CIS FW and Wireshark with npcap packet capturing driver where does the CIS FW driver and the npcap packet capturing driver fit in below flow and in what order?

(outbound = top to bottom flow, inbound = bottom to top flow)

1 - Application layer
2 - Windows OS layer
3 - Windows Kernel layer
4 - Hardware layer (network adapter)
5 - Physical layer (cable / wireless)

Is it like this:

1 - Application layer
2 - Windows OS layer
3 - Windows Kernel layer
3.1 - CIS FW driver
3.2 - npcap packet capturing driver
4 - Hardware layer (network adapter)
5 - Physical layer (cable / wireless)

In other words, where does npcap sniff the traffic?
After the CIS FW driver or before it, or else?

Thanks.

2

Google is your friend: Wireshark Questions

3

You will notice that both the CFW driver and npcap driver are both listed and thus attached to the network adapter when you view the network adapter properties. Npcap won’t see certain packets when the firewall blocks them, I just don’t remember exactly other than I know you wont see the forged TCP RST packets that the firewall sends in response when you use block action for an application.

4

I asked our friend Google too but I couldn’t find a match to my question, glad you found one, thanks! :-TU

5

Yep, both CFW driver and npcap driver are listed and attached correctly to the network adapter when I open up the network adapter properties.
Both CFW and Wireshark work nicely, however… now here it comes…

When I ping www.comodo.com with ping set to Blocked Application in FW Application Rules I still see the outgoing ping request in Wireshark as follows:

“2”,“0.506941”,“”,“2610:1c8:1a::1”,“ICMPv6”,“94”,“Echo (ping) request id=0x0001, seq=57, hop limit=128 (no response found!)”,“2610:1c8:1a::1”

Note: ping resolves 2610:1c8:1a::1 to www.comodo.com

When I set FW to Block All mode than there is no outgoing ping request as shown above.
Also when I Block HIPS DNS Client Service for ping (with FW in Safe mode) than there is also no outgoing ping request as shown above.

I am a bit puzzled by this, is ping (or any other application) still sending outgoing (non-DNS) requests when it is set to FW rule Blocked Application in FW Safe mode with HIPS DNS Client Service allowed?

6

You should ping using an IP address instead of by host name also, for IPv6 you need to make sure you enable IPv6 filtering. But I did some tests and wireshark will not see any packets for outgoing connections of blocked applications. Blocking ping does not show ping requests, blocking a web browser and attempting to access say the router web page by IP address, wireshark will not show outgoing TCP packets when capturing with npcap.

7

I will try ping with ip addresses too.

FW Setting “Filter IPv6 traffic” was enabled (ticked) all the time.

Did you use npcap or WinPcap with Wireshark for your tests?
Which version of Wireshark, npcap or WinPcap did you use?

8

I used npcap 0.9995 and wireshark 3.2.5 you are still capturing with winpcap so you would need to uninstall winpcap. Otherwise try installing npcap without winpcap compatibility mode which is selected by default in the installer. Winpcap captures closer to the application layer, in your list the windows OS, so it will see outgoing packets that really do get blocked by the firewall.

9

I’m using npcap 0.9995 and wireshark 3.2.5 too (WinPcap was never installed before).

Now, I did many pings using ping 2610:1c8:1a::1

Result:

Regardless of HIPS DNS Client Service Allowed or Blocked for ping - Wireshark shows all ping requests (with FW in Safe mode).
Ping sends out 4 requests by default per run and all 4 requests are shown in Wireshark.
I did try many ping runs over time to allow communication stack to settle, but unfortunately all ping requests are still shown in Wireshark.

When FW is in Block All mode than no ping request is shown.

I will try ping with IPv4 too later, see if that behaves differently.

10

Here are the ping IPv4 tests . . .

ping ipv4.l.google.com
Same result as with above ping IPv6 tests, also the same is that HIPS DNS Client Service access setting (Block or Allow) does matter.

Note: ping resolves ipv4.l.google.com to 172.217.17.78

ping 172.217.17.78
Same result as with above ping IPv6 tests, also the same is that HIPS DNS Client Service access setting (Block or Allow) does NOT matter in this case.

When FW is set to Block All mode then no ping requests in Wireshark are shown (same as above with IPv6 tests).

So ping with IPv4 behaves the same as with IPv6, ping requests are shown in Wireshark when ping is set to FW rule Blocked Application.

Am still puzzled by these outgoing blocked pings . . . ?

11

It looks like they broke something again as 6882 you won’t see the packets that are being blocked, whereas 7036 it shows up in wireshark when capturing with npcap. In the past if you were using WinPcap, you could see the attempted outgoing packets. I first tested with 12.0.0.6882 which didn’t show any packets, but then I tried 12.2 and
I saw what you were describing.

12

I am glad (or not so glad from this great tool’s point of view) that you could reproduce the outgoing blocked pings in Wireshark.

Would it make sense to re-install npcap with disabled WinPcap API-compatible Mode and try again if Wireshark shows the outgoing blocked pings (or are you using this mode already and seeing the packets too than I don’t have to test that)?
I installed npcap with default settings except that I enabled (ticked) the admin_only mode for security/safety reasons.

Furthermore I will try to monitor and capture the network traffic in the router and investigate the network traffic dump file if the outgoing blocked pings really go out on the internet.

13

Uninstalled npcap and re-installed with disabled WinPcap API-compatible Mode (unticked) and with admin_only mode enabled (ticked as before).
However, disabling WinPcap API-compatible Mode does not solve it, I still see the outgoing blocked pings in Wireshark.

14

I not even sure anymore as I’m seeing different behavior even on 6882. I had npcap installed before comodo firewall and I didn’t see packets, then I tried switching to winpcap which then I was able to see packets. Then I went back to npcap and was still able to see packets when originally I didn’t. It could be depending on if npcap was installed before hand or if winpcap was ever installed that is cause different outcomes.

15

I spent time searching the internet for a clear answer where npcap sniffs the traffic in the communication stack. Up to now I only found many different answers (including Ploget’s find). One says it sniffs the traffic between FW and NIC and the other says it sniffs between application and FW or another one says a combination of the previous two answers.
So till now it is not clear to me where npcap sniffs the stack.

In order to find the answers myself I tried to play with CIS FW Global Rules and setup some Global Rules to block a single IPv4 address for traffic coming in or going out for testing with ping.

Now, I found the following behavior which I don’t really get.

Note: In FW Application Rules ping is set to FW rule Allowed Application for the remainder of this test.

Outgoing Global Rule

In FW Global Rules added at the bottom of the list the following rule:

Action : Block
Protocol : IP
Direction : Out
Source address : Any Address
Destination address : IPv4 Single Address 172.217.020.078
IP details : Any

Executing ping 172.217.20.78 results in the same strange observation as reported earlier, outgoing blocked ping packets are shown in Wireshark. So no change here.

Incoming Global Rule

In FW Global Rules changed the above added Global Rule into:

Action : Block
Protocol : IP
Direction : In
Source address : IPv4 Single Address 172.217.020.078
Destination address : Any Address
IP details : Any

Now when executing ping 172.217.20.78 ping sends and receives(!) the ping packets. Also Wireshark shows both ping packets, request and reply.

It seems the incoming Global Rule isn’t blocking the incoming ping traffic from 172.217.020.078. Even swapping Source and Destination address in the incoming Global Rule didn’t change a thing, ping request packets go out and reply packets do come in.
I deleted the incoming Global Rule and created a new one and even moving it up or down the Global Rules list, I did this multiple times but to no avail.

Since this Global Rule for incoming traffic isn’t working I can’t continue finding out where npcap sniffs the traffic…

Please someone check if a Global Rule for blocking incoming traffic for an single ipv4 address as shown above is working or not?!

EDIT:

Deleting the incoming Global Rule and changing the FW Application Rule for ping from Allowed Application into Outgoing Only result in the same effect, ping still receives the incoming ping reply traffic!

16

Both npcap and comodo firewall driver (inspect.sys) are NDIS 6.x lightweight filter drivers which are bound to the miniport adapter (NIC/network adapter), they are both a Modifying Filter Driver with the same filterclass, depending on which one was installed first is the order they see outgoing and incoming packets. The reason you see “blocked” outgoing packets is because npcap was installed after CFW which means it sees packets before CFW processes those packets.

Packet flow of outgoing network traffic:
Application(user-mode) > Windows OS(kernel-mode) > TCP/IP network stack(protocol binding) > Npcap(LWF driver module 1) > inspect(LWF module 2) > network adapter. reverse the order for incoming packets.

As for why you can’t block incoming ping replies with global rules is because those are part of an existing “connection”, cfw is a stateful packet filter so that when you send outgoing packets such as ping requests, the ping replies will be allowed back. The rules work on where the initial connection starts from, so your global rule to block incoming from an IP address will block any packet originating from that address that is not part of an existing connection. Also rules are processed from top to bottom, so your block outgoing rule will not work as it is below the global allow out rule.

17

Thanks for this clarifying info. In my search for answers I found and read same information too. It is like you say - and I was also thinking in that direction - that the installation order of filters with the same filterclass determines the bounding order in the communication stack. I also searched for if it would be possible to change this bounding order (by changing load order or filter priority) in an easy way, It seems to be difficult to change it or maybe impossible at all.

If you are interested, the following npcap reg key might have something to do with the bounding order of npcap but I would not start messing with it unless someone who knows how it works and tells me how to change the order. :slight_smile:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\npcap\Linkage

Nevertheless, all this information is good to know when observing and analyzing (firewall) traffic in Wireshark or other sniffers.

Ah, that explains it. That’s a concern less, thanks a lot.

As for the rules processing order, I always consult the handy flow image shown on this page when I need to: Global Rules, Firewall Protection, Best Firewall, Network Connection - COMODO

18

As a last test I used another PC on the LAN to ping the PC on which I run the CIS/npcap tests.
Without any FW rules for that other PC I see ping packets (request and reply) in Wireshark which is correct.
When I setup a FW Global Rule for blocking incoming traffic from that other PC (single IPv4 address set to the other PC’s local address) then no ping packets show up in Wireshark which is also correct.

So together with the earlier findings and information this confirms the flow:

Note: read > as outgoing traffic direction and < as incoming traffic direction.

Application(user-mode) <> Windows OS(kernel-mode) <> TCP/IP network stack(protocol binding) <> Npcap(LWF driver module 1) <> inspect(LWF module 2) <> network adapter.

Great that we found out were npcap is sniffing the traffic and that CFW/npcap installation order plays a role in it. :-TU :slight_smile: