Comodo Default System Applications Rule

Comodo Internet Security - CIS Firewall Help - CIS
#1

Comodo ver. 5.x.x.1355. Stealth all ports mode.

I finally checked the option to have Comodo gen rules for safe applications.

I was somewhat surprised by the this Systems Applications rule it generated. I assume this replaces the individual rules for System, svchost.exe, etc. prior ver. Comodo firewalls generated?

What is the processing behind this Systems Applications rule? Are all OS app. certificates, hashes, etc. verified before the system class app is allowed to execute? Or is only a “safe” list being used?

[attachment deleted by admin]

#2

The system applications are recognised by signature or hash.

In v5.4 some of the Windows system are listed in Trusted Files list. That is because that is a quicker look up method than checking the signature. That list works with hash look up.

#3

Thanks, Eric.

So if I wanted to create a rule for svchost.exe, I would have to move it above the systems applications rule I assume.

Also I was somewhat puzzeled by not seeing a DNS subrule generated for each outbound TCP request. I assume that Comodo is defaulting to the global DNS function in svchost.exe? Although the Avast network processing does strange things to outbound Internet requests. Everything is going though 127.0.0.1; even outbound UDP activity from IE8. It almost appears that Avast network processing is actually doing DNS name resolution.

#4

That should work. If I recall correctly rules are read top-down.

Also I was somewhat puzzeled by not seeing a DNS subrule generated for each outbound TCP request. I assume that Comodo is defaulting to the global DNS function in svchost.exe?
It gets the default Allow Outgoing Traffic rule and that suffices unless the gateway uses Bootstrap Protocol.
Although the Avast network processing does strange things to outbound Internet requests. Everything is going though 127.0.0.1; even outbound UDP activity from IE8. It almost appears that Avast network processing is actually doing DNS name resolution.
I think Avast relays all traffic including DNS requests.
#5

I played around with the default web browser rules Comodo has applied to IE. From what I could tell, best to leave the defaults that Comodo creates. Avast appears not to work properly when using the Comodo web browser rules.

Been logging all the outbound connects and all is well except … First, I am getting a lot of outbound svchost.exe UDP traffic from port 1900 127.0.0.1 to port xxxxx 127.0.0.1. Don’t know what to make of that since Avast doesn’t use svchost that I am aware of.

I also saw one log entry for port 138 outbound to Microsoft’s IP range 65.xxx.xxx.xxx. Perhaps I have to create some inbound block rules for the NetBIOS ports?

#6

When you have Avast installed it acts a s a local proxy, so, all requests from your browser are routed via localhost 127.0.0.1. Although from what I’ve seen, unlike other local proxy servers, Avast doesn’t use a specific port, rather it uses any dynamic port. I guess that may be configurable in the interface somewhere…

If you’re using the pre-defined browser rule it should work correctly, as one of the individual rules allows IP out to the loopback Zone (127.0.0.1/8).

If you have the SSDP/UPnP services enabled, which they are by default, svchost will make connections over UDP to 239.255.255.250 port 1900. SSDP uses either TCP or UDP on port 2869. The fact that the address is loopback (127.0.0.1) means the port is probably coincidental, as svchost also requires looback connections for both UDP and TCP, something like TCP/UDP - Out - 127.0.0.1 - ANY.

Standard NetBIOS uses three ports by default, 137, 138 and 139, SMB over TCP uses port 445. The NetBIOS datagram service (UDP over port 138) is used to send unicast messages to either individual PCs or to a group of PC’s. The fact that it seems to be sending to Microsoft, might suggest your router is not filtering outbound NetBIOS packets correctly.

The easiest thing to do, is create a Port set and call it NetBIOS. Include the aforementioned ports and then create a rule for the system process that:

Action - Block
Protocol - TCP and UDP
Direction - Out
Source Address - ANY
Destination Address - ANY
Source Port - ANY
Destination Port - Set of Ports - NetBIOS

You will, of course, have to have rules for the System process that allows communication between devices on your LAN, preceding this block rule. You don’t need to block inbound NetBIOS traffic if you have a Block IP in as a final Global rule.

#7

When you have Avast installed it acts a s a local proxy, so, all requests from your browser are routed via localhost 127.0.0.1. Although from what I’ve seen, unlike other local proxy servers, Avast doesn’t use a specific port, rather it uses any dynamic port. I guess that may be configurable in the interface somewhere…

For IE, Avast web shield, i.e. Avastsvc.exe, single threads everything through 127.0.0.1 TCP port 12080 as the sending port. It will additional dynamically use ports in the 12000 - 12999 range. It primarily uses port 80 as the receiving port although it can redirect via 80xx ports. See attached screen shot.

Interestingly, it excludes https, port 443, traffic. I assume that is due to the SSL implications. This might be illuminating to users of Avast that think web shield is protecting their secure web site access.

Avast web shield creates a “dymanic” local host proxy which is somewhat unique.

When I appplied Comodo’s default web browser rules to IE, it totally altered the Avast web proxy behavior. The web proxy via Avastsvc.exe is the entity that is connecting to the Internet. When Comodo’s web browser rules are used, it is IE that is connecting which in effect negates Avast’s web shield protection.

Note: I believe Avastsvc.exe is designed to work hand in hand with Avast’s Network shield.

Standard NetBIOS uses three ports by default, 137, 138 and 139, SMB over TCP uses port 445. The NetBIOS datagram service (UDP over port 138) is used to send unicast messages to either individual PCs or to a group of PC’s. The fact that it seems to be sending to Microsoft, might suggest your router is not filtering outbound NetBIOS packets correctly.

I had major problems with NetBIOS on XP. So much so, I disabled it. On this WIN 7 box, NetBIOS seems to be much better behaved. Although I might go the route NIS 2011 uses. It basically blocks all inbound activity from ports 135 - 139 and 445 that is not local network based. That is the safest way to go.

[attachment deleted by admin]

#8

Actually, the proxy port for Avast is 12080, but AvastSvc.exe then uses dynamic ports to make the Internet connections. The connections seen in the image, were generated using the pre-defined web browser rule, so if you’re seeing IE connecting directly, something is wrong with your configuration.

If you only have a single PC, there’s no need to keep NetBIOS enabled, likewise SMB over TCP, although disabling that service is a little more complicated. As I said earlier, you need to prevent outbound NetBIOS in addition to inbound connections, but if your router is correctly configured, this should already be happening.

Edit: Setting the IE rule to Outgoing only or Trusted, is bizarre, it hides the actual process.

[attachment deleted by admin]

#9

Avast also doesn’t handle IPv6, so for all those people who have accidental 6to4/Teredo tunnels, without even knowing, are not being offered any protection for the webshield, if they do connect to an IPv6 enabled site.

[attachment deleted by admin]

#10

Your firewall log shows connections for Avastsvc.exe.

I enable firewall logging for the AvastSvc.exe application rule Comodo created. I also previously enabled logging on the Global Outbound Allow All rule. I am not receiving any firewall log entries for AvastSvc.exe?
However, active connections shows multiple connections for AvastSvc.exe.

This implies to me that AvastSvc.exe is bypassing the Comodo firewall and is running as a P2P connection?

[attachment deleted by admin]

#11

Radaghast, do you have your Loopback zone defined as a Trusted Network? I do not. My gut is telling me that is the culprit.

I set up my Comodo installation as “stealth my ports …” originally.

#12

Perhaps it’s something to do with the firewall configuration you’re using. I personally don’t use generic rules, as they are far to liberal and never seem to show exactly what’s happening. What I see in the firewall log is exactly what I see in Process Hacker, with the exception of only seeing one entry for IE to the Avast proxy port in the firewall log, whilst there are many in Process Hacker.

I also don’t use the Active Connections display in CIS as it’s not very accurate and at times, displays connections that are only known to CIS and not the system as a whole. At other times it doesn’t display connections the system knows about.

[attachment deleted by admin]

#13

It doesn’t make any difference if the loopback zone is available or not. Unless the zone is explicitly defined as part of a firewall rule, it’s not doing anything. In the case of Avast, the loopback zone has no importance, as Avast installs a TDI filter driver to intercept and redirect web traffic through the proxy.

#14

Attached is my TCPView output.

It appears that Avast is doing some type of NAT activity. The source port assigned by IE appears to be incremented by 1 by AvastSvc.exe when it sends out the packet. Now I have NAT turned on in my router so I am sure that the source port is being changed again. That alone is “double NATing” I assume.

[attachment deleted by admin]

#15

I watched my connections in TCPView and it appears some unknown “system process” is actually doing the TCP/IP connections. I suspect that this process is Avast’s non-plug and play network driver.

Appears the AvastSrv.exe is just doing front end activity for this network driver and that is why it is not being logged. This “system process” is showing the corresponding source ports that IE used so I am pretty sure this is the guy actually controlling network traffic.

Whatever the Avast network driver is it is not being recognized by the Comodo firewall.

#16

As you surmise, AvastSvc is making calls to an Avast driver that creates and maintains the connections. The entries you’re seeing for the ‘System Process’ with a PID of 0 (zero) - known by different names in different process viewers, such as ‘idle process’ and ‘system idle process’ - is a pseudo process that handles TCP connections after they’ve been closed by the application/process that initiated them, hence the connections are in the TIME_WAIT state.

Whatever the Avast network driver is it is not being recognized by the Comodo firewall.

You won’t see drivers in process viewers directly, only the process responsible for making the request. if you want to know what’s happening ‘behind the scenes’, use Process Explorer or Process Hacker and look at the details for the process (partial image below).

[attachment deleted by admin]

#17
  • is a pseudo process that handles TCP connections after they’ve been closed by the application/process that initiated them, hence the connections are in the TIME_WAIT state.

I know what your are referring to and I assure you it is not the case. What I am seeing are established active connections from that “system process” aka Avast’s Network shield driver I assume.

The real “initiation” process so to speak is IE. I have log entries for those that are for all purposes worthless. The desitination port is always 12080 and IP address is always 127.0.0.1. The log entries also don’t correspond to actual connections since my Comodo log might show four IE transactions whereas Comodo’s active connections for AvastSvc.exe number 50+ in some instances.

At this point, I stick with my contention that Avast’s web shield has created a P2P tunnel that is not being monitored by the Comodo firewall.

#18

I’m really not sure what you’re seeing. All the ‘System’ PID0 entries I see in TCPview related to the Avast connections are in a TIME_WAIT state, that means the connection is in the process of being closed and is waiting a defined period, if memory servers 120 seconds, of time, for any remaining fragments to arrive, before finally making the socket available for reuse.

If you’re seeing active connections from the PID0 System process, please post a screen shot.

#19

With regard to a “p2p tunnel” can you elaborate why you believe this is happening, as all I see is a standard local proxy connection.

#20

Replace “P2P” wording with VPN.

You might find this illuminating although the person is using Win 7 firewall. Explains the “leaking” alerts I got from Comodo when it was learning Avastsrv.exe.