Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 4 subscribers
  • Views 30419 views
  • Users 0 members are here
Options
Suggested
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.

DamienML

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

    In line with Michael's post, Derrick, you might consult Configuring HTTP/S proxy access with AD SSO.  You also might be interested in a document I maintain that I make available to members of the UTM Community, "Configure HTTP Proxy for a Network of Guests."  If you would like me to send you this document, PM me your email address. I also maintain a version auf Deutsch initially translated by fellow member hallowach when he and I did a major revision in 2013.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to Michael Dunn

    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. 

  • 0 in reply to DouglasFoster
    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"
    :)
  • 0 in reply to DouglasFoster

    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
  • 0 in reply to BAlfson

    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

  • 0 in reply to DouglasFoster

    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
  • 0 in reply to DouglasFoster
    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.
     
  • 0 in reply to Michael Dunn

    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
  • 0 in reply to BAlfson

    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.

Unfiltered HTML