CA-98.01
Published: 1998-01-05 00:00:00
Updated: 1998-08-24 00:00:00
"smurf" IP Denial-of-Service
Attacks
This advisory is intended primarily for network administrators responsible for router configuration
and maintenance.
The attack described in this advisory is different from the denial-of-service attacks described in
CERT advisory CA-97.28.
The CERT Coordination Center has received reports from network service providers (NSPs),
Internet service providers (ISPs), and other sites of continuing denial-of-service attacks involving
forged ICMP echo request packets (commonly known as "ping" packets) sent to IP broadcast
addresses. These attacks can result in large amounts of ICMP echo reply packets being sent
from an intermediary site to a victim, which can cause network congestion or outages. These
attacks have been referred to as "smurf" attacks because the name of one of the exploit programs
attackers use to execute this attack is called "smurf."
The CERT/CC urges you to take the steps described in Section III to reduce the potential that
your site can be used as the origination site (Sec. III.C) or an intermediary (Sec. III.A.) in this
attack. Although there is no easy solution for victim sites, we provide some recommendations in
Sec. III.B.
We will update this advisory as we receive additional information. Please check our advisory files
regularly for updates that relate to your site.
I. Description
The two main components to the smurf denial-of-service attack are the use of forged ICMP echo
request packets and the direction of packets to IP broadcast addresses.
The Internet Control Message Protocol (ICMP) is used to handle errors and exchange control
messages. ICMP can be used to determine if a machine on the Internet is responding. To do this,
an ICMP echo request packet is sent to a machine. If a machine receives that packet, that
machine will return an ICMP echo reply packet. A common implementation of this process is the
"ping" command, which is included with many operating systems and network software packages.
ICMP is used to convey status and error information including notification of network congestion
and of other network transport problems. ICMP can also be a valuable tool in diagnosing host or
network problems.
On IP networks, a packet can be directed to an individual machine or broadcast to an entire
network. When a packet is sent to an IP broadcast address from a machine on the local network,
that packet is delivered to all machines on that network. When a packet is sent to that IP
broadcast address from a machine outside of the local network, it is broadcast to all machines on
the target network (as long as routers are configured to pass along that traffic).
IP broadcast addresses are usually network addresses with the host portion of the address having
all one bits. For example, the IP broadcast address for the network 10.0.0.0 is 10.255.255.255. If
you have subnetted your class A network into 256 subnets, the IP broadcast address for the
10.50 subnet would be 10.50.255.255. Network addresses with all zeros in the host portion, such
as 10.50.0.0, can also produce a broadcast response.
In the "smurf" attack, attackers are using ICMP echo request packets directed to IP broadcast
addresses from remote locations to generate denial-of-service attacks. There are three parties in
these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also
be a victim).
The intermediary receives an ICMP echo request packet directed to the IP broadcast address of
their network. If the intermediary does not filter ICMP traffic directed to IP broadcast addresses,
many of the machines on the network will receive this ICMP echo request packet and send an
ICMP echo reply packet back. When (potentially) all the machines on a network respond to this
ICMP echo request, the result can be severe network congestion or outages.
When the attackers create these packets, they do not use the IP address of their own machine
as the source address. Instead, they create forged packets that contain the spoofed source
address of the attacker's intended victim. The result is that when all the machines at the
intermediary's site respond to the ICMP echo requests, they send replies to the victim's machine.
The victim is subjected to network congestion that could potentially make the network unusable.
Even though we have not labeled the intermediary as a "victim," the intermediary can be victimized
by suffering the same types of problem that the "victim" does in these attacks.
Attackers have developed automated tools that enable them to send these attacks to multiple
intermediaries at the same time, causing all of the intermediaries to direct their responses to the
same victim. Attackers have also developed tools to look for network routers that do not filter
broadcast traffic and networks where multiple hosts respond. These networks can the
subsequently be used as intermediaries in attacks.
For a more detailed description of the "smurf" attack, please consult this document:
"The Latest in Denial of Service Attacks: 'Smurfing':
Description and Information to Minimize Effects"
Author: Craig Huegen <chuegen@quadrunner.com>
URL: http://www.quadrunner.com/~chuegen/smurf.txt
II. Impact
Both the intermediary and victim of this attack may suffer degraded network performance both on
their internal networks or on their connection to the Internet. Performance may be degraded to the
point that the network cannot be used.
A significant enough stream of traffic can cause serious performance degradation for small and
mid-level ISPs that supply service to the intermediaries or victims. Larger ISPs may see backbone
degradation and peering saturation.
III. Solution
A.Solutions for the Intermediary
1.Disable IP-directed broadcasts at your router.
One solution to prevent your site from being used as an intermediary in this attack
is to disable IP-directed broadcasts at your router. By disabling these broadcasts,
you configure your router to deny IP broadcast traffic onto your network from other
networks. In almost all cases, IP-directed broadcast functionality is not needed.
Appendix A contains details on how to disable IP-directed broadcasts for some
router vendors. If your vendor is not listed, contact that vendor for instructions.
You should disable IP-directed broadcasts on all of your routers. It is not sufficient
to disable IP-directed broadcasts only on the router(s) used for your external
network connectivity. For example, if you have five routers connecting ten LANs at
your site, you should turn off IP-directed broadcasts on all five routers.
2.Configure your operating system to prevent the
machine from responding to ICMP packets sent to IP
broadcast addresses.
If an intruder compromises a machine on your network, the intruder may try to
launch a smurf attack from your network using you as an intermediary. In this case,
the intruder would use the compromised machine to send the ICMP echo request
packet to the IP broadcast address of the local network. Since this traffic does not
travel through a router to reach the machines on the local network, disabling
IP-directed broadcasts on your routers is not sufficient to prevent this attack.
Some operating systems can be configured to prevent the machine from responding
to ICMP packets sent to IP broadcast addresses. Configuring machines so that
they do not respond to these packets can prevent your machines from being used
as intermediaries in this type of attack.
Appendix A also contains details on how to disable responding to ICMP packets
sent to IP broadcast addresses on some operating systems. If your operating
system is not listed, contact your vendor for instructions.
B.Solutions for the Victim
Unfortunately, there is no easy solution for victims receiving the potentially large number of
ICMP echo reply packets. ICMP echo reply traffic (the traffic from the intermediary) could
be blocked at the victim's router; however, that will not necessarily prevent congestion that
occurs between the victim's router and the victim's Internet service provider. Victims
receiving this traffic may need to consult with their Internet service provider to temporarily
block this type of traffic in the ISP's network.
Additionally, victims in this position should contact the intermediaries and inform them of
the attack and of the steps described in the previous section. (Please refer them to
http://www.cert.org/nav/alerts.html or ftp://ftp.cert.org/pub/cert_advisories/ for the most
recent version of this advisory.)
Victims can use the "whois" command to obtain contact information for the sites. More
information on using whois is available in
ftp://ftp.cert.org/pub/whois_how_to
C.Solution for the Site Where Attacks Originate
We recommend filtering outgoing packets that contain a source address from a different
network.
Attacks like the smurf attack rely on the use of forged packets, that is, packets for which
the attacker deliberately falsifies the origin address. With the current IP protocol
technology, it is impossible to eliminate IP-spoofed packets. However, you can use filtering
to reduce the likelihood of your site's networks being used to initiate forged packets.
As we mentioned in CERT advisory CA-97.28 on Teardrop and Land denial-of-service
attacks, the best current method to reduce the number of IP-spoofed packets exiting your
network is to install filtering on your routers that requires packets leaving your network to
have a source address from your internal network. This type of filter prevents a source
IP-spoofing attack from your site by filtering all outgoing packets that contain a source
address from a different network.
A detailed description of this type of filtering is available in RFC 2267, "Network Ingress
Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing"
by Paul Ferguson of Cisco Systems, Inc. and Daniel Senie of Blazenet, Inc. We
recommend it to both Internet Service Providers and sites that manage their own routers.
The document is currently available at
ftp://ftp.isi.edu/in-notes/rfc2267.txt
Appendix A - Vendor Information
Below is a list of the vendors who have provided information for this advisory. We will update this
appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC
did not hear from that vendor. Please contact the vendor directly.
Cray Research - A Silicon Graphics Company
Current versions of Unicos and Unicos/mk do not have the ability to reject ICMP requests send to
broadcast addresses. We are tracking this problem through SPR 709733.
Cisco Systems
Cisco recommends the following configuration settings as protection against being used as an
intermediary in smurf attacks:
1.Disabling IP directed broadcast for all interfaces on which it is not needed. This must be
done on all routers in the network, not just on the border routers. The command "no ip
directed-broadcast" should be applied to each interface on which directed broadcasts are
to be disabled.
Very few IP applications actually need to use directed broadcasts, and it's extremely rare
for such an application to be in use in a network without the knowledge of the network
administrator. Nonetheless, as when any functionality is disabled, you should be alert for
possible problems.
This is the preferred solution for most networks.
2.If your network configuration is simple enough for you to create and maintain a list of all the
directed broadcast addresses in your network, and if you have a well-defined perimeter
separating your own network from potentially hostile networks, consider using a filter at the
perimeter to prevent directed broadcasts from entering the network. For example, if your
network number is 172.16.0.0, and you uniformly use a subnet mask of 255.255.255.0,
then you might use Cisco access list entries like
access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.255 0.0.255.0
access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.0 0.0.255.0
Note that this is not a complete access list; it's simply two entries. See the Cisco
documentation for more information on configuring access lists. The best place to apply
such a filter is usually on the incoming side of each router interface that connects to the
potentially hostile network.
This solution may be administratively infeasible for networks using variable-length subnet
masks, or which have complex external connectivity. There is also some possibility that
legitimate directed broadcasts may be being sent into your network from the outside,
especially if you're working in a research environment.
In addition to these protections against being used as an intermediary in a smurf attack, Cisco
recommends that you take steps to prevent users within your own network from launching such
attacks. For "stub" networks which do not provide transit connectivity (most corporate and
institutional networks, many smaller ISPs), this is usually best done by installing filters at the
network perimeter to prevent any packets from leaving your network unless their IP source
addresses actually lie within your network's address space. For the example network above, you
might place the following entry in the incoming access lists on the interface(s) facing your internal
network:
access-list 101 permit ip 172.16.0.0 0.0.255.255 0.0.0.0 255.255.255.255
access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
Data General Corporation
DG/UX has an option to enable/disable the forwarding of IP broadcast packets. It is disabled by
default. This means that if DG/UX is used along the path, it will not forward the attack packets.
DG/UX B2 with Security Option has a 'netctrl' facility which enables the administrator to disable
the response to a broadcast ICMP ping message.
DIGITAL EQUIPMENT CORPORATION
Currently DIGITAL products do not deny individual ICMP service to a host. That, outside the
intranet, firewalls should protect from this kind of spoof/attack.
If the problem has to be dealt with inside the firewall and the intranet, then policy should address
"malicious acts"and the individuals responsible.
FreeBSD, Inc.
In FreeBSD 2.2.5 and up, the tcp/ip stack does not respond to icmp echo requests destined to
broadcast and multicast addresses by default. This behaviour can be changed via the sysctl
command via mib net.inet.icmp.bmcastecho.
IBM Corporation
AIX 4
There is a network attribute called "bcastping" that controls whether or not responses to ICMP
echo packets to the broadcast address are allowed. A value of zero turns off responses and a
value of one turns them on. The default is zero (i.e., by default AIX version 4 is not vulnerable to
the described denial-of-service attack).
Use the following command to check the value of the bcastping attribute:
$ no -o bcastping
Use the following command to turn off responses to ICMP broadcast packets (as root):
# no -o bcastping=0
AIX 3
The "bcastping" attribute does not exist in version 3.
IBM and AIX are registered trademarks of International Business Machines Corporation.
Livingston Enterprises, Inc.
Livingston Enterprises products don't respond to ICMP packets not sent to their own address, but
do forward them. They're currently examining the problem to see what kind of solution they can
provide.
The NetBSD Project
Under NetBSD you can disable forwarding of directed broadcast packets with this command, as
root:
# sysctl -w net.inet.ip.directed-broadcast=0
NetBSD will always respond to broadcast ICMP packets. In the future, NetBSD may allow this to
be disabled.
Sun Microsystems
To prevent incoming broadcast packets from entering your network (III. A. 1. in this advisory)
Solaris 2.6, 2.5.1, 2.5, 2.4, and 2.3:
Use the command: ndd -set /dev/ip ip_forward_directed_broadcasts 0
SunOS 4.1.3_U1 and 4.1.4:
Do the following:
Add ``options DIRECTED_BROADCAST=0'' to system configuration
file and rebuild kernel
To prevent systems from responding to broadcast ICMP packets (III. A. 2. in this advisory)
Solaris 2.6, 2.5.1, 2.5, 2.4, and 2.3:
Use the command: ndd -set /dev/ip ip_respond_to_echo_broadcast 0
A corresponding variable for ip_respond_to_echo_broadcast does not exist in SunOS 4.1.x.
The CERT Coordination Center thanks Craig A. Huegen. Much of the content in this advisory has
been derived from his document on "smurf" attacks. The CERT Coordination Center also thanks
Paul Ferguson and Daniel Senie for providing information on network ingress filtering, and John
Bashinski of Cisco for his contributions.
If you believe that your system has been compromised, contact the CERT Coordination Center or
your representative in the Forum of Incident Response and Security Teams (see
http://www.first.org/team-info/)
CERT/CC Contact Information
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for
emergencies during other hours.
Fax +1 412-268-6989
Postal address:
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can support a shared
DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send email to
cert-advisory-request@cert.org
In the subject line, type
SUBSCRIBE your-email-address
Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorhsip
information can be found in http://www.cert.org/legal_stuff/legal_stuff.html and
ftp://ftp.cert.org/pub/legal_stuff. If you do not have FTP or web access, send mail to cert@cert.org
with "copyright" in the subject line.
CERT is registered in the U.S. Patent and Trademark Office.
Revision history
Aug. 24, 1998 Updated vendor information for Data General Corporation.
Aug. 14, 1998 Updated vendor information for Sun Microsystems.
Apr. 28, 1998 Updated vendor information for Cisco Systems and
Sun Microsystems.
Corrected URL for obtaining RFCs
Apr. 10, 1998 Updated vendor information for Cisco Systems
Feb. 10, 1998 Updates to Appendix A - Vendor Information
Jan. 29, 1998 Updated reference to the filtering document (now an RFC) in
Section III-C.
Jan. 13, 1998 Updated vendor information for NetBSD.
Jan. 7, 1998 Updated or added vendor information for Digital Equipment Corporation
and Livingston Enterprises, Inc.
