Proposal for a new method to block

distributed denial-of-service (DOS) attacks.

 

 

John L. Sokol

7/2001

 

 

Nature of the problem.

Distributed denial-of-service (DOS) attacks crippled the Internet in February 2000 according to the "FBI investigations and other information," the National Infrastructure Protection Center (NIPC).

Over the past few years these attacks have been getting more frequent and persistent with no technical fixes known at this time.

Hackers have been hijacking innocent third parties computers using a variety of virus, worms and Trojans such as Trin00, Tribal Flood Net, TFN2K, MStream, Stacheldraht network.vbs and Trinity v3.  These programs can turn a desktop system into a “zombie” computer.  These zombie systems behave normally but monitor an IRC (Internet Relay Chat) channel, website or listen for a command packet waiting for it’s hacker to point to a victim.   These systems, tens of thousands of them, under the remote control by the hacker can then launch massive denial-of-service attacks.

These attacks can be any kind of attack from syn and smurf, using illegitimate raw-packet attacks to confuse a servers TCP/IP stack, but these can be filtered.

Even more dangerous are the new attacks that flood millions of legitimate http requests or transmit 100 MBps of UDP packets down a customers T3 line. These packets appear legitimate in all aspects, but their quantity make filtering or manually blocking them at the victim’s ISP useless. Even without spoofing addresses there are thousand of addresses that the upstream backbone providers would need to block. Even more difficult is these attacks are now against incoming routers. This fills the incoming Internet connection but packets never leave router making impossible to use an analysis tool (like tcpdump) to examine the offending packets.

Tracking these packets back to their source has not helped because most of the time it some broadband DSL or cable modem customer that it not very knowledgeable about computers and was totally unaware that there computer was taking place in an attack. For every end user who system is cleaned of the hacking software there are another 10 getting infected.

Soon with Windows XP making spoofed packet easier then ever tracking these packets back to their origins will be next to impossible with the current infrastructure.

Current solutions.

Cures such as Firewalls, and anti-virus software are effective when used correctly but this is often not the case as demonstrated by the large numbers of these attacks currently taking place. Something more is needed.

ISP and Broadband providers need to implement source address filtering; blocking an end used system from spoofing or lying about its IP address.

 

Proposal for a new protocol.

A new protocol needs to be implemented on the ingress routers and bridges where end users connect to the Internet. This is in these DSL Modems, Cable Modems or routers just above, or in the terminal server themselves.

This protocol should also be implemented in the core or ingress/egress routers of the backbone but it may not be viable due to performance issues.

The Basic idea is to use the IP ROUTER ALERT Option RFC2113 in the IP header to send a message to all router along a path.  Like RSVP, but instead of establishing a QOS reservation allowing packets a higher priority through the network, this would do the reverse. This would notify routers along the path to temporarily block packets toward the victim ISP’s address block.

There would need to be 3 basic parts and strong precautions to prevent malicious uses of this service that would be just as bad at the DOS this is intended to remedy.

Router Alert is to send a single datagram packet, hop-by-hop towards the destination address; Routers that don’t know about the protocol just ignore it and pass it forward.  Routers that are aware of the protocol can receive and block the packet, then resend an altered form towards the destination or it or send message back to the source. And also take an action based on that packet.

Part 1, Send a Router Alert packet, message back to the source address of the offending packet. Routers in the middle can then block these packets along the path. Each router accepting the packet block can send a Router Alert encoded message back eliminating the blocks from the router closer to the victim possible there by reducing the number of block addresses in core routers. This last part has security issues since we don’t want the attacking servers to be able to un-block it’s own attack.

Part 2, In the case of spoofed source addresses, Like 127.0.0.1 a packet is send just 1 hop up to begin to trace the origins back to their true source.  This is done by asking the intermediate routers to record the router the packet arrived from (from Arp or the inbound interface, or tunneling protocol). The recorded information can then be place in the header like the record route option on a ping packet (RFC 791).  This can then allow the victim system to trace the packet 1 hop farther back with each bogus packet.

Upon reaching the end of cooperative routers the blocking packet can then be sent. Those backbones not responding to these traces will be eating the cost for this extra bandwidth but the victim connection will not be.  So it would be in the best interest for a backbone to offer this servers to it’s customers and support the protocol all the way to the peering points because it reduced their traffic.

 

Part 3, The routers should open a TCP connection or some verified UDP to verify the source address of the victims system is the one really requesting the blocking of packets.  It’s very important that not just anyone can block packets going to a specific ISP or Host.  This could also be optional for running a trace where only the destination address of the packets could receive the trace origin of packets coming to it.