Unless you lived under a rock for the past week you've heard of the distributed denial of service attacks (DDOS) against some of the top Internet web sites. In particular these attacks were of the bandwidth consumption type. Some of the network providers involved claim to have been upwards of 1 Gb/s traffic. These attacks are not knew. David Dittrich has performed an excellent job dissecting these attacks and the tools that enable them. You can find David's analysis of these tools at: * Trinoo http://staff.washington.edu/dittrich/misc/trinoo.analysis * Tribe Flood Network http://staff.washington.edu/dittrich/misc/tfn.analysis * Stacheldraht http://staff.washington.edu/dittrich/misc/stacheldraht.analysis A number of meetings have been held to discuss the attacks and search for possible solutions. These include CERT Distributed-Systems Intruder Tools Workshop back in November and the two recent Birds of Feather (BOF) sessions organized by the ICSA at the RSA and NANOG conferences. You can find David's notes on the CERT workshop at: http://staff.washington.edu/dittrich/talks/cert/ You can find the results of the CERT workshop at: http://www.cert.org/reports/dsit_workshop.pdf CERT has also issued an advisory last month on the problem: http://www.cert.org/advisories/CA-2000-01.html These attack are made possible because of fundamental design decisions at the IP protocol level. It does not provide strong authentication of the source of a packet, and it only provides a best effort service with no resource allocation protocol. To date no one has come up with a "silver bullet" solution to the problem. That being said, the are a number of options to mitigate it. I'll present a few and would like to hear what other suggestions you may have. Network Ingress Filtering: -------------------------- All network access providers should implement network ingress filtering to stop any of their downstream networks from injecting packets with faked or "spoofed" addressed into the Internet. Although this does not stop an attack from occurring it does make it much easier to track down the source of the attack and terminate it quickly. For information on network ingress filtering read RFC 2267: http://info.internet.isi.edu/in-notes/rfc/files/rfc2267.txt Rate Limit Some Network Traffic: -------------------------------- A number of routers in the market today have features that allow you you limit the amount of bandwidth some type of traffic can consume. This is sometimes referred to as "traffic shaping". In Cisco IOS software this feature is called Committed Access Rate (CAR). CAR allows you to enforce a bandwidth policy against network traffic that matches an access list. This can be used in a proactive way if you know most of your network traffic will be of some particular type. For example if you are running a web farm you can configure the system such as any web traffic gets as much bandwidth as it requires while limiting all other traffic to smaller manageable rate. It can also be used in a reactive way if you can craft an access rule that will match some of the network traffic using by the DDOS attack. For example if the attack is employing ICMP packets or TCP SYN packets you could configure the system to specificly limit the bandwidth those types of packets will be allowed to consume. This will allow some of these packets which may belong to legitimate network flows to go through. Because of the avalanche effect of the DDOS attacks for this option to be effective it must be deployed as depth into the network as possible (closer to the source of the attack packets). You may need to ask your network access provider to implement these filters for you in their routers. This will not be possible for many organizations for a number of reasons. Furthermore, DDOS attack tools can generate random packets such as that matching them with a set of access list rules can become difficult unless you do so by using negative space (by defining normal traffic and assuming everything else is DDOS traffic). To find out more about CAR go to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcpart4/qcpolts.htm http://www.cisco.com/warp/public/707/newsflash.html Intrusion Detection Systems --------------------------- Use an Intrusion Detection System to detect attackers that are communicating with the "slave", "master" or "agent" machines. This will allow you to know whether some machine in your network is being used to launch a known attack but will probably not detect new variations of these attacks and the tools that implement them. Most IDS vendors have signatures available to detect Trinoo, TNF or Stacheldraht network traffic. Host Auditing Tools ------------------- A number of file scanning tools are available that attempt to detect the existence of known DDOS tool client and server binaries in your system. A number of host auditing tool vendors have updated their tools to include these signatures. Just like antivirus software the tools become obsolete as new DDOS tools are developed or modified. The NIPC has made available a tool called "find_ddos" that searches the filesystem for the Trinoo, TNF, TNF2K and Stacheldraht DDOS tools. The tool is available for Solaris (Sparc and Intel) and Linux (Intel) operating systems. Beware that the NIPC does not provide source code to this program. You can find the program at: http://www.fbi.gov/nipc/trinoo.htm Network Auditing Tools ---------------------- A number of network scanning tools are available that attempt to detect the presence of DDOS agents running on hosts on your network. A number of network auditing tool vendors have updated their products to include the tests. Just like antivirus software these tools become obsolete as new DDOS tools are developed or modified. Dave Dittrich, Marcus Ranum, and others have developed "gag". This tool detects Stacheldraht agents. Its available for Unix systems. You can find the program at: http://staff.washington.edu/dittrich/misc/sickenscan.tar Dave Dittrich, Marcus Ranum, George Weaver, David Brumley, and others have developed "dds". This tool detects Trinoo, TFN and Stacheldraht agents. You can find the program at: http://staff.washington.edu/dittrich/misc/ddos_scan.tar Automated Network Tracing Tools ------------------------------- Tracing streams of packets with faked or "spoof" address through the network is a time consuming tasks that requires the cooperation of all networks carrying the traffic and that must be completed while the attack is in progress. If you recall when SYN flooding DOS attacks became fashionable back in 1997 MCI developed a tool called DoSTracker that automated a lot of the work required for them to trace the source of an attack through their network. Tools need to be developed to automate the tracing process within a network under the same authority as well as tools that can request traces to be performed across network authority boundaries. I'll buy the first person to write such tool a case of Red Hook Extra Special Bitter (ESB). Emergency Data Centers ---------------------- One can also think of these attacks as some type of natural disaster. It is common to have as part of your disaster contingency plans access to an offsite emergency data center that can be brought online in a short period of time to resume partial or full operational capacity. Organizations with enough resources should consider such site as a mitigating factor to the risk of a DDOS attack. Insurance --------- A number of insurance companies are now providing computer and computer security related policies. Under some circumstances this may provide a better return on investment (ROI) that some of the other measures presented here. Example of companies providing some type of computer security insurance are: http://www.tricityins.com/cc_insurance.htm http://www.securitydealers.com/protection/sedgwick.htm http://www.insuretrust.com/insurance.html http://www.aig.com/corpsite/pr2/pro04_17_97.html If you have any other suggestions that might mitigate the DDOS attacks let us know. -- Elias Levy SecurityFocus.com http://www.securityfocus.com/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:34:16 PDT