[nsp] NetFlow and DoS attacks - tuning

Wed Dec 17 03:31:28 EST 2003

Arbor Networks (http://www.arbornetworks.com) provide commercial  
anomaly-detection and traffic-analysis systems which make use of  
NetFlow quite effectively, in my experience.  Specifically, Arbor  
Peakflow DoS is the anomaly-detection solution.

On Dec 16, 2003, at 11:22 PM, Charles Sprickman wrote:

> 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/
>>
> _______________________________________________
> 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/
>
---------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // 408.527.6376 voice