Avast Web Shield - changed/fixed?

Regarding the problem the Web Shield component was having with several outbound firewalls... was this problem fixed?

I'd heard through the grapevine that they were changing the way it was deployed altogether (no longer was a proxy). Is this true? And if so did it happen yet?

I've got all these extra resources just laying around on this new/old box, and I'm itching to use them. Even considering going back to using a real-time AV, and a fully featured one at that, with URL scanning and all. But I want to make sure I won't run into this problem.

Thanks.

 

No, it still uses the same model in v8 (i.e. transparent local proxy).

 

I appreciate the honesty, being aware of who you are and all. Oh well, I was never a big fan of web scanning anyway. I've yet to meet one that didn't cause a noticeable slowdown (to some degree, even if slight). And feel the File Shield would nab it anyway, though perhaps at a later entry point. Running Sandboxie, it would nab it before I recovered it, which is the only entry point that matters to me.

And since I use Pidgin Messenger quite a bit these days, and had someone recently attempt an exploit on me through it (to no avail), the idea of an IM Shield is attractive to me as well.

And I've always liked the Network Shield, and have yet to use it since the Script Shield was introduced, but would like to give it a look.

 

From a security standpoint would you consider it acceptable to turn off the Avast Web Shield and have the firewall monitor the traffic instead? Are there any other shields where this is an issue?

 

I think the idea of having to turn off an avast shield is totally preposterous and im sure if avast felt it was a total problem they would simply have removed it from v8.
The web shield is an important part of the total protection package and turning OFF modules is weakening the protection offered.
It is only the outbound function of firewalls that have been affected so if your machine is clean then the question becomes totally irrelevant.

 

Yes, you've stated this before, but I'm not sure it's the only way to go. Having an opinion that the system is clean is pointless - we are in large part relying on the security software to tell us that. The primary reason for using a third party software firewall instead of Windows Firewall is outbound protection, so using a function such as Web Shield which bypasses the firewall is not irrelevant.

 

By continuing to use both your protection could end up being weakened in the end... if both conflict with each other you could end up with NEITHER product properly protecting you in the end. So my advice would be to only use one or the other. The choice if of course yours. I definitely cannot live without outbound filtering. Web scanning on the other hand, I do live without just fine, and even thrive without.

And I don't see why Avast would ditch something that's been around for so long, and become such a staple, even knowing about this conflict. That doesn't mean they don't consider it a viable concern. Nor will outbound FW vendors ditch outbound protection over it. It's up to end users to be aware of such conflicts and decide on how to handle it accordingly.

I also think it's faulty logic that outbound filtering is rendered moot if you have no malware. You never know when a Windows service even, like svchost.exe, will become vulnerable to an exploit that needs patched with next Tuesday's batch. Most of those patches you see that say "this could allow a remote user to compromise... blah blah blah" can be prevented with a tight outbound filtering regimen. And I personally don't know what Explorer is trying to do, connecting out every time I try to install something, but I don't like it, or trust it. Can you assure me it isn't sending out any user info? How about other apps/processes, even ones generally trusted? If it's not necessary for what I need to get done, I don't allow it. I know plenty of apps that are generally trusted in here that do strange things by monitoring them with my outbound FW & HIPS. Things that aren't necessary... connecting out, sending pings home (CCleaner does it with every install), setting hooks. Just not the type of ship I like to run.

I'll gladly sacrifice web scanning to keep those measures intact. With SBIE, NoScript, D+, DNS filtering, WOT, VTzilla, and VT Hash Check scanning new files anyway... I'm more than covered anyhow.

Also I'm pretty sure Avira's Web Guard has the same problem. They also deploy a proxy in an identical manner... or at least did back when I used it. Using Port 44080 if I recall.

I'm not sure if MBAM Pro utilizes their URL scanning in a similar manner or not. If not, and you want web scanning, that's the route I'd go.

 

Totally irrelevant to your setup, perhaps. Obviously if one is trying to control outbound (including Windows 7 built in firewall where the issue exists as well), it's quite relevant.

 

@Kirk Reynolds.
Did you even read my post correctly..?
Please read it again before replying with attitude.If the system is clean and your certain that there are no malicious call outs then outbound control need not be a concern unless your some sort of control freak.
If outbound control were such an issue like you CLAIM it to be then microsoft would have implemented this feature.

 

Did you read mine?

Who said outbound control was such an issue, you?

I said: "Totally irrelevant to your setup, perhaps. Obviously if one is trying to control outbound (including Windows 7 built in firewall where the issue exists as well), it's quite relevant."

The merits to whether controlling outbound is beneficial or not has nothing to do with my statement. Whether it's good, bad, redundant, or useless, the fact remains that it's quite relevant to others other than yourself.

You have no idea what my or anyone else's setups are, including software installed and policies in place, nor any idea of everyone's views about outbound control. Thus it is irrelevant to your setup, but it's obviously relevant to others.

 

@Kirk Reynolds.
I was simply trying to outline why outbound control may not be needed and i did not expect a barrage of personal criticism.Would you please refrain from this and just stick to the issue in hand.I appreciate your comments and they are correct but please respect mine on this.
Regards.

 

If one runs a clean/tight ship... then web scanning is not needed. If you use NoScript, and have other means like DNS filtering, not to mention that your File Shield would snuff out anything anyway... though perhaps 2 seconds later.

After I posted my hardened Web Browser rules for Comodo I had a few people PM me showing me traffic they noticed that was now being blocked that wasn't prior when they had simple allow all outbound rules (very common with trusted apps... what you're doing if you have no outbound FW). Now in a perfect world you like to think/hope it's legitimate traffic, doing legitimate things. But do you really know? Some of it looked downright shady... phoning home. And I'm talking about apps that are well respected in here. I'm talking in fact about essential things, web browsers, IE, Firefox, & Chrome. I've hardly met an app that didn't try to take some liberty like this, no matter how trusted. And I don't put 100% trust behind anything, so I block it if it's not essential. In every case the person said their browser worked just fine denying the traffic.

On the other hand... a Web Scanner would have blocked a grand total of 0 things for me since moving to XP 8 years ago. And even if that came to an end, I'm a closed browser away (thanks to Sandboxie) from snuffing it out.

So which one sounds more useless given that scenario?

I do not hand trust out so easily... only to a certain extent. Do what you need to do, and nothing more. And I allow only that via outbound & app control. Who knows how much privacy I've retained as a result over time... how much info. that otherwise would have seeped out along with those random connections to remote/Google servers. If you're fine with that, then so be it. It's also protects against exploits. In case the next patch doesn't get there soon enough, if it has no door to come in and can't piggy back onto any apps/processes because you run a Paranoid HIPS, it's SOL.

 

The problem is that there is at least a dozen of svhosts. If Outpost or any other FW asked me to allow svhost tomorrow, I know I would.

 

I wouldn't... chalk another one up in favor of XP over newer OS's. I have only 2 instances of svchost running right now, and none of them need internet access granted for anything to function properly on my box.

Only exception being once a month when I update Windows, I allow it manually for only those ports/protocol/IP's needed. Then afterward put a block rule for svchost back in place for the next 30 days. Everything works fine.

Just an example of the increasing number of concessions one has to make with each new OS, and the added attack surface that comes along with it.

Using outbound filtering/app control in this manner can take an OS that already has the attack surface of a flea and even put armor on the flea and prevent it from being exploited. And with WehnTrust you can add ASLR & SEHOP to XP system wide... combined with Hardware DEP always on. And with no .NET FW, Java, or PDF in my case, that surface gets even smaller. Best of both worlds = tiniest attack surface possible + protection against exploits, which granted becomes kind of moot at that point but hey, I like it.

Really I think Hardware DEP (AlwaysOn) is the most important by far. The app specific mitigations provided by EMET, on their own, (i.e. Heap Spray, ROP) won't do much. But combined with AlwaysOn Hardware DEP, becomes more than the sum of it's parts.