Traffic Flood

As we covered previously, traffic floods consist of attacks that consume resources such as bandwidth and packet processing capacity. If you imagine an internet connection as being a water pipe and the traffic being water inside of the pipe, the flood of traffic will be a momentary burst of water that fills up the whole water pipe.

One might ask the question, “Why not just get a bigger pipe?” It is true that the problem can be mitigated at this point in time by adding capacity, but that solution will not scale as attacks grow in size. Please also keep in mind that there is a monetary cost to adding this additional capacity. If this capacity is merely “attack insurance” then it is more challenging to justify.

Source Spoofing

While IP source spoofing is not an attack on its own, it is an important concept to understand. As explained by Wikipedia:

In computer networking, IP address spoofing or IP spoofing is the creation of Internet Protocol (IP) packets with a false source IP address, for the purpose of hiding the identity of the sender or impersonating another computing system.

An attacker can spoof the source address of the attack when connected to an ISP or a provider that allows this. “How can the ISPs be so careless and trusting to allow spoofed IPs?”, you ask. Well, if you go back to the early days of the internet, it was a wide-area network connecting local academic and research networks that were mainly trustworthy. Therefore, the basic design of the IP protocol and infrastructure do not generally take into consideration the fact that some malicious user can create fake source IP address for the purpose of attacking others.

It is important to point out that when sending traffic from spoofed addresses, the attackers have no intention of receiving a response. We can use this fact to our advantage when we try to identify spoofed IPs and mitigate against the attacks.

Reflection and Amplification

The mechanics of reflection relies on a system to source a reply from the reflection point to direct the response to the spoofed source. If you recall our favorite pizza shop example from Chapter 1 (Figure 1-6), our bad guy friend is pretending to be Mike (spoofed source) and calling the pizza shop (reflection point). If successful, Mike and the pizza shop are both victims, with Mike sustaining a loss of productivity and the pizza shop potentially losing money and resources.

If we apply the same concept in the digital world, when we have a UDP-based service that does not validate source IP, coupled with an attacker’s ability to spoof IP, they form the basis of a large-scale DDoS attack. We have already seen an example of the UDP reflection flow in Figure 1-7 back in Chapter 1.

In Figure 3-1, we can see that the majority of the flood attacks consist of amplification floods.

Figure 3-1. Attack protocol frequency (source: http://ddosmon.net/insight)

Digging into amplification as a method, we can break down the popularity of different protocols used. Each has its own qualities that make it more enticing to the attacker. In Figure 3-2, the graphic gives us an idea of the popularities of amplification protocols as of this writing. DNS makes up half of the amplification attack traffic seen on the internet, with NTP, CLDAP, Chargen, and SSDP following close behind.

Figure 3-2. Frequency of protocols used for reflection (source: http://ddosmon.net/insight)

This amplification and reflection would be particularly damaging when a small request produces a large response. There are lots of well-documented attacks using this reflection and amplification method with DNS, NTP, and SNMP.

Reactive Versus Proactive Always-On Mitigation

The first driver for your mitigation topology is to determine if you want a reactive or proactive always-on approach. The main trade-off is the infrastructure cost. Your network and system’s first job is to accomplish your business goals, whether that is to attract business leads, communicate your mission, or to sell items online. In order to accomplish that, your infrastructure needs to run as lean as possible. If you were to place an always-on mitigation solution by watching the network traffic at all times, this would translate to additional overhead and cost. Since this device is the gatekeeper, it needs to be provisioned with as much capacity as your network, with the same availability goals; otherwise, it will become a bottleneck.

In a proactive always-on mitigation, your mitigation device might be a purpose-built device that watches over all the traffic. This device or layers of devices will need to be placed in between the external and internal network to prevent external threats.

On the other hand, if you were to choose a reactive mitigation, you might be able to scale out the solution better. You can use routing protocols to divert traffic toward the mitigation layer only when needed. Since the mitigation devices are only used when needed, you only need capacity that can sustain the attack volume and not necessarily your overall network capacity.

The downside of a reactive mitigation compared to a proactive model might be the added complexity and additional delay introduced. The added complexity of routing requires additional planning, configuration, and knowledgeable staff. The delay occurs between the time we detect an attack and the time it takes for routing to kick in and onramp the traffic toward the mitigation device. This delay is also realized as service impacting if the attack is large enough to overwhelm the target resources.

Potential Points of Attack Mitigation

Regardless of whether the mitigation approach is proactive or reactive, it makes sense to place the DDoS mitigation devices as close to the attack source as possible. You do not need to carry all the “dirty” traffic across your network just to drop them deep within your network, where other scale problems could come to light, making it a waste of network resources. Therefore it is beneficial to drop all the traffic you need to drop as early as possible. In a typical network where the attacks are coming in from the internet, the mitigation should be as close to the edge as possible.

In Figure 3-3, we are placing a dedicated, purpose-built, reactive mitigation system between the internet edge and the core portion of the network. When you need to mitigate, the traffic is redirected toward the mitigation systems, and clean traffic is passed back to the network.

If you utilize cloud-based mitigation, the redirection will almost always take place outside your network border. The traffic is redirected via DNS or BGP before they ever reach your border device, and clean traffic is returned back to your premise via physical or virtual tunnel links. In this case, the mitigation point is outside your organization.

Figure 3-3. Asymmetric reactive mitigation (source: http://bit.ly/2DW99GD)

It is worth noting that the actual mitigation technique could be a feature on your existing devices such as IPTables or an Access List instead of dedicated scrubbing hardware. If facing a choice of where to turn on mitigation, the same general approach should be taken. The mitigation feature should be enabled as close to the internet edge as possible.

Effective DDoS attack mitigation involves more than just one control and data plane tool. In most infrastructure, there are tools already at your disposal that you should take advantage of. In other cases, a dedicated mitigation device should be deployed. The key is to find the right tool to take care of the right attack. Let’s explore some common tools in the following sections.

Purpose Built DDoS Mitigation Devices

These systems are the most flexible but carry a higher price tag than their network device peers. They can provide both stateless and stateful functions. Since they are purpose-built, they are focused and effective in dealing with most of the common DDoS attacks we have seen in this book. However, the downside is they are yet-another-device that you have to manage and another skill set you have to staff for. Also, due to the high price tag, they are generally reserved for entities who can justify the dollars spent.

In the following sections, we will apply the theories we have learned so far in this chapter and apply them toward mitigating two of the most common DDoS attacks: combating the classic flood and combating the state exhaustion scenario.

Analyzing the Attack

Let us take a look at a snapshot of a DNS amplification attack packet in Figure 3-5 as seen by the attack target for the purpose of device a mitigation strategy.

Figure 3-5. DNS amplification packet

A few key characteristics can be identified:

1. All of the packets in question are from UDP source port 53 (normal for DNS responses) with a trailing set of IP fragments.

2. All packets are large for UDP DNS (not necessarily bad).

3. The DNS responses are for an ANY query.

4. There are a very large number of answers.

5. Each response is for the same domain name. The domain name itself is unimportant. The attacker has found one that behaves to their liking and they use it as a packet generator.

Let us zoom out and look at the packet distribution in this “lag” attack that was sent in pulses with a variety of attacks in Figure 3-6. The green line (top line) in this case, represents the DNS responses with fully formed DNS headers. The blue line (second line) shows all of the trailing IP fragments. The red line (third line) is the attack target server, which is not listening on any destination ports. It is sending back ICMP port unreachable messages in 100 ms increments.

Figure 3-6. Packet distribution of attack

From the packet trace and packet distribution analysis, we can see that the DNS behavior is not what you would expect. If the DNS ANY response is large, the DNS server should have switched the conversation from UDP to TCP. To successfully carry out the attack, the whole transaction must be in UDP and use an open DNS resolver that supports extension mechanisms for DNS or EDNS0.

We are now ready to construct our mitigation strategy. 

Mitigation Strategy

To successfully mitigate this attack, it is important to understand if it is your internet edge that is saturated or if it is a bottleneck that leads to a service that you are protecting. Protecting the internet edge in this scenario is challenging with on-premise techniques. If you have a 10-Gb per-second internet connection, and there is greater than 10-Gb per-second traffic destined to your company, there is little you can do with on-premise equipment.

Let us explore some of the options on hand:

1. We can try to reduce the dependency on off-net DNS transactions.

   This is probably easier said than done. The reason that this is imperative is that these are DNS responses, and most of our legitimate DNS responses will look similar to the attack aside from the fact that you may have responses from millions of previously unknown DNS servers

2. You can drop or rate-limit UDP source port 53 at the internet edge.

   This is a reasonable measure especially if you do it during attack time as a reactive measure. To aid this effort, perhaps you can have an off-net DNS server that is explicitly allowed but rate limited. To drop UDP source port 53 traffic, you have a few options:

   • Call your upstream provider and tell them to drop source port 53 during the attack.

   • Make the list of source ports to drop more dynamic using BGP Flowspec, if your provider supports such feature, so the blocked list is only constructed during time of attack.

3. Blackhole

   You can instruct your upstream provider to blackhole or null route the attacked destination. This is probably the last option resort, as you are letting the attacker take out the host/device/service that is under attack; however, it may be more important to save the rest of the hosts in the network.

Let us take a look at a second example of combating the state exhaustion DDoS attacks.

Attack Dynamics and Analysis

According to Wikipedia:

Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. It accomplishes this by opening connections to the target web server and sending a partial request. Periodically, it will send subsequent HTTP headers, adding to—but never completing—the request. Affected servers will keep these connections open, filling their maximum concurrent connection pool, eventually denying additional connection attempts from clients.

In Figure 3-7, we have dissected the packets coming in from a Slowloris attack.

Figure 3-7. Slowloris packet capture

What you see here is a session generated by slowhttptest. It is important to notice a few properties of the attack:

• The length of the entire session is 30 seconds due to the RST sent by the server. The attacker could have kept the session open for much longer if this didn’t happen. This shows the intent of keeping sessions open for quite a while.

• The TCP window size of the attacker is quite small but not unreasonably small at first, especially considering windows advertised by mobile devices.

• The page that is being served by the target is just the Apache default page. However, the transmission is stretched across many packets at a slow interval due in part to the small window size.

• The attacker’s advertised window hits 0 and stays there after the 4-seconds mark.

The effect in the test environment of one attacker versus one server is pretty telling. Notice the behavior of Apache after 20 seconds of slowhttptest traffic in Figure 3-8.

Figure 3-8. SlowLoris packets per second

The green line (top line) shows our attacker sending HTTP GETs to the server. The server reached its own threshold at approximately 12 seconds into the test. At approximately 27 seconds, we see the effects clearly as out-of-order packets (represented in red) increase and Apache sends a 504 code for as many GET requests as it can handle. Finally, Apache dies at 41 seconds while the tool continues to run.

Let us devise a mitigation strategy appropriate for the session exhaustion attack.

Mitigation Strategy

We will focus on using the host as a mitigation strategy. In our scenario, Apache has a few features that can be tweaked to help with this type of attack.

The mod_reqtimeout Apache module, shown in Example 3-2, has a few options that give you insight into how it may help with the attack.

<IfModule mod_reqtimeout.c>

  RequestReadTimeout header=20-40,MinRate=500 body=20-40,MinRate=500

</IfModule>

This configuration instructs Apache to wait for 20 seconds to complete the HTTP header transfer. If the client maintains sending the header at 500-bytes per second, then the server will wait for up to 40 seconds for the header to complete.

The purpose of modQOS is to add some constraints around server resources and the types of clients that you wish to serve. A few configuration options of note that are helpful for this attack follow:

QS_SrvMaxConnPerIP

Slowloris does not require a large number of sources to be effective. In fact, it is one of the selling points of the attack that an attacker could take down a server with a low-powered PC. This feature places a ceiling on the number of connections established per source IP address.

QS_SrvMinDataRate

Slowloris achieves its goal primarily by launching many slow connections and trying to maintain them for as long as possible. This option allows the server to drop a connection based on a minimum speed

You can find out more information on mod-qos at http://mod-qos.sourceforge.net/.