At 23:49 09.09.97 +0400, Basil Dolmatov wrote:
>> éÎÔÅÒÅÓÎÏ ?
>>
>>
>îÅ ÒÅÚÏÌ×ÉÔÓÑ ÞÔÏ-ÔÏ... íÏÖÅÔ ÓÁÍ ÔÅËÓÔ ÓÀÄÁ?
SMURF ATTACK INFORMATION -- METHODOLOGY AND PREVENTION INFORMATION
FOR THE NETWORK LEVEL
Craig A. Huegen <c-huegen@quadrunner.com>
Tue Sep 9 21:40:59 PDT 1997
(Note: This paper is really *still* under construction. I'm going to be
adding a few more pieces; namely, there will be a section on how to trace
an attack while it is going on. This is the #1 question I'm receiving
regarding this paper.)
Editor's plea: *please* distribute this information to other engineers
you know of. It's important that these attacks be minimized.
The guidelines here provides in-depth information for Cisco routers in the
prevention of Smurf attacks. Some information is general, however, it is
written with a strict Cisco router focus. No confirmation has been
made to the effects on other routers. The only testing I have performed is
listed below, on Cisco equuipment. I am attempting to collect some
information from other colleagues who are willing to put other vendors'
boxes through the test.
DESCRIPTION:
The "smurf" attack, named after its exploit program, is the most recent
in the category of network-level attacks against hosts. A perpetrator
sends a large amount of ICMP echo (ping) traffic at 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.
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 "helpers", and the spoofed address
target, or the "victim". The victim is the target of a large amount of
traffic that the helpers 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 "helper". These ping packets hit the
helper's broadcast network of 100 hosts; each of them takes the packet
and responds to it, creating 100 ping replies outbound. If you multiply
the bandwidth, you'll see that 76.8 Mbps is used outbound from the
"helper" after the traffic is multiplied. This is then sent to the victim
(the spoofed source of the originating packets).
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). The RFC for
routing states that a router MAY perform this translation for directed
broadcasts. Because in a few select cases it is desirable (NetBIOS over
IP with no central WINS server is one example--remote broadcasting),
most vendors have chosen to implement this feature. Generally, with
IP providers and the Internet as we know it today, this behavior should
not be needed.
(Editor's note: I welcome other examples where this is needed.)
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. In this case, a device will take the
packet and send an interrupt for processing.
Because most host IP stacks pay little attention to the IP header of an ICMP
packet, or (if they check the IP header for ICMP) implement responding
to ICMP broadcasts, the packet is handed to the ICMP layer, where in the
case of smurf attacks, an ICMP echo reply is prepared and shipped out to
the spoofed address source of the packet--the victim.
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 all routers which
provide routing to large multi-access broadcast networks (generally LANs),
with more than 5-10 devices. It is unnecessary on point-to-point interfaces,
such as POS, serial T1, HSSI, etc. No testing has been done on
multipoint frame-relay; however, since it is a multi-access network,
it should behave just like a LAN. Point-to-point sub-interface models
will behave like many point-to-point links--again, this command really
isn't needed there.
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.
(Again, editor's note: Know of any more applications where this would
break in today's world? Mail me, see below...)
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 Mbits/sec 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 Kbits/sec
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 Mbit/sec 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.
(This next section assumes IOS behavior with standard central switching--
FIB/CEF isn't covered here, the behavior is different, I believe.)
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, or if the router has to generate packets from itself. 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
sent 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), 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 unreachables. 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 is coming in the near future, so that the source
interface and MAC address of a particular attack can be identified at the
interrupt level as well.
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.
This is very new code, and the only release it is currently integrated in
is 11.1(13.5)CA, a maintenance interim release. Future releases of 11.1CA
will contain this fix. Efforts are underway to integrate this in the
other major versions and branches as well.
ADDITIONAL INFO:
CPU impact:
I tested this in the lab, by generating 75-80 Mbps of traffic @ 33-37k pps
destined for a host behind the router. An access-list specifically denied
icmp echo replies to that host.
The router was a 7505 with RSP1. It had cyBus FEIPs in slot 0 and 1.
Traffic came in from Fast0/0 and was destined for a host on Fast1/0. At
35k pps / 80 Mbps, CPU load remained at approximately 30-35% while dropping
the packets.
Keep in mind that these performance numbers are preliminary. The traffic
load was not *exactly* the numbers stated above and were not meant to be a
controlled test. All numbers are approximate.
VIP controllers, CEF/FIB switching, RSP4, etc., will affect the CPU load.
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.
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.
/cah
My disclaimer: I'm speaking about this as an interested party only. I
do not speak for Cisco Systems. All research for this paper is being done
purely as a hobby.
Craig A. Huegen, <c-huegen@quadrunner.com>
Cheers,
Yuri
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@east.ru if you want to quit.
List archive is accessible at
