Can service providers prevent DDoS attacks?

Ask the Expert

Can service providers prevent DDoS attacks?

Why is it that DDoS assaults have been a popular attack method for such a long time? Is it time for service providers to implement more proactive defenses?

Continue Reading This Article

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

Distributed denial-of-service (DDoS) attacks have been popular for a simple reason: they work. The results of a DDoS attack can be crippling. An attacker can use a DDoS attack to shut down a business, for example, or prevent a political adversary from sharing opinions. Before the rise of DDoS attacks in 1999, attackers usually launched denial-of-service attacks from a handful of networked machines. When tools like Trinoo and Tribe Flood Network 2000 were widely released, launching a flood from thousands of machines became quite easy. Today, most DDoS attacks are launched from botnets, which are comprised of tens of thousands of machines or more. Some current reports claim there are a few botnets boasting more than a million infected machines.

During the past few years, service providers have been implementing more proactive defenses, using automated sensors and blocking technology to look for unusual traffic patterns that are often associated with a DDoS attack. Mechanisms, implemented in tools like Arbor Networks Inc.'s Peakflow, Cisco Systems Inc.'s Guard DDoS mitigation appliances and Mazu Networks Inc.'s Enforcer, look for the tell-tale sign of a SYN flood.

Before discussing SYN flood detection mechanisms, it'll be useful to review the process of a Transmission Control Protocol (TCP) connection. When a client attempts to connect with a server, the server must first perform a passive open, where it first binds to a port and initiates it for connections. Then a client may open and establish a connection. TCP, however, requires what is often referred to as a three-way handshake:

  • 1) A SYN request, or synchronization packet, is sent to the server.
  • 2) In response, the server replies with an acknowledgement and synchronization: SYN-ACK.
  • 3) Finally the client sends an acknowledgement, or ACK, back to the server: SYN-ACK-ACK

    The client and server have then received an acknowledgement of the connection.

    With a SYN flood, the attacker launches a barrage of session initiation packets, specifically TCP SYN packets, but never completes the connection. Detection tools sense the SYN from the attacking bots, the SYN-ACK from the victim, but the final leg of the three-way handshake never occurs, a distinct pattern that indicates a likely flood. Some ISPs will block packets once they detect such a pattern.

    In an attempt to dodge ISP pattern-recognition filters, some attackers are moving from SYN floods to HTTP floods. HTTP floods, unlike SYN floods, actually complete the three-way handshake. With an HTTP flood, the attacking machine sends a SYN, and the victim responds with a SYN-ACK. The attacker completes the three-way handshake with an ACK and then issues an HTTP GET request for a common page on the target (such as index.html). An HTTP flood resembles the patterns of normal Web surfing, making it harder for automated tools to differentiate. As usual for the information security space, the ISPs have raised the bar in proactive DDoS defenses, while the attackers are working hard to jump over it.

    More information:

  • Are IPSes the best way to counter botnet attacks? Ed Skoudis explains.
  • Learn how to block and reroute a DDoS attack.
  • This was first published in April 2007