íÁÎÁ ×ÏÔ, ÓÉÎØÇÁ.
--
(KD1350) Dmitri E. Kalintsev
CDPlayer@irc Network engineer at Global One South Africa.
mailto:dek@Global-One.co.za phone: +27 (0)11 322-5628 fax: 322-5601
cell +27 (0)82-880-4706
> SMURF ATTACK INFORMATION -- METHODOLOGY AND PREVENTION INFORMATION
> FOR THE NETWORK LEVEL
> Craig A. Huegen <c-huegen@quadrunner.com>
> Thu Aug 28 15:22:31 PDT 1997
>
> 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. I have second-hand information
> regarding some brief testing on another platform, and information from a
> sales engineer for another platform. The only testing I have performed is
> listed below, on Cisco equuipment.
>
> 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 spoofed traffic at broadcast addresses, hoping
> their echo packets will be magnified and sent to the spoofed address.
> The providers/machines most commonly hit are IRC servers and 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 LAN 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 says 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.
>
> Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen
> to a select number of addresses in normal operation--promiscuous mode,
> or serving interrupts on all packets, isn't assumed here. 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 implement the "MAY" condition of 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 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 frame-relay; however, since it is
> a multi-access network, it should behave just like a LAN.
>
> 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.
>
> 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 point of entry
> is desired.
>
> (This next section assumes that you are using IOS in the mainline 11.1 or
> 11.2 branches or earlier. CEF/FIB switching, which is still in beta from
> Cisco, handles packets differently. It is not covered here.)
>
> 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 team to help save your pipes by
> filtering before the traffic is sent to you. Again, it is unknown
> (although I have second-hand information for some) how well other
> manufacturers' routers handle these attacks with filtering.
>
> This is very new code, and the only release it is currently integrated in
> is 11.1(13.5)CA, a maintenance interim release. 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%.
>
> 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.
>
> VIP controllers, CEF/FIB switching, RSP4, etc., will lower the CPU
> percentage number.
>
> 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
>
> (I am not speaking for Cisco in any way, shape, or form. I speak for
> myself only.)
>
> ----
> Craig A. Huegen, consultant <c-huegen@quadrunner.com>
> Cisco Certified Internetwork Expert, #2100
> Quadrunner Communications - Network and Systems Consulting
--
(KD1350) Dmitri E. Kalintsev
CDPlayer@irc Network engineer at Global One South Africa.
mailto:dek@Global-One.co.za phone: +27 (0)11 322-5628 fax: 322-5601
cell +27 (0)82-880-4706
