Vista/7 outbound control - not really that hard

I've read so many horror stories about how difficult it is. That you basically NEED one of those 3'rd party plugins just to even make it tolerable, if not use a 3'rd party FW altogether if you want outbound control.

But I just got done fixing a few people's boxes and decided to play around with the outbound control this time to see for myself. I personally don't get what all the fuss is about. I can do everything I can do in my Comodo FW from what I see, granted not laid out as nicely. In fact I can create in one rule what takes me 2-3 rules in my Comodo FW to make, since you can list multiple single addresses in the same rule.

Granted, I just set a few app rules. I didn't get into other networking rules, i.e. svchost. etc... to see how it handles such things. And/or perhaps there's other weaknesses about it that I'm oblivious to? But from the sample size I got, the outbound control seems adequate to me just the way it is.

This used to be one of my biggest concerns about upgrading from XP. Now instead it's one of the (very) few reasons I want to upgrade.

 

The devil is in the detail as the saying goes.

If creating outbound rules for applications was the only issue, anyone with rudimentary firewall knowledge could sucessfully create outbound rules for WIN 7 firewall. The issue by design by the way is svchost.exe. WIN 7 firewall uses WSH, windows service hardening, to securely handle svchost.eve outbound access. It dynamically opens and closes ports as required for WIN 7 services that need Internet access. WSH in WIN 7 is more secure than that provided in Vista. No other third party firewall has this capablity.

WIN 7 also has "hidden" services that are not listed under services.msc. Some of these require outbound Internet access. So how do you create a firewall rule for a service that is "hidden?" There are ways but it is extremely difficult and not recommended.

I beleive Microsoft is purposely being glib when they made the statement that all outbound WIN 7 firewall traffic is allowed. That is not the case and they know it.

I believe the third-party WFC add-on to the WIN 7 firewall has made good progress at determining what outbound svchost.exe rules are required. I have not tested the product so I can't say if it exactly what it does. There are numerous threads on it on the Wilders secuirty forum. I beleive it maintains WSH integrity in that it acts as a "backend" filter to the WIN 7 firewall. It is intercepting its traffic and creating separate rules on how to handle that traffic?

The absolute worst thing you can do is create a "global" WIN 7 firewall rule to allow all outbound svchost.exe on port 80 and 443. By doing that, you have in essence turned off all WSH protection.

 

Hi,
Explained really-really exact.
However, one in a thousand that can understand this, if ?
Unfortunately even among developers of third party WF control.

 

Ah, thanks itman... so there you have it. Then using something like WFC in addition to it seems to be the best approach, since as you say no other 3'rd party FW caters to this need while WFC is adapting.

Okay, well this explains a lot. I never saw anyone actually break down exactly "what" was wrong with it. Just always ask what FW to use instead of it.

And this reinforces to me how satisfied (and safe) I feel with XP Pro. I don't have any services/processes that require internet access for my box to function properly. But these new OS's are supposedly "more secure"? How? By what measure? Sure there's more integrated security tools, and mitigation techniques, but at what cost? A larger attack surface is what, not to mention the bloat.

I don't have to worry that my OS & FW have some shady process leaking through it for one thing. And of all the 11 processes & 9 services I have running all have been thoroughly poked & prodded for vulnerabilities over the years and patched accordingly. And now it's not targeted nearly as much as Vista/7 either, with it's EOL much nearer.

I have to say I feel safer on XP Pro than any other Windows OS all things considered. Out of the box maybe 7, but with the right hardening & software you can more than account for any security shortcomings XP has, and the smaller attack surface/targeting gives it the edge.

 

Salut,


I read you sometimes "English" gentlemen and I view your certainties, XP than Windows 7 pro... Let's get!

Svchost.exe, although a firewall allow it, tell you what? the process parent or child? This is not because you will allow the parent "svchost" children will be allowed, so it is without problems, at least in the local network.

As regards the windows firewall, should take a look inside before you talk about it, the only fix is to allow windows update output, the rest is easy and it works rather well.


Je vous lis parfois messieurs les "anglais" et je découvre vos certitudes, XP pro supérieur à Windows 7... passons!

svchost.exe, bien des pare feu l'autorisent, vous parlez de quoi? le processus parent ou enfant? ce n'est pas parce que vous allez autoriser le parent "svchost" que les enfants seront autorisés, donc c'est sans problèmes, au moins dans le réseau local.

Quant au pare feu de windows, il faudrait jeter un oeil dedans avant d'en parler, la seule difficulté c'est d'autoriser windows update en sortie, le reste est plus facile et ça marche plutôt bien.

 

Here is an excellent tutorial on WIN 7 firewall and explains WSH in detail: http://sourcedaddy.com/windows-7/understanding-windows-service-hardening.html

 

Agreed. It may not be as "hand-holding" user-friendly as answering pop ups, but the concept is quite easy to grasp and it's very intuitive. Heck, a simple Google search will unveil all kinds of easy-to-follow tutorials.

 

Merci.



"The absolute worst thing you can do is create a "global" WIN 7 firewall rule to allow all outbound svchost.exe on port 80 and 443. By doing that, you have in essence turned off all WSH protection."

Not sure, windows update uses ports 80 and 443 outbound, and the order of the rules is that if this "global" rule is placed last, the door is already almost closed.

 

Correct. One of the rules you need if you enable WIN 7 firewall outbound protection is a rule for WIN Updates. You would create a TCP rule for svchost.exe but only for service Windows Update i.e. wuauserv. I would leave the ports undefined. Why? Because WIN 7 services may use TCP ports other than 80 and 443.

Also WIN Updates is usually triggered by the BITS service which in turn calls multiple other services many of which need outbound access and firewall rules.

Get my drift here? This is why Microsoft doesn't want you to enable outbound protection and just let WIN 7 do it's thing.

 

I have a little trouble understand your response, english difficult for me...

I want just to point out that , for example, Look 'n' stop allows svchost and services at its facility, process parent and children, without states of mind, as upstream, rules are and protect already, principle of hierarchy of rules.

For windows the principle must be the same, and even though do not allow svchost port 80 and 443 without restriction, to filter more tight, this is not a disaster.


J'ai un peu de mal à comprendre votre réponse, anglais difficile pour moi...

Je veux juste faire remarquer que, par exemple, Look n' stop autorise svchost et services dès son installation, processus parent et enfants, sans états d'âme, vu que en amont, des règles sont prépondérantes et protègent déjà, principe de hiérarchisation des règles.

Pour windows le principe doit être le même, et même s'il ne faut pas autoriser svchost port 80 et 443 sans restriction, pour filtrer plus serré, ce n'est pas une catastrophe.

 

First from what I gather by posts on Wilder's, appears LnS is not being actively supported anymore?

I am not familiar with LnS. From the svchost.exe posts pertaining to LnS, it appears LnS monitors svchost.exe outbound traffic. It will tell you details on the oubound connection including the service used. This is all well an fine but since Microsoft uses multiple servers all over the world that constantly change, I can't see how maintaining a list of allowed IPs can be anything but an effort in futility.

The closest Vista/WIN 7 firewall add-on that made an attempt at properly handling svchost.exe is Windows Firewall Notifier(WFN). The developer by the way is French. The add-on does make a valiant attempt at allowing outbound svchost.exe services but hasn't been able to handle those "hidden" services I mentioned previously. So WFN reverts to creating a rule to allow all svchost.exe connections for TCP ports 80, 443. I helped the developer with testing WFN so I am very familiar with the product.

Bottom line - I beleive monitoring WIN 7 outbound connections via a firewall is an effort in futility. I agree with Microsoft on WIN 7 outbound connections. If your PC is dialing out to places it shouldn't be, your infected and should be directing your efforts at removing the malware.

 

i take it from your post that it is better to let the Windows firewall handle svchost rather than having some 3rd party firewall app do it.

 

Yes. I spent many months trying to set up trying to set up oubound rules for svchost.exe and was still getting block connections. I spent many hours watching svchost.exe with ProcessExplorer.

Firewalls were designed to keep things out of your PC. That is their primary purpose. As far as oubound goes there are better ways to monitor your connections; TCPView, Wireshark, nmap, etc. CurrPorts when run in admin mode will also show most services that svchost.exe is using on a connection. Again it doesn't show those hidden services Win 7 uses.

 

@ itman:

tnx a lot for sharing m8!

 

"Hidden" services cited by Itman (currports) connect without asking never anything to any firewall.


With Look n' stop firewall, have requested access to the internet at home and were allowed:

system32/services.exe
system32/svchost.exe
explorer
helpanne
taskeng
taskhost
wermgr
msdt
h.h
werfault
relpost
userinit
mmc
rundll32
msiexec

syswow64/cmd
rundll

servicing/trustedinstaller

ps: mmc explorer and rundll can be allowed once.



Filter outbound is not indispensable in fact, except in case of infection... during it and after.

 

While true, it would make me feel much better in the meantime if this malware wasn't allowed to call all of it's buddies.

Also, even if it's dialing to places it "should be", I don't really know or trust what it's doing. And on XP I don't have to trust it... I can just block it.

And this goes for more than just svchost. And it's a big reason why I use outbound control. Also, it converse bandwidth. So many programs I trust even, will try to access the internet when they simply don't need to. Comodo has 2 processes (cpf & cmdagent) that try to connect. I've looked around, and have yet to see a valid explanation as to exactly what they are trying to do, and why they need/want access. So I don't allow it, and everything works just fine.

And thank you very much , itman, for the information you've provided here.

 

I'm sorry you had such bad experience with svchost.exe, usually with few rules you can tame the same.
Where there's your problem, can you explain ? or better post your WF cof. file ? There are no hidden connections.

 

First, what is listed are not WIN 7 services. Go into Control Panel -> System and Secuirty -> Adminstrative Services -> services.msc. Then open each service and note its short name. These are most of the services managed by svchost.exe.

Appears LnS is allowing any svchost.exe outbound request just like any other third party firewall.

Why is this an issue? The first thing a rootkit and other malware attempts to do is install a hidden service. It will also try to install a bogus copy of svchost.exe but that is a bit more difficult in WIN 7. The malware installs hidden code to attempt to execute the hidden service using a legit copy of svchost.exe. If a third pary firewall has a rule to allow outbound svchost.exe, the hidden service directly connects to the Internet.

Again the weak point of third party firewalls is they have to allow unconditional access to svchost.exe TCP port 80, 443 minimally to support WIN Updates, UDP port 53 for DNS, UDP ports 67, 68 for DHCP, and other functions such as certificate updates and the like. The best that can be done to restrict access scope is to specify destination IP address. I have already expressed by opinions on the futility of using IP addresses.

 

Ports normally required for common Windows services using Windows firewall w.advanced security:

1. DHCP = UDP, local 68, remote 67

2. DHCPv6 = UDP, local 546, remote 547

3. wuauserv.exe (Windows update) = TCP, remote 80 & 443

4. DNS Client = UDP, remote 53

5. CryptSvc (Cryptographic services) = TCP, remote 80 & 443

6. SSDPSRV (SSDP Discovery) = UDP, local 1900, remote 1900

7. w32time (Windows time) = UDP, local 123, remote 123

if no local port listed, then this implies "Any". When creating the rule, choose svchost.exe plus the associated service you want to apply the rule to.

 

A few other services but not all that connect outbound are:

BITS
LanmanWorkstation
NLA

If you don't allow BITS, wuauserv doesn't work correctly.

WIN 7 will also use svchost.exe to connect out periodically to validate your OS license.

It goes on and on.

 

i suspected as much.
i had no such restrictions when i used LnS firewall, i basically allowed svchost to do pretty much as it pleased. lol
which probably means that this stuff should be left alone if you're about as clueless as i am.

i'm just gonna let the Windows 8 firewall do its thing.

tnx everyone for chipping in as this is quite interesting stuff i think.

 

Here is the link to what acted as the forum for Windows Firewall Notifier(WFN) as it was being developed: http://www.ghacks.net/2011/07/28/windows-firewall-notifier/.

Go through all the comments and note how the developer tried his best to find all services used by the Vista/WIN 7 firewall only to have something else popup out of nowhere.

Note that the Vista firewall is not as extensive as the WIN 7 firewall and appears individuals have been able to sucessfully create outbound rules for it without crippling critical update functions.

 

Salut,


Aucun intérêt à faire une fixation sur svchost ou ses services, j'ai rarement vu un service se connecter à internet et déclencher une alerte, à part windows update et quelques autres, svchost c'est du réseau local essentiellement.

Eviter les fuites en filtrant les services? comment?... ce n'est pas du travail de firewall, c'est du domaine de la proactivité, avec un bloqueur comportemental et de l'heuristique dynamique et statistique, c'est le rôle de l'antivirus, pas l'affaire du réseau.


No interest to a fixation on svchost or its services, I've rarely seen a service to connect to the internet and trigger an alert, apart from windows update and a few others, svchost is LAN basically.

Avoid leaks by filtering services? how?... it is not the work of firewall, it's being proactive with a behavioral Blocker domain and heuristics statistical and dynamic, it is the role of the antivirus, pas case network.

 

It is useless to tell me where to find services and their exe.


The problem of leaks is not that svchost, there are many others, and it is not by filtering services or other them should be avoided, it is a matter of being proactive, so antivirus.

Filter output is an advantage, be it sinking into paranoia? should be rather clear demarcation skills, and well to say that if you have a good antivirus, Bitdefender or Kaspersky, one hardware firewall well adjusted (only incoming filtering), and no software firewall...
You will die?... no! nothing will happen, the danger will come may be from the local network.

 

I'm getting the impression that this is the best course of action as well, for every OS since XP. To stick with the integrated FW and your plugin of choice for it. I see camps for both WFN & WFC in here. It'd be nice to get an objective rundown of the pros & cons for both of them to help people make informed decisions. I've never really seen anything like this. All the posts about them are simply information about bugs and patches/updates.