__________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN DDoS Mediation Action List Updated April 3, 2000 15:00 GMT Number K-032 ______________________________________________________________________________ PROBLEM: Distributed Denial of Service attacks have drawn attention to fundamental flaws in the present implementation of the TCP/IP stack. PLATFORM: Any Platform using the TCP/IP stack. DAMAGE: Both the intermediary and victim of this attack may suffer degraded network performance to the point of no access. SOLUTION: Apply the workarounds to help prevent, mediate the effects of, and forensics after an attack. ______________________________________________________________________________ VULNERABILITY The risk is medium. Failure to act on the recommended action ASSESSMENT: items will not lead to a compromise, but will aid in the attack's ability to go unresolved. ______________________________________________________________________________ Much has been said of the recent Distributed Denial of Service (DDoS) attacks. Although with the current TCP/IP implementation, there is little that can be done to prevent your network from suffering the effects of a DDoS, there are steps that can be taken to help reduce the chances that networks are used as a source of an attack agains another network. For more detailed information about DDoS tools, see CIAC's paper at: http://ciac.llnl.gov/ciac/documents/CIAC-2319_Distributed_Denial_of_Service.pdf First and foremost is to ensure that all systems are fully patched and that only necessary services are in use. For many, this is an endless battle that is challenging at best. The minimum effort should be to ensure that your border routers and systems in your Demilitarized Zone (DMZ) are as secure as possible. None of these attacks are possible if systems cannot be found to use as agents. The following steps should be taken as well: - Egress/Ingress filtering on all routers - Ensure routers are not Broadcast Amplifiers - Enable logging on all routers ______________________________________________________________________________ EGRESS FILTERING Egress filtering is the process of examining all packet headers leaving a subnet for address validity. If the packet's source IP address originates inside the subnet that the router serves, then the packet is forwarded. If the packet has an illegal source address, then the packet is simply dropped. There is very little overhead involved, therefore there is no degradation to network performance. While this will not prevent your site from participating in a DDoS, it will aid in the forensic process of detecting the source of these attacks. This will ensure that your network will not participate in a spoofed DoS attack. Since most of the attackers are interested in anomymity, and many of the DDoS tools do not test for egress filtering, your network will likely not be involved in an attack at all. In order to accomplish this, it is necessary to know the IP addresses that your network services. The router will check the source address of the packet against the routing table. Network administrators will have to check with each of their router manufacturers on specifics of how to enable this feature. Cisco has added this feature to the current 11.1CC branch of their OS. It is an interface command: [no] ip verify unicast reverse-path CIAC has already released a bulletin pertaining to the filtering of spoofed IP addresses. G-48: TCP SYN Flooding and IP Spoofing Attacks is available at: http://www.ciac.org/ciac/bulletins/g-48.shtml ______________________________________________________________________________ BROADCAST AMPLIFIER The second step is to make sure that your border routers are not Broadcast Amplifiers. A broadcast amplifier is a system that will take a single ICMP Echo Request and respond with one echo for each host on the network at the time of receiving the request. One such attack that takes advantage of a Broadcast Amplifier is called the "smurf" attack. The attacker will spoof the source address of the ICMP Echo Request - matching it to the target of the attack. Once the broadcast amplifier receives the request, the target will become flooded with ICMP Echo Replys. There is also a similar attack that uses the UDP Protocol called "fraggle". There are organizations that are "patrolling" the internet for networks that are still acting as a broadcast amplifiers and posting the IP addresses to a web site. One organization's database is used by EuroCERT to alert European network owners that have not fixed their routers. it is important to make sure that your routers are not on these lists. The lists can be found at: http://www.powertech.no/smurf http://www.netscan.org/ These organizations will test networks to see if it is a Broadcast Amplifier, but CIAC does not recommend this technique to determine if subnets need to be reconfigured. Simply ping the Network Base IP Address (XXX.XXX.XXX.0 / Class C) and the Broadcast Address (XXX.XXX.XXX.255 / Class C) of the subnet. If one or more duplicate replies are received, then the router is a broadcast amplifier and considered "broken", and should be fixed. There is one case study that shows that turning off broadcast amplification may have adverse affects on the network. If a host is configured to remote broadcast into a LAN workgroup so that the workstations on that LAN can see the server (such hosts are NT servers, or Samba servers) without a broadcast amplifier, the WINS server on the network will not receive the broadcast. This could cause some name resolution on Windows systems to not function properly. For this reason, and the fact that broadcast amplification can be a useful diagnostic tool, we recommend that only border routers be configured not to be broadcast amplifiers. This, in conjunction with the egress filtering, will ensure that your site is not a participant in a "smurf" or "fraggle" attack. These attacks will not work if the source address cannot be spoofed to the target address. CIAC has already released a bulletin pertaining to broadcast amplifiers. I-021A: "smurf" IP Denial of Service Attacks is available at: http://www.ciac.org/ciac/bulletins/I-021a.shtml ______________________________________________________________________________ INGRESS FILTERING One step that could aid in reducing the effects of a DDoS attack is to also install Ingress filtering on all border routers. Ingress filtering is the process of sifting through all of the packets entering a subnet and dropping the packets that are not allowed. The trick to Ingress filtering is to determine which IP addresses to block from your network. CIAC recommends that all private and reserved addresses not be allowed to enter. Below is a table of these addresses. 0.0.0.0/8 - Historical Broadcast 10.0.0.0/8 - RFC 1918 Private Network 127.0.0.0/8 - Loopback 169.254.0.0/16 - Link Local Networks 172.16.0.0/12 - RFC 1918 Private Network 192.0.2.0/24 - TEST-NET 192.168.0.0/16 - RFC 1918 Private Network 224.0.0.0/4 - Class D Multicast 240.0.0.0/5 - Class E Reserved 248.0.0.0/5 - Unallocated 255.255.255.255/32 - Broadcast Another suggestion is to take the Smurf Amplifiers Registry and add it to the above list. The registry can be found at http://www.powertech.no/smurf/ in many different formats that can be piped into different network routers. It is up to the network administrators to decide if all of the subnets are to be blocked in the registry. Many network administrators only block the high amplifying subnets. ______________________________________________________________________________ ROUTER LOGGING Router logs are invaluable in tracing these DDoS attacks. CIAC has found a surprising number of networks that do not have logging turned on. In many of the older systems, logging all packets that pass through the router and those that are dropped can cause a load issue with the CPU. With the developments in both software and hardware, it is now possible to log all packets or at least log packets at defined intervals, which would be sufficient to aid in forensics. While in many cases the source IP address will be spoofed, the MAC address of the packet source will be true. Using the MAC address to backtrack the attack packets through each hop can discover its source. If any one hop along the way does not have the proper logging, the attacker will go undiscovered. Starting with version 11.1CA of Cisco's IOS, many with these feature are available. Network administrators should consult their router manufacturers to see what needs to be done to enable at least interval logging. ______________________________________________________________________________ REFRENCES Graig A. Huegen - Smurfing: The Latest DoS Attack - http://users.quadrunner.com/chuegen/smurf.cgi The SANS Institute - Help Defeat Denial of Service Attacks: Step-by-Step - http://www.sans.org/dosstep/index.htm PowerTech - Smurf Amplifier Registry - http://www.powertech.no/smurf/ P. Ferguson and D. Senie - RFC: 2267 - Defeating Denial of Service Attacks which employ IP Source Address Spoofing - http://ftp.apnic.net/ietf/rfc/rfc2000/rfc2267.txt CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE, DOE contractor sites, and the NIH may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), use one of the following methods to contact CIAC: 1. Call the CIAC voice number 925-422-8193 and leave a message, or 2. Call 888-449-8369 to send a Sky Page to the CIAC duty person or 3. Send e-mail to 4498369@skytel.com, or 4. Call 800-201-9288 for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ (or http://ciac.llnl.gov -- they're the same machine) Anonymous FTP: ftp.ciac.org (or ciac.llnl.gov -- they're the same machine) Modem access: +1 (925) 423-4753 (28.8K baud) +1 (925) 423-3331 (28.8K baud) PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) K-022: FreeBSD - Asmon/Ascpu Vulnerability K-023: FreeBSD - Delegate Proxy Server Vulnerability K-024: Microsoft Systems Management Server Vulnerability K-025: MySQL Password Authentication Vulnerability K-026: Microsoft SQL Server Admin Login Encryption Vulnerability K-027: Microsoft SQL Server and MSDE Malicious Query Vulnerability K-028: FreeBSD - Port Exploits for mh/nmh, Lynx, and mtr K-029: Microsoft "Registry Permissions" Vulnerability K-030: SGI - Vulnerability in the objectserver daemon K-031: Mobile Malicious Code