[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 impossiblefor the target of the attack to use their system or network for its intendedpurpose. This may be done in an effort to destroy an online competitor, as partof an extortion attempt, or simply to express rage.
While there are many different types of DoS attacks, one of the simplest is apacket-flooding volumetric attack, where the attacker sends far more traffic athis target than the target’s network connection can carry. For example, a sitewith a gigabit connection might be targeted for 10 gigabits worth of inboundtraffic.
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 thesite’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 asa “distributed reflective DNS amplification attack.” To understand how thatsort of attack works, let’s begin by reviewing the way a recursive resolvernormally works.
Recursive Resolvers
A recursive resolver is a type of domain name server thathelps applications (like your web browser) resolve domain names to IPaddresses. For example, when you want to check out the latest sports scores at
espn.com
, your browser automatically asks your ISP’s recursive resolver toresolve
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”).
Sometimes Not Sharing Is The Right Thing To Do
Recursive resolvers should be, and normally are, configured by theiradministrators to only answer queries for their intended local users. Forexample, an ISP will typically run a local recursive resolver for use by theirown customers, but disallow access by any/all non-customers.
Open recursive resolvers, which answer queries for anyone, anywhere, aremisconfigured, and this can lead to them being misused to attack innocentthird parties.
The Attack
A typical distributed reflective DNS amplification attack involves threecategories 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 largebotnet. We say that these queries are “spoofed” because they’re intentionallycreated 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 getdirected 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 inputand returning a large output. This is the very definition of “amplification.”The net result of many open recursive resolvers all answering spoofed questionscan be a crushing amount of network traffic, hitting the targeted site from nameservers 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 toonly hit known-open recursive resolvers, there are so many open recursiveresolvers on the Internet that some attackers may simply spray spoofed trafficagainst any/all IPv4 addresses. While this “wastes” many fake queries that endup being sent to IPs that don’t have an open recursive resolver on them, theattacker 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 ofnetwork address space that’s announced to the Internet, but which isn’t used byany end users or computers. Because there are no end users and no computers onthose network addresses, there shouldn’t be any traffic coming into thatnetwork from the Internet. Anything that does hit that dark network addressblock is unsolicited by definition. Typically unsolicited traffic will showup, often including spoofed DNS queries looking for open recursive resolversto exploit.
By passively instrumenting unused address space, we can see that attacktraffic, and thereby get a pretty good sense of who’s currently being targetedfor attacks.
SIE Channel 14
While anyone with a block of unused network address space can set up their owndarknet, most people don’t have the spare address space, equipment orexpertise to actually do so. Fortunately, you don’t need to go to all thattrouble — you can simply arrange to get access to Farsight Security’s DarknetChannel at the Security Information Exchange (SIE)
The Farsight Security Information Exchange is best known as a terrific sourceof 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 typesof data (such as spam samples and much more).
Upon receiving access to Channel 14, you can immediately watch darknet trafficon Channel 14 just as if you’d set up your own private darknet.
Tshark
Darknet data on Channel 14 is emitted inpcap format. The most common tool to workwith pcap data is aprotocol analyzer. One ofthe 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 yourblade and become root on that system, then create a directory to hold the filesyou 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 saw1,854 requests from an attacker pretending to be
185.75.56.115
, looking forrandom 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:
- http://dnsamplificationattacks.blogspot.com/2014/12/domain-defconorg.html and
- http://www.nothink.org/honeypot_dns.php
Sadly, there are many other attacks we can dig out of even just a minute’sworth of SIE Channel 14 data, but that’s enough of an example to give you asense 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 betterto fix the vulnerability that’s being exploited, thereby making the attacksstop. Several steps should be taken in this case:
- Any open recursive resolver should be configured so that only intended userscan 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. Whilethis will not protect you, it will help protect everyone else. A nice startingpoint for this topic is here.
- Learn more about the underlying issues. One nice background article waswritten 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 whynot sign up for access to SIE Channel 14, and see what else is happeningyourself?
Commercial users are charged a fee for access to SIE, but universityacademic researchers and “Internet superheroes” (those working to combatonline abuse as an uncompensated “labor of love”) can ask to receive lowcost/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 contactFarsight 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)
Heading
