This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Setup different web filter profiles for different networks.

I need some advice about how to setup different (and more secure) web filter profiles based on my network. 

I currently have a LAN with about 30 PC's + servers + printers on a 192.168.0.xx subnet and its plugged into eth0 on my SG135w UTM 9 (DHCP for the LAN is supplied by my Active Directory Domain)

I also have a WiFi network on a 192.168.10.xx subnet which is plugged into eth2 on the appliance (the WiFi access is supplied by a separate wifi system, but the appliance does supply IP address for everyone on the WiFi subnet. 

Eth1 is the WAN port for the network. 

I am trying to make sure there is no routing between the two subnets, which is my first problem. 

Secondly the SG135w is in my Active Directory domain and I want to enable AD authentication for the LAN PC's and to stop using transparent mode. But I don't want it to effect the WiFi (at least not yet) But I am not sure how to have one network using Standard Mode and one network using Transparent Mode, I can see that I can create different profiles but how do I setup the "Default Web Filter Profile" so other profiles can be used for the different networks? 

Cheers....



This thread was automatically locked due to age.
Parents
  • Go to Web Protection, Web Filtering.  Turn on.
    This will be your "main" profile.  Set the Allowed Networks to be "eth1 (Network)" or whatever your named your wired in computers to be.  Go to Policies tab.  For the Base Policy, set the Default content filter action to whatever policy you want.
     
    Now test - comfirm your wired people can transparently use the network and have that policy applied.  Make sure your wireless have no access.
     
    Now set the mode from transparent to standard.  On your wired clients, change the proxy to eth1's IP, 8080.  Test it works.
     
    Go to Web Filter Profiles and create a new profile for "eth2 (Network)".  Under Policies, click on Base Policy to edit it and create/choose a new filter action (so that it is different from wired).
    Test again, with wireless making sure the correct policy is applied.

    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.
  • 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. 

  • I understand the dislike for poor documentation.  This has been this way since Sophos UTM 9.0 and I suspect the same way in the Astaro ASG 8.x products as well.
     
    There is no harm or potential security hole if Standard mode is enabled.  Standard mode means that the UTM is listening to incoming packets directed to the firewall on port 8080.  But in this case it is already listening on port 80/443.
     
    There is, however, a implication to configuration.
     
    I know it is not in the documentation, but if I recall correctly (a few years ago when UTM was king and I was in these forums) that it was common knowledge that if you wanted to have a Standard Mode and and Transparent Mode for the same network but wanted different behaviour you needed to put the profile for Standard mode first.  This is because the Transparent mode profile includes Standard mode.
     
    So let me be precise:
     
    If the firewall sees incoming packets with destination of the UTM for port 8080 from a network in any active Web Profile's "Allowed networks" they will be forwarded to the httpproxy.  Regardless of the Profile's Standard/Transparent setting.
     
    If the firewall sees incoming packets with destination of something other than the UTM for port 80 or 443 from a network in any active Web Profile's "Allowed networks" they will be forwarded to the httpproxy IF that Web Profile is set to Transparent.
     

    In any case, its been like this for 5+ years and (to my knowledge) this is the first complaint.  I agree with you, but I doubt the documentation will change as management will see this as rock bottom priority compared to the other work we are doing.
     
    You can interpret the options as
    "Standard Mode only"
    "Transparent Mode as well"
    :)
  • Doug's right.  It should say "Both" just like in the FTP Proxy configuration.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Completely ignore the Standard mode proxy, I think your setup can be defeated in Transparent mode through a hosts file.  This is even mentioned in Bob's document "That means that a potential exploit would remain; a user on the Guest network could use a service like DynDNS to trick the Proxy into providing access to an internal IP."  Actually DynDNS isn't needed, just a hosts file.
     
    Starting with the same assumptions:
    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]
    The attacker creates a host file entry for payroll.example.local to 192.168.0.5
    An attacker uses Transparent proxy to reference http://payroll.example.local

    So the UTM sees an incoming connection to 192.168.0.5 on port 80.  The firewall sends it to the httpproxy.
    httpproxy doesn't re-resolve (pharming protection off).  In fact is pharming protection was on maybe even the attacker doesn't even need to know the correct IP because phaming protection would correct it.
    There are no filter actions that apply (no direct ip) and as per your assumption there is no block on *.example.local in the transparent mode guest proxy.
    So the request is allowed.  From guest network to internal network over the transparent proxy.
     
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 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.

  • Enabling the proxies together makes perfect sense for Internal networks.  It is generally not considered a risk because you are enabling the exact same access using two different methods.  There are several cases where clients normally connect in Transparent mode but for some reason the application works better in Standard.  So AFAIK it is not uncommon that you deliberately want both.
     
    I agree that we should be better at informing an Admin what is happening.
     
    If a browser tries to use Standard mode and it fails, it does not fall back to Transparent.  It just fails.  Non browser clients may be different.  However this is not really an issue.
     
    Ultimately, it has been like this for years and AFAIK there has been no customer requests for it to be any different.  Even with XG there were (AFAIK) no requests/requirement to be able to turn on Transparent mode with Standard mode.  Therefore, the priority on this is probably fairly low.
     
    If a change is made, it will definitely not be a change that affects current customers.  Better documentation is probably easier to push for than an additional option for Transparent Mode only.  Because with the latter you will have to argue the value of the feature versus the cost of implementation, and therefore the cost of not implementing some other feature that may have more users requesting it.
     
    I think that your concerns about "Because the proxies have some shared and some differing configuration mechanisms, actual packet processing results will be different in difficult-to-predict ways" is being a bit alarmist.
     
    I do agree that the UTM may not be the best (easiest to configure) for controlling both a guest and an internal network.  In that case I would recommend the XG which does a better job at it.