Haunted by the Ghost of Smurfing
Robert Owen Thomas When the smurf attack (named for the source code used to launch the attack) hit the Internet, it caught many backbone providers off guard. Smaller ISPs also succumbed to the attack, and the Internet pipes became clogged with bogus broadcast and ICMP traffic. Many rushed to protect themselves against such attacks. However, in the dash to build solid defenses, many have forgotten that it is not only the intended victim of the smurf attack that is in danger. The network used to amplify the smurf attack must also be protected. This is the topic of this column. What is a Smurf Attack? To smurf a victim, the attacker uses the now infamous smurf.c source code. This code spoofs the source address of the ICMP ECHO_REQUEST packets to be the address of the intended victim. Then, the packets are addressed to the broadcast address of some existing network. When this packet hits the broadcast address of the destination network, the destination network amplifies the response into many responses, effectively flooding the victim with many replies. How many replies? Consider a broadcast to a class C network. The responses could come from more than 254 hosts. On class B network, the responses could come from 60000 or more hosts! Worse, an attacker will often use multiple networks to amplify the smurf attack against the intended victim. For example:
Evil Host: 192.168.1.15 Assume all hosts are on class C networks, meaning a netmask of 255.255.255.0 or 24 bits. The Evil Host launches the smurf attack, and sets the source address of the ICMP ECHO_REQUEST (ping) packet to be the Victim Host's IP address. The destination address is set to be 192.168.55.255, which is the broadcast address of the amplifier network. The packet winds its way across the Internet, finally hitting the 192.168.55.0 network. Without adequate router-based or host-based countermeasures, it is likely that every host on the 192.168.55.0 network will now respond with an ICMP ECHO_REPLY packet. These packets will be sent to the Victim Host, 192.168.20.3. From that one spoofed packet will arise many response packets, all hitting the Victim Host. The Victim Host will be flooded, perhaps rendering it unusable for some amount of time. This victim could be your Web server, your mail server, your screening router, or even your firewall. Further, the Victim Host's Internet link is also saturated, perhaps denying network access to all of the hosts on the Victim Host's network. The Amplifier Network also suffers network congestion. But Isn't This Old News? This is certainly an old attack within the rapid pace of events on the Internet. The source code, smurf.c, was made available in late 1997, and CERT released an official incident report in January of 1998. One would think that the problem would have been eradicated by now. Alas, this is not the case. Recent discussions among Level One Internet backbone providers indicates that the smurf problem still exists, and is still being actively exploited. The CEO of one Level Two ISP recently reported that he had been hit by a massive smurf attack. Another security product vendor was taken off the air when their upstream ISP was hit with a smurf attack. Yet another major ISP has even taken the step of consulting an attorney with the intent of suing the smurf amplifier. Other ISPs and corporations have reported the same problem. So why is this still an issue? The real issue is that many network managers still have not taken the relatively simple steps necessary to prevent their networks from becoming smurf amplifiers. An attacker is not going to use his/her own network as the amplifier - this would defeat the purpose of the attack. So, the attacker requires a poorly configured network on the Internet to be the amplifier. This is where the network or system manager can step in and prevent such attacks. Preventing Smurf Amplification at the Border Router The smurf attack relies upon a directed broadcast, or a packet sent directly to the broadcast address of a given network. Fortunately, this is a fairly simple type of packet to discard entirely. Tests by the Level One backbone providers have found that dropping such packets results in a minimal, and certainly not noticeable, load on the border routers. For Cisco routers running the Cisco IOS, the following is an example configuration for an Ethernet interface:
interface Ethernet0 description Engineering Department building 1-A floor 4 ip address 192.168.55.254 255.255.255.0 no ip proxy-arp no ip directed-broadcast
The "no ip directed-broadcast" line tells the router not to allow packets sent to the broadcast address of the interface (e.g., 192.168.55.255) to pass. With a few keystrokes, the smurf amplification is prevented. Preventing Smurf Amplifications at the Host Your network perimeter can be protected with the few keystrokes shown above, and this is a good first step. However, it is still possible (though likely self-defeating) to launch a smurf attack or subnet ping within your network. Fortunately, many UNIX vendors have devised ways to prevent this problem. Sun in Solaris 2.3 and higher has added a variable to the ndd IP tuneables called ip_respond_to_echo_broadcast. By disabling this tuneable, the Solaris host will no longer respond to broadcast pings. To tune this, simply type:
pudge# ndd -set /dev/ip ip_respond_to_echo_broadcast 0
The Solaris host will no longer respond to broadcast ping messages. To make this change permanent, insert the line above into /etc/rc2.d/S69inet in the "Set configurable parameters" section. Other UNIX vendors have implemented similar fixes. Please contact your vendor or support newsgroup for the proper syntax. Hosts running Windows 95 or Windows NT do not respond to broadcast echo packets. Conclusions During audits, it is often surprising how many old exploits still work. It is, therefore, critical for every system and network administrator to understand the nature of an exploit or attack. The big picture should be applied to all security issues. How does this affect the key hosts? How does this affect the entire infrastructure? Furthermore, companies should take the time to quiz their Internet providers regarding security. After all, what good will the best security measures do if the upstream Internet link is down because of a security incident? Remember, security is an end-to-end issue that requires forethought and cooperation across the board. About the Author
Rob Thomas is a long-time UNIX and networking geek specializing in information security. He can be reached at: robt@cymru.com, http://www.cymru.com/~robt.
|