DDOS, IDS, RTBH, and Rate limiting

Mailman List Mirror (Read Only)
1

Netflow is stateful stuff, and just to run it on wirespeed, on hardware,
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.

i am not talking that on some hardware it is just impossible to run it.
So everything about netflow are built on assumption that hosting or ISP
can run it. And based on some observations, majority of small/middle
hosting providers are using minimal,just BGP capable L3 switch as core,
and cheapest but reliable L2/L3 on aggregation, and both are capable in
best case to run sampled sFlow.

Actually, sFlow from many vendors is pretty good (per your points about flow
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.

<snip>

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

Ah, and there is one more huge problem with netflow vs FastNetMon -
netflow just by design cannot be adapted to run pattern matching, while
it is trivial to patch FastNetMon for that, turning it to mini-IDS for
free.

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

Best regards,
Denys

Avi Freedman | Your flow has something to show you; can you see it? |
CEO, CloudHelix | (avi at cloudhelix dot com) | my name one word on skype |

2

Netflow is stateful stuff, and just to run it on wirespeed, on hardware,
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 network.
Does it worth to buy ASR, if L3 switch already doing the job (BGP/ACL/rate-limit/routing)?

i am not talking that on some hardware it is just impossible to run it.
So everything about netflow are built on assumption that hosting or ISP
can run it. And based on some observations, majority of small/middle
hosting providers are using minimal,just BGP capable L3 switch as core,
and cheapest but reliable L2/L3 on aggregation, and both are capable in
best case to run sampled sFlow.

Actually, sFlow from many vendors is pretty good (per your points about flow
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 obstacle,
software licensing cost. On latest JunOS, for example on EX2200, you need
to purchase license (EFL), and if am not wrong it is $3000 for 48port units.
So if only sFlow feature is on stake, it worth to think, to purchase license,
or to purchase server. Prices for JFlow license on MX, just for 5/10G is way above cost
of very decent server.

<snip>

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, for
statistical/telemetry purposes. But i am not sure it is possible to run them
together.

Ah, and there is one more huge problem with netflow vs FastNetMon -
netflow just by design cannot be adapted to run pattern matching, while
it is trivial to patch FastNetMon for that, turning it to mini-IDS for
free.

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

About scaling, i guess it depends on proper deployment strategy and sysadmins/developers
capabilities. For example to deploy new ruleset for my pcap-based "homemade"
analyser to 150 probes across the country - is just one click.

3

Actually, sFlow from many vendors is pretty good (per your points about
flow
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
obstacle,
software licensing cost. On latest JunOS, for example on EX2200, you need
to purchase license (EFL), and if am not wrong it is $3000 for 48port units.
So if only sFlow feature is on stake, it worth to think, to purchase
license,
or to purchase server.

Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2):

I am not aware of any vendor requiring an additional license to enable sFlow.

sFlow (packet sampling) works extremely well for the DDoS flood
detection / mitigation use case. The measurements are build into low
cost commodity switch hardware and can be enabled operationally
without adversely impacting switch performance. A flood attack
generates high packet rates and sampling a 10G port at 1-in-10,000
will reliably detect flood attacks within seconds.

For most use cases, it is much less expensive to use switches to
perform measurement than to attach taps / mirror port probes. If your
switches don't already support sFlow, you can buy a 10G capable white
box switch for a few thousand dollars that will let you monitor 1.2
Terabits/sec. If you go with an open platform such as Cumulus Linux,
you could even run your DDoS mitigation software on the switch and
dispense with the external server. Embedded instrumentation is simple
to deploy and reduces operational complexity and cost when compared to
add on probe solutions.

Peter Phaal
InMon Corp.

4

Wow, that's great news then, i'm using mostly Cisco gear now, but seems will have to take a look to Juniper, thanks for information.
If it is free, then if EX2200 available, it is much easier to run sFlow and write custom collector for it, than installing custom probe(in most common cases).

5

pmacct includes sfacctd which is an sflow collector.. Accessible via
the same methods as it's nfacctd collector or pcap based collector..

6

Thanks! Most important there is plugin API,so it is easy to write custom code to do some analysis and on events - actions.