Is there a firewall that handles svchost properly?

Hi all,

I'm looking for a firewall that handles svchost properly, i.e. lets me at all the "hosted" bits individually. I know I've seen reference to this here before, but I guess I'm not phrasing my search criteria very well: I just keep getting millions of links to messages in which people are wondering what this svchost thing is.

I think Outpost (non-free?) was mentioned as having this capability. Or was it LnS? I'm currently using Kerio 2.1.5 and don't like the way it handles svchost.

What I'm really looking for is a decent, very comprehensive application firewall, as I'm using a Linksys router with a good stateful packet filter built in. But I don't think such an application exists yet - aside from that one which uses an online database and requires you to upload suspect files for their inspection (can't remember its name).

Thanks for any input!

 

Outpost v. 2.7 (paid) is a very capable firewall which handles svchost.exe very well if configured properly. Paranoid 2000, who often posts on this forum, has produced a guide to producing a secure configuration for Outpost. That guide contains an extensive discussion on how to set Outpost for svchost.exe. If you don't like Outpost or can't use it, you can probably adapt the rules suggested in Paranoid 2000's guide for another highly configurable firewall.

Here's a link to the guide:

http://www.outpostfirewall.com/forum/showthread.php?t=9858

 

What issues or concerns do you have with Kerio and it's handling of svchost?

Regards,

CrazyM

 

Thanks profhsg, I'll take a look at that guide. Sounds promising!

Don't get me wrong, CrazyM: I love the old Kerio. And so far it's working well as an application firewall. But svchost is just one big lump in Kerio 2.1.5. So many things go through it that its rules need to be far more lenient than they should be. I want control of the DLLs that use svchost individually, if that's possible.

Thanks for your input, guys!

 

It sounds like you're after a firewall which also does checksums on components used by the executable/dlls.

But firstly, three things need to be stated here. Firstly, dlls are not executable by themselves. By dll injection, an executable may use a function within the dll file. (dll = Dynamicly linked library). Second, component checking firewalls already exist. However, often the checksumming process is so non-discriminating that components which legitimately get modified often are checked as well. Consequently, the result is a stream of 'false positives' alerting to the fact that a program's components have changed.

Thirdly, it is possible to create tight rules for svchost.exe without intrusive/painful measures. It is most likely that the rules you have chosen to create are the problem, rather than any missing feature of the firewall you are using. (See the Outpost link provided and/or BZ's default ruleset)

 

Thanks for the reply, ghost16825 (can I just call you ghost?. I'm after a firewall that allows specific control over each and every aspect of every application and component in my system - at least as far as network access is concerned. I want to be able to choose an application in this mythical firewall and methodically specify protocols, ports, and directions to which it has access. I want svchost broken down into the DLLs that are actually requesting the net access and then I want to be able to specify policies for each of them as well.

Right now my svchost rules look like this:

http://www.syrinx.net/images/shrules.gif

The first is DNS, the second, DHCP (both to my router), and the fourth is for Windows' insistence on time synchronization. The third rule is the one I don't like. What if the impossible happened and I got infected by a trojan which hides behind svchost and happens to phone home to a web service (SOAP, XML-RPC, etc.) listening on port 80 or 443? It could send ANYTHING out (not to mention receiving information). Currently I have to give svchost outbound access on these ports or be plagued by alerts asking me whether to allow it out on port 80 or 443.

That's why I want more fine-grained control. I'm not looking specifically for MD5 signature maintenance. I thought I recalled mention of a firewall that allowed one to peer inside svchost and apply rules to each component therein. Perhaps I was mistaken.

I'd write this mythical app firewall myself, but I've not enough Windows experience for the job. I'm a Linux/Python/C kinda guy.

Thanks for the response!

 

zigguratt, how could a trojan hide behind SVCHOST? My understanding is that the "Generic Host Process for Win32 Services" {i.e. SVCHOST} functions only for Windows vital services, such as what you mentioned: DNS, DHCP, etc.

 

I'm not certain, but is this the type of concern that is being discussed? It has been a concern of mine, as a user of ZoneAlarm Pro.

http://vil.mcafeesecurity.com/vil/content/v_100699.htm

Rich

 

Thank you Rich, never heard of that. "Backdoor-AZF" {McAfee classification} sounds like a job for my TrojanHunter app to cover. TH supposedly handles DLL-injecting trojans. I hope to capture a sample of that one and send in to TH now.

 

Yes, that's exactly what I'm talking about, and it's just one example. I see svchost as a huge security hole in Windows and want more control over it.

 

Whoa! Fast posting around here! I use TH (guard & scanner) as well. Call me paranoid, but I just want to cover all eventualities...

 

As ghost16825 eluded to you will not have the component control with Kerio 2.1.5 that other firewalls offer, but you may be able to refine your rules.

The rule for Windows Time is fine and restricted to an IP. If you do not want Windows doing this, simply disable the service.

You can play the "What if ...?" game for ever. You just need to define a realistic security policy that best suits your needs.
For rule #3 the outbounds will most likely all be for Microsoft sites. Your option for refining this rule is to start gathering a list of IP's used (enable logging) and then modify your rule set allowing outbound to those IP's only. An option would be to use the Custom IP list for this (much like you could use the trusted zone list in ZA for svchost).

Regards,

CrazyM

 

Here is the key sentence:

----------------------
Currently, the trojan needs to be manually installed and connected in order to achieve remote access to the victim's machine.
----------------------

I would be more concerned about how a trojan could become installed, rather then worrying about my firewall. With all of the other protection available, what is the possibility, really, of this happening?

Regarding your rules: I'm not sure why you have #3. Permitted, unlimited outbound doesn't seem wise here. I concur with CrazyM's suggestion about setting up rules for svchost.

regards,

-rich
________________
~~Be ALERT!!! ~~

 

I don't really understand about svchost needing access. I have it blocked in and out tcp and udp in Kerio 2.1.5 any address and have not noticed it causing any problems in the last couple of years.

 

Depends on how you have your rules configured as svchost.exe will be the process behind some common network functionality in Windows. An example why you may not have seen it: is your DNS rule in Kerio for "any application"?

Regards,

CrazyM

 

This is the way Kerio's default system-wide rules are set up. When I became aware of how Services (Win2K) and Svchost (WinXP) work, I changed from "any application" to listing the specific application, leaving any other attempts oubound by those services to call up an alert. I assume this is what you would advise people to do?

-rich
________________
~~Be ALERT!!! ~~

 

The defaults may be fine for some, others may want stricter rules. It is a matter of how much you want to lock things down. Firewall choice/rule sets along with other measures should be part of an overall assessment of what best suits your security needs. Unfortunately there is no magic bullet or right answer for all. What may meet my requirements could be totally unsuitable for you. This is something we each need to define and implement.

Regards,

CrazyM

 

Since many people post asking about rules, how would you teach someone just getting started with a rule-set firewall, how to define needs and requirements?

thanks,

-rich
________________
~~Be ALERT!!! ~~

 

Ah, but that's a choice you have made. If you have created this rule for Automatic Updates, then it is possible to restrict it to Microsoft's netblock. Also, for a DHCP Broadcast if I'm not mistaken this only need to be allowed outbound from the client (which asks for DNS servers/an IP address to be assigned to it).

 

That is a pretty broad question as it depends on the firewall and a number of other things such as users, their use of the system(s), their habits (good, bad or indifferent), their computer knowledge, other security/privacy measures in place.

The following comments are based on the premise of no local servers and a deny all inbound policy.

For rule based firewalls, application based or not, a basic rule set would limit outbound connections to required services only. This will vary for users but usually include DHCP, DNS, HTTP, HTTPS, POP3, SMTP, FTP, NNTP and probably some IM (MSN, Yahoo, AOL) services.

The next option if you wanted to refine or customize your rules further, application based or not, would be to limit certain services to specific IP’s. This would typically see things like DNS, SMTP, POP3 restricted further.

The last option would be applicable for application rule based firewalls where you could further restrict something like the topic of this post, svchost.exe, or have things like application based DNS rules. For those using and concerned with proxy software and localhost, some firewalls will also allow for setting restrictions on what can access localhost and the proxy (loopback rules).

Do you need to go the extent of the last option? This will always be subject of debate and a matter of personal preference. My suggestion for those just getting started would be option one as a minimum (a little more than a default permit any outbound) and option two as a happy medium if they wish to customize a little further.

Regards,

CrazyM

 

Thanks for those suggestions. That seems like the logical first step, rather than just copying someone else's ruleset.

(great quote in your sig!)

-rich
________________
~~Be ALERT!!! ~~

 

quick question.

why won't pointing your svchost.exe to your dynamic/static ip gateway (esp. if you are behind a router) do? svchost.exe is only allowed to access 192.168.2.1 on my PC. so any trojan or malware cannot use svchost to access any other internet address.

 

The only choice I've made so far is to use Kerio. The reason I posted in the first place was to find an alternative with which I didn't HAVE to make the choice we're discussing. I will, however, change my svchost rule to build up a list of legit IPs in the Custom Address Group - or figure out Microsoft's netblock and specify that instead. At least until I can find an alternative to Old Kerio.

At the moment I'm not even using DHCP so I'm going to disable that rule anyway. I only added it recently when experimenting with the router. The only change I would make to the rule would be to specify local port 68 instead of [Any port]. You do need bidirectional communication with the DHCP server, however, unless I seriously misunderstand DHCP!

[Edit: I just checked and this rule (with local port 68 specified) is now exactly the same as the "Assign DHCP Server" rule in the BlitzenZeus Kerio rule set]

 

That works fine for any available local services to which svchost needs access, such as DHCP/DNS (see above). This also assumes you aren't connected directly to the 'net, as I suspect most people are. But it definitely won't work when Windows wants to connect to the Windows Update servers, which are, oddly, not behind your router...

 

Nothing wrong with using something like that as a starting point or guide, just don't implement it carte blanche. It is important that a user understand all their rules and what they do. Always a fun learning experience to start with no rules (deny all) and build from there

A good common sense approach.

Regards,

CrazyM