Last Day to Save $400 on SANS Albuquerque 2014

Help Defeat Distributed Denial of Service Attacks: Step-by-Step

Revision: 1.4 - Date: 2000/03/23 16:05:35 GMT
Immediate Actions Requested Of All Organizations Connected To The Internet
Related Resources:
Roadmap to Defeating DDoS

Organizations that operate networks connected to the Internet may be serving as unwitting participants in Denial of Service (DoS) Attacks like those that hit many organizations in early February, 2000.

You can act now to reduce the chances that your network could be used to damage other networks if you implement the following two steps:

  • Egress Filtering to Stop Spoofed IP Packets from Leaving Your Network
  • Stop Your Network from Being Used as a Broadcast Amplification Site
These two steps should be implemented immediately, and detailed instructions for doing this are provided below. Broad application of these two steps can significantly reduce the threat posed by DoS Attacks.

Step1: Egress Filtering to Stop Spoofed IP Packets from Leaving Your Network

Purpose: To prevent your network from being the source of spoofed (i.e. forged) communications that are often used in DoS Attacks.

Action: Ensure that your routers and firewalls are configured to forward IP packets only if those packets have the correct Source IP Address for your network. The correct Source IP Address(es) would consist of the IP Network Addresses that have been assigned to your site. It is important to do this throughout your network, especially at the external connections to your Internet or upstream provider.
Step 1.1: Deny Invalid Source IP Addresses

All organizations connected to the Internet should only allow packets to leave their network with valid Source IP Addresses that belong to their network. This will minimize the chance that your network will be the source of a Spoofed DoS Attack. This will not prevent Distributed DoS attacks coming from your network with valid source addresses.

In order to implement this you will need to know the IP network blocks that are in use at your site. If you do not know this information at this time, then please skip to Step 1.2, and come back to this step once you have that information.

Preventing Spoofed Source IP Address traffic can be accomplished with filtering on routers, firewalls, and hosts. Here is a generic example of what the filter needs to look like.

Permit Your Sites Valid Source Addresses to the Internet. Deny All Other Source Addresses.

On the router(s) connected to your ISP(s), if the interface IP address on the link connecting to the ISP is not out of one of your site's IP blocks, you should also permit packets with the interface IP address.

For detailed instructions on implementing this filtering please select the platform that you are using from the list in the "Step One: Detailed Directions" section below.

Step 1.2: Deny Private & Reserved Source IP Addresses

This step is not necessary if you were able to fully complete Step 1.1.

If you are unsure what address space is in use at your site, then you should at least deny Private (RFC 1918) and Reserved Source IP Addresses.

The following is a list of source addresses that should be filtered.

0.0.0.0/8   - Historical Broadcas
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

If you are using Network Address Translation (NAT), you need to make sure that you perform this filtering between your NAT device and your ISP, and you should also verify that your NAT device configuration only translates address used and authorized for your internal address space.

Denying Private and Reserved Source IP Addresses can be accomplished with filtering on routers, firewalls, and hosts. Please select the platform that you are using from the list in the "Step One: Detailed Directions" section below.

Step 1: Detailed Directions for Egress Filtering
Please select the router, firewall, or host that you use from the list below for detailed instructions on how to implement Egress Filtering to Stop Spoofed IP Packets for the particular platform that you are using.

Step2: Stop Your Network from Being Used as a Broadcast Amplification Site

Purpose: To ensure that your network can not be used as a Broadcast Amplification Site to flood other networks with DoS attacks such as the "smurf" attack.

Action: Configure all of your systems (routers, workstations, servers, etc.) so that they do not receive or forward Directed Broadcast traffic.
Step 2.1: Disable IP Directed Broadcast on all Systems

Detailed directions for doing this are available for the following systems.

For all other systems, please go to http://users.quadrunner.com /chuegen/smurf/ where you'll find Craig Huegen's authoritative page containing instructions for many other types of systems.

The following systems have Directed Broadcast disabled by default. However, these systems may have a way to turn this behavior back on. Please select the link for your platform for information on making sure that the system is in the default state, and does not allow directed broadcasts.

For Windows NT 4.0, the default behavior for answering broadcast packets was changed in Service Pack 4. The latest Service Packs for NT can be obtained from Microsoft at http://support.microsoft.com/support/kb/articles/Q152/7/34.ASP
Step 2.2: Test your network to determine if it is an amplification site.

To test your network to see if it is acting as an amplification site you can use the "ping" command to send an ICMP Echo Request packet to the Network Base IP Address of your network(s) and the Broadcast IP Address of your network(s).

You will need to know your Network Base IP Address and your Broadcast IP Address. You may find the CIDR Table helpful in determining these addresses for your network.

From a machine on the Internet side of your router (i.e. off your site) ping both the Network Base Address (x.x.x.0 for a /24 aka Class C) and the Broadcast Address (x.x.x.255 for a /24 aka Class C) of an internal subnet with a number of machines on it.

Please select from the following list of operating systems for detailed instructions on using the ping command and analyzing the output to determine if your network is a Broadcast Amplification site.

Another way to test your network is to go to some of the public web sites that provide a way to test your network from a remote location.

Please be aware that these sites are operated by independent third parties, and that you should use them at your own risk. If your site is in really poor shape it may get added to a "blacklist" that can then be used by attackers to identify your site as a good broadcast amplification site. Because of this you are strongly encouraged to self test with the ping commands listed above first.

Step 2.3: Require that Vendors Disable IP Directed Broadcast by Default

When you purchase new systems, require that the vendor disable receipt and forwarding of directed broadcast packets as specified in RFC 2644.

From RFC 2644:
A router MAY have a configuration option to allow it to receive directed broadcast packets, however this option MUST be disabled by default, and thus the router MUST NOT receive Network Directed Broadcast packets unless specifically configured by the end user.

A router MAY have an option to enable receiving network-prefix- directed broadcasts on an interface and MAY have an option to enable forwarding network-prefix-directed broadcasts. These options MUST default to blocking receipt and blocking forwarding of network-prefix-directed broadcasts.

Based on this you should be asking your vendors to ship systems with Directed Broadcast disabled by default. At the very least the vendor should provide a mechanism to disable Directed Broadcasts.

Some vendors already disable IP directed broadcast by default in the latest versions of their software, but many do not. Please help educate these other vendors by pointing them to RFC 2644.

Credits:
Please see the Credits Section for a list of the many talented people that helped to make this document a reality.