The Dyn attack on October 21, 2016 has been a big topic of conversation in cybersecurity circles. I was off work that day and didn't learn about the attacks until Saturday, when friends and family started asking me what happened. From reading Brian Krebs' blog over the past month, I made an educated guess that it had something to do with the Mirai botnet. It appears that, in part, my guess was correct. This blog post is not about the Mirai botnet, the big name companies that people couldn't access, or vulnerable Internet-of-things devices. This post is about indirect participation in the attack and its effects.

Don McKeon and I spent some time during the week following the attack checking out what network flow traffic looked like during the Dyn attacks. While our initial goal was to see if we could spot indications of active participation in the attacks, other things we found were more interesting. I'm sharing them here.

First, if you need a "layman's" overview of the Dyn attack, the SANS Internet Storm Center has a video (or slides if you don't have 16 minutes to watch the recording).

Don and I looked at the Internet traffic destined for Dyn's address space on the day of the attack, the two days prior to the attack, and the Friday before. We found the Dyn address space by looking up their autonomous system number (ASN 33517) in the pmap (Section 4.7) files we construct daily from Border Gateway Protocol (BGP) routing data.

From this network traffic, we looked at the protocols and ports used, and the number and sizes of flows that occurred. We compared these values across time. When we looked at the number and volume of flows, we summarized them by internal IP address and plotted the values using a pivot table in a spreadsheet.

We noticed no significant differences in the type of traffic or the internal IP addresses communicating with Dyn during versus before the attacks. What we did notice were large increases (2-3 times) in the volume of UDP DNS (port 53) traffic. These extra flows were similar to those seen outside the attack times; there were just more of them. They do not appear to be related to active participation in the attack. Here is why we think this finding is significant:

• If you or your users tried to visit sites that used Dyn for DNS during the attacks, you were probably an indirect participant. Devices that perform DNS queries are seldom configured to ask for the information they need only once. Most will retry a query at least twice for any DNS server that could answer the question before returning an error to the user. These retries mean that if an organization sends its normal number of requests to a non-responsive DNS server, the actual traffic volume going to that DNS server at least doubles. For a DDoS attack, this behavior can make it difficult for a victim to separate legitimate traffic from attack traffic.
• If you or your users tried to visit sites that used Dyn for DNS during the attacks, you may have been indirectly impacted. The obvious impact--that you and your users could not get to your desired websites--is not what I mean. Rather, I'm talking about another side of this situation: multiple DNS retries mean you are sending at least twice the normal volume of DNS traffic to certain resolvers. If your organization is a heavy user of Dyn DNS resolution, this volume could represent a significant spike in the overall network traffic volume, which could degrade your network performance if you are already constrained or it could adversely impact your own internal DNS resolver. The increase can also skew traffic reporting (how should this be accounted for in trending or baselining a system?) or trigger alerts from anomaly-detection systems.

The bottom line is that attacks against popular Internet services can have residual effects across organizations that are neither targets nor direct participants. It is important for organizations to be aware of these possible effects so they can respond, if necessary, and understand where they may have more subtle influence on business operations, analysis, and planning.

DDOS attacks are occurring at an increasing rate. Given the abundance of soft targets on the Internet that can be used to participate in these type of attacks, another attack similar to Dyn is surely soon to follow. It is becoming increasing important for organizations to be aware when attacks occur like the one on Dyn.

Oh, and if you're looking for information on how to detect if you actively participated in the Dyn attack or Mirai botnet, here are a few things you can check:

• Did you have non-internal resolvers directly querying Dyn?
• If you don't have all clients going through internal resolvers, did you have new clients making queries to Dyn during the attack windows?
• Do you have devices making lots of outbound telnet (port 23) or port 2323 connections?

If you want to be proactive in making sure that you do not have devices that participate in a future attack, there are two things that you can do:

1. Disable WAN/UPnP access to and from your devices.
2. CHANGE DEFAULT PASSWORDS!

Did you notice anything else abnormal in your traffic during the Dyn attacks? Have comments or questions? Let us know!