Original issue date: January 5, 1998<BR>
Last revised: March 13, 2000<BR>
Added pointer to <a href="ftp://ftp.isi.edu/in-notes/rfc2644.txt">RFC2644/BCP34</a>.
<P>A complete revision history is at the end of this file.
<P>This advisory is intended primarily for network administrators
responsible for router configuration and maintenance.
<P>The attack described in this advisory is different from the
denial-of-service attacks described in CERT advisory
<A HREF="http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html">CA-97.28</A>.
<P>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."
<P>The CERT/CC urges you to take the steps described in
<A HREF="#III">Section III</A> to reduce the potential that your site can be
used as the origination site (<A HREF="#IIIc">Sec. III.C</A>) or an
intermediary (<A HREF="#IIIa">Sec. III.A.</A>) in this
attack. Although there is no easy solution for victim sites, we
provide some recommendations in <A HREF="#IIIb">Sec. III.B.</A>
<P>We will update this advisory as we receive additional
information. Please check our advisory files regularly for updates
that relate to your site.
<P><HR>
<P>
<H1>I. Description</H1>
<P>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.
<P>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.
<P>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).
<P>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.
<P>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).
<P>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.
<P>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.
<P>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.
<P>For a more detailed description of the "smurf" attack, please
consult this document:
<P><UL>
"The Latest in Denial of Service Attacks: 'Smurfing':<BR>
Description and Information to Minimize Effects"<BR>
Author: Craig Huegen <<A HREF="mailto:chuegen@quadrunner.com">chuegen@quadrunner.com</A>><BR>
URLs: <A HREF="http://www.quadrunner.com/~chuegen/smurf.txt">http://www.quadrunner.com/~chuegen/smurf.txt</A> and <A HREF="http://users.quadrunner.com/chuegen/smurf.cgi">Smurfing: The Latest DoS Attack</A><BR>
<P></UL>
<H1>II. Impact</H1>
<P>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.
<P>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.
<P>
<A NAME="III"></A>
<H1>III. Solution</H1>
<P>
<A NAME="IIIa"></A>
<OL>
<H2><LI TYPE="A">Solutions for the Intermediary</H2>
<P>
<OL>
<H3><LI>Disable IP-directed broadcasts at your router.</H3>
<P>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.
<P>This network management best practice is described in more detail
in the following document authored by Daniel Senie of Amaranth
Networks Inc.:</P>
<DL><DD>
<a href="ftp://ftp.isi.edu/in-notes/rfc2644.txt">RFC2644/BCP34: Changing the Default for Directed Broadcasts in Routers</a>
</DL>
<P>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.
<P>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.
<P>
<H3><LI>Configure your operating system to prevent the machine from responding to ICMP packets sent to IP broadcast addresses.</H3>
<P>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.
<P>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.
<P>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.
<P></OL>
<A NAME="IIIb"></A>
<H2><LI>Solutions for the Victim</H2>
<P>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.
<P>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
<A HREF="http://www.cert.org/nav/alerts.html">
http://www.cert.org/nav/alerts.html</A>
or <A HREF="ftp://ftp.cert.org/pub/cert_advisories/">
ftp://ftp.cert.org/pub/cert_advisories/</A>
for the most recent version of this advisory.)
<P>Victims can use the "whois" command to obtain contact information
for the sites. More information on using whois is available in
<P>
<A HREF="ftp://ftp.cert.org/pub/whois_how_to">ftp://ftp.cert.org/pub/whois_how_to</A>
<P>
<A NAME="IIIc"></A>
<H2><LI>Solution for the Site Where Attacks Originate</H2>
<P>We recommend filtering outgoing packets that contain a source
address from a different network.
<P>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.
<P>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.
<P>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. We recommend it to both Internet
Service Providers and sites that manage their own routers. The
document is currently available at
<P>
<A HREF="ftp://ftp.isi.edu/in-notes/rfc2267.txt">
ftp://ftp.isi.edu/in-notes/rfc2267.txt</A>
<P>
Note this RFC is no longer considered just informational but has been
adopted as a Best Common Practice for network administrators as of
February, 2000.</P>
</OL>
<HR>
<P>
<H1>Appendix A - Vendor Information</H1>
<P>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.
<P>
<H4>Cray Research - A Silicon Graphics Company</H4>
<P>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.
<P>
<H4>Cisco Systems</H4>
<P>Cisco recommends the following configuration settings as protection
against being used as an intermediary in smurf attacks:
<P>
<OL><LI>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.
<P>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.
<P>This is the preferred solution for most networks.
<LI><P>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
<P><PRE>
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
</PRE>
<P>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.
<P>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.
<P></OL>
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:
<P><PRE>
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
</PRE>
<P>
<H4>Data General Corporation</H4>
<P>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.
<P>DG/UX B2 with Security Option has a 'netctrl' facility which
enables the administrator to disable the response to a broadcast ICMP
ping message.
<P>
<H4>DIGITAL EQUIPMENT CORPORATION</H4>
<P>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.
<P>If the problem has to be dealt with inside the firewall and the
intranet, then policy should address "malicious acts"and the
individuals responsible.
<P>
<H4>FreeBSD, Inc.</H4>
<P>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.
<P>
<H4>IBM Corporation</H4>
<P>
<B>AIX 4</B>
<P>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).
<P>Use the following command to check the value of the bcastping
attribute:
<P><PRE>
$ no -o bcastping
</PRE>
<P>Use the following command to turn off responses to ICMP broadcast
packets (as root):
<P><PRE>
# no -o bcastping=0
</PRE>
<P>
<B>AIX 3</B>
<P>The "bcastping" attribute does not exist in version 3.
<P>IBM and AIX are registered trademarks of International Business Machines
Corporation.
<P>
<H4>Livingston Enterprises, Inc.</H4>
<P>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.
<P>
<H4>The NetBSD Project</H4>
<P>Under NetBSD you can disable forwarding of directed broadcast
packets with this command, as root:
<P><PRE>
# sysctl -w net.inet.ip.directed-broadcast=0
</PRE>
<P>NetBSD will always respond to broadcast ICMP packets. In the
future, NetBSD may allow this to be disabled.
<P>
<H4>Sun Microsystems</H4>
<P>To prevent incoming broadcast packets from entering your network (III. A. 1. in this advisory)
<P>
<UL>Solaris 2.6, 2.5.1, 2.5, 2.4, and 2.3:
<P><PRE>Use the command: ndd -set /dev/ip ip_forward_directed_broadcasts 0</PRE>
<P>SunOS 4.1.3_U1 and 4.1.4:
<P>Do the following:
<PRE>Add ``options DIRECTED_BROADCAST=0'' to system configuration
file and rebuild kernel</PRE>
</UL>
<P>To prevent systems from responding to broadcast ICMP packets
(III. A. 2. in this advisory)
<P>
<UL>Solaris 2.6, 2.5.1, 2.5, 2.4, and 2.3:
<P><PRE>Use the command: ndd -set /dev/ip ip_respond_to_echo_broadcast 0</PRE>
<P>A corresponding variable for ip_respond_to_echo_broadcast does not
exist in SunOS 4.1.x.
<P>
</UL>
<HR>
<P>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.
<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>
<p>Copyright 1998 Carnegie Mellon University.</p>
<HR>
Revision History
<PRE>
Mar. 13, 2000 Added pointer to <a href="ftp://ftp.isi.edu/in-notes/rfc2644.txt">RFC2644/BCP34</a>.
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.
</PRE>
|