Block clients that do not have a proxy set

Recommendations:

1) Turn on Transparent Mode Web Filter with no authentication and collect data.   

You will be surprised at how much non-browser traffic occurs on your network.   Automatic Updates from Microsoft, Adobe, Java, Antivirus.   Remote access applications like GoToMyPc.   There will probably be some non-Domain PCs in your organization that need network access.   There will be some fat-client applications that use https for communications.  Few if any of these applications will notice your proxy settings, and even fewer will be able to pass AD SSO credentials.   You may also have occasion to log into a PC with a local account, which cannot pass AD SSO, but may still need network access.

Transparent and Standard modes can (and should) be used together.   Put the Standard Mode Filter Profiles higher in the list so that they are evaluated first, because a Transparent Mode Filter Profile is actually a "both" profile.

2) How to use Transparent Mode

I use Transparent Mode with Authentication=None because I want all of those non-browser programs to work as expected without thousands of user complaints and special intervention.

I apply it to pretty much my entire network.

I configure Transparent mode with a Filter Action that allows the categories that are likely to be safe and likely to be necessary, with reputation Neutral or higher.

3) Proxy Bypass

Proxy bypass for Standard Mode is assumed to be done with the Proxy Script, based on regex of the URL.   Proxy Bypass for Transparent Mode is assumed to be based on a server skip list (based on IP), which is unknowable.   Instead, create an exception that disables all proxy functions.   This has worked well for me and the one exception applies to both Proxy Modes.   I actually assign tags to Website objects, then apply the tag to the Bypass-All Exception object.   This eliminates nearly all use of Regex, which avoids many errors and is simpler to maintain.

You SHOULD have a proxy script that bypasses all internal websites, whether referenced by DNS name or ip address.   Do not make UTM the bottleneck to your internal operations.

4) QUIC Protocol

You MUST block UDP 443 in your firewall, or Chrome will bypass your proxy whenever a server supports their QUIC protocol.   Optionally, you can add it to the Allowed Target Servers list so that Standard Mode connections allow it to work.   It is supposed to be faster.   Sophos has never said publicly whether their proxy handles it well, but users on this forum seem to have had success with it enabled.

5) Uncategorized sites

I block uncategorized sites.   This creates some support calls, but I have determined that it is worth the inconvenience.

6) TrustedSource.org

Get an account with them (Free) and use it to check and submit site categorization requests.   They will get you a result and a response email in 24 hours and it will flow to UTM eventually (5 days).  The Sophos submit form triggers the same process but provides no feedback.  I have been told that the database reference to use on lookups is "McAfee SmartFilter 4.2 XL-1"

DouglasFoster said:

4) QUIC Protocol

You MUST block UDP 443 in your firewall, or Chrome will bypass your proxy whenever a server supports their QUIC protocol.   Optionally, you can add it to the Allowed Target Servers list so that Standard Mode connections allow it to work.   It is supposed to be faster.   Sophos has never said publicly whether their proxy handles it well, but users on this forum seem to have had success with it enabled. 

QUIC is not supported by the UTM or XG proxy.  Any traffic that goes through QUIC is not virus scanned.  That being said, most QUIC traffic is to very large sites (and therefore usually safe) sites such as Google.

Michael, thank you for clarifying the status of QUIC.  My instincts were to keep it blocked, since there had not been an affirmative support statement.

I would suggest that a future release should have a system-supplied Firewall Rule to block UDP 443 by default.   Document the change in the release notes for those few sites that have a reason to turn it back on.

This is important because my testing indicates Chrome follows the following search path:

1. UDP 443 using Standard Proxy settings (if present)  -- UTM Standard Mode proxy will block, Chrome will move to step 2.
2. UDP 443 ignoring Standard Proxy settings - UTM Transparent Mode proxy will ignore, traffic will pass unfiltered based on Firewall Rules.
3. TCP 443 using Standard Proxy settings (if present)
4. TCP 443 ignoring Standard Proxy settings.

Blocking the port with a firewall rule, will be transparent to the user whether proxies are enabled or not, because Chrome will fail over to TCP 443 if both UDP 443 attempts fail. 

Without the default block, a lot of installations may have traffic bypasssing Web Proxy simply because the system manager does not understand Chrome.

In the XG there is a specific checkbox for Blocking QUIC.  Here is a screenshot from 17.5, there is even more detail in 18.

I don't know about UTM but given that is exists in the XG it may be in the roadmap for UTM.  Don't quote me on that.

Guys, I've had it in 'Allowed Target Services' for at least two years - are you sure that's ignored and QUIC is blocked automatically by the Standard Proxy?

Cheers - Bob

Ok, I just took a look.  AFAIK:

On the XG the Service definition for "HTTP" and "HTTPS" is TCP/UDP.  So on XG if you create a firewall rule for HTTP/HTTPS it automatically allows QUIC.  If you want to block QUIC you then need to check the Block QUIC box in the firewall rule.

On the UTM the Service definition for those is TCP only.  So on the UTM if you create a firewall rule for HTTP/HTTPS it does not allow QUIC (this is firewall enforcement not proxy).  If you wanted to allow QUIC you would need to do something like you did, Bob.

On both systems QUIC is not handled by the web proxy.  So all connection that occurs over QUIC as no policy or virus scan applied.  Therefore most customers want to block QUIC.

Ok, I just took a look.  AFAIK:

On the XG the Service definition for "HTTP" and "HTTPS" is TCP/UDP.  So on XG if you create a firewall rule for HTTP/HTTPS it automatically allows QUIC.  If you want to block QUIC you then need to check the Block QUIC box in the firewall rule.

On the UTM the Service definition for those is TCP only.  So on the UTM if you create a firewall rule for HTTP/HTTPS it does not allow QUIC (this is firewall enforcement not proxy).  If you wanted to allow QUIC you would need to do something like you did, Bob.

On both systems QUIC is not handled by the web proxy.  So all connection that occurs over QUIC as no policy or virus scan applied.  Therefore most customers want to block QUIC.

Which says that UTM does not need new code written, just a data element to implement a secure-by-default configuration rule.  

If an organization buys a web filter, it is safe to assume that tbey value policy enforcement more than the performance of a web browser (or a Google server.)

It is not reasonable for UTM to knowingly allow traffic to bypass its webfilter, as happened in my situation until I stumbled on tbe policy bypass two years after first launch.

My apologies to Douglas Foster, he is correct.

I was thinking about how the XG works and forgotten about how the UTM creates hidden firewall rules when you enable the web proxy with Web Filer Profiles and transparent mode.

So while my statement was correct about "if you create a firewall rule" but it is incorrect about using the web proxy.
David's statement was correct about if using the web proxy. You should create a rule to block QUIC.

I agree that UTM could do this better.