Setup different web filter profiles for different networks.

RE:  Note: When you configure a profile for "Transparent" it will also work for "Standard" for the same incoming IPs.  In other words, Standard is always on and the radio button is really just turning Transparent on and off.

Michael, I cannot help being impatient with undocumented features. I just checked, and the help page says nothing about "Both".   I hope you are mistaken on this one, only because it would vindicate the documentation.  If "Transparent" means "Both", the user interface should says "Both".   Security products need to help the system administrator know what the product does, so that they configure the product without unexpected behaviors. 

Doug's right.  It should say "Both" just like in the FTP Proxy configuration.

Cheers - Bob

This is more than just a documentation problem, it is a security vulnerability.   The product needs to be changed ASAP to match the current documentation (although allowing a "both" option is also legitimate for upward compatibility with those few who know about this feature and want it preserved).

The problem is that DNS and packet routing does not behave the same between Standard Mode and Transparent Mode (when pharming protection is off, as it should be for the proposed guest network)

Assume:

• The inside network is *.example.local and the internet-facing network is *.example.com
• The questioner follows Bob's Guest Network documentation and directs the guest network to Google DNS on 8.8.8.8 or (better) the new Quad9 DNS on 9.9.9.9 (see quad9.org for details.)
• In the Guest filter action, he also blocks addresses of the form 192.168.*.*  (https?://192\.168\.\d{1-3}\.\d{1-3}
• Because *.example.local cannot be resolved by Google DNS, he does not think to block it in the filter action. [Which proves to be the critical mistake]
• An attacker uses Standard proxy to reference http://payroll.example.local

 Here is what happens:

• The target address on the original packet is the UTM, so DNAT rules to not apply and the packet is not blocked at the DNAT layer.
• The standard proxy resolves payroll.example.local using its own DNS, which probably returns the actual internal address.
• The filter action does not block based on the IP address, because it examines the URL, not the IP address.
• The standard proxy has no block on *.example.local, so the access is permitted.
• The standard proxy connects to the website on behalf of the user, using its own interface address for the outbound packet, so no NAT rule is needed and the packet is forwarded.

See my longer discussion on this post:

https://community.sophos.com/products/unified-threat-management/f/general-discussion/99195/utm-dns-security-considerations

Doug, I think the vulnerability you detail does not exist.  In the Guest document, the Guest Network has its own Profile and Filter Action - Guests are not allowed to use the other Profiles or Filter Action(s).  The DNAT of port 8080 prevents Guests from using the Standard Proxy.

Cheers - Bob

How does a Transparent mode access to 192.168.0.5 succeed if 192.168.0.0/16 is in the Transparent mode Destination Skiplist without a firewall rule allowing the traffic?

Cheers - Bob

You are correct Bob, a DNAT rule to dead-end traffic from the Guest network to the UTM port 8080 will disable the Standard Mode web proxy function that the UTM Administrator never knew was enabled.   Disabling the function is necessary to avoid the problem.  Disabling the automatic and undocumented activation of the function is exactly what is needed so that the vulnerability is not created by default.

I was assuming a DNAT rule to block access from the Guest network to the Internal address ranges, which is the type of DNAT rule that would be skipped by Standard Proxy.

The key issue is that Transparent Mode without Pharming has a very different security posture from Standard Mode, because both DNS and packet routing are handled differently.  Therefore it is absurd to assume that if one is enabled, then enabling the other is also appropriate and innocuous.   Clearly, the original developers at Astaro did not understand the differences when they decided to enable Standard Mode automatically.   Now that the problem is defined, a corrective measure is needed.

To the original question:

I no longer consider it safe to use one perimeter device to protect both an internal network and a Guest network, regardless of the make and model of the device.   The two networks should be isolated for security reasons, and they should be on separate Internet addresses for reputation reasons.   Providing a Guest network is optional.   Protecting devices on the Guest network is also optional (users should know that they use it at their own risk.)  But if you decide to protect your Guest network, the correct way to protect it is with a dedicated device, not a shared device.   This conclusion has to do with the DNS complexity in my other post, even more than with the features of UTM.

For the transparent mode scenario, I was assuming that DNAT-to-dead-end rules would prevent traversal from Guest to Internal.   I was also assuming that *.example.local would be unresolvable, so the protection should be complete.   When Standard Mode is enabled, the DNAT rule is skipped and the web address becomes resolvable. 

See #2 in Rulz, Doug - DNATs come before Proxies.  It prevents the Guests from accessing their Profile in Standard mode.  Or have I not yet understood what you're saying?

Cheers - Bob

See #2 in Rulz, Doug - DNATs come before Proxies.  It prevents the Guests from accessing their Profile in Standard mode.  Or have I not yet understood what you're saying?

Cheers - Bob

Our replies may have crossed.   Yes, a DNAT to block port 8080 is viable.   A higher-priority Standard Mode proxy to block all is also viable.  Both of these methods turn off something that the system manager never asked to turn on.   Why is a workaround supposed to be an acceptable alternative to doing only what the system administrator authorizes?

But why is enabling the proxies together even considered worthwhile?

• What happens if Transparent is enabled, Standard is disabled, and the client tries to use standard mode?  Nothing important.  After a delay, the browser detects the proxy as unresponsive, and switches to direct mode.   Once that happens, the packet is processed by Transparent mode.   The user complains about slow web browsing, tech support identifies the problem, and either enables a standard proxy or disables the proxy settings.
  
  
• What happens if Transparent and Standard proxies are enabled together, because of the current configuration?   Because the proxies have some shared and some differing configuration mechanisms, actual packet processing results will be different in difficult-to-predict ways.  To solve these differences, the system manage will probably need to create separate profile-policy-action sequences anyway. 

I can see no benefit from enabling both proxies together, but many downsides.