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, 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

BAlfson said:

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?

I was assuming that there was no such rule.

Lets say you had multiple internal network segments that are allowed to talk to each other.  Either they go through the proxy (there is no skiplist) or there is a skiplist and it is allowed through firewall rule.

Internal A

Internal B

Guest

All are configured in transparent mode.  Internal A needs to be able to access resources on Internal B through the UTM.

Assuming that there is no skiplist, the traffic goes through httpproxy.

If attacker on Guest does a TCP connect to a IP on Internal B port 80, I *think* that the firewall will send it to httpproxy.  And if the attacker then writes appropriate HTTP 1.1 headers with Host: target.company.internal  I think the proxy will allow it.

If there was a skiplist and there was no firewall HTTP rule, I think both Internal A and Guest would be block by firewall.

If there was a skiplist and there was a firewall HTTP rule that was only Internal A and Internal B... Guest would I think be blocked.

---

Here is another possible solution.  Create a standard mode Filter Profile for the guest network that is higher priority that the transparent mode Filter Profile.  But set the filter action to Block All.  Anything in exceptions would still get through, but you'd prevent most access with a block page.

---

As a separate discussion, by the way, XG does not suffer from this problem.  In the equivalent of the "Filter Profiles", you actually specify full firewall rules you can specify the allowed source and destination networks.  Therefore in the firewall rule you can say that from Guest to Internet, HTTP with proxy and they'll never be able to access internal.  However XG is like the UTM in that you cannot enable transparent mode only without also doing standard mode.

Michael, I guessed at your Sophos email address and sent you the "Configure HTTP Proxy for a Network of Guests" document earlier today.  Would you look at that and make any modifications you think necessary to your post just above this one.

I like your alternative to the DNAT because it more-elegantly keeps the solution inside the Web Filtering configuration.

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.