Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: DonZ63 on September 26, 2011, 11:08:58 PM
-
I ask this because I have seen in my event logs that avastsrv.exe being blocked at boot time.
I have also reset the Win 7 firewall to default settings since installing Avast.
-
Yes it does. The Avast service requires incoming to be allowed.
-
Thanks.
BTW - I tried the paid ver. of Sphinx Win 7 Firewall Control. Didn't care for it. When I get time, I am going to try out this new freebie: http://www.neowin.net/news/windows-firewall-notifier-130 (http://www.neowin.net/news/windows-firewall-notifier-130)
-
That new one looks interesting but since it's very new, I expect it to have a few updates so I'll wait a while before trying it. I like that it just uses the default firewall and doesn't use a completely different one in conjunction with the built in one. That should make it much lighter weight.
-
uses the default firewall and doesn't use a completely different one in conjunction with the built in one
From what I have gleaned from the minimal documentation for it, not exactly. It appears it is designed primarily to alert you to an oubound connection and then allow/block it. It then creates its own allow/block rule which cannot be modified. What is unclear is if you create your own detailed firewall rule for an outbound alert, it will create a WIN 7 firewall outbound rule.
As the "firewall notifier" name implies, I think all the software is designed to do is alert you to an outbound connection, you specify allow or block, and then later set up your own WIN 7 firewall rule and delete the rule Firewall Notifier generated.
At least it should provide good leak protection.
-
There should be no need to add or remove anything to the windows firewall in default settings for avast.
Uninstall avast then reset your firewall and reinstall avast and things should work as they are supposed to, no exclusions neccessary unless you enable outbound protection in the windows firewall.
-
Yes, but if you enable outbound protection in the built in firewall, it is very complicated to manually set up rules allowing it for apps since it will then block everything, including things like Windows Update. From what I read about the firewall notifier is that it greatly simplifies the process by first enabling the outbound protection and then alerting you when attempts are made and letting you decide what to do from there. It then creates rules in the Windows firewall based on your decisions. The Win7 Firewall Control is actually another firewall built on top of the existing one and using the same API's but it does a pretty good job, even in the free version, which is what I'm currently using.
Like I said, the notifier app looks interesting and I may try it out when it matures a little more.
-
There should be no need to add or remove anything to the windows firewall in default settings for avast.
I agree that Avastsvc.exe does not require an inbound exception in the WIN 7 firewall since the WIN 7 firewall automatically handles inbound localhost which is needed for avastsvc.exe to function. In fact allowing avastsvc.exe inbound access is dangerous since any external inbound TCP port 80 activity should be the result of a oubound connection under stateful inspection criteria.
Exceptions to the above would be P2P activity.
There is the question about browser activity since outbound TCP port 80 activity from the browser should be blocked since that activity is being done by avastsvc.exe. I think I saw occasional TCP port 80 leakage from IE8 when I was using Comodo as my firewall which caused me to block TCP port 80 outbound from IE8.
-
There should be no need to add or remove anything to the windows firewall in default settings for avast.
I agree that Avastsvc.exe does not require an inbound exception in the WIN 7 firewall since the WIN 7 firewall automatically handles inbound localhost which is needed for avastsvc.exe to function. In fact allowing avastsvc.exe inbound access is dangerous since any external inbound TCP port 80 activity should be the result of a oubound connection under stateful inspection criteria.
Exceptions to the above would be P2P activity.
There is the question about browser activity since outbound TCP port 80 activity from the browser should be blocked since that activity is being done by avastsvc.exe. I think I saw occasional TCP port 80 leakage from IE8 when I was using Comodo as my firewall which caused me to block TCP port 80 outbound from IE8.
It doesn't seem to require an exception in the Windows Firewall but it certainly does in any other firewall you use. I had to allow incoming for the Avast service in both the PC Tools firewall and in Win 7 Firewall Control. I see no reason to block browser activity though.
I have uninstalled Win 7 Firewall Control and I'm trying the Firewall Notifier. There have been a few glitches so far. It did not recognize connection attempts by Ventrilo, a popular voice chat program used by gamers in particular, and I had to manually create an outgoing rule. It also is not allowing Windows Update to connect so I'll have to find the solution for that.
UPDATE: For some reason the Firewall Notifier app does not automatically allow Windows services like Windows Update, Windows Time, etc. to connect and does not give a notification when they attempt to. I fixed it by creating a rule to allow outbound for C:\Windows\System32\svchost.exe and now everything works as it should. The author of the program says that he has a new version almost ready to release that should fix the problems.
-
This for me is somewhat strange, as inbound connections that are associated with the outbound connection are generally allowed back in without being molested. e.g. if avastSvc.exe makes an outbound connection request, its associate inbound response should be let in.
Essentially there should be no occurrence of an inbound connection to/for avastSvc.exe if it didn't originate the original outbound request.
-
This for me is somewhat strange, as inbound connections that are associated with the outbound connection are generally allowed back in without being molested. e.g. if avastSvc.exe makes an outbound connection request, its associate inbound response should be let in.
Essentially there should be no occurrence of an inbound connection to/for avastSvc.exe if it didn't originate the original outbound request.
All I know is that the PC Tools Firewall says that Avastsvc.exe is attempting to behave as a server (which means incoming connection attempts) and you have to allow that. The Win 7 Firewall Control alerts to incoming so you have to choose "enable all" for it. My XP machine has an exception in the XP firewall to let avastsvc through. The Win 7 firewall seems to handle it differently or maybe Avast is now on it's trusted list so it's allowed automatically.
-
Yes it has to act as a server as it is intercepting browser calls to connect to the internet so that traffic can be routed through the localhost proxy.
You click on link or type in URL in the Browser
> redirect to Web Shield proxy
> Internet
< Web Shield proxy
< redirect to browser cache
displayed in browser.
So it is handling outbound connection request and subsequent inbound connection response. That is very loosely what a server does.
-
UPDATE: For some reason the Firewall Notifier app does not automatically allow Windows services like Windows Update, Windows Time, etc. to connect and does not give a notification when they attempt to. I fixed it by creating a rule to allow outbound for C:\Windows\System32\svchost.exe and now everything works as it should. The author of the program says that he has a new version almost ready to release that should fix the problems.
Here's the scoop on svchost.exe on Vista and WIN 7. You have to create outbound rules for the container services that handle win updates and time resolution at a minimum or allow just svchost.exe by inself like you did once the firewall outbound protection is enabled. If you look at the default outbound rules, you will see default rules for DNS and DHCP so you don't have to create additional rules for those.
Now in the XP days, that is all you needed to allow svchost.exe to work and give you maximum protection from svchost.exe dial-outs from malware using it to run their own container services.
WIN 7 appears to use svchost.exe for other things that I haven't fully checked out yet. It also has something called "hardening" that MS states prevents malware from running it's own container services although I fully don't buy it. You will get a warning when try to create svchost.exe container service rules stating "hardening" feature and you really shouldn't create individual svchost.exe service rules.
I guess MS considers Google updater services OK since they run under svchost.exe and you won't even know it!
-
Here's the scoop on svchost.exe on Vista and WIN 7. You have to create outbound rules for the container services that handle win updates and time resolution at a minimum or allow just svchost.exe by inself like you did once the firewall outbound protection is enabled. If you look at the default outbound rules, you will see default rules for DNS and DHCP so you don't have to create additional rules for those.
Now in the XP days, that is all you needed to allow svchost.exe to work and give you maximum protection from svchost.exe dial-outs from malware using it to run their own container services.
WIN 7 appears to use svchost.exe for other things that I haven't fully checked out yet. It also has something called "hardening" that MS states prevents malware from running it's own container services although I fully don't buy it. You will get a warning when try to create svchost.exe container service rules stating "hardening" feature and you really shouldn't create individual svchost.exe service rules.
I guess MS considers Google updater services OK since they run under svchost.exe and you won't even know it!
What I don't understand is why the Firewall Notifier program did not alert for svchost trying to connect. It's supposed to give alerts about all outgoing connection attempts. I have so far found three things it doesn't alert for. Ventrilo, the game DiRT3 (it does alert for incoming but not outgoing, and the Games for Windows Live framework. I had to manually makes rules for those and in the case of GFWL, I had to look at the outgoing block log of the Notifier app to see what needed to be allowed. It was the LiveID component. Windows Firewall Notifier is a very new application and I'm sure it will get better in time.
UPDATE: There is a new version of the Firewall Notifier out, v1.3.2 and all the problems are fixed. It now notifies for all outgoing connection attempts like it should.
-
I never and never did put avast! on any Windows Firewall on any pcs i ever used... So i dont think you need to add something to it. No matter what versions of avast! or Windows.
Mr.Agent
-
The exception for Avast was added to the exceptions in my XP firewall automatically.
-
Here is a link to the outbound rules one person created for his system: http://npr.freei.me/firewallrules.html (http://npr.freei.me/firewallrules.html). BTW - this link does not work on my home PC but I connect fine to it at work - go figure. Note this should be used as a rough guide only since this person for example uses OpenDNS as his DNS provider. It is a good example for rules for svchost.exe. Note that his AV is MSE and that requires a rule for the BITS container service.
Next is a link to what I consider is the definitive lay person tutorial on everything about the WIN 7 firewall: http://sourcedaddy.com/windows-7/understanding-windows-service-hardening.html (http://sourcedaddy.com/windows-7/understanding-windows-service-hardening.html). This tutorial is written is non-techo babble found on the MS TechNet site. The two sections I recommend on ready first are 'Understanding Windows Service Hardening' and 'Understanding (Firewall)Rules Processing.' Note that the WIN 7 firewall does not process rules like most of the popular firewalls in existance today. These firewalls process rules in a top down fashion.
Best to leave WIN 7 outbound default rules in place till you really know what you are doing. Just add rules for your existing outbound Internet applications; primarily anything that requires updating. This would include Avast applications that perform virus definition updating plus the avastsvc.exe program and the like. Finally your browser if using Avast's web shield would have to allow optionally outbound TCP from any local port to localhost(127.0.0.1) remote port 12080. I say optionally since it appears the WIN 7 firewall will allow all outbound activity to localhost unless specifically overridden. You will also have to include rule for https activity TCP from any local port to remote port 443 for your browser.
-
I pretty much think that's gibberish and overkill. If you enable the outbound blocking in Win 7, it's not easy to manage things and you definitely have to make an outbound rule for svchost since Windows Update, Time, and probably a few other things will not work without it. If you leave the Firewall in it's default state where all outbound is allowed, then of course you don't need to do anything. The Firewall Notifier greatly simplifies the handling of outgoing connections and should be a part of the Firewall to begin with in my opinion.
That chart of rules is the very one I used to create rules that would let Windows Update and Time function. With the updated version of the notifier, it now detects the attempt of svchost to connect and lets you choose how to handle it. I tested it by deleting the rules I had created manually and then accessing Windows Update. It detected the connection attempt and I chose to allow it. To simplify my rules, I just accepted the default rule it created that allows all outbound connections. I don't think I need any specific rules for specific services and/or ports. That's just overkill in my opinion.
-
I don't think I need any specific rules for specific services and/or ports.
I think it is important to understand how malware has evolved over time. Malware today hides itself. The days of firing up Task Manager and looking for strange proceses running are long over.
Windows OSes have always included what I call "spawners." Simply put these programs have the ability to create other processes on demand. However, the sub-processes run under the identity of the name of the creator processes. Hence, the occurance of multiple svchost.exe processes running anytime you view running processes in Task Manager. There are other spawners like svchost.exe most notably rundll32.exe that require periodic examination.
As I stated previously, WIN 7 has tightened up the criteria under which the spawners can execute. However, malware creators are very clever and ability to create new exploits is always present. Then there is the issue of what I call "grey" applications. Grey applications are programs created from legit vendors that are used for analyzing your computer activity for commercial purposes aka non-malicious spyware is how I classify them.
Unfortunately, only a few firewalls have the capability of recognizing and controlling spawning processes. Most are commercial firewalls. The only retail ones that I know of is Vista and WIN 7 firewalls plus PrivateFirewall. I tried to install PrivateFirewall on my WIN 7 installation and it was disaster.
Summing this up if a person is really concerned about undesirable outbound activity, spawning processes cannot be ignored. One alternative is to force each subprocess to be shown indivdually as a separate svchost.exe for example entry. The WIN 7 command run from a command prompt window with admin privledges is SC Config servicename Type= own. To restore original state use the same command with Type= share. Ref: http://commandwindows.com/sc.htm (http://commandwindows.com/sc.htm)
-
I don't think I need any specific rules for specific services and/or ports.
Pertaining to ports, the fundamental tenant of outbound firewall creation is restrict outbound activity to specific portocols, ports, and ideally IP addresses or if not possible, at least domain URLs. Simply put, the easiest way to determine if a "legit" outbound application is not really legit is to observe it using non-standard http/https ports or connecting to malicious/questionable IP addresses.
Forget using digital certificates as a failsafe way of determining is an application is legit. Digital signatures are being hacked every day.
-
I don't think I need any specific rules for specific services and/or ports.
Pertaining to ports, the fundamental tenant of outbound firewall creation is restrict outbound activity to specific portocols, ports, and ideally IP addresses or if not possible, at least domain URLs. Simply put, the easiest way to determine if a "legit" outbound application is not really legit is to observe it using non-standard http/https ports or connecting to malicious/questionable IP addresses.
I have never done that with any firewall I have ever used and never had a problem. Like I said, I consider that overkill. I have no idea what other things use svchost besides Update and Time and I certainly don't want to have a different rule for each one of them. Considering the fact that the huge majority of home computer users are sufficiently protected by the default state of the Windows Firewall and a good AV product(especially if they are connected through a router), I often wonder why I even concern myself with having more than that since I have been on line since 1999 without a single infection. I was on dial up from 1999 to 2004 and never even used any kind of a firewall at all. I only had first McAfee and then Norton AV and they caught every attempt that was made.
-
Considering the fact that the huge majority of home computer users are sufficiently protected by the default state of the Windows Firewall and a good AV product(especially if they are connected through a router),
I agree with you 100% on this one. This main point is if you are protected by a good router or modem/router combo with a built-in firewall. The router should also have NAT, statefull inspection, and IPS protection in the form of denial of service attack protection. Note however that router safety no longer can be taken for granted. Millions of existing routers are susceptable to DNS rebinding exploits. Mine was hacked with this. Resolved it by creating a "honeypot" server on my router to trap those rebind attacks.
If a user does not have a router, then all versions of Windows Firewall would not be adequate since they could be hacked via a DoS or DDoS attack. Also with NAT missing, their actual sending ports would be exposed.
Again outbound firewall protection is really only protection against yourself. If one keeps their PC free of malware and practices safe Internet usage, outbound firewall protection is redundant. Unfortunately, the first thing the average young PC user installs is peer-to-peer software that exposes his PC to the world.
-
I finally got around to installing Windows Firewall Notifier. Got to say I am impressed by this little app. Does everything that the WIN 7 outbound firewall processing is missing. The WIN 7 world needs to really find out about this gem.
I also see the problem with limiting svchost.exe. WIN 7 appears to use it network wise for a lot more than Win Updates and Time Updating. Probably if you want to limit its services you will have to create create firewall rules for all the netsvcs items shown in Task Manager plus any application update services such as Adobe Reader, etc. A lot of work. Probably just allowing everything is OK due to the "hardening" WIN 7 firewall applies. One still has to periodically examine what services are loaded to determine if an "undesireable" exists.
I did get an answer to the stange rundll32.exe dial-outs have been experiencing. Appears WIN 7 is dialing out on port 443 to MS servers periodically. What it is doing is beyond me but I suspect it has something to do with run statistics and the like MS is harvesting. Need to research that more. I did change the WFN rule to only connect to the MS server IP range. You definitely don't want to give unrestricted outbound access to rundll32.exe.
I also tightened up my IE8 rule to only connect to TCP 21, 443, and 12080. You really want to eliminate any port 80 outbound activity from your browser if you are using Avast's web shield.
-
I have not gotten any notice for rundll. Is it included in the default rules? I don't use WebRep or anything else like it though.
If you open up Notifier again after it's activated, you can see all of the default rules of the Windows Firewall and there are quite a few allowing outbound connection for svchost. Why Windows Update and Time weren't included is a mystery to me. Making them break when you enable the outbound protection makes no sense to me at all. In my opinion, Microsoft needs to look at the Firewall Notifier and at least consider adding it's functionality to the Windows Firewall.
I looked in the Task Manager just now and it doesn't show a single instance of svchost running. I always had multiple ones in XP. It did come up momentarily when I went to Windows Update but disappeared again as soon as WU was fully loaded. I guess this is part of the hardening they speak of?
-
I looked in the Task Manager just now and it doesn't show a single instance of svchost running. I always had multiple ones in XP. It did come up momentarily when I went to Windows Update but disappeared again as soon as WU was fully loaded. I guess this is part of the hardening they speak of?
Sure doesn't sound right to me. You should have multiple instances of svchost.exe running at any given time. Remember that only a few svchost.exe services require internet access; most run on localhost only. You sure you are not filtering out the display of them in Task Manager?
I will be posting in the next couple of days, the svchost services my WIN 7 x64 SP1 requires. I really should charge for this info since no where on the web could I find details on this.
In the meantime, a FYI:
I have found a somewhat "brute force" method of determining what svchost service is executing when a popup alert is generated by WFN. This works for WIN 7 x64 SP1. I also assume it will work for XP and Vista.
Note: Before adding any firewall rule for a svchost.exe service, determine that the service is a valid Windows or application generated service. Also remember that the service might be valid but intrusive e.g. Google update service, etc.
Allowing the svchost.exe service to execute as noted below could cause a leakage of data from your PC if the service is malicous. At present, I know of no way to determining what service requires outbound access until it does a network transmission. If the developer of WFN can figure out a way to display the short service name of a blocked svchost.exe request, he would have found the "Holy Grail" of Windows sub-tasking in my opinion.
1. Keep the WFN popup visible on the desktop and note the IP address and port shown.
2. Open a command prompt window as admin.
3. Enter the following minus the quotes after the command prompt - "netstat -anob". Do not press the enter key yet.
4. Click on the Allow button on the WFN popup for svchost.exe. Immediately thereafter press the keyboard Enter key to execute the netstat command that was previously entered.
5. Scroll up in the command prompt window searching for the original blocked IP address. Once found, you will observe to left on the same line, the short name of service that svchost requested.
Note that netstat command will most likely display the program name that called svchost.exe. Therefore, you will not see the service short name listed under svchost.exe but under the calling program name.
6. Open up Task Manger and click on the Services tab and search for the full service name associated with the short name that was displayed as a result of the netstat command.
7. Delete the global allow firewall rule for svchost.exe that WFN generated.
8. Create a new WIN 7 firewall custom outbound rule for svchost.exe selecting the above appropriate service. For protocol I always use TCP and for destination/receiving ports I always use 80 and 443.
-
Like I said in the other thread at ghacks, There are default rules in the Firewall allowing svchost to connect to ports other than 80 and 443 and using protocols other than TCP. The one I made for my home network had to allow all ports since I'd allow one and the next time a different one would come up. I even got one for port 0. I allowed all ports but restricted the IP's to the ones created by the router for the 3 different computers connected to it.
I still have no instances of svchost showing in Task manager .AHH wait, I didn't have "Show processes by all users" checked. With that checked there are 11 instances of svchost running. None have given any alerts though except for Update, Time and elements of my network.
-
I just posted an new inquiry on why avastsvc.exe is listening on port 135 and using svchost.exe RpcSs services on the Internet. This in spite of the fact I have it set to "connect to web known browsers" only?
-
Had my first hiccup with WFN today. I was fooling around with my MBAM firewall rules and did something WFN didn't like. The result was .Net error everytime I opened WFN. Error was something to do with corruption in the WFN log file.
I tried to fix by uninstalling retaining my rules and settings, then deleted the WFN folder and restored it from the download. Still a no go. Then I shut down the PC for a while and when I rebooted later, magically WFN was fine. Go figure?
I did find out something in my testing that I asked Avast about and received a contrite answer to the issue. If you have web shield configured to check all outbound connections, it bypasses all Windows firewall outbound processing in the .1289 version! So I guess if you trust Avast which I do not, then you don't have to do anything in regards to Windows firewall outbound processing. Just run web shield with full outbound connection scanning.
-
Why would you not trust Avast? I also don't completely understand what you mean when you say Avast bypasses all outbound rules. Do you mean while you're in the browser or at all times? I definitely get alerts for other applications trying to connect and I have the web shield set to scan everything so, it's not completely bypassing outbound rules. I'm not sure what "scan only well known browser processes" means so I haven't selected that option.
-
I don't trust any "free" software. My mother taught me as a young boy that "there is no such thing as a free lunch." Now I am not implying anything malicious but stuff like spy and adware. More so in these tight economic times when everyone is scrambling to make a buck. That is my personal opinion.
As far as Avast web shield goes, first ensure that web shield is set to filter all outbound connections i.e. the "well known web browser" box is unchecked. Next select an application that connects to the Internet, update is what selected, and for which no output firewall rule exists. You can also just disable one of your existing outbound firewall rules for updating. Then perform an update action for that software. On my PC, the update succeeded. No blocked activity and no firewall alert from WFN.
My theory is web shield in this .1289 ver. is actually operating as a firewall and has some how turned off portions of the WIN 7 firewall.
-
Well the web shield doesn't actually filter outbound connections, neither does it scan outbound content. It only redirects outbound http traffic through its proxy, so that the corresponding inbound traffic is also routed through the proxy and scanned.
So no it isn't acting as a firewall, the network shield monitors outbound connections in the fact it compares the domain against its malicious sites list.
-
I retested the web shield issue this morning with the same result. If it is set to filter all outbound connections, the Win 7 outbound firewall rules are bypassed. My theory on this as you pointed out, Avast web shield is running a proxy server on localhost, 127.0.0.1. By definition, proxy servers bypass firewalls creating in effect a "tunnel" connection. I don't know if this affects all firewalls but it most certainly does the WIN 7 firewall with outbound filtering set on.
As far as web processing goes, running a proxy server is fine. That is as long as you trust the proxy server. However for non-web outbound processing, the proxy is a security risk in that it is overriding the firewalls outbound rules.
I also would like to know what protection web shield provides. If all it is doing is checking IP addresses, I don't need it. I use MBAM PRO whose IP blocker is more effective in tests I have performed.
-
Most firewalls are smart enough to know what is using the localhost proxy. It shouldn't be creating any tunnel as you would surely already have a rule to allow avastSvc.exe that controls the shields, including the Web Shield and the localhost proxy.
You really should check out the avast help file as the web shield 'doesn't check IP addresses' so the MBAM IP checking doesn't hold a candle to what the web shield does (apples and oranges, chalk and cheese). See image extract of a little on the web shield in the avast help center/file.
-
select an application that connects to the Internet, update is what selected, and for which no output firewall rule exists. You can also just disable one of your existing outbound firewall rules for updating. Then perform an update action for that software. On my PC, the update succeeded. No blocked activity and no firewall alert from WFN.
I have experienced that same behavior with 3rd party firewalls that replace the Windows one. What I have determined is that some applications that update by connecting through IE (taking you to a web page like CCleaner does) will not produce an alert if there is a rule already in place that allows outgoing for the browser. Other applications that connect directly to a server without going through a web page first (MBAM for example) will always produce an alert and a corresponding rule will be created, but maybe not with the Web Shield checking everything.
-
What I have determined is that some applications that update by connecting through IE (taking you to a web page like CCleaner does) will not produce an alert if there is a rule already in place that allows outgoing for the browser.
Thank you! CCleaner being able to connect w/o an outbound firewall rule was driving me crazy. Was just about to e-mail the WFN developer about a leak on CCleaner.
However, what I stated previously about applications that do not do updating via a browser still stands. I have tested with both MBAM and SpywareBlaster both of which have stand alone updaters.
-
This applies to WIN 7 only.
If you are using only a IPv4 router, I see a major issue with the WIN 7 firewall core inbound and outbound rules. They allow Teredo which is a tunneling IPv6 to IPv4 protocol. Numerous exploits to date have been documented with IPv6 to IPv4 tunneling. I have blocked both inbound and oubound rules. For additonal protection I have also added rules to block the IPv6 protocol(type 41) for all connections both inbound and outbound.
Your choice.
BTW - IE8 now runs much better by the way.
-
My new router is IPv6 capable where my old one wasn't. My ISP however, is not using IPv6 yet at all. Do you think I should still need those rules?
A question--why IE8 on Win7?
Update:--I found that I can't make a blanket rule blocking IPv6 because it still keeps giving alerts when things get blocked and that's too annoying. What I did was hit block when the alert came up for an IPv6 connection. That put the application in the exclusions list meaning it would now be blocked without a popup. I had a rule allowing connections for TCP and UDP and the program still connects that way but now blocks IPv6 attempts only.
I also found that DonZ is correct about the Web Shield. With the shield scanning everything,I deleted my MBAM rule and then tried to update it. It was in need of updating and it connected and started updating with no complaint from WFN. The strange thing was that when the downloading was almost finished, then the popup showed telling me that the connection had been blocked! The connection had already been made successfully. I then tried it with scanning known browser processes only and a big window immediately came up saying that the connection could not be made along with the WFN popup saying it had been blocked. No connection to the MBAM update server could be made until a rule was created allowing it. I can only conclude that the web shield does indeed bypass the Windows Firewall outgoing blocking (if it is enabled of course) if it is set to scan all traffic.
-
This applies to WIN 7 only.
If you are using only a IPv4 router, I see a major issue with the WIN 7 firewall core inbound and outbound rules. They allow Teredo which is a tunneling IPv6 to IPv4 protocol. Numerous exploits to date have been documented with IPv6 to IPv4 tunneling. I have blocked both inbound and oubound rules. For additonal protection I have also added rules to block the IPv6 protocol(type 41) for all connections both inbound and outbound.
Your choice.
BTW - IE8 now runs much better by the way.
IE9 is much better than IE8 on Win 7.
The 10 Best New Features in Internet Explorer 9
http://www.technobuffalo.com/internet/the-10-best-new-features-in-internet-explorer-9
-
DCH keeps asking me about the acceptabilty of letting svchost run unfiltered for outbound network processing. Remember Conficker? Below is it's high-level operational write-up.
[Edit] BTW - new strains on Conficker are back in the wild. So much so Sophos has a new scanner/removal tool for it.
This is just one of a multiple of malware that have used svchost in the past. My opinion is that the lack of svchost.exe protection is the "dirty little secret" of the third party retail firewall industry.
A Static Analysis of Conficker
Like most malware, Conficker propagates itself in the form of a packed binary file. Our first step in analyzing Conficker consists of undoing the work of the packers and obfuscators to recover the original malware binary code. Conficker is propagated as a dynamically linked library (DLL), which has been packed using the UPX packer. The DLL is then run as part of svchost.exe and is set to automatically run every time the infected computer is started. After unpacking, we find that the UPX packed binary file is not the original code but incorporates an additional layer of packing. We use IDA Pro to remove this second layer of obfuscation and dump the original code from memory. To do so, we first run the Conficker service, snapshot the core Conficker library as a memory image, and from this code segment reconstruct a complete Windows executable program. The program requires a PE-header template, and we compute an entry point that allows the program to enter Conficker's code segment. This appears to be a clever way of making the analysis of Conficker a bit more challenging than usual. We now describe the static analysis of the original code, which reveals the full extent of the malware logic and capabilities.
Ref:http://mtc.sri.com/Conficker/