Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

   


   


   















      :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[inet-admins] [CISCO SMURF attack information]



 , .
-- 
   (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
   http://www.Global-one.co.za/~dek             cell  +27 (0)82-880-4706

-- BEGIN included message

> 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
   http://www.Global-one.co.za/~dek             cell  +27 (0)82-880-4706

-- END included message



 




Copyright © Lexa Software, 1996-2009.