[nsp] NetFlow and DoS attacks - tuning

[Charles Sprickman]

On Sun, 14 Dec 2003, Paul Kohler wrote:

> Hi Charles,

> I think the timers are what you can play with. Typically customers like
> to configure them lower than their default 15 sec for inactive and 30
> min for active values so that possible attacks can more quickly be
> identified. For more info check
> http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm#1222819

My only concern here is to not let it swamp the router...  It seems like
setting these lower will give me more accurate flow stats, but probably
cause more cpu usage, correct?

> - As Nathan alluded to, Flow-tools or any other app is not mandatory to
> successfully identify and mitigate a DoS attack. While an apps provide
> additional functionality or ease-of-use, you can still use CLI.

...Unless the router is so swamped you cannot login.  Then having some
(any) netflow data for the brief periods where the router can breathe
again is quite helpful.

> - Here's a good overview presentation
> http://www.dfn-cert.de/dfn/berichte/db093/behringer-ddos.pdf
> it covers NetFlow but also rate-limiting, CAR, uRPF, etc...

That was very interesting.  I sent that around the office to help explain
what a DoS attack is and show that it's not just something you can "fix".

In the paper there's mention of Dante's tool for looking at flows for
possible DoS attacks.  It seems that they no longer have this available,
this is all that Google will give me:

http://archive.dante.net/security/dos/  (no link to the tool)

It does seem old (2001), is anyone aware of something similar?

If you could also comment on the note on page 15 about the "scheduler
allocate" command, that would be helpful.

Thanks for all the info,

Charles

> Paul
>
> At 01:13 AM 12/14/2003, Nathan Patrick wrote:
> >I've found "show ip cache flow" to be extremely useful in diagnosing DoS
> >attacks.
> >
> >Given the quantity of flow data that we archive, flow-tools searches take
> >quite some time. It's often faster to simply hop on the router and try
> >"show ip cache flow | inc K" to find IPs sourcing large amounts of
> >traffic, or taking a visual look at "show ip cache flow" for random source
> >IPs and their ingress interface. "show ip cache flow | inc <attacked IP>"
> >is also very useful, as it lets you know what's hitting a destination.
> >More advanced regexps can give you some interesting data.
> >
> >As for tuning, we set our inactive timeout to 300 seconds and active
> >timeout to 1 minute. The inactive timeout gets flows out of the cache
> >quickly, while the active timeout cuts up long running flows (news peers,
> >etc.) for graphing and some other applications. Other than that, we've
> >found the defaults to work well on NPE-400s as well as RSP4s. Note that
> >these parameters are not intended to reduce router load, but rather help
> >other applications.
> >
> >-Nathan
> >
> >Charles Sprickman wrote:
> >
> >>Hi,
> >>
> >>I'm very new to netflow and flow-tools, but I had to use them tonight to
> >>try and figure out what was being hit and where from (thanks elr at panix!).
> >>
> >>After we dug up what we wanted, we started wondering about what kind of
> >>impact logging all the flows was having on the router (a vxr w/npe-300),
> >>as it was falling down under a 20,000 pps hit at a 384K SDSL customer
> >>behind it.
> >>
> >>There appear to be some tunables for flow export:
> >>
> >>router.bway.net(config)#ip flow-cache ?
> >>  entries             Specify the number of entries in the flow cache
> >>  feature-accelerate  Enable flow based feature acceleration
> >>  timeout             Specify flow cache timeout parameters
> >>
> >>But I'm not really sure what I should be setting these to.  I want some
> >>data during an attack, as it seems flow-tools is almost mandatory for
> >>figuring out what is being hit when the traffic doesn't exit the router to
> >>a LAN segment, but I also don't want the router to sacrifice itself in the
> >>process.
> >>
> >>Any pointers?  Any real-world experience with tuning this?
> >>
> >>Thanks,
> >>
> >>Charles
> >>
> >>--
> >>Charles Sprickman
> >>spork at inch.com
> >>
> >>_______________________________________________
> >>cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>
> >>
> >>
> >
> >_______________________________________________
> >cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>