Encrypted SNI death blow to transparent filtering

Posted October 3, 2018 by David Redekop to DNS Security

Encrypted SNI, announced by Cloudflare this past week, is a positive move towards privacy and security. It makes sure that along the path from your browser, all the way to the host you’re contacting, even the hostname such as dnsthingy.com isn’t visible.

However, the side effect of this natural progression of encryption, is that gateways which depend on SNI for Internet Filtering cannot do so any longer when Encrypted SNI is deployed. Transparent filtering, as it is called, is in use by Squid and many other SSL filtering gateways.

On the other hand, the good news is that DNS-based filtering remains as powerful as ever. In fact, DNS-based filtering has a significant advantage over proxy-based technology for these reasons:

  • Lower RAM and storage resources required on gateway such as pfSense (only a DNS query response vs packet inspection, caching of page contents, etc)
  • Faster end-user experience (for the time it takes for a DNS query the end-user knows if destination is blocked or allowed)
  • Better compatibility – no more worries about end-user applications’ proxy incompatibilities
  • Better IoT security control and connectivity

It is clear that DNS-based filtering is here to stay. Watch for news on how DNS over TLS and DNS over HTTPS have a future on-premise to provide the best of security and privacy, while also facilitating system administrators’ responsibility to provide security at the gateway.

DNS rebind protection

Posted July 26, 2018 by David Redekop to DNS Security

The green circle is what you’re looking for on your local DNS server on your LAN. Then, and only then, according to GRC DNS benchmark freeware, do you pass the test of private IPs being stripped from public DNS queries. As of DNSthingy build 1916 and above, this behaviour is now the default.

This is important because it’s a security strategy to mitigate DNS rebinding attacks that are making the rounds to get into private IPv4 networks which are often presumed to be protected from the public internet.

Steve Gibson on Security Now Episode #673 (show notes PDF) had great coverage on the DNS rebinding attack, after already having covered it in episode #260.

A setting is available in pfSense that is used to enable this setting in the pfSense UI (2.3+) under System -> Advanced:

As long as that box is unchecked as shown in the screenshot, it will trigger build 1916 and onwards to block RFC1918 private addresses (10.0.0.0/24, 172.16/12, 192.168/16) + 169.254/16 subnets as well as IPv6 link-local and the applicable area of NAT64 space. Note that this is also the behaviour with pfSense default DNS resolver (unbound).

On other platforms (ClearOS, ASUS) this behaviour is default as well, starting with Build 1916 and onwards.

To check your build, log into your dashboard -> Router -> rest your mouse over your “Running” version to display your build number as shown here.

The qualifying build is available on pfSense Rapid Release Channel as of 27 July 2018 and will be deployed automatically on other platforms. Keep enjoying your peace of mind!

DNS over TLS or HTTPS – the rest of the story

Posted April 3, 2018 by David Redekop to DNS DTTS

Secure DNS isn’t everything it first appears… especially when you consider the impact on different roles.

Introduction

DoH (DNS over HTTPS) and/or DNS over TLS rapidly gained attention of the infosec community with CloudFlare’s announcement of 1.1.1.1 offering on their worldwide anycast network. While the 35-year-old DNS protocol admittedly remains the weakest building block of the Internet in terms of security and privacy, not everything is at it seems.

Perspective

In order to objectively assess this recent announcement of CloudFlare’s, it’s important to assess the impact on audiences of all types not just what the headlines would have you believe. There are at least four identifiable audience types to whom the impact is quite significant and different from one another, and each have solid rationales for their perspectives.

  1. The consumer

    There’s no doubt that the Internet consumer over the years has been abused in terms of tracking and targeted advertising as we need to look no further than the facebook debacle we are experiencing in Q1-Q2 of 2018. Even when someone visits https://www.example.com, the DNS or the Internet “directory” has been mostly delivered in plain-text, meaning that anyone along the way, including your Internet gateway, your ISP and anyone else in the path of the data transit had visibility into what each subscriber’s habits were. So, the idea of secure DNS means that each individual DNS query, or directory lookup, is no longer visible to those parties, thereby providing additional privacy as well as security. The privacy part is more obvious since the actual question of “where is www.example.com” is completely obscured from the Internet Service Provider and everyone else from your device to the service you’re asking. The security aspect happens to be a nice side benefit since the obscurity of the question and answer disallows any man-in-the-middle altering of the answer as well as profiling of your habits. All in all, secured DNS is a huge win for the consumer, most especially in a nation-state that is oppressive. That is, as long as the oppressive state isn’t blocking that service of which you’re asking. This is just a small prediction: certain nation states will be blocking 1.1.1.1 if they haven’t already by 2 April 2018.

  2. The Systems Administrator (sysadmin)

    The role of the often underappreciated sysadmin is to be the silent hero, unworthy of any outward accolades. The reward of a “job well done” is found in the lack of problems experienced by users and stakeholders alike. Sysadmins have handled the gradual, but predictable, rollout to the secured web (http to https), the “going dark” problem in stride, because it was good for the Internet community by achieving greater privacy and security. Partially this was because DNS remained a channel of control for the sysadmin. If a device tried to access a destination known to be in control of a malicious actor, it could be blocked at the DNS level because (a) it was visible and (b) it was known to be bad. When you remove the visibility to the sysadmin who is responsible to make sure nothing malicious happens over the edge of a network, this is a problem.

  3. The Provider

    Any organization in the position of gaining end user or sysadmin trust to have their DNS queries sent to them for answers, has a whole lot of responsibility. This kind of burden doesn’t come without cost, and therefore, benefit. Any organization that offers recursive, encrypted DNS services, and fast delivery at that, needs to be analyzed in terms of motives. In the case of CloudFlare, it is obvious that their existing subscribers benefit the most, as it is even expressed in their own blog post:

    “…every new user of 1.1.1.1 makes Cloudflare’s Authoritative DNS service a bit better. And, vice versa, every new user of Cloudflare’s Authoritative DNS service makes 1.1.1.1 a bit better.”

    Of course, every company can do what they want, but an objective assessment should always consider the provider’s true motive. In this case, the customers as well as the customers of Cloudflare’s customers stand to win when they use 1.1.1.1.

  4. The Nation State

    The reality of oppressive regimes isn’t lost, either. The “going dark” problem, up until now, at least still revealed clear-text DNS queries, for the most part, except for OpenDNS’s DNScurve adoption, implemented as DNScrypt. Clear-text DNS allowed DNS-based filtering and analytics to play a significant role with great nation state firewalls to allow or block certain connections and services.

    With secured DNS now being part of the “going dark” protocols, it simply complicates the cat-and-mouse game, in which anyone is welcome to participate. When secured DNS is standardized and can be hosted anywhere, from a directory perspective, it just made it that much more difficult for nation states to filter source/destination pairs to be blocked.

    To be sure, vendors to Nation State firewalls will quickly up their game to compensate for lack of DNS visibility by offering increased threat intelligence fine-tuned to destinations including granular per-IP SANs to make up for the lack of DNS visibility.

How does DNSSEC fit into all of this?

Aside from the fact that DNSSEC is often misunderstood as private or secure (as in encrypted), it gives no privacy advantages whatsoever over non-DNSSEC DNS. This well-intentioned protocol has been a 20-year challenge and still isn’t being widely adopted. When properly implemented, DNSSEC gives authenticity, making DNS man-in-the-middle attacks impossible.

Our Conclusion

Everyone agrees on the importance that the edge of a network plays in terms of network reliability and security. In the industry, we often make an analogy to physical border officials who have the unenviable job of allowing or refusing entry to visitors. In the same way that officials need to have at least a reasonable risk assessment of entering individuals, the same applies to the edge of a computer network. While detailed traffic between endpoint and secured server should remain private and encrypted, the determination of which devices are communicating where, that should remain in control of the edge.

To do so, means the edge must have DNS visibility. This is not only sensible, but it is possible, and everybody wins. Here’s how:

Endpoint ↔ [Secured DNS channel] ↔ Edge ↔ Secured DNS channel ↔ Public Resolver

To give end users the privacy while allowing sysadmins to have the tools to protect the managed network, all outgoing connections must be whitelisted with DTTS (Don’t Talk To Strangers), an implementation of short-lived “allow” rules based on the TTL (Time To Live) of successful DNS answers. “Strangers” are destination IPs that were not first resolved via DNS. For example, badactor.co will not resolve to an IP address, therefore, no “allow” rule is created to its authoritative destination. On the other hand, google.com is permitted, so an “allow” rule is temporarily created for the asker, but only for the period of the TTL. Likewise, any internet traffic attempted without an allowed DNS query is simply not allowed. This approach gives the end-user the complete confidentiality of a banking transaction, while the sysadmin knows only that Internet-Exit-Point-A is conducting business with Bank-B, not aware of any further details. The Nation State is aware of the same since source-destination IP pairs always remain visible in transit. Everybody is happy.

Who doesn’t like a happy ending?

Quad9 support

Posted November 22, 2017 by David Redekop to DNS Feature

DNSthingy’s core value is on-premise filtering with fastest possible performance (i.e. it isn’t a cloud DNS service), allowing you to apply different policies to different device groups. You’re never locked into a one-size-fits-all scenario. An IoT network should not have the same permission as a desktop or mobile device, for example.

However, once a domain is approved for upstream resolution, DNSthingy will send it to the upstream DNS resolver of your choice. This is made very easy with a customized drop-down list like this:

So, in addition to all the DNSthingy services, you can use quad9.net (9.9.9.9) as a resolver of last resort to provide additional protection.

How we are different from OpenDNS

Posted July 11, 2017 by David Redekop to DNS

For those familiar with the great service from our OpenDNS friends, a common question we get is “How are you different from OpenDNS?”

Well, we don’t compete with them. Assuming you also like them, our service complements theirs! In fact, quite a number of our subscribers are OpenDNS subscribers as we integrate quite well as you’ll see if you try it out, including a native built-in OpenDNS Updater so you don’t need to run your dynamic IP updater on any other device.

There are many other differences though, here’s a partial list that most often applies:

  • Deterministic answers – apply different DNS policies to different devices. For example:
    • IoT devices for example, need a very limited whitelist
    • Guest iOS devices may just want obviously-bad content blocked
    • CFO money transfer devices need a very limited whitelist only to the bank in use
  • Whitelisting is our specialty
    • Start with nothing, add what you need
    • Cloud-based web crawler searches and identifies dependencies and threat intelligence to allow only what is safe
  • Domain-joined devices do not need to use Active Directory’s DNS servers:
    • Our rainbow (or re-direct) lists feature AD domain redirection to AD so that all non-AD queries are never sent to AD DNS.
    • Benefit #1 is that your Active Directory DNS servers can now experience a high-level of protection by having strict egress control
    • Benefit #2 is that your devices can experience different treatment from others (appropriate policy based on use case)
  • A live log for complete visibility of DNS queries (and their answers) that occur on your network
  • Tight integration with firewall rules disallows the easiest of DNS filtering circumvention:
    • This also hijacks the hijackers – if you have malware that changes your DNS servers to 8.8.8.8, for example, DNSthingy hijacks the DNS queries and answers them by the policy/rule set applied to the device
    • If you use the “No Internet” rule, it’s more than just a DNS firewall. All traffic is blocked while maintaining internal visibility. Perfect for a NAS or devices that should never have egress access at all (a simple way to stop exfiltration).
  • Importantly, we do not offer public resolver services at all. DNSthingy has a focus in the on-premise space where layer 2 (mac address) can be followed for IP address changes, etc. This is how we are completely different and yet integrates with OpenDNS (and other cloud public resolvers, for that matter). We also appreciate the security that DNSSEC and DNScrypt bring to Internet security, so those are included and dashboard switches for you to enable are coming shortly.

Thanks for reading, we have much more coming to our blog in the next few days!

New SafeSearch option includes Bing

Posted June 27, 2016 by David Redekop to DNS Feature

SafeSearch filters the display of explicit search results in images, videos, and text.

We’re glad to be able to offer an expanded version of our Forced SafeSearch feature. Forced SafeSearch uses the network-level enforcement method offered by Bing and Google. Here’s how the feature looks on the dashboard with a simple ON/OFF button:

Force SafeSearch option on DNSthingy.com/dashboard

This setting is now on by default for new subscribers and new Blacklist rulesets. This was much requested as iOS’s Siri uses Bing exclusively.

Why we believe Forced SafeSearch is better

It is important to note that this feature is not locking SafeSearch as utilized in the past for school/home environments. Locking and other proxy methods previously in use, could easily bypass SafeSearch by using https (SSL) instead of http. Locking SafeSearch into the browser is easily bypassed with a new private/incognito window.

The combination of network-level forced SafeSearch and alternate DNS attempts being blocked (also a default with DNSthingy in router mode) makes circumvention much more difficult.

Authoritative DNS made easy

Posted February 15, 2016 by David Redekop to DNS Feature

How often do you end up having to remember IP addresses to access internal resources such as a NAS or any of your IoT devices? Consider using names instead of IP addresses:

Before After
By IP address By memorable name
Example: http://192.168.1.10 Example http://MyNAS.local
Hard to remember Easy to remember
Might change with a factory reset Never needs to change
Incompatible with future network schemes Never needs to change
Will need to change with IPv6 Never needs to change

A better practice is to simply choose an easy-to-remember name and use your DNSthingy to create an authoritative list and enable it on your rulesets. Now you’ll never have to remember the IP address by simply following these steps, for example, if you had a NAS at 192.168.1.10 you wish to access by various names:

  1. From DNSthingy.com/dashboard, login and create a new authoritative list like this:
    Create an authoritative list
  2. Fill in the IP address and the full list of names you want to work, similar to this:
    Edit the list names
  3. Finally, enable the list in your rulesets so it looks like this:
    Authoritative list enabled

That’s it! You’re all set! Now you can always access your NAS via http://mynas.local or http://nas.local or http://yournas.local or http://newnas.local.

Important: this feature requires version 2.7.0 which will be automatically upgraded for all subscribers and non-subscribers alike.

Ad-free iOS apps

Posted December 17, 2015 by David Redekop to Blacklist Case Study DNS

iOS apps, especially with little children, are often completely unusable unless the ads and trackers are all blocked. Many parents are used to putting an app in airplane mode before letting kids play. Unfortunately that disqualifies all apps that require connectivity.

DNSthingy ad-blocking disabled: DNSthingy ad-blocking enabled:
with-iAd without-iAd

While Apple has their own iAd ecosystem, many mobile apps use alternate ad providers (mopub is a popular one), which are already blocked in our default blacklists.

But to have a truly beautiful iOS app experience and cover all the bases, follow these steps for the ruleset applied to your iOS devices:

  1. block-ads

    The blacklist above does not include hosts that prevent services from working.

  2. Now you want to create a separate list (Dashboard -> Manage Rules -> My Lists -> Create a List -> blacklist) called iAds and include these hosts:

    iadsdk.apple.com
    iad.apple.com

  3. Finally, go to your Ruleset and turn it on like this:

    block-iAds

Note: blocking Apple iAds will prevent iTunes radio (does anyone still listen to that?) from working as well as the occasional tracked ad. For most subscribers, this is a small price to pay for a superior iOS app experience.

Enjoy!

Avoid private DNS record leakage

Posted November 12, 2015 by David Redekop to DNS Feature

The nature of mobile devices that roam from site to site, often means that private DNS records unintentionally leak out to the public Internet. For example:

DNS record OK to be public visible DNS record that should remain secret
MailServer.YourCompany.com YourSecretServer.YourCompany.local

As long as your devices stay on your business network, network information leakage isn’t a concern. However, let’s say a mobile device is setup at the office with an application that references YourSecretServer.YourCompany.local and then it is taken home by a team member.

As soon as the app is launched at home, the home router is asked:

Hi, where is YourSecretServer.YourCompany.local?

And, of course, it sends that request upstream to your Internet Service Provider. Even though it cannot answer it, the DNS request (the question above) has been sent across the Internet in clear-text and therefore subject to surveillance of the most trivial kind.

To avoid this type of DNS leakage, DNSthingy firmware never allows DNS queries to be sent to the Internet unless they are part of the Mozilla Public Suffix list found at:

publicsuffix.org

In any and all foreign premises where DNSthingy answers DNS queries, when the query for YourSecretServer.YourCompany.local is asked, DNSthingy simply answers with NXDOMAIN, meaning it does not exist.

That’s how we prevent DNS record leakage in all of our current firmware versions.