To be on the receiving end of a distributed denial of service (DDoS) attack is a nightmare scenario for any network administrator, security specialist or access provider. It begins instantly, without warning, and continues relentlessly: machines down, jammed bandwidth, overloaded routers. . . .
To be on the receiving end of a distributed denial of service (DDoS) attack is a nightmare scenario for any network administrator, security specialist or access provider. It begins instantly, without warning, and continues relentlessly: machines down, jammed bandwidth, overloaded routers. An effective, immediate response is often difficult and may depend on third parties, such as ISPs. With these challenges in mind, this article will explore some techniques that systems administrators and security professionals can employ should they ever find themselves in this rather undesirable situation.

It's easy to recognize a DDoS attack: slow networks and servers crashing catch the eye of every administrator (or their users!). The first step in our defense is to identify and qualify what type of traffic is bombarding the network. Most DDoS attacks send a very specific type of traffic over and over: ICMP, UDP, TCP - albeit with forged source addresses. But an unusually large quantity of a certain packet type should be an accurate starting point for characterizing the attack and useful information for crafting filters in the future. The exception to this rule, to be addressed later, would be DDoS attacks directed at specific services, such as HTTP, using valid traffic and requests.

To identify and inspect the packets, we need to analyze the network traffic. This can be accomplished using two different methods depending on where the traffic is being examined. The first method can be used on a machine located on the target network. tcpdump is a widely available sniffer that works well for our purposes. Analyzing the output in real-time is impossible on a busy network, so the first step is to use the "-w" option to write the data to a file. Next, use a tool such as David Dittrich's modified version of tcpdstat or tcptrace to summarize the findings.

The link for this article located at SecurityFocus is no longer available.