{"id":1315,"date":"2018-10-10T18:18:53","date_gmt":"2018-10-10T11:18:53","guid":{"rendered":"https:\/\/lagonet.vn\/?p=1315"},"modified":"2018-10-10T18:18:53","modified_gmt":"2018-10-10T11:18:53","slug":"a-cisco-guide-to-defending-against-distributed-denial-of-service-attacks","status":"publish","type":"post","link":"https:\/\/kb.lagonet.vn\/?p=1315","title":{"rendered":"A Cisco Guide to Defending Against Distributed Denial of Service Attacks"},"content":{"rendered":"<table id=\"framework-base-content\" cellspacing=\"0\">\n<tbody>\n<tr>\n<td id=\"framework-column-main\">\n<div id=\"framework-content-main\">\n<div class=\"content_parsys parsys\">\n<div class=\"about layout-rst section\">\n<div class=\"layout-about parsys\">\n<div class=\"gd11v1 cl-grids section\">\n<div class=\"gdb gd11-pilot gd11v1-pilot\">\n<div class=\"gd-mid\">\n<div class=\"gd11v1-mid parsys\">\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><b>Contents<\/b><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#1\">Introduction: The Case for Securing Availability and the DDoS Threat<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#2\">Categorization of DDoS Attacks and Problems Caused<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#3\">DDoS Attack General Categories<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#4\">Volume-Based DDoS Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#5\">Application DDoS Flood Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#6\">Low-Rate DoS Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#7\">Detailed Examples of DDoS Attacks and Tools<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#8\">Internet Control Message Protocol Floods<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#9\">Smurf Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#10\">SYN Flood Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#11\">UDP Flood Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#12\">Teardrop Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#13\">DNS Amplification Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#14\">SIP INVITE Flood Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#15\">Encrypted SSL DDoS Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#16\">Slowloris<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#17\">Low Orbit Ion Cannon and High Orbit Ion Canon<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#18\">Zero-Day DDoS Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#19\">The DDoS Lifecycle<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#20\">Reconnaissance<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#21\">Exploitation and Expansion<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#22\">Command and Control<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#23\">Testing<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#24\">Sustained Attack<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#25\">Network Identification Technologies<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#26\">User\/Customer Call<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#27\">Anomaly Detection<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#28\">Cisco IOS NetFlow<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#29\">Packet Capture<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#30\">ACLs and Firewall Rules<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#31\">DNS<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#32\">Sinkholes<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#33\">Intrusion Prevention\/Detection System Alarms<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#34\">ASA Threat Detection<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#35\">Modern Tendencies in Defending Against DDoS Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#36\">Challenges in Defending DDoS Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#37\">Stateful Devices<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#38\">Route Filtering Techniques<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#39\">Unicast Reverse Path Forwarding<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#40\">Geographic Dispersion (Global Resources Anycast)<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#41\">Tightening Connection Limits and Timeouts<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#42\">Reputation-Based Blocking<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#43\">Access Control Lists<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#44\">DDoS Run Books<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#45\">Manual Responses to DDoS Attacks<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#46\">Traffic Scrubbing and Diversion<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#47\">Conclusion<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#48\">References<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#49\">NetFlow<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#50\">Reputation Management Tools<\/a><br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#51\">DDoS Run Book Case Study and Template<\/a><\/p>\n<h1>Introduction: The Case for Securing Availability and the DDoS Threat<\/h1>\n<p>Denial of service (DoS) and distributed denial of service (DDoS) attacks have been quite the topic of discussion over the past year since the widely publicized and very effective\u00a0<a href=\"http:\/\/tools.cisco.com\/security\/center\/viewAlert.x?alertId=30207\">DDoS attacks on the financial services industry<\/a>\u00a0that came to light in\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/ERP-financial-DDoS.html\">September and October 2012<\/a>\u00a0and resurfaced in\u00a0<a href=\"http:\/\/www.infosecurity-magazine.com\/view\/31142\/phase-3-of-the-op-ababil-ddos-attacks-on-us-banks-commences\/\" target=\"_blank\" rel=\"noopener\">March 2013<\/a>.<\/p>\n<p>The purpose of this white paper is to provide a number of tools, some or all of which may apply to a customer&#8217;s environment, that can be part of an overall toolkit to help identify and mitigate potential\u00a0<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/products\/security\/what-is-a-ddos-attack.html\">DDoS attacks<\/a>\u00a0on customer networks.<\/p>\n<p>The following quotes and excerpts are from several high-profile individuals and organizations that are focused on defending networks from these types of attacks:<\/p>\n<p>&#8220;&#8230;<i>recent campaigns against a number of high-profile companies\u2014including U.S. financial institutions\u2014serve as a reminder that any\u00a0cyber security threat has the potential to create significant disruption, and even irreparable damage, if an organization is not prepared for it.<\/i>&#8221;<\/p>\n<p>&#8220;<i>Cybercrime is no longer an annoyance or another cost of doing business. We are approaching a tipping point where the economic losses generated\u00a0<\/i><br \/>\n<i>by cybercrime are threatening to overwhelm the economic benefits\u00a0created by information technology. Clearly, we need new thinking and approaches to reducing the damage that cybercrime inflicts on the well-being of the world.<\/i>&#8221;<\/p>\n<p>The preceding quotes from\u00a0<a href=\"http:\/\/blogs.cisco.com\/author\/JohnStewart\" target=\"_blank\" rel=\"noopener\">John Stewart<\/a>, Cisco Senior Vice President and Chief Security Officer are eye opening considering that the miscreants are using the network infrastructure to financially impact organizations and diminish the purpose of this infrastructure.<\/p>\n<p>&#8220;<i>The bottom line is that unfortunately, no organization is immune to a data breach in this day and age&#8230;<\/i>&#8221;<\/p>\n<p>&#8220;<i>We have the tools today to combat cybercrime, but it&#8217;s really all about selecting the right ones and using them in the right way.<\/i>&#8221;<\/p>\n<p>&#8220;<i>In other words, understand your adversary &#8212; know their motives and methods, and prepare your defenses accordingly and always keep your guard up&#8230;<\/i>&#8221;<\/p>\n<p>These quotes from the\u00a0<a href=\"http:\/\/www.verizonenterprise.com\/resources\/reports\/rp_data-breach-investigations-report-2013_en_xg.pdf\">Verizon 2013 Data Breach Investigations Report<\/a>\u00a0(PDF) speak to the point that organizations are befuddled with the number of technologies, features, and processes available to help defend their networks. There is no one-size-fits-all approach. Each entity must determine which solutions meet its requirements and which help mitigate the threats that concern it.<\/p>\n<p><i>&#8220;The number of DDoS attacks in Q1 2013 increased by 21.75 percent over the same period of last year.&#8221;<\/i><\/p>\n<p><i>&#8220;Attacks targeting the infrastructure layer represented more than a third of all attacks observed during the first three months of 2013.&#8221;<\/i><\/p>\n<p>&#8220;<i>What defined this quarter (Q1 2013) was an increase in the targeting of Internet Service Provider (ISP) and carrier router infrastructures&#8230;<\/i>&#8221;<\/p>\n<p>While the preceding statements from\u00a0<a href=\"http:\/\/www.prolexic.com\/\" target=\"_blank\" rel=\"noopener\">Prolexic<\/a>\u00a0are certainly keeping service providers&#8217; (SP) network security experts awake at night, it is a legitimate fear that everyone should possess. If the core of the Internet is impacted by a malicious attack or inadvertent outage, we will all suffer because the Internet has become our lifeblood in terms of how we work, live, play, and learn.<\/p>\n<p>While the actual DDoS attacks garner the headlines, it is imperative that organizations also fully understand the impact of inadvertent, unmalicious outages. Two recent examples of unintentional events are the\u00a0<a href=\"http:\/\/inside.godaddy.com\/inside-story-happened-godaddy-com-sept-10-2012\/\">GoDaddy DNS Infastructure outage<\/a>\u00a0that took place in September 2012 and the\u00a0<a href=\"http:\/\/blog.cloudflare.com\/todays-outage-post-mortem-82515\">CloudFlare outage<\/a>\u00a0that occurred in March 2013. Although the details of each event differ, the key message is that each outage occurred on a production network, adversely impacted resources that thousands\u2014if not millions\u2014of people used, and was initially reported in the press as an &#8220;attack.&#8221;<\/p>\n<p>At the heart of many customers&#8217; concerns is the ability to protect against DDoS attacks. The focus may revolve around customers&#8217; own networks and data, network and data services that customers provide to their own customers, or a combination.<\/p>\n<p>While the network landscape and the nature of the assets that require protection will vary among customers and verticals, the general approach to mitigating DDoS attacks should be relatively similar across every environment. This approach should consist of, at a minimum, developing and deploying a solid security foundation that incorporates general best practices to detect the presence of outages and attacks and obtain details about them.<\/p>\n<p>At Cisco we have been espousing the following six-phase methodology to customers and at training conferences, Cisco Live, Black Hat, CanSecWest, and other venues.<\/p>\n<p><b>Figure 1. Six-Phase Methodology<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig01.jpg\" alt=\"The six phases are preparation, identification, classification, traceback, reaction, and postmortem\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>The\u00a0<i>Service Provider Security<\/i>\u00a0white paper provides more information about the\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/sp_infrastruct_scty.html#16\">six-phase methodology<\/a>.<\/p>\n<h2>Categorization of DDoS Attacks and Problems Caused<\/h2>\n<p>DDoS attacks have become a &#8220;Swiss army knife&#8221; for hacktivists, cyber criminals, and cyber terrorists, and in some cases used in nation-state attacks.<\/p>\n<p>These attackers and their campaigns are becoming sophisticated. Attackers are using evasion techniques outside of the typical volume-based attacks to avoid detection and mitigation, including &#8220;low and slow&#8221; attack techniques and SSL-based attacks. They are deploying multivulnerability attack campaigns that target every layer of the victim&#8217;s infrastructure, including the network infrastructure devices, firewalls, servers, and applications.<\/p>\n<p>In the following subsections, we cover the types of DDoS attacks, common methodologies and tools used, and the impact of each attack.<\/p>\n<h2>DDoS Attack General Categories<\/h2>\n<p>There are three different general categories of DDoS attacks:<\/p>\n<ul>\n<li>Volume-based DDoS attacks<\/li>\n<li>Application DDoS attacks<\/li>\n<li>Low-rate DoS (LDoS) attacks<\/li>\n<\/ul>\n<p><b>Volume-Based DDoS Attacks<\/b><\/p>\n<p>In volume-based (or volumetric) DDoS attacks, the attackers typically flood the victim with a high volume of packets or connections, overwhelming networking equipment, servers, or bandwidth resources. These are the most typical DDoS attacks. In the past, volumetric attacks were carried out by numerous compromised systems that were part of a botnet; now hacktivists not only use conventional attack methodologies, but also recruit volunteers to launch these attacks from their own machines. In addition, new waves of huge volumetric attacks are now launched from datacenters of cloud service providers, when attackers either rent or compromise cloud-based systems that have tremendous Internet bandwidth.<\/p>\n<p>A botnet is a gang of Internet-connected compromised systems that could be used to send spam email messages, participate in DDoS attacks, or perform other illegitimate tasks. The word botnet comes from the words\u00a0<i>robot<\/i>\u00a0and\u00a0<i>network<\/i>. The compromised systems are often called\u00a0<i>zombies<\/i>. Zombies can be compromised by tricking users into making a &#8220;drive-by&#8221; download, exploiting web browser vulnerabilities, or convincing the user to run other malware such as a trojan horse program. Figure 2 shows an example of a typical botnet.<\/p>\n<p><b>Figure 2. Botnet Example<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig02.jpg\" alt=\"botnet example\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>In this example, an attacker controls the zombies to launch a DDoS attack against the victim&#8217;s infrastructure. These zombies run a covert channel to communicate with the command-and-control server that the attacker controls. This communication often takes place over Internet Relay Chat (IRC), encrypted channels, bot-specific peer-to-peer networks, and even Twitter.<\/p>\n<p>With the advent of cloud services and providers, a new trend has emerged. Attackers are either renting or compromising large datacenter\/cloud machines to launch DDoS attacks. Cloud computing is not only creating new opportunities for legitimate organizations; it&#8217;s also providing a great platform for cyber criminals because it inexpensively and conveniently allows them to use powerful computing resources to do bad things. This concept is illustrated in Figure 3.<\/p>\n<p><b>Figure 3. Compromised Cloud Servers<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig03.jpg\" alt=\"compromised cloud servers\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><b>Application DDoS Flood Attacks<\/b><\/p>\n<p>Application DDoS attacks can target many different applications; however, the most common target HTTP aiming to exhaust Web servers and services. Some of these attacks are characteristically more effective than others because they require fewer network connections to achieve their goal. For instance, an attacker could launch numerous HTTP GETs or POSTS to exhaust a web server or web application.<\/p>\n<p>On the other hand, other applications such as Voice over IP (VoIP), DNS, and others are often targeted. Examples of these attacks are covered later in this paper.<\/p>\n<p><b>Low-Rate DoS Attacks<\/b><\/p>\n<p>Low-rate DoS (LDoS) attacks often take advantage of application implementation weaknesses and design flaws. A prime example of these types of attacks is\u00a0<a href=\"https:\/\/en.wikipedia.org\/wiki\/Slowloris_(computer_security)\">Slowloris<\/a>, a tool that allows an attacker to take down a victim&#8217;s web server with minimal bandwidth requirements and without launching numerous connections at the same time. Slowloris will be covered in detail later in this paper.<\/p>\n<h2>Detailed Examples of DDoS Attacks and Tools<\/h2>\n<p>The following are several examples of the more specific types of DDoS attacks and related tools.<\/p>\n<p><b>Internet Control Message Protocol Floods<\/b><\/p>\n<p>Internet Control Message Protocol (ICMP) flood attacks have existed for many years. They are among the oldest types of DoS attacks. In ICMP flood attacks, the attacker overwhelms the targeted resource with ICMP echo request (ping) packets, large ICMP packets, and other ICMP types to significantly saturate and slow down the victim&#8217;s network infrastructure. This is illustrated in Figure 4.<\/p>\n<p><b>Figure 4. ICMP Flood Example<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig04.jpg\" alt=\"ICMP flood example\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><b>Smurf Attacks<\/b><\/p>\n<p>Another type of ICMP-based attack is a smurf attack. The name\u00a0<i>smurf<\/i>\u00a0comes from the original exploit tool source code,\u00a0<i>smurf.c<\/i>, created by an individual called TFreak in 1997. In a smurf attack, an attacker broadcasts a large number of ICMP packets with the victim&#8217;s spoofed source IP to a network using an IP broadcast address. This causes devices in the network to respond by sending a reply to the source IP address. This exchange is illustrated in Figure 5.<\/p>\n<p><b>Figure 5. Smurf Attack<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig05.jpg\" alt=\"smurf attack\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>This attack can easily be mitigated on a Cisco IOS device by using the\u00a0<b>no ip directed-broadcast\u00a0<\/b>subinterface command, as shown in the following example:<\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<blockquote>\n<pre>Router(config)# <strong>interface GigabitEthernet 0<\/strong>\nRouter(config-if)# <strong>no ip directed-broadcast<\/strong><\/pre>\n<\/blockquote>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><b>Note:<\/b>\u00a0Additional mitigation techniques are covered later in this paper.<\/p>\n<p><b>SYN Flood Attacks<\/b><\/p>\n<p>When a host (client) initiates a TCP connection to a server, the client and server exchange a series of messages to establish the connection. This connection establishment is called the TCP three-way handshake. This is illustrated in Figure 6.<\/p>\n<p><b>Figure 6. TCP Three-Way Handshake<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig06.jpg\" alt=\"TCP three-way handshake\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<ul>\n<li>The client requests a connection by sending a SYN (synchronize) message to the server<\/li>\n<li>The server acknowledges this request by sending SYN-ACK back to the client<\/li>\n<li>The client responds with an ACK (acknowledgement) and the connection is established<\/li>\n<\/ul>\n<p>In a SYN flood attack, the attacker does not reply to the server with the expected ACK. To do this, the attacker can spoof the source IP address or simply not reply to the SYN-ACK. This is illustrated in Figure 7.<\/p>\n<p><b>Figure 7. SYN Flood Example<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig07.jpg\" alt=\"SYN flood example\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><a href=\"http:\/\/tools.ietf.org\/html\/rfc4987\" target=\"_blank\" rel=\"noopener\">RFC 4987<\/a>\u00a0provides more information about how TCP SYN flood attacks work and common mitigations.<\/p>\n<p>Later in this paper we cover modern techniques for mitigating these types of attacks.<\/p>\n<p><b>UDP Flood Attacks<\/b><\/p>\n<p>Similar to TCP flood attacks, the main goal of the attacker when performing a UDP flood attack is to cause system resource starvation. A UDP flood attack is triggered by sending a large number of UDP packets to random ports on the victim&#8217;s system. The system will notice that no application listens at that port and reply with an ICMP destination unreachable packet. Subsequently, if a large number of UDP packets are sent, the victim will be forced to send numerous ICMP packets. In most cases, these attacks are accomplished by spoofing the attacker&#8217;s source IP address. Most modern operating systems now limit the rate at which ICMP responses are sent, minimizing the impact and mitigating this type of DDoS attack.<\/p>\n<p><b>Teardrop Attacks<\/b><\/p>\n<p>Teardrop attacks involve sending crafted packets with overlapping, over-sized payloads to the victim system. Modern operating systems are now immune to this attack, but because of a deficiency in the TCP fragmentation and reassembly implementation of older operating systems, this attack caused a crash of those systems.<\/p>\n<p><b>DNS Amplification Attacks<\/b><\/p>\n<p>A Domain Name System (DNS) request can be recursive or nonrecursive (or iterative). Client applications, such as Internet browsers, typically request that the DNS server perform recursion by setting a Recursion Desired (RD) flag in the DNS request packet. If the DNS server cannot answer the request either from its cache or zone information, the server will request assistance from other DNS servers. See\u00a0<a href=\"http:\/\/technet.microsoft.com\/en-us\/library\/cc961401.aspx\" target=\"_blank\" rel=\"noopener\">Recursive and Iterative Queries<\/a>\u00a0for an explanation of this process.<\/p>\n<p>Unfortunately, many recursive name servers accept DNS queries from any source. In addition, many DNS implementations allow recursion by default, even when the name server is anticipated to serve only authoritative requests. This is known as an\u00a0<i>open resolver<\/i>. DNS open resolvers are vulnerable to multiple malicious attacks, such as DNS cache poisoning and DDoS attacks.<\/p>\n<p>A DNS amplification attack is the most common DDoS attack that uses recursive name servers, although some DNS amplifications attacks may not require a recursive server to be successful. DNS amplification attacks are similar to smurf attacks. In a smurf attack, an attacker can send spoofed ICMP echo requests (type 8) to create a DoS condition. In a DNS amplification DDoS attacker, an attacker sends small, spoofed address queries to an open resolver, causing it to send much larger responses to the spoofed-address target. Subsequently, the resolver contributes to the DDoS attack on spoofed addresses. Figure 8 illustrates the basic steps of a DNS amplification DDoS attack.<\/p>\n<p><b>Figure 8. DNS Amplification Attack<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig08.jpg\" alt=\"DNS amplification attack\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>The following steps are illustrated in Figure 8:<\/p>\n<ol>\n<li>The attacker triggers and directs the compromised machines to begin the attack<\/li>\n<li>The compromised machines send a DNS query for the domain\u00a0<i>example.com<\/i>\u00a0and set the source IP address to the victim&#8217;s IP address<\/li>\n<li>The open resolver servers ask the upstream name server(s) the location of\u00a0<i>example.com<\/i><\/li>\n<li>The name server sends a reply back to the open recursive servers<\/li>\n<li>The open recursive servers send DNS responses to the victim<\/li>\n<\/ol>\n<p><b>Note:<\/b>\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/dns-bcp.html\">DNS Best Practices, Network Protections, and Attack Identification<\/a>\u00a0provides information about general best practices, network protections, and attack identification techniques that operators and administrators can use for DNS implementations:<\/p>\n<p>Additional modern DDoS mitigation techniques are covered later in this paper.<\/p>\n<p>The\u00a0<a href=\"http:\/\/openresolverproject.org\/\">Open DNS Resolver Project<\/a>\u00a0maintains a list of DNS servers that are known open resolvers.<\/p>\n<p>The\u00a0<a href=\"http:\/\/dns.measurement-factory.com\/\">Measurement Factory<\/a>\u00a0is similar to the Open DNS Resolver Project. It keeps a list of Internet-accessible DNS servers and allows the community to search for open recursive resolvers. It also provides a free tool to test a single DNS server to determine whether it allows open recursion.<\/p>\n<p><a href=\"http:\/\/www.dnsinspect.com\/\">DNSInspect<\/a>\u00a0is another free web-based tool for testing DNS resolvers.<\/p>\n<p><b>SIP INVITE Flood Attacks<\/b><\/p>\n<p>The Session Initiation Protocol (SIP) is a VoIP standard defined in RFC 3261. SIP INVITE messages are used to establish a media session between user and calling agents. In SIP INVITE flood attacks, the attacker sends numerous (often spoofed) INVITE messages to the victim, causing network degradation or a complete DoS condition.<\/p>\n<p><b>Encrypted SSL DDoS Attacks<\/b><\/p>\n<p>Encrypted (SSL-based) DDoS attacks are becoming more prevalent because they allow attackers to gain the following advantages:<\/p>\n<ul>\n<li>Encrypted DDoS attacks consume more CPU resources during the encryption and decryption process. Consequently, they amplify the impact on the victim system or network.<\/li>\n<li>Numerous DDoS mitigation technologies do not support decryption of SSL traffic. A large number of these attacks cannot be scrubbed.<\/li>\n<\/ul>\n<p><b>Note:<\/b>\u00a0Modern mitigation capabilities for SSL DDoS attacks are covered later in this paper.<\/p>\n<p><b>Slowloris<\/b><\/p>\n<p>Slowloris is an attack tool created by RSnake (Robert Hansen) that tries to keep numerous connections open on a web server. The attack works by opening connections on the victim&#8217;s server and sending a partial request. Intermittently, the attack sends subsequent HTTP headers. However, the attack does not complete the request to maintain these connections as open until the victim is not able to process requests from legitimate clients.<\/p>\n<p>Similar attack tools and methodologies exist. The following are a few examples:<\/p>\n<ul>\n<li><a href=\"http:\/\/sourceforge.net\/projects\/pyloris\/\" target=\"_blank\" rel=\"noopener\">PyLoris<\/a><\/li>\n<li>QSlowloris (a variant of Slowloris for Windows)<\/li>\n<li><a href=\"https:\/\/code.google.com\/p\/slowhttptest\/\">slowhttptest<\/a><\/li>\n<\/ul>\n<p><b>Low Orbit Ion Cannon and High Orbit Ion Canon<\/b><\/p>\n<p>Low Orbit Ion Cannon (<a href=\"http:\/\/tools.cisco.com\/security\/center\/viewAMBAlert.x?alertId=22056\">LOIC<\/a>) and High Orbit Ion Canon (<a href=\"http:\/\/tools.cisco.com\/security\/center\/viewAlert.x?alertId=28879\">HOIC<\/a>) have become popular DDoS tools for hacktivist groups such as Anonymous and the Syrian Electronic Army. These tools allow even nontechnical people to create a DDoS attack with a few clicks using their own computers instead of the traditional bot-served attacks.<\/p>\n<p><b>Zero-Day DDoS Attacks<\/b><\/p>\n<p>Zero-day DDoS attacks (often called one-packet-killers) are vulnerabilities in systems that allow an attacker to send one or more packets to an affected system to cause a DoS condition (a crash or device reload). These attacks are often the most stealthy and difficult to detect because they often are unknown to vendors and no patches or workarounds exist. Typically, these type of vulnerabilities and exploits are sold in the underground market, making them one of the biggest threats for any organization. The weaponization of these types of exploits is becoming the new normal for cyber criminals.<\/p>\n<h1>The DDoS Lifecycle<\/h1>\n<p>The motives, targets, and scope of a DDoS attack have evolved over the past decade. The primary goal of the attack, however\u2014to deny network users access to resources\u2014has not evolved. The components that make up an attack have not changed much either. To understand the DDoS lifecycle, it is important to first understand the components that make up the infrastructure of an attack. The lifecycle described here focuses primarily on the botnet, or a collection of zombie machines reporting to one or more command-and-control (C2) servers.<\/p>\n<p><b>Reconnaissance<\/b><\/p>\n<p>The beginning of a DDoS attack is characterized by manual or automated attempts to find vulnerable hosts to act as C2 servers or botnet clients. The reconnaissance may come from the attacker in the form of IP probes (also called ping sweeps). These probes can create a smaller list of hosts to probe further with port scans. Port scans provide more information about the host, such as the services offered and the operating system version. The attacker uses this information to determine the easiest way to exploit a vulnerability.<\/p>\n<p><b>Figure 9. DDoS Reconnaissance<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\"><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig09.jpg\" alt=\"DDoS reconnaissance\" width=\"400\" \/><\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><b>Exploitation and Expansion<\/b><\/p>\n<p>After the potential victims are identified, they are targeted for exploitation so that the attacker can control the targeted system. The exploited system can now become a part of the DDoS infrastructure. Depending on the needs of the attacker, the victim machine may become a C2 server, send DDoS traffic, or propagate exploits to other machines. After time has passed, the botnet can grow to thousands, even millions, of hosts.<\/p>\n<p><b>Figure 10. DDoS Infrastructure Components<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig10.jpg\" alt=\"DDoS infrastructure components\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>It is important to note that not all hosts participating in a DDoS attack are victims of an exploit. Sometimes people who are sympathetic to a political cause willingly install DDoS software to harm a specific target. Likewise, botnets are used for purposes other than DDoS attacks.<\/p>\n<p><b>Command and Control<\/b><\/p>\n<p>Botnets require maintenance. Internet Relay Chat (IRC), a form of real-time text messaging, uses a client\/server model and is also a common botnet communication protocol. The zombie clients and the C2 servers must communicate to deliver instructions to the clients, such as timing an attack or updating malware. A peer-to-peer (P2P) botnet model is more difficult to detect and disrupt because the connections are many-to-many, reducing the risk that an offline C2 server will disrupt operations.<\/p>\n<p><b>Testing<\/b><\/p>\n<p>A botnet reaches critical mass when there are enough hosts to generate traffic with enough bandwidth to saturate the victim. When the botnet reaches this point, there will likely be a testing period. Victims of the testing will see a large amount of traffic over a few seconds or minutes. The attacker can assess the effectiveness of the attack and make adjustments prior to creating the sustained attack. Often the traffic in a sustained attack changes over time, and the attacker will test these changes to maximize the impact on the victim.<\/p>\n<p><b>Sustained Attack<\/b><\/p>\n<p>The attacker determines when to instruct the botnet clients to begin sending traffic to the targeted infrastructure. The main body of the DDoS attack may last from hours to weeks, depending on the motives of the attacker. Layer 7 attacks are becoming more popular, and they come mostly in the form of HTTP GET floods, SSL GET floods, and HTTP POST floods. Amplification attacks are increasing in popularity.<\/p>\n<h1>Network Identification Technologies<\/h1>\n<p>To be properly prepared to defend the network infrastructure from DDoS attacks, it is extremely important to know as soon as possible that there is anomalous behavior, malicious or otherwise, occurring in the network. Having a pre-emptive awareness of malicious or nefarious behaviors and other incidents in the network will go a long way toward minimizing any downtime that impacts the network&#8217;s data, resources, and end users.<\/p>\n<p>The following is a partial list of tools and technologies that are available&#8211;some of which are probably already present in the network\u2014to help aid in the detection, identification, and subsequent classification of anomalous network events. These tools and technologies will help focus on Indicators of Compromise (IOC).<\/p>\n<p><b>User\/Customer Call<\/b><\/p>\n<p>We are all too familiar with the phone call we get from our end user, customer, or even sometimes from our parents and grandparents! It usually starts with &#8220;The Internet is down. Can you help me?&#8221; Well, in most cases, we can be certain that the entire Internet itself is not down but there is some factor, or factors, that are impeding our ability to connect to the server, application, data, etc. we need to access. Regardless of the specifics of the scenario, we want to prevent an end user from telling us of a problem. Although requests from end users are sometimes the first time we find out about a network problem, we would rather be proactively notified of an issue prior before the users discover it. The balance of our list will help us do just that.<\/p>\n<p><b>Anomaly Detection<\/b><\/p>\n<p>As with many of these techniques, we need established baselines for network performance. These can include, but are not limited to, bandwidth usage, device CPU utilization, and traffic type breakdowns. It is simply impossible to detect changes in the network baseline if we have not established these baselines.<\/p>\n<p>Networks and network-enabled devices constantly create traffic. However, this traffic follows certain patterns according to application and user behavior. Analyzing these patterns allows us to see what is\u00a0<i>not<\/i>\u00a0normal. The key is to collect traffic information (NetFlow) and calculate various statistics to compare against a baseline. The resulting abnormalities are then analyzed in more detail.<\/p>\n<p><b>Cisco IOS NetFlow<\/b><\/p>\n<p><a href=\"http:\/\/www.cisco.com\/go\/netflow\">Cisco IOS NetFlow<\/a>\u00a0is a form of network telemetry that Cisco routers and switches can collect locally or push.<\/p>\n<p><b>Figure 11. Cisco IOS NetFlow<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig11.jpg\" alt=\"Cisco IOS NetFlow\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>Data provided through NetFlow is similar to information in a phone bill. The user can view who is talking (source and destination IP address) and how long the conversations last (amount of traffic in terms of bytes and packets).<\/p>\n<p>Figure 12 highlights the seven key parameters (as used in NetFlow version 5) that are inspected in each packet to determine whether a new flow should be created. If any of the seven fields differs from flows that have previously been created, a new flow is created and added to the NetFlow cache. The seven fields are as follows:<\/p>\n<ul>\n<li>Source IP address<\/li>\n<li>Destination IP address<\/li>\n<li>Source port<\/li>\n<li>Destination port<\/li>\n<li>Layer 3 protocol<\/li>\n<li>TOS byte<\/li>\n<li>Input interface<\/li>\n<\/ul>\n<p><b>Figure 12. NetFlow Key Parameters<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig12.jpg\" alt=\"NetFlow Key Parameters\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>NetFlow data can be exported from network devices to a variety of open source and commercial NetFlow Collection tools. The Cisco Cyber Threat Defense Solution is an effective method of collecting and analyzing NetFlow data. Cyber Threat Defense brings together the work of Cisco and Lancope to quickly and effectively identify anomalous behavior in the network and provide insight into how some of this behavior can be addressed. For more details on this solution, see\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/netsol\/ns1238\/index.html\">Cisco Cyber Threat Defense<\/a>.<\/p>\n<p><b><i>NetFlow Output Example: Financial Distributed Denial of Service Attacks Targeting Financial Institutions<\/i><\/b><\/p>\n<p>Cisco IOS NetFlow data on Cisco IOS routers and switches aided in the identification of IPv4 traffic flows that could have been attempts to perform the DDoS attacks against financial institutions. The following example shows NetFlow output that indicates the types of traffic flows seen during the DDoS events:<\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<pre>router#show ip cache flow\nIP packet size distribution (90784136 total packets):\n  1-32  64  96 128 160 192 224 256 288 320 352 384 416 448 480\n  .000 .698 .011 .001 .004 .005 .000 .004 .000 .000 .003 .000 .000 .000 .000\n  512 544 576 1024 1536 2048 2560 3072 3584 4096 4608\n  .000 .001 .256 .000 .010 .000 .000 .000 .000 .000 .000\nIP Flow Switching Cache, 4456704 bytes\n 1885 active, 63651 inactive, 59960004 added\n 129803821 ager polls, 0 flow alloc failures\n Active flows timeout in 30 minutes\n Inactive flows timeout in 15 seconds\nIP Sub Flow Cache, 402056 bytes\n 0 active, 16384 inactive, 0 added, 0 added to flow\n 0 alloc failures, 0 force free\n 1 chunk, 1 chunk added\n last clearing of statistics never\nProtocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)\n--------         Flows     \/Sec     \/Flow  \/Pkt     \/Sec     \/Flow     \/Flow\nTCP-Telnet    11393421      2.8         1    48      3.1       0.0       1.4\nTCP-FTP            236      0.0        12    66      0.0       1.8       4.8\nTCP-FTPD            21      0.0     13726  1294      0.0      18.4       4.1\nTCP-WWW          22282      0.0        21  1020      0.1       4.1       7.3\nTCP-X              719      0.0         1    40      0.0       0.0       1.3\nTCP-BGP              1      0.0         1    40      0.0       0.0      15.0\nTCP-Frag         70399      0.0         1   688      0.0       0.0      22.7\nTCP-other     47861004     11.8         1   211     18.9       0.0       1.3\nUDP-DNS            582      0.0         4    73      0.0       3.4      15.4\nUDP-NTP         287252      0.0         1    76      0.0       0.0      15.5\nUDP-other       310347      0.0         2   230      0.1       0.6      15.9\nICMP             11674      0.0         3    61      0.0      19.8      15.5\nIPv6INIP            15      0.0         1  1132      0.0       0.0      15.4\nGRE                  4      0.0         1    48      0.0       0.0      15.3\nTotal:        59957957     14.8         1   196     22.5       0.0       1.5\nSrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts\nGi0\/0         192.168.10.201  Gi0\/1         192.168.60.102  06 0984 0050     1\nGi0\/0         192.168.11.54   Gi0\/1         192.168.60.158  06 0911 0035     3\nGi0\/1         192.168.150.60  Gi0\/0         10.89.16.226    06 0016 12CA     1\nGi0\/0         192.168.10.17   Gi0\/1         192.168.60.97   11 0B89 0050     1\nGi0\/0         10.88.226.1     Gi0\/1         192.168.202.22  11 007B 007B     1\nGi0\/0         192.168.12.185  Gi0\/1         192.168.60.239  11 0BD7 0050     1\nGi0\/0         10.89.16.226    Gi0\/1         192.168.150.60  06 12CA 0016     1\nrouter#<\/pre>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>In the preceding example, there are multiple flows for\u00a0<b>UDP\u00a0<\/b>port\u00a0<b>80 (hex value 0050)<\/b>. In addition, there are also flows for\u00a0<b>TCP\u00a0<\/b>port\u00a0<b>53 (hex value 0035)<\/b>\u00a0and\u00a0<b>TCP\u00a0<\/b>port\u00a0<b>80 (hex value 0050)<\/b>.<\/p>\n<p>The packets in these flows may be spoofed and may indicate an attempt to perform these attacks. It is advisable to compare the flows for\u00a0<b>TCP\u00a0<\/b>port\u00a0<b>53 (hex value 0035)<\/b>\u00a0and\u00a0<b>TCP\u00a0<\/b>port\u00a0<b>80 (hex value 0050)\u00a0<\/b>to normal baselines to aid in determining whether an attack is in progress.<\/p>\n<p>As shown in the following example, to view only the packets on UDP port 80 (hex value 0050), use the\u00a0<b>show ip cache flow | include SrcIf|_11_.*0050<\/b>\u00a0command to display the related Cisco NetFlow records.<\/p>\n<p><b>UDP Flows<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<pre>router#show ip cache flow | include SrcIf|_11_.*0050\nSrcIf     SrcIPaddress   DstIf     DstIPaddress  Pr SrcP DstP Pkts\nGi0\/0     192.168.12.110  Gi0\/1     192.168.60.163 11 092A 0050   6\nGi0\/0     192.168.11.230  Gi0\/1     192.168.60.20  11 0C09 0050   1\nGi0\/0     192.168.11.131  Gi0\/1     192.168.60.245 11 0B66 0050  18\nGi0\/0     192.168.13.7   Gi0\/1     192.168.60.162 11 0914 0050   1\nGi0\/0     192.168.41.86  Gi0\/1     192.168.60.27  11 0B7B 0050   2\nrouter#<\/pre>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><b>Packet Capture<\/b><\/p>\n<p>Whereas NetFlow can provide macro analytic details of the traffic traversing the network, packet captures can provide the micro analytic details, such as the actual data (or words used) in a conversation. There will be certain situations in which there is simply no substitute for looking at the packets on the wire. Packet capture can be accomplished on Cisco network devices in a number of ways:<\/p>\n<ul>\n<li>SPAN\/RSPAN\/ERSPAN<\/li>\n<li>VACL Capture<\/li>\n<li>Router IP Traffic Export (RITE)<\/li>\n<li><a href=\"http:\/\/www.cisco.com\/en\/US\/prod\/collateral\/iosswrel\/ps6537\/ps6555\/ps9913\/datasheet_c78-502727.html\">Embedded Packet Capture (EPC)<\/a><\/li>\n<li><a href=\"http:\/\/www.cisco.com\/en\/US\/products\/ps6120\/products_tech_note09186a0080a9edd6.shtml\">Firewall Packet Capture<\/a><\/li>\n<\/ul>\n<p>A number of open source tools, such as tcpdump, snoop, and Wireshark (<a href=\"http:\/\/www.wireshark.org\/\" target=\"_blank\" rel=\"noopener\">http:\/\/www.wireshark.org<\/a>), can drill down into the packet contents from packet captures. In addition, it is important to know that some of these tools can look into and match specific fields in the packet (for example, source and destination IP, protocol, and length.) Some tools can also display the top ports or protocols used in the captures, which could help identify potential DoS activity.<\/p>\n<p>The following is an example of packet capture output that is being further analyzed by Wireshark:<\/p>\n<p><b>Figure 13. Wireshark Packet Capture Analysis<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><a href=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig13-higher-res.jpg\"><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig13.jpg\" alt=\"wireshark packet capture analysis\" width=\"600\" \/><\/a><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><b>ACLs and Firewall Rules<\/b><\/p>\n<p>Although the primary purpose of access control lists (ACLs) and firewall rules is to filter traffic to and through various ingress and egress points of the network, they can also enhance the visibility of the traffic flowing through the network.<\/p>\n<p>The following documents provide guidelines for using various types of ACLs to filter traffic and describe how ACL logging can be used to gain an understanding of the type of traffic that is allowed and denied throughout the network:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/acl-logging.html\">Understanding Access Control List Logging<\/a><\/li>\n<li><a href=\"http:\/\/www.cisco.com\/en\/US\/tech\/tk648\/tk361\/technologies_white_paper09186a00801afc76.shtml\">Transit Access Control Lists: Filtering at Your Edge<\/a><\/li>\n<li><a href=\"http:\/\/www.cisco.com\/en\/US\/tech\/tk648\/tk361\/technologies_white_paper09186a00801a1a55.shtml\">Protecting Your Core: Infrastructure Protection Access Control Lists<\/a><\/li>\n<\/ul>\n<p><b><i>Firewall Syslog Output Example: Financial Distributed Denial of Service Attacks Targeting Financial Institutions<\/i><\/b><\/p>\n<p>The following example of firewall syslog messages indicates the types of traffic being sent, and subsequently dropped, by firewalls during the DDoS events that took place against financial institutions in September and October 2012.<\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<pre>firewall#show logging | grep 106023\n Oct 04 2012 00:15:13: %ASA-4-106023: Deny udp src outside:192.0.2.18\/2944\n     dst inside:192.168.60.191\/80 by access-group \"tACL-Policy\"\n Sep 04 2012 00:15:13: %ASA-4-106023: Deny udp src outside:192.0.2.200\/2945\n     dst inside:192.168.60.33\/80 by access-group \"tACL-Policy\"\nfirewall#<\/pre>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>In the preceding example, the messages logged for the tACL\u00a0<i>tACL-Policy<\/i>\u00a0show potentially spoofed\u00a0<b>IPv4\u00a0<\/b>packets for\u00a0<b>UDP port 80<\/b>\u00a0sent and dropped by the firewall. This was the type of traffic being seen during DDoS attacks against financial institutions.<\/p>\n<p>The following document provides information about using syslog to identify incidents:\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/identify-incidents-via-syslog.html\">Identifying Incidents Using Firewall and Cisco IOS Router Syslog Events<\/a>.<\/p>\n<p><b>DNS<\/b><\/p>\n<p>DNS is a &#8220;background&#8221; service we do not often think about, but it is actually used many times each day by every user in every organization. A profusion of application types use name-based lookups using DNS. These include the following:<\/p>\n<ul>\n<li>Web browsers<\/li>\n<li>Email servers<\/li>\n<li>Web servers<\/li>\n<li>Malware such as trojans and bots running on compromised hosts<\/li>\n<\/ul>\n<p>Administrators can\u00a0<i>and should<\/i>\u00a0examine DNS logs and statistics as regularly as possible. This DNS-related information should then be correlated with other forms of telemetry (such as NetFlow, packet capture, and application logs) discussed in this section to further investigate potential malicious behavior in the network. For example, there may be a baseline level of DNS queries from certain sources and for certain domains\/sites, and a spike or change can indicate potential malicious behavior in the network.<\/p>\n<p>The following chart from\u00a0<a href=\"http:\/\/oss.oetiker.ch\/rrdtool\/\">http:\/\/oss.oetiker.ch\/rrdtool\/<\/a>\u00a0provides a snapshot of the types, and corresponding amounts, of DNS queries. Although the graph itself is dated, it is easy to see the spike in DNS A(lias) queries that took place between 20:00 and 21:00 the previous night. After averaging roughly 133 A queries per second over a period of time (which is undetermined from the graph), the number of A queries per second surged to a peak of 376. This type of anomalous behavior can be quickly identified, and subsequently analyzed, using DNS analytics.<\/p>\n<p><b>Figure 14. DNS Query Snapshot<\/b><\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<p><img decoding=\"async\" src=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/images\/csc_child_pages\/white_papers\/ddos_fig14.jpg\" alt=\"dns query snapshot\" width=\"400\" \/><\/p>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p><a href=\"http:\/\/oss.oetiker.ch\/rrdtool\/\">http:\/\/oss.oetiker.ch\/rrdtool\/<\/a><\/p>\n<p>Other warning signs, as detailed in the following article, include the presence of new domains (<i>young domains<\/i>) being queried, domains that only a handful of employees are referencing (<i>esoteric domains<\/i>), and a large number of failed DNS queries or lookups (<i>lookup failures<\/i>). For more information, see\u00a0<a href=\"http:\/\/www.darkreading.com\/analytics\/security-monitoring\/got-malware-three-signs-revealed-in-dns-traffic\/d\/d-id\/1139680\" target=\"_blank\" rel=\"noopener\">Three Signs of Malware Revealed in DNS Traffic<\/a>.<\/p>\n<p>For additional information about general best practices, network protections, and attack identification techniques that operators and administrators can use for implementations of the DNS protocol, see\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/dns-bcp.html\">DNS Best Practices, Network Protections, and Attack Identification<\/a>.<\/p>\n<p><b>Sinkholes<\/b><\/p>\n<p>Sinkholes are an often-overlooked source of pertinent network traffic details because they are frequently viewed as simply a means of diverting traffic to an unused area of the network. While blackholing traffic is used to deflect undesirable traffic from end user devices and data, sinkholing traffic provides additional advantages. Within the sinkhole network, it is advantageous to include tools and devices that can provide monitoring and added visibility into the traffic that is diverted there.<\/p>\n<p>For additional information about using sinkholes to capture and analyze anomalous or undesirable network traffic, see\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/worm-mitigation-whitepaper.html#tt_sinkholes\">Sinkholes<\/a>\u00a0in\u00a0<i>Worm Mitigation Technical Details<\/i>.<\/p>\n<p><b>Intrusion Prevention\/Detection System Alarms<\/b><\/p>\n<p>Another good source of network IOCs are the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) devices that are deployed at strategic points in the network. IDS shuns sources and performs TCP resets of suspect connections, and IPS helps prevent compromises by dropping traffic inline. Although the focus of IDS and IPS is to detect and prevent bad traffic, it is advisable to use the alarms and log messages from these devices as early warning indicators of anomalous, and potentially malicious, traffic in the network. False positives can be expected when using IPS, so not all IPS-related alarms indicate an attack or even unexpected network activity. Even so, the visibility provided by IPS devices is valuable and should be correlated with the other types of identification information detailed throughout this section.<\/p>\n<p>The following table provides an overview of the Cisco IPS signatures that could trigger events on potential attempts that were associated with the DDoS attacks against financial institutions that took place in September and October 2012.<\/p>\n<\/div>\n<\/div>\n<div class=\"htmlblob section\">\n<table class=\"table-formatted-vborders\" width=\"700\">\n<tbody>\n<tr class=\"primary-header\">\n<th class=\"th-content-left\" valign=\"top\" width=\"25%\"><strong>CVE ID<\/strong><\/th>\n<th class=\"th-content-center\" valign=\"top\" width=\"5%\"><strong>Signature Release<\/strong><\/th>\n<th class=\"th-content-center\" valign=\"top\" width=\"5%\"><strong>Signature ID<\/strong><\/th>\n<th class=\"th-content-center\" valign=\"top\" width=\"30%\"><strong>Signature Name<\/strong><\/th>\n<th class=\"th-content-center\" valign=\"top\" width=\"5%\"><strong>Enabled<\/strong><\/th>\n<th class=\"th-content-center\" valign=\"top\" width=\"5%\"><strong>Severity<\/strong><\/th>\n<th class=\"th-content-center\" valign=\"top\" width=\"5%\"><strong>Fidelity*<\/strong><\/th>\n<th class=\"th-content-center\" valign=\"top\" width=\"20%\"><strong>Notes<\/strong><\/th>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S672<\/td>\n<td>1493\/0<\/td>\n<td>Distributed Denial of Service on Financial Institutions<\/td>\n<td>Yes<\/td>\n<td>High<\/td>\n<td>90<\/td>\n<td valign=\"middle\">\n<div>\n<p>\u2014<\/p>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S593<\/td>\n<td>2152\/0<\/td>\n<td>ICMP Flood<\/td>\n<td>No<\/td>\n<td>Medium<\/td>\n<td>100<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S572<\/td>\n<td>4002\/0<\/td>\n<td>UDP Host Flood<\/td>\n<td>No<\/td>\n<td>Low<\/td>\n<td>75<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S520<\/td>\n<td>4004\/0<\/td>\n<td>DNS Flood Attack<\/td>\n<td>No<\/td>\n<td>Medium<\/td>\n<td>85<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S593<\/td>\n<td>6009\/0<\/td>\n<td>SYN Flood DoS<\/td>\n<td>No<\/td>\n<td>Medium<\/td>\n<td>85<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S573<\/td>\n<td>6901\/0<\/td>\n<td>Net Flood ICMP Reply<\/td>\n<td>No<\/td>\n<td>Informational<\/td>\n<td>100<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S573<\/td>\n<td>6902\/0<\/td>\n<td>Net Flood ICMP Request<\/td>\n<td>No<\/td>\n<td>Informational<\/td>\n<td>100<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S573<\/td>\n<td>6903\/0<\/td>\n<td>Net Flood ICMP Any<\/td>\n<td>No<\/td>\n<td>Informational<\/td>\n<td>100<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S573<\/td>\n<td>6910\/0<\/td>\n<td>Net Flood UDP<\/td>\n<td>No<\/td>\n<td>Informational<\/td>\n<td>100<\/td>\n<td>Retired<\/td>\n<\/tr>\n<tr>\n<td>NA<\/td>\n<td>S573<\/td>\n<td>6920\/0<\/td>\n<td>Net Flood TCP<\/td>\n<td>No<\/td>\n<td>Informational<\/td>\n<td>100<\/td>\n<td>Retired<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<p>* Fidelity is also referred to as Signature Fidelity Rating (SFR) and is the relative measure of the accuracy of the signature (predefined). The value ranges from 0 through 100 and is set by Cisco Systems, Inc.<\/p>\n<p>Administrators could configure Cisco IPS sensors to perform an event action when an attack was detected and one of the signatures in the preceding table was triggered. The configured event action would result in preventive or deterrent controls to help protect against an attack that was attempting to carry out the attacks. As the notes in the table indicate, all but one of the signatures has been retired to increase the performance of Cisco IPS sensors while focusing on more current threats. That being said, if DDoS attacks are a concern for your organization, it is recommended that these signatures be enabled. The event action does not necessarily have to be a preventative measure, such as dropping or resetting an existing connection; the action can be to notify administrators of potential DDoS attack attempts using alarms or log messages.<\/p>\n<p><b>ASA Threat Detection<\/b><\/p>\n<p>Cisco ASA threat detection consists of different levels of statistics gathering for various threats, as well as scanning threat detection, which determines when a host is performing a scan. Administrators can optionally shun any hosts determined to be a scanning threat.<\/p>\n<p>Threat detection statistics can help administrators manage threats to the Cisco ASA; for example, enabling scanning threat detection provides statistics to help analyze the threat. Administrators can configure two types of threat detection statistics:<\/p>\n<p><b>Basic threat detection statistics:<\/b>\u00a0Include information about attack activity for the system as a whole. Basic threat detection statistics are enabled by default and have no performance impact.<\/p>\n<p><b>Advanced threat detection:<\/b>\u00a0Statistics track activity at an object level so the Cisco ASA can report activity for individual hosts, ports, protocols, or access lists. Advanced threat detection statistics can have a major performance impact, depending on the statistics gathered, so only the access list statistics are enabled by default.<\/p>\n<p>Visit\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/docs\/security\/asa\/asa82\/configuration\/guide\/conns_threat.html\">Configuring Threat Detection<\/a>\u00a0for more information about this feature.<\/p>\n<h1>Modern Tendencies in Defending Against DDoS Attacks<\/h1>\n<p><b>Challenges in Defending DDoS Attacks<\/b><\/p>\n<p>The challenge in preventing DDoS attacks lies in the nature of the traffic and the nature of the &#8220;attack&#8221; because most often the traffic is legitimate as defined by protocol. Therefore, there is not a straightforward approach or method to filter or block the offending traffic. Furthermore, the difference between volumetric and application-level attack traffic must also be understood.<\/p>\n<p>Volumetric attacks use an increased attack footprint that seeks to overwhelm the target. This traffic can be application specific, but it is most often simply random traffic sent at a high intensity to over-utilize the target&#8217;s available resources. Volumetric attacks generally use botnets to amplify the attack footprint. Additional examples of volumetric attacks are\u00a0<a href=\"http:\/\/blogs.cisco.com\/security\/real-world-dns-abuse-finding-common-ground\/\" target=\"_blank\" rel=\"noopener\">DNS amplification attacks<\/a>\u00a0and\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/ac123\/ac147\/archived_issues\/ipj_9-4\/syn_flooding_attacks.html\">SYN floods<\/a>.<\/p>\n<p>Application-level attacks exploit specific applications or services on the targeted system. They typically bombard a protocol and port a specific service uses to render the service useless. Most often, these attacks target common services and ports, such as HTTP (TCP port 80) or DNS (TCP\/UDP port 53). For further details about mitigating application-level attacks, see \u00a0<a href=\"http:\/\/tools.cisco.com\/security\/center\/viewAMBAlert.x?alertId=27115\">Identifying and Mitigating the Distributed Denial of Service Attacks Targeting Financial Institutions<\/a>.<\/p>\n<p><b>Stateful Devices<\/b><\/p>\n<p>Stateful devices do not provide complete coverage and mitigation for DDoS attacks because of their ability to monitor connection states and maintain a state table. Maintaining such information is CPU and memory intensive. When bombarded with an influx of traffic, the stateful device spends most, if not all, of its resources tracking states and further connection-oriented details. This effort often causes the stateful device to be the &#8220;choke point&#8221; or succumb to the attack.<\/p>\n<p>For further information about stateful inspection, see the\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/docs\/security\/asa\/asa82\/configuration\/guide\/intro.html#wp1043760\">Stateful Inspection Overview<\/a>\u00a0section of the\u00a0<i>Cisco ASA 5500 Series Configuration Guide<\/i>. Common stateful inspection devices and their role in threat mitigation are firewalls, IDS\/IPS devices, load balancers, and web application firewalls.<\/p>\n<p>Firewalls represent the most common stateful inspection devices in today&#8217;s threat mitigation arsenal. In stateful firewall solutions, there is a component commonly known as the stateful packet inspection (SPI) engine. This is also referred to as DPI (deep packet inspection). This engine provides intelligence by looking into the packet flow to determine and define connection information and application-level details. For more details about firewall stateful inspection, see the\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/prod\/collateral\/vpndevc\/ps5708\/ps5710\/ps1018\/product_implementation_design_guide09186a00800fd670.html#wp9000440\">Cisco IOS Software Stateful Packet Inspection<\/a>\u00a0section of the\u00a0<i>Cisco IOS Firewall Design Guide<\/i>.<\/p>\n<p>IDS\/IPS devices are often deployed at the network core and\/or edge and provide intelligent decision capabilities by using DPI to analyze and mitigate an array of attacks and threats. Moreover, DPI allows the IDS\/IPS device to react to network events and traffic in real time, providing alerts or inline mitigation. For more details about IDS\/IPS stateful inspection, see\u00a0<a href=\"http:\/\/www.cisco.com\/c\/en\/us\/products\/security\/ios-intrusion-prevention-system-ips\/index.html\">Cisco IOS Intrusion Prevention System<\/a>.<\/p>\n<p>Load balancers use SPI to make decisions based on the connections that traverse the load balancer function. For more details about the load balancer stateful inspection engine, see\u00a0<a href=\"http:\/\/www.networkcomputing.com\/networking\/your-load-balancer-firewall\/860567352\" target=\"_blank\" rel=\"noopener\">Is Your Load Balancer A Firewall?<\/a><\/p>\n<p>Web application firewalls use SPI to evaluate web-based application flows, such as GET requests. For details about SPI in web application firewalls, see the\u00a0<a href=\"https:\/\/www.owasp.org\/index.php\/Web_Application_Firewall\" target=\"_blank\" rel=\"noopener\">Web Application Firewall<\/a>\u00a0page documented by the Open Web Application Security Project (OWASP).<\/p>\n<p><b>Route Filtering Techniques<\/b><\/p>\n<p>Remotely triggered black hole (RTBH) filtering can drop undesirable traffic before it enters a protected network. Network black holes are places where traffic is forwarded and dropped. When an attack has been detected, black holing can be used to drop all attack traffic at the network edge based on either destination or source IP address. For further information regarding RTBH filtering, see the\u00a0<a href=\"https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/security\/intelligence\/blackhole.pdf\">Remotely Triggered Black Hole Filtering &#8212; Destination Based and Source Based<\/a>\u00a0(PDF).<\/p>\n<p><b>Note:<\/b>\u00a0RTBH filtering is supported on Cisco IOS, Cisco IOS-XE, and Cisco IOS-XR platforms. For more details, including using RTBH filtering for IPv6, see\u00a0<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/ipv6_rtbh.html\">Remotely Triggered Black Hole Filtering in IP Version 6 for Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software<\/a>.<\/p>\n<p><b>Unicast Reverse Path Forwarding<\/b><\/p>\n<p>Network administrators can use Unicast Reverse Path Forwarding (uRPF) to help limit malicious traffic flows occurring on a network, as is often the case with DDoS attacks. This security feature works by enabling a router to verify the &#8220;reachability&#8221; of the source address in packets being forwarded. This capability can limit the appearance of spoofed addresses on a network. If the source IP address is not valid, the packet is discarded.<\/p>\n<p>uRPF guards against IP spoofing by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table.\u00a0Normally, the security appliance examines only the destination address when determining where to forward the packet. uRPF instructs the security appliance to look also at the source address. For any traffic to be allowed through the security appliance, the security appliance routing table must include a route back to the source address. See\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2267.txt?number=2267\" target=\"_blank\" rel=\"noopener\">RFC 2267<\/a>\u00a0for more information.<\/p>\n<p>To enable uRPF, enter this command: hostname(config)#<b>ip verify reverse-path interface\u00a0<\/b><i>interface_name<\/i><\/p>\n<p>uRPF works in two different modes: strict mode and loose mode. When administrators use uRPF in strict mode, the packet must be received on the interface that the security device would use to forward the return packet. uRPF in strict mode may drop legitimate traffic that is received on an interface that was not the firewall&#8217;s choice for sending return traffic. Dropping this legitimate traffic could occur when asymmetric routing paths exist in the network.<\/p>\n<p>When administrators use uRPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior using the\u00a0<b>allow-default<\/b>\u00a0option, which allows the use of the default route in the source verification process. In addition, a packet that contains a source address for which the return route points to the Null 0 interface will be dropped. An access list may also be specified that permits or denies certain source addresses in uRPF loose mode.<br \/>\nCare must be taken to ensure that the appropriate uRPF mode (loose or strict) is configured during the deployment of this feature because it can drop legitimate traffic. Although asymmetric traffic flows may be a concern when deploying this feature, uRPF loose mode is a scalable option for networks that contain asymmetric routing paths.<\/p>\n<p><b>Geographic Dispersion (Global Resources Anycast)<\/b><\/p>\n<p>A newer solution for mitigating DDoS attacks dilutes attack effects by distributing the footprint of DDoS attacks so that the target(s) are not individually saturated by the volume of attack traffic. This solution uses a routing concept known as Anycast. Anycast is a routing methodology that allows traffic from a source to be routed to various nodes (representing the same destination address) via the nearest hop\/node in a group of potential transit points. This solution effectively provides &#8220;geographic dispersion.&#8221; For details regarding geographic dispersion that uses Anycast to dilute a DDoS attack, see\u00a0<a href=\"http:\/\/arstechnica.com\/security\/2013\/03\/how-whitehats-stopped-the-ddos-attack-that-knocked-spamhaus-offline\/\">How whitehats stopped the DDoS attack that knocked Spamhaus offline<\/a>.<\/p>\n<p><b>Tightening Connection Limits and Timeouts<\/b><\/p>\n<p>Antispoofing measures such as limiting connections and enforcing timeouts in a network environment seek to ensure that DDoS attacks are not launched or spread from inside the network either intentionally or unintentionally. Administrators are advised to leverage these solutions to enable antispoofing and thwart random DDoS attacks on the inside &#8220;zones&#8221; or internal network. To use connection limits and timeouts for DDoS defense purposes, see the\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/docs\/security\/asa\/asa82\/configuration\/guide\/conns_connlimits.html\">Configuring Connection Limits and Timeouts<\/a>\u00a0section of the\u00a0<i>Cisco ASA 5500 Series Configuration Guide<\/i>.<\/p>\n<p><b>Caution:<\/b>\u00a0Oversubscription of stateful processes can cause a device to fail. For more details, see\u00a0<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#37\">Stateful Devices<\/a>.<\/p>\n<p><b>Reputation-Based Blocking<\/b><\/p>\n<p>Reputation-based blocking has become an essential component to today&#8217;s web filtering arsenal. A common trend of malware, botnet activity, and other web-based threats is to provide a URL that users must visit for a compromise to occur. Most often such techniques as spam, viruses, and phishing attacks direct users to the malicious URL.<\/p>\n<p>Reputation-based technology provides URL analysis and establishes a reputation for each URL. Reputation technology has two aspects. The intelligence aspect couples world-wide threat telemetry, intelligence engineers, and analytics\/modeling. The decision aspect focuses on the trustworthiness of a URL. Reputation-based blocking limits the impact of untrustworthy URLs. For details about web reputation technology, see\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/prod\/vpndevc\/ps10142\/ps10164\/web_rep_index.html\">Cisco Web Reputation Technology<\/a>. An example of reputation-based solutions is the\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/products\/ps10164\/index.html\">Cisco Web Security Appliance<\/a>\u00a0and\u00a0<a href=\"http:\/\/www.cisco.com\/en\/US\/products\/ps10154\/index.html\">Cisco Email Security Appliance<\/a>.<\/p>\n<p>Global and crowd-sourced reputation information provides the most coverage in web reputation technology, and administrators may question which reputation engine or service to use and whether one is enough. The recommendation is to use multiple engines or services, such as the following:<\/p>\n<ul>\n<li><a href=\"http:\/\/reputationauthority.org\/\">WatchGuard Reputation Authority<\/a><\/li>\n<li><a href=\"http:\/\/www.webseoanalytics.com\/free\/seo-tools\/bookmarks-finder.php\">WebSEO Analytics<\/a><\/li>\n<\/ul>\n<p>Moreover, web reputation solutions with high coverage include Cisco Web Security Appliance,\u00a0<a href=\"http:\/\/www.imperva.com\/products\/wsc_threatradar-reputation-services.html\">Imperva<\/a>, Trend Micro, and others.<\/p>\n<p>Another evolution is on the horizon for web reputation. Beyond the traditional attack, there is a continuous threat to the brand and business reputation. Many tools and services are available for organizations to protect manage their reputations. See\u00a0<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#48\">References<\/a>\u00a0for more details regarding the available tools.<\/p>\n<p><b>Access Control Lists<\/b><\/p>\n<p>ACLs provide a flexible option to a variety of security threats and exploits, including DDoS. ACLs provide day zero or reactive mitigation for DDoS attacks, as well as a first-level mitigation for application-level attacks. An ACL is an ordered set of rules that filter traffic. Each rule specifies a set of conditions that a packet must satisfy to match the rule. Firewalls, routers, and even switches support ACLs. When the device determines that an ACL applies to a packet, it tests the packet against the conditions of all rules. The first match determines whether the packet is permitted or denied. If there is no match, the switch applies the applicable default rule (generally an implicit &#8220;deny all&#8221;). The device continues processing packets that are permitted and drops packets that are denied.<\/p>\n<p><b>Note:<\/b>\u00a0Switches support port and VLAN ACLs.<\/p>\n<p>ACLs are often used to protect networks and specific hosts from unnecessary or unwanted traffic via protocol\/port filtering, although filtering may also be based on TCP options and flags. For example, ACLs can disallow HTTP traffic from a high-security network to the Internet. You could also use ACLs to allow HTTP traffic only to specific sites, using the IP address of the site to identify it in an IP ACL.<\/p>\n<p>ACL filtering provides flexible mitigation options. The following list provides additional examples of the available filtering options:<\/p>\n<ul>\n<li>\u00a0 \u00a0Layer 4 protocol<\/li>\n<li>\u00a0 \u00a0TCP and UDP ports<\/li>\n<li>\u00a0 \u00a0ICMP types and codes<\/li>\n<li>\u00a0 \u00a0IGMP types<\/li>\n<li>\u00a0 \u00a0Precedence level<\/li>\n<li>\u00a0 \u00a0Differentiated Services Code Point (DSCP) value<\/li>\n<li>\u00a0 \u00a0TCP packets with the ACK, FIN, PSH, RST, SYN, or URG bit set<\/li>\n<li>\u00a0 \u00a0Established TCP connections<\/li>\n<\/ul>\n<p>The following resources provide more details about ACL configuration and management:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.cisco.com\/en\/US\/tech\/tk648\/tk361\/technologies_configuration_example09186a0080100548.shtml\">Configuring Commonly Used IP ACLs<\/a><\/li>\n<li><a href=\"http:\/\/www.cisco.com\/en\/US\/products\/sw\/secursw\/ps1018\/products_tech_note09186a00800a5b9a.shtml\">Configuring IP Access Lists<\/a><\/li>\n<li><a href=\"http:\/\/www.cisco.com\/en\/US\/docs\/switches\/datacenter\/nexus5000\/sw\/configuration\/guide\/cli_rel_4_0_1a\/sec_ipacls.html\">Cisco Nexus 5500 Series NX-OS Software Configuration Guide &#8211; Configuring ACLs<\/a><\/li>\n<\/ul>\n<p><b>DDoS Run Books<\/b><\/p>\n<p>Early in 2013, the concept of DDoS run books gained a bit of prevalence. The premise behind a DDoS run book is simply to provide a &#8220;playbook&#8221; for an organization in the event that a DDoS attack arises. In essence, the run book provides crisis management (better known as an incident response plan) in the event of a DDoS attack. The run book provides details about who owns which aspects of the network environment, which rules or regulations must still be adhered to, and when to activate\/instrument certain process, solutions, and mitigation plans. A\u00a0case study and an example\u00a0template for DDoS run books\u00a0are in\u00a0<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#48\">References<\/a>.<\/p>\n<p><b>Manual Responses to DDoS Attacks<\/b><\/p>\n<p>It is worth nothing that manual responses to DDoS attacks focus on measures and solutions that are based on details administrators discover about the attack. For example, when an attack such as an\u00a0<a href=\"http:\/\/security.stackexchange.com\/questions\/29220\/what-is-http-get-post-flooding-attack\" target=\"_blank\" rel=\"noopener\">HTTP GET\/POST flood<\/a>\u00a0occurs, given the information known, an organization can create an ACL to filtering known bad actors or bad IPs and domains. When an attack such as Slowloris arises, administrators can configure or tune firewalls or load balancers to limit connection attempts, as discussed in\u00a0<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#41\">Tightening Connection Limits and Timeouts<\/a>. Manual responses also include obscuring IP addressing schemes, using Network Address Translation (NAT), and creating custom IPS signatures or application layer inspection policies based on attack traffic, baselines, and industry events.<\/p>\n<p>The response process is often overlooked. As mentioned in\u00a0<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#44\">DDoS Run Books<\/a>, organizations often do not have a process or a plan and thus rely exclusively on manual responses. Proactive solutions and constant monitoring and configuration updates should be the common practice, with manual responses regarded as rare solutions.<\/p>\n<p><b>Traffic Scrubbing and Diversion<\/b><\/p>\n<p>Because of the prevalence of DDoS attacks in recent years, numerous organizations and businesses now provide DDoS protection as a service. While there are various ways to accomplish DDoS protection and attack mitigation, most providers offer an inline solution in which an organization&#8217;s traffic can be sent to or through the service entity. The service then filters out the offending traffic and reinjects the good traffic into the organization. A few of the most prevalent in the industry are in the following list:<\/p>\n<ul>\n<li>Prolexic Technologies: DoS and DDoS Protection<\/li>\n<li>AT&amp;T Internet Protect: Distributed Denial of Service Defense<\/li>\n<li>Verizon: DoS Defense Services<\/li>\n<li>Arbor Networks: Pravail Availability Protection System (APS)<\/li>\n<\/ul>\n<p>At its core, the Prolexic DDoS Solution uses Prolexic&#8217;s PLX routed platform service (the most basic Prolexic DDoS mitigation solution). In general it allows a customer to route traffic to the Prolexic environment where it will be inspected and filtered based on anomalies, known misbehaviors, and provided details. Subsequently the &#8220;clean&#8221; traffic will be routed back into the customer environment. For more details regarding the PLXrouted solution, see the\u00a0<a href=\"http:\/\/www.prolexic.com\/pdf\/PLXrouteddatasheet.pdf\" target=\"_blank\" rel=\"noopener\">PLXrouted datasheet<\/a>\u00a0(PDF). For more details regarding Prolexic solutions, see their\u00a0<a href=\"http:\/\/www.prolexic.com\/services-dos-and-ddos-mitigation.html\" target=\"_blank\" rel=\"noopener\">DDoS mitigation service portal<\/a>.<\/p>\n<p>The AT&amp;T Internet Protect: Distributed Denial of Service Defense solution is for AT&amp;T customers looking for DDoS protection. Because AT&amp;T already runs the network that the customer&#8217;s traffic is traversing, AT&amp;T uses its expertise and intelligent solutions in the backbone to filter any malicious or ill-advised traffic before it enters the customer environment. In addition, the defense solution analyzes netflow. If any flows pose a threat, they are routed to a &#8220;scrubbing environment&#8221; where the traffic is filtered, allowing the remaining &#8220;good&#8221; traffic to continue to the customer environment. For more details about the AT&amp;T Internet Protect &#8211; Distributed Denial of Service Defense solution, see\u00a0<a href=\"http:\/\/www.business.att.com\/content\/productbrochures\/ddos_prodbrief.pdf\" target=\"_blank\" rel=\"noopener\">AT&amp;T Internet Protect &#8211; Distributed Denial of Service Defense Solution Product Brief<\/a>\u00a0(PDF).<\/p>\n<p>The Verizon DoS Defense Service works much like those previously discussed in that it monitors traffic and routes traffic through the Verizon environment to be scrubbed, allowing the good traffic to be routed back to the protected customer environment. For details, including Service Level Agreement (SLA) information, see the\u00a0<a href=\"http:\/\/www.verizonenterprise.com\/terms\/us\/products\/security\/dosdefense\/\" target=\"_blank\" rel=\"noopener\">Verizon DoS Defense page<\/a>.<\/p>\n<p>The Arbor Networks Pravail Availability Protection System (APS) solution is an example of an onsite (on premise) solution. The unit sits inline in a customer environment and has a connection back to the Arbor intelligence backend. This service incorporates intelligence and information learned from the Arbor Security Engineering and Response Team (ASERT). Coupled with techniques such as baselining and anomaly detection, Arbor APS is a prominent DDoS solution. See the\u00a0<a href=\"http:\/\/www.arbornetworks.com\/products\/pravail\/aps\" target=\"_blank\" rel=\"noopener\">Pravail Availability Protection System solution page<\/a>.<\/p>\n<h1>Conclusion<\/h1>\n<p>With the number of DDoS attacks increasing over the past year, it is important that network engineers, designers, and operators build services and monitor networks in the context of defending against DDoS attacks.<\/p>\n<p>This document presented the different attack types, their categories, and the techniques they use. It presented classic and current methodologies in the identification, classification, and mitigation of DDoS attacks. Because networks vary, we do not aim to provide an all-inclusive DDoS mitigation document that applies to every organization, but we have attempted to describe the tools available for dealing with DDoS attacks.<\/p>\n<p>Using the Cisco six-phase DDoS mitigation model is a good start, and may also be continuously revisited when creating a sound DDoS policy. Preparation is a key part of any DDoS strategy. Ensure that the tools to be used for DDoS identification are tested, functioning, and in the proper locations and that networking staff is trained and capable of operating the necessary tools for DDoS identification.<\/p>\n<p>There is nothing worse than having a network impaired or down and not having a good plan to identify and classify the problem. DDoS attacks can be hard to identify. Many network problems have the look and feel of a DDoS at the beginning, but then complete analysis rules out a DDoS attack. Knowing the baseline traffic and network utilization is the key to understanding a suspected DDoS condition.<\/p>\n<p>The techniques in this white paper provide network administrators with information and tools necessary to identify and mitigate DDoS problems.<\/p>\n<h1>References<\/h1>\n<p>Cisco IOS Firewall Design Guide<br \/>\n<a href=\"http:\/\/www.cisco.com\/en\/US\/prod\/collateral\/vpndevc\/ps5708\/ps5710\/ps1018\/product_implementation_design_guide09186a00800fd670.html\">\/\/www.cisco.com\/en\/US\/prod\/collateral\/vpndevc\/ps5708\/ps5710\/ps1018\/product_implementation_design_guide09186a00800fd670.html<\/a><br \/>\nDNS Best Practices, Network Protections, and Attack Identification<br \/>\n<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/dns-bcp.html\">\/\/www.cisco.com\/web\/about\/security\/intelligence\/dns-bcp.html<\/a><br \/>\nDeep Inside a DNS Amplification DDoS Attack<br \/>\n<a href=\"http:\/\/blog.cloudflare.com\/deep-inside-a-dns-amplification-ddos-attack\">http:\/\/blog.cloudflare.com\/deep-inside-a-dns-amplification-ddos-attack<\/a><br \/>\nReal World DNS Abuse: Finding Common Ground<br \/>\n<a href=\"http:\/\/blogs.cisco.com\/security\/real-world-dns-abuse-finding-common-ground\/\" target=\"_blank\" rel=\"noopener\">http:\/\/blogs.cisco.com\/security\/real-world-dns-abuse-finding-common-ground\/<\/a><br \/>\nDefenses Against TCP SYN Flooding Attacks<br \/>\n<a href=\"http:\/\/www.cisco.com\/web\/about\/ac123\/ac147\/archived_issues\/ipj_9-4\/syn_flooding_attacks.html\">\/\/www.cisco.com\/web\/about\/ac123\/ac147\/archived_issues\/ipj_9-4\/syn_flooding_attacks.html<\/a><br \/>\nHow whitehats stopped the DDoS attack that knocked spamhaus offline<br \/>\n<a href=\"http:\/\/arstechnica.com\/security\/2013\/03\/how-whitehats-stopped-the-ddos-attack-that-knocked-spamhaus-offline\/\">http:\/\/arstechnica.com\/security\/2013\/03\/how-whitehats-stopped-the-ddos-attack-that-knocked-spamhaus-offline\/<\/a><br \/>\nIdentifying and Mitigating the Distributed Denial of Service Attacks Targeting Financial Institutions<br \/>\n<a href=\"http:\/\/tools.cisco.com\/security\/center\/viewAMBAlert.x?alertId=27115\">http:\/\/tools.cisco.com\/security\/center\/viewAMBAlert.x?alertId=27115<\/a><br \/>\nRemotely Triggered Black Hole Filtering in IP Version 6 for Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software<br \/>\n<a href=\"http:\/\/www.cisco.com\/web\/about\/security\/intelligence\/ipv6_rtbh.html\">\/\/www.cisco.com\/web\/about\/security\/intelligence\/ipv6_rtbh.html<\/a><\/p>\n<h2>NetFlow<\/h2>\n<p>How Cisco IT Uses NetFlow to Capture Network Behavior, Security, and Capacity Data<br \/>\n<a href=\"http:\/\/www.cisco.com\/web\/about\/ciscoitatwork\/network_systems\/network_data_monitoring_and_reporting_web.html\">\/\/www.cisco.com\/web\/about\/ciscoitatwork\/network_systems\/network_data_monitoring_and_reporting_web.html<br \/>\n<\/a>Cisco IOS NetFlow<br \/>\n<a href=\"http:\/\/www.cisco.com\/c\/en\/us\/products\/ios-nx-os-software\/ios-netflow\/index.html\">http:\/\/www.cisco.com\/c\/en\/us\/products\/ios-nx-os-software\/ios-netflow\/index.html<br \/>\n<\/a>NetFlow collectors help with collection, analysis, and display of NetFlow data exported from network devices:<\/p>\n<ul>\n<li>NFDUMP<br \/>\n<a href=\"http:\/\/nfdump.sourceforge.net\/\">http:\/\/nfdump.sourceforge.net\/<\/a><\/li>\n<li>NfSen is a graphical web-based front end for the\u00a0<i>nfdump<\/i>\u00a0tools:<br \/>\n<a href=\"http:\/\/nfsen.sourceforge.net\/\">http:\/\/nfsen.sourceforge.net\/<\/a><\/li>\n<\/ul>\n<h2>Reputation Management Tools<\/h2>\n<p><a href=\"http:\/\/searchengineland.com\/5-free-deep-reputation-management-checking-tools-163551\">http:\/\/searchengineland.com\/5-free-deep-reputation-management-checking-tools-163551<\/a><br \/>\n<a href=\"https:\/\/www.openforum.com\/articles\/online-reputation-management-tools\/\">https:\/\/www.openforum.com\/articles\/online-reputation-management-tools\/<\/a><br \/>\n<a href=\"http:\/\/socialmouths.com\/blog\/2013\/04\/25\/manage-your-online-reputation\/\">http:\/\/socialmouths.com\/blog\/2013\/04\/25\/manage-your-online-reputation\/<\/a><\/p>\n<h2>DDoS Run Book Case Study and Template<\/h2>\n<p><a href=\"https:\/\/www.sans.org\/reading-room\/whitepapers\/incident\/practical-social-media-incident-runbook-34252\">https:\/\/www.sans.org\/reading-room\/whitepapers\/incident\/practical-social-media-incident-runbook-34252<\/a>\u00a0(PDF)<br \/>\n<a href=\"https:\/\/www.whitehatsec.com\/blog\/checklist-to-prepare-yourself-in-advance-of-a-ddos-attack\/\">https:\/\/www.whitehatsec.com\/blog\/checklist-to-prepare-yourself-in-advance-of-a-ddos-attack\/<\/a><\/p>\n<\/div>\n<\/div>\n<div class=\"text parbase section\">\n<div class=\"clb c100-dm c100v1-dm no-border no-padding\">\n<hr \/>\n<p>This document is part of the\u00a0<a href=\"https:\/\/tools.cisco.com\/security\/center\/home.x\">Cisco Security portal<\/a>.<\/p>\n<p>This document is provided on an &#8220;as is&#8221; basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.<\/p>\n<p><a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html#\">Back to Top<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<div class=\"clear-all\">&#8212;<\/div>\n<div>Details:\u00a0<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html\">https:\/\/www.cisco.com\/c\/en\/us\/about\/security-center\/guide-ddos-defense.html<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"<p>Contents Introduction: The Case for Securing Availability and the DDoS Threat Categorization of DDoS Attacks and Problems Caused DDoS Attack [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[29,30,31,25,16,19,6],"tags":[],"class_list":["post-1315","post","type-post","status-publish","format-standard","hentry","category-ccie-rs","category-ccna","category-ccnp-route","category-cisco","category-courses","category-issues","category-networking"],"_links":{"self":[{"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=\/wp\/v2\/posts\/1315","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1315"}],"version-history":[{"count":0,"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=\/wp\/v2\/posts\/1315\/revisions"}],"wp:attachment":[{"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kb.lagonet.vn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}