Mitigation Guidelines for Denial-of-Service Attacks

Number: TR12-001
Date: 22 February 2012

Audience

This Information Report is intended for IT professionals and managers within federal, provincial/territorial and municipal governments; critical infrastructure; and other related industries. The recipients of this product may further distribute it to technical stakeholders within their organization.

Purpose

The purpose of this Information Report is to provide IT security personnel with an introduction to distributed denial-of-service (DDoS) attacks, their modus-operandi and the recommended steps to help with the preparation, identification, containment, recovery and continuous improvement efforts required to limit associated organizational risk. This document may be used by system administrators, computer security incident response teams (CSIRTS), IT security operations centres and other related technology groups.

Introduction

Denial of service (DoS) attacks are common malicious network actions aimed at disrupting the availability of computing resources from legitimate users. These types of attacks, especially DDoS attacks have recently gained in popularity due to the availability of DoS rental services from botnet operators, as well as the availability of various free and easy to use hacking tools. The latter have enabled activists using hacking to support their causes (also known as hacktivists) to efficiently recruit large numbers of followers to perpetrate cyber attacks, increasing both their distribution and power. Well known examples of DoS attacks include the use of the Low Orbit Ion Cannon DDoS tool in support of WikileaksFootnote 1 used by hacking group “Anonymous” and attacks against national infrastructures such as KoreaFootnote 2 , GeorgiaFootnote 3 and EstoniaFootnote 4.

DoS and DDoS definition

A DoS attack is an attempt to make a computer resource unavailable to its intended users Footnote 5. A DDoS attack occurs when multiple systems simultaneously flood networked computer resources, rendering them inaccessible. A DDoS attack, in contrast with a DoS attack, comes from many sources, often hundreds or even thousands. As a result, mitigation actions against a DDoS attack are more difficult to coordinate and associated traffic is more damaging to the target.

DDoS attacks often use stateless protocols such as UDP and ICMP, but stateful protocols can also be used when the connections are not fully established such as during a TCP SYN flood attack. Both techniques make it easier for the attacker to use spoofed IP addresses and harder to determine the source of the attack.

Five Steps To Defend Against DDOS Attacks

Preparation

Preparation is the most important step in defending against a DDoS attack. Clear and complete procedures and guidelines should be established well before an attack takes place. Any organization can fall victim to DDoS attacks, either directly or indirectly. Having a solid plan in place will help reduce the risk and lessen the impact should an attack occur.

Identification

Indicators that your organization may be under a DDoS attack could include poor network performance, inaccessible services or system crashes. Being able to identify and understand the nature of the attack and its targets will help in the containment and recovery process. For this purpose, organizations require tools that provide visibility over their managed information technology (IT) infrastructure. Often, prior to a DDoS attack, a reconnaissance of the target is performed by the attacker. This may include scanning the target network for known exposed vulnerabilities or sending malformed packets to the target host to analyze changes in response time. This reconnaissance activity may be hard to detect, especially because it may take place well before the attack itself. A knowledgeable attacker will also ensure scan traffic does not meet the threshold required to trigger alarms from network monitoring tools. However, there may be available intelligence indicating an increased likelihood of a DDoS attack against an organization. Good examples are the Anonymous Operations (aka “anonops”)Footnote 6 , which broadly advertise their motivation and targets.

Containment

Having a pre-determined containment plan before an attack for a number of scenarios will significantly improve response speed and limit damages resulting from a DDoS attack. For example, the containment strategy for a mail server may differ from one for a web server. Underestimating the importance of this phase can result in mistakes and significant collateral damages. Therefore, understanding the nature of DDoS attacks and documenting the associated decision-making process is critical. An organization should clearly identify its network perimeter and exposed assets. Load balancers, modern firewall technologies (Deep Packet Inspection, proxy, application layer filtering), content caching, content hosting geographic diversity, dynamic DNS service and ISP-based DDoS protection services are some of the tools an organization may leverage to contain an ongoing DDoS attack.

Recovery

Depending on the containment strategy employed and the sensitivity to its collateral impact, an organization may be under different pressure to recover from a DDoS attack. Understanding the characteristics of the attack is required for an appropriate recovery. DDoS may exploit limits in the following resources:

A DDoS attack may exploit any or a combination of these limitations. An organization equipped with a flexible provisioning model for these resources may be able to rapidly adapt and sustain long-term DDoS attacks. However, some attacks may leverage vulnerabilities in protocols or software and achieve unexpected high impact as a result.Footnote 7 An organization equipped with packet capture capability may be able to identify the delivery method of the attack and potentially design an accurate Intrusion Prevention System / Firewall signature. Despite mitigation efforts, some DDoS attacks may be persistent over time. An organization using connection logs and other tools may be able to provide a list of potentially offending IP addresses (if not spoofed) to their upstream ISP, law enforcement and national Computer Emergency Response Team (CERT) to coordinate mitigation/investigation of the offending sources.

Lessons Learned

Lessons learned is a very important step that is often overlooked. Lessons learned activities should take place as soon as possible following an incident. All decisions and steps taken throughout the incident handling cycle should be reviewed. All procedures should be reviewed to see where improvements may be made.

Perhaps the most challenging part of performing a Lessons Learned review involves documenting the impact and cost the incident caused to the organization. Although time consuming, this step is essential to allow organizations to properly justify security resources and assess their return on investment. Damages to an organization include tangible metrics, such as loss in sales and productivity, as well as intangible metrics, such as reputation and brand.

By performing this review after each incident, organizations will enable continuous improvement and potentially significant reduction in the impact of incidents.

Checklist

The following checklist is intended to help organizations during the various mitigation phases of DDoS attacks. Many of these mitigations are applicable to other types of cyber attacks as well and should be considered accordingly.

Checklist for mitigation phases of DDoS attacks
# Item In progress Completed
Preparation
1. Identify your most critical assets and the services they provide.
  • Are they up to date with the latest patches?
  • Do they run any unnecessary services such as Telnet or FTP?
   
2. Establish procedures with your Internet Service Provider (ISP) to determine how they can assist your organization during a DDoS attack. Knowledge of any Service Level Agreement (SLA) that exists and what costs may be incurred.    
3. Establish 24/7 contact information for your ISP and alternate methods for communications.    
4. Deny all obviously spoofed traffic (e.g., internal IP addresses that should not be coming in or going out of your network). Implement a bogon block list (unallocated address space) at the network boundary.    
5. Establish procedures on how to segregate your networks in the event of a DDoS attack. Use existing network devices, such as routers and managed switches, to defend against DDoS attacks. Employ service screening on edge routers wherever possible in order to decrease the load on stateful security devices such as firewalls.    
6. Disable all unnecessary services and restrict access to and from all previously identified critical hosts based on DDoS traffic characteristics.    
7. Create a whitelist of the source IPs you must allow if you need to prioritize traffic during an attack.    
8. Document your network topology including all IP addresses. Keep it up to date.    
9. Review your Business Continuity Plan (BCP) and ensure senior management and legal team understand the significance of a DDoS attack, including their roles.    
10. Understand “normal.” Establish a baseline of network traffic, CPU usage, connection and memory utilization of critical hosts under normal conditions so that network monitoring tools will trigger on abnormal changes.    
11. Acknowledge that your organization may be attacked. Organizations should consider the development and implementation of policies, plans and procedures to defend against DDoS attacks. Identify and planfor resources to implement these plans.    
12. Assign roles and responsibilities. Identify who plays a role in defending against a DDoS attack and ensure they are aware of this responsibility. This should include personnel from critical business functions, IT operations, network and IT security teams, legal advisors, and media relations staff. Ensure an up-to-date point-of-contact list with primary and alternate personnel is maintained. As the network may be unavailable, including mobile devices, ensure alternate communications mechanisms are in place.    
13. Conduct exercises. The worst time to test plans and procedures is during an attack.    
Identification
1. Determine if you are the primary target or a collateral victim. (ex: is your upstream internet provider or content hosting provider the target ?)    
2. Understand the logical flow of the attack.    
3. Determine what type of traffic is being used, such as IP addresses, ports and protocols.    
4. Consider using network analysis tools to determine the type of traffic being used in the attack (e.g., TcpDump, Wireshark, Snort).    
5. Review any available logs to understand the attack and what is being targeted.    
6. Notify appropriate personnel. This may include senior management and the legal team.    
Containment
1. Contact your ISP to implement filtering.    
2. Block the traffic as close to the network cloud as possible (router, firewall, load balancer, etc.).    
3. Relocate the target to another IP address if a particular host is being targeted. This is a temporary solution.    
4. If a particular application is being targeted, consider disabling it temporarily.    
5. Identify and correct the vulnerability or weakness that is being exploited. An example of this may be an unused service that is accidently left enabled on a public facing device or unpatched operating system.    
6. Implement filtering based on the characteristics of the attack. An example may be blocking IMCP echo packets.    
7. Implement rate limiting for certain protocols, allowing a certain number of packets per second for a specific protocol or to access a certain host.    
Recovery
1. Confirm that the DDoS attack has finished and services are reachable again.    
2. Confirm that your networks are back to your baseline performance.    
3. If necessary, patch and update all affected machines.    
4. If possible, identify the source of the attack. Enlist the help of your ISP.    
5. Review logs for signs of reconnaissance. Maintain logs for possible future law enforcement requirements.    
Lessons Learned
1. Create or update the following documents:
  • Standard Operating Procedures
  • Emergency Operating Procedures
  • Business Continuity Plans
   

Recommendations

CCIRC recommends that organizations assess their risk exposure to Denial of Service attacks which may be caused accidentally or intentionally and consider mitigation advice herein provided and implement them as appropriate for the specific IM/IT environment.

References

  1. US-CERT, Understanding Denial-of-Service Attacks
    http://www.us-cert.gov/cas/tips/ST04-015.html
  2. NIST, Computer Security Incident Handling Guide
    http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf
  3. GovCERT.NL, Factsheet: Protect your online services against dDoS attacks
    http://www.govcert.nl/english/service-provision/knowledge-and-publications/factsheets/protect-your-online-services-against-ddos-attacks.html
  4. Societe Generale DDoS Incident Reponse
    http://cert.societegenerale.com/resources/files/IRM-4-DDoS.pdf

Reporting

Any Canadian Critical Infrastructure Operator wishing to report incidents may do so using the CCIRC Cyber Duty Officer PGP encryption key, found at:
http://www.publicsafety.gc.ca/cnt/ntnl-scrt/cbr-scrt/rprt-eng.aspx

Associated reports should be sent to:
cyber-incident@ps-sp.gc.ca.

Critical Note

Some of the information contained in this message is provided strictly for the purpose of defensive reconfiguration of assets owned by the recipient. The recipient is advised not to engage into any form of information collection activities outside its own network perimeter using the information within this product. Such actions include probing, downloading, browsing or crawling sites contained within this report.

NOTICE: This message and accompanying attachments contain information that is intended only for the use of the individual or entity to whom it is addressed. Any dissemination, distribution or copying of the contents of this communication by anyone other than the intended recipient is strictly prohibited without the consent of the originator. If you have received this communication in error, please notify the sender immediately at the above address and delete the e-mail.

This message and accompanying attachments contains information which may have been collected from external sources for which CCIRC cannot verify the accuracy and integrity. CCIRC does not accept liability for negative consequences resulting from the use of the information herein provided.

Links to websites not under the control of the Government of Canada are provided solely for the convenience of users. The government is not responsible for the accuracy, currency or the reliability of the content. The government does not offer any guarantee in that regard and is not responsible for the information found through these links, nor does it endorse the sites and their content.


Note to Readers

In support of Public Safety's mission to build a safe and resilient Canada, CCIRC's mandate is to help ensure the security and resilience of the vital non-federal government cyber systems that underpin Canada's national security, public safety and economic prosperity. As Canada's computer security incident response team, CCIRC is Canada's national coordination centre for the prevention and mitigation of, preparedness for, response to, and recovery from cyber incidents on non-federal government systems. It does this by providing authoritative advice and support, and coordinating information sharing and incident response.

Please note, CCIRC PGP key has recently been updated.
http://www.publicsafety.gc.ca/cnt/ntnl-scrt/cbr-scrt/_fl/CCIRCPublicPGPKey.txt

For general information, please contact Public Safety Canada's Public Affairs division at:

Telephone: 613-944-4875 or 1-800-830-3118
Fax: 613-998-9589
E-mail: ps.communications-communications.sp@canada.ca

Footnotes

  1. 1

    Introduction to LOIC: http://en.wikipedia.org/wiki/LOIC

  2. 2

    http://blogs.mcafee.com/mcafee-labs/malware-in-recent-korean-ddos-attacks-destroys-systems

  3. 3

    http://asert.arbornetworks.com/2008/08/georgia-ddos-attacks-a-quick-summary-of-observations/

  4. 4

    http://en.wikipedia.org/wiki/2007_cyberattacks_on_Estonia

  5. 5

    Definition: http://en.wikipedia.org/wiki/Denial-of-service_attack

  6. 6

    http://anonops.blogspot.com/2011/09/tar-sands-action-september-3-press_04.html

  7. 7

    http://www.theregister.co.uk/2011/08/24/devastating_apache_vuln/

Date modified: