How to treat System and Svchost?

Hi, I’ve been referring others to use CIS for a while now and they keep asking me about how to treat System and Svchost. I have always just allowed it because if not then the computer would not have internet access. I know this is probably the wrong way to treat these processes.
Hopefully its safe to post these IPs.

How should I treat these?
and is there a safer rule I can create for them?

Application: System
Remote: 224.0.0.22 - IGMP
Port:

Application: System
Remote: 169.254.255.255 - UDP
Port: nbname (137)

Application: svchost.exe
Remote: 224.0.0.252 - UDP
Port: 5355

and when I open a prompt to upload a file I get:
(i.e. uploading screen shots on here)

Application: System
Remote: 127.0.0.1 - TCP
Port MS-ds (445)

Thank you.

Info:
OS: Win 7 x64
CIS 4.1.150349.920

[attachment deleted by admin]

I have those two at Outgoing only and it’s working fine.

xNOTTA You can read here:

https://forums.comodo.com/firewall-help-cis/all-about-svchostexe-t58549.0.html

:-TU Alright, going to set mine to “Outgoing Only”.
Thanks for the quick reply. :smiley:

:-La Nice chunk of info…but i know what it is…just didn’t know which rule to apply to it for best security.

The only rule I have for ‘System’ is:

allow UDP in from in [modem] to in [NIC] src port 137 destination port 137 ask and log IP in/out from IP any to IP any src port any dest port any

I never get bothered by traffic to or from ‘System’.

IGMP is used by IP hosts and adjacent multicast routers to establish multicast group memberships. It is an integral part of the IP multicast specification, although it does not actually act as a transport protocol; it is analogous to ICMP for unicast connections; read on for how I address fundamental security vulnerability concerning ICMP.

IGMP can be used for online streaming video and gaming, and allows more efficient use of resources when supporting these types of applications. IGMP is vulnerable to some attacks, and firewalls commonly allow the user to disable it if not needed.

I have never seen an alert concerning ‘System’ w/respect to IGMP. If this is something that you’re ‘subscribed’ to, I’d suggest ascertaining the IP source and create a rule explicitely to / from that source if that’s appropriate. That notwithstanding, the last rule should catch it and allow you to allow or deny as you deem fit.

You should keep in mind that Comodo is ‘statefull’, i.e., you only have to establish rules for outbound connections (all unsolicited inbound traffic is blocked w/out logging of any kind).

========================

UDP traffic to ‘System’ on port 137 concerns NETBIOS Name Service. A principle reqmt for NetBIOS services on MS hosts (Win9x/ME/NT/Win2000). UDP 137 is used for browsing, logon sequence, pass-thru validations, printing support, trust support, WinNT Secure Channel, and WINS registration. This is a key target in auth & DOS attacks. It should be blocked at all perimeters; NIC-filter on public-exposed MS hosts. ‘NetBIOS over TCP’ should be disabled on each host in TCP/IP config. It should only be allowed in from ‘gateway’ devices which can not be suppressed for such traffic.

Traffic on port 445 is bound by default to \Device, i.e., all devices. The SMB (Server Message Block) protocol is used among other things for file sharing in Windows NT/2000/XP. You definitely should disable ‘simple file sharing’; it is evil. In Windows NT it ran on top of NetBT (NetBIOS over TCP/IP), which used the famous ports 137, 138 (UDP) and 139 (TCP). In Windows 2000/XP, Microsoft added the possibility to run SMB directly over TCP/IP, without the extra layer of NetBT. For this they use TCP port 445.

Use the following registry key to unbind port 445 and allow for binding Alfresco:

[ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters ]

  • In the right-hand side of the window find an option called TransportBindName
  • Double click that value, and then delete the default value, thus giving it a blank value.
  • Close the registry editor
  • Reboot the computer
  • open a command prompt and type: netstat -an (ensure there is no process listening on TCP port 445)

UDP traffic inbound - via aforementioned ports - can result in ICMP outbound. To deal with ICMP, I’ve set up the following global rules in their entirety, i.e., all inclusive (that not listed does NOT exist):

allow ICMP in from in [modem] to in [NIC] where ICMP message is ECHO REQUEST
allow ICMP in from IP any to in [NIC] where ICMP message is FRAG NEEDED
block ICMP in from not in [modem] to IP any where ICMP message is any
allow ICMP out from in [NIC] to in [modem] where ICMP message is PORT UNREACHABLE
allow ICMP out from in [NIC] to in [modem] where ICMP message is ECHO REPLY
allow ICMP out from in [NIC] to in [modem] where ICMP message is FRAG NEEDED
block and log ICMP out from IP any to IP any where ICMP message is any

This effectively stealths one’s system from ICMP probes, and any spurious outbound ICMP type 3 in the log can be decisively dealt with Johnny-on-the-spot; they are evil. With the Comodo config I’m running I never see ICMP type 3 code 3 out in the log. In fact my logs are so boring they wouldn’t be exciting even to a newborn baby. They’d just point out the obvious facts apparent, i.e., new IPs that should be incorporated into existing zones, IPs in the port 443 IP zone that are shared (80 / 443), new port 443 IPs, new port 80 IPs, etc., etc., etc. and on and on and on and on; its all a bunch of boring ■■■■.

My last firewall event was from 1 Jul 10, and the one prior to that was 25 Jun 10. To address those issue - not fix - I had to do some zone housekeeping. My last Defense+ log entry was 22 Jun 10 and pertained to updating BOINC.

Comodo pawns ALL other secutiry products. Hands down, no qwexion, if somebody gets infiltrated, compromized, zombied, virused, et ali., the user allowed it. The only product that has a leg up on Comodo is FWBUILDER. If you’re spending money on AV product that isn’t going into Avira’s coffers: you’re wasting your $'s; Comodo AV is good enough to back-stop - last line of defense - its excellent IDS / IPS.

When used in conjunction with other free products, e.g., Ad-Aware and Windows Defender (for real-tiem protection), MVPS host file with SpyBot as adjunct (for browser restricted zone entries). If with all that in place and you get compromised, then you are an Iranian nuclear scientist with ‘stuff’ on your PC.

SVCHost is a Windows service that runs WIndows services. In and of itself it should be considered ‘safe’ except when your system has been hijacked or compromised. So in general any internet connections SVCHost makes should be good to go. But to just ALLOW ALL for SVCHOST is a big gaping security hole that one can fly an aircraft carrier through. So how to tell if SVCHost is legit? For that purpose I created a file called ‘Process_Tool.cmd’ with the following lines:

Tasklist /FI “IMAGENAME eq svchost.exe” /svc
pause

Then I created a shortcut on my desktop that points to it. When I click on it, it displays all SVCHOST processes and what services are associated with it. As long as the display is akin to the following:

Image Name PID Services

svchost.exe 672 DcomLaunch
svchost.exe 724 RpcSs

svchost.exe 792 AudioSrv, CryptSvc, EventSystem, lanmanworkstation, Netman, Nla, RasMan, Schedule, SENS, ShellHWDetection, Themes, winmgmt, wuauserv

svchost.exe 916 Dhcp, Dnscache
svchost.exe 1200 Wecsvc
svchost.exe 1476 TermService
svchost.exe 840 TapiSrv

Its all good, and the requested connection can be allowed. Then its a simple matter of looking in the firewall log and establishing which zone the IP address should be placed into. If however, there’s an SVCHost w/out an associated service, or if there’s an unknown service associated w/an instance of SVCHost, that’s a big clue the system has been zombified.

The first thing I did to deal with SVCHost was to set up a file group called ‘DNS’. In it I put all files that are known to need interweb connection, and therefor would require DNS lookup service, i.e., UDP out to the DNS zone on port 53. In the DNS file-group I placed:

%windir%\system32\svchost.exe
%windir%\system32\wuauclt.exe
%windir%\system32\wupdmgr.exe
E:\BOINC\boinc.exe
C:\Program Files\Internet Explorer\iexplore.exe
C:\Program Files\Ad-Aware\AAWService.exe
C:\Program Files\Ad-Aware\Ad-AwareAdmin.exe
C:\Program Files\Windows Defender\MSASCui.exe
C:\Program Files\Java\jre6\bin\javaw.exe
C:\Program Files\Common Files\Java\Java Update\jaucheck.exe
C:\Program Files\Common Files\Java\Java Update\jucheck.exe
C:\Program Files\Common Files\Java\Java Update\jusched.exe
C:\Program Files\Java\jre6\bin\java.exe
E:\Visual Studio\Common7\IDE\devenv.exe
C:\WINDOWS\system32\Macromed\Flash\FlashUtil10e.exe
C:\Program Files\Common Files\Adobe\ARM\1.0\AdobeARM.exe
C:\Program Files\Common Files\Adobe\ARM\1.0\AcrobatUpdater.exe
C:\Program Files\Download Guard for Internet Explorer\DownloadGuard.exe
C:\WINDOWS\PCHealth\HelpCtr\Binaries\HelpCtr.exe
E:\VLC\vlc.exe
E:\Open Office\OpenOffice.org 3\program\soffice.bin
E:\FTP_Voyager\FTPVoyager.exe
C:\Program Files\Common Files\Microsoft Shared\DW\DW20.EXE
E:\Spybot\SDUpdate.exe
%windir%\system32\msiexec.exe
%windir%\SoftwareDistribution*
C:\Program Files\COMODO\COMODO\COMODO Internet Security\cfpconfg.exe

Then I create a firewall rule allowing file-group DNS:

UDP out from in [NIC] to in [DNS] where src port is any dest port 53

Note: [DNS] is a zone defined with the DNS servers. Moreover, NO OTHER APP SHOULD BE ASKIN’ for UDP out to port 53. If so, then it gets put into the DNS file-froup. THe DNS file-grup rule-set should come before any other app’s ruleset and no app is explicitely given UDP out permission (except for its existance in the DNS file-set).

Then I set up a rule for SVCHost with the following rules:

Allow TCP out from in [NIC] to [AAWservice - ???] where src port is any dest port 80
Allow TCP out from in [NIC] to [AAW - Sweden] where src port is any dest port 80
Allow TCP out from in [NIC] to [AAW - cachely.net] where src port is any dest port 80
Allow TCP out from in [NIC] to [AAW - lavasoft.com] where src port is any dest port 80
Allow TCP out from in [NIC] to [AAW - lnw.net] where src port is any dest port 80
Allow TCP out from in [NIC] to [AAW - xo.net] where src port is any dest port 80
Allow TCP out from in [NIC] to [AAW - msecn.net] where src port is any dest port 80
Allow TCP out from in [NIC] to [SVChost - lnw.net] where src port is any dest port 80
Allow TCP out from in [NIC] to [SVChost - AkamaiTech] where src port is any dest port 80
Allow TCP out from in [NIC] to [PCCWGlobal.net] where src port is any dest port 80
Allow TCP out from in [NIC] to [bosch] where src port is any dest port 80
Allow TCP out from in [NIC] to [msecn.net - 80] where src port is any dest port 80
Allow TCP out from in [NIC] to [MS Update] where src port is any dest port 80
Allow TCP out from in [NIC] to [SVCHost] where src port is any dest port 80
Allow TCP out from in [NIC] to [SVCHost - USA] where src port is any dest port 80
Allow TCP out from in [NIC] to [SVChost - France] where src port is any dest port 80
Allow TCP out from in [NIC] to [SVCHost - 80/443] where src port is any dest port-set 80/443
Allow TCP out from in [NIC] to [Akamai - ARM - 80/443] where src port is any dest port-set 80/443
Allow TCP out from in [NIC] to [msecn - 80/443] where src port is any dest port-set 80/443
Allow TCP out from in [NIC] to [SVCHost - 443] where src port is any dest port 443
Allow TCP out from in [NIC] to [SVCHost AkamaiTech - 443] where src port is any dest port 443
Allow TCP out from in [NIC] to [Akamai - ARM - 443] where src port is any dest port 443
Allow TCP out from in [NIC] to [Adobe - ARM - 443] where src port is any dest port 443
Ask/log IP in/out IP any to IP any where src port is any dest port any

To establish the domain name of the IP address that outgoing connection attempt is made, I ‘googled’ a web-site using the search term: ‘reverse DNS’ and have that bookmarked. Well, actually, its one of my favorties in my IE8 favorite bar. IF its an SVCHost where the domain name can not be resolved, and SVCHost appears un-hijacked (per aforementioned shortcut), then the address is assumed to be Win Update in some form. If it is Adobe or Ad-Aware phoning home for update, SVCHost won’t be the app making the connection (since the zone is already allowed for SVCHost). What will happen in that case is the app itself, e.g., Adobe, Ad-Aware, etc. will attempt the connnection. Then after allowing that, SvcHost MAY chime in and wants access there too. However, since SVCHost now has perimssion to the zones already defined for the respective apps already, it won’t ever do that.

The only maintenance that needs to be done with successive IP access attempts is establish if the IP already exists in some zone, e.g., is a formerly secure IP connection, i.e., on port 443, now being accessed on port 80? Easy enough to pull it out of the 443 exclusive zone and put it into the 80/443 shared zone. No further changes to the existing rule-set for SVCHost are necessary. The underlying premise is that unknown domain name IP’s attributed to SVCHost will be pertainent to Win updates in some form.

It should be pointed out that each app, e.g., Ad-Aware, Adobe, etc., have their own exclusive zone. SVCHost is granted permission to access those zone exlicitely when the IP address that SVCHost is attempting to connect to ALREADY EXIST IN AN APP ZONE.

SVChost hardly bothers me about anything. Its quite a bit of homework getting that set-up initially (obviously), but once you do, SVCHost won’t bother you hardly at all, and whatever it wants you’ll know the request is legit, and above all else: you’ll be able to classify for what putative purpose the connection attempt was made for. Clearly the easiest alternative for SVCHost is: Allow IP any from IP any to IP any src port Any dest port ANY. But ThAT just gives me the heebie-jeebies. IF that sounds good to you, you don’t need Comodo; Zone Alarm is probably more than what you really need (if anything). If that’s good enough for you, then you’re pretty confident that systems can’t be hijacked, malware doesn’t masquerade under a legit name, trojan horses don’t exist and so forth. Basically you live in a world of pink flying-unicorns that shoot skittles out their ■■■■ over spectacular rainbows and everybody eats peaches and cream all day long.

Hi again, Hopefully it’s alright that I reply to this older post.
I went though my logs and made up rules for system and svchost.

(Image attached)
Green = My router IP range.
Red = My MAC address.

They appear to be working flawlessly and I haven’t been prompted to allow/block by either of them.

I don’t want either process accessing anything more than giving me internet. (i.e. no win update, etc.)

Do these seem safe? what should I add or remove?

Also, thanks to everyone who replied. :]

[attachment deleted by admin]