STEPS TO PREVENTING DOS ATTACKS

6 steps to help prevent distributed denial of service attacks

 

 

1. Secure the hosts on your network

Since some types of distributed denial of service attacks require attackers to execute programs on numerous host machines, you should ensure that your host machines are secure. Remove all unnecessary or unused network daemon programs especially the BSD "r" commands such as rlogin and rexec. Replace them with ssh.

Network programs are sometimes vulnerable to buffer overflow and other types of bugs, exposing your host to exploitation. These are fixed when they are found and you should ensure you are running current and up-to-date versions of daemons to take advantage of bug fixes.

2. Disallow IP spoofing

IP spoofing is the term for causing one host to pretend to be another. A well-known case used this technique to gain access to hosts supporting the BSD "r" commands by spoofing trusted hosts.
It's quite difficult to know for certain whether a datagram is genuine or spoofed. You should ensure that any datagrams coming into your network with a source address that belongs to your network are treated as suspect. Kernels 2.2 and newer provide an implementation of the spoof protection described in RFC1812 that will suit most simple network configurations. Some distributions already use this. If yours doesn't, execute the following on each Linux hosts at boot time:

for pfile in /proc/sys/net/ipv4/conf/*/rp_filter
do
 echo "1" > $pfile
done

You can protect non-Linux hosts by using firewall rules in your Linux router. To protect our example networks we would use:
For older kernels:

ipfwadm -I -a deny -W ppp0 -S 172.29.16.0/24
ipfwadm -I -a deny -W ppp0 -S 172.29.17.0/24

For 2.2 kernels:

ipchains -A input -w ppp0 -s 172.29.16.0/24 -j deny
ipchains -A input -w ppp0 -s 172.29.17.0/24 -j deny

For 2.3 and newer kernels:

iptables -A FORWARD -i ppp0 -s 172.29.16.0/24 -j DROP
iptables -A FORWARD -i ppp0 -s 172.29.17.0/24 -j DROP

3. Disallow ICMP to broadcast and multicast addresses from outside

To prevent "smurf" type attacks you should prevent ICMP messages arriving at your broadcast and multicast addresses from outside your network. Assuming the network device that supports our Internet connection is ppp0 and that our broadcast addresses are 172.29.16.255 and 172.29.17.255.
For older kernels:

ipfwadm -I -a deny -P icmp -W ppp0 -D 172.29.16.255
ipfwadm -I -a deny -P icmp -W ppp0 -D 172.29.17.255
ipfwadm -I -a deny -P icmp -W ppp0 -D 224.0.0.0/4

For 2.2 kernels:

ipchains -A input -p icmp -w ppp0 -d \
  172.29.16.255 -j deny
ipchains -A input -p icmp -w ppp0 -d \
  172.29.17.255 -j deny
ipchains -A input -p icmp -w ppp0 -d \
  224.0.0.0/4 -j deny

For 2.3 and newer kernels:

iptables -A FORWARD -m multiport -p icmp -i ppp0 -d \
  172.29.16.255 -j DROP
iptables -A FORWARD -m multiport -p icmp -i ppp0 -d \
  172.29.17.255 -j DROP
iptables -A FORWARD -m multiport -p icmp -i ppp0 -d \
  224.0.0.0/4 -j DROP

In 2.2 kernels and newer, you can also use the following command on each of your hosts to prevent them from replying to ICMP echo requests on broadcast and multicast addresses:

echo "1" >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

If you're using a kernel that supports netfilter, you can also use the limiter to limit the volume of ICMP echo requests to all other addresses to a reasonable rate. To limit incoming ICMP messages in our example network to one per second, but allow bursts of two per second, you could use:

iptables -A FORWARD -m limit -p ICMP -i ppp0 \
  --limit 1 --limit-burst-number 2

You might optionally want log any matching datagrams to ensure that you're able to see any potential attacks.

4. Consider even more tightly controlled firewalls

If you have limited requirements for Internet access, you might consider an even more tightly controlled firewall. For example, you could filter ICMP to broadcast addresses, even from local hosts to help ensure that even if a local host is breached your network cannot be used as an "amplifier." You might also consider deploying firewalls on each local host rather than relying only on filtering in routers and a more network firewall configuration (such as a NAT or masquerade-style configuration, or use of a perimeter network).

5. Be vigilant and observant

You can minimize the damage associated with distributed denial of service attacks by being aware of them soon after they begin. It is important to keep an eye on what is happening on your network and using the logging facilities of the Linux firewall support can help. Use the -l argument on ipfwadm and ipchains rules, and the -j LOG target for iptables commands to cause datagrams matching the rule to be logged to the console. Beware: The host activity caused by this logging can precipitate a denial of service attack all by itself. Fortunately the iptableslimit matcher (-m limit) works with logging as well.

The kernel provides a means of logging datagrams suspected to be spoofed IP addresses using:

echo "1" >/proc/sys/net/ipv4/conf/all/log_martians

Staying alert and aware also involves keeping up to date with bugs and exploits that have been discovered and reported by others. The Computer Emergency Response Team (CERT) provides a web site and mailing list designed to keep network and system administrators advised of newly reported security problems. You can find CERT at http://www.cert.org/.

6. Communicate with your peers and encourage them to do the same

This is the most important step. Widespread adoption of good security practices can afford reliable and effective protection against distributed denial of service attacks. Make sure you know who the network or security administrator is of your network peers and upstream providers. Talk with them, let them know what you are doing, and encourage them to do the same. When something does happen, you'll be able to quickly gain their support and assistance and work together to solve the problem.