Spotting A DNS Denial of Service Reflection Attack in SIE Darkspace Telescope Data

[Editor: This week, in part one of a two part series, Farsight Scientist Joe St Sauver talks about spotting denial of service (DOS) attacks from a server at the Security Information Exchange (SIE). Next week, in part two, St Sauver will discuss additional darkspace-related examples while demonstrating use of SIE Remote Access (SRA).]

Denial of Service Attacks In General

The goal of an online denial of service (DoS) attack is to make it impossible for the target of the attack to use their system or network for its intended purpose. This may be done in an effort to destroy an online competitor, as part of an extortion attempt, or simply to express rage.

While there are many different types of DoS attacks, one of the simplest is a packet-flooding volumetric attack, where the attacker sends far more traffic at his target than the target’s network connection can carry. For example, a site with a gigabit connection might be targeted for 10 gigabits worth of inbound traffic.

While the targeted site may be able to drop that traffic at its firewall, that’s too late — the attack traffic will have already used up all of the site’s network capacity before eventually being blocked by the firewall.

Denial of service attacks can last for hours, days, or even longer.

Distributed Reflective DNS Amplification Attacks

One specific type of packet flooding attack is known as a “distributed reflective DNS amplification attack.” To understand how that sort of attack works, let’s begin by reviewing the way a recursive resolver normally works.

Recursive Resolvers

A recursive resolver is a type of domain name server that helps applications (like your web browser) resolve domain names to IP addresses. For example, when you want to check out the latest sports scores at espn.com, your browser automatically asks your ISP’s recursive resolver to resolve espn.com to its IP address (which happens to be 199.181.132.250 — but you don’t need to know that because DNS “just works”).

Recursive resolvers should be, and normally are, configured by their administrators to only answer queries for their intended local users. For example, an ISP will typically run a local recursive resolver for use by their own customers, but disallow access by any/all non-customers.

Open recursive resolvers, which answer queries for anyone, anywhere, are misconfigured, and this can lead to them being misused to attack innocent third parties.

The Attack

A typical distributed reflective DNS amplification attack involves three categories of entities:

There’s a bad guy attacker A
There’s a good guy victim V, and
There are open recursive resolver(s) ORR1, ORR2, ORR3, etc.

When attacker A decides to attack his target, he generates a series of “spoofed” DNS queries, either from a single source system or from a large botnet. We say that these queries are “spoofed” because they’re intentionally created to look as if they’re actually being sent from good guy victim V, even though they’re actually being sent by attacker A. Those queries get directed by the attacker to ORR1, ORR2, ORR3, etc.

Each of the open recursive resolvers dutifully answers the queries it receives, replying with its answers to the apparent source of those queries, victim V. Because DNS queries are often small while DNS responses can be quite large, the open recursive resolver acts as a “traffic amplifier,” taking a small input and returning a large output. This is the very definition of “amplification.” The net result of many open recursive resolvers all answering spoofed questions can be a crushing amount of network traffic, hitting the targeted site from name servers all around the Internet. These attacks sadly happen all too often.

Seeing Distributed Reflective DNS Amplification Attacks As They Happen Using A Darkspace Telescope

While an attacker may potentially carefully target his spoofed traffic to only hit known-open recursive resolvers, there are so many open recursive resolvers on the Internet that some attackers may simply spray spoofed traffic against any/all IPv4 addresses. While this “wastes” many fake queries that end up being sent to IPs that don’t have an open recursive resolver on them, the attacker will still hit plenty of IPs that do have open recursive resolvers — the Open Recursive Resolver Project estimates that there are currently about 28 million of them Internet-wide

The attacker may also inadvertently “hit” something else, and that’s a “darknet,” or “darkspace telescope.” A darkspace telescope is a block of network address space that’s announced to the Internet, but which isn’t used by any end users or computers. Because there are no end users and no computers on those network addresses, there shouldn’t be any traffic coming into that network from the Internet. Anything that does hit that dark network address block is unsolicited by definition. Typically unsolicited traffic will show up, often including spoofed DNS queries looking for open recursive resolvers to exploit.

By passively instrumenting unused address space, we can see that attack traffic, and thereby get a pretty good sense of who’s currently being targeted for attacks.

SIE Channel 14

While anyone with a block of unused network address space can set up their own darknet, most people don’t have the spare address space, equipment or expertise to actually do so. Fortunately, you don’t need to go to all that trouble — you can simply arrange to get access to Farsight Security’s Darknet Channel at the Security Information Exchange (SIE)

The Farsight Security Information Exchange is best known as a terrific source of real-time DNS data, distributed as a series of real-time streaming channels, but SIE does also include darknet data on Channel 14, as well as other types of data (such as spam samples and much more).

Upon receiving access to Channel 14, you can immediately watch darknet traffic on Channel 14 just as if you’d set up your own private darknet.

Tshark

Darknet data on Channel 14 is emitted in pcap format. The most common tool to work with pcap data is a protocol analyzer. One of the most popular protocol analyzers is Wireshark (or the command-line/terminal version of Wireshark, known as Tshark).

Once you have access to an SIE blade server receiving Channel 14, ssh into your blade and become root on that system, then create a directory to hold the files you capture, and run tshark:

$ su
# mkdir /srv/test
# tshark  -B 100  -b duration:60  -a files:1  -i eth1.14  -w /srv/test/tshark.cap

Decoding that tshark command we have:

-B 100: use a 100MB buffer to help capture traffic without loss (default: 1 MB)
-b duration:60: capture traffic for sixty seconds
-a files:1: only capture one file’s worth
-i eth1.14: listen on the eth1 interface, subinterface 14 (where Channel 14 gets received)
-w /srv/test/tshark.cap: save the captured traffic to the directory /srv/test with a name that begins tshark and a .cap extension

Running that command, we ended up with a file called tshark_00001_20160503004421.cap

We can then process that file to look for DNS amplification traffic. DNS amplification traffic often requests “ANY” as a record type. Will we see any queries of that sort in our darknet sample data? Let’s check. In tshark v1.8.2 we can say:

# tshark  -r /srv/test/tshark_00001_20160503004421.cap  -T fields  -e ip.src  \
-e dns.qry.name -R "dns.flags.response eq 0 and dns.qry.type eq any"          \
| sort | uniq -c | sort -nr

Decoding that command:

-r /srv/test/tshark_00001_20160503004421.cap: read this file as input
-T fields -e ip.src -e dns.qry.name: report only the source IP & the DNS query name
-R "dns.flags.response eq 0 and dns.qry.type eq any": filter only successful DNS “any” queries
sort | uniq -c: sort the results, uniq-ify and count the results

There was only one line of results:

1854 185.75.56.115     defcon.org

Translated, over the course of one minute, the darknet’s address space saw 1,854 requests from an attacker pretending to be 185.75.56.115, looking for random open recursive resolvers to resolve the domain defcon.org for “ANY” DNS records. Why defcon.org? It returns a large response to ANY queries. This is well known/documented at sites such as:

Sadly, there are many other attacks we can dig out of even just a minute’s worth of SIE Channel 14 data, but that’s enough of an example to give you a sense of how powerful darknets can be and how this whole process works.

Fixing defcon.org and other Open Recursive Resolvers So They Can’t Be Abused

While it’s well and good to identify DOS attacks when they occur, it’s better to fix the vulnerability that’s being exploited, thereby making the attacks stop. Several steps should be taken in this case:

Any open recursive resolver should be configured so that only intended users can access that system. This page has more information on how to fix that issue.
If you run BIND for your recursive resolvers, apply Jared Mauch’s TCP ANY patch
Ensure that spoofed traffic can’t be emitted from your address space. While this will not protect you, it will help protect everyone else. A nice starting point for this topic is here.
Learn more about the underlying issues. One nice background article was written by Paul Vixie, Farsight’s CEO, entitled “Rate-limiting State: The edge of the Internet is an unruly place,”.

Conclusion

There’s a lot more that we could look at in our darknet packet captures so why not sign up for access to SIE Channel 14, and see what else is happening yourself?

Commercial users are charged a fee for access to SIE, but university academic researchers and “Internet superheroes” (those working to combat online abuse as an uncompensated “labor of love”) can ask to receive low cost/no cost grant access to SIE, including access to darknet data on Channel 14. To learn more about getting access to SIE Channel 14, please contact Farsight Sales at [email protected].

Joe St Sauver, Ph.D. is a Scientist with Farsight Security, Inc.

Read the next part in this series: Accessing Darknet Telescope Data via SIE Remote Access (SRA)