Proxy not blocking EXE/DLL
I have a T35 running Fireware 12.5.3. Proxy for HTTP does not block EXE downloads. Web UI\Http Proxy Action Settings\Body Content Types shows Windows EXE/DLL checked with Action set to Deny. Believe proxy is working since Web UI\Dashboard\Subscription Services shows Gateway antivirus scanning numerous objects with count constantly trending upward. However, I am allowed to download .exe files from any site including those not on HTTP Proxy Exceptions List.
Have verified this behavior from 2 separate computers on network. I must be doing something wrong or missing something obvious, but cannot figure out what it could be. Any help would be appreciated.
Thanks ahead of time.
0
Sign In to comment.
Comments
1) what is the exact URL which is being downloaded?
Some .exe files have slightly different hex characters in them which do not match the Body Content Type string.
Also, is this a HTTPS access or a HTTP access?
If a HTTPS, are you doing Inspect and do you have a HTTP proxy action which is blocking exe/dll files?
2) on a HTTP proxy action, you can add a Deny in URL Paths for *.exe and *.dll which will block those downloads
Bruce, thanks for your reply. I appreciate your help and apologize for not getting back to this sooner.
Turns out the exe downloads were, as you probably imagined, through https.
A good example of a download I would like to block is https://www.fosshub.com/Audacity.html?dwl=audacity-win-2.3.3.exe . The download itself is a harmless audio editing program, but I would like to block my users from downloading it or any exe or dll from a website which I have not approved.
The router does have an HTTPS Proxy Action enabled. However, the Domain Names setting contained 3 domains. If no match, the action to take was set to Allow rather than Inspect.
I tried enabling Inspect but had to forego Inspection. I found the interference with what I would term regular web browsing to be unsettling at best. For instance, several major news sites, cnn.com, foxnews.com, and msnbc.com could not be reached because the FireFox browser reported "Warning:Portential Security Risk Ahead" because "a secure connection could not be established" or "did Not Connect: Potential Security Issue". Google could not be reached unless placed in the Domain List with an allow setting. I assume the results would be similar for other websites.
Have I misconfigured something to create this issue or is there some additional configuration which is necessary?
Thanks for your help.
Did you import a cert from your CA if you have one or the firewall cert on to your PCs prior to enabling Inspect on your HTTPS proxy action?
If not, you need to do so.
Use Certificates with HTTPS Proxy Content Inspection
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/certificates/cert_https_proxy_resign_c.html
Chrome & IE use the Windows certificate store.
Firefox uses its own certificate store.
It's also worth noting by default, Chrome will also try to use a protocol called QUIC, that can circumvent the proxy.
See:
https://watchguardsupport.secure.force.com/publicKB?type=Article&SFDCID=kA10H000000g3dzSAA&lang=en_US
-James Carson
WatchGuard Customer Support
You need to import the "Fireware HTTPS Proxy" certificate to all computers/devices subject to HTTPS/DPI, and it needs to be in the local computer store's Trusted Root Certification Authorities > Certificates store. If you have a Windows domain, it can be pushed out via group policy to Windows computers. Once installed or pushed, Microsoft Edge, IE, and Chrome will use it by default, but Firefox needs to be set manually or via a separate GPO after downloading their ADMX files because Firefox defaults to its own internal cert store.
To prevent QUIC from working, block UDP port 443 outbound. It also can be disabled via group policy...I do both!
To prevent DNS over HTTPS (DoH), block "content-type = application/dns-message in a HTTP proxy action specified in a HTTP or HTTPS proxy policy" (Bruce Briggs' recommendation in an old beta test).
After that, you'll still need to add some sites that break under HTTPS/DPI checks.
Gregg
Gregg Hill
Thanks so much for the input from everyone.
I had imported the certificate from the firewall after my most recent post but let the import function choose where to import. It chose Intermediate Certification Authorities rather than Trusted Root Certification Authorities. I moved it based on Gregg's comment and achieved success. I did not understand this was necessary from the various WG Knowledge base articles I read.
Again. Thanks so much for the help from the 3 of you.
It also sometimes makes a difference if one uses Internet Explorer to import it vs. using the MMC. I always use the MMC now after discovering that IE sometimes puts into the user store instead of the local computer store, in spite of actually choosing local computer when importing it. I figured out that one when IE, Edge, and Chrome all worked, but not Firefox, even with Firefox set to look at the local computer store.
Gregg Hill
Damn MS ;-)