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

Discussion in 'other firewalls' started by TheWindBringeth, Mar 21, 2012.

Thread Status:
Not open for further replies.
  1. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    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?

    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.
     
  2. noobian

    noobian Registered Member

    Joined:
    Aug 15, 2012
    Posts:
    11
    Thanks to TheWindBringeth and others for the discussion, and to pegr for simplifying the practical implications so that even a noobile could understand. ;)

    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)?
     
  3. homeless_sapient

    homeless_sapient Registered Member

    Joined:
    Apr 11, 2012
    Posts:
    34
    @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.
     
  4. homeless_sapient

    homeless_sapient Registered Member

    Joined:
    Apr 11, 2012
    Posts:
    34
    @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).
     
  5. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    @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.
     
  6. homeless_sapient

    homeless_sapient Registered Member

    Joined:
    Apr 11, 2012
    Posts:
    34
    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.
     
  7. noobian

    noobian Registered Member

    Joined:
    Aug 15, 2012
    Posts:
    11
    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..
     
  8. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    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?
     
    Last edited: Aug 16, 2012
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    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.
     
  10. homeless_sapient

    homeless_sapient Registered Member

    Joined:
    Apr 11, 2012
    Posts:
    34
    @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.
     
  11. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    @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

    ?
     
  12. homeless_sapient

    homeless_sapient Registered Member

    Joined:
    Apr 11, 2012
    Posts:
    34
    @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.
     
  13. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    @homeless_sapient: Well thanks for sharing some info and good luck with that effort. Let us know how you make out.
     
  14. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,545
    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.
     
    Last edited: Aug 17, 2012
  15. gdiloren

    gdiloren Registered Member

    Joined:
    Jul 3, 2007
    Posts:
    146
    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!...
    ;)
     
  16. homeless_sapient

    homeless_sapient Registered Member

    Joined:
    Apr 11, 2012
    Posts:
    34
    @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: https://www.wilderssecurity.com/showpost.php?p=2102129&postcount=70
     
    Last edited: Aug 17, 2012
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    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.
     
    Last edited: Aug 17, 2012
  18. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    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:thumbd:
     
  19. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    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.
     
    Last edited: Aug 18, 2012
  20. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,410
    Location:
    U.S.A.
    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.
     
  21. Woody777

    Woody777 Registered Member

    Joined:
    Aug 29, 2006
    Posts:
    490
    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.
     
  22. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    @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/5208-known-online-armor-issues/#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.
     
  23. Woody777

    Woody777 Registered Member

    Joined:
    Aug 29, 2006
    Posts:
    490
    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.
     
  24. homeless_sapient

    homeless_sapient Registered Member

    Joined:
    Apr 11, 2012
    Posts:
    34
    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.freeforums.org/the-latest-betas-releases-t6.html
     
  25. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    @homeless_sapient: Perhaps you've already seen this from June 24, 2010, but if not:

    http://vistafirewallcontrol.freeforums.org/lanonly-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."
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.