ho usato outpost
ti riporto link e spiegazione accurata per lo SVCHOST.EXE, devi valutare tu che servizi chiudere e agire dic onseguenza, per esempio s esinconizzi l'orologia, l'ascerai aperta quella porta, altrimenti no.
http://www.agnitum.com/support/onlinecomunity.html
http://www.outpostfirewall.com/guide/rules/system.htm
New Ruleset Recommendation for svchost.exe 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, 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.
__________________