Local proxies impeding firewall protection (on Windows 7 at least)

In case anyone isn't familiar with recent events, some people discovered that the installation of avast 7 interfered with the operation of their firewall and prevented their firewall from blocking traffic in the way they desired and expected. Based on my casual wanderings and readings (which have included the Comodo forum thread http://forums.comodo.com/firewall-help-cis/comodo-firewall-and-avast-7-t82382.0.html ) I believe the problem scenarios discovered thus far are:

Windows 7 + Comodo Firewall + avast7
Windows 7 + Private Firewall + avast7
Windows 7 + Windows Firewall + avast7

A post from yesterday suggests there may be at least one more:

Windows 7 + Windows Firewall + avast6

I think this a case of avast manifesting a pre-existing shortcoming in the way certain firewalls selectively block traffic on some operating systems such Windows 7. Avast hooks the networking stack to put its Web Shield in the position of a local proxy so that it can inspect and block traffic on some web related ports. It appears that some firewalls may not have enough visibility or control over things to cope with that local proxying.

Since there could be other software programs that establish a local proxy in way similar to that used by avast and perhaps even other firewall/OS combinations that have shortcomings, I thought I'd post this.

 

This is a bug in Avast Web Shield. They should not interfere with other products, or maybe the only firewall that works with their Web Shield is their firewall from the Internet Security package. This makes sense. You like the free version, you buy more.

All you can do is to disable Web Shield or to set it to scan only the common internet browsers. But in this way, the browser traffic is not filtered anymore by your firewall.

 

I haven't seen evidence that this is related to a bug in avast software. If you have, I would appreciate a link to the information. Just because software A interferes with Software B doesn't mean that software A is at fault.

Might the avast7 changes which exacerbate this issue have been made with the knowledge that it would break some other firewalls and therefore possibly increase adoption of the avast7 firewall included package? Maybe, maybe not, I truly don't know.

However, the point I made remains the same I think. If a software package can, inadvertently or intentionally, degrade the performance of a firewall that people are expecting to protect them, then that firewall has a shortcoming (which may be related to OS shortcomings). The firewall manufacturer, together with OS manufacturer if necessary, should work to eliminate that shortcoming. Meanwhile, users should stay abreast of developments and make whatever adjustments they need to in order to maintain the protection they were trying to achieve in the first place.

 

I suspect that Avira's WebGuard does something similar: you allow it in your firewall (obviously) and from that point all or part of the traffic that Avira's WG monitors is allowed by your firewall. When I disable the WG I get popups from my firewall that I never get otherwise.

 

That does sound consistent to me. If I may ask, what firewall and what OS? What happens if you allow Avira WG, block your browser, then attempt to go to an Internet site with that blocked browser?

 

Privacyware's Privatefirewall and Windows XP32 SP3. If I block IE or FF I cannot access internet. But when I check the rules in the firewall I can see that IE has a whole set (probably by default) and Firefox just two, maybe set by me when answering popups while browsing with the WG off. If I switch Avira's WG off and open Firefox, Privatefirewal ask me to set the new rules. So I am browsing everyday without those rules, Avira seems to act as the effective browser for Privatefirewall.

With one exception: when I try to access a ftp page I get "PF has blocked outgoing TCP (6) packet from _________ to _________ (ftp)", even with the WG on.

 

I'd have to play with Avira WG in order to fully appreciate what you are saying, but now that you elaborate it doesn't sound as though it is causing your firewall to fail to block something it should. Contrast the behavior you see with the behavior described in that Comodo thread, or the related bug report at https://forums.comodo.com/bug-repor...ocked-applications-with-avast-7-t82440.0.html .

Regarding your ftp comment, I would look at what ports the Avira WG is configured to proxy. I would be slightly surprised if something called a WebGuard proxied FTP (which has nothing to do with the "web", even though some web browsers have FTP client functionality built into them).

 

So, you're saying that if I make a video player and after you install it you discover that it broke the capability of Windows Media Player and Windows Media Center to play video files, is not a fault in my software ?

The same applies here too. Avast Web Guard should not interfere with another firewall products, or at least after it inspects the web traffic it should redirect it back to the firewall filter.

 

I would want to know more about how and why the installation of your software interfered with WMP before commenting on whose fault it is. In keeping with this:

Fault (noun)
1) A defect or imperfection; flaw; failing; error or mistake
2) Responsibility for failure or a wrongful act; a misdeed or transgression

I would first try to assess things from a "technical correctness" point of view. When doing this I would try to look at each piece of software in isolation (disregard the interference issue) and focus on whether there is a bug or inherent shortcoming of some sort. I would next try to assess things from a "liability" point of view. I would consider the fact that AffectorSoftware in some way adversely impacts AffectedSoftware, but I would consider the legitimacy of what it is that AffectorSoftware is doing.

Example: The installation of SoftwareFirewall breaks the operation of ApplicationProgram that must communicate with a remote host in order to function correctly. Lets assume that both programs are bug free and for example there isn't a bug in SoftwareFirewall where it continues to block this application even when there is an allow rule for ApplicationProgram. Is SoftwareFirewall "at fault" in the sense that it *must or should be fixed* to never block ApplicationProgram? I think everyone including you would answer NO and agree that there is no one that needs to fix anything.

Why would one answer NO to that but YES to the subject of this thread? One answer comes to mind and that is in the example just above the adverse interference is (or should be) expected by and desirable to the user who installed the AffectorSoftware. I am willing to acknowledge that aspect but before asserting that avast has stepped over some line and done something that they must or should fix, I'd like to see some evidence that what they are doing is "wrong" from some other point of view. I'm inclined to think and assume, until I see evidence to the contrary, that avast is for example using published OS APIs in an appropriate manner to provide legitimate WebShield type behavior and although this causes certain problems for certain firewalls it is not yet proven to be wrong design or implementation. For all I know, the changes made in avast7 (which exacerbate this issue) were actually wise changes from a WebShield implementation point of view.

According to a Comodo developer named egemen (see https://forums.comodo.com/beta-corn...mer-preview-t83044.0.html;msg592815#msg592815) "Because CIS operates at NDIS layer i.e. the lowest layer of the protection, it sees the actual connection i.e. avast proxy. Normally CIS should have blocked the loppback area connection to the proxy however because of the limitations in Windows 7, it fails.". I can't provide verification of that, and I don't know if the other affected firewalls are also pointing the finger at some change and/or limitation in Windows 7. Point is, we can't simply blame and demand changes from avast if the root cause is elsewhere. If the root cause is elsewhere, avast making changes might be convenient for users but it won't actually address the underlying problem that could be manifested by other software including malware.

Just to keep things clear, I think "Web Guard" is the Avira parallel an earlier poster mentioned and I haven't heard of it interfering with firewall products. What is known to interfere with some (but not all, which is interesting) firewall products is the avast "Web Shield". The problem is this isn't just a simple case of redirection, but rather a case of redirecting application connections to a local web port proxy which in turn creates *its own* connections to the remote servers. Traffic from an application which is redirected to WebShield is sent by the application. Subsequent related traffic from WebShield to the remote servers is sent by WebShield.

 

No firewall other than one that is integrated with the AV as part of a security suite supplied by the AV vendor will able to see what is behind a local proxy as all web traffic will appear to be coming from the proxy. Other AVs that use local proxies for web filtering include Avira and NOD32 on Windows XP. One of the issues that local proxying raises is the inability to create specific firewall rules for individual applications.

There is no good reason for using a local proxy for web filtering on Vista or Windows 7 as WFP can be used instead. ESET changed NOD32 to use WFP instead of a local proxy on Vista and Windows 7, but it appears that some other AV vendors are still using local proxies.

 

Being a Windows firewall user I've been looking at this and although I don't use any of these AV products, It's not a happy feeling that something can make holes through the firewall, without a great deal of effort.

Having read the thread at the Comodo forums and the related thread at Avast, I did a few tests and I can confirm that both Avast and Avira, via their respective web proxies, allow any application, making a connection over HTTP, free access. Even when the applications are blocked or don't have rules of their own.

I also tried Comodo, as I used to use their product and it seems only Avast 7 has a similar effect to that seen with the Windows firewall. When using Avast 6 and Avira AV premium 2012, it was possible to prevent applications from making connections with appropriate rules.

According to the developer at the Avast forums, Avast 7 now uses WFP, whereas Avast 6 did not.

 

Well, all web traffic *leaving the machine* will appear to be coming from the proxy. There is still the question of visibility and blocking prior to the proxy.

I just ran a few double checks on an XP machine running Comodo Firewall and Avast 6 with WebShield enabled. I can allow FF and IE while disallowing AvastSvc.exe so as to indirectly block FF and IE. I can also allow IE and AvastSvc.exe while disallowing FF so as to selectively block just FF. In an attempt to determine what Comodo is doing, I then created two rules for FF: allow out to localhost port 12080 followed by deny all out. FF was able to load a remote page. This makes me think that Comodo does not have a filter tap above the point where AvastSvc.exe performs its redirect (Comodo doesn't actually see the attempt to connect to a remote host) but Comodo does see the attempt to connect to the proxy's listening port and blocks that. So it gets the job done. On this platform at least. Supposedly not on Windows 7 with avast 7 for some reason.

Heimdall's post has reminded me about that WFP comment in the avast forum (I forgot about it). FWIW, I think this is the one in question: http://forum.avast.com/index.php?topic=93953.msg759534#msg759534:

"we have changed one driver in the v7. We abandoned the old and not supported TDI interface and started to use the new one (well, its already a few years old, but still newer) - WFP. I bet this is why Comodo has now troubles filtering our proxy requests and while at the same time allows traffic from the avastsvc.exe (where WebShield is hosted) these things together create that hole. I would love to help Comodo understand the method we currently use and help them change the firewall in such a way that they are able to see and block that - should I be contacted by anyone. The method we use is fully supported and documented and from several meetings with other companies I know for sure there are several (if not many) major products out there that use the same - so I guess such fix in Comodo will help not only Avast users but also many others."

Based on a subsequent comment by lukor in that thread:

"are you guys setting any rules for the localhost communication. since it is actually the connection between the browser and Webshield that you want to control and it is between 127.0.0.1:xxxx and 127.0.0.1:12080"

I think although there was some change to WFP there is still a redirect to local proxy. As for whether that is appropriate given what avast's WebShield does, perhaps that would be appropriate to discuss in that avast thread.

PS: Heimdall, what OS were you testing under?

 

I have to wonder if these comments regarding WFP are really just something of smoke screen or maybe I'm misunderstanding what's being said.

According to lukor, the reason he suspects Comodo firewall is failing, is the belief it's using the TDI for it's drivers, but according to the Comodo developer, their firewall uses the TDI, WFP and NDIS, so something's missing there. Then there's Windows 7 firewall, which apparently has had this 'problem' forever, and yet, it too uses the Windows Filtering Platform.

As far as Windows 7 firewall is concerned, it's this localhost communication that seems to be the real issue. From everything I've seen, it's actually not possible to prevent this kind of connection, with this firewall.

Windows 7

 

The issue isn't whether the firewall is using WFP, it's whether the AV is using it for web filtering or relying on a local proxy instead.

 

So, if Avast is using the WFP API for their web filter/proxy that's the problem? If so, we already know they are.

 

If Avast is using WFP as you say, they must have implemented it in a different way to ESET because there shouldn't be a firewall problem if implemented correctly.

For example, with NOD32 if Firefox makes an outbound connection on Windows 7, a third-party firewall such as Comodo will see the connection as originating from firefox.exe. But on Windows XP, Comodo will see all connections filtered by NOD32 as originating from the NOD32 proxy, ekrn.exe. The difference is that on Windows 7, NOD32 does its filtering via WFP and on Windows XP it uses a local proxy.

 

I'm just repeating the worda of the Avast developer, referenced in the posts above.

[/quote]For example, with NOD32 if Firefox makes an outbound connection on Windows 7, a third-party firewall such as Comodo will see the connection as originating from firefox.exe. But on Windows XP, Comodo will see all connections filtered by NOD32 as originating from the NOD32 proxy, ekrn.exe. The difference is that on Windows 7, NOD32 does its filtering via WFP and on Windows XP it uses a local proxy.[/QUOTE]

Thanks for the clarification. Personally, I'm only looking at the relationship between Windows 7 firewall and these web-shields/proxies provided by the AV suppliers. From what I've seen so far, Windows 7 firewall is unable to block connections using either Avast web shield or Avira web guard.

The story seems to be a little different with third party firewalls on Windows 7. I've only looked at Comodo, which seems able to block connections in all cases, other than with avast 7. From what I've read, other firewalls fair differently.

 

The Firewall is at fault if the Firewall can be bypassed, or is unable to see the connections or communications, or

unable to enforce the Firewall Rules. Any application that can install an Local Proxy, regardless to the legitimacy

of its archatecture and actions, and exists the ability to bypass the Firewall, that ability is equal to the adverse

actions of hacking/cracking thus leaving the Firewall at fault, or perhaps the developer of the Firewall?


I just installed an brand new steel door on my house with an heavy duty deadbolt, double lock, and security chain.
Problem is, when the wind blows, the cold air leaks in through the bottom and sides of the door.
The wind blowing is an legitimate element, with legitimate actions, the door was professionally installed.....


HKEY1952

 

FWIW, I took a very quick glance at Windows Filtering Platform. I noticed that it provides support for "Permit/Block" type filtering at various layers but also supports Callouts which can be used to provide more sophisticated processing including manipulation of traffic. Which would seem to reinforce the "it is more a question of how WFP is used" idea. It may be that avast simply switched from hooking and redirecting things via TDI to doing the same via WFP while attempting to reuse the balance of their existing (local proxy) code as is. Based on a quick look it appears to me that avast also redirects mail related connections to port 12025 so that MailShield can provide email scanning [on the clear side of a MailShield provided secure connection with the remote mail servers]. Possibly, there could be even more local proxying involved. Which I mention to promote awareness. I think the appropriateness of avast's approach is an interesting and relevant question, but this topic issue transcends that.

I don't have time to research & confirm everything, but today I was trying to imagine why for example XP+Comodo+avast6 and Win7+Comodo+avast6 function adequately but Win7+Comodo+avast7 doesn't. Running with the idea that the "savior" is Comodo being able to see and block the connection from the application to the local proxy's listening port, what provides that ability remains in Win7 but was broken when avast switched from using TDI to WFP. So one hypothesis is that when WFP is used as a means to redirect to a local proxy, that somehow bypasses Comodo's mechanism (TDI maybe?) for seeing and blocking the local traffic.

The local proxy scenario only presents a problem if the firewall can't see, identify the immediately previous sender of, and block traffic in all the right places you would want it to. It sounds as though the "pure WFP approach" might eliminate that issue in the sense that various pieces of software can utilize WFP to perform filtering and whatever while still allowing a final stage firewall filter to identify through some API call the very first sender of data (the application). IOW, it sounds as though those WFP utilizing components *might* be entirely transparent to the firewall. If that is true (?), then although the firewall would be able to block selective applications it would not be able to recognize and block the WFP utilizers. Is Microsoft taking us from one insufficiently fine grained filtering scenario to another?

 

I wasn't challenging what you said about Avast using WFP. I don't know Avast myself and I'm sure you are right in what you say.

The only point I was making is that if Avast also uses a local proxy for web filtering, the local proxy will necessarily create an insurmountable loss of control for any third-party firewall.

For anyone who wants to be able to see network traffic and set packet filtering rules on a per application basis, the choices are: either switch to an AV that doesn't use a local proxy OR upgrade to the AV vendor's security suite where the integrated firewall will have access to the inner workings of the local proxy OR turn off web filtering in the AV in order to restore full firewall control. All downloaded files will get scanned by the AV anyway so, although there is some additional risk in not using the AV web filter, an AV web filter isn't essential.

 

The packet filtering capability of the firewall isn't being bypassed; it simply sees all traffic as having originated from the local proxy that the AV is using. The firewall isn't at fault because it's a consequence of how firewalls and local proxies work.

Providing the firewall has a HIPS module, there is no opportunity for a bypass because the HIPS will see when an unknown application tries to make an outbound network connection, or tries to inject itself into the memory space of a known application that is allowed outbound network access. The HIPS will then either raise an alert prompting the user for a decision or silently block the attempted connection according to a predefined policy, depending on how it is configured.

What is true is that that once the initial connection has been allowed by the user, all outbound network traffic initiated by the application will be reported by the firewall packet filter as originating from the local proxy used by the AV, which makes it impossible to set firewall packet filtering rules on a per application basis.

 

Interesting: The little "Windows 7 Firewall Control" (Free Edition) - http://www.sphinx-soft.com/Vista/index.html - works flawlessly with Avast 7 (and 6). All outbound rules made by Windows 7 Firewall Control are blocked when Avast's Web Shield is activated.

 

This is because W7FC from Sphinx uses a different packet filter. The discussion here was about Windows Firewall and Windows Filtering Platform.

 

@homeless_sapient: Are you testing Avast 7 and Windows7FirewallControl on Windows 7? If so...

Was your browser able to connect with a remote website via *HTTP* when:

1) AvastSvc.exe outgoing was allowed but your browser outgoing was blocked?
2) Your browser outgoing was allowed by AvastSvc.exe was blocked?

Can you successfully block your browser from connecting to localhost:12080 (Avast Web Shield listen port)?

FWIW, I just took a quick look at the Windows7FirewallControl site and noticed two things at http://www.sphinx-soft.com/Vista/faq.html:

"Windows7FirewallControl is based on Windows Filtering Platform (WFP) completely".

"Web browser set with LanOnly can connect worldwide.
The antivirus (AV) online network monitoring produces the unexpected behavior. Modern AVs are very nifty and trap web browsers and e-mail clients "inside" PC before the applications reach real network address on-the-fly. The applications (browsers/e-mail clients) interact with an AV related services locally and real network interaction goes through (in the name of) AVs as the result. Local traffic is important vitally mostly, expected safe and permitted by many predefined firewall rules. Disabling AV online monitoring disables the traffic trapping. The applications will issue the traffic directly and can be controlled/disabled normally after that. DisableAll set to the applications disables the local traffic only otherwise."

This seems to describe a limitation in blocking browser traffic when the AV is redirecting to a local proxy (what this thread is about). At the moment I don't understand why that description begins with the first sentence pertaining to LanOnly. In any case, I think I would do some extra testing given that it seems to be warning about something on topic.

 

@TheWindBringeth:

Avast 7 & Windows7FirewallControl / Windows 7 64 bit:
1)
AvastSvc.exe outgoing-incoming is allowed & Browser outgoing-incoming is blocked --> The Browser is blocked INDEED.
2)
AvastSvc.exe outgoing-incoming is blocked & Browser outgoing-incoming is allowed --> The Browser is NOT blocked.
«2)
AvastSvc.exe outgoing-incoming is blocked & Browser outgoing-incoming is allowed --> The Browser is PARTIALLY blocked. Isn't blocked for certain sites. For example Google sites (search, gmail, maps) or hup.hu are working. Other sites don't work.

The free edition Windows7FirewallControl of doesn't let me block ports and other fine tunings, but:
1)
AvastSvc.exe outgoing-incoming is allowed & Firefox outgoing-incoming is blocked --> Entering localhost:12080 in the addressbar of Firefox --> Instantly: "Unable to connect".
2)
AvastSvc.exe outgoing-incoming is blocked & Firefox outgoing-incoming is alowed --> Entering localhost:12080 in the addressbar of Firefox --> After 15-20 seconds loading attempt ("Connecting to localhost…" is statusbar): "The connection has timed out".
3)
AvastSvc.exe outgoing-incoming is allowed & Firefox outgoing-incoming is allowed --> Entering localhost:12080 in the addressbar of Firefox --> The browser loads instantly an empty page (the about:blank page), and only after 15-20 seconds shows "The connection has timed out", when in the addressbar "http://localhost:12080/" is replaced with "http://www.localhost.com:12080/".

Otherwise my opinion is, that Avast is incorrect. They shouldn't break W7's Firewall functionality.