SMURF Attack

Problem:

As explained at http://www.quadrunner.com/~chuegen/smurf.cgi:

The "smurf" attack, named after its exploit program, is one of the most recent in the category of network-level attacks against hosts. A perpetrator sends a large amount of ICMP echo (ping) traffic at IP broadcast addresses, all of them having a spoofed source address of a victim. If the routing device delivering traffic to those broadcast addresses performs the IP broadcast to layer 2 broadcast function noted below, most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply each, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, there could be potentially hundreds of machines reply to each packet.

The "smurf" attack's cousin is called "fraggle", which uses UDP echo packets in the same fashion as the ICMP echo packets; it is a simple re-write of "smurf".

Currently, the providers/machines most commonly hit are IRC servers and their providers.

There are two parties whom are hurt by this attack... the intermediary (broadcast) devices--let's call them "amplifiers", and the spoofed address target, or the "victim". The victim is the target of a large amount of traffic that the amplifiers generate.

Let's look at the scenario to paint a picture of the dangerous nature of this attack. Assume a co-location switched network with 100 hosts, and that the attacker has a T1. The attacker sends, say, a 768kb/s stream of ICMP echo (ping) packets, with a spoofed source address of the victim, to the broadcast address of the "bounce site". These ping packets hit the bounce site's broadcast network of 100 hosts; each of them takes the packet and responds to it, creating 100 ping replies out-bound. If you multiply the bandwidth, you'll see that 76.8 Mbps is used outbound from the "bounce site" after the traffic is multiplied. This is then sent to the victim (the spoofed source of the originating packets).

Solutions:

*

Apply filtering rules at your border router.

Filter out ICMP/UDP packets directed for broadcast addresses. To filter out ICMP directed broadcast, please use this vendor specific information (for others please refer to http://www.quadrunner.com/~chuegen/smurf.cgi):
o

Cisco - as of IOS version 12.0, a feature called no ip directed-broadcast" is now the default configuration. For previous versions of IOS, use the interface configuration command to enable this.
o

Bay Networks - You can use this command

[1:1]$bcc
bcc> config
hostname# ip
ip# directed-bcast disabled
ip# exit
o

3Com NetBuilder - To disable 3Com routers from forwarding directed broadcast, you can enter this command

SETDefault -IP CONTrol = NoFwdSubnetBcast

*

Apply patches for hosts to discard ICMP directed broadcast

Here is the relevant information for specific platforms:
o

IBM AIX 4.x - use this command

no -o bcastping=0 Â Â Â Â # disable bcast ping responses (default)
o

Solaris - add this command into /etc/rc2.d/S69inet

ndd -set /dev/ip ip_respond_to_echo_broadcast 0
o

FreeBSD - as of version 2.2.5, FreeBSD does not respond to echo request directed for broadcast addresses. The relevant sysctl parameter is

net.inet.icmp.bmcastecho
o

NetBSD/OpenBSD - use this parameter for sysctl

sysctl -w net.inet.ip.directed-broadcast=0
o

Linux - in Linux you can completely deny echo request by compiling this option in the kernel, i.e. CONFIG_IP_IGNORE_ECHO_REQUESTS.

However, this violates RFC 1122. To protect Linux hosts from this attack, one can make use of Linux's in-kernel firewall capability. This can be done with

ipfwadm -I -a deny -P icmp -D 123.123.123.0 -S 0/0 0 8
ipfwadm -I -a deny -P icmp -D 123.123.123.255 -S 0/0 0 8

(replace 123.123.123.0 and 123.123.123.255 with your base network number and broadcast address, respectively).