What is a DDoS attack ?
A denial of service (DoS) attack is any attack that prevents a legitimate user from accessing a network resource. A distributed denial of service (DDoS) attack is one that uses multiple network resources as the source of the specific attack vector. The use of multiple resources is primarily intended as a method to amplify the capabilities of a single attacker, but it can also help to conceal the identity of an attacker and complicate mitigation efforts. Most DDoS attacks leverage a “botnet”, which is a network of Internet connected computer systems centrally controlled by an attacker (Figure 1.1). Botnets can range in size from a handful of systems to tens of millions. Most botnets use compromised computer resources without the knowledge of the owner.
Within the larger scope of information security, DDoS attacks fall within the “Availability” pillar of the CIA Triad (Figure 1.2).
DDoS differs from other areas of information security exploitation that attempt to alter or gain access to data to cause harm. DDoS attacks are predicated on the notion that it is the legitimate user’s access to the data that provides value for an organization, and removing that access causes the most harm.
Explanation
A denial of service attack is any attack that results in an outage of a network resource.
This often involves large volumes of network traffic, but may also be accomplished through low volume exploitation of protocol or application weaknesses.
DDoS Impact
Damage to Reputation
By causing an outage, an attacker can negatively impact the reputation of a company.
Direct Revenue Loss
An outage to a network resource that directly generates revenue, such as E-commerce or online media, can directly impact an organization.
Lost Productivity
A DDoS attack often prevents employees from performing their normal responsibilities.
Attack Smokescreen
A DDoS attack can be used to hide other nefarious activities from information security personnel.
Attacker Motivations
Extortion
A common motivation for DDoS attacks is the extortion of money from the targeted company. In a typical DDoS extortion scheme, the attacker will anonymously contact the victim organization to request a specific amount of money to be paid to prevent a future attack. Often the attacker will prove their capabilities by performing a limited DDoS attack at a specific time. The anonymous transfer of funds is usually carried out using the Bitcoin virtual currency. A cyber-criminal gang known as DD4BC was exposed in December 2015 for operating a massive DDoS extortion ring.
Hacktivist
Within the scope of DDoS, “hacktivism” is the use of DDoS to promote a specific political agenda. An attack of this type will often be preceded by a public statement from the attacker on social media or other public forums detailing a specific grievance or manifesto. Victims of these attacks are often well established brands or companies that are likely to suffer substantial reputation damage from the associated customer impact and news coverage. The most well known example of this type of attacker is the loose hacktivist collective “Anonymous,” which has claimed responsibility for DDoS attacks targeting Bank of America, Visa, Mastercard, the Church of Scientology and many others.
State-sponsored/Cyber terrorism
A cyber terrorism campaign involves a nation or terrorist organization performing a DDoS attack. The primary goal is often the silencing of speech from certain sources, or the substantial disruption to the target’s telecommunications infrastructure and commerce. These types of DDoS attacks are generally much larger and better orchestrated due to the significant resources of the attacker. A suspected example occurred in March 2015 when a DDoS barrage originating from China targeted specific anti-China resources hosted on Github. Other examples include a three week DDoS attack in the spring of 2007 targeting the country of Estonia, which effectively disconnected the country from the Internet. The attack was linked to a political dispute with Russia.
Personal Vendetta
The historical origins of DDoS are primarily from online disputes between individuals or small groups. These types of attacks grew in popularity during the late 1990s in online chat systems. The primary purpose of these attacks is to “punish” someone for a perceived wrong, or silence their speech. These types of attacks are still prevalent today.
Business Rivalry
The purpose of these attacks is to cause financial impact or embarrassment to a business competitor. These attacks are typically long in duration, and target resources responsible for revenue generation, such as E-commerce systems. The advent of DDoS-for-hire services, where someone can purchase a DDoS attack for less than $20, has facilitated and made this type of attack more common.
Networking Refresher
OSI model
Throughout the training portal, references will be made to the Open Systems Interconnection (OSI) model. This is a conceptual model that standardizes communication functions within network connected systems. Most DDoS attacks fall within layers 3, 4 and 7 and subsequent courses will discuss these areas in detail. An understanding of the OSI model is not required for novices, but is recommended for advanced trainees.
| Layer | Protocol Data Unit | Purpose | Examples |
|---|---|---|---|
| 7 Application | Data | High-Level Application APIs | HTTP, HTTPS, DNS |
| 6 Presentation | Data | Data translation between a service and application | CSS, HTML, XML, JSON |
| 5 Session | Data | Managing communication | RPC |
| 4 Transport | Segment/Datagram | Transmission of data between points on a network | TCP, UDP |
| 3 Network | Packet | Management of a multi-node network | IPv4, IPv6, ICMP |
| 2 Data Link | Frame | Transmission of data between physically connected devices | PPP, L2TP |
| 1 Physical | Bit | Transmission of data stream over a physical medium | DSL, Ethernet |
WAN routing/connectivity
The Internet is a collection of interconnected computer networks that communicate using IPv4 or IPv6 protocols (Figure 1.3). Small networks, such as those of a home user or a small business, connect to the Internet through larger Internet Service Providers (ISPs). ISPs and other large networks connect to each other through one or more public and private peering points where network traffic can be exchanged. The connections between network devices consist of fiber optic or copper cabling with a specific maximum capacity. The interconnection of large networks is primarily managed by the BGP protocol which creates a mechanism for exchanging route (or path) information. This routing information allows an Internet connected network to advertise to the entire Internet the paths to reach that network.
Figure 1.3: WAN Connectivity
IPv4/IPv6
The Internet Protocol is the protocol that all Internet connected devices use to communicate on the Internet. All higher layer protocols (on the OSI model) are encapsulated within this lower level protocol. The header of an IP packet contains a variety of information, most importantly the source and destination address for the network devices that are communicating.
TCP
The Transmission Control Protocol (TCP) is a layer 4 protocol (on the OSI model) and is used to establish virtual circuits between two applications. A virtual circuit is a reliable, connection-based communication channel. TCP data is contained within an IP packet and is made reliable by the addition of checksums, ordering information, and an acknowledgement mechanism. Communication on a fully established TCP virtual circuit is difficult to forge. The TCP 3-way handshake is illustrated in Figure 1.4.
Figure 1.4: TCP 3-way HandshakeFigure
UDP
The User Datagram Protocol (UDP) is a layer 4 protocol (on the OSI model) and is used for connectionless transmission of data between applications. UDP contains a checksum, but does not ensure reliability or ordering of data unless it is implemented within a higher layer protocol. Due to this limitation, an attacker can often forge a UDP based communication.
UDP is a connectionless protocol that doesn’t provide a handshake mechanism. As a result, most applications built upon UDP do not have a mechanism to verify the client IP address. This capability may be added by the application protocol, but generally doesn’t exist.
ICMP
The Internet Control Message Protocol (ICMP) is contained within an IP packet but is often considered a layer 3 protocol (on the OSI model). The protocol is primarily used for intermediate network devices to communicate error messages back to a sender of data. ICMP contains a checksum, but does not ensure reliability or ordering of data. Due to this limitation, an attacker can often forge an ICMP message.
HTTP(S)
The Hypertext Transfer Protocol (HTTP) and its encrypted counterpart HTTPS are layer 7 application protocols used for communication of data on the World Wide Web. Both HTTP and HTTPS requests are sent within TCP virtual circuits, resulting in a reliable communication channel. The use of TCP makes the forging of certain client information such as source IP addresses very difficult.
DNS
The Domain Name System (DNS) protocol is a mechanism for applications to obtain IP address information for human readable network names. The DNS protocol primarily operates over UDP, but may also operate over TCP for certain large information transactions and for legacy compatibility. DNS requests that are issued using UDP can easily be forged to contain a fake source IP address. It is very difficult to forge the source IP address of a DNS request sent over a TCP virtual circuit.
BGP
The Border Gateway Protocol (BGP) is the mechanism by which networks on the Internet connect to each other (peers). Upon establishing a peering session with a network, each BGP participant exchanges routing table information containing all networks that are reachable through the peer.
Conventions
Packet Captures
The packet captures referenced throughout the training portal are in the default format commonly associated with the tcpdump utility. An example output is shown below with certain fields explained. A more complete explanation of the format can be found on the tcpdump website. An understanding of this output is not required for novices, but is recommended for advanced trainees.
Metric Graphs
The metric graphs referenced throughout the training portal are generally displayed as time series data with the chronologically most recent data points on the right-side of the X-axis.
Bandwidth Attacks
Overview
This course covers volumetric DDoS attacks, one of the most common forms of DDoS attacks. Upon completion of this course, the participant will have an understanding of how volumetric DDoS attacks work, why they are so effective and how they can be mitigated.
Definitions
Bandwidth
The volume of data on a network link. This is often measured in megabits-per-second (Mbps) or gigabits-per-second (Gbps). Bandwidth is often used as a measure of the maximum capacity of a network link.
(1 Gbps = 1,000Mbps = 1,000,000Kbps = 1,000,000,000bps)
Botnet
This is a globally distributed group of computers that have been exploited so that an attacker may use them to initiate DDoS attacks. A botnet may consist of end-user systems located on residential Internet connections, or high capacity servers on well connected networks. Botnets may even exploit seemingly innocuous devices connected to the Internet such as Internet of Things devices (smart home systems, CCTV, smart TV’s, etc.). The owner of the resource is often unaware that their resources are being used to launch DDoS attacks.
Null Route
This is a network route that goes nowhere. All matching traffic is simply discarded.
Attack Overview
A volumetric DDoS attack is any attack that attempts to overwhelm the target by saturating the available network capacity. This course is specific to volumetric attacks originating from a botnet. A subsequent course will provide details of a reflected volumetric DDoS attack.
The Internet consists of a vast number of individual networks all interconnected to each other. Large, well connected networks (ISPs) provide access to smaller networks. The connections between these networks all have a finite amount of bandwidth capacity which is often fixed due to technical or contractual limitations. Regardless of the limitation, most links cannot be trivially upgraded to a higher capacity without incurring substantial cost in both time and money. Volumetric DDoS attacks are possible due to the relatively small network capacity of a target compared to the overall capacity of all Internet connected devices.
Figure 2.1 illustrates a generalized volumetric DDoS attack. The target has a maximum link capacity of 1Gbps, and each attacking botnet node is on a common residential broadband connection capable of sending traffic at 20Mbps. Thus, a botnet of just 50 nodes is needed to overwhelm the target network (50nodes x 20Mbps = 1Gbps). Botnets of 100,000 nodes are fairly common, and large botnets with more than 10million nodes have been observed in recent years. With DDoS traffic consuming all link capacity, no legitimate traffic is able to pass through the connection.
Attack Impact
Link Saturation
The primary effect of the volumetric attack is the saturation of upstream links that connect the target network to the Internet. When more traffic is sent to a link than it can transmit, excess traffic is dropped by the upstream network device. This results in significant packet loss, causing either performance degradation or a full network outage. The extent of the packet loss depends on the amount of excess traffic but may reach nearly 100%. Impact to applications can often be observed by users with as little as 5-10% packet loss.
Increased Load on Network Devices
The increase in overall network traffic caused by a volumetric DDoS attack, frequently causes higher than normal resource utilization on network devices such as routers, switches and firewalls. If the devices are not properly sized for the level of traffic then they may reboot, hang, or otherwise degrade in performance.
Conceal Other Attack Vectors
The volumetric DDoS attack produces so much traffic that it may make it difficult to detect more subtle attacks that may be occurring simultaneously. Attackers have used volumetric attacks to overwhelm devices such as intrusion detection/prevention systems or firewalls. By rendering these devices ineffective they can increase the success rate of traditional remote vulnerability exploitation.
Increased Network Costs
Many organizations use a burstable, or tiered, pricing model for purchasing network connectivity. A volumetric DDoS attack can raise IT costs by artificially increasing link utilization. An attack lasting just eight hours once per month would be sufficient to artificially inflate network costs for customers using the common 95th percentile billing model.
Why Are Volumetric DDoS Attacks So Effective?
Finite Network Capacity
In most cases, organizations have a finite amount of network capacity that cannot be easily increased to handle the additional traffic caused by a volumetric DDoS. As an example, an organization may have a 1Gbps connection from their upstream ISP. To increase the capacity to 10Gbps would likely require a new physical link (cable), more powerful network equipment (routers/firewalls/switches), and IT implementation time. The time required by many ISPs to provision additional capacity is generally 4 to 6 weeks.
Simplicity
Any target located on the Internet can be targeted by a volumetric DDoS. The attacker requires no special knowledge of the target environment, or understanding of advanced DDoS techniques. The attacker simply needs the IP address of the target, and the ability to send traffic. For this reason, volumetric attacks are often the first type of DDoS attack attempted by an attacker.
Fundamental to Topology of the Internet
The Internet is comprised of many interconnected smaller networks. This topology means that any one network, no matter how large the organization is, is dwarfed in scale by the combined capacity of all networks connected to the Internet. Given this topology, volumetric DDoS attacks will always be possible and the scale of the attacks will primarily be dependent upon the attacker’s ability to harness vulnerable resources for constructing a botnet.
Requires Upstream Blocking
To mitigate a volumetric DDoS attack, the traffic must be blocked prior to its transmission across the saturated network link. To do this requires the participation of network providers upstream from the targeted network. For small organizations this may entail contacting upstream ISPs, or, for those using BGP routing, the creation and propagation of null routes. By forcing the mitigation to occur upstream, it can cause an organization to be dependent on vendors (like ISPs) that may be less skilled or willing to assist in DDoS mitigation.
Any Traffic Will Do
A volumetric DDoS attack can leverage any protocol, and target any endpoint even if the target is not providing a publicly accessible service. The only requirement for a volumetric DDoS attack is to route traffic to the network that the attacker is trying to impact. As an example, an attacker could send a large volume of UDP packets to an IP address and port that isn’t even in use on the target network. Since the IP address is routable, the traffic will traverse the target organization’s network links causing impact.
Spoofed Sources
Since the volumetric DDoS attack doesn’t depend on establishing a persistent connection, the source IP address is often forged. To make detection and mitigation more challenging, attackers will often set the source IP address to a completely random IP address. This renders simplistic DDoS mitigation strategies, which depend on identifying and blocking the IP addresses responsible for sending large amounts of data, ineffective.
Explanation
Volumetric DDoS attacks saturate the Internet connection of the target at the interconnect with the upstream carrier. As a result, filtering downstream is not effective as the bottleneck is located further upstream.
Mitigation Strategies
Blocking With On-Premises Devices
Attempting to block a volumetric DDoS attack using on-premises devices such as IPS/IDS and firewalls is typically ineffective. As illustrated (Figure 2.2), these devices are positioned in the network downstream from the point at which the DDoS traffic causes saturation of the link and packet loss. Discarding the traffic after the bottleneck has no effect on attack mitigation.
Blocking Upstream by the ISP
If contacted, the technical support arm of most ISPs will add simple rules to block specific traffic before it reaches the target network. This approach can be effective at mitigating simplistic attacks, but will often be unable to mitigate more complex scenarios. The limitation is related to the minimal filtering capabilities offered by most ISPs. For example, most ISPs will be happy to filter all traffic to or from a specific IP address, or using a certain protocol. But this is a very blunt tool which may not be granular enough to block DDoS traffic while at the same time allowing legitimate traffic.
Null Routing the Target IP
An organization that uses BGP may use null routes to prevent devices on the Internet from sending traffic to the target IP. The main benefit of this approach is its distributed effect, since the null route announcement is sent to all devices on the Internet that receive Internet routing table announcements. Since this mechanism results in the target IP becoming unreachable, it is only useful if the target IP is expendable and traffic can be discarded to save other resources on the same network. For this reason, null routes are typically only an effective mitigation in multi-user environments where a problematic user can be segmented off to ensure a good experience for the remaining users.
Hide Behind a Large CDN
Traditional content distribution networks (CDNs) function by locating web server caches throughout the world to deliver content to the Internet. A CDN typically works as an HTTP(S) proxy where all requests are made to the CDN server, which subsequently initiates a private connection to the organization’s server to obtain the data. With regard to volumetric attacks, using a CDN often implicitly protects a network from these types of attacks because the traffic is sent to the CDN (Figure 2.3) which often is comprised of a massive, globally distributed network.
Dedicated Mitigation Services
A dedicated DDoS mitigation service, like that provided by Incapsula, is often the most effective approach. These services are similar to the CDN approach (Figure 2.3) mentioned earlier, but with advanced capabilities specific to identifying and blocking DDoS traffic. Much like a CDN, reputable mitigation services have a massive globally distributed network of scrubbing centers capable of blocking large DDoS attacks.
Examples
UDP Flood
This volumetric DDoS attack generates a large quantity of large UDP packets. UDP is a common protocol used for communication on the Internet, and many services such as DNS, games, chat, and VOIP use this protocol. The size of the attack packets are often the same, typically set at 1500 bytes or the maximum segment size for the link. The contents of the data portion of the packets are often randomized or a simple repeated character. The source IP address(es) of the DDoS packets may be forged as a random IP address. The target of these attacks are often UDP based services like DNS, which makes mitigation more challenging as the protocol can’t simply be dropped as it is used for legitimate communication. The packet capture below is from a UDP flood with randomized source IP address, targeting the NTP port on 192.168.0.10. The timestamp and packet size can be used to estimate the attack intensity (approx. 7.5Mbps in this example)
15:10:59.049061 IP 143.223.76.113.4722 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.049273 IP 173.119.200.61.4723 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.049463 IP 148.234.201.93.4724 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.049486 IP 17.168.132.133.4725 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.049667 IP 11.91.239.117.4726 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.049856 IP 247.26.232.148.4727 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.049884 IP 166.251.44.78.4728 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.050084 IP 55.47.7.207.4729 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.050269 IP 57.218.140.70.4730 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.050455 IP 202.34.238.47.4731 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.050641 IP 157.179.60.60.4732 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.050826 IP 204.251.51.22.4733 > 192.168.0.10.123: NTPv3, unspecified, length 1400
15:10:59.051012 IP 94.115.239.70.4734 > 192.168.0.10.123: NTPv3, unspecified, length 1400
ICMP Flood
This volumetric DDoS attack generates a large quantity of large ICMP packets. ICMP is a common protocol used on the Internet for communicating miscellaneous status information between devices. The size of the attack packets are often the same, typically set at 1500 bytes or the maximum segment size for the link. The contents of the data portion of the packets are often randomized or a simple repeated character. Although any ICMP message type may be used, the ICMP ping request/response types are most common. The source IP address(es) of the DDoS packets may be forged as a random IP address. The packet capture below is from an ICMP flood with randomized source IP address, targeting 192.168.0.10. Note that the packet type is “echo reply”, yet there are no associated “echo request” packets as would normally be expected with legitimate traffic. The timestamp and packet size can be used to estimate the attack intensity (approx. 700Mbps in this example)
15:21:52.876250 IP 22.26.9.93 > 192.168.0.10: ICMP echo reply, id 61449, seq 59013, length 1408
15:21:52.876286 IP 213.82.111.254 > 192.168.0.10: ICMP echo reply, id 61449, seq 59525, length 1408
15:21:52.876299 IP 33.101.41.249 > 192.168.0.10: ICMP echo reply, id 61449, seq 59781, length 1408
15:21:52.876312 IP 158.119.39.80 > 192.168.0.10: ICMP echo reply, id 61449, seq 60037, length 1408
15:21:52.876326 IP 203.22.9.28 > 192.168.0.10: ICMP echo reply, id 61449, seq 60293, length 1408
15:21:52.876347 IP 207.166.25.255 > 192.168.0.10: ICMP echo reply, id 61449, seq 60549, length 1408
15:21:52.876360 IP 63.24.49.82 > 192.168.0.10: ICMP echo reply, id 61449, seq 60805, length 1408
15:21:52.876377 IP 38.65.17.70 > 192.168.0.10: ICMP echo reply, id 61449, seq 61061, length 1408
15:21:52.876397 IP 124.119.163.183 > 192.168.0.10: ICMP echo reply, id 61449, seq 61317, length 1408
15:21:52.876410 IP 235.22.178.49 > 192.168.0.10: ICMP echo reply, id 61449, seq 61573, length 1408
Fragmented ICMP Flood
This volumetric attack is identical to the ICMP flood, but with packets larger than the maximum segment size of the connection (usually 1500 bytes). If, for example, the data section of the packet is 10,000 bytes it will be split into 7 packet fragments. Upon reaching the target, the receiving device will reassemble the packet using extra CPU resources on the device. Other than this differentiator, the attack is identical to the more general ICMP flood. The packet capture below is a fragmented ICMP flood targeting 192.168.0.10. Note the high number of packet fragments which is atypical of legitimate ICMP traffic.
15:34:15.659680 IP 10.100.210.10 > 192.168.0.10: ICMP echo reply, id 62985, seq 45600, length 1424
15:34:15.659685 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.659688 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.659691 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.659697 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.659865 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.659870 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.659873 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.659876 IP 10.100.210.10 > 192.168.0.10: icmp
15:34:15.660034 IP 10.100.210.10 > 192.168.0.10: icmp
Tsunami SYN Flood
This volumetric DDoS attack generates a large quantity of large TCP SYN packets. TCP is the most common protocol used on the Internet, and is used for connection oriented higher-level protocols like HTTP(S). The ‘SYN’ designation indicates that the synchronize flag has been set on the TCP packet, which is normally done during the setup of a new connection. The size of the attack packets are often the same, typically set at 1500 bytes or the maximum segment size for the link. The contents of the data portion of the packets are often randomized or a simple repeated character. The source IP address(es) of the DDoS packets may be forged as a random IP address. These attacks are often targeted at TCP based services like HTTP, which make mitigation more challenging as the protocol can’t simply be dropped as it is used for legitimate communication. The packet capture below is from a Tsunami SYN flood with randomized source IP address, targeting 192.168.0.10. Note that the packet has the SYN (S) flag set and that the length is 1400 bytes. This length is atypical of SYN packets which normally have no packet data. The timestamp and packet size can be used to estimate the attack intensity (approx. 230Mbps in this example)
15:42:52.311365 IP 75.39.99.97.29276 > 192.168.0.10.443: Flags [S], seq 653296982:653298382, win 512, length 1400
15:42:52.311433 IP 47.11.132.217.29281 > 192.168.0.10.443: Flags [S], seq 863791764:863793164, win 512, length 1400
15:42:52.311477 IP 175.130.183.129.29284 > 192.168.0.10.443: Flags [S], seq 83028330:83029730, win 512, length 1400
15:42:52.311544 IP 243.38.227.16.29288 > 192.168.0.10.443: Flags [S], seq 2139105808:2139107208, win 512, length 1400
15:42:52.311603 IP 105.129.100.77.29292 > 192.168.0.10.443: Flags [S], seq 1067694761:1067696161, win 512, length 1400
15:42:52.311632 IP 73.243.253.11.29294 > 192.168.0.10.443: Flags [S], seq 911930069:911931469, win 512, length 1400
15:42:52.311692 IP 96.175.11.103.29298 > 192.168.0.10.443: Flags [S], seq 379725064:379726464, win 512, length 1400
15:42:52.311739 IP 129.21.68.48.29301 > 192.168.0.10.443: Flags [S], seq 90102282:90103682, win 512, length 1400
15:42:52.311796 IP 210.181.176.241.29305 > 192.168.0.10.443: Flags [S], seq 1302395233:1302396633, win 512, length 1400
15:42:52.311855 IP 65.143.106.210.29309 > 192.168.0.10.443: Flags [S],
Protocol Attacks
Overview
This course covers DDoS attacks that exploit weaknesses in specific protocols primarily at Layer 3 and Layer 4 of the OSI model. Upon completion of this course the participant will have an understanding of how these DDoS attacks work, why they are so effective and how they might be mitigated.
Definitions
Client
In the client/server model the client is the computer system that is initiating a new connection to another system (the server).
Server
In the client/server model the server is a computer service that waits to receive a connection and request from another system (the client).
Attack Overview
Protocol attacks are a diverse collection of various attacks intended to cause disruption to an environment by exploiting a specific weakness or inefficiency in the protocol. Many of these attacks exploit weaknesses of Layer 3 and 4 protocols such as TCP, IP and UDP. Unlike volumetric attacks, the intention is not to saturate the Internet connection but instead to cause disruption with a relatively small amount of network traffic.
Most communication on the Internet uses a client/server model. In this model, a network device or system that is presenting a resource to the Internet awaits connections from clients. The client initiates a connection, and once the connection is established communication can begin. For each connection, resources are expended on both the client and the server. As an example, when a TCP connection is created between a user’s web browser and a web server, the web server will allocate various memory areas to track the communication and maintain connection state data. Additionally, most operating systems have finite limits on the size of connection tables, and other internal network state tables. Protocol attacks attempt to disrupt communication by exhausting these resources on the target system. As a general rule, the more resources a specific protocol uses the more susceptible it is to DDoS attack. Protocol DDoS attacks are possible due to the limited amount of server resources in comparison to the total client resources available on the entire Internet.
Figure 3.1 illustrates the TCP connection DDoS attack, one of the most trivial protocol attacks. The targeted system has a finite configuration limit within the operating system allowing it to support up to 20,000 TCP connections. This means that a botnet of just 20 nodes would be able to easily fill the pool of connections (20nodes x 1000 conns/node = 20,000 connections). A botnet of 100,000 nodes is fairly common, and large botnets with more than 10million nodes have been observed in recent years. With DDoS connections filling all connection slots on the target, no legitimate connections can be established.
Attack Impact
Increased Memory Usage on Network Devices
Devices that track network connection state like firewalls, IPS/IDS, or load balancers often use more memory when experiencing a protocol DDoS attack. Each new connection or data flow requires allocation of resources on these devices. If the strength of the attack is high enough, it may result in exhausting memory on these devices. Small memory leaks that might otherwise go unnoticed will be exacerbated by these attacks.
Increased Load on Network Devices
Devices that track network connection state like firewalls, IPS/IDS or load balancers may use more CPU resources. This behavior is common in TLS/SSL-related protocol attacks where the target or intermediate devices may decrypt the traffic at considerable CPU cost.
Reach Arbitrary Limits
Most operating system network stacks contain specific hardcoded limits that control the size of various buffers and tables stored in physical memory. So although the target may appear normal or idle, one of these arbitrary limits may have been exceeded, which results in the rejection of additional connections.
Why Are Protocol DDoS Attacks So Effective?
Difficult to Diagnose
Protocol DDoS attacks are often low bandwidth attacks that may easily go unnoticed. Protocol attacks that exploit hardcoded limits in network devices may go completely unnoticed as devices may appear idle. These attacks can sometimes be misdiagnosed as a simple network outage rather than an attack.
Finite Resources
With few exceptions, most organizations have a finite amount of CPU and memory on their network devices and servers. A protocol DDoS attack intended to exhaust CPU or memory on these devices takes advantage of this fact. Increasing CPU or memory capacity on servers and network devices will often require ordering more expensive hardware with substantial delivery and setup time.
The Internet Is a Massive Attack Resource
Regardless of how large an organization’s environment might be, it is dwarfed by the resources of the entire Internet. A large organization may have 10,000 servers with 160,000 CPU cores and 320TB of memory, but this same capacity could be achieved with a medium-sized botnet of just 100,000 nodes. So although most protocol attacks exhaust nearly an equal amount of resources on the attacker side, the available resource pool is much larger.
Spoofed Sources
Some protocol attacks don’t require establishing a persistent connection, thus the source IP address is often forged. To make detection and mitigation more challenging, attackers often set the source IP address to a completely random IP address. This renders simplistic DDoS mitigation strategies that depend on identifying and blocking the abusive IP addresses ineffective.
Explanation
Volumetric DDoS attacks may use any protocol. Discarding of ICMP packets may mitigate attacks that use that protocol, but should be done cautiously to prevent other network side-effects.
Explanation
Volumetric DDoS attacks may use any protocol. Discarding of ICMP packets may mitigate attacks that use that protocol, but should be done cautiously to prevent other network side-effects.
Mitigation Strategies
Blocking with On-Premises Devices
Blocking protocol DDoS attacks with on-premises devices such as IDS/IPS and firewalls may be successful due to the low bandwidth nature of these attacks. This is in contrast to volumetric DDoS attacks where the bottleneck is upstream and outside the control of the organization. Also, unlike volumetric attacks, a large portion of protocol attacks do not have spoofed source IP addresses. As a result, simple attacks can be blocked with simple firewall rules. More advanced attacks, particularly those sourced from very large botnets, will require purpose-built DDoS mitigation hardware to properly identify and automatically block the attack traffic.
Blocking Upstream by the ISP
This method of mitigation is often ineffective for protocol DDoS attacks. If contacted, the technical support arm of most ISPs will add simple rules to block specific traffic before it reaches the target network. This approach can be effective at mitigating simplistic attacks, but will often be unable to mitigate more complex scenarios. The limitation is related to the minimal filtering capabilities offered by most ISPs. For example, most ISPs will be happy to filter all traffic to or from a specific IP address, or all traffic using a certain protocol. But this is a very blunt tool and may not be granular enough to block DDoS traffic while at the same time allowing legitimate traffic. The same level of filtering is available in on-premises firewalls and routers with the added benefit of being under the control of the organization.
Traffic Analytics
Due to the low bandwidth nature of most protocol attacks, one of the greatest challenges is identifying that an attack is actually underway. Tools that analyze traffic patterns and look for anomalies based on historical data can be invaluable in making this determination.
Null Routing the Target IP
This method of mitigation is generally not recommended for protocol DDoS attacks as it blocks all traffic to the target. This option is very imprecise and will affect both legitimate and attack traffic destined for the target IP.
Hide Behind a Large CDN
Traditional content delivery networks (CDNs) function by locating web server caches throughout the world to deliver content to the Internet. A CDN typically works as an HTTP(s) proxy where all requests are made to the CDN server, which subsequently initiates a private connection to the organization’s server to obtain the data. With regard to protocol attacks, using a CDN often implicitly protects a network from these types of attacks because the traffic is sent to the CDN (Figure 3.2) which often is comprised of a massive, globally distributed network. This type of mitigation solution will only protect services supported by the CDN (generally HTTP and HTTPS).
Dedicated Mitigation Services
A dedicated DDoS mitigation service, like that provided by Incapsula, is often the most effective. These services are similar to the CDN approach (Figure 3.2) mentioned earlier but with advanced capabilities specific to identifying and blocking DDoS traffic. Much like a CDN, a reputable mitigation service has a massive globally distributed network of scrubbing centers capable of blocking large DDoS attacks.
Examples
SYN flood classic and modern
The classic SYN flood is a low bandwidth protocol DDoS attack intended to exhaust the resources on the target device. This is achieved by not completing the normal TCP 3-way handshake. The normal 3-way handshake (Figure 3.3) has the client sending an initial SYN packet to the server. The server adds the half-open connection to its internal connection state table (syn queue) and then replies with a SYN-ACK. In a normal connection, the client then responds with an ACK. At this point the connection is established and communication can occur. In the classic SYN flood, this process is interrupted (Figure 3.4). Just as in a normal connection the attacker sends an initial SYN packet. To conceal the attacker, the source IP address is often forged. Upon receiving the SYN packet, the server adds the half-open connection to its internal connection state table (syn queue) and then replies with a SYN-ACK. This SYN-ACK goes to the forged source address and is generally discarded, meaning that the server will never receive the final ACK as it would in a normal connection establishment. The server maintains the half-open connection state information for a specific timeout. If a large number of half-open connections are initiated, the connection state table (syn queue) will become full and no further connections will be permitted to the server.
In many regards the classic SYN flood has been mitigated by the use of SYN cookies, increased state table size, and other mitigation techniques. The modern SYN flood sends the same packets but is substantially different from its historical predecessor. The major difference is the number of packets-per-second sent by the attacker. In the classic SYN flood, it was trivial to fill the connection state table, as it defaulted to just 1024 entries in many network stacks. An attacker could effectively DDoS a target by sending a few hundred packets per minute. The modern SYN flood generates SYN packets measured in millions of packets-per-second (PPS). This high volume of SYN packets creates two effects. The first is that load balancers, firewalls and other devices that manage connection state will use excessive CPU and may overflow their network state tables. The second, and more damaging behavior, is that many networks are not sized appropriately for a high volume of very small SYN packets. For instance, a router advertised as handling 1Gbps of data might only be able to handle 100Mbps of very tiny SYN packets. So although the target’s network connection appears underutilized, the network hardware itself may be under extreme pressure and unable to direct traffic in a timely manner. The packet capture below is a TCP SYN flood with randomized source IP addresses, targeting the HTTPS port on 192.168.0.10. The timestamp and packet size can be used to estimate the attack intensity (approx. 60,000 PPS)
03:05:29.246728 IP 158.191.135.9.49749 > 192.168.0.10.443: Flags [S], seq 52800378, win 512, length 0
03:05:29.246742 IP 133.238.17.124.49750 > 192.168.0.10.443: Flags [S], seq 1663210950, win 512, length 0
03:05:29.246763 IP 206.126.41.118.49751 > 192.168.0.10.443: Flags [S], seq 758194152, win 512, length 0
03:05:29.246786 IP 137.77.98.4.49753 > 192.168.0.10.443: Flags [S], seq 269771553, win 512, length 0
03:05:29.246799 IP 119.86.245.230.49754 > 192.168.0.10.443: Flags [S], seq 1530171648, win 512, length 0
03:05:29.246821 IP 227.52.64.150.49755 > 192.168.0.10.443: Flags [S], seq 306851430, win 512, length 0
03:05:29.246833 IP 158.209.242.234.49756 > 192.168.0.10.443: Flags [S], seq 1332043940, win 512, length 0
03:05:29.246858 IP 135.1.224.126.49758 > 192.168.0.10.443: Flags [S], seq 899324917, win 512, length 0
03:05:29.246880 IP 2.138.29.36.49759 > 192.168.0.10.443: Flags [S], seq 1208062333, win 512, length 0
03:05:29.246893 IP 253.35.171.28.49760 > 192.168.0.10.443: Flags [S], seq 1358791898, win 512, length 0
TCP Connection Flood
The TCP connection flood is a low bandwidth protocol DDoS attack that attempts to overwhelm connection limitations of the target device. This attack is specific to connection oriented services such as those using the TCP protocol (i.e., HTTP, HTTPS, SSH, SMTP, etc). The TCP connection flood is simplistic, with the client performing the full TCP 3-way handshake to establish a full ESTABLISHED connection. By doing this an attacker may be able to completely fill all available connection table entries, thus preventing legitimate customers from connecting. Since this attack completes the 3-way handshake it is not commonly spoofed, and the source IP address is often the IP address of a system in a botnet. A typical indicator of this attack type is a high number of connections in the ESTABLISHED state in the output of netstat (Linux and Windows). Often a single source IP address may have hundreds or thousands of open connections, and typically the connections are left idle, i.e., not sending/receiving any data from whatever application is being attacked. An example might be a web server with 20,000 connections in the ESTABLISHED state, yet the log files show no actual requests being performed.
03:18:46.649026 IP 10.1.10.250.50584 > 192.168.0.10.http: S 552149290:552149290(0) win 17922 <mss 8961,sackOK,timestamp 1386647176 0,nop,wscale 7>
03:18:46.649099 IP 192.168.0.10.http > 10.1.10.250.50584: S 2492797415:2492797415(0) ack 552149291 win 5792 <mss 1460,sackOK,timestamp 2753318625 1386647176,nop,wscale 7>
03:18:46.723639 IP 10.1.10.250.50584 > 192.168.0.10.http: . ack 1 win 141 <nop,nop,timestamp 1386647195 2753318625>
03:18:46.726798 IP 10.1.10.250.50585 > 192.168.0.10.http: S 2383907015:2383907015(0) win 17922 <mss 8961,sackOK,timestamp 1386647196 0,nop,wscale 7>
03:18:46.726825 IP 192.168.0.10.http > 10.1.10.250.50585: S 2489206418:2489206418(0) ack 2383907016 win 5792 <mss 1460,sackOK,timestamp 2753318705 1386647196,nop,wscale 7>
03:18:46.798548 IP 10.1.10.250.50584 > 192.168.0.10.http: . ack 2 win 141 <nop,nop,timestamp 1386647213 2753318695>
03:18:46.799870 IP 10.1.10.250.50585 > 192.168.0.10.http: . ack 1 win 141 <nop,nop,timestamp 1386647214 2753318705>
03:18:46.802977 IP 10.1.10.250.50586 > 192.168.0.10.http: S 2942092780:2942092780(0) win 17922 <mss 8961,sackOK,timestamp 1386647215 0,nop,wscale 7>
03:18:46.802998 IP 192.168.0.10.http > 10.1.10.250.50586: S 2501835850:2501835850(0) ack 2942092781 win 5792 <mss 1460,sackOK,timestamp 2753318775 1386647215,nop,wscale 7>
03:18:46.873142 IP 10.1.10.250.50585 > 192.168.0.10.http: . ack 2 win 141 <nop,nop,timestamp 1386647232 2753318775>
03:18:46.877548 IP 10.1.10.250.50586 > 192.168.0.10.http: . ack 1 win 141 <nop,nop,timestamp 1386647233 2753318775>
03:18:46.880701 IP 10.1.10.250.50587 > 192.168.0.10.http: S 1675212591:1675212591(0) win 17922 <mss 8961,sackOK,timestamp 1386647234 0,nop,wscale 7>
03:18:46.880723 IP 192.168.0.10.http > 10.1.10.250.50587: S 2491864230:2491864230(0) ack 1675212592 win 5792 <mss 1460,sackOK,timestamp 2753318855 1386647234,nop,wscale 7>
03:18:46.952330 IP 10.1.10.250.50586 > 192.168.0.10.http: . ack 2 win 141 <nop,nop,timestamp 1386647252 2753318855>
03:18:46.952764 IP 10.1.10.250.50587 > 192.168.0.10.http: . ack 1 win 141 <nop,nop,timestamp 1386647252 2753318855>
03:18:46.956170 IP 10.1.10.250.50588 > 192.168.0.10.http: S 3263953535:3263953535(0) win 17922 <mss 8961,sackOK,timestamp 1386647253 0,nop,wscale 7>
03:18:46.956189 IP 192.168.0.10.http > 10.1.10.250.50588: S 2495715443:2495715443(0) ack 3263953536 win 5792 <mss 1460,sackOK,timestamp 2753318935 1386647253,nop,wscale 7>
03:18:47.025264 IP 10.1.10.250.50587 > 192.168.0.10.http: . ack 2 win 141 <nop,nop,timestamp 1386647270 2753318925>
03:18:47.029859 IP 10.1.10.250.50588 > 192.168.0.10.http: . ack 1 win 141 <nop,nop,timestamp 1386647271 2753318935>
tcp 0 0 10.1.10.250:38342 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:28401 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:51944 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:28632 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:58742 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:58205 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:13832 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:19448 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:42705 192.168.0.10:80 ESTABLISHED
tcp 0 0 10.1.10.250:17252 192.168.0.10:80 ESTABLISHED
SlowLoris/R.U.D.Y.
The SlowLoris and RUDY DDoS attacks are low bandwidth attacks that attempt to exhaust target connection resources by submitting requests that never complete. This keeps the connection open indefinitely, slowly exhausting the ability of the target to receive new connections from legitimate clients. Both attacks are extensions of the TCP connection attack and work by attempting to fill all available connection table entries. What differentiates the SlowLoris/RUDY attacks from a mundane TCP connection flood is that the connection isn’t idle. Instead, the connecting client slowly sends a request that will never complete. By slowly sending data to the server, the attacker is able to keep the connection open and circumvent mitigations that function by closing idle connections. The indicators for these attacks are nearly identical to that of the TCP connection flood. Below is an example of the SlowLoris HTTP GET request.
SlowLoris GET Request
Connection to target.example.com 80 port [tcp/http] succeeded!
GET / HTTP/1.1
Host: targethost.example.com:80
<pause slightly>
X-<random string>: <random string>
<pause slightly>
X-<random string>: <random string>
<pause slightly>
X-<random string>: <random string>
<pause slightly>
X-<random string>: <random string>
<pause slightly>
….
Layer 7 Attacks
This course covers DDoS attacks that exploit weaknesses in specific applications and their related protocols (layer 7 in the OSI model). Upon completion of this course the participant will have an understanding of how these DDoS attacks work, why they are so effective and how they might be mitigated.
Definitions
LAMP Stack
This is a common model of a web services stack, named for the original components (Linux, Apache, MySQL, PHP). A modern LAMP stack may have different components (i.e., NGINX instead of Apache, or PostgreSQL instead of MySQL), but the general model is the same.
Attack Overview
Application-level attacks are a diverse collection of attacks intended to cause disruption to an environment by exploiting specific weaknesses or inefficiencies in an application. The key differentiator between application-level and other attacks is that the attack traffic is “in protocol,” meaning that the traffic is legitimate from a protocol perspective. By being “in protocol,” the attacks are often difficult to distinguish from legitimate traffic.
As discussed in previous courses, the primary model for communication on the Internet is the client/server model. In this model, clients initiate connections to a server, after which data is sent and received between the participants. This communication channel is managed by layer 4 protocols such as TCP and UDP. Above this layer of communication are application layer protocols such at HTTP, DNS, SMTP and many more. It is the application level protocols that are responsible for the actual exchange of information between session participants. Figure 4.1 illustrates an example of the HTTP protocol commonly used to request and receive data on the World Wide Web (WWW) using a web browser.
Application-level attacks can take a variety of forms, but are generally more focused than volumetric or protocol attacks. Due to the “in protocol” nature of these attacks, they can also be used to cause impact at a deeper level than other attacks. Figure 4.2 summarizes the environmental impact of each attack type. Note how application-level attacks compare to the other attack types. The focused nature of application-level attacks also allows an attacker to target specific inefficient or vulnerable areas of an application such as dynamic content, searches or user login functionality.
Figure 4.3 illustrates a common HTTP request flood, one of the most trivial application-level attacks. The targeted system has a finite amount of CPU resources and as a result can process a respectable 10,000 web page loads per second. An HTTP request flood is in essence the same as a person pressing the “reload” button in their web browser repeatedly. You might expect that one person on one computer might easily be able to reload a web page once per second. Now imagine that one person could replicate that behavior 10,000 times in one second – this is effectively what happens when a botnet performs an HTTP request flood. With the attack traffic overwhelming the target, legitimate requests are discarded or delayed.
In the previous example, the application-level DDoS attack originates from a botnet. However, a botnet isn’t specifically required to perform such an attack. An example of such an attack vector is the exploitation of vulnerabilities (such as XSS) that cause all visitors to a website to unwittingly send requests to the target. This method reduces the cost to the attacker, and provides a pool of attack nodes that may be much larger and more distributed than any botnet.
Attack Impact
Increased Resource Usage on Application Servers
Application servers that are responsible for responding to a request will often experience a sudden increase in CPU or memory utilization. This is often exacerbated by an attacker targeting specific resources that typically require more CPU or memory.
Increased Resource Usage on Database Systems
Application-level attacks often extend beyond the specific reach of the attacker’s request. In a classic LAMP environment, the attacker’s request is received and then responded to by a web server. However, their request may access data and resources stored on other systems, such as a database server. This behavior can cause increased resource usage on these supporting systems. Attackers often attempt to exploit this behavior by targeting components that are difficult to scale to higher capacity, such as monolithic relational databases.
Exhaust Storage on Devices
Many applications write data to disk as part of the normal operation of the system. Examples include application log files, session data, or user uploaded content. A DDoS attack may exhaust storage resources, causing system instability and failures. Application log files can be particularly troublesome as they are often required for troubleshooting both traditional issues and DDoS incidents.
Increase Cloud Costs
An auto-scaling cloud environment may be less susceptible to application-level attacks due to the environment’s ability to automatically create new resources (e.g., bandwidth) to handle the additional requests. However, these resources aren’t free, and the DDoS attack will have a direct financial impact by increasing cloud hosting fees to process the bad requests.
Reach Arbitrary Application Limits
Many applications have default configuration values that affect the performance of the application. As an example, most web servers have a finite number of worker threads, that when exhausted will cause client requests to be delayed or fail. Likewise, a database may only allow a specific number of licensed connections. Application-level attacks are very effective at triggering poor performance by exceeding application limits. So although the environment may appear idle, client performance is significantly impacted due to a configuration limit being reached.
Why Are Application-Level DDoS Attacks So Effective?
Difficult to Diagnose
Application-level DDoS attacks are often low bandwidth attacks that may go unnoticed. Additionally, their impact may be less obvious as they penetrate deeper into the environment and affect resources that may seem unrelated. For example, high CPU usage on a web server may be a very obvious indicator of an application-level attack. However, similar high usage on a database may be misdiagnosed as a performance problem, software bug, or misconfiguration.
Mimic Real User Behavior
Identifying and mitigating an application-level attack can be challenging as the traffic may appear legitimate. A skilled attacker may construct an attack that goes to great effort to masquerade as legitimate. This may include mimicking of real user behavior in navigating a website, including realistic pauses and browser interactions. Extensive analysis of traffic patterns and anomaly detection may be required to identify these attacks.
Finite Resources
With few exceptions, most organizations have a finite amount of CPU, memory and disk I/O on their servers. An Application-level DDoS attack crafted to exhaust CPU or memory on these servers takes advantage of this limitation. Increasing these resources on servers will often require provisioning new systems, which can be costly and time consuming.
Requires Minimal Attacker Resources
A skilled attacker can create a DDoS attack by targeting inefficient areas of the environment. This generally requires significantly less attacker resources (as little as one computer) than those required to carry out volumetric or protocol attacks.
Dynamic Threat
The environments run by most organizations are dynamic, with new applications and features continually being created. Each new application or feature is an area that an attacker might leverage for a DDoS attack. The dynamic nature of applications stands in contrast with the network infrastructure, which may only see a full refresh every 3-5 years and in the meantime has to settle for small incremental improvements. So although an environment may seem safe today, each new application change opens up the possibility of a new DDoS risk. The areas of risk and the number of permutations of application-level attacks are essentially limitless.
Internet is a Massive Attack Resource
Regardless of how large an organization’s environment might be, it is dwarfed by the resources of the entire Internet. A large organization may have 10,000 servers with 160,000 CPU cores and 320TB of memory, but this same capacity could be achieved with a medium-sized botnet of just 100,000 nodes. So although most application-level attacks exhaust nearly an equal amount of resources on the attacker side, the available resource pool is much larger.
Mitigation Strategies
Blocking with On-Premises Devices
Blocking application-level DDoS attacks with on-premises devices such as IDP/IPS and firewalls may be successful due to the low bandwidth nature of these attacks. This is in contrast to volumetric DDoS attacks where the bottleneck is upstream and outside the control of the organization. Also, unlike volumetric and protocol attacks, nearly all (TCP specifically) application-level attacks do not have spoofed source IP addresses. As a result, simple attacks can be blocked with simple firewall rules. More advanced attacks, and those sourced from very large botnets, will require purpose-built DDoS mitigation hardware to properly identify and automatically block the attack traffic.
Blocking Upstream by the ISP
This method of mitigation is often ineffective for application-level DDoS attacks. If contacted, the technical support arm of most ISPs will add simple rules to block specific traffic before it reaches the target network. This approach can be effective at mitigating simplistic attacks, but will often be unable to mitigate more complex scenarios. The limitation is related to the minimal filtering capabilities offered by most ISPs. For example, most ISPs will be happy to filter all traffic to or from a specific IP address, or all traffic using a certain protocol. But this is a very blunt tool and may not be granular enough to block DDoS traffic while at the same time allowing legitimate traffic. The same level of filtering is available in on-premises firewalls and routers with the added benefit of being under the control of the organization. In addition, unless they are given decryption keys, the ISP is unable to inspect the content of traffic using encrypted protocols like HTTPS, making identification and mitigation more difficult.
Traffic Analytics
Due to the low bandwidth nature of most application-level attacks, one of the greatest challenges is identifying that an attack is actually occurring. Tools that analyze traffic patterns and look for anomalies based on historical data can be invaluable in making this determination.
Null Routing the Target IP
This method of mitigation is generally not recommended for application-level DDoS attacks as it blocks all traffic to the target. This option is very imprecise and will affect both legitimate and attack traffic destined for the target IP.
Hide Behind a Large CDN
Traditional content delivery networks (CDNs) function by locating web server caches throughout the world to deliver content to the Internet. A CDN typically works as an HTTP(s) proxy where all requests are made to the CDN server, which subsequently initiates a private connection to the organization’s server to obtain the data. With regard to application-level attacks, using a CDN may help mitigate some attacks (Figure 4.4). Specifically, requests for resources located on the CDN, such as static web objects, will be fulfilled and absorbed by the massive CDN infrastructure. However, dynamic content such as user login requests, content searches or similar non-cacheable data, will be passed by the CDN to the organization’s backend servers resulting in a DDoS attack. Moreover, this type of mitigation solution will only protect services supported by the CDN (generally HTTP and HTTPS).
Dedicated Mitigation Services
A dedicated DDoS mitigation service, like that provided by Incapsula, is often the most effective approach to solving application-level attacks. These services are similar to the CDN approach (Figure 4.4) mentioned earlier, but with advanced capabilities specific to identifying and blocking DDoS traffic. Much like a CDN, a reputable mitigation service has a massive globally distributed network of scrubbing centers capable of blocking large DDoS attacks.
Application Blocking
For smaller application-level attacks, an organization may be able to mitigate the attack by disabling the feature being targeted. For example, if the attacker is targeting a search feature on the site that is inefficient, it may be better to temporarily disable that feature in order to maintain a proper level of performance for the other components on the site.
Examples
HTTP/HTTPS request flood
HTTP and HTTPS are the application protocols responsible for sending and receiving data on the World Wide Web. These protocols use the client server model, with the client, or browser, submitting a request to a server for a specific resource. The server then responds with the requested data or an error message. Figure 4.1, above, illustrates an example of an HTTP request and response communication pattern. As with all application-level attacks, there are a massive number of permutations possible. Some examples include:
- General High Request Rate
The simplest of all application-level attacks is to send “in protocol” requests at a rate higher than the target is able to respond. In this way the attacker tries to overwhelm the target and exhaust all resources in an effort to prevent legitimate traffic from accessing the target. - Exploit Search Functionality
Many websites have functionality that allows a visitor to search for content. For example, an e-commerce website might have a product search feature, or an airline booking website may have a flight search capability. Because this data is non-cacheable on a CDN, the request is passed through to the backend servers where it is then processed. Depending on how the search functionality is implemented, this may require database queries or access to other APIs and systems all of which are likely to require substantial resources. If the search feature is critical to the business, an attacker may be able to damage the business by targeting this specific component efficiently. - Exploit User Login Functionality
Many websites have functionality that allows a visitor to login to an account. This functionality might be found in online banking portals, e-commerce sites, and online gaming networks, just to name a few. As with all dynamic content, the login functionality is non-cacheable by a CDN, and will be passed through to the backend servers for processing. The way in which login functionality is implemented varies substantially from organization to organization, but often requires a database lookup of various customer data and the use of encryption algorithms for password verification. These processes tend to use a disproportionate amount of resources as compared to “normal” requests, and can be leveraged by attackers to increase the effectiveness of their attacks. - Large Objects
HTTP and HTTPS requests are generally very small (100’s of bytes), however the responses may be very large. By targeting heavy resources on a website, an attacker may be able to exhaust outbound Internet bandwidth or raise the target’s bandwidth costs by increasing network usage. An example of this behavior might be the repeated request by an attacker for a large PDF document located on the website. - Uploading Content
Some websites give users or the public the ability to upload arbitrary content. Websites that allow uploads by the general public raise their risk of a DDoS attack. An attacker can exploit this functionality to exhaust storage space on the receiving system, or raise storage costs by uploading junk data. - Site Crawling
To mimic user behavior and obfuscate the DDoS attack, an attacker may coordinate a large botnet to “crawl” a website in a manner similar to human visitors. The attack attempts to overwhelm the computer resources of the target and thwart mitigation attempts by making the requests indistinguishable from legitimate requests. - Form Data Flooding
Any web form that accepts user provided data is susceptible to a more general type of flooding. Although an attacker might not know the details of how the form data is processed, nearly all form submissions follow the same behavior. A client provides data, which is submitted to the server, which in turn executes code to do “something” with that data. The “something” may be to put the data in a database, send an email, register a new user account, or any number of possible scenarios.
Below is a section of web server logs showing unusual behavior with respect to the target server. As web traffic patterns are unique to each organization, spotting anomalies can be challenging. Hardware platforms exist that can assist in analyzing traffic, and some DDoS mitigation vendors (including Incapsula) use this capability.
10.100.0.10 – – [06/Mar/2016:04:07:05 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.224.53.82 – – [06/Mar/2016:04:07:05 +0000] “GET / HTTP/1.1” 200 524
10.112.192.37 – – [06/Mar/2016:04:07:05 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.81.18.17 – – [06/Mar/2016:04:07:06 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.187.155.114 – – [06/Mar/2016:04:07:06 +0000] “GET /faq HTTP/1.1” 200 8532
10.155.79.59 – – [06/Mar/2016:04:07:06 +0000] “GET / HTTP/1.1” 200 524
10.92.174.1 – – [06/Mar/2016:04:07:07 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.18.186.58 – – [06/Mar/2016:04:07:07 +0000] “GET /cart/fetch HTTP/1.1” 200 1492
10.52.188.48 – – [06/Mar/2016:04:07:07 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.19.83.193 – – [06/Mar/2016:04:07:07 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.73.66.15 – – [06/Mar/2016:04:07:07 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.99.28.45.6 – – [06/Mar/2016:04:07:08 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.173.85.62 – – [06/Mar/2016:04:07:08 +0000] “GET / HTTP/1.1” 200 524
10.92.29.235 – – [06/Mar/2016:04:07:08 +0000] “GET /about HTTP/1.1” 200 4492
10.184.49.62 – – [06/Mar/2016:04:07:08 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
10.88.24.63 – – [06/Mar/2016:04:07:08 +0000] “GET /download/whitepaper-v1.pdf HTTP/1.1” 200 4050194
UDP DNS request flood
DNS is the application protocol used by computers to translate human readable names like www.example.com to an IP address. All organizations have a public DNS server to allow public users on the Internet to resolve their hostnames. This protocol uses the client-server model, with the client requesting the IP address for a specific hostname. If the DNS server is unreachable or overloaded, the client will not be able to obtain an IP address, and as a result will not be able to reach the resource. By overwhelming a DNS server, an attacker may be able to cause an outage for all hostnames for which the attacked server acts as the authoritative name server. As DNS primarily uses UDP, this application-level DDoS attack often has a forged source IP address. Below is a packet capture for a sample UDP DNS request flood. As with any application-level attack, identifying differences in traffic patterns is critical for successful mitigation. The packet capture shows that one specific DNS record is being repeatedly queried at an extremely high rate. The timestamp and packet size can be used to estimate the attack intensity (approx. 80,000 queries/second).
02:58:11.727630 IP 10.49.41.63.4292 > 192.168.0.10.domain: 28956+ A? www.example.com. (36)
02:58:11.727637 IP 10.5.52.6.4592 > 192.168.0.10.domain: 24992+ A? www.example.com. (36)
02:58:11.727640 IP 10.91.147.52.44492 > 192.168.0.10.domain: 5342+ A? www.example.com. (36)
02:58:11.727642 IP 10.148.99.228.24022 > 192.168.0.10.domain: 61639 PTR? 219.3.113.10.in-addr.arpa. (74)
02:58:11.727659 IP 10.69.98.28.29242 > 192.168.0.10.domain: 5821+ A? www.example.com. (36)
02:58:11.727662 IP 10.59.59.191.32482 > 192.168.0.10.domain: 58911+ A? www.example.com. (36)
02:58:11.727690 IP 10.253.152.29.19323 > 192.168.0.10.domain: 19425+ MX? testdomain.com. (49)
02:58:11.727695 IP 10.81.92.11.8391 > 192.168.0.10.domain: 24811+ A? www.example.com. (36)
02:58:11.727698 IP 10.92.198.59.23931 > 192.168.0.10.domain: 19425+ A? www.example.com. (36)
02:58:11.727728 IP 10.58.59.251.8244 > 192.168.0.10.domain: 2284+ A? www.example.com. (36)
02:58:11.727738 IP 10.22.199.192.38191 > 192.168.0.10.domain: 31132+ A? www.example.com. (36)
02:58:11.727762 IP 10.31.135.66.43134 > 192.168.0.10.domain: 2991+ A? www.example.com. (36)
02:58:11.727763 IP 10.31.49.19.6243 > 192.168.0.10.domain: 29146+ A? www.example.com. (36)
Reflection Attacks
Attack Overview
Reflection and amplification attacks are a type of volumetric DDoS attack where an attacker uses an intermediate system to increase the size of an attack and/or conceal the true origin of the attack. As with other volumetric DDoS attacks, the attacker attempts to overwhelm Internet circuits and network devices.
A key concept in this class of DDoS is the notion of “reflection”. In terms of DDoS, reflection is when an attacker uses publicly available resources of a 3rd party to launch an attack against the victim. This differs from a botnet in that the 3rd party resources being used are not necessarily under the control of the attacker. In a typical DDoS botnet, the attacker has taken control of devices on the Internet and installed software capable of performing DDoS attacks, and it is these devices that make up the botnet. In a reflection scenario, a publicly accessible application is used by the attacker to launch a DDoS assault against the target. The primary method of operation for such attacks is to target applications that use UDP as the transport protocol and to issue a request with a forged source IP address set to that of the intended target. Figure 5.1 illustrates an example of this reflection behavior in a DNS request. The primary purpose of the reflection technique is to conceal the true source of the attack, and leverage another network’s resources to execute the attack.
Another key concept in this class of attack is the notion of “amplification”. In terms of DDoS, amplification is when an attacker uses publicly available resources of a 3rd party to increase the intensity of an attack beyond their own capabilities and resources. In some scenarios, certain publicly accessible applications distributed throughout the globe may exceed the capabilities of even the largest botnets. In simple terms, amplification is when a request is sent to a server and the response is larger than the request. To take advantage of this scenario, an attacker needs to be able to direct the response traffic to the victim, and this is where amplification and reflection combine to achieve a devastating effect. Figure 5.2 illustrates how the DNS reflection attack shown earlier can be modified slightly to amplify the intensity. When this behavior is repeated at scale, DDoS attacks in excess of 100Gbps can easily be achieved. The table in Figure 5.3 (US-CERT TA14-017A) lists the amplification factor of protocols commonly used for DDoS.
| Protocol | Bandwidth Amplification Factor | Vulnerable Command |
|---|---|---|
| DNS | 28 to 54 | see: TA13-088A [4] |
| NTP | 556.9 | see: TA14-013A [5] |
| SNMPv2 | 6.3 | GetBulk Request |
| NetBIOS | 3.8 | Name resolution |
| SSDP | 30.8 | SEARCH request |
| CharGEN | 358.8 | Character generation request |
| QOTD | 140.3 | Quote request |
| BitTorrent | 3.8 | File search |
| Kad | 16.3 | Peer list exchange |
| Quake Network Protocol | 63.9 | Server info exchange |
| Steam Protocol | 5.5 | Server info exchange |
| Multicast DNS (mDNS) | 2 to 10 | Unicast query |
| RIPv1 | 131.24 | Malformed request |
| Portmap (RPCbind) | 7 to 28 | Malformed request |
Figure 5.3: US-CERT TA14-017A
Applications used for reflection and amplification DDoS attacks generally meet the following criteria:
- Source IP can be spoofed
To succeed, the attacker must be able to direct the 3rd party systems to send traffic to the victim. This generally means that the application must use a connectionless protocol like UDP or ICMP. - Response is significantly larger than request
The larger the response to request ratio, the more attractive the application is to being exploited by an attacker for amplification. - Plentiful number of public servers
The more prevalent an application is on the Internet, the greater the likelihood that it will be used for reflection and amplification attacks. This is why DNS and NTP are commonly exploited, while CHARGEN (Character Generation Protocol), which has been deprecated for over a decade, is infrequently used by attackers. - Reflection servers are on high bandwidth connections
To maximize the effect, the servers being used for amplification should be located on large network connections with significant computing resources. By using these services, an attacker can generate higher volumes of DDoS traffic.
Much like DDoS attacks originating from botnets, often the administrators of the systems that are being used in the reflection attack are unaware of their role in attacking a victim. Unless they have specific monitoring in place, they may not notice the additional network traffic volume. In part this is due to the attacker intentionally distributing their attack across a large number of intermediate systems. Individually, each system may only see a small increase in network traffic volume, but when all of these systems are combined the result can be significant. As an example, suppose an attacker has at their disposal 1000 DNS servers that can be used for amplification attacks. If each server generates just 100Mbps of traffic, this may go unnoticed by the system administrator, but to the victim the cumulative effect would be a 100Gbps DDoS attack.
Attack Impact
Link Saturation
The primary effect of the reflected amplification attack is the saturation of upstream links that connect the target network to the Internet. When more traffic is sent to a link than it can transmit, excess traffic is indiscriminately dropped by the upstream network device. This results in significant packet loss, causing either performance degradation or a full network outage.
Increased Load on Network Devices
The increase in overall network traffic caused by a reflected amplification DDoS attack, frequently causes higher than normal resource utilization on network devices such as routers, switches and firewalls. If these devices are not properly sized for the level of traffic, they may reboot, hang, or otherwise degrade in performance.
Conceal Other Attack Vectors
The reflected amplification DDoS attack produces so much traffic that it may make it difficult to detect more subtle attacks. Attackers have used reflected amplification attacks to overwhelm devices such as intrusion detection/preventions systems or firewalls. By rendering these devices ineffective, attackers can increase the success rate of traditional remote vulnerability exploitation.
Increased Network Costs
Many organizations use a burstable, or tiered, pricing model for purchasing network connectivity. A reflected amplification DDoS attack can raise IT costs by artificially increasing link utilization. An attack lasting just 8 hours once per month would be sufficient to artificially inflate network costs for customers using the common 95th percentile billing model.
Why Are Reflection and Amplification DDoS Attacks So Effective?
Finite Network Capacity
With few exceptions, organizations have a finite amount of network capacity that cannot be easily increased to handle the additional traffic caused by a reflected amplification DDoS attack. As an example, an organization may have a 1Gbps connection from their upstream ISP. Increasing the capacity to 10Gbps would likely require a new physical link (cable), more powerful network equipment (routers/firewalls/switches), and IT implementation time. The typical amount of time required by many ISPs to provision additional capacity is generally 4 to 6 weeks.
Traffic Sources Are Unaware of Their Involvement
For a reflection attack to work, it must allow an attacker to direct an intermediate system to send network traffic to the target. This is almost always done by spoofing the source IP address. The intermediate network may be completely unaware that their resources are being used to attack another network, or they may misinterpret the traffic as the target attacking them. The reflection may make the attack harder to diagnose and mitigate.
Allows an Attacker to Amplify Attack
By targeting applications that produce a response much larger than the request, an attacker can use limited network resources to generate a high volume attack. For example, an attacker may have access to a 1Gbps Internet circuit. If they target an application that provides 20:1 amplification (not uncommon), they now have the potential to launch a 20Gbps attack.
Fundamental to Topology of the Internet
The topology of the Internet is one of many interconnected smaller networks. This topology means that any one network, no matter how large the organization is, is dwarfed in scale by the combined network capacity of all networks connected to the Internet. Given this topology, reflected amplification DDoS attacks will always be possible and the scale of the attacks will primarily be dependent upon the ability of the attacker to leverage vulnerable applications for purposes of reflection and amplification.
Requires Upstream Blocking
To mitigate a reflected amplification DDoS attack, the traffic must be blocked prior to its transmission across the saturated network link. To do this requires the cooperation of network providers upstream from the targeted network. For small organizations this may entail contacting upstream ISPs, or for those using BGP routing, the creation and propagation of null routes. By forcing the mitigation to occur upstream, it can cause an organization to be dependent on vendors (like ISPs) that may be less skilled in DDoS mitigation.
Any Traffic Will Do
A reflected amplification DDoS attack can leverage any protocol, and target any endpoint even if the target is not providing a publicly accessible service. The only requirements for a reflected amplification DDoS attack is that the traffic is routed to the network that the attacker is trying to impact. For example, an attacker could send a large volume of UDP packets to an IP address and port not in use on the target network. Since the IP address is routable, the traffic will traverse the target organization’s network links causing impact.
Mitigation Strategies
Blocking With On-Premises Devices
Attempting to block a reflected amplification DDoS attack using on-premises devices such as IPS/IDS and firewalls is typically ineffective. This is because these devices are positioned downstream from the point at which the DDoS causes saturation of the link and packet loss (as illustrated in Figure 5.4).
Blocking Upstream by the ISP
If contacted, the technical support arm of most ISPs will add simple rules to block specific traffic before it reaches the target network. This approach can be effective at mitigating simplistic attacks, but will often be unable to mitigate more complex scenarios. The limitation is related to the minimal filtering capabilities offered by most ISPs. For example, most ISPs will be happy to filter all traffic to or from a specific IP address, or using a certain protocol. But this is a very blunt tool which may not be granular enough to block DDoS traffic that is similar in many respects to legitimate traffic.
Null Routing the Target IP
An organization that uses BGP may use null routes to prevent devices on the Internet from sending traffic to the target. The main benefit of this approach is its distributed effect, since the null route announcement is sent to all devices on the Internet that receive Internet routing table announcements. Since this mechanism results in the target IP becoming unreachable, it is only useful if the target IP is expendable and traffic can be discarded to save other resources on the same network. For this reason, null routes are typically only an effective mitigation in multi-user environments where a problematic user can be segmented off to ensure a good experience for the remaining users.
Hide Behind a Large CDN
Traditional content distribution networks (CDNs) function by locating webserver caches throughout the world to deliver content to the Internet. A CDN typically works as an HTTP(S) proxy where all requests are made to the CDN server, which then initiates a private connection to the organization’s server to obtain the data. With regard to reflected amplification attacks, using a CDN may implicitly protect a network from these types of attacks, because the traffic is sent to the CDN (Figure 5.5) which often is comprised of a massive, globally distributed network.
Dedicated Mitigation Services
A dedicated DDoS mitigation service, like that provided by Incapsula, is often the most effective solution. These services are similar to the CDN approach mentioned earlier, but with advanced capabilities specific to identifying and blocking DDoS traffic. Much like a CDN, reputable mitigation services have a massive globally distributed network of scrubbing centers capable of blocking large DDoS attacks.
Examples
DNS reflection and amplification attack
DNS is one of the most fundamental applications used on the Internet. It is primarily used for translating hostnames into IP addresses (i.e., www.example.com -> 10.100.10.10). The DNS infrastructure is a hierarchical and globally distributed directory with numerous servers being delegated as authoritative name servers for certain areas of the directory. For example, there are servers referred to as gTLD servers that are authoritative for “.com” domains, and these servers in turn have pointers to other DNS servers that are authoritative for “example.com”. DNS is an attractive DDoS tool for the following reasons:
- Significant amplification
Security researchers have been able to achieve an amplification rate of up to 179:1. - Easily Spoofed source IP address
DNS uses the UDP protocol which can easily be manipulated to have a forged source IP address. - DNS Infrastructure is massive
The DNS infrastructure is globally distributed and massive in size. Due to the critical nature of DNS, the servers often are located on very large network connections. Moreover, the global DNS infrastructure is operated by many different independent organizations, making a coordinated DDoS response nearly impossible.
Identifying a reflected and amplified DNS attack is relatively simple based on certain markers within a packet capture (see example below). Specifically note the following:
- Unusually high rate of DNS traffic
Despite its importance, in most environments DNS usually represents a negligible volume of traffic. DNS reflection and amplification attacks are typically massive in scale (measured in 10s of Gbps) and clearly stand out compared to normal traffic patterns. - Unsolicited responses
A packet capture of a normal DNS communication will show a request followed by a response. In a DNS reflection and amplification attack, only DNS responses will be observed. This is because the (forged) request was sent by the attacker. - Unusual responses
This item is somewhat subjective, but to achieve a high rate of amplification the attacker may issue DNS requests for certain high amplification items that are normally not seen. Notable among these is the DNS ANY response.
Example packet capture:
02:58:11.727630 IP 10.49.41.63.domain > 192.168.0.10.4292: 28956*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727637 IP 10.5.52.6.domain > 192.168.0.10.4592: 24992*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727640 IP 10.91.147.52.domain > 192.168.0.10.44492: 5342*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727659 IP 10.69.98.28.domain > 192.168.0.10.29242: 5821*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727662 IP 10.59.59.191.domain > 192.168.0.10.32482: 58911*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727695 IP 10.81.92.11.domain > 192.168.0.10.8391: 24811*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727698 IP 10.92.198.59.domain > 192.168.0.10.23931: 19425*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727728 IP 10.58.59.251.domain > 192.168.0.10.8244: 2284*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727738 IP 10.22.199.192.domain > 192.168.0.10.38191: 31132*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727762 IP 10.31.135.66.domain > 192.168.0.10.43134: 2991*- 5/0/3 NS ns1.example.com.,[|domain]
02:58:11.727763 IP 10.31.49.19.domain > 192.168.0.10.6243: 29146*- 5/0/3 NS ns1.example.com.,[|domain]
NTP reflection and amplification attack
NTP is another fundamental application used on the Internet. It is used by servers to synchronize clocks with an extreme level of accuracy. The public NTP infrastructure is a large globally distributed network of volunteer run time servers. The NTP infrastructure is organized in strata with atomic clocks and other sources of true time occupying stratum 0. Devices that synchronize to a stratum 0 source are stratum 1 and so forth. NTP is an attractive DDoS tool for the following reasons:
- Significant amplification
Security researchers have been able to achieve an amplification rate of up to 556:1. - Easily Spoofed source IP address
NTP uses the UDP protocol which can easily be manipulated to have a forged source IP address. - NTP Infrastructure is massive
The NTP infrastructure is globally distributed and massive in size. Due to the critical nature of NTP, the servers often are located on very large network connections. Like DNS, the global NTP infrastructure is also operated by many different independent organizations making a coordinated DDoS response nearly impossible.
Identifying a reflected and amplified NTP attack is relatively simple based on certain markers within a packet capture (see example below). Specifically note the following:
- Unusually high rate of NTP traffic
In most environments, NTP represents an important but often negligible volume of traffic. NTP reflection and amplification attacks are normally massive in scale (measured in 10s of Gbps) and stand out from normal traffic patterns. - Unsolicited responses
A packet capture of a normal NTP communication will show a request followed by a response. In an NTP reflection and amplification attack, only NTP responses will be observed. This is because the (forged) request was sent by the attacker. - Unusual responses
This item is somewhat subjective, but to achieve a high rate of amplification the attacker may issue NTP requests for certain high amplification items that are normally not seen. Notable among these is the “monlist” response. Monlist is a remote command in older versions of NTP that sends the requester a list of the last 600 hosts who have connected to that server.Example packet capture: 02:58:11.727630 IP 10.49.41.63.ntp > 192.168.0.10.4292: NTPv2, Reserved, length 482
02:58:11.727637 IP 10.5.52.6.ntp > 192.168.0.10.4592: NTPv2, Reserved, length 591
02:58:11.727640 IP 10.91.147.52.ntp > 192.168.0.10.44492: NTPv2, Reserved, length 928
02:58:11.727659 IP 10.69.98.28.ntp > 192.168.0.10.29242: NTPv2, Reserved, length 913
02:58:11.727662 IP 10.59.59.191.ntp > 192.168.0.10.32482: NTPv2, Reserved, length 937
02:58:11.727695 IP 10.81.92.11.ntp > 192.168.0.10.8391: NTPv2, Reserved, length 729
02:58:11.727698 IP 10.92.198.59.ntp > 192.168.0.10.23931: NTPv2, Reserved, length 1242
02:58:11.727728 IP 10.58.59.251.ntp > 192.168.0.10.8244: NTPv2, Reserved, length 283
02:58:11.727738 IP 10.22.199.192.ntp > 192.168.0.10.38191: NTPv2, Reserved, length 372
02:58:11.727762 IP 10.31.135.66.ntp > 192.168.0.10.43134: NTPv2, Reserved, length 442
02:58:11.727763 IP 10.31.49.19.ntp > 192.168.0.10.6243: NTPv2, Reserved, length 823
Understanding Risks
Overview
This course investigates areas of DDoS risk and provides a loose framework for understanding an organization’s DDoS risk level. Upon completion of this course, the participant will have an understanding of how an attacker identifies targets, and how an organization can reduce its DDoS risk.
DDoS Risk Framework
As we saw in the previous course material, the spectrum and number of permutations of DDoS attacks are immense. Combine this with the unique footprint of each organization’s applications and infrastructure, and the challenge of properly identifying and addressing DDoS risk becomes clear. To assist in this endeavor, a loose framework (Figure 6.1) is presented that can be used to identify and categorize DDoS risk.
Likelihood of Being Targeted
Like all information security risks, DDoS attack risk is in part related to the likelihood of being targeted by an attacker. This risk classification is primarily based upon the size and industry of the organization, and how it might relate to the motivations of an attacker (see course 1 for a refresher). It should be noted, though, that organizations in industries with a low likelihood of being targeted by a DDoS are still susceptible to an attack, and their overall risk may increase due to other risk factors. Figure 6.2 provides a high-level snapshot of the likelihood of being targeted based on industry.
Attack Impact
When assessing overall risk, the business impact of a DDoS attack is a significant factor that must be evaluated. This risk factor is primarily about understanding what losses may occur as a result of a DDoS attack. Common impacts are damage to reputation, lost sales, lost customers, and lost productivity. For example, the impact of a DDoS attack on a large online retailer is likely to be much greater than the impact to a personal blog. This impact, however, shouldn’t be measured in absolute terms. From the owner’s perspective, the damage to a neighborhood sandwich shop that loses its ability to accept online orders is no less significant than the damage to a large online retailer.
Attack Complexity
The ease with which an attacker can execute an effective DDoS attack is a significant factor that contributes to the overall risk of an organization. This risk factor is in part dependent on the attacker’s motivation (see course 1 for a refresher). A motivated attacker that seeks to damage a specific organization will devote more time and resources to an attack. Implementing effective DDoS protection and mitigation solutions directly affects this risk factor and can substantially reduce the overall risk of a DDoS attack.
Identifying Areas of Risk
With the above mentioned framework in mind, the organization’s infrastructure and business must be reviewed and each identified risk area must be classified. This identification process is partially subjective, and requires a complete understanding of the DDoS landscape and how it relates to the organization’s industry. Below are suggested technical and business areas to be investigated as part of this investigation. Each organization is unique, and this list is not exhaustive.
Technical
- Identify All Publicly Accessible Services
Network scanning tools such as nmap (www.nmap.org) can be used to enumerate all publicly accessible services within an organization’s network. This is often the first step in identifying susceptible applications. In general, the fewer network ingress points into an organization, the less exposure to risk. This same tool is often used by an attacker to collect intelligence prior to launching a DDoS attack. - Validate Capacity of Network Equipment
All network equipment should be validated to confirm operability at the limits of the Internet circuits. This validation should include bandwidth (Gbps) and transactions (packets/second) for a variety of protocols. - Enumerate Areas of Dynamic Content
Dynamic content is often targeted by application-level attacks, and the first step in understanding risk to these types of attacks is to create an inventory of these areas. Particular attention should be given to any HTML forms as these are common targets. To locate dynamic content, manual or automated review of all websites should be performed. - Assess Vendors
Outsourced components of an organization’s infrastructure should also be identified and assessed for resilience against DDoS attacks. An example might be an online retailer that has gone to great lengths to protect its own infrastructure, but is still impacted when its credit card processor is targeted by a DDoS attack.
Business
- Identify Business Critical Systems
Organizations often have a variety of business systems and processes with various levels of criticality. Each business system should be identified and ranked according to its criticality to the business. - Cost of Downtime
To properly understand risk, a business must quantify the cost of downtime for business critical systems. For an ordering system at an online retailer, this cost can be represented as $/hour in lost sales. Other losses such as damage to reputation may be more difficult to quantify, but should nonetheless be assessed to understand the general scope. - Identify Political Risk
Some organizations operate under increased risk due to political or socioeconomic factors. Well known examples were the attacks on major banks launched by Anonymous in the wake of the 2008 financial crisis. Similarly, politically outspoken corporate executives have at times painted a target on their business for “hacktivists”. - Understand Overall Industry Risks
It is important to understand how other organizations operating within the same industry have been impacted by DDoS attacks. By collecting data and sharing risk information within a specific sector, a business can learn from the mistakes of others. Additionally, the shared knowledge and communication may lead to a strategic response to DDoS threats within that industry.
Mitigation Techniques
Overview
This course covers DDoS mitigation techniques. Upon completion of this course, the participant will have an understanding of both high-level mitigation strategies and details of specific techniques used within these strategies.
High-Level Mitigation Strategies
Throughout the training courses, reference has been made to various high-level mitigation strategies. The primary differences among these approaches are where the mitigation takes place within the network and who is responsible for the mitigation.
On-Premises Mitigation Hardware
Numerous vendors produce network devices capable of mitigating DDoS attacks to varying degrees. This category of mitigation hardware includes devices such as:
- Traditional and “next-gen” firewalls
- Web application firewalls (WAF)
- Intrusion prevention/detection systems (IPS/IDS)
- Purpose-built DDoS mitigation appliances
- Load balancers
The approach of each vendor to DDoS mitigation can vary considerably. Purpose-built DDoS mitigation appliances generally offer the most complete suite of tools, with other devices offering a more limited selection. Although each solution has a different approach, common amongst all solutions is that the device is located on the target network. Figure 7.1 illustrates where these devices are typically located.
Advantages
- May already exist in the environment (such as firewalls)
- Under full control of the target IT staff
Limitations
- Unable to mitigate volumetric attacks, including volumetric application-layer DDoS attacks
- Doesn’t provide complete protection against all attack vectors
- Requires the target IT staff to be DDoS experts
- Must be configured and tested extensively to confirm efficacy
- Dedicated DDoS mitigation appliances can be very expensive
- Doesn’t scale with DDoS threats
ISP Blocking and “Clean Pipes”
Most ISPs, when prompted to do so by their customer, will implement basic filtering rules within their network to block DDoS traffic. These rules typically block traffic based upon Layer 3 (network layer) and Layer 4 (transport layer) data. Some examples might include:
- Block all traffic to/from IP x.x.x.x
- Block all HTTP traffic to/from IP x.x.x.x
- Block all ICMP traffic
- Block all UDP packets to port 53 larger than 500 bytes
To address the growing concerns of their customers, some ISPs have begun offering “clean pipe” services that attempt to block DDoS traffic upstream of the customer, and only send legitimate traffic. The techniques used vary considerably from one ISP to the next. Figure 7.2 illustrates where the “clean pipe” mitigation occurs in a typical environment.
Advantages
- Traffic is blocked upstream of the target
- Mitigation capacity scales as the internet connection scales
- ISP purportedly has DDoS experts to assist in mitigation
- ISPs typically have substantial network capacity to absorb even large attacks
Limitations
- ISP is unable to decrypt secure traffic, complicating application-level DDoS mitigation
- Mitigation can only occur on the protected internet circuit from the ISP
- DDoS mitigation is not the primary business/focus of the ISP
- Mitigation performed is a “black box” to the customer
Content Delivery Network (CDN)
Although not intended to be used as a DDoS mitigation platform, most traditional CDNs work well for this purpose. Key to their effectiveness is that they operate as an HTTP/S web proxy located on very large and widely distributed Internet connections. This configuration allows the much smaller target environment to hide behind the CDN and leverage its significant resources. Figure 7.3 illustrates how the CDN protects an environment.
Advantages
- Traffic is blocked upstream of the target
- Reputable CDN providers have massive capacity, providing significant mitigation capability
- Automatically protects against all volumetric and protocol DDoS attacks
- Many organizations already use CDNs
- Provides a secondary benefit of increased performance and reliability
Limitations
- Can only be used to protect services supported by the CDN, typically HTTP(S)
- Application-level DDoS attacks pass through the CDN to the target with no mitigation
DDoS Traffic Scrubbing Service
A DDoS traffic scrubbing service is a dedicated DDoS mitigation platform operated by a 3rd party that removes DDoS traffic upstream of the target. These services generally operate in either a routed or proxy mode as illustrated in figures 7.4 and 7.5. In the proxy mode, traffic is handled in much the same way as a CDN. All requests are made through proxy servers operated by the mitigation vendor, and only legitimate requests are passed through to the target’s real environment. In the routed mode, when mitigation is activated, all IP traffic is passed through the mitigation vendor. Once cleaned of DDoS traffic, the remaining traffic is passed through to the target environment by way of GRE tunnels or private network connections.
Advantages
- Traffic is blocked upstream of the target
- Reputable scrubbing services have massive capacity, providing significant mitigation capability
- Protects against all attack types
- Service is purpose-built to provide DDoS protection
- Allows a target to completely conceal resources behind DDoS mitigation service (routed mode)
- Mitigation is geographically distributed even if the target is not
Limitations
- Many services can only be used to protect supported services, typically HTTP and HTTPS (proxy mode), others offer individual IP address protection irrespective of protocol.
- Some services require BGP (routed mode)
- Requires routing changes that delay mitigation (routed mode)
- May require moving an entire netblock rather than mitigation of a single target (routed mode)
- May be limited to a small number of regional scrubbing centers
Detailed Mitigation Techniques
The high-level strategies outlined previously are primarily differentiated from each other by the location within the network environment at which the mitigation occurs. The actual techniques used to detect and discard traffic may be used across multiple high-level strategies. As an example, the SYN cookie mitigation technique may be activated as part of an on-premises mitigation strategy or used within a DDoS scrubbing service as part of their protection. Included below is a non-exhaustive list of common mitigation strategies. Just as there are many types of DDoS attacks, the techniques used to detect and mitigate them can often be equally numerous.
Source Address Rate Limiting
This mitigation technique sorts the traffic to the target based on the source IP address. By doing this, source IP addresses that are identified as sending an unusually high volume of traffic can be easily blocked. Source address rate limiting works best against non-spoofed DDoS attacks. With spoofed attacks, such as SYN floods, the source IP address is often randomized resulting in no identifiable true source for the attack traffic. This mitigation technique is found in dedicated DDoS mitigation services and hardware, but can also be pulled from NetFlow and logging data on general purpose network equipment.
Works well against:
- Non-spoofed volumetric attacks
- Non-spoofed attacks sourced from botnets
- Non-spoofed application-level attacks
Protocol Rate Limiting
This mitigation technique is similar to the source address rate limiting mentioned previously. Rather than sorting the traffic based on the source IP address, it is sorted by the actual protocol being used. In this manner a fixed limit on the amount of traffic can be set, protecting the environment so that other protocols may work properly. An example of this technique would be to set a limit of 10Mbps for ICMP traffic. Any ICMP traffic above 10Mbps is discarded, preventing the environment from being overwhelmed by the bad data. This particular technique is not precise and will cause the loss of legitimate data. In some cases, this loss may be acceptable in an effort to protect more critical services at the expense of less critical ones.
Works well against:
- Any attack that targets a non-critical protocol
- Volumetric attacks
Anomaly Detection
A fundamental concept of DDoS mitigation is the ability to separate good traffic from bad. In a hypothetically perfect DDoS attack, an attacker would be able to send traffic that mimics real user interactions and behaviors. By doing this, the attacker can make the identification of bad traffic nearly impossible. At the other end of the spectrum is a more rudimentary attack that might simply repeat the same identical request. To identify good traffic from bad, mitigation services and hardware vendors employ proprietary systems designed to detect and block anomalous traffic. These systems vary by vendor but often use statistical models and mathematical algorithms to make this determination.
Works well against:
- Application-level attacks
- Protocol attacks
HTTP/S Javascript Challenge
Anomaly detection works well in mitigating application-level attacks if a traffic history is available to identify good traffic from bad. When no history is available, it can be difficult to make this identification. The HTTP/S Javascript challenge technique attempts to solve this problem by focusing on the capabilities of the connecting client rather than the traffic itself. DDoS attack software is often minimal, without the features normally available in a standard web browser. One such feature is the ability to run Javascript. The Javascript challenge is a technique where the DDoS mitigation hardware or service will inject a piece of javascript code that the client browser must run to generate a cookie that can be used in subsequent requests. If the cookie is included in requests, then the request will be passed through to the target environment. Otherwise, the challenge will be presented again. By doing this, DDoS software with limited Javascript capabilities will be blocked outright.
Works well against:
- Application-level HTTP and HTTPS attacks
Reputation Data
A large portion of DDoS attacks are sourced from botnets that may contain hundreds of thousands of globally distributed attack nodes. To combat these botnet resources, DDoS mitigation service and hardware vendors operate reputation databases. These reputation databases collect and score the source IP addresses of traffic and use this score when determining which traffic to discard or allow. The approach used by each vendor is unique, but often entails explicit block and allow lists for sources with a known history of malicious and legitimate traffic, respectively. Reputation data is generally not used as the exclusive mechanism for discarding traffic, as it has a high probability of discarding legitimate traffic.
Works well against:
- Non-spoofed attacks
- Attacks sourced from botnets
SYN Cookies
The SYN flood is one of the most common DDoS attacks, and it works by overwhelming a system’s connection handling resources. With each new partial TCP connection, memory is allocated and an entry is created within the network state tracking table. The SYN cookie mitigation technique attempts to resolve this issue by sending a SYN-ACK back to the original sender with enough information to reassemble the full TCP connection if a response to the SYN-ACK is ever received. By crafting a special SYN-ACK, the target system will no longer need to allocate resources for the partial TCP connection. This is done through the use of a specially constructed initial sequence number in the SYN-ACK sent by the target.
Works well against:
- SYN floods
DDoS Trends
Overview
This course provides an overview of DDoS attack trends. Upon completion of this course, the participant will have an understanding of the history of DDoS attacks and how they evolved to the current state. This course also speculates on the future of DDoS attacks.
Timeline of Notable DoS Events
Date Event 1988 Robert Tappan Morris launches a self replicating worm that spreads uncontrollably throughout the Internet. Due to a flaw in the replication logic, the worm causes a massive unintentional DoS across much of the Internet. 1996 Source code for the SYN flood DoS becomes generally available on network security mailing lists. 1997 Hacker _eci releases source code for the WinNuke attack, a DoS that targets individual Windows systems. The attack is commonly used on Internet Relay Chat (IRC) networks for personal disputes. Hacker TFreak releases source code for the Smurf attack, an ICMP amplification DoS. The attack is commonly used against Internet Relay Chat (IRC) servers.
The “AS 7007 incident”, is the first notable BGP hijacking. Although unintentional, this results in a massive DoS to significant portions of the Internet.
1999 The trinoo, TFN, and Stacheldraht botnets are formed and are capable of launching DDoS attacks. A trinoo botnet attack on the University of Minnesota is often regarded as the first instance of a botnet DDoS attack. 2000 Michael “MafiaBoy” Calce (aged 15) launches successful DoS attacks against Yahoo!, Fifa.com, Amazon.com, Dell, E*TRADE, eBay and CNN. He also attempted, unsuccessfully, to attack the Internet root name servers. 2004 Hackers on 4chan develop the Low Orbit Ion Cannon (LOIC), a DDoS tool that would be used extensively by Anonymous and other groups to launch DDoS attacks. 2007 A series of DDoS attacks target various Estonian organizations. The attacks are suspected to have been orchestrated with Russian government approval. These attacks are notable as the first government sponsored DDoS attacks. 2008 Hacktivist collective Anonymous launches its first significant DDoS attack, successfully targeting the Church of Scientology. 2009 A coordinated DDoS attack targeting Facebook, Google Blogger, LiveJournal and Twitter is launched. The target is a Georgian blogger critical of Russia, and the attacks are suspected of being launched by the Russian government. 2010 Hacktivist collective Anonymous launches “Operation Avenge Assange” targeting banks that froze donations to Wikileaks. Targets included Visa, MasterCard, PayPal, and Amazon. 2013 A massive DDoS attack targeting anti-spam organization Spamhaus.org breaks records with traffic peaking at 300Gbps. 2014 The hacking group Lizard Squad initiates successful DDoS attacks against the Sony Playstation Network and Microsoft Xbox Live. The motivation for the attacks is to promote a DDoS-for-Hire service. 2015 A network security hardware manufacturer reports a DDoS attack in excess of 500Gbps against an unnamed customer. This attack is suspected to be the largest on record at that time. Multiple DDoS attacks suspected of being sponsored by the Chinese government target Github in an effort to disrupt anti-censorship service GreatFire.org.
The Evolution of DoS
Early Internet (pre-1995)
During the early days of the Internet, Denial of Service (DoS) attacks were very uncommon and the majority of “attacks” were unintentional. A well known example is the Morris Worm that wreaked havoc upon the early Internet. The intention of the worm was to discover the size of the Internet, but a mistake in the replication code made the worm much more aggressive than intended. The concept of a volumetric DoS attack was well understood due to the limited size of network connections at this time. Although not common, simple ICMP ping floods did exist.
Typical Attack Volume NA Common Attack Types ICMP ping
Unintentional DoSCommon Motivations Personal attacks
UnintentionalCommon Targets Individuals Common Attacker Profile Individual hackers
Security researchers
Network engineersDoS Infancy (1995-2000)
In 1996, source code for the SYN flood was released publicly on various network security mailing lists. This is the first notable instance of DoS source code being widely available, and initiated an era of rapid development of new DoS attacks. During this time, much of the development of DoS software was spurred by the growth of Internet Relay Chat (IRC), a popular real-time chat service. Attacks were launched by individuals or small groups as part of ongoing feuds and disputes. Due to the real-time nature of IRC, the attacks provided instant gratification for the attacker and only necessitated short barrages to achieve the desired result.
Typical Attack Volume 0-100 Mbps Common Attack Types ICMP/UDP volumetric attacks
SYN flood
WinNuke
Smurf/Fraggle attacksCommon Motivations Personal attacks
Online feuds
BraggingCommon Targets IRC users
IRC servers
Shell hosting servicesCommon Attacker Profile Individual hackers
Hacker groupsRise of Botnets (2000-2005)
Prior to 2000, the majority of DoS attacks were launched from individual attackers located on high bandwidth network connections. As the Internet continued to expand and network connections increased in capacity, attackers needed more resources to effectively launch their attacks. This was the catalyst for development of the first botnet, and the distributed denial of service (DDoS) attack was born. Although IRC was still a common target for attacks, websites of well known organizations and companies increasingly became victims. A notable example were the multiple attacks initiated in 2000 by Michael “MafiaBoy” Calce against Yahoo!, Amazon.com, Dell, E*TRADE, eBay and CNN. At the time he was 15 years old, and motivated by a desire to establish dominance for his group of hackers in the online world. With focus shifting from IRC to websites, the duration of attacks also increased.
Typical Attack Volume 0-10 Gbps Common Attack Types ICMP/UDP volumetric attacks
SYN flood
HTTP(S) request floodCommon Motivations Personal attacks
Online feuds
BraggingCommon Targets Websites
IRC users
IRC serversCommon Attacker Profile Individual hackers
Hacker groupsThe Hacktivist & State-Sponsored Threat (2005-2010)
A DDoS attack in 2007 targeting Estonia is speculated to be the first state-sponsored DDoS attack. This attack campaign originated from a political dispute between Estonia and Russia, and significantly impacted Estonia for nearly a month. At the same time hackers began to use DDoS as a tool for “hacktivism” by punishing organizations opposed to their agenda. One such event was the action initiated by the hacker collective Anonymous against the Church of Scientology. During this period DDoS attacks continued to expand both in volume and duration. As DDoS attacks increased in intensity and frequency, the DDoS mitigation industry began its rapid growth.
Typical Attack Volume 0-100 Gbps Common Attack Types ICMP/UDP volumetric attacks
SYN flood
HTTP(S) request floodCommon Motivations Hacktivism
State-sponsored
BraggingCommon Targets Websites Common Attacker Profile Individual hackers
Hacktivist groups
State-sponsoredAmplification and Reflection Attacks Push the Limits (2010-2016)
In the escalating DDoS arms race, attackers developed new tools to increase the impact and efficiency of their attacks. By exploiting certain protocols, attackers are able to amplify the effect of their attacks, reaching bandwidth amplification factors of up to 500. DNS and NTP amplification attacks are responsible for record breaking attack volumes of up to 500Gbps. During this period, the creation of the Bitcoin virtual currency ushered in a new era of DDoS for financial gain. Criminal gangs operate extortion schemes, using DDoS attacks to intimidate businesses. Botnet operators offer DDoS-for-Hire services that allow anyone to launch a DDoS attack for as little as $20.
Typical Attack Volume 0-500 Gbps Common Attack Types Amplification/Reflection attacks
ICMP/UDP volumetric attacks
SYN flood
HTTP(S) request floodCommon Motivations Hacktivism
State-sponsored
DDoS-for-Hire
ExtortionCommon Targets Websites Common Attacker Profile Individual hackers
Hacktivist groups
State-sponsored
Organized crimeInto the Future (2016+)
The history of DDoS shows a clear pattern of escalation. Starting as a tool used primarily by individual hackers in online feuds, DDoS attacks have become the online weapon of choice of governments, activists and organized crime. Recent DDoS attack activity suggests that terrorist organizations may soon follow suit. As DDoS mitigation capabilities increase, attackers will continue to develop their own capabilities in an ongoing arms race. This will inevitably lead to larger attacks, with a 1000Gbps attack expected within the next five years. Additionally, evolving application-level DDoS attacks will become more prevalent as a way to circumvent DDoS mitigation strategies.
Typical Attack Volume 0-1000 Gbps Common Attack Types Amplification/Reflection attacks
ICMP/UDP volumetric attacks
SYN flood
Layer-7 attacksCommon Motivations Hacktivism
State-sponsored
DDoS-for-Hire
Extortion
TerrorismCommon Targets Websites
Financial systemsCommon Attacker Profile Terrorist organizations
Hacktivist groups
State-sponsored
Organized crimeThe Exceptional Longevity of DDoS Attacks
DDoS attacks are unique from other security vulnerabilities in that they often have extraordinary longevity. As an example, the SYN flood first appeared in 1996, and twenty years later is still one of the most common attacks. While certain attacks have become extinct, the vast majority will continue to be effective well into the future. This longevity is primarily due to attacks exploiting fundamental weaknesses in the architecture of the Internet. The most notable example of this phenomenon is the volumetric attack, which will always be possible due to the finite amount of bandwidth for a given Internet connection.
source and pictures :https://www.ddosbootcamp.com/
Leave a Comment