LinuxDevCenter.com

oreilly.comSafari Books Online.Conferences.

We've expanded our Linux news coverage and improved our search! Search for all things Linux across O'Reilly!

Search
Search Tips

advertisement

Listen Print Subscribe to Linux Subscribe to Newsletters

Preventing Distributed Denial of Service Attacks
Pages: 1, 2, 3




6 steps to help prevent distributed denial of service attacks

There are several things you can do to assist in preventing your network from being used in 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.

Pages: 1, 2, 3

Next Pagearrow




Tagged Articles

Be the first to post this article to del.icio.us

Sponsored Resources

  • Inside Lightroom
Advertisement

Sponsored by:

O'Reilly Media

©2009, O'Reilly Media, Inc.
(707) 827-7000 / (800) 998-9938
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
About O'Reilly
Academic Solutions
Authors
Contacts
Customer Service
Jobs
Newsletters
O'Reilly Labs
Press Room
Privacy Policy
RSS Feeds
Terms of Service
User Groups
Writing for O'Reilly
Content Archive
Business Technology
Computer Technology
Google
Microsoft
Mobile
Network
Operating System
Digital Photography
Programming
Software
Web
Web Design
More O'Reilly Sites
O'Reilly Radar
Ignite
Tools of Change for Publishing
Digital Media
Inside iPhone
O'Reilly FYI
makezine.com
craftzine.com
hackszine.com
perl.com
xml.com

Partner Sites
InsideRIA
java.net
O'Reilly Insights on Forbes.com