nanog mailing list archives

Re: Is current DDoS detecting method effective?


From: Jared Mauch <jared () puck nether net>
Date: Mon, 7 Mar 2005 15:13:40 -0500


On Mon, Mar 07, 2005 at 01:43:29PM +0200, Kim Onnel wrote:
On Mon, 07 Mar 2005 06:11:35 +0000 (GMT), Christopher L. Morrow
<christopher.morrow () mci com> wrote:

Some of your cflowd gathering should also see these things, but they will
need data correlation, something Arbor already went to the trouble of
doing for you... So, define: "attack" and then see if your tool fits that
definition.

So I can safely say that Detecting DDoS attacks is mostly done using
Netflow data, now the only tool(known) on the market to analyze for
attacks is Arbor, now besides being expensive, which is a problem for
Mid-sizes ISPs, doing that with open-source tools(cflowd,...) isnt
quite easy for a network engineer, who rarely has programming
experience, thats my problem now, we either need to outsource or buy
Arbor,

I've seen open-source Netflow DDoS specific apps. anyone tried them
(Zazu and Panoptis)

-With the small experience i've gained to work out these tools,
- Zazu is still under devel. but some times reports nice results
- couldnt compile panoptis

Any luck with (stager, Silktools, ntop,...)?

I wish there could be a documented ISPs experience for using
open-source tools to detect DDoS, or a homegrown script that uses
flow-tools to report anomalies.

        I once took some time to write a netflow processing system.

        It's not that hard..

        If you want some "basic" detection, I recommend doing something
like this:

        sort by the top "proto+dstip+dstport+tcpflags"
combination.  The more of these you see, the more it may
look weird.

        As Chris mentioned before, what defines the "bad" threshold
depends on your customerbase.  Maybe 1Kpps is bad.  Maybe 100Kpps is 
normal.

        Cisco publishes the netflow datagram specification, so
you may be able to write an optimized netflow daemon that doesn't
take up too much cpu/disk/whatnot if you discard the lower
levels of the "noise".

        Once you define your 'signal' and 'noise' you can then
determine what is valuable to you.

http://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.htm

        - jared

-- 
Jared Mauch  | pgp key available via finger from jared () puck nether net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.


Current thread: