Comodo spuriously creating svchost.exe FW rule for Allow IP Out / Any / Any / Any
Comodo Free FW 220.127.116.1198
I know that many people have posted both here and on other forums concerning Comodo’s FW behaviour in respect of svchosts.exe, in particular where Comodo creates a custom rule (when “Create rules for safe applications” is set) for outbound activity for svchost.exe
I’ve seen this creation of a custom rule a number of times. Sometimes I’ve turned on logging to see what the activity is all about and I see that svchost is highly active (typically several entries per minute). Not knowing what was really going on, in the past I have overcome the issue by restoring a previous system partition image (I make them frequently) and gone forward from there without the situation re-occuring (except maybe several months down the line, so I just do an image restore again).
However, I came across a situation just last week where restoring an image was less than an ideal solution (basically I was upgrading from Win 10 1909 to 20H2, using Windows Update Assistant and immediately upon completion of the upgrade the svchost issue cropped up).
This is what happened:-
• Upgraded from Win10 1909 to 20H2 using Windows Update Assistant • Soon after update, noticed that a new discrete application entry for svchost.exe is added in to the Application Rules list in Comodo. The custom rule associated with this entry was Allow IP Out From MAC Any To MAC Any Where Protocol Is Any. Subsequent testing showed this occurring during the final reboot phases of the upgrade. • Being inquisitive I enabled logging for this entry and saw a whole swathe of events. The bulk of these were UDP (various ports) to my router's LAN IP. A smaller number were TCP to external IPs. • A simple restore of the previous image, whilst possible, was less practical due to the intervening 1909 to 20H2 upgrade. So I started to look around for possible causes and potential solutions. The only one of these that I tried suggested that it might be Windows time sync related, so I disabled automatic time setting and this seemed to address the issue. However on subsequent attempts I could not recreate this 'solution'. • I thought about the whole situation overnight and came up with a number of things to try. The first of these was to create the equivalent application rule on another similarly configured PC (that was already on 20H2) and see what happened. Interestingly I could not create a new discrete rule for svchost (Comodo would not allow this), so I added Allow IP Out From MAC Any To MAC Any Where Protocol Is Any to the existing svchost entry. Low and behold Comodo immediately started logging a similar swathe of events. • So back on the original 'problem' PC I deleted the 'new' Application entry that had been created at the end of the upgrade, half expecting that it would be automatically recreated. But NO, it wasn't (and once again I could not manually create an equivalent discrete Application entry, only add Allow IP Out From MAC Any To MAC Any Where Protocol Is Any to the existing entry). But does Comodo not recreating the rule automatically shed some light?
So my current thoughts are along these lines:
• Comodo usually treats svchost.exe as a Windows System Application (or such like). So, by default Allow IP Out From MAC Any To MAC Any Where Protocol Is Any is permitted. • For some reason (e.g. timing issue at boot time) the Windows System Application rule does not get fired, so Comodo, due to “ Create rules for safe applications” being set, creates a rule for svchost.exe. But creates a discrete Application entry for the rule (rather than adding to the existing svchost.exe entry) – again, could this extra entry be due to a timing issue? • So, on that basis, the swathes of events were likely occurring all along (by that I mean, weeks, months, years), but just not being logged.