Hello Ed,
If you ever see anything like this again, call PSIRT ASAP. PSIRT is our
Cisco Product Security Incident Response Team. They are available 24x7.
http://www.cisco.com/warp/public/707/sec_incident_response.shtml
As for my value add on this thread, remember two document:
Improving Security on Cisco Routers
http://www.cisco.com/warp/public/707/21.html
Essential IOS Features Every ISP Should Consider ("IOS Essentials" for
short)
http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip
We're busy updating some of the security sections in IOS Essentials and will
push a new version out tonight.
Barry
> -----Original Message-----
> From: Edward Henigin [mailto:ed@staff.texas.net]
> Sent: Wednesday, February 09, 2000 11:53 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [nsp] DoS tracking
>
>
> Guys,
>
> I'm not too concerned about the high-volume DOS attacks
> we're seeing nowadays, believe it or not. They suck, but we happen
> to have enough bandwidth available and decent enough CAR rules in
> place which protect us well enough.
>
> Right now I'm more concerned with some low-volume DOS
> attacks which are capable of killing a 7513/RSP4. I don't know
> what the hell can do that, but I've seen a couple of instances in
> the past where one of my router cpu load shoots up, HDLC connections
> drop (T1 and T3), and BGP sessions go down. Since the behaviour
> is so anamolous, my best guess is that it's some sort of DOS attack.
>
> But it's a low-volume DOS attack. There is no traffic
> spike according to my MRTG. I see nothing to make me believe that
> the issue is any kind of flood directed at the router or any hosts
> behind the router. So it must be some sort of specific vulnerability
> in IOS, or maybe in router in general, that I'm not thinking of or
> am not aware of.
>
> Anyone have any pointers, experience, suggestions for
> getting educated about this?
>
> Ed
>
>
> PS Charles -- sorry for not adding any useful info to you
> specifically. We use CAR: we CAR incoming icmp echo request,
> incoming tcp syn, and incoming udp (no ports specified). That has
> seemed to offer good protection so far. The UDP CAR is a much
> higher limit than the ICMP or TCP SYN CAR's, but still lower than
> you might think, and protects against UDP floods from TFN-type
> attacks.
>
> Blocking the traffic with access-lists or null0 routes
> seems like a lot of work to me. I guess if someone wrote a script
> to parse netflow output, and you had your netflow expiring like on
> 5 minute intervals or shorter, then you could do what you're talking
> about. You'd need a dedicated, powerful box to do that kind of
> number crunching. It seems like a small incremental gain over just
> CAR alone, and not worth the effort. Being able to get you to
> notify your upstream so they can put anti-DOS access-lists in place,
> that would help, but you're going to have a noticable delay before
> that can be done, usually, and would only be helpful on long-lived
> attacks, which I really don't see that often.
>
> The #1 way to avoid being flooded: don't run an IRC server.
> The #2 way to avoid being flooded: don't run open shell servers
> from which anyone IRC's. Once you get past those two, your odds
> of being DOS'd go through the floor. If you get attacked with any
> regularity, seriously consider the value of those damn shell servers
> compared to your sanity.
>
> Ed
> --
> On Wed, Feb 09, 2000 at 01:11:00PM -0500, Charles Sprickman said:
> > Hello,
> >
> > With all the attacks happening these days (yahoo, cnn, etrade,
> etc.), I'm
> > wondering if anyone here could share their techniques for tracking down
> > source addresses using netflow (or any other nifty methods you
> may have).
> >
> > While many attacks have varying source addresses, some don't
> and it seems
> > possible to at least try to block some of the traffic.
> Basically what I'm
> > looking to do is hopefully start a thread here where we can share info
> > about how to identify and quell some of the more common attacks.
> >
> > Some ideas:
> >
> > -netflow for dummies
> > -quick-n-dirty netflow collector setup
> > -using tcpdump/snoop to identify huge flows
> > -capabilities of various cisco platforms for flow collection
> and filtering
> > (ie: when will the router just fall over and die)
> > -talking to / educating your upstream
> >
> > Just thought it would be useful for some of us smaller ops on
> this list to
> > start talking about this now rather than at the time someone is
> being hit
> > and is in a panic... This seems like a more appropriate forum
> than NANOG,
> > so I'm posting here, let me know if this is not a good assumption.
> >
> > Thanks,
> >
> > Charles
> >
> > --
> > =-----------------= =
> > | Charles Sprickman Internet Channel |
> > | INCH System Administration Team (212)243-5200 |
> > | spork@inch.com access@inch.com |
> > = =----------------=
>
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:10 EDT