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?

How and why we force router DNS

Posted March 1, 2018 by David Redekop to Feature

It’s amazing how DNS (the Internet’s “phone book”) can have so many different variations of how it’s used and abused. It’s a fundamental building block insomuch as the Internet is almost entirely useless without it.

On all of our platforms, DNS is forced when using the standard port and protocol over TCP and UDP port 53. Here are the firewall rules that are installed with our service:

On pfSense, these rules (among others) are inserted, but we’re showing just the DNS-forcing ones here on this screenshot:

On ASUS routers as well as ClearOS/Linux variations, the iptables rules look like this at the command-line in a typical setup (sorry there’s no GUI for these rules on AsusWRT):

This command will show and include the forcing rules:

iptables -L DNSthingy -nv -t nat --line-numbers

The result:

Chain DNSthingy (1 references)
num pkts bytes target prot opt in out source destination
2 645 44407 DNAT udp -- * * 0.0.0.0/0 !192.168.11.1 udp dpt:53 to:192.168.11.1:53
3 2 80 DNAT tcp -- * * 0.0.0.0/0 !192.168.11.1 tcp dpt:53 to:192.168.11.1:53

These types of rules are also referred to as DNS hijacking rules. Hijacking in a good sense, of course, because if you have a reason to distrust a device, you want to at the very least hijack its DNS usage to apply the policy of the router.

Benefits of forcing DNS

  • DNS poisoning is mitigated, especially when the attacker has a publicly-available DNS server that is being used by silently changing internal client device DNS settings (like DNSchanger does).
  • Convenience for devices with static DNS configured. Sometimes devices have statically assigned themselves a DNS server, now it doesn’t matter what public DNS resolver is statically set on a client device because the hijacking rule forces the router’s DNS to be used.
  • Endpoints require no DNS management. Since the forced DNS settings are applied, no customization is required on a per-endpoint basis.

Important note on DNS benchmark tests

Steve Gibson has an awesome freeware Domain Name Speed Benchmark utility we often recommend.

When DNS usage is forced, it makes it impossible to benchmark public DNS resolvers from “behind” one of these gateways. During benchmark tests, you want to disable the hijacking rules temporarily.

To disable these rules on AsusWRT or Linux, which will delete line number 2 and 3 based on the query above:

iptables -D DNSthingy 2
iptables -D DNSthingy 3

After ASUS reboot and/or Linux networking restart, the firewall rules will once again be auto-applied.

To disable these rules on pfSense, simply click on the checkmark to disable it, and apply the changes. After the benchmark tests are run, the rules can be enabled once again.

WARNING: Forcing DNS on port 53 alone won’t force all DNS

As a result of port 53 DNS enforcement on many edge devices, endpoint security software has begun to work around it. For example, Webroot uses port 7777. AVG and several others use port 443. Of course it’s easy to simply block destination port 7777 but when it comes to port 443 that’s not so easy as you would be blocking HTTPS (with TCP) and you’d be blocking QUIC (with UDP). This is where the zero trust model comes in.

Attack of the Internet of ‘Thingys’ episode

Posted January 26, 2018 by David Redekop to Press

David Schropfer invited us to his show this week…

Sobering report from the World Economic forum. And, by ‘sobering,’ it means: if you don’t already have a drinking problem, this could cause one!
We talk about the IoT Christmas, and new things to watch out for:

Great interview with David Redekop of DNSthingy: Internet of things, Botnets and more… Wrap up by answering a few guest questions

If you’re interested in how threats occur in the modern days we talk about a variety of bad actor approaches and how they can be addressed or mitigated including an important role by Quad9.

Here’s the link directly to the episode:

https://www.voiceamerica.com/episode/104958/attack-of-the-internet-of-thingys

Blocking third party ads – a security feature

Posted January 23, 2018 by David Redekop to Security

In hindsight, we have verifiable information that blocking of third party ad networks is a necessary security precaution:

These ads and misleading displays are blocked with our default Rule Set which blocks third party ad networks including ones mentioned by Arstechnica.

Keep safe!

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 zero trust protects from crunchyroll hack

Posted November 5, 2017 by David Redekop to Case Study DTTS

Crunchyroll is in the top 1,000 sites globally. When a site this popular is hacked to distributed malware, it’s a big deal. Here’s an overview of how the hack worked:

The homepage suggested a new player to download, which, when you look at the source, was a actually updating the player from somewhere else *other* than crunchy roll:

It is worth noting that when websites are hacked for malicious intent, the actual payload is never hosted on the hacked site. The attacker simply changes the content of web server files so that unsuspecting visitors retrieve the malicious payload from a server elsewhere, usually one that is more completely controlled by the attacker.

In short, the victim’s computer retrieves the crunchyroll.com home page but along with it a request to download a new player from the attacker’s choosing. In this case, the IP address of 109.232.225.12 is based in the Netherlands, but even leading threat intelligence providers had no negative reputation scores for this IP address. Furthermore, the malware-laden CrunchyRoll.exe was digitally signed, allowing this to sneak by many layers of typical cybersecurity protection.

Compare that with the Zero Trust Model with what we call Don’t Talk To Strangers. “Strangers” are IP addresses that were not preceded with a DNS lookup. To use an example different from the Crunchyroll hack, consider if you want to ping 8.8.4.4 (and the result fails, in red below) vs ping google-public-dns-b.google.com (which succeeds in pinging 8.8.4.4 because it was preceded with a DNS lookup, in green below).

The zero trust model deployed in this manner protected Crunchyroll visitors from the very first moment their site was hacked. It provides the same protection for any other similar type of attack.

Version 3.2 firmware upgrade

Posted October 31, 2017 by David Redekop to Feature

When your device auto-upgrades to version 3.2, you will enjoy the following enhancements:

1. Block page now utilizes an IP subnet (vs a single static IP on the LAN interface). This allows for faster unblock page processing, coming shortly.

2. Better NetBIOS name discovery. In cases where our service host is not the DHCP server, better name discovery is now included.

3. IP enforcement and DNS services combined into a single service. Previously there were two processes in place to facilitate load balancing across devices, but in cases where only one appliance is in use, a single process is more efficient.

4. Under mytools.management/log, logging capability has been enhanced with many view filter options (Status, IP, Name, Answer, Rule, Rule Kind, etc).

5. Logging capability addition for traffic logging in order to easily visualize blocked/allowed packets while narrowing the list down by source, destination or blocked/allowed status

Better Browser Experience for blocked SSL sites

Posted September 7, 2017 by David Redekop to Feature

Traditionally, DNS-level filtering for SSL has been problematic because the block page SSL certificate would never match the host header requested by the browser.

For example, https://badactor.co access would be presented with https://someblockurl.com certificate. This would result in the end-user having to approve an SSL mismatch warning, illustrated to the right, which incidentally, is exactly what bad actors would do with DNS poisoning attacks. This makes it very difficult to train end-users when to ignore and when to heed warnings like that!

Our approach is different. By default, all TCP port 443 (used for TLS/SSL connections) that attempt to connect to the block page server are rejected (a TCP reset). This achieves the following results:

  • End-user device response is immediate, so the user isn’t waiting and wondering what’s going on
  • Bandwidth usage is reduced
  • Device resources are never congested due to wait times

Some DNS-based SSL blocking approaches, will offer a DNS answer of 0.0.0.0 which achieves the above results as well, but then cannot present the end-user with anything helpful.

What we do want, is for the end-user to have some sort of feedback to indicate what just happened. This is where our browser extension comes in handy. To see it in action, here’s a short demonstration:

And here’s a direct link to the knowledge base article with further details and extension access.

Now you can enjoy a user-friendly SSL block page experience!

How a scam should fail

Posted August 25, 2017 by David Redekop to Case Study Security Whitelist

I’m dumbfounded at how often I personally receive deceptive SMS messages like this one here I just received:

When I opened the message, I see that it would be a motivating message for someone to click on if there’s hope to receive some “refund”, even if it’s someone else’s:

Fortunately I was confident with our zero trust model that I could go ahead and click on the link and was unable to go any further:

This is really what it looks like when you protect an end-user, even if that’s yourself 🙂