Network Operators and smurf

Sun Apr 26 20:50:11 UTC 1998

>I block *ALL* packets from any netblock which is implicated as a smurf
>amplifier, on the first offense.
>
>I will remove those blocks when I can PROVE that they can no longer be used
>as a smurf amplifier.  To date, NOBODY on the list has come forward and said
>"we've audited and fixed, please remove the block".
>
>PSU (which is on the list) said "we're looking into it" but that was more
>than two weeks ago! How long does it take to telnet into your routers and
>check the ethernet interfaces for the correct configuration?  A day or so?
>Perhaps, even if you have a HUGE netwokr.
>
>It does not require two weeks.

First, I am not speaking for Penn State, although I am a member of the
University's CERT team.  Second, I am not asking that any block be removed.
Such a request would have to come from others at PSU.

It may require two weeks when you have to deal with the multiple domains of
control one finds at this University.  This means that you can not just walk up
to some machines and pull the plug without have large quantities of excrement
start flowing rapidly down hill from on high and sweeping everything in it's
path away.

The security office been very active in checking out which routers are still
vulnerable.  Unfortunately there are a number of `routers' (read multi-homed
UNIX systems) that are not directly connected to the university's backbone that
have not been secured.  These machines usually are being administered by a grad
student who is more interested in study for comprehensive exams than in
installing the necessary patches to fix the problem.  In that case the security
office will usually offer to assist in securing these systems.  Sometimes that
offer will not be accepted, or it may take a week for everyone to come to an
agreement as to what needs to be done.

So, yes, it may very well take more that two weeks to complete.  But, I believe
that all routers that make up the University backbone and are maintained by the
Office of Telecommunication have been secured.

-- Dan Ehrlich

>
>Blocking just ICMP is pointless - block EVERYTHING.  The only way we ever
>get this fixed is to make it HURT to be on the blacklist.
>
>--
>-- 
>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 12:29:19PM -0400, Jason Lixfeld wrote:
>> What config options/access-lists are you using.  If Martin says his
>> routers choked, and you say yours don't, I'd like to know (as would
>> anyone, I think) what you are running and how you are running it.  I
>> assume you are using access-lists.  Are you using NetFlow?  On which
>> interfaces?  Are you blocking inbound echo-reply?  To where?  Everywhere
>> or just your core network?  The problem I'm faced with, is I'm currently
>> blocking ICMP to my core networks, NOT to customers or dialup ports.  They
>> will REALLY bitch if I start doing that.  I'm going to change it to block
>> echo-reply to those networks only. 
>> 
>> Currently, the measures "I" am taking is:
>> 
>> o outbound access-list permitting ONLY networks which source on our
>> router.
>> 
>> o inbound access-list denying ICMP (which will be modifiec to block ICMP 
>> echo-reply only) to core networks along with .0 and .255 address blocks.
>> 
>> o no ip directed-broadcast on ALL interfaces
>> 
>> o ip route-cache flow (so I can get some information on these *ssholes)
>> 
>> What else do I need?!  What am I doing wrong with the above (if anything)
>> 
>> TiA...
>> 
>> On Sun, 26 Apr 1998, Karl Denninger wrote:
>> 
>> :Since I have started blacklisting people, the list has grown to more than 4
0
>> :netwroks.
>> :
>> :However, only ONE, and that one was very short (< 5 minutes) smurf has take
n
>> :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/D
OV
>> :			     | NEW! Corporate ISDN Prices dropped by up to 50%!
>> :Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUN
TS
>> :Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no co
st
>> :
>> :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
>> :
>> 
>> --
>> Regards,  
>> 
>> Jason A. Lixfeld             jlixfeld at idirect.ca
>> iDirect Network Operations   jlixfeld at torontointernetxchange.net
>> 
>> ---------------------------------------------------------------------
>> TUCOWS Interactive Ltd. o/a  | "A Different Kind of Internet Company"
>> Internet Direct Canada Inc.  | "FREE BANDWIDTH for Toronto Area IAPs"
>> 5415 Dundas Street West      | http://www.torontointernetxchange.net
>> Suite 301, Toronto Ontario   | (416) 236-5806	     (T)
>> M9B-1B5 CANADA               | (416) 236-5804        (F)
>> ---------------------------------------------------------------------
>> 
>

-- 
Dan Ehrlich - Systems Analyst - PSU Computer Science and Engineering
"Universities should be safe havens where ruthless examination of realities
 will not be distorted by the aim to please or inhibited by the risk of
 displeasure." - Kingman Brewster