System Process (Again)

I updated Avast to the latest version around midnight. As soon as my WinXP SP2 computer rebooted, Comodo pop-up a warning regarding the “System” process. I thought I was done with the “System” process causing hell in my life. Past experience with allowing “System”, which Comodo continues to recommend as safe (trusted), is IMO dangerous. I selected “Block Application”, ticked ‘Remember’ and clicked “Okay”. I could have sworn that “Application Rules” already had a “System” process entry.

After creating a “Block Application” rule for the “System” process, the log started to fill up with blocked “System” local requests. Before the Avast update the log only showed blocked remote requests.

After doing some searching on the matter, someone in the Comodo forum suggested to someone else that the “System” process should be outgoing only. So, I deleted the rule, waited 15 seconds and when Comodo popped up the “System” warning again, I changed the rule. Here is the new and current “Application Rules” for “System”:


System
   |- Allow All Outgoing Requests
   `- Block and Log All Unmatched Requests

The computer is wired to a router and in the “Global Rules” I have created rules to allow this computer to see the router’s IP, as well as the other computers on the LAN. Here are all of the “Global Rules”. The first 4 are the ones I created, the remaining are the defaults:

Allow All Outgoing Requests If The Target Is IP In [192.168.1.1 - 192.168.1.1]
Allow All Incoming Requests If The Sender Is IP In [192.168.1.1 - 192.168.1.1]
Allow All Outgoing Requests If The Target Is IP In [192.168.1.101 - 192.168.1.105]
Allow All Incoming Requests If The Sender Is IP In [192.168.1.101 - 192.168.1.105]

Allow All Outgoing Requests If The Target Is In [Home Network]
Allow All Incoming Requests If The Sender Is In [Home Network]
Block ICMP Out From MAC Any To MAC Any Where ICMP Message Is PROTOCOL UNREACHABLE
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 17.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 15.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 13.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is ECHO REQUEST

Here is a sample of the first 10 entries in the log when the problem began:

Date Created: 2012-04-26 02:02:44
Records count: 134

Date                 Application  Action   Direction  Protocol  Source IP     Source Port  Destination IP  Destination Port
2012-04-26 00:02:42  System       Asked    In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 00:03:49  System       Blocked  In         UDP       192.168.1.1    138         192.168.1.101   138 
2012-04-26 00:04:30  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 00:04:40  System       Blocked  Out        UDP       192.168.1.101  138         192.168.1.255   138 
2012-04-26 00:04:54  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 00:04:56  System       Blocked  Out        UDP       192.168.1.101  137         192.168.1.255   137 
2012-04-26 00:04:59  System       Blocked  Out        UDP       192.168.1.101  138         192.168.1.255   138 
2012-04-26 00:05:03  System       Blocked  Out        UDP       192.168.1.101  138         192.168.1.255   138 
2012-04-26 00:05:07  System       Blocked  Out        UDP       192.168.1.101  138         192.168.1.255   138 
2012-04-26 00:05:43  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137

The log goes on and on like that until I changed the “System” rule to “Allow All Outgoing Requests” only. This change obviously slowed down the amount of entries filling the log. Here are the last 10 log entries (relevant to composing this post):

Date Created: 2012-04-26 02:40:45
Records count: 168

Date                 Application  Action   Direction  Protocol  Source IP     Source Port  Destination IP  Destination Port
2012-04-26 02:29:26  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 02:31:28  System       Blocked  In         UDP       192.168.1.1    138         192.168.1.101   138 
2012-04-26 02:31:32  System       Blocked  In         UDP       192.168.1.1    138         192.168.1.101   138 
2012-04-26 02:31:36  System       Blocked  In         UDP       192.168.1.1    138         192.168.1.101   138 
2012-04-26 02:33:24  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 02:34:10  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 02:34:59  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 02:35:56  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 02:36:26  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137 
2012-04-26 02:36:56  System       Blocked  In         UDP       192.168.1.1   1025         192.168.1.101   137

Both Avast (including it’s definitions) and Comodo are on their latest versions. Avast reports no virus. I’ve since rebooted the computer several times with no change, the log continues to fill up with blocked local “System” requests.

I would appreciate it if someone could please explain what’s happening. Why is the computer now generating these local requests after the Avast update and why isn’t Comodo not using the “Global Rules” as it did before?

The log for April 25 had 2,251 entries and for April 26 it had 3,032 entries, all pertaining to the issue described above. That’s a total of 5,283 entries, or an average of 2,641.5 entries per day. And, it’s continuing to grow!

Are we dealing with a bug in “Global Rules” or is something else going on?

Please help.

What you’re seeing is relatively normal behaviour for the System process. To help understand this, it helps to know what this process does. One its responsibilities is servicing file and printer sharing requests for Microsoft based PCs. To do this, it primarily use the NetBIOS protocol, which uses TCP and UDP over ports 137, 138 and 139. Unfortunately, as you’re finding out, two of these services - NetBIOS Name Service (UDP port 137) and NetBIOS Datagram Service (UDP port 138) - can be quite noisy.

To cater for this process you have to decide if you need the services it supports. If the answer to that is no, then the easiest thing to do, is disable the service in the properties of the Network adapter. If the answer is yes, then you’ll have to create some basic rules.

For the most part, the rules you create will allow the service to send and receive requests, to and from the LAN and will block all other NetBIOS traffic. Looking at your post, you appear to be on a LAN and you appear to have some of the rules necessary to support the process in place. Take a look at the images below and take a read through this thread.

The images have been simplified to show the important details, however, the main points are:

  1. Create a port set for the NetBIOS/SMB ports
  2. Make sure you have a Network Zone with your LAN IP address range (you seem to have this)
  3. Run Stealth Ports Wizard with the first and third options (or create the rules manually)
  4. Add a Block rule to the System process using the Port Set created earlier.

[attachment deleted by admin]

Sorry for the long delay. I read the thread you posted and made some changes. However, it’s worse now as the Windows XP computer can’t even see itself or the Workgroup without returning an error.

[Workgroup Name] is not accessible. You might not have permission to use this network
resource. Contact the administrator of this server to find out if you have access permission.

The list of servers for this workgroup is currently not available.

This was so aggravating that I had to get away from it for awhile. It’s particularly aggravating that everything work fine until Avast was updated and I rebooted the computer.

I don’t understand why something called “Global Rules”, aren’t global rules. This is so frustrating and doesn’t seem very intuitive. I set Comodo up to allow In/Out of TCP or UDP for those specific IP addresses mentioned before. Once in “Global Rules” and later when that didn’t work, under “System” in “Application Rules”.

These rules in Comodo need to be air tight, otherwise if I connect with a VPN and lose the protection of the router, it falls upon Comodo as the last line of defense from the “System” nasties getting into the computer. Which I’ve already been bitten by once before when System wasn’t configured correctly.

Which brings me back to Avast and how Comodo worked fine before the Avast update. Something about the latest version of Avast changed the way the latest version of Comodo works.

Can I just copy the Comodo configuration from one of the Windows 7 Laptops and use those settings on the Windows XP desktop?

The Windows 7 laptops don’t have a problem seeing each other and use 1/10 of the amount of setting in Comodo to work correctly.

Thank you very much for your reply.

Which version of Avast were you running prior to the update?

I don't understand why something called "Global Rules", aren't global rules. This is so frustrating and doesn't seem very intuitive. I set Comodo up to allow In/Out of TCP or UDP for those specific IP addresses mentioned before. Once in "Global Rules" and later when that didn't work, under "System" in "Application Rules".

Global rules are just that, in the sense that you create a rule that opens or closes a port for a specific protocol and in so doing affect all applications running on the system. Application rules are specific to each application. To use CIS effectively, a combination of Global and Application rules is good practice.

These rules in Comodo need to be air tight, otherwise if I connect with a VPN and lose the protection of the router, it falls upon Comodo as the last line of defense from the "System" nasties getting into the computer. Which I've already been bitten by once before when System wasn't configured correctly.

Providing you block NetBIOS/SMB from connecting to and receiving from the Internet, you should be ok. If your router is configured correctly, it should be doing this already.

Which brings me back to Avast and how Comodo worked fine before the Avast update. Something about the latest version of Avast changed the way the latest version of Comodo works.

The only issue, I’m aware of with Avast, is the one discussed here.

Can I just copy the Comodo configuration from one of the Windows 7 Laptops and use those settings on the Windows XP desktop?

It depends on the rules you’ve configured for the Windows 7 PC?

The Windows 7 laptops don't have a problem seeing each other and use 1/10 of the amount of setting in Comodo to work correctly.

Thank you very much for your reply.

Are you using Windows 7 Homegroups?

It may be a good idea if you could post screenshots of your Application and Global rules.

Currently using v7.0.1426 of Avast. According to the Avast history page which is located here, the previous version should have been v7.0.1407. However, I do not believe Avast is listing intermediate versions on that page, so the previous version I had installed might have been higher.

When Avast v7 was first released, I remember waiting to update from the last v6 I had installed to the new v7 because of an update issue people were having migrating. Once that issue was sorted out and Avast released a new v7 minor, I then updated. Then updated again, that’s when the previous Comodo System rules stopped working.

So, I believe the previous v7 I had installed was higher than v7.0.1407, according to the Avast history page the first v7 major release. Unfortunately, I can’t be certain of the prior installed version, but based on the Avast history page it had to be some version higher then the initial v7.0.1407 and lower than the current v7.0.1426.

That’s where it gets confusing. I think of “Global Rules” in the traditional sense – that these rules have the highest priority and govern everything, including all applications. So, when I create global rules to allow all traffic in/out on a IP range of 192.168.1.1 to 192.168.1.1 and a separate additional rule doing the same but with a range of 192.168.1.101 to 198.168.1.105, I wouldn’t expect Comodo to ignore them.

It would seem to me that global rules that allow in/out in those specific IP ranges, which are allowing anything and anything and anything, would be specific enough for Comodo to allow all access to the LAN. And, if not all access of the LAN, at the very least give the Comodo hosted computer the ability to see itself. It doesn’t. With these global rules listed with the highest priority at the top of the sorter, they appear to do nothing. I’ve logged them, they never get touched.

In my withered state of mind, I wouldn’t think that all LAN traffic from all applications, or even the host the ability to see itself, would fall to “Applications Rules”, but instead be something global. Or, at the very least start with “Global Rules” to allow all traffic and then further tailor the access of individual applications in “Applications Rules”.

The issue isn’t so much about when using a normal Internet connection through the router. The issue is when there is an encrypted VPN Internet connection. A VPN is a direct connection and tunnels right through the connected router, bypassing all the security of the hardware firewall. That’s why it’s acutely important that Comodo has “System” setup correctly on the VPN connected computer. Since using a VPN is like having the computer connected directly to the MODEM, Comodo at that point becomes the only line of defense.

I didn’t understand this a couple of years ago when I connected with the VPN and the LAN shared directories were attacked. Later, I realized that as soon as I connect to the host Concentrator, all hardware benefits of the router are gone.

As I’ve said in the past, Comodo shouldn’t use a blanket statement to the end user in the pop-up that the “System” process is “Safe”. “Safe” is misleading and could be potentially dangerous. “System” needs to be locked down, not treated as “Safe” and granted all access.

Here are all of the Windows 7 “Global Rules”:


Allow All Outgoing Requests If The Target Is In [Home Network]
Allow All Incoming Requests If The Sender Is In [Home Network]
Allow IP Out From IP Any To IP Any Where Protocol Is Any
Allow ICMP In From IP Any To IP Any Where ICMP Message Is FRAGMENTATION NEEDED
Allow ICMP In From IP Any To IP Any Where ICMP Message Is TIME EXCEEDED
Block IP In From IP Any To IP Any Where Protocol Any

Here are all of the Windows 7 “Application Rules” as it pertains to “System”:


Allow System To Send Requests If The Target Is In [Home Network]
Allow System To Receive Requests If The Sender Is  In [Home Network]
Block and Log All Unmatching Requests

Here are all of the current Windows XP “Global Rules”:


Allow All Outgoing Requests If The Target Is In [Home Network]
Allow All Incoming Requests If The Sender Is In [Home Network]
Block ICMP Out From MAC Any To MAC Any Where ICMP Message Is PROTOCOL UNREACHABLE
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 17.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 15.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 13.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is ECHO REQUEST

Here are all of the current Windows XP “Application Rules” as it pertains to “System”:


Allow System To Send Requests If The Target Is In [Home Network]
Allow System To Receive Requests If The Sender Is  In [Home Network]
Block and Log All Unmatching Requests

With not much to lose, I went ahead and copied the Windows 7 “System” rule to the Windows XP “System” rule and not only do I once again have access to the LAN, the host computer can see itself.

Because I don’t understand “System” and Comodo well enough to make my own determination, I’m not sure whether the Windows 7 “System” rules are safe enough to be used by themselves on a Windows XP desktop that’s connected through a VPN. Seems to me that this direct connection needs more than “Home Network” to lock down “System” safely. Is this true?

Nope, I use Workgroups for all connected devices, for me it’s easier and no compatibility issues.

See above.

Thanks for your continued support, it is very much appreciated.


P.S. #1 There are only 13 visible lines in the compose window for the forum editor. Most forums allow the user to adjust the size of the editor window to make it easier. Is everyone forced to use such a tiny restrictive editor window when they post?

P.S. #2 The insert URL button isn’t very good with this editor. It just dumps the URL BBcode tags. I currently don’t see an option to change editors, is it possible to change to a different editor once my post count goes beyond a certain point?

If you were already running version 7, prior to your problems, I don’t think Avast is the problem.

That's where it gets confusing. I think of "Global Rules" in the traditional sense -- that these rules have the highest priority and govern everything, including all applications.

They do govern all applications, but they can also be overridden by a specific application rule. that’s their beauty.

So, when I create global rules to allow all traffic in/out on a IP range of 192.168.1.1 to 192.168.1.1 and a separate additional rule doing the same but with a range of 192.168.1.101 to 198.168.1.105, I wouldn't expect Comodo to ignore them.

Unless an application rule existed that prevented that application from accessing those IP address blocks, they should have worked. Conversely, an application must also have a rule that allows it to access those ranges.

It would seem to me that global rules that allow in/out in those specific IP ranges, which are allowing anything and anything and anything, would be specific enough for Comodo to allow all access to the LAN And, if not all access of the LAN, at the very least give the Comodo hosted computer the ability to see itself. It doesn't. With these global rules listed with the highest priority at the top of the sorter, they appear to do nothing. I've logged them, they never get touched.

A Global rule in isolation, will not have any effect on the system overall. If you need to provide access to a resource, you must have an application rule, for whichever application needs the access. Depending on other settings, you may or may not need a Global rule.

In my withered state of mind, I wouldn't think that all LAN traffic from all applications, or even the host the ability to see itself, would fall to "Applications Rules", but instead be something global. Or, at the very least start with "Global Rules" to allow all traffic and then further tailor the access of individual applications in "Applications Rules".

That’s pretty much how things work.

The issue isn't so much about when using a normal Internet connection through the router. The issue is when there is an encrypted VPN Internet connection. A VPN is a direct connection and tunnels right through the connected router, bypassing all the security of the hardware firewall. That's why it's acutely important that Comodo has "System" setup correctly on the VPN connected computer. Since using a VPN is like having the computer connected directly to the MODEM, Comodo at that point becomes the [u]only[/u] line of defense.

In this case you would provide the rules necessary to access the LAN address block and block access to the VPN address block. Again, Application rules would control this for a specific application and you may or may not need corresponding Global rules.

I didn't understand this a couple of years ago when I connected with the VPN and the LAN shared directories were attacked. Later, I realized that as soon as I connect to the host Concentrator, all hardware benefits of the router are gone.

If your router firmware supports it, create the endpoint for the VPN on the router.

As I've said in the past, Comodo shouldn't use a blanket statement to the end user in the pop-up that the "System" process is "Safe". "Safe" is misleading and could be potentially dangerous. "System" needs to be locked down, not treated as "Safe" and granted all access.

I agree.

Here are all of the Windows 7 "Global Rules":

Allow All Outgoing Requests If The Target Is In [Home Network]
Allow All Incoming Requests If The Sender Is In [Home Network]
Allow IP Out From IP Any To IP Any Where Protocol Is Any
Allow ICMP In From IP Any To IP Any Where ICMP Message Is FRAGMENTATION NEEDED
Allow ICMP In From IP Any To IP Any Where ICMP Message Is TIME EXCEEDED
Block IP In From IP Any To IP Any Where Protocol Any

Here are all of the Windows 7 “Application Rules” as it pertains to “System”:


Allow System To Send Requests If The Target Is In [Home Network]
Allow System To Receive Requests If The Sender Is  In [Home Network]
Block and Log All Unmatching Requests

Here are all of the current Windows XP “Global Rules”:


Allow All Outgoing Requests If The Target Is In [Home Network]
Allow All Incoming Requests If The Sender Is In [Home Network]
Block ICMP Out From MAC Any To MAC Any Where ICMP Message Is PROTOCOL UNREACHABLE
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 17.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 15.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is 13.0
Block ICMP In From MAC Any To MAC Any Where ICMP Message Is ECHO REQUEST

Here are all of the current Windows XP “Application Rules” as it pertains to “System”:


Allow System To Send Requests If The Target Is In [Home Network]
Allow System To Receive Requests If The Sender Is  In [Home Network]
Block and Log All Unmatching Requests

With not much to lose, I went ahead and copied the Windows 7 “System” rule to the Windows XP “System” rule and not only do I once again have access to the LAN, the host computer can see itself.

The only difference seems to be down to either the type of installation used for CIS or the use of Stealth Ports Wizard. Other than that the rules are fundamentally the same. There’s certainly nothing in the Windows 7 rules listed, that would have prevented XP from accessing the LAN. I assume the IP address blocks used for ‘Home Network’ are the same?

Because I don't understand "System" and Comodo well enough to make my own determination, I'm not sure whether the Windows 7 "System" rules are [b]safe enough[/b] to be used by themselves on a Windows XP desktop that's connected through a [b]VPN[/b]. Seems to me that this direct connection needs more than "Home Network" to lock down "System" safely. Is this true?

There’s really no difference in the rules listed above. For File and printer sharing on a LAN the ‘System’ process needs to be able to send and receive TCP and UDP over ports 137, 138. 139 and 445. Using the Stealth Ports wizard with the first option:

Define a new trusted network and make my ports stealth for everyone else

Will create the necessary rules to support this functionality and also provide access for other services such as network discovery, SSDP/UPnP etc. If you want to block access to the System process beyond the LAN address block, simply allow the rules create via the aforementioned process and add a block rule for anything else.

As far as Global rules are concerned, if you have installed the full CIS suite, including the AV or you’ve run Stealth Ports Wizard with the third option:

Block all incoming connections and make my ports stealth for everyone

You’ll need to make sure there are Global rules to allow LAN access - these will also be created for you when using option one above. The reason for this is because when installing the full suite or using option three above, a Global rule is created that blocks all inbound connections, apart from those specifically allowed through rules above it.

****

P.S. #1 There are only 13 visible lines in the compose window for the forum editor. Most forums allow the user to adjust the size of the editor window to make it easier. Is everyone forced to use such a tiny restrictive editor window when they post?

P.S. #2 The insert URL button isn’t very good with this editor. It just dumps the URL BBcode tags. I currently don’t see an option to change editors, is it possible to change to a different editor once my post count goes beyond a certain point?

The forum software could be better…