At 13:15 09/02/00 -0800, Barry Raveendran Greene wrote:
In those pages there should a link to TCP Intercept (it is mentioned - but
not linked):
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/intercpt.htm
-Hank
>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