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

[TheWindBringeth]

Originally Posted by homeless_sapient

Avast 7 & Windows7FirewallControl / Windows 7 64 bit:
1) AvastSvc.exe outgoing-incoming is allowed & Browser outgoing-incoming is blocked --> The Browser is blocked INDEED.

That's good. The interesting question would be: why?

a) Blocked because Windows7FirewallControl see's Firefox attempting to connect to a remote host?
b) Blocked because Windows7FirewallControl sees Firefox attempting to connect to local port 12080 (after the Avast redirect)?
c) Blocked because Windows7FirewallControl is blocking Firefox's other use of local ports?

Originally Posted by homeless_sapient

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.

I think the desired behavior would be for everything to be blocked. The "it depends" part is curious. As you probably know, Avast doesn't redirect HTTPS connections to the local proxy. So if the sites that are working are, for whatever reason, being fetched via HTTPS it might make sense.

Regarding the localhost stuff, it sounds like domain guessing (browser.fixup.* config settings) is coming into play. If you ever want to you can disable that and/or go the pretend-to-be-a-browser route via telnet.

Thank you very much for testing and sharing info. It is interesting that Windows7FirewallControl is doing at least some blocking that some other firewalls aren't. If Comodo doesn't address this issue on Win7 via their newer version, I may take a look at it myself.

[noobian]

Thanks to TheWindBringeth and others for the discussion, and to pegr for simplifying the practical implications so that even a noobile could understand.

Originally Posted by pegr

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.

A couple questions...I'm trying to choose lighter realtime protection to go with Sandboxie once my KIS license expires. Is the web filter the only known Avast/Avira process interfering with the Windows or Comodo FW's? And, given a choice between deactivating web filtering on Avast or Avira and using MSE - which I don't think uses a web filter at all, but also seems to have a lower default protection rate than Avast or Avira (when they have web filtering enabled), which option would you suggest? In other words, how much is, say, Avast's webshield likely to contribute to its detection rate (in independent testing)?

[homeless_sapient]

@noobian: The web shield of Avast AV interferes with Comodo FW and Windows 7's built-in firewall. I haven't tested Avira paid version, but the free Avira has no web shield-like component and doesn't conflict with Comodo FW and Windows 7's built-in firewall. MSE is working fine with Comodo FW (but I personally don't like MSE). Another solution would be Comodo IS (with its own antivirus), but Comodo's antivirus feels me a little buggy. "Avast AV + Windows7FirewallControl" is a really lightweight couple, but in this case of course you loose the proactive force of Comodo FW.

[homeless_sapient]

@TheWindBringeth: I've tested the Plus version of Windows7FirewallControl. It's much more advanced with a lot of features. There is a "Check AV Hook" option for every program. In the case of my web browsers this feature gives this message: »The applications traffic is processed by AV online protection or VPN. All the traffic is hooked/redirected by AV/VPN via localhost (127.0.0.1) and issued worldwide in the name of the AV/VPN. Enabling localhost for the applications enables the applications worldwide.« But – as I'd said – : the AvastSvc.exe allowed + Browser blocked --> The Browser is blocked for EVERY sites (http, https and for ftp also).

[TheWindBringeth]

@homeless_sapient: I like the idea of a firewall actually checking for and reporting such a scenario. Do you have to exercise the program and cause it to generate traffic before you are given that message?

Given the FAQ, this "Check AV Hook" feature, and the message you shared I'd say the author is bending over backwards to draw user attention to the type of scenario we're talking about where the firewall doesn't have enough visibility to explicitly recognize and block a client's outbound connection attempt to a remote server when there is a redirect to local proxy. It sounds as though this firewall may *indirectly* block such client connections *if* it is configured to block the client's *localhost* traffic. Bear in mind though that some users may want to allow localhost traffic while blocking Internet traffic.

IMO, it would be wise to verify that the firewall can not only block vanilla connections to localhost ports but also the unique scenario where a connection attempt to a remote web server is redirected to localhost:12080 (Web Shield). I would use telnet for this because it doesn't talk to itself via loopback like Firefox does. I would first make sure that Avast's option to scan traffic from well known browsers only is disabled. Then I would block localhost (or all traffic) for telnet. Then see what happens when:

1) telnet localhost 12080 (or telnet localhost <some other local listening port>)
2) telnet www.google.com 80

Both connection attempts should be blocked. Hopefully this makes sense.

[homeless_sapient]

I'm not a network expert like you, but I've tried your proposal:
Avast's option to scan traffic from well known browsers only is disabled (default setting). Than:
1)
AvastSvc.exe traffic enabled + Avast Web Shield started + Microsoft Telnet Client traffic blocked ––> "telnet localhost 12080" and "telnet www.google.com 80" cannot open connections.
BUT:
2)
AvastSvc.exe traffic enabled + Avast Web Shield stopped + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" cannot open connections; but "telnet www.google.com 80" can initialize connections.
HOWEVER, other scenarios:
3)
AvastSvc.exe traffic enabled + Avast Web Shield started + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" and "telnet www.google.com 80" both can initialize connections.
4)
AvastSvc.exe traffic disabled + Avast Web Shield started + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" cannot open connections; but "telnet www.google.com 80" can initialize connections.
5)
AvastSvc.exe traffic disabled + Avast Web Shield stopped + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" cannot open connections; but "telnet www.google.com 80" can initialize connections.
6)
AvastSvc.exe traffic disabled + Avast Web Shield stopped + Microsoft Telnet Client traffic disbaled––> of course "telnet localhost 12080" and "telnet www.google.com 80" cannot open connections.

SO:
"telnet localhost 12080" initialites connection in the 3) scenario only.

[noobian]

Originally Posted by homeless_sapient

@noobian: The web shield of Avast AV interferes with Comodo FW and Windows 7's built-in firewall. I haven't tested Avira paid version, but the free Avira has no web shield-like component and doesn't conflict with Comodo FW and Windows 7's built-in firewall. MSE is working fine with Comodo FW (but I personally don't like MSE). Another solution would be Comodo IS (with its own antivirus), but Comodo's antivirus feels me a little buggy. "Avast AV + Windows7FirewallControl" is a really lightweight couple, but in this case of course you loose the proactive force of Comodo FW.

Thanks, h.s.!

By the way, I noticed that one of the devs on the Avast forum had said they plan to stop using a local proxy for the web shield. He didn't say roughly when, of course..

[TheWindBringeth]

Originally Posted by homeless_sapient

I'm not a network expert like you, but I've tried your proposal:
Avast's option to scan traffic from well known browsers only is disabled (default setting). Than:
1) AvastSvc.exe traffic enabled + Avast Web Shield started + Microsoft Telnet Client traffic blocked ––> "telnet localhost 12080" and "telnet www.google.com 80" cannot open connections.
BUT:
2) AvastSvc.exe traffic enabled + Avast Web Shield stopped + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" cannot open connections; but "telnet www.google.com 80" can initialize connections.
HOWEVER, other scenarios:
3) AvastSvc.exe traffic enabled + Avast Web Shield started + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" and "telnet www.google.com 80" both can initialize connections.
4) AvastSvc.exe traffic disabled + Avast Web Shield started + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" cannot open connections; but "telnet www.google.com 80" can initialize connections.
5) AvastSvc.exe traffic disabled + Avast Web Shield stopped + Microsoft Telnet Client traffic enabled ––> "telnet localhost 12080" cannot open connections; but "telnet www.google.com 80" can initialize connections.
6) AvastSvc.exe traffic disabled + Avast Web Shield stopped + Microsoft Telnet Client traffic disbaled––> of course "telnet localhost 12080" and "telnet www.google.com 80" cannot open connections.

SO:
"telnet localhost 12080" initialites connection in the 3) scenario only.

My thoughts...
1) OK
2) OK *if* for telnet you were blocking localhost connections while allowing off machine connections. A nice idea to experiment with Web Shield disabled.
3) OK
4) Hmmm. If correct, a possible explanation: With AvastSvc.exe traffic disabled the firewall sees/blocks the vanilla connection attempt to localhost:12080, does not see/block the connection attempt redirected to localhost:12080, also does not see/block the off machine connection attempt initiated by Web Shield.
5) OK
6) OK

FWIW, I *used to* routinely write networking software mostly for non-Windows systems. Knowledge fades with time but I think I can still make meaningful observations/comments at some levels. When it comes to the internal characteristics of the Windows stack, exactly how software hooks into it, and the behavior of such hooks/filters, I can't go far. So for example with #4, someone who does have good exposure to WFP and other internals would likely be able to explain exactly why that behavior does or doesn't make sense.

At the end of the day the important question is whether YOU understand the behavior, limitations, etc of the firewall you are using. At least at a higher level so that you know what it can/cannot do and thus have some certainty about how your configuration will work. You are thinking of things on your own and seem comfortable running tests of interest. So I suspect you have gotten a feel for things and may ferret out more. If I may ask, what if anything do you find confusing?

[itman]

This is the upteenth time I have posted this.

If you don't want leakage from your browser HTTP connection using Avast web shield, you first have to change the existing browser HTTP firewall rule from allow to deny.

Then you must create two rules for avastsvc.exe.

1. TCP outbound local port any, remote port 12080 remote IP 127.0.0.1
2. TCP outbound local port any, remote port 80 remote IP any.

With Avast web shield active all outbound browser HTTP TCP port 80 traffic is done by avastsvc.exe.

[homeless_sapient]

@TheWindBringeth: Thank you for your detailed and patient responses.

@itman: Hm, in Comodo FW your advice just doesn't work. The different web browsers cannot be blocked separately. Window7FirewallControl easily does this. This is not a trivial problem. Not only the web browsers but also some messenger programs and other softwares are hooked by this interesting Avast feature.

[TheWindBringeth]

@homeless_sapient: What happens if you:

Test1) Generally allow things but for AvastSvc.exe block TCP out destination localhost:12080

Test2) Generally allow things but for AvastSvc.exe block TCP in destination localhost:12080

?

[homeless_sapient]

@TheWindBringeth:
1) Generally allow things but for AvastSvc.exe block TCP out destination localhost:12080
2) Generally allow things but for AvastSvc.exe block TCP in destination localhost:12080
–––> Same results for 1) and 2): The browser cannot access the web sites, except for a couple like google.com, yahoo.com, hup.hu…

I'm sorry for not having replied to your question. I forgot it. My goal is to imitate the Windows7FirewallControll blocking rules in Comodo. I would like to use an Avast7-Comodo combo with the possibility to block the internet access of CERTAIN applications through web shield.

[TheWindBringeth]

@homeless_sapient: Well thanks for sharing some info and good luck with that effort. Let us know how you make out.

[luciddream]

Originally Posted by Heimdall

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.

And I can corroborate these findings as well. I was just about to say the same thing. And I saw someone mention that the free version of Avira wouldn't have this pitfall because WebGuard doesn't come with it. But doesn't it now come with it via an optional toolbar?

The first thing I thought when I saw the OP was: "I bet Avira has this problem as well", because I knew it's WebGuard works in a very similar, if not identical manner. And I believe it used port 44080 for that proxy, for the record.

In my post not long ago about AV's "increasing your attack surface", this is the exact type of thing I was talking about. I even mentioned that port in particular for people to glance at via "netstat -an" for scenarios such as this.

Stuff like this only reinforces to me how much happier I am without a real-time AV. Increase my attack surface, cause conflicts, slow my box down, and chew on my HD... and never find a thing for that trouble.

I would only use MSE, or the AV as part of the suite for whatever 3'rd party FW/HIPS I used. No such conflicts this way. To me that peace of mind is far more important than a few percentage points on some test using subjective sample sizes.

[gdiloren]

I'm shocked at how poor support there is at Avast, Avira and even Comodo on this "Proxie problem". They throw the ball for "future" updates (next one? in six month? next year?). I left AVAST and Avira webguard and I'm using the Comodo suite. You have to learn but it then comes natural!...

[homeless_sapient]

Originally Posted by gdiloren

I'm using the Comodo suite. You have to learn but it then comes natural!...

@gdiloren: I'm in a similar situation to use Comodo AV instead of Avast . Comodo Firewall and Defense+ are really smart and powerfull, but the antivirus component from their Internet Security suite is a somewhat buggy: http://www.wilderssecurity.com/showp...9&postcount=70

[itman]

itman: Hm, in Comodo FW your advice just doesn't work. The different web browsers cannot be blocked separately.

It worked for me when I had Comodo 5 and Avast 6 installed. I believe the web shield proxy is identical in Avast 7.

First, Avast web shield needs unrestricted access to locahost address 127.0.0.1 not just port 12080. Comodo monitors localhost 127.0.0.1/255.0.0.0 activity.

When Comodo is installed it will create an entry in Network Zone called "Loopback Zone" I believe. That is localhost.

Next take a look at the default rule for your browser that Comodo generated. Note that the first rule is "Allow Access to Loopback Zone." You need to duplicate that rule and make it your first firewall rule for AvastSvc.exe. Your second rule for AvastSvc.exe is as I original posted:TCP outbound local port any, remote port 80 remote IP any.

Finally move the AvastSvc.exe rule you just created or modified above any existing browser application firewall rules. Remember Comodo's firewall executes rules top to bottom. If the AvastSvc.exe is below your existing browser rules, those browser rules will be executed first and override the AvastSvc.exe rule. Actually the Avastsvc.exe rule should preceed all your rules that use TCP outbound port 80. As I stated in my original posting, many things silently connect though your browser that you are not aware of e.g. SpywareBlaster updates.

[itman]

I'm shocked at how poor support there is at Avast

First, I am no Avast fanboy. In fact, I don't even have their product installed on any of my installations.

However if you need help, please get it though the appropriate Avast forum section. I am so-so on their products but i have never encountered such experienced and curteous help as I received from members there.

In contrast to the ignoramous trolls who prowl the Norton forums that need to sent to the deepest part of hell

[TheWindBringeth]

Originally Posted by itman

It worked for me when I had Comodo 5 and Avast 6 installed. I believe the web shield proxy is identical in Avast 7.

Avast: "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. "

Comodo: "The issue is avast intercepts WEB connections at the driver level and redirects connections to its own local proxy. 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. CIS uses TDI, WFP and NDIS to provide its firewall functionality. WFP maybe enough ti implement an average firewall but it is not enough for a firewall like CFW so that it could not be used alone wihtout the support of the other 2 technologies. Windows 8 allowed us to use WFP more than previous windows editions and it should not be a problem with the next CIS editions which support Windows 8."

Microsoft: "TDI Filters and LSPs cannot be included in a certification submission: Network transport driver interface (TDI) filters and layered service providers (LSPs) cannot be used by either kernel-mode or user-mode software or drivers. You cannot include TDI filters or LSPs in your Windows 8 certification submission. Your certification can be blocked if other software on the test computer (for example, anti-virus software) contains a TDI filter or LSP. Workaround: Replace any TDI filters or LSPs in your software with calls to the Windows Filtering Platform (WFP) or other approved APIs. Remove other software that uses TDI filters or LSPs from the test computer."

Me: I think the shift in supported Windows interfaces has put us on unsteady ground. It isn't just Avast and Comodo that have had or will have to deal with that. So especially when it comes to Windows 7 and Windows 8, I think we need to thoroughly test firewalls including "against" redirection scenarios like those created by 1) Avast 6, 2) Avast 7. It would be nice if both of those, and any other types of redirection, scenarios were built into a stand alone firewall leak test of some sort.

PS: Some things I've read make me think that the TDI interface will still be built into and available on Windows 8 but that Metro/ModernUI app related traffic is handled in a such a way that it bypasses the TDI interface. So when it comes to testing things on Windows 8, at least if one is concerned about what not officially Windows 8 certified software might be able to do if it finds its way onto their system, one will have to test *both* the Metro/ModernUI scenario *and* desktop scenario (separately). If anyone is very familiar with such stack specifics I'd be interested in comment and/or confirmation.

[itman]

Avast: "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. "

Sounds to me if people insist on using Comodo for their firewall, Avast 6 would be a better choice to use; especially if they want to use Avast web shield. Based on the issues I have read concerning Avast 7, this might be a better option for that reason alone.

I am not a big Comodo fan. It is a great firewall for XP but lacking on WIN 7.

Since most people use Avast free and Avast is not making money from that product, I think they are well within their rights to restrict development on what the product is compatiable with.

Again I noticed this "hole" referenced above if Avastsvc.exe was not executed prior to any firewall rule that uses HTTP. If avastsvc.exe rule was executed first, it effectively trapped HTTP traffic. Finally, if the browser HTTP firewall is set deny/block, it cannot connect via TCP port 80, etc.

[Woody777]

Does Online Armor Free have this Problem with Avast? I see if picks up the loopback. To me It appears to be filtering W7 X 64 traffic when Avast is installed. Maybe the answer is to start using one of the free security suites of which Comodo is indeed a good example of.

[TheWindBringeth]

@Woody777: FWIW, I don't recall seeing anyone saying that Online Armor has a problem with one of the redirection scenarios. However, I just very quickly did a search and found:

"Online Armor Banking Mode will not work with anti-virus applications that use proxies for content filtering if that anti-virus application is excluded in Online Armor, posted August 12, 2011"
http://support.emsisoft.com/topic/52...es/#entry31544

So perhaps there are some scenarios where Online Armor functionality can be impacted.

I don't know if suites are the answer. On one hand, since the suite's components are designed and tested together, that should reduce if not eliminate interference between the suite's components. Does that, however, prevent some other software installed by the user from redirecting before that suite's hooks? I don't know. It seems to me that one aspect to "the answer" would be having the OS guarantee that a firewall component can 1) inspect and optionally block all of an application's outbound network operations before they could be redirected in some way, while 2) preventing said firewall component from itself rerouting the traffic in some way.

[Woody777]

I agree. It does appear to me that OA is picking up the local Proxy before applications access the internet. That being said I see no reason to use a firewall that does not control this traffic. Well, I guess you d have a hips but that is all.

[homeless_sapient]

Windows7FirewallControll has solved the problem from old time onwards – around 2009/2010:

»3.3.4.63
The security rules protection against third party hacks. Ability to block applications even the traffic is caught by online antivirus processing (redirecting all the web/mail applications to localhost first instead of real destinations)«

http://vistafirewallcontrol.freeforu...leases-t6.html

[TheWindBringeth]

@homeless_sapient: Perhaps you've already seen this from June 24, 2010, but if not:

http://vistafirewallcontrol.freeforu...zone-t102.html

"AV online file monitoring hooks all the applications to localhost and redirects the activity through the AV related services. We received many complaints like “I have disabled a browser, but it still easily goes to the internet”. The problem was always in the AV online monitoring. So we decided to treat localhost as any other remote host for the application permissions and not to enable localhost by default. "

"So an AV monitored application issues a public IP:80 request, AV implicitly(*) redirects the request to localhost:80 (127.0.0.1:80) which is enabled by LanOnly. Then AV processes the request and re-issues the request to the publicIP:80 in the name of an AV related entity (typically the AV service). The AV service is usually permitted to access to anywhere (for AV database updates, for instance), so the application request easily reaches the destination... As “what to do” we could recommend to exclude localhost:80 (127.0.0.1:80) from LanOnly zone as localhost:80 is practically equivalent to anywhere:80 under AV online monitoring. Then re-apply new LanOnly zone to all the corresponding applications."