Network Operators and smurf
Karl Denninger
karl at mcs.net
Sun Apr 26 14:03:56 UTC 1998
Since I have started blacklisting people, the list has grown to more than 40
netwroks.
However, only ONE, and that one was very short (< 5 minutes) smurf has taken
down a customer circuit or our IRC server since the last edits were made to
the amplifier list over a week ago.
I'm going to try to post a web page on this tonight. What we're doing here
WORKS. It inconveniences a few people (those who amplify smurfs), but it
WORKS and it STOPS the smurf attacks from burying your connections.
Our core routers don't even get mildly bothered doing the discards.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV
| NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Sun, Apr 26, 1998 at 02:08:04AM -0400, Martin, Christian wrote:
> All,
>
> Given the contributions to this thread have been mostly theoretical in
> nature, I'd like to share an experience of mine that in some ways
> negates some of the propsed solutions to smurf attacks in the context of
> smaller ISPs.
>
> Recently, one of our downstream customers was subject to a smurf attack,
> and we placed an access-list on our egress interface to the customers
> network. The customer hangs of an SMDS cloud - our link to the cloud is
> at 34 Mbps, his T1. We were blocking echo replies destined for his
> network. We are connected upstream at 45Mbps. As the attack
> intensified, router CPU Utilization jumped to 99%, and the input queue
> on our inbound HSSI was at 75/75. We started dropping packets at a rate
> of about 7000/sec. The attacks were coming in from all over the world.
> The NetFlow cache was growing at an alarming rate, and, after a while
> the HSSI just DIED. As the HSSI bounced, our BGP session bounced with
> it, causing some mild route flapping (Not vaccilating enough to be
> damped, but enough nonetheless). Eventually the attack subsided, and
> all went back to normal, but for a period of time, say 10 minutes, we
> had a 7507, 64megs, RSP2 WITH the HSSI on a VIP2 on its knees.
>
> We decided that parsing NetFlow logs would give us a better idea of who
> was amplifying the attacks, and with a simple shell script, we were able
> to build a database of ASNs, with admin contacts from RADB/RIPE/ARIN.
> We are planning on sending emails to these customers to ask them to stop
> amplifying smurfs (script does that too), because this is unacceptable.
>
> My point, then is this: Filtering echo replies is/can be a futile
> attempt at preventing this type of attack. I watched a 7507 die
> defending against one attack. More recently, we got hit so hard that
> the router was screaming without ANY access-lists blocking ICMP
> echo-replies, perhaps because there was no real fast-switching taking
> place (each source is different, so the first packet is process
> switched. Our NetFlow cache went from 3900 flows to 27000 flows in
> about 4 mins.) And, as we were not amplifying the smurfs, source
> address verification is a moot point. I am all for allowing these
> netblocks time to implement this type of filtering (layer3 to layer2
> broadcast translation prevention), but not for very long. It appears
> the best way to light a fire under someones rear end is to publicly
> shame them into acting. For those who don't act quickly enough, there
> can be no quarter.
>
> If I appear hostile, I am...
>
> PS
>
> If anyone has similar experiences, please share them, as there has
> already been enough rhetoric filling this thread, and it is clear that
> everyone knows the solution lies at edge and beyond, not in the core.
>
> -Christian Martin
More information about the NANOG
mailing list