UTM in transparent/bridged mode

There is a significant loss in capability and accountability when you switch to teansparent mode.

I suggest that you enable teansparent mode as a backup to standard mode rather than a replacement.

There is a significant loss in capability and accountability when you switch to teansparent mode.

I suggest that you enable teansparent mode as a backup to standard mode rather than a replacement.

Hi Douglas,

Thanks for the replies.  The problem is that I don't want to specify proxy settings on my appliances.  We have issues where some applications ignore the system proxy settings and attempt to go straight out through the firewall too.

Thanks

The two proxy methods are not exclusive.   The proxy method determines the port -- UTM standard proxy uses 8080 (by default), while transparent mode monitors 80 and 443 only.  Since the two modes operate on different ports, they can be operate in parallel.   Of course, to use transparent mode, the UTM needs to be on the path to the internet, which was the focus of my previous post.   (That suggestion does not requiring any IP address changes.) 

To use both methods, you have to create a filter profile for each method:  The source IP and port determines the filter profile.  The filter profile (and optionally the device type) determines the authentication method and the https inspection method.   The authentication method determines the user.  The user determines the policy.  The policy determines the filter action, and the filter action determines whether the URL is allowed.

With both modes enabled, the transparent mode proxy will handle any traffic that does not honor the device proxy configuration.    This includes traffic that is configured for DIRECT in your proxy script.  You need to add your Direct destinations into the transparent skiplist (or retest to see if they work acceptably in transparent mode.)

With non-browser applications, they will not have NTLM information needed for automatic user identification.   Consequently, many problems with these applications can be solved with an exception entry to bypass authentication for the destination server.   This works with both proxy modes.

When transparent mode takes effect, firewall rules to block port 80/443 will no longer be relevant, so you may need to create appropriate transparent-mode policies to maintain your desired security posture.

Doug said, "Since you have an existing firewall, i would recommend keeping it at the perimeter.   UTM opens unwanted ports and the UTM firewall rules are ignored when a proxy is involved."  I don't often disagree with him, but I will here.  It's true that someone accustomed to Cisco can be surprised by how the UTM functions.  Firewall rules are applied, but rules created by enabling proxies are applied before manual rules (see #2 in Rulz).  If you want to close a port at a WAN connection, just use a DNAT to a non-existent IP.

In general, I would not recommend bridging the UTM, but it's not clear to me from this discussion what function(s) the UTM provides.  Is this simply a thread about Web Filtering that should be moved to the Web Protection forum?

My approach would be to get rid of the perimeter firewall if the UTM has a Network Protection subscription, and possibly so even if it does not.  Again, it's not clear to me exactly what the situation is.

Cheers - Bob

Bob, we will have to agree to disagree.  

If UTM wants to be a perimeter device, it needs to not open ports that the user does not expect to have open.  Sophos calls XG a firewall, but it does not call UTM a firewall.   I think that is instructive.   UTM is a product with many good features at a great price, but an acceptable perimeter firewall is not one of them.

If you want to sell the idea that the workarounds are acceptable, I suggest you (or Sophos) create a wiki article that itemizes all of the necessary DNAT workarounds.   It seems they include SMTP Proxy which opens 25 on all addresses, something with RED certificates being visible on the internet even when the RED devices are not supposed to be visible on the internet, and (my experience) WAF opens 443 even when all WAF sites are configured for alternate ports.  What else do we need to worry about that is not on my list?   We cannot patch what we do not know, and a wiki article would at least warn the sysadmins who stumble on the entry.  Specifically, can 127.0.0.99 work as a DNAT dead-end, or will UTM respond on all loopback addresses?  If I use a non-loopback private IP, I need to worry about that IP being used in the future, so a loopback address is definitely preferred.

On port scanning, I only have experience with Trustwave, and once they accept a defense, it does roll over to all subsequent scans.   I am astounded by how much they can expose from an automated scan, as I assume the bad guys and the NSA can learn as much or more.   I would love to know how to prevent the information leakage which allows PCI scanners to know the version numbers of component products.   I value what Trustwave reports, because if they can detect a version number and rattle off all of the vulnerabilities that might be unaddressed, then we can assume that a bad guy can extract the same version information and attempt to attack each of those vulnerabilities.   It is a headache to prove that each CVE has been addressed, but the information at least gives me a degree of parity with the bad guys.