What do you do with your proxy policies?

GePo

TL;DR Are Proxy policies useless (with few exceptions)?

They're smarter than packet filter policies, but even the predefined proxy actions are essentially pass-through. There are no meaningful rules in any of the predefined proxy actions, just templates.

1. Only exception I saw was in the SMTP content type ruleset, suggesting typical attachment types to allow (if you change the default action to Deny).
2. Even then, what's the point of inspecting SMTP when everyone uses gmail.com and Google's API…?
3. If you use proxy policies, do you manually come up yourself with all the specific things you want/need to filter? Do you just use them to enable services like Gateway AV?
4. I just want to filter "evil" traffic from clients and to servers; I have no idea what e.g. to add to an HTTPS proxy Header Fields or URL Paths rulesets. And in the rare occasion I need to block sites, I use the Blocked Sites feature.

5. For other traffic, like IBM Aspera or video streaming, I know even less on its "valid" and "invalid" nature. I thought of using the TCP-UDP policy, but it's not even designed for incoming traffic?

6. Somewhat separately… With most traffic encrypted, I assume a proxy policy without working trusted certificates makes no sense either. Without a directory server or an in-house DNS server, one method would be to install the Firebox default cert on all clients. But can't you use a purchased cert (from Comodo etc.) which has a trusted root chain, to generate the necessary cert to install on the Firebox? The documentation makes no mention of this method, so I must be missing something here.

james.carson

Hi @GePo

I'd suggest reading thru the docs for each proxy. There's an explanation of what most of the actions inside each proxy do.

(About Proxy Actions)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/general/proxy_actions_about_c.html

1. The defaults are just that, defaults. You're able to change them to whatever best fits your organization.

2. Many organizations still host their own mail servers either locally or in the cloud. If you don't use SMTP, there's no requirement to configure an SMTP proxy.

3. Most customers will use the quick setup wizard's default proxy policies which enable services like Gateway AV if you have a license for that service.

4. "Evil" can mean many things. The firewall allows granular control so that you can allow what you want in/out based on what you perceive that to be.

5. The TCP/UDP proxy specifically detects HTTP, HTTPS, SIP, FTP, IMAP, POP3, and SMTP on nonstandard ports. For most inbound traffic, you would want to use an inbound proxy action that matches the traffic you're trying to send in, or a packet filter if there is not a proxy for that traffic. If you're hosting any of these services, you should be able to determine what protocol is in use. Once you know that information, set up a policy based on that.

6. You are correct, enabling content inspection would require that the firebox's proxy authority certificate be installed on clients, or a certificate the client PCs trust be installed on the firebox. No commercial CA will sell you a certificate that has the ability to resign additional traffic -- so the two predominant options will be to install the firebox's proxy authority cert, or install a domain certificate (such as from Active Directory) onto the firebox.

The documentation for this is here:
(Use Certificates with Outbound 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