Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Is current DDoS detecting method effective?

  • From: Jared Mauch
  • Date: Mon Mar 07 15:14:52 2005

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
> <> 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 

	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.

	- jared

Jared Mauch  | pgp key available via finger from
clue++;      |  My statements are only mine.

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.