Section 5.6 Packet Storms, Smurf Attacks, and Fraggles

---

5.6 Packet Storms, Smurf Attacks, and Fraggles

Packet storm is the name given to a technique used by an intruder (or sometimes many intruders working together) to flood a system with junk packets to use up bandwidth to prevent legitimate packets from getting through in a timely manner. This is one type of Denial of Service (DoS) attack. If the attack originates from multiple systems, it is called a Distributed Denial of Service attack, or DDoS attack. Some of the "brute force" DDoS attacks rely on the cracker compromising many systems, installing the zombies, and, sometimes months later, instructing all of them to attack the victim's system at once. This is illustrated in Figure 5.3, where each box represents an unrelated system. Note that the cracker needs to send only a few messages to cause millions of junk packets to flood the victim's system. The cracker can use ICMP or UDP packets with spoofed source addresses to make it almost impossible to trace the source of the attacks. Boxes labeled "Z" are known as zombies. These are the many compromised systems that attack the victim on command.

Figure 5.3. Distributed Denial of Service attack.

As Figure 5.3 illustrates, once the masters and zombies are set up, a few packets from the cracker will disable even the largest site. Because of multiple levels of "indirection" between the cracker and the victim, a cracker is unlikely to be caught unless he boasts to the wrong person.

Smurf attacks are a particular type of packet storm attack whereby the attacker provides a fake source address when sending a ICMP echo (ping) to an IP broadcast address as the destination. Unless the destination network is designed to defend against this attack, this request will be seen by all the systems on the network and each of these will reply to the fake source, flooding this site (the intended victim) with bogus packets. This attack can be made even worse by using a broadcast address as the spoofed source address too, causing a multiplication of the number of systems that the fake source and the destination each have that respond to these broadcasts.

Craig Huegens http://users.quadrunner.com/chuegen/smurf/ Web site provides much information on Smurf attacks and responses. His site is frequently cited by other sites and he graciously has allowed the use of his material in this book.

The use of a broadcast destination address to cause one initial packet to generate many replies (ICMP echo replies in this case) is called amplification. Thus, the perpetrator does not need to expend too much bandwidth on her system. If there are 100 systems on the network where she sent her ping to the broadcast "host," she will get 100 junk echo replies delivered to the victim's system. If she hits a large site, such as a university or Fortune 500 company, she may get 1000-to-1 amplification. Thus, she can launch the attack from a system with anything from a dial-up to a T1 connection and take down a large target site with a T3 or better. If the class A network 10.*.*.* allows broadcast destinations, the echo request would be sent to 10.255.255.255.

The site where echo requests are sent to is called an amplifier. An attacker can use multiple amplifiers in parallel for an increased effect. This is done by sending a packet first to one amplifier and then to a second amplifier and then a third packet to the first amplifier. This still is a single stage of amplification. If the intended victim also supports broadcast destinations, two stages of amplification can be obtained.

This is done by sending packets to the victim's network's broadcast address with a spoofed source address that is the broadcast address for another network. If the victim's network has 50 systems and the other network has 100 systems, each of the victim's 50 systems will respond to the echo request with a message to the other network, causing a reply from each of its 100 systems. This results in a multiplication of 50 100 or 5000. If each site has 1000 systems, a multiplication of 1,000,000 will be obtained. Most large networks defend against this attack now.

The name of this attack is due to the Smurf cartoon characters where many, many of these blue creatures tend to flood places.

There is an attack related to a Smurf attack called a fraggle, which uses UDP echo requests similarly to the ICMP echo request by tweaking the smurf program.

5.6.1 Avoiding Being an Amplifier

There are a number of things you need to do to avoid being an amplifier, unwittingly used to attack other systems. These things should be done anyway to protect yourself. They are discussed on the following page.

Block all packets from the Internet with a broadcast destination or broadcast source at your initial router or firewall.

If you do not have a firewall or router between your systems and the Internet (and cannot be convinced to do so if you have more than a few systems), the preceding advice should be applied to each system. Each of these systems definitely should be running IP Chains to allow this sort of filtering. (Remember that any Linux box with a reasonably recent distribution, 2.2 kernel or later, may easily be configured as a firewall between your internal LAN and either a separate Ethernet card to the Internet or a PPP, ISDN, T1, or T3 to the Internet. Even a 386 can keep up with an ISDN connection and a Pentium can handle a T3 connection.)

Your firewall should also be configured to block packets coming from outside your organization claiming a source address that should only originate from inside your organization and vice versa. (This is a common packet spoofing technique.) The "vice versa" is to prevent rogues within your organization from launching attacks. If you are an ISP or university, you certainly must guard against rogues! If you are a large organization of another sort, this certainly is true too. Disallow source addressing for packets coming into your network (and leaving your network as well if you might have rogues within your network).

You may want to disallow directed broadcasts within your subnets with more than, say, five systems. (Be sure that you do not have any applications that rely on broadcasts before doing this, such as DHCP.) "Firewalls with IP Chains and DMZ" on page 514 covers firewall configuration in great detail, including a sample set of very thorough rules.

The commands for common routers are as follows.

 Cisco:       Interface command "no ip directed-broadcast" Proteon:       IP protocol configuration "disable directed-broadcast" Bay Networks:       Set a false static ARP address for broadcast address 

You could prevent ICMP echo requests and ICMP echo replies from entering your network by silently ignoring them, but this is not recommended except as a last resort. This makes troubleshooting difficult for both yourself and others having difficulties getting to your network. The reason for also ignoring (dropping) the replies is that some crackers will send these, expecting your system to send a response saying that it did not send an ICMP echo request. It might be possible to allow normal echos while blocking Smurf attacks by only blocking ICMP echo replies with a size much more than 100 bytes, because the Smurf attacks seem to use a packet of about 1000 bytes.

Turn off replies for ICMP echos to broadcast addresses (silently discarding them). This specifically is allowed in RFC-1122 Section 3.2.2.6, where they use the term multicast instead of broadcast. This capability is available starting in the 2.2 kernels. There is a patch available for some older kernels. Controlling this and other kernel parameters designed to block various attacks is covered in "Kernel Protocol Switches" on page 80. To stop this particular attack, the following command should be issued on each boot-up:

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

RFC 1122 is available at

www.faqs.org/rfcs/rfc1122.html

5.6.2 Repelling a Packet Storm Attack

If you find yourself the victim of a packet storm attack, you are in a difficult situation. A packet storm uses up the bandwidth of your Internet connection before it leaves your ISP. Thus, there is no recovery possible from your network. Some companies will try to sell you their box that "will protect against packet DDoS and similar attacks." Do not be taken in by unsubstantiated claims. Although they may protect against Smurf attacks, packet fragmentation attacks, and similar attacks that depend on violating the protocols, a Linux firewall that is configured as described in this book will do an excellent job protecting against these for little cost.

Use Snort or sniffit or tcpdump to analyze the packets, especially the claimed source addresses. Do they seem to be from a single IP address or many? If only a single address or a small number of them seem to be attacking, determine the organization owning the IP address using the techniques in "Finding the Attacker's System" on page 707. Contact them and have them stop the attack. Insist that they shut down their equipment, if necessary, to stop the attack.

Keep in mind that the source address may be spoofed, so it is possible that the attack is coming from an unrelated system. If that organization is unreachable or uncooperative, use traceroute with the source IP address as the argument. Observe the systems listed just before the specified system that seem to be from a different organization. This would be the ISP or upstream provider. Follow the same techniques just discussed to contact them and ask them to verify and stop the attack.

If the source address is spoofed (or if the previous suggestions were not fruitful), it is time to contact your ISP or upstream provider. They should have a plan of action for this problem, but many do not. If the source address is spoofed, they need to see which system last handled the packet and that entity needs to see which system handled it before that, and so on, until the source system has been found. If many source systems are attacking, this technique might need to be followed for each one, a time-consuming effort. Although it is easy to block attacks of a particular type of packet, even some of the current DDoS programs offer attacks using varying types of packets.

Future DDoS programs will vary the packets even more, making blocking even harder. Already, there has been some discussion among white hats about enhancements to the protocols to allow a destination system to send a message upstream to say "stop sending packets with these specifications." This would allow prompt blocking of these attacks. Also, as more sites enhance their firewalls to have Egress filtering, the blocking of evil packets originating from their networks, these attacks will become harder to perpetrate.

5.6.3 Cisco Routers

SysAdmins using Cisco routers might benefit from reading Cisco's Web page for tightening security on their routers:

www.cisco.com/warp/public/707/3.html

It discusses blocking network access to what Cisco calls a router's UDP diagnostic port. These commonly supported Linux/UNIX services are used frequently for DoS attacks. These services are listed in Table 5.1.

Table 5.1. Linux/UNIX Diagnostic Services

Service	Port	TCP	UDP	Purpose
Echo	7	Y	Y	Echos what is received.
Discard	9	Y	Y	Throws away what is received.
Daytime	13	Y	N	Sends system date and time.
Chargen	19	Y	Y	Generates a stream of characters.

To disable them on a Cisco router, issue the following global configuration commands:

 no service udp-small-servers no service tcp-small-servers 

You also want to disable these on your Linux systems as well by commenting out their entries in /etc/inetd.conf. Although these services are helpful to SysAdmins at other sites trying to analyze network problems, they also are useful to crackers and those committing DoS attacks.

Unfortunately, although these services are internal to inetd, you cannot use TCP Wrappers to allow their use by certainly friendly hosts or domains. However, you could use the firewall capability of IP Chains to grant their use only to certain systems.

5.6.4 DDoS Attacks: Web Resources to Counteract

Craig Huegen's excellent site, already mentioned, should be referred to. It is at

http://users.quadrunner.com/chuegen/smurf/

Besides Craig Huegen's site, the following site offers a good explanation:

www.cert.org/tech_tips/denial_of_service.html

How to respond:

www.cert.org/reports/dsit_workshop.pdf

These tools will help detect trin00 and TFN (Tribe Flood Network):

www.iss.net/cgi-bin/dbt-display.exe/db_data/press_rel/release/122899199.plt

This site offers suggestions for improving site security:

www.cert.org/security-improvement

These sites offer suggestions for recovering from incidents:

www.cert.org/nav/recovering.html

www.sans.org/newlook/publications/incident_handling.htm

Following the well-publicized DDoS attacks in February 2000, this author has seen several firewall vendors falsely claim that their equipment will protect against these. Most of the types of DDoS attacks that these firewall boxes can block, such as SYN flood attacks and fragmented packets, already can be blocked by a properly configured Linux box, as explained in this book. Seek independent advice.

---

Top