Despite advances in Internet security technology, high-profile denial-of-service (DoS) attacks continue to disrupt the operations of many organizations. Few are prepared to
For any incident response scenario, including DoS attacks, preparation is the key to mitigating the issue quickly.
In this tip, we will analyze the breadth and depth of the DoS threat by referencing recent DoS attacks, and how to prepare for a DoS attack both from a technical standpoint as well as key business and communication strategies that can help deal with the situation faster and for less money.
The breadth and depth of the DoS threat
However, DoS attacks are still most effective when they have many attacking nodes, or in other words, a botnet, for a DDoS attack. This is because it is difficult to block a large number of sources and the bandwidth required for an individual system is low, so even systems with slow Internet connections can be used.
DoS attack response preparation: Business planning
The business aspects of DoS attack preparation should include communication, business continuity planning and engagement with the ISP. If an enterprise’s Web presence is hosted by an external hosting provider, it must ensure the provider has the capability, tools and procedures to respond to DoS attacks in a timely fashion. Regardless of the individual tools used, the provider needs to know how to effectively use the tools and develop effective procedures. Some of the short-term steps to minimize the impact of a DoS attack could have negative long-term effects on complexity if not removed after the DoS attack.
An enterprise should also include a DoS attack response service in its contract with a provider, and potentially even flesh out the details of what that response should include in a service-level agreement (SLA). For instance, it's wise to make sure the SLA mandates that response time is documented, since a faster response time potentially results in less downtime for an enterprise’s Web presence.
Listen to this tip
as an mp3
Listen to DoS attack responses demand better business continuity plans as an MP3 here!
When negotiating a contract, the fees and any extra usage charges can potentially be pre-negotiated too; doing this in advance prevents the provider from charging exorbitant fees for additional services during an incident. Having an SLA also ensures the ISP or hosting provider meets the availability requirements, such as 99.9% uptime of the enterprise’s Web presence, at the price agreed.
Also, in planning for the response to a DoS attack, an enterprise’s computer security incident response team (CSIRT) should establish methods of communication with the business, including key decision makers in business operations, to ensure key stakeholders are notified and consulted during an incident. Key decision makers should be identified and given the ability to disconnect the Internet connection in a worst-case scenario or to just disconnect parts of the Internet. Disabling the Internet connection might require an executive to sign off on the decision, but the decision to block an individual network could be made by CSIRT consensus. Lines of communication should also be opened with the relevant internal groups, including Marketing or Public Relations, so those groups can potentially communicate with the media concerning the DoS attack. Setting up these communication channels can also help identify the key decision makers, such as the figure that can authorize the purchase of a new DoS protection network appliance to minimize the impact of the attack if necessary.
DoS attack response preparation: Technical response
For any incident response scenario, including DoS attacks, preparation is the key to mitigating the issue quickly. The preparation depends on the type of attack and how the Internet presence is hosted. The technical preparation can be divided into network and Web infrastructure parts, including identification, response and monitoring. Identifying a DoS attack can range from the simple, such as receiving a notification from a customer that they couldn’t use your website, to the more complex, such as receiving a notification from a bandwidth-monitoring tool that reports over-utilization of your WAN link.
More hacker threats
Learn about the current threat levels presented by botnets.
Defend a proxy server against attacks.
Once notified of the potential incident, investigate the infrastructure under attack to determine the most effective response. Identify the specific server or applications under attack by looking at IDS, flow data, server logs, application logs, or other network data, and looking for high-usage patterns. If a Web application is under attack, a response could be moving the Web presence to a different hosting provider, server or network, or implementing a DoS protection tool to ensure continuity of operations. The server or service can even be moved to a cloud provider or a content distribution network. Monitoring can be used to determine if the attack has stopped, changed or if additional action is necessary. The monitoring could just utilize detection tools and setting alerts when a threshold is met, such as 80% link utilization or a large number of UDP connections. You could also contact the source ISPs to ask them to block their customers from participating in the DDoS attack or to block the sources. It is possible to block the sources yourself, but blocking a large number of attacking computers may be difficult. Once the DoS attack has abated, either the blocks need to be removed or the Web presence must be moved back to the original hosting location. Evaluate if any of the protections put in place or long-term changes made should remain intact.
DoS attacks can cripple a business, but with preparation, the business disruption can be minimized. The evolution of DoS attacks has made them more difficult to stop and to track all of the sources, but new methods have been developed to minimize the impact. While it might not be possible to stop the attack, it is possible to continue to run your business with preparation, but that preparation must include not only internal technical measures, but also detailed communication and planning with external providers, backup up by a detailed SLA that will prevent unwanted surprise delays and fees when an incident occurs.
About the author:
Nick Lewis (CISSP) is an information security architect at Saint Louis University. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and previous at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.
This was first published in April 2012