svchost.exe and rule-settings

[Falke]

Today I installed Windows XP Pro.

Two questions:
Can I import the rule settings of Outpost under W98 without problems to Outpost under Win XP?
Does anybody know how to handle svchost.exe? Some things that should be blocked? Or can I allow all?

Falke

[MegaHertz]

Falke

Can I import the rule settings of Outpost under W98 without problems to Outpost under Win XP?

I suspect as long as the apps are the same it would work, but I'm not sure on that (I don't think that there is an import option for rules. Yet). You may try using the old config file, I don't think the config file is affected by OS (just make sure you switch back to rules mode to cover anything that may pop up).

Does anybody know how to handle svchost.exe? Some things that should be blocked? Or can I allow all?

On my system I have to allow svchost.exe for DNS and DHCP. My rules for it however are very strict. I would recommend you got to BlackViper.com (http://www.blackviper.com/WinXP/servicecfg.htm) and read up on the services and disable all the uneccessary ones.

P.S. I would never allow all if you can avoid it.

[Falke]

I already have imported the old cfg.-File. But I was not sure If all functions correct than.

Thx for your advise with svchost.exe.
I will look at BlackVipers Site.

Falke

[David]

Hi Falke,

I have done a lot of work and posting regarding svchost.exe. By now you have probably got some insight from the microsoft knowledge base or the excellent site by Black Viper. Currently, I have three separate configurations that people can try. Two of them are variations of the same idea. Your choice regarding each set will depend on you sensitivity to security and privacy and you trust of Microsoft. I will also list some general advice based on recent experiences and a few good websites.

SVCHOST.EXE Setup #1

Setup number one is simple. DO NOT CREATE A RULE for SVCHOST.EXE. Make sure there is no listing for this executable under Trusted, Partially Allowed, or Blocked Applications. Be aware that you may have to "double click" on "Trusted", "Partially "Allowed", or "Blocked" in order to verify that svchost.exe does not exist under any of these headings. Sometimes the program listing can be collapsed under these headings in the same way that you can collapse and expand directories in Windows Explorer File Manager. Another important step is to NEVER run a security scan at an online scanning site unless your Outpost Firewall is in the "Block Most" mode. Many scanning sites may invoke SVCHOST.EXE by requesting a connection to one of the services that it controls. You will not see these warnings if you are in "Block Most Mode". In fact, it is my opinion that the firewall should only be in Rules Wizard Mode under three conditions:
1. New Outpost Installation
2. Troubleshooting a Connection Issue
3. Setting Up a Rule for a Newly Installed Application

SVCHOST.EXE Setup #2

This setup involves creating rules for SVCHOST.EXE. In this case you will have a rule in the list for SVCHOST.EXE under Partially Allowed Applications. The only rule that I have ever had to create was the following.
Where the protocol is UDP
Where the host is: 239.255.255.250
Where the remote port is: 1900
Allow It.
The remote host mentioned is IANA, the Internet Assigned Numbers Authority. I am not sure about the nature of this communication with IANA. It may be for some kind of Domain Name Resolution.

SVCHOST.EXE Setup #3

This setup involves setting up a rule exactly like the rule created in setup 2. However, the action chosen is "Deny It".
Any one of the three setups described is probably reasonably secure, even number two, since only one, probably trustworthy remote address is used. Since I am uncertain about the nature of the communication with IANA, I would suggest setup one or three for anyone very sensitive about privacy and security.

A little extra information.

EXPLORER.EXE

Sometimes Windows Explorer will ask for permission to access the internet. You can follow any of the suggestions, one, two, or three for EXPLORER.EXE. The only difference is the Remote Host and the Remote Port. Here is a rule.
Where the protocol is TCP
Where the direction is Outbound
Where the host is sa.windows.com
Where the Remote Port is HTTP
Allow it OR Deny It, it is your choice or do not create any rule at all like in Setup one for svchost.exe above. Sometimes it may be best to create the rules for an executable like svchost.exe and choose "Deny It". "Allow It" can also be chosen if you do not care about contact between your system and the sites mentioned above. I would not allow any other remote hosts for either of them though. The reason for this is that if you are in Rules Wizard Mode, you will see less incidental popups regarding those executables. But, as I said, "Block Most" is the best place to be almost all of the time. One last piece of advice regarding rule setting for these Applications. Your Remote Port may vary depending on whether you use a LocalProxy or an ISP proxy. I do not use these, so I do not know how the Popup box will appear for these executables. Regardless, the same methods for setting up the rule for these executables apply.

I have tried all of the setups listed above and all have worked without incident. So, anyone applying those methods should not experience problems. The only reason that I have experimented with so many different setup methods has just been curiousity. Currently, I am trying to setup everything on a rule by rule basis to better understand the connections that different applications need or do not need. It takes a lot of patience.... :o

Concerning some of the services on XP. Most likely you can STOP and then set to DISABLED the Universal Plug-n-Play Service (UPnP) and the Simple Service Discovery Protocol Rule (SSDP). UPnP uses port 5000 and SSDP is responsible for using port 1900. Then you should not get any popups regarding these at all. I also worked with my system with these services enabled and disabled with no adverse side effects either way. My opinion is that almost 100% of the people out there can disable these services with no issue. There will certainly be no system crashes related to disabling these services.

Concerning Trusted and Blocked Applications. My opinion is that only programs that you wrote or that come from a highly trusted source should be in Trusted Applications. And, the only applications that I would add under blocked would be suspicious programs that I initally suspect are trojans. Then I would delete the rule as soon as I removed the trojan with an effective removal tool like Tauscan. This way, I can check the effectiveness of the removal process. I think that this is pretty much consistent with the advice in the Outpost Manual.

Sorry about the long message. I just wanted to try to provide as many options as possible to suit everyone's taste. Below are a few links to some helpful sites.

Microsoft Support Article Concerning Svchost.exe
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q250320

Information on Windows Services (listed previously in this thread)
Windows 2000
http://www.blkviper.com/WIN2K/servicecfg.htm
Windows XP
http://www.blkviper.com/WinXP/servicecfg.htm

Good places to look up IP addresses:
www.arin.net (American Registry)
www.ripe.net (European Registry)
www.apnic.net (Asia-Pacific Registry)

Good Places for general and application port information:
http://www.iana.org/assignments/port-numbers (General)
http://www.practicallynetworked.com/sharing/app_port_list.htm
Each of these ports lists are extensive. Just scroll down.

And, of course the Outpost manual can be found in the download section of www.agnitum.com

Well, I hope that I helped more than confused anyone reading this message. Again, nobody should experience any problems with any of the setups that I listed above. I've tested them all.

Good Luck..

Best Regards,
David :)

[David]

To anyone reading the reply by me above, please be aware that I modified my original post slightly to reflect that SSDP uses UDP port 1900, not TCP. Anyway, the above message has been corrected also. Sorry if that mistake caused anyone a problem.

:o

Thanks,
David

[Falke]

Hi David

Thank you very much for your help :-)
I disabled SSDP and now svchost.exe needs no configuration anymore and I'm running Outpost in Block Most Mode.
Only DNS Resolving but I never got a pop-up from Outpost to make a rule. It is allowed without asking me. Is this normal?

Falke

[David]

Hi Falke,

I believe this is normal. There is a Global Rule to allow DNS on UDP port 53. I think that is the correct port and protocol. :confused:

svchost.exe, seems to be involved in DNS resolution and is necessary to browse the web. In a way, even if you do not have any extra rule created for svchost.exe, you always have the Global rule for DNS which uses svchost.exe. Global rules do not show up in the Applications Lists. svchost.exe controls many functions, but like you, I only want svchost.exe allowed for DNS, nothing else.

If you want to see where the rule is to allow DNS, you must go to Options -> System and click on settings under Global Applications and System rules. You will be able to inspect the rules there. These rules are the reason that you were not asked about DNS.

Hope that answered your question. I was starting to confuse myself. :D

I think everything that you described is NORMAL....

David
:)

[Falke]

thanks again :-)
Yes, this answered my question...

[Le Prechaun]

I believe this is normal. There is a Global Rule to allow DNS on UDP port 53. I think that is the correct port and protocol. :confused:

That's correct. But not as widely known is that in some situations DNS can use TCP port 53, too. Such a situations is e.g. when the size of the DNS response exceeds 512 bytes. Then your box issues the request again, using TCP instead of UDP.

Just came to my mind... :)

[Alan Guy]

Originally posted by David

svchost.exe, seems to be involved in DNS resolution and is necessary to browse the web. In a way, even if you do not have any extra rule created for svchost.exe, you always have the Global rule for DNS which uses svchost.exe. Global rules do not show up in the Applications Lists. svchost.exe controls many functions, but like you, I only want svchost.exe allowed for DNS, nothing else
That caught my attention because on my Win2000 it's the services and controller app (services.exe) which does the dns work. So I did a little checking and it appears that for XP, svchost .exe handles the dns, but on Win2000 it's services.exe that does it.

I actually have svchost.exe totally blocked with no ill effects. And my services.exe is allowed ONLY for dns. Again this is on a stand-alone Win200Pro, dial-up.

I understand you were discussing XP, but I just didn't want someone mistakenly thinking that it's svchost that does the dns on ALL Windows machines.

[David]

Hi Alan,

That is a great catch. Thank you. I went straight from Me to XP, so I have no experience with Windows 2000. But, I do have a question for you. If there is a global rule for DNS, why did you need to create a rule for it under the application services.exe? The global rule seems to handle svchost.exe and accessing the DNS just fine on my PC. I think that if you deleted the rule that you have for services.exe and DNS, you would be OK. The global rule allows for DNS through UDP 53. I am only GUESSING, but I have a feeling that the rule that you created for services.exe is probably for TCP 53. Occasionally if I am in Rules Wizard mode, I will get a popup for creating a rule for svchost.exe TCP 53, but I just press block once. In fact, most of the time, I am in 'Block Most' mode, so I do not get that popup at all. The only rule that I have ever needed is the Global Rule for UDP 53. Check your settings for services.exe (DNS) and try what I have recommended here and let me know. I do not think you will have any problems getting rid of your services.exe DNS rule if you use the global rule, but please verify this if you get time.

Thanks again,
David
:)

[Alan Guy]

Hi David,Originally posted by David
If there is a global rule for DNS, why did you need to create a rule for it under the application services.exe? The global rule seems to handle svchost.exe and accessing the DNS just fine on my PC. I think that if you deleted the rule that you have for services.exe and DNS, you would be OK. The global rule allows for DNS through UDP 53. I am only GUESSING, but I have a feeling that the rule that you created for services.exe is probably for TCP 53.
No, my rule for services.exe is for UDP, Outbound, Remote Port 53 and for my ISP's 3 DNS IPs only. My Global DNS Rule is deleted.

The main reason I made my own rule is that the *fun* part of firewalls (for *me*, and the best way for me to learn) is to delete all the out-of-the-box default rules; turn on a packet sniffer; connect to my ISP and one-at-a-time create rules to make things work. I don't need the sniffer that much anymore, though ;)

When a transaction wont work for me, I switch off the firewall, switch on a packet sniffer and perform the task then log off. Then look at the packets to see what protocols, ports and IPs were involved in the transaction; switch on the fw again, build the necessary rules, log back on and test and tweak.

In awhile you learn what rules are necessary to do what you need to do, whether VPN, ftp, pcAnywhere, IRC or anything else - and build YOUR rules for YOURself. If a desired transaction fails - switch on the packet sniffer and quickly see why. That's just my preference, though. Obviously there's a need for good *default* rules. That's how we ALL start, right?

Sooo... I uncheck the Global Rules to start with, and build my own rules - under Applications, mainly.
Occasionally if I am in Rules Wizard mode, I will get a popup for creating a rule for svchost.exe TCP 53, but I just press block once. In fact, most of the time, I am in 'Block Most' mode, so I do not get that popup at all. The only rule that I have ever needed is the Global Rule for UDP 53.
I stay in Rules Wizzard mode, but really only because there's no *Build All Your Own Rules* mode. And really, and especially for a newbie, the Pop-ups help one learn what's necessary for a given transaction to happen if you haven't made a rule to allow it yet. So even though I feel pretty competent at building rules - I stay in Rules Wizzard Mode. It also saves having to fire up the packet sniffer sometimes.
I do not think you will have any problems getting rid of your services.exe DNS rule if you use the global rule...
Oh I already know that that works. As I said, I just prefer to build my own rules: Inbound, Outbound, Ports, Protocols and Applications.

I wasn't saying I had a problem with services.exe or with DNS, I'm doin fine here ;) I just wanted to point out that DNS is not universally handled by svchost.exe in all Windows OSes. On Win2000 it's the Services and Controller APP or services.exe.

Take care, David.

[David]

Hi Alan,

Thanks for the very complete reply. Actually, my situation is kind of a hybrid of yours. I rarely use the presets for applications, and even if I do, I edit the rules once they are set in order to tighten them up as much as I can get them without causing great inconvenience. As far as the global rules go, I have looked at them all but have not edited or added to them yet. But, I do see a great deal of wisdom in specifying only your ISP DNS machines in your rules and will make similar changes to my configuration. In addition, I will scrutinize the other global rules over the coming days and maybe make some changes there also. The technique of using the sniffer to see what is going on with your system ports and then applying what you learn to rule setting is OUTSTANDING :D. In fact, I hope that some other users will pick up on that and give it a try on those applications they are having difficutly using. It is a very good method. I have one utility that I can use for the same purpose if I need to. I was about to ask you why you used a sniffer when Agnitum does not recommend it. But, you already answered that question when you commented about shutting down the Firewall and Service before operating the port sniffer.

Well, this has been good dialog for me, especially since I moved directly to XP and skipped 2000. Thanks for the dialog. I think that many people, especially new users will find the dialog in this thread educational.

Best Regards,

[mengano]

interesting options but none of them work blocking Svhost.exe prevents me from connection to the cable network using WinXP Pro and I must allow for DHCP for renewal of IP as required by ny connection. Viper did not help that much and the last time I did use few of his suggestions I could not get WinXP to boot.Ok I must admit that was six months ago so he's changed few of his suggestions I noticed hehe!

[David]

Hi mengano,

If you set up the rules properly, svchost.exe should only be communicating with the DNS server or possibly localhost.

It is important to take a look at the LOCAL ADDRESS and the REMOTE HOST. On my system, I see svchost.exe incoming on 1900 but through the loopback rule. NO REMOTE HOST IS CONTACTED.

If you see an outside host connected to any port but DNS through svchost.exe, then you have set up the rules improperly.

As far as DHCP goes, that is handled by a GLOBAL rule. So, you will have no problem getting your IP unless an application rule is set up to deny this. There is NO reason why you cannot set up the rules as outlined above and be successful.

I use WinXP home. And, I assure you that rules you need to set up for this firewall concerning svchost.exe will be no different than stated here.

I have used these rules for several months and have tested these rules on multiple online security scanning sites. The results of all of those security checks met or exceeded my expectations. In all cases, the results showed my PC completely stealth. Additionally, I have not had any issues with online exploit or privacy tests.

I will be online later to help if you need further assistance refining your ruleset. With a little time, I am pretty sure that we can create a configuration that you will be happy with. :)

Be patient and keep working with it....you will get there. :D

[grendizer]

About setup number 1:
If I remove svshost from the list. Next time it will try to connect, a message box will pop up. What should I do then?

[David]

Hi grendizer,

If you use setup 1, you MUST set your firewall policy to Block Most and it MUST be in Block Most Policy when you startup or shutdown. Really, there are only three reasons to be in Rules Wizard Policy:

1. New Outpost installation.

2. Troubleshooting application connection isses.

3. New application installation needs internet access rules.

Actually, I believe that you will probably find setup number 2 or 3 in my previous post to this thread more convenient to use. I have the first option in that post only to make a point and also to give a complete list of options for users.

:)

[Mikhail]

If I remove svshost from the list. Next time it will try to connect, a message box will pop up. What should I do then
grendizer, what is exactly displayed in the messaage box (port, protocol, remote host)?
Really, there are only three reasons to be in Rules Wizard Policy:
David, let me argue with you. There are many people who like to install new software several times a week and if it does not work corectly (no prompt for Outpost) and blocked user will be frustrated. Please note - not everyone remember that they have a firewall installed and what's the difference between these Policies.

[David]

Hi Mikhail,

I agree with what you said. In fact the rules that I listed include installation of a program that needs web access as a valid reason to be in Rules Wizard Mode. It follows that if people install and uninstall software frequently, they will be in Rules Wizard Mode frequently.

And yes, some users will get frustrated if they follow my general rule of staying in Block Most policy and run into problems. But, there is a tradeoff. If you operate in Rules Wizard Mode while doing online security scans, a new user might get inbound connection requests for ports and services that they know nothing about. Not knowing what to do with those requests is, in my opinion, more harmful than the inconvenience associated with forgetting to switch to Rules Wizard Mode after installing a new program. And, usually people who experiment with software a lot will not forget something like changing a firewall policy and even if they do forget, they will realize their mistake instantly.

But, I have to admit that I do not always follow my own rules. My original recommendations are made for maximizing security of the user which generally minimizes convenience. Currently I follow this procedure:

Operate in Rules Wizard Mode unless doing an online security scan.

Using that procedure, a user should be able to get to have the convenience of working in Rules Wizard policy without the problems of incoming connection requests on security sites. This works very well for me. :)

[grendizer]

Thanks for your help.
Svchost is currently in my "trusted applications" group.
Yes, I often install many new programs.
I am now testing some P2P programs. I just installed Xolox and Overnet.
David, I think I will choose your method number 2 for Svchost. But if you do not mind, I have one question about it :
Where the host is: 239.255.255.250
remote or local?
what is this IP?
TIA :)
grendi

[David]

Hi grendizer,

Having svchost.exe in Trusted Applications will expose many of the services running on your PC to the internet. Mikhail's argument was not with my svchost.exe rules, it was with my suggestion to normally run in Block Most policy.

As for svchost.exe, I recommend that you use suggestion number two in my original recommendations to Falke. svchost.exe has nothing to do with your ability to set up rules for applications or install applications. And, as Mikhail suggested, operate using the Rules Wizard Policy of Outpost for convenience since you install programs frequently.

Please make these changes as soon as possible.

[grendizer]

Hi David, I followed your instructions for Svchost, and now it allows the connections only for one remote IP. Will there be other lots of other IP poping up some Outpost dialogs?
Anyway, I'm feeling safer now! :D

[David]

Hi grendizer,

It is possible, but rare that you will get continued popups for svchost.exe now that you have rules setup for SSDP. If you ever do get one, I would Block Once or create a rule to Deny the connection until you figure out what is going on. Just remember, that if you going to do an online security scan like the ones at grc.com, www.pcflank.com, and scan.sygate.com, you should operate in Block Most Policy for the duration of the test. Then once you have passed the security scan and proven to yourself once again that Outpost is keeping you safe, you can return to Rules Wizard Mode and continue as normal. :)

[grendizer]

Hi David

I just let down all rules settings for Svchost.
Dialogs are just popping up all the times.
Either it's Windows Update, either it's time synchronization, etc.
It's just annoying me :)
So now it is back in my "trusted applications" folder!

Thanks anyway.

grendi

[RISC OS]

Well I have svchosts in blocked apps and I haven't experienced any problems, even at windows update.

[grendizer]

Risc : then when Windows Update wants to connect, you get an Outpost dialog poping up? Or does it connect without the popup window?
:confused:

[gunnarj]

grendizer,

Instead of putting svchosts in "blocked" or "trusted" apps, why don't you try "partially allowed" with one rule for UDP as explained in an earlier post? Maybe that would work better for you.


gunnarj

[RISC OS]

grendizer

There is no popup when I go to windows update.

[grendizer]

Gunnarj : you assume that all Svchost connections use UDP? Then I should set a rule for all incoming and outgoing connections using UDP?
:confused:

[David]

grendizer,

I think that gunnarj was talking about the one UDP rule for port 1900 to 239.255.255.250 as described in Setup #2 and Setup #3 of my previous host. I do not believe gunnarj was trying to imply that you should block all traffic using UDP to this executable.

RiscOS. Putting 'svchost.exe' in blocked applications will not cause any problems in your case. In Windows 2000, DNS UDP 53 is handled by an executable called 'services.exe'. But, in Windows XP and XP Pro, it is handled by 'svchost.exe'. So, if an XP user puts this in blocked applications, they may not be able to access the internet at all.

grendizer, keep in trusted applications and use setup #2 or setup #3. About the time syncronizer; just shut off Windows time update routine or create the rules. You may need up to four different rules as the time syncronizer seems to try verifying the time through several avenues. I will make a post for you later with some more specifics. But, I am warning you, svchost.exe handles many services on an XP PC including UPnP and you are asking for trouble by keeping it in the Trusted Application.

[grendizer]

Thanks David.
The thing is : I autorized the time syncronizer service, but then, many other things from Scvhost tried to connect to the internet and made Outpost pop up a dialog.
I'm on DSL, permanent connection.

[David]

Hi grendizer,

I know that it is possible that other popups may occur. But, that is one of the inconveniences of staying in 'Rules Wizard' Mode. I am not going to tell you how you should operate your firewall. I am only going to tell you the truth about the consequenses of certain practices. Then the decision is yours.

You say popups for other things??? What other things??
Inbound or Outbound?
Which port? Local or remote?
Which protocol?
Which direction?
Which executable?

If you give me that information, then I can try to help you. You can get the information from the popup or just by temporarily creating the rule and then examining it. I cannot think of any reason or access type that could possibly involve system services as much as in your situation. So, I am very interested to work with you and find out what is going on. :)

Let me know.

[grendizer]

Hi David, thanks for the help.
I will remove Svchost.exe from the trusted applications group and enclose screen shots of the Outpost dialog boxes next time.
But I can tell you Svchost tries to connect MANY times.
See you, :)
grendi

[Danil]

grendizer, any news?

What about screenshots? or at least we need the following information - what is dispayed in the dialogue message:

exact port
local or remote port?
protocol
remote host

[grendizer]

Ok, I removed Svchost from the "trusted applications" then restarted Windows.
Here is one screenshot of the Outpost Firewall dialog that popped up on Windows XP Pro startup.

This is only ONE of the many times an Outpost dialog pops up because of Svchost.

[David]

No problem grendizer,

That one is quite common. Port 1900 is SSDP which was plainly covered in my original post. But, it is interesting that you say you have had problems with other ports. Those are of interest to me. And, I have seen it on other XP systems, but it was related to software the user had on their system. Please provide the following information:

***FOR ALL PORTS THAT YOU ARE SEEING TRAFFIC ON SVCHOST.EXE, PLEASE PROVIDE THE FOLLOWING INFORMATION***
Local or remote?
Which port?
Which protocol?
Direction: Inbound, Outbound, or 'Not Specified'?
Which executable?

EXAMPLES:
Local Port 5000 TCP INBOUND SVCHOST.EXE
Remote Port 1900 UDP 'NO DIRECTION SPECIFIED' SVCHOST.EXE

We have covered UDP 1900, now lets cover the others. Kindly provide the information that I have requested and we can try to go through them one by one and figure out what is going on. I have given you a couple of examples of the format that I would like to see. Please confine your answers to svchost.exe since this is the application that we are trying to troubleshoot and also, provide the information in text form instead of an attached picture because only one picture per post is allowed and you say that you have svchost.exe using multiple ports.

Finally, provide answers for the following questions please.

1. Does the appearance of popups for svchost.exe, other than for port 1900, appear after you begin to use specific applications.

2. Give your hardware information including all connected devices whether by PCI slot, USB port, serial, parallel, etc.

3. List all programs that you use to access the internet other than browsers, e-mail clients, or applications that only use the internet for updating.

4. Give the name of your ISP (optional), any special software that you installed from your ISP, type of service (dial-up, cable, DSL, sattelite).

5. Please list any special network hardware that you use with your sytem like routers, hubs, cable modems, dsl modems/routers, etc. unless that information was provided in your answer to question #2.

Thanks for your patience with this matter grendizer. I look forward to your report concerning the port information for svchost.exe and also the answers to my system related questions.

Have a good night grendizer. :)
Talk to you later.

[grendizer]

Hi David.

I red your old post about the Simple Service Discovery Protocol, but what is this thing exactly? What does it do? Why should I disable it?

You wanted my hardware information. I have many! Do you want a screenshot of my device manager?

Sorry for not replying fast, but I have lots of things to do during the week! :)

David

[David]

grendizer,

Hi.... :)

I am on vacation right now, but I will try to pick this subject up with you in detail when I return. I am studying some Microsoft articles on SSDP, so I hope to have better answers for you when I return to the forums next week. :)

Talk to you later.

[David]

Hello,

After using Outpost on Windows XP for about a year now, I have learned a lot about what rules need to be applied to minimize rule creation popups from Outpost for SVCHOST. In this post, I would like to address only the ruleset that I am currently using according to the OS and Outpost version specifications outlined below.

The strategy that I chose when creating my ruleset for svchost.exe was to create a ruleset that would not only minimize rules creation popups for normal browsing and internet use, but also minimize rule creation popups when performing online security scans. The ruleset that I am about to list are applicable to systems with the following specifications:

Operating System: Windows XP Home or Windows XP Professional (possibly Windows 2000)
Outpost Version: 1.0.1817.1645
Outpost Setup: Default Global Rules (also applies to configurations where the default rules have been modified to specify remote hosts)

Generic Host Process for Services Ruleset by David

[SVCHOST SSDP (UPnP) Connection Rule]
Where the protocol is: UDP
Where the remote port is: 1900
Deny It

Comments: The direction can be excluded from the rule. SVCHOST only purpose for using this port is for enabling the Simple Service Discover Protocol (SSDP), and this is an application rule, so the port will only be blocked for this application (SVCHOST) and thus, only the SSDP service. Other applications will be able to use this port normally and the SSDP service will be safely blocked if the user chooses the 'Deny It' option as I have recommended. Users who must use UPnP should choose 'Allow It' and specify a remote host as applicable as SSDP is used in combination with the UPnP service.

[SVCHOST UPnP Connection Rule]
Where the protocol is: TCP
Where the direction is: Inbound
Where the local port is: 5000
Deny It

Comments: The direction can be excluded from the rule. SVCHOST only purpose for using this port is to enable the Universal Plug-n-Play Service (UPnP) and this is an application rule, so the port will only be blocked for this application (SVCHOST) and thus, only the UPnP service. Other applications will be able to use this port normally and the UPnP service will be safely blocked if the user chooses the 'Deny It' option as I have recommended. Users who utilize UPnP should choose 'Allow It' and specify a remote host as applicable.

[SVCHOST BlackJack (1025) Connection Rule]
Where the protocol is: TCP
Where the direction is: Inbound
Where the local port is: 1025
Deny It

Comments: I have to be honest. I am not entirely sure about the uses of this port. But, when performing online security scans, I have to create a rule to block this port. Other applications will be able to use this port normally and the "whatever service" is enabled by svchost.exe will be safely blocked if the user chooses the 'Deny It' option as I have recommended. Perhaps it is related to certain types of gaming that use some service that port 1025 offers. Perhaps it is just related to Microsoft Gaming. If you have a problem with a Microsoft game or other game, just look in your blocked logs and if you see svchost.exe blocked on port 1025, try changing the rule to 'Allow It'.

[SVCHOST Time Synchronization Connection Rule]
Where the protocol is: UDP
Where the remote host is: time.windows.com, time.nist.gov
Where the remote port is: 123
Allow It

Comments: The rule can also be made 'Deny It'. But, if you choose the 'Deny It' option, then you should probably disable the 'Windows Time' service and obviously not try to use the time updating feature under the 'Internet Time' tab of do the 'Date and Time Properties' window.

[SVCHOST DNS (DOMAIN) Connection Rule]
Where the protocol is: TCP
Where the direction is: Outbound
Where the remote port is: 53
Deny It

Comments: The first point that I want to make about this rule is that I DO NOT currently have this rule in my ruleset. Most, over 99%, of the sites that I visit do not require this rule to be present. The global rule for 'Allow DNS Resolving' already takes care of most sites. So, I do not recommend that you create this rule unless you have researched the benefits and potential risks regarding this rule. Currently, if I do get a rule creation popup for TCP Outbound 53, I choose 'Allow Once' or 'Block Once' based on whether I trust the site(host) involved or not. And, I admit that my knowledge is limited on why the use of this rule may be necessary. But I can say that I have never had a problem connecting to a remote host or visiting a web site by choosing 'Block Once' when I get a rule creation popup for TCP 53. The choice is yours concerning TCP 53. Additionally, if you want to completely 'Remove' or just 'uncheck' the Global Rule for DNS resolving, you can create an application specific rule for SVCHOST that will handle UDP 53. That way, this traffic will only be associated with the SVCHOST executable which is the proper application to handle the normal DNS UDP 53 traffic. This is a little more advanced configuration and if you would like to do this and are having problems, PM myself or one of the other Moderators or Administrators directly and we will try to help you with this.

NOTE: If you are using the Global Rule for DNS Resolving or even if you have disabled this rule and made an application specific (SVCHOST) rule for DNS Resolving, please further secure your system by adding 'remote hosts' as outlined in this thread:

http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=5552

That is it. Those represent all of the rules that I currently have defined for SVCHOST in the current version of Outpost. Those rules have allowed me to use my system, browse normally, and perform security checks at online scan sites (GRC, Sygate, Kalish, PCFlank, DSL Reports, and Norton) without any rule creation popups for SVCHOST. For your information, I prefer to associate as many rules as possible with applications. The benefit is that you are able to effectively block use of a specific port for an application or a service enabling application, like SVCHOST, without totally blocking port from use by other applications. The fact of the matter is that "a port is a port" and the significance of seeing a port, like UDP 1900, in your connection logs is only relative to the application that is utilizing that port. For example if SVCHOST appears in your logs using port UDP 1900, then it is probably SSDP, but if another application were to use port UDP 1900 it would only be for the purposes of allowing legitimate traffic for that application on UDP 1900 and would be unrelated to the SSDP service.

Further Reading:
Universal Plug and Play and Simple Service Discover Protocol:
http://www.upnp.org/

Thread where TCP port 53 is discussed (read entire thread):
http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=4953

Online Scan Sites
http://www.mycgiserver.com/~kalish/
https://grc.com/x/ne.dll?bh0bkyd2
http://www.pcflank.com/ (under Test Your System, multiple scans)
http://scan.sygate.com/ (multiple scans)
http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=873 (FAQ with scan site list)

Ruleset Proposed by Agnitum
http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=5438
Comments: The proposed ruleset for svchost.exe by Agnitum for the next version of Outpost is shown in Danil's second post to that thread. Note that many of the rules specify a remote host. In reality for normal browsing, that specification will work. But if you are doing online security scans, you may get rules creation popups. After all, you must take care to secure more than the default or standard situations. So, I personally do not use remote hosts in my rules, except of course for the time sychronization rule which handles the Windows Time Service. That rule only contacts one of two remote hosts by default. time.windows.com or time.nist.gov This policy effectively allows me to browse and do online security scans normally while staying in Rules Wizard Policy.

Let me know if you have any questions or issues with any of the information that I have presented in this post.

Have a good morning. :)

[grendizer]

Hi David, thanks for all those tips :D But Svchost is so active on my Win XP, perhaps it is better to allow it for everything? After all, all those services are from Microsoft, they shouldn't be dangerous :)

[David]

grendizer,

My advice to you is to figure out which services are involved and disable them if they are not necessary. Outside of that, the only other advice that I can give you is to start with a new or clean hard drive and install Windows again. It is a mystery why you would have so much service activity. In fact, it is more than a mystery, it is wrong. There is no reason why there should be so much unexplained SVCHOST activity. Discover the reason or reformat your hard drive. That is the best advice that I can give you.

[David]

Try this ruleset for svchost.exe:

[SVCHOST SSDP (UPnP) Connection Rule]
Where the protocol is: UDP
Where the remote port is: 1900
Deny It

This rule will Deny SSDP which is used in conjuction with the UPnP service to setup device and control point communication under the UPnP protocol. So if you use UPnP, then you must enable both this rule for SSDP and the rule for the UPnP service.

[SVCHOST UPnP Connection Rule]
Where the protocol is: TCP
Where the direction is: Inbound
Where the local port is: 5000
Deny It

This rule will Deny the UPnP service which is used in conjuction with SSDP to setup device and control point communication under the UPnP protocol. So if you use UPnP, then you must enable both this rule for the UPnP service and the rule for SSDP.

[SVCHOST Time Synchronization Connection Rule]
Where the protocol is: UDP
Where the remote host is: time.windows.com, time.nist.gov
Where the remote port is: 123
Allow It

Needed for auto time synchronization. Deny It if you do not use this feature.

[SVCHOST DNS UDP Connection Rule]
Where the protocol is: UDP
Where the remote host is: <IP or DNS1>, <IP or DNS2>, etc.
Where the remote port is: 53
Allow It

Required for DNS lookups. If you have problems, try enabling the next rule for TCP DOMAIN and see if it helps. If you are unsure about the IP addresses of the DNS servers of your Internet Service Provider, then do not check the box to specify remote host. Your rule should just read, UDP, port(remote) 53, and allow it. If you use this rule, please uncheck the rule for DNS in the Global Rules. There is no need for two rules allowing the same thing.

[SVCHOST DNS (DOMAIN) TCP Connection Rule]
Where the protocol is: TCP
Where the direction is: Outbound
Where the remote port is: 53
Deny It

Notice that this is TCP and the action is to 'Deny It'. I have not found much use for this rule and have never needed it to browse.

[SVCHOST DHCP (IP Address Acquisition) Rule]
Where the protocol is: UDP
Where the direction is: Outbound
Where the remote port is: 67
Where the local port is: 68
Allow It

If you get an IP address for your PC by DHCP, then this rule is required. If you use a Static IP address then you may not need this rule and you can change the action to 'Deny It'. If you use DHCP and are experiencing difficulties getting an IP, try removing the "direction" from the rule. If you use this rule, please uncheck the rule for DHCP in the Global Rules. There is no need for two rules allowing the same thing.

[SVCHOST RPC TCP Connection Rule]
Where the protocol is: TCP
Where the direction is: Inbound
Where the remote port is: 135
Deny It

[SVCHOST RPC UDP Connection Rule]
Where the protocol is: UDP
Where the direction is: Inbound
Where the remote port is: 135
Deny It

Inbound connections from other hosts to your PC on this port is generally not necessary. The people who require such a connection will know it and can change this to 'Allow It'. If you do not know the purpose of RPC on port 135, DO NOT set these rules to 'Allow It'.

[SVCHOST HTTP Connection Rule]
Where the protocol is: TCP
Where the direction is: Outbound
Where the remote port is: 80
Allow It

[SVCHOST HTTPS Connection Rule]
Where the protocol is: TCP
Where the direction is: Outbound
Where the remote port is: 443
Allow It

The HTTP and the HTTPS rules are sometimes required due to the fact that some of Microsoft's Help features may utilize online resources. Without these rules, some help features in Windows may cease to function. My own preference is to deal with port 80 and 443 requests on a per incident basis or try to define specific remote hosts to secure them a little further. But, defining remote hosts has its negative points also because sometimes the IP address changes for a given URL. My recommendation is that you leave both rules above 'Allow It', 'Deny It' (not preferred), or use the 'Allow Once' or 'Block Once' buttons on a per incident basis and do NOT attempt defining remote hosts for these rules.

[SVCHOST Extended TCP Coverage Rule]
Where the protocol is: TCP
Deny It

[SVCHOST Extended UDP Coverage Rule]
Where the protocol is: UDP
Deny It

These two rules are LAST and should ALWAYS be LAST in the list. They basically deny any traffic, without asking, for any activity that is not defined by the rules above them. That will help eliminate the popups. The negative effect is that if you are experiencing a problem using a necessary service that is enabled by svchost.exe, then you will have to check your 'Blocked' logs to find out what is happening.

If you have read my suggestion in this post Svchost (http://www.outpostfirewall.com/forum/showthread.php?s=&postid=38549#post38549), then you will see some differences between the rules that I wrote there and the rules that I have given here. There is a reason for that. Because of the last two rules in this list, only the activity defined by this application rule will be allowed. This is because the application rule for svchost.exe will take priority over any Global Rule defined. So, I had to add a rule for allowing DNS lookups and also DHCP to rules here in order to allow those activities to take place. The Global Rules for these two items and a few more like RPC are rendered useless by the ruleset above. This ruleset should take care of any SVCHOST enabled service. You will also note that I do not have the rule for denying TCP port 1025 in this ruleset. That is because it is no longer needed based on the last two rules for denying TCP and UDP. In fact, the only rules that are required are the 'Allow It' rules that I have listed here because all other activity will be denied by the last two rules. However, I left in the 'Deny It' rules for SSDP, UPnP, TCP DOMAIN, RPC, HTTP, and HTTPS in the case a user would like to modify the permissions for these specific items. If you have any problems with ANY of the UDP rules, try removing the 'direction' and see if that fixes the problem.

Using the ruleset above, no more popups should occur. Please try them if you have time. And, please ask if you have any problems or questions about the rules or ideas that I have presented here.

Follow-up comments regarding ruleset listed above.

I just wanted to write a quick follow up. I created the rules specified above for svchost.exe. After doing that, I unchecked the Global rules for 'Allow DNS Resolving', 'Allow Outgoing DHCP', 'Block Remote Procedure Call (TCP)', and 'Block Remote Procedure Call (UDP)'. These rules should no longer be required as applications specific rules for svchost.exe were created for the same purpose. Then, I tested the ruleset that I have listed above and only found one issue. When I tried to release and renew my IP address using the IP address from my PC using the 'ipconfig' command in an MSDOS Window, I ran into an old Outpost bug, 'Learning Mode'. I tried the solution of operating Outpost in 'Block Most' Policy, but that did not work. This made my attempt to manually release and renew my IP address futile. However, it did NOT affect my PC's ability to gain an IP address during bootup. My suspicion is that this is due to the fact that Outpost operates in 'Allow Most' Policy during bootup or that DHCP IP Acquisition is happening before Outpost can start, not because the rule is functioning properly during bootup.

What does this mean?

1) Dial-up users may have issues with this ruleset. But, as far as I know dial-up users must start Outpost after logging into their ISP so that Outpost properly registers their IP, so it may not really matter. By the way, this is another current Outpost bug.

2) Broadband users will have to avoid releasing and renewing their IP using the 'ipconfig' command from an MSDOS Window. This should not happen often anyway. If it becomes necessary, a broadband user could place the firewall in 'Disable' mode temproarily for the purpose of manually releasing and renewing their IP using the 'ipconfig' command.

The rules are still worth trying though as this problem only seems to affect manual releasing and renewing of IP Addresses using 'ipconfig' and workarounds have been stated here in points 1 and 2 above. Let me know if you try these rules and have any issues. :)

[Calle]

David.

You wrote:

///////////////////////////
A little extra information.

EXPLORER.EXE

Sometimes Windows Explorer will ask for permission to access the internet. You can follow any of the suggestions, one, two, or three for EXPLORER.EXE. The only difference is the Remote Host and the Remote Port. Here is a rule.
Where the protocol is TCP
Where the direction is Outbound
Where the host is sa.windows.com
Where the Remote Port is HTTP
Allow it OR Deny It, it is your choice or do not create any rule at all like in Setup one for svchost.exe above.

//////////////////////////////////////

I run WinXP pro, and if I try to implement this rule and come to the "Where the host is sa.windows.com", then I do get the error message about "Trying to resolve IP address" and then "Authoritative Answer Host not found".
So I cannot create that rule.

Why is that?
Carl

[MegaHertz]

Carl,

This maybe the problem (see screenshot). You may just want to try a little later.

[Calle]

Thanks, MegaHertz.

Must I be on-line to make a rule?? When I was building that rule I was off-line. I would think it strange if one needs to be on-line.

Carl

[MegaHertz]

Originally posted by Calle
Thanks, MegaHertz.

Must I be on-line to make a rule?? When I was building that rule I was off-line. I would think it strange if one needs to be on-line.

Carl
Ahhh, yes you need to be online so that the name can be resolved to an IP in this case however you can get the IP off of the screenshot I posted.

[Hal]

Thanks David:
I already had your ruleset for svchost and i've modified it following your more recent instructions.
In fact, the only rules i haven't implemented are last two.
I don't think they're necessary just because if outpost has a connection request not specified above, it will prompt and ask me what to do, so, you know, if you add those ones, you feel like if you could just be blocking something it has not to be blocked.
By the way i've got to say no connection attempt has been made, so, with the other rules you cover all the svchost connections.
But the real purpose of this reply is just to say i've implemented that rule using a dial up connection and having outpost running before connecting i encountered no problems to establish connection with my internet provider.
By the way i also unchecked the global rules of outpost dns and dhcp, i wonder if that could make outpost to use less memory...
The test i've run show all ports stealth so, i've got to save, that rule is perfectly safe and usefull, keep on that great work.

[Tom Pachulka]

I must say I've read this thread with great interest!

David, you said that the only real reason svchost.exe should be allowed to establish an internet connection is DNS resolving, and this is handled through Global system rules (for those of us who do rely on global rules). So, I wonder whether adding svchost.exe to Blocked app's list would do the trick?

That is, assuming Global rules take precedence over Application rules (is it true???), DNS resolving would be allowed thru Global rules, and everything else would be blocked at the application rules level. Bingo! No need to add any other rules for svchost.exe!

Or am I missing something?

Thanks!
Tom

[David]

Hi Tom,

Originally posted by Tom Pachulka
David, you said that the only real reason svchost.exe should be allowed to establish an internet connection is DNS resolving, and this is handled through Global system rules (for those of us who do rely on global rules). So, I wonder whether adding svchost.exe to Blocked app's list would do the trick?

That is, assuming Global rules take precedence over Application rules (is it true???), DNS resolving would be allowed thru Global rules, and everything else would be blocked at the application rules level. Bingo! No need to add any other rules for svchost.exe!

No...No...No Don't do that. :)
The rules processing order is:

1. Trusted IPs
2. NetBIOS
3. Application
4. Global

I know that seems backwards, but it is actually an order that I like. That may sound strange and we could have a long conversation about the PROS and CONS, but the processing order that Agnitum uses is legitimate and effective. I do have one suggestion. Do not use the DHCP rule for svchost.exe. Just leave the global rule for that enabled. I have had problems with the DHCP rule for svchost.exe and will let the user's know when I figure out what is happening. I do want to note that I am using a router and users connecting to the internet normally may be able to just leave the svchost.exe DHCP rule and be OK. Try it and see what works in this regard. One last point, plugins are processed in addition to the the rules above. So be advised that even if a firewall rule does not block some traffic, the plugins still may block some traffic depending on how they are configured. We can discuss any of these points here or you can e-mail me through my user profile if any issue needs to be discussed at length.

Have a good day. :)

[guitarhero]

I am running Win2K.


Task manager shows 3 copies of SVCHOST running, though they all appear to be idle.


Is this normal?


Thanks.

[David]

Hi guitarhero,

Originally posted by guitarhero
I am running Win2K.
Task manager shows 3 copies of SVCHOST running, though they all appear to be idle.
Is this normal?
Yes, that is normal. svchost.exe is used to enable many of the system services. So, you will find many entries with this executable. You can get some idea of which services by recording the port number involved. You can find this information in the Open Ports log in Outpost. The, just look up the port numbers on Google or some other search engine. Some services are more difficult to identify than others, but the entries you see are most likely legitimate. If you would like additional information about services on XP and 2000, please see these sites:

Windows XP Services (http://www.blkviper.com/WinXP/servicecfg.htm)

Windows 2000 Services (http://www.blkviper.com/WIN2K/servicecfg.htm)

One tip....On Windows 2000, you can place svchost.exe in the Blocked Applications list as it is not used for DNS and DHCP as it is in Windows 2000. DHCP and DNS are handled by services.exe on Windows 2000.

I hope that helps. Have a good day. :)

[guitarhero]

Thanks David,

I'm feeling reassured :p

I did look at the BlackViper page before posting, but it was over my head, I'm afraid. :confused: Perhaps I need to print out the printer friendly version and take it away for study.

I love this forum and would like to thank you and the other Mods (and posters) for all the advice and hand-holding.

Cheers.

[David]

Hi guitarhero,

Originally posted by guitarhero
I'm feeling reassured :p
Glad to hear that you are comfortable with Outpost and the advice given in the forums.
Originally posted by guitarhero
I did look at the BlackViper page before posting, but it was over my head, I'm afraid. :confused:
I'm afraid too sometimes. ;) It is a slow process. There is a lot to learn about computers. And then you throw in computer security on top of that and it takes a while to learn. Nobody has all the answers. We support each other here and I know that each of us learn something new everyday in this forum.
Originally posted by guitarhero
Perhaps I need to print out the printer friendly version and take it away for study.
I believe that he has a PDF version of his Services List that you can download. You can view it with the FREE Adobe Acrobat Reader.
Originally posted by guitarhero
I love this forum and would like to thank you and the other Mods (and posters) for all the advice and hand-holding.
Thanks very much for the kind comments. I am sure the other Moderator's will appreciate them also.

Have a good day. :)

[hayc59]

guitarhero, its nice to see kind words, its very uplifting!!
i am a noob Mod here and the guys before me do a great job here!! but you are right its a great place........thank you..:D :D :D

[Tom Pachulka]

David,

I entered svchost.exe rules you've outlined in this thread, and I lost my connection to the internet. And here's why: since global rules are always checked last, the Extended UDP Coverage Rule (the one at the end of the ruleset, that blocks all UDP traffic) blocks DNS resolving before the system rule has a chance to allow it!

So, I guess I was right that in theory Global rules should take precedence over application rules... that's why we call the "global" ;-)

Tom

[David]

Tom,

I understand what you are saying. But, if you made a svchost.exe rule to allow UDP 53 and placed it above any deny coverage rule then it would work for you. In fact, that point is impossible to dispute because that is exactly what I do.

By processing Global Rules/general firewall rules first, you run the potential risk of allowing malware to use a port that the global rules allow. But, with application rules processed first, that risk is eliminated. Placing global rules first would represent a security risk, not a realization and submission to common sense on Agnitum's part. Global rules are really meant for internet gateways, large corporate servers, and internet servers where application rules really do not apply as they may interfere with the proper function of those hosts. In the case of Outpost, I look as Global Rules as covering everything that the specific (application) rules do not cover. So, they are processed in the right position...last. They simply offer another way of operating a firewall without Application rules. For absolute personal security, as much traffic as possible should be associated with applications and services and should be tightly monitored. Global Rules make this very difficult and can easily distract users from understanding the true nature of traffic to and from their systems. At some point in the near future, I will be operating entirely without Global Rules and I believe that I will be safer for doing that.

[Tom Pachulka]

David,

I agree with you. If you explicitly allow UDP 53 at the application level, you're OK.

But my point is different. What I'm saying is that with your ruleset, you cannot rely on global rules for DNS resolving. This type of traffic will be stopped at the application level (the last two rules that stop "all other" TCP/UDP traffic), before global rules have a chance to work.

And yes, I agree that global rules should be applied last. Mathematically this makes more sense than the opposite (common sense) approach.

Thanks!
Tom

[David]

Hi Tom,

Originally posted by Tom Pachulka
But my point is different. What I'm saying is that with your ruleset, you cannot rely on global rules for DNS resolving. This type of traffic will be stopped at the application level (the last two rules that stop "all other" TCP/UDP traffic), before global rules have a chance to work.
Ahaaaa... :) I see what you are saying and you have made a valid and intersting point. Adding those last two rules to some applications was an afterthough of mine. I knew that occasionally users had to deal with multiple popups for some applications like file sharing programs and service enabling applications like svchost.exe. So, for those types of applications, I just decided to tell people to make a TCP Deny and UDP Deny rule at the end of the rule list. As you have seen, it is kind of like a per application method of enforcing a 'Blcok Most' Policy while in Rules Wizard Mode. To tell you the truth, if you just use all of the other rules that I have outlined and leave out TCP Deny and UDP Deny, you should never have a problem with excessive popups where svchost.exe is concerned. I just added those last two rules so that I was giving users what I believed to be the safest possible answer. To tell you the truth, I don't even use them myself because I almost never get a rules creation popup for svchost.exe with the rules that I have given. However, I do use the TCP and UDP Deny rules on file sharing applications because they are a problem.

Anyway, as you have already discovered, just leaving off those last two rules will allow processing through Global Rules. :)

[Psiho]

Originally posted by David
Try this ruleset for svchost.exe:



looong time nobody here :)
OK, I'm a newbe. I installed couple of days ago. As every good good newbe :) I read Agnitum FAQ and their recommendations on setting up SVCHOST at http://www.agnitum.com/support/outpostfaq.html#general20

Now I also read this complete thread and am just a bit confused about difference of David's ruleset and Agnitum's ruleset. Now, knowing that you David are defenetly an authority here (number of your posts here is enough hehe) and Agnitum is also... maybe just a short comment on this difference?

Also... I still have Agnitum's ruleset but I had to add rule:
UDP Outbound 239.255.255.250 1900 Allow It
I couldn't connect to my dsl provider without it. This rule is triggered every time I connect/disconnect. And I see you have suggested a rule:


[SVCHOST SSDP (UPnP) Connection Rule]
Where the protocol is: UDP
Where the remote port is: 1900
Deny It


... that actually would block the rule I mentioned and I need. So agnitum forgot it and I kept getting popups, and you denied and I couldn't connect :) ... still unsure what rules to apply :)

regards

[Paranoid2000]

Psiho,

While I cannot claim David's authority on this topic, there are a couple of observations I can make :)

The rule in question blocks Universal Plug 'n Play. This is done by default presumably due to the serious security problems uncovered with uPnP at the time. If, however, you are using a uPnP modem for Internet access (could you please verify this?), then you will have to alter this rule (change it to Allow) - but do check the following articles and ensure you have the appropriate patches in place (especially the second one which is rated Critical):

www.microsoft.com/technet/security/bulletin/MS01-054.asp
www.microsoft.com/technet/security/bulletin/MS01-059.asp

[David]

Hello Psiho,

The IP address that you noted in the SSDP rule originally came from me. In fact you will find that IP in one of my early rulesets in this thread. I have since chosen not to include the IP in my rules. This is because I wanted to completely close this component of the SSDP service for use from any IP. My suggestion is DO NOT use the IP Address in any rules except maybe for DHCP and DNS rules. And, I also generally do not recommend the use of direction in UDP rules. I have already consulted with Agnitum about the UDP rules and expect and answer soon. If you have a UPnP capable router, then maybe you will want to enable the UPnP and SSDP rules so that you can take advantage of the auto-configuration that UPnP offers. If you are allowing this traffic to a suitable router, then you should set the remote IP in the UPnP and SSDP rule to the IP of your router. If you are not using UPnP enabled devices, then set the SSDP and UPnP rules to 'Deny It'.

Further, I recommend that you use the last fully documented set of rules that I recommend for svchost.exe. I do not like the Agnitum rules and plan on writing them about my difference of opinion very soon. In fact, I have a printout of their ruleset on my desk now and am making notes.

If you have any questions, let me know.

Here is a direct link to the latest ruleset posted by me in this thread:
Latest SVCHOST.EXE Ruleset (http://www.outpostfirewall.com/forum/showthread.php?s=&postid=42469#post42469)

Have a good day. :)

[David]

Originally posted by David
Hello Psiho,

The IP address that you noted in the SSDP rule originally came from me. In fact you will find that IP in one of my early rulesets in this thread. I have since chosen not to include the IP in my rules. This is because I wanted to completely close this component of the SSDP service for use from any IP. My suggestion is DO NOT use the IP Address in any rules except maybe for DHCP and DNS rules. And, I also generally do not recommend the use of direction in UDP rules. I have already consulted with Agnitum about the UDP rules and expect and answer soon. If you have a UPnP capable router, then maybe you will want to enable the UPnP and SSDP rules so that you can take advantage of the auto-configuration that UPnP offers. If you are allowing this traffic to a suitable router, then you should set the remote IP in the UPnP and SSDP rule to the IP of your router. If you are not using UPnP enabled devices, then set the SSDP and UPnP rules to 'Deny It'.

Further, I recommend that you use the last fully documented set of rules that I recommend for svchost.exe. I do not like the Agnitum rules and plan on writing them about my difference of opinion very soon. In fact, I have a printout of their ruleset on my desk now and am making notes.

If you have any questions, let me know.

Here is a direct link to the latest ruleset posted by me in this thread:
Latest SVCHOST.EXE Ruleset (http://www.outpostfirewall.com/forum/showthread.php?s=&postid=42469#post42469)

Have a good day. :)

[Psiho]

Originally posted by Paranoid2000
If, however, you are using a uPnP modem for Internet access (could you please verify this?)
:) and how to find this out? All I know is that it's Erricson HM220dp model.

but do check the following articles and ensure you have the appropriate patches in place


That's one of the good things that came with DSL. Windows update. I update almost everything regulary. BTW I think those updates came in SP1 of XP because they're not listed on my installed updates nor detected in scan.

[Psiho]

Thx for your answer David. I changed all my rules to match your advice, but uh man I have questions :)

Originally posted by David
My suggestion is DO NOT use the IP Address in any rules except maybe for DHCP and DNS rules

Q1: in your ruleset you use it also in rule for time synchronizing ???
And, I also generally do not recommend the use of direction in UDP rules
Q2: I've read the thread where you discussed this, but in your ruleset you use it in "SVCHOST DHCP (IP Address Acquisition) Rule" and in "SVCHOST RPC UDP Connection Rule" ???

Q3(comment): in your ruleset for rules like DNS UDP and DHCP you mention (in red) that we should turn of those rules in Global rules. You do not mention that for RPC rules in ruleset but in comment below :) Small thing but did confuse me a bit :)

Q4: something also bugs me and some Agnitum presets for some apps do the same thing. That is f.i. your 2 rules: HTTP and HTTPS connection for SVCHOST. Isn't it easier to combine those rules in one? and separate HTTP and HTTPS ports with comma so we use both in a same rule?
I have already consulted with Agnitum about the UDP rules and expect and answer soon.
Q4: I guess ther's no need to ask this but... will you please post the results of this here? I think I'm not the only one (newbe) who would like to se some kind of consensus on this, because your variations in opinions are much more than "variations" :)
If you are not using UPnP enabled devices, then set the SSDP and UPnP rules to 'Deny It'.

I did. And I don't know how, nor why... but it seems to work and I do not get popus anymore after I connect or disconnect to my ISP.

regards

[David]

Hello Psiho,

Originally posted by Psiho
Q1: in your ruleset you use it also in rule for time synchronizing ???
I know that I put an IP there. Maybe I should have qualified my statement. Any general service, like RPC or UPnP or SSDP for example, should probably not specify a remote host IP if you are not using that service and making a Deny Rule. After all, you want the service port covered for all cases. If you are making a Allow rule for one of these AND YOU KNOW that the service port will only be accessed by certain IP addresses, then it is OK to enter IPs. For example, each UPnP device on your home network, would have an IP and you would use only those in your rules. In the case of the Time Sync rule, the two domains that I listed are the two default domains that Windows XP uses for time synchronization. If you use some other time syncronizing software, you may have to enter the domain or IP address of the host that software uses. Also, for any service that you want to have general access, you might choose not to use a remote IP or host in your rule. Understand? Here is a link to a good tutorial for Outpost rules. It was written for Zone Alarm users, but you may find it generally helpful.

David's ZAP to Outpost Migration Tutorial (http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=4355)
Originally posted by Psiho
Q2: I've read the thread where you discussed this, but in your ruleset you use it in "SVCHOST DHCP (IP Address Acquisition) Rule" and in "SVCHOST RPC UDP Connection Rule" ???
For several technical reasons, direction in UDP rules is a real sticky issue for me. In general, I do not recommend it as in some cases it may cause problems. However, some services like DHCP do seem to work well with direction included in the rule. I am working on understanding this issue at this moment and I may have more to offer within a week. You can try direction in UDP rules if you like, but I warn you that some extra troubleshooting may be involved if you have a problem with one of those rules. If you do choose to use direction in some of your future UDP rules and start having connection problems with that rule, I advise you to keep an eye on the Blocked log which will help you track down any problems and fix them. For now, please create the rules as specified. I will provide more information on this subject as soon as possible.
Originally posted by Psiho
Q3(comment): in your ruleset for rules like DNS UDP and DHCP you mention (in red) that we should turn of those rules in Global rules. You do not mention that for RPC rules in ruleset but in comment below :) Small thing but did confuse me a bit :)
Confuses me too. :) Actually the rules are redundant and you have made an excellent observation. I created these rules so that if a user did not use ANY global rules, they would still have protection. It is your choice whether you want to use the global or application rules for RPC, DNS, DHCP, and other services. You can even leave the redundant application and global rules if you like. It will not hurt anything. In the case of the DNS rules, there are benefits for users of the FREE version of Outpost who exclusively use the application (svchost.exe) rule. The benefit is that you can specify the IP addresses of your ISP's DNS Servers. There is some security advantage for doing that. Please reference this thread for more information.

Making the Default Global DNS Rule More Secure (http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=5552)
Originally posted by Psiho
Q4: something also bugs me and some Agnitum presets for some apps do the same thing. That is f.i. your 2 rules: HTTP and HTTPS connection for SVCHOST. Isn't it easier to combine those rules in one? and separate HTTP and HTTPS ports with comma so we use both in a same rule?
Yes, you can combine HTTP and HTTPS rules. In fact, all TCP rules could be written in one rule and another rule could cover all UDP rules. However, you lose some fine control over your ruleset if you do this. Shutting down the TCP rule would shut down everything and likewise for the UDP rule. The rules are separated for flexibility.
Originally posted by Psiho
Q4: I guess ther's no need to ask this but... will you please post the results of this here? I think I'm not the only one (newbe) who would like to se some kind of consensus on this, because your variations in opinions are much more than "variations" :)
No problem. :)
Originally posted by Psiho
I did. And I don't know how, nor why... but it seems to work and I do not get popus anymore after I connect or disconnect to my ISP.
My guess is that you probably do not have UPnP enabled modem or device. So, that is why it is probably working fine. You would know it if there was a problem. You would see many blocked connections to port TCP 5000 and UDP 1900. If it works, stick with it. :)

I hope that helps clear things up a little for you. :)

Have a good day. :)

[Hal]

David what do you think about agnitum preset for svchost included in outpost 2???

[PrivateEye]

I am warning you, svchost.exe handles many services on an XP PC including UPnP and you are asking for trouble by keeping it in the Trusted Application.

**shiver***:eek:

I second that!
There have been a long line of virus's (like 'Code-Blue') and trojans which attempt to attach themselves to svchost.exe if only because this application is always running. So if you keep it in Trusted Applications the you might as well uninstall the firewall to regain the system resources - because there is no point running it anymore...

[David]

Hello Hal and others,
Originally posted by Hal
David what do you think about agnitum preset for svchost included in outpost 2???
I believe the preset is OK to use. There is no need to change it from the Agnitum default. However, there does need to be a little fine tuning done to that rule to eliminate some redundancies with the global rules and also to address things like the fact that services.exe handles DNS in Windows 2000, not svchost.exe. I will be writing Agnitum about this and one other issue on Friday. I will try to have an updated ruleset, possibly very similar to the last, by Wednesday June 3.

Have a good day. :)

[AtticInsane]

Yes, allow svchost to access the internet and to except connections. this is a windows componet in NT/XP that needs access to browse and to have certain apps perform correctly.

[Paranoid2000]

Windows 2000/NT users can avoid giving svchost.exe (or services.exe) access completely, just relying on Global rules for DHCP and DNS. For Windows XP, though, it does do more (like timesync and uPnP) so most will probably have to have it in Partially Allowed.

[David]

I have one thing to add to that. The executable that handles the DHCP and DNS activity cannot be placed in Blocked Applications. Doing so will result in loss of network connectivity. As a minimum for Windows XP:

1. svchost.exe handles DNS and DHCP on XP. You will probably need rules to handle UPnP and Time Syncronization to avoid rules creation popups. svchost.exe must NOT be blocked.

2. services.exe should not need any rules or can possibly be Blocked.

For Windows 2000:

1. svchost.exe can technically be blocked on this OS. Or, you could create rules as described above. Either way should work.

2. services.exe must NOT be Blocked becaue it handles DNS and DHCP on Win2000. If the Global rules are in place, then a ruleset for this application should not be required.

[David]

Hello,

Since many people come across this thread in their search for answers on how to handle svchost.exe and possibly services.exe, I just wanted to point out that the FAQs forums should be reviewed or searched first for answers to common configuration questions. With regards to svchost.exe, a very good FAQ has just been completed by Paranoid2000. And in that FAQ is included the latest recommendations on svchost.exe and services.exe configuration based on extensive discussion by the forum staff and beta testers. Additionally, that FAQ contains many other fine recommendations on using Outpost to secure your system. So, please refer to this thread for the latest recommendations on svchost.exe and also as a general guide to configuring Outpost to maximize security:

A Guide to Producing a Secure Configuration for Outpost (http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=9858)

You won't be disappointed. ;)

Have a good day. :)