DDOS, IDS, RTBH, and Rate limiting
denys at visp.net.lb
Fri Nov 21 09:03:54 UTC 2014
On 2014-11-21 06:45, freedman at freedman.net wrote:
>> Netflow is stateful stuff, and just to run it on wirespeed, on
>> you need to utilise significant part of TCAM,
> Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second
> without affecting packet forwarding.
Yes, i agree,those are good for netflow, but when they already exist in
Does it worth to buy ASR, if L3 switch already doing the job
>> i am not talking that on some hardware it is just impossible to run
>> So everything about netflow are built on assumption that hosting or
>> can run it. And based on some observations, majority of small/middle
>> hosting providers are using minimal,just BGP capable L3 switch as
>> and cheapest but reliable L2/L3 on aggregation, and both are capable
>> best case to run sampled sFlow.
> Actually, sFlow from many vendors is pretty good (per your points about
> burstiness and delays), and is good enough for dDoS detection. Not for
> security forensics, or billing at 99.99% accuracy, but good enough for
> traffic visibility, peering analytics, and (d)DoS detection.
Well, if it is available, except hardware limitations, there is second
software licensing cost. On latest JunOS, for example on EX2200, you
to purchase license (EFL), and if am not wrong it is $3000 for 48port
So if only sFlow feature is on stake, it worth to think, to purchase
or to purchase server. Prices for JFlow license on MX, just for 5/10G is
way above cost
of very decent server.
>> So for a small hosting(up to 10G), i believe, FastNetMon is best
>> solution. Faster, and no significant investments to equipment. Bigger
>> hosting providers might reuse their existing servers, segment the
>> network, and implement inexpensive monitoring on aggregation switches
>> without any additional cost again.
> It can be useful to have a 10G network monitoring box of course...
> And with the right setup you can run FastNetMon or other tools in
> addition to generating flow that can be of use for other purposes
> as well...
Technically there is ipt_NETFLOW, that can generate netflow on same box,
statistical/telemetry purposes. But i am not sure it is possible to run
>> Ah, and there is one more huge problem with netflow vs FastNetMon -
>> netflow just by design cannot be adapted to run pattern matching,
>> it is trivial to patch FastNetMon for that, turning it to mini-IDS for
> It's true, having a network tap can be useful for doing PCAP-y stuff.
> But taps can be difficult or at least time consuming for people to
> put in at scale. Even, we've seen, for folks with 10G networks.
> Often because they can get 90% of what they need for 4 different
> business purposes from just flow :)
About scaling, i guess it depends on proper deployment strategy and
capabilities. For example to deploy new ruleset for my pcap-based
analyser to 150 probes across the country - is just one click.
More information about the NANOG