| By Craig A. Huegen |
Craig A. Huegen
chuegen@pentics.com
Last Update: Tue Feb 8 17:47:36 PST 2000
New additions:
* Removed "smurf update" section -- no longer valid given
distributed DoS
Editor's plea: *please* distribute this information freely,
and abide by
my redistribution requirements (see the very end) when
doing so. It's
important that these attacks be minimized, and communication
is the only
way to help with this.
OVERVIEW:
The information here provides in-depth information regarding
"smurf" and
"fraggle" attacks, with a focus on Cisco
routers and how to reduce the
effects of the attack. Some information is general and
not related to an
organization's particular vendor of choice; however, it
is written with a
Cisco router focus. No confirmation has been made to
the effects on other
vendors' equipment; however, others have provided me with
information for
various vendors, which is provided in the document. See
the
"Acknowledgements" section below for the sources
and contact information.
I am happy to accept information from other colleagues
or other vendors
who are willing to provide information about other vendors'
products in
relation to this topic.
This paper is always being updated as I receive more information
about
attacks and work with ways to minimize impact.
DESCRIPTION:
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 it 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 potentially
be hundreds of machines to 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 was a simple
re-write of "smurf".
Currently, the providers/machines most commonly hit are
IRC servers and
their providers.
There are two parties who 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).
HOW TO DETERMINE IF YOUR NETWORK IS VULNERABLE:
Several sites have been established to do both active
and passive scanning
of networks to determine whether or not directed-broadcast
is enabled.
http://www.netscan.org/
is a site which actively scans the IPv4 address
space and mails network contacts with information on how
to disable them.
http://www.powertech.no/smurf/
is a site which will test scan your
network and allow you to enter a known smurf amplifier
site.
HOW TO KEEP YOUR SITE FROM BEING
THE SOURCE
PERPETRATORS USE TO
ATTACK VICTIMS:
The perpetrators of these attacks rely on the ability
to source spoofed
packets to the "amplifiers" in order to generate the traffic
which causes
the denial of service.
In order to stop this, all networks should perform filtering
either at the
edge of the network where customers connect (access layer)
or at the edge
of the network with connections to the upstream providers,
in order to
defeat the possibility of source-address-spoofed packets
from entering
from downstream networks, or leaving for upstream networks.
Paul Ferguson of cisco Systems and Daniel Senie of BlazeNet
have written
an RFC pertaining to this topic. See:
ftp://ftp.isi.edu/in-notes/rfc2267.txt
for more information and examples on this subject.
Additionally, router vendors have added or are currently
adding options
to turn off the ability to spoof IP source addresses
by checking the
source address of a packet against the routing table to
ensure the return
path of the packet is through the interface it was received
on.
Cisco has added this feature to the current 11.1CC branch,
used by many
NSP's, in an interface command '[no] ip verify unicast
reverse-path'.
See the "other vendors" section for 3Com information regarding
this feature.
HOW TO STOP BEING AN
INTERMEDIARY:
This attack relies on the router serving a large multi-access
broadcast
network to frame an IP broadcast address (such as 10.255.255.255)
into a
layer 2 broadcast frame (for Ethernet, FF:FF:FF:FF:FF:FF).
RFC 1812,
"Requirements for IP Version 4 Routers",
Section 5.3.5, specifies:
---
A router MAY have an option to disable receiving network-prefix-
directed broadcasts on an interface and MUST have
an option to
disable forwarding network-prefix-directed
broadcasts. These options
MUST default to permit
receiving and forwarding network-prefix-
directed
broadcasts.
---
Generally, with IP providers and IP applications as we
know them today,
this behavior should not be needed, and it is recommended
that
directed-broadcasts be turned off, to suppress the effects
of this attack.
RFC 2644, a Best Current Practice RFC by Daniel Senie,
updates RFC 1812
to state that router software must default to denying
the forwarding
and receipt of directed broadcasts.
Ethernet NIC hardware (MAC-layer hardware, specifically)
will only listen
to a select number of addresses in normal operation.
The one MAC address
that all devices share in common in normal operation is
the media
broadcast, or FF:FF:FF:FF:FF:FF. If a device receives
a packet destined
to the broadcast link-layer address, it will take the
packet and send an
interrupt for processing by the higher-layer routines.
To stop your Cisco router from converting these layer
3 broadcasts into
layer 2 broadcasts, use the "no ip directed-broadcast"
interface
configuration command. This should be configured on each
interface of all
routers.
As of Cisco IOS version 12.0, "no ip directed-broadcast"
is now the default
in order to protect networks by default. "ip directed-broadcast"
will be
needed if your network requires directed broadcasts to
be enabled.
Other vendor information:
* Proteon/OpenROUTE:
Daniel Senie ( dts@senie.com
) reports that Proteon/OpenROUTE Networks
routers
have an option to turn off directed broadcasts in the
IP
Configuration menus. The command sequence to
turn them off is:
*CONFIG (on newer routers) or
TALK 6 (on older routers)
Config>PROTOCOL IP
IP Config>DISABLE DIRECTED-BROADCAST
A restart of the router is then required.
* Nortel Networks (Bay Networks):
Jon Green ( jcgreen@netins.net
) reports that bugID CR33408 added the
ability
to disable network-directed broadcasts beginning in version
12.01 rev 1 of BayRS code.
To disable, enter:
[1:1]$bcc
bcc> config
hostname#
ip
ip# set directed-bcast disabled
ip# exit
Note that this will bounce all IP interfaces.
Greg Hankins ( ghankins@mindspring.net
) reports that in BayRS 13.01
and later, directed-broadcast
is disabled by default.
Tim Winders ( twinders@SPC.cc.tx.us
) mentions that if you upgrade
to BayRS 13.01+
from 12.01, directed-broadcasts are not disabled.
* 3Com NETBuilder products:
Mike Kouri (Mike_ Kouri@3com.com
) reports that all 3Com NETBuilders have
an
option to keep the router from forwarding the directed
broadcasts.
The command sequence to disable the
forwarding is:
SETDefault -IP CONTrol = NoFwdSubnetBcast
Additionally, 3Com NETBuilder products running
version 9.1 or later can
be configured to discard
source-spoofed packets:
SETDefault !port -FireWall
CONTrol = (Filter, DenySrcSpoofing)
3Com states
in the web page (listed below) that this command
"Specifies whether packets are subject to source-spoofing
checks. This is a
CPU-intensive option and generally
results in performance degradation. You
should
disable this option except on interfaces where external,
untrusted
traffic is received. The source address
of incoming packets is checked
against the routing
table. If the routing information shows that the
source address is unreachable, or reachable on different
interfaces,
then it is a SrcSpoofing attack."
* Lucent (Ascend):
Will Pierce ( willp@dreamscape.com
) reports that on Maxes or Pipelines
running
TAOS 6.0.0 or higher, you can go to the Ethernet->Mod
Config menu
and set both "Reply DirectedBcast Ping"
and "Forward Directed Bcast" to
"No". For the
Max TNT, there is an example at
ftp://ftp.ascend.com/pub/Software-Releases/MaxTNT/Release-2.0.X/2.0.0/doc/tnt20.pdf
on page 40. TNT versions 2.0.0 and higher
support this.
* Cabletron SmartSwitch Router (Yago/SSR):
Greg
Hankins ( ghankins@mindspring.net
) reports directed-broadcast is
disabled by
default, and can be enabled by entering the global command
"ip enable directed-broadcast".
* Foundry Networks:
Greg Hankins ( ghankins@mindspring.net
) reports that hardware running
Foundry's routing
software can be configured to disable
directed-broadcasts
with the global or per-interface "no ip
directed-broadcast"
command.
* Redback Networks:
Justin Streiner ( streiner@stargate.net
) reports that on the SMS-500
and SMS-1000
access switches, there is no support for directed
broadcasts unless used in conjunction with DHCP, and
they are not
forwarded by default.
* Extreme Networks:
Aurobindo Sundaram ( sundaram@austin.apc.slb.com
) reports that you
can disable IP broadcast
forwarding on Extreme's Summit 1 switches
by using
the following commands:
disable ipforwarding broadcast
all
disable ipforwarding broadcast vlan vlan-name
* ArrowPoint Communications:
Greg Hankins ( ghankins@mindspring.net
) reports that directed-broadcasts
can be disabled
by using the "no ip subnet-broadcast" global
configuration
command.
* SGI IRIX as a router:
Mike O'Connor ( mjo@dojo.mi.org
) reports that IRIX has been configured
by
default to not forward the directed-broadcasts when used
as a router.
The tunable for this is in /var/sysgen/master.d/bsd.
There is one case study where this will stop intended
behavior: In the
case where samba (an SMB server for UNIX) or NT is used
to "remote
broadcast" into a LAN workgroup so that the workstations
on that LAN can
see the server, this will prevent the LAN machines from
seeing the remote
server. This is *only* in the case where there is no
WINS server (WINS is
routed unicast) and a "remote broadcast" is being used--it's
a rare but
notable condition.
(Editor's note: I welcome any comments as to what else
breaks without
the support for directed-broadcast.)
Additionally, hosts can be patched to refuse to respond
to broadcasted
ICMP echo packets. RFC 1122, "Requirements for Internet
Hosts --
Communications Layer", Section 3.2.2.6, states:
---
An ICMP Echo Request destined
to an IP broadcast or IP
multicast address MAY
be silently discarded.
DISCUSSION:
This neutral provision results from
a passionate debate
between those who feel
that ICMP Echo to a broadcast
address provides
a valuable diagnostic capability and
those
who feel that misuse of this feature can too
easily create packet storms.
---
Because of this, most IP stack implementors have chosen
to implement the
default support provision, which is to reply to an ICMP
Echo Request.
As mentioned in the paragraph from the RFC (above), it
is perfectly legal
for a host to silently discard ICMP echos. Several patches
have been
found floating about in mailing lists for disabling response
to broadcast
ICMP echos for the freely-available UNIX systems.
In the case of the smurf or fraggle attack, each host
which supports this
behavior on a broadcast LAN will happily reply with an
ICMP or UDP (smurf
or fraggle, respectively) echo-reply packet toward the
spoofed source
address, the victim.
The following section contains information to configure
hosts *not* to
respond to ICMP echo requests to broadcast addresses.
IBM has provided a setting in AIX 4.x to disable responses
to broadcast
addresses. It is not available in AIX 3.x. Use the "no"
command to turn
it off or on. NOTE: On AIX 4.x responses are DISABLED
by default.
no -o bcastping=0 # disable
bcast ping responses (default)
Solaris can be set not to respond to ICMP echo requests.
Add the
following line to your /etc/rc2.d/S69inet startup:
ndd -set /dev/ip ip_respond_to_echo_broadcast
0
If you're using Solaris as a router, you can configure
it not to
forward directed broadcasts by placing the following line
in
your /etc/rc2.d/S69inet startup:
ndd -set /dev/ip ip_forward_directed_broadcasts 0
Starting with version 2.2.5, FreeBSD's IP stack does not
respond to icmp
echo requests destined to broadcast and multicast addresses
by default.
The sysctl parameter for this functionality is net.inet.icmp.bmcastecho.
Beginning with version 3.x, FreeBSD makes this option
configurable in
the /etc/rc.conf file with an option under the miscellaneous
network
configuration section.
Under NetBSD, directed broadcasts can be disabled by using
the sysctl
command:
sysctl -w net.inet.ip.directed-broadcast=0
Under Linux, one can use the CONFIG_IP_IGNORE_ECHO_REQUESTS
variable to
completely ignore ICMP echo requests. Of course, this
violates RFC 1122.
"ipfw" can be used from Linux
to block broadcast echos, a la:
Any system with ipfw can be protected by adding rules
such as:
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)
To protect a host against "fraggle" attacks on most UNIX
machines, one
should comment the lines which begin with "echo" and "chargen"
in
/etc/inetd.conf and restart inetd.
INFORMATION
FOR VICTIMS AND HOW TO SUPPRESS ATTACKS:
The amount of bandwidth and packets per second (pps) that
can be generated
by this attack is quite large. With a 200-host LAN, I
was able to
generate over 80 Mbps traffic at around 35 Kpps toward
my target--a
pretty significant amount. The victims receive this because
traffic is
multiplied by the number of hosts on the broadcast network
used (in this
case, with a 200-host network, I was only required to
send 400 Kbps
to the broadcast address--less than one-third of a T1).
Many hosts cannot process this many packets per second;
many hosts are
connected to 10 Mbps Ethernet LANs where more traffic
than wire speed
is sent. Therefore, the ability to drop these packets
at the network
border, or even before it flows down the ingress pipes,
is desired.
Cisco routers have several "paths" which packets can take
to be routed;
each has a varying degree of overhead. The slowest of
these is "process"
switching. This is used when a complex task is required
for processing
packets. The other modes are variations of a fast path--each
of them with
a set of advantages and disadvantages. However, they're
all handled at
interrupt level (no process-level time is required to
push these packets).
In IOS versions (even the most recent), access-list denies
are handled at
the process (slow) level, because they require an ICMP
unreachable to be
generated to the originating host. All packets were sent
to the process
level automatically to be handled this way.
Under a recent code change (Cisco bug ID CSCdj35407--integrated
in version
11.1(14)CA and later 11.1CA, 11.1CC, 11.1CE, and 12.0
trains), packets
denied by an access-list will be dropped at the interrupt
(fast) level, with
the exception of 2 packets per second per access-list
deny line. These 2
packets per second will be used to send the "ICMP unreachable
via
administrative block" messages. This assumes that you
don't want to log
the access-list violations (via the "log" or "log-input"
keywords). The
ability to rate-limit "log-input" access-list lines (in
order to more
easily log these packets) is currently being integrated;
see the section
below on tracing spoofed packet attacks for information
on logging.
Filtering ICMP echo reply packets destined for your high-profile
machines
at the ingress interfaces of the network border routers
will then permit
the packets to be dropped at the earliest possible point.
However, it
does not mean that the network access pipes won't fill,
as the packets
will still come down the pipe to be dropped at the router.
It will,
however, take the load off the system being attacked.
Keep in mind that
this also denies others from being able to ping from that
machine (the
replies will never reach the machine).
For those customers of providers who use Cisco, this may
give you some
leverage with the providers' security teams to help save
your pipes by
filtering before the traffic is sent to you.
An additional technology you can use to protect your machines
is to use
committed access rate, or CAR. CAR is a functionality
that works
with Cisco Express Forwarding, found in 11.1CC, 11.1CE,
and 12.0. It
allows network operators to limit certain types of traffic
to specific
sources and/or destinations.
For example, a provider has filtered its IRC server from
receiving
ICMP echo-reply packets in order to protect it, but many
attackers are
now attacking other customer machines or network devices
in order to
fill some network segments.
The provider above chose to use CAR in order to limit
all ICMP echo
and echo-reply traffic received at the borders to 256
Kbps. An example
follows:
! traffic we want to limit
access-list 102 permit icmp any any echo
access-list 102 permit icmp any any echo-reply
! interface configurations for borders
interface Serial3/0/0
rate-limit input access-group 102 256000 8000 8000 conform-action
transmit exceed-action drop
This limits ICMP echo and echo-reply traffic to 256 Kbps
with a small
amount of burst. Multiple "rate-limit" commands can be
added to an
interface in order to control other kinds of traffic as
well.
The command "show interface [interface-name] rate-limit"
will show the
statistics for rate-limiting; "clear counters [interface-name]"
will
clear the statistics for a fresh look.
CAR can also be used to limit TCP SYN floods to particular
hosts --
without impeding existing connections. Some attackers
have started
using very high streams of TCP SYN packets in order to
harm systems
once again.
Here is an example which limits TCP SYN packets directed
at host
10.0.0.1 to 8 kbps or so:
! We don't want to limit established TCP sessions -- non-SYN
packets
access-list 103 deny tcp any host 10.0.0.1 established
! We do want to limit the rest of TCP (this really only
includes SYNs)
access-list 103 permit tcp any host 10.0.0.1
! interface configurations for network borders
interface Serial3/0/0
rate-limit input access-group 103 8000 8000 8000 conform-action
transmit exceed-action drop
Currently, CAR is only available for 7200 and 7500 series
routers.
Additional platform support is planned in 12.0.
Additionally, CAR can be used to set IP precedence; this
is beyond
the scope of this paper. Consult www.cisco.com for more
information
on the uses of CAR.
TRACING SPOOFED
PACKET STREAMS:
Tracking these attacks can prove to be difficult, but
is possible with
coordination and cooperation from providers. This section
also assumes
Cisco routers, because I can speak only about the abilities
of Cisco to
log/filter packets and what impact it may have.
Today, logging packets which pass through or get dropped
in an ACL is
possible; however, all packets with the "log" or "log-input"
ACL options
are sent to process level for logging. For a large stream
of packets,
this could cause excessive CPU problems. For this reason,
tracking
attacks via IOS logging today is limited to either lower
bandwidth attacks
(smaller than 10k packets per second). Even then, the
number of log
messages generated by the router could overload a syslog
server.
Cisco bug ID CSCdj35856 addresses this problem. It has
been integrated
into IOS version 11.1CA releases beginning with 11.1(14.1)CA
(a
maintenance interim release), and makes it possible to
log packets at
defined intervals and to process logged packets not at
that interval in
the fast path. I will update this page with version numbers
as the
releases are integrated.
Some information on logging:
In later 11.1 versions, a new keyword was introduced for
ACL logging:
"log-input". A formatted ACL line utilizing
the keyword looks like this:
access-list 101 permit icmp any any echo log-input
When applied to an interface, this line will log all ICMP
ping packets
with input interface and MAC address (for multi-access
networks).
Point-to-point interfaces will not have a MAC address
listed.
Here's an example of the log entry for a multi-access
network (FDDI, Ether):
Sep 10 23:17:01 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted
icmp
10.0.7.30 (FastEthernet1/0 0060.3e2f.6e41) -> 10.30.248.3
(8/0), 5 packets
Here's an example of the log entry for a point-to-point
network:
Sep 10 23:29:00 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted
icmp
10.0.7.30 (BRI0 *PPP*) -> 10.0.19.242 (8/0), 1 packet
Substituting "log" for "log-input" will eliminate the
incoming interface
and MAC address from the log messages.
We'll use the first log entry to demonstrate how to go
from here. This
log entry means the packet came in on FastEthernet1/0,
from MAC address
0060.3e2f.6e41, destined for 10.30.248.3. From here,
you can use "show ip
arp" (if needed) to determine the IP address for the MAC
address, and go
to the next hop for tracing or contact the necessary peer
(in the case of
an exchange point). This is a hop-by-hop tracing method.
Example of "show ip arp" used to find next hop:
netlab#show ip arp 0060.3e2f.6e41
Protocol Address Age (min) Hardware Addr
Type Interface
Internet 10.0.183.65 32 0060.3e2f.6e41
ARPA FastEthernet1/0
As you can see, 10.0.183.65 is the next hop where the
packets came from
and we should go there to continue the tracing process,
utilizing the same
ACL method. By doing this, you can track the spoof attack
backwards.
While this is general information on tracking spoofed
packets, it must be
noted that the victims of a smurf/fraggle attack get packets
from the listed
source in the packets; i.e., they receive echo-reply packets
truly from the
source listed in the IP header. This information should
be used by the
amplifiers or intermediaries to track the spoofed echo
_request_ packets
back to their source (the perpetrator).
OTHER
DENIAL OF SERVICE ATTACKS WORTHY OF MENTION:
Two other denial of service attacks frequently encountered
are TCP SYN
floods, and UDP floods aimed at diagnostic ports on hosts.
TCP SYN attacks consist of a large number of spoofed TCP
connection set-up
messages aimed at a particular service on a host. Older
TCP
implementations cannot handle many faked connection set-up
packets, and
will not allow access to the victim service.
The most common form of UDP flooding directed at harming
networks is an
attack consisting of a large number of spoofed UDP packets
aimed at
diagnostic ports on network devices. This attack is also
known as the
"pepsi" attack (again named after the
exploit program), and can cause
network devices to use up a large amount of CPU time responding
to these
packets.
To get more information on minimizing the effects of these
two attacks,
see:
Defining Strategies to Protect Against TCP SYN
Denial of Service Attacks
http://cio.cisco.com/warp/public/707/4.html
Defining Strategies to Protect Against UDP Diagnostic
Port DoS Attacks
http://cio.cisco.com/warp/public/707/3.html
PERFORMANCE INFORMATION:
One ISP has reported that, spread across three routers
(2 RSP2 and 1
RSP4), the fast drop code eliminated a sustained 120 Mbps
smurf
attack and kept the network running without performance
problems.
As always, your mileage may vary.
ACKNOWLEDGEMENTS:
Thanks to all those who helped review and provide input
to the paper, as
well as sanity checking.
Referenced documents:
RFC-1122, "Requirements for Internet Hosts - Communication
Layers";
R.T. Braden; October 1989.
RFC-1812, "Requirements for IP Version 4 Routers"; F.
Baker; June 1995.
RFC-2267, "Network Ingress Filtering: Defeating Denial
of Service Attacks
which employ IP Source Address
Spoofing"; P. Ferguson, D. Senie;
January 1998.
RFC-2644, "Changing the Default for Directed Broadcasts
in Routers";
D. Senie; August 1999.
Defining Strategies to Protect Against TCP SYN
Denial of Service Attacks
http://cio.cisco.com/warp/public/707/4.html
Defining Strategies to Protect Against UDP Diagnostic
Port DoS Attacks
http://cio.cisco.com/warp/public/707/3.html
Cisco command documention to turn off directed broadcasts
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/cs/csprtn1/csipadr.htm#xtocid748113
3Com command documentation to turn off directed broadcasts
http://infodeli.3com.com/infodeli/tools/bridrout/u_guides/html/nb101/family/REF/ip4.htm#190
3Com command documentation to disable source spoofing
http://infodeli.3com.com/infodeli/tools/bridrout/u_guides/html/nb101/family/REF/firewal3.htm#1823
PERMISSION TO DUPLICATE:
Permission to duplicate this information is granted under
these terms:
1. My name and e-mail address remains on the information
as a target for
questions and identification
of the source
2. My disclaimer appears on the information at the bottom
3. Feel free to add extra information from other discussions,
etc., but
please ensure the correct attribution
is made to the author. Also
provide Craig Huegen
( chuegen@pentics.com
) a copy of your additions.
4. Please help disseminate this information to other
network
administrators who are affected by these
attacks.
If you have questions, I will be happy to answer them
to the best of my
knowledge.
MY DISCLAIMER:
I'm speaking about this as an interested party only.
All text in this
paper was written by me; I speak/write for no one but
myself. No vendors
have officially confirmed/denied any of the information
contained herein.
All research for this paper is being done purely as a
matter of
self-interest and desire to help others minimize effects
of this attack.
Craig A. Huegen
chuegen@pentics.com
http://www.pentics.net/denial-of-service/white-papers/smurf.txt
|
|
