ed,
does your MRTG monitoring include packet rates as well as octet rates?
we see similar events here at UCB, usually accompanied by easily observable
spikes in packet rate, but no apparent spike in octet rate. unfortunately
(well maybe it's not so unfortunate :-), i don't have any examples that
i can show you.
ken
>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