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:09 EDT