Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Subscribers 5 subscribers
  • Views 6469 views
  • Users 0 members are here
Options
Suggested

Feature request - DNS Web Filtering

Tha IT

Given how prevalent HTTPS is these days , DNS Filtering on the Guest , IOT  , Reporting and Mobile WLANS is an absolute requirement.

To be able for the Sophos XG's to function like a DietPI without the need for running a seperate HW/VM would be a godsend for us.We are increasingly finding that the only thing onsite piece of equipment customers tend to have is a router + fiber/wireless and 4G Failover.It gives customers piece of mind that contractors and users can perform their duties on mobiles whilst not doing unproductive/illegal work as well as provide some web filtering for black box IOT devices.

Whilst these things aren't perfect ie we sometimes have to allow web connectivity checkers from android and apple to go through otherwise it disconnects from the wifi.

Use Cases

1)Messaging - Common aggregation point (Canteen/SOC/Emergency Assembly Point )  or site wide WIFi where users should only be able to access MS Teams , SFB or Slack to report issues , hazards,productivity issues etc . Many devices here are BYOD and in a lot of my customer use cases they have a contractor on site for 2 months . It's not worth their time and money to send me out installing and removing HTTPS certs on devices . In many cases we've found App Control is not granular enough or sometimes doesn't function cross platform.

2) IOT LockDown - IOT Devices that should only be able to go to $manufacturer.com and check for updates and update telemetry data . Cannot deploy HTTPS Scanning Certificates on a web connected sprinkler or Connected Cow system . FQDN Hostgroups and wildcard support have made this much less of a painpoint than before , but will  further lock down what an IOT device can and cannot do on the network.

3)Realtime Alerting on Day 0/Suspicious/Prohibited DNS Activity - ATP somewhat does this , but being able to get realtime log email alerts when a bad actor queries to go to a categorized dns domain ie c&c/hacking/fraud/proxy/pron  site to allow immediate discovery , investigation and removal of bad actors on the network.

 

Features it will need to reach feature parity with some competitor solutions:

1)Live query logging via F/W console to debug issues . We've had issues where a provider will ask us only to whitelist *incompetentprovider.com only to find out they also use cdn.provider.com

2)Ability via Daily/Weekly Reporting in XG and IView to report on Top 20 domains accessed , Top 20 Domains Denied , Risky DNS domains accessed etc

3)Full Blacklist ability ie only allow domain1.com and deny all other dns queries.

4)Regex support for BOTH whitelisting and blacklisting client ie client[1-99]\.google\.com

Parents
  • 0

    Current implementation: HTTPS with no scanning does categorization using the FQDN from the SNI. It can block via webpage (and certificate) or by dropping the connection. We do not do categorization/blocking on DNS requests. The practical difference between the current solution and DNS is that we currently can log/block all FTP/HTTP/HTTPS connections to sites in any given category, however a DNS solution would apply to other connections/ports as well. The problem with DNS categorization and filtering is that it is easy to bypass. A device with malware can use a local hosts file. A device with someone bypassing filtering can use google's DNS servers.
    ATP does work on DNS (in addition to the web proxy), however it is designed to only catch callhome domains (infected devices connecting to known command and control sites).

    If your concern is HTTPS, I fail to understand what DNS filtering gets your that the current HTTPS proxy (with scanning off) does not get you. Can you explain?

    1) What about the current solution does not allow you to do this? Set up a URL Group or Custom Category for your whitelisted messaging FQDNs, create a web policy that allows the whitelist and blocks everything else. Create a WiFi SSID for "Guest WiFi (Locked Down)". Create a firewall rule for that network that goes to that web policy, no HTTPS decryption. Anyone who connects can access your allowed things no problem. If they try and access anything not allowed they'll get a block page (HTTP) or a certificate warning (HTTPS)/dropped connection (as per config).

    2) Agreed. Again, I'm not sure what about the current solutions does not allow you to do this, though it may be painful to do. AFAIK IoT is on our radar.

    3) I cannot speak on the reporting/alerting side. The data is there in the web proxy reporting.

    Wishlist:

    1) I know I can, but not via command line. This is more about preferred way of working.

    2) I cannot speak on the reporting/alerting side.

    3) You can do via web proxy, not DNS. Again, if the concern is HTTP/HTTPS why do you need DNS? And how would this deal with anyone who chooses to use any other DNS provider?

    4) Agreed, somewhat. You can whitelist via exceptions using RegEx, though this applies to all policies. Whitelist/Blacklist via URL groups or custom categories has some wildcarding but is not RegEx. There is a problem of this legacy of several ways of doing things and we'd rather not introduce a new, additional ways. Coming up with a solution that works for what we want and also maintains that upgrades with pre-existing stuff still behaves the same is difficult.

    Whitelist/Blacklist KB community.sophos.com/.../127270

  • 0 in reply to Michael Dunn

    Thanks Michael , you've made some good points .

     

     

    Just a question now that TLS 1.3 is effectively upon us.

    Can you still filter BYOD devices via SNI  without decryption ? 

  • 0 in reply to Tha IT

    I just had a quick lesson in TLS 1.2 and 1.3 Client hellos.  :)

    In short - SNI is still sent plaintext in TLS 1.3.  There is an extension that allows for encrypted SNI but no one is using it (yet).  The handshake for TLS 1.3 looks like the handshake for TLS 1.2, which makes it backwards compatible.  But a handshake for TLS 1.3 with encrypted SNI, looks to a TLS 1.2 server as a handshake with no SNI at all, something that many TLS 1.2 servers wont like.  Proper encrypted SNI also requires you to use DNS-over-TLS.

    Effectively, if a client uses encrypted SNI, that client is TLS 1.3 only.

    When using the new DPI mode, TLS 1.3 is fully supported.  Even if you are not doing decryption you still have the SNI and can still block on it.  If configured for block pages (default) then it lets the connection through to the server, inserting itself into the encryption (using the XG CA), to redirect the client to a page on XG:8090 containing the real block page. 

    When using the proxy mode, TLS 1.3 is not supported.  Even if you are not doing decryption you still have the SNI and can still block on it.  If configured for block pages (default) it will pretend it is the server and that it only supports TLS 1.2.  It used the XG CA to display the block page.

     

    tl;dr answer:  SNI is unencrypted and both DPI and proxy mode work fine.  It will remain like this until clients and servers decide backwards compatibility no longer matters.  Let me know the lag time between the IPv6 standard and non-test websites that only support IPv6.

     

    https://blog.cloudflare.com/encrypted-sni/

Reply
  • 0 in reply to Tha IT

    I just had a quick lesson in TLS 1.2 and 1.3 Client hellos.  :)

    In short - SNI is still sent plaintext in TLS 1.3.  There is an extension that allows for encrypted SNI but no one is using it (yet).  The handshake for TLS 1.3 looks like the handshake for TLS 1.2, which makes it backwards compatible.  But a handshake for TLS 1.3 with encrypted SNI, looks to a TLS 1.2 server as a handshake with no SNI at all, something that many TLS 1.2 servers wont like.  Proper encrypted SNI also requires you to use DNS-over-TLS.

    Effectively, if a client uses encrypted SNI, that client is TLS 1.3 only.

    When using the new DPI mode, TLS 1.3 is fully supported.  Even if you are not doing decryption you still have the SNI and can still block on it.  If configured for block pages (default) then it lets the connection through to the server, inserting itself into the encryption (using the XG CA), to redirect the client to a page on XG:8090 containing the real block page. 

    When using the proxy mode, TLS 1.3 is not supported.  Even if you are not doing decryption you still have the SNI and can still block on it.  If configured for block pages (default) it will pretend it is the server and that it only supports TLS 1.2.  It used the XG CA to display the block page.

     

    tl;dr answer:  SNI is unencrypted and both DPI and proxy mode work fine.  It will remain like this until clients and servers decide backwards compatibility no longer matters.  Let me know the lag time between the IPv6 standard and non-test websites that only support IPv6.

     

    https://blog.cloudflare.com/encrypted-sni/

Children
  • 0 in reply to Michael Dunn

    Thanks Michael for at least considering this. With the new DPI mode from what I understand it can also intercept non standard ports ( ie non 80/443) I take it ? That's one of the other issues I've faced , in that a lot of these devices are using nonstandard ports like  8443 , 8180 , 8880 to connect to some web api socket for data streaming.

    DNS Filtering isn't an I win button , but if you layer it up with port ranges , APT , address lists/web categories it works pretty well. Effectively the "dumber" , "unmanaged" or "blacker" the box the more we tend to need it.

    Especially now that we can force to do redirects to the XG's DNS server (Page 52 of the EAP1 PDF) it makes a lot of sense to put those hands together being able to filter certain clients DNS views.

    Granted this is all just feels like it's all just temporary wins/control in this arms race this until the browser/app developers decide to head off to fully encrypted DNS and SNI.

Unfiltered HTML