DDOS, IDS, RTBH, and Rate limiting

Fri Nov 21 02:19:31 UTC 2014

Roland, you seem to have a lot of experience with these kinds of tools.
What open-source NetFlow analysis tools would you recommend for quickly
detecting a DDoS attack?

On Thu, Nov 20, 2014 at 5:12 PM, Roland Dobbins <rdobbins at arbor.net> wrote:

>
> On 21 Nov 2014, at 6:22, Denys Fedoryshchenko wrote:
>
>  Netflow is stateful stuff,
>>
>
> This is factually incorrect; NetFlow flows are unidirectional in nature,
> and in any event have no effect on processing of data-plane traffic.
>
>  and just to run it on wirespeed, on hardware, you need to utilise
>> significant part of TCAM,
>>
>
> Again, this is factually incorrect.
>
>  i am not talking that on some hardware it is just impossible to run it.
>>
>
> This is also factually incorrect.  Some platforms/linecards do not in fact
> support NetFlow (or other varieties of flow telemetry) due to hardware
> limitations.
>
>  And last thing, from one of public papers, netflow delaying factors:
>> 1. Flow record expiration
>>
>
> This is tunable.
>
>  • Typical delay: 15-60 sec.
>>
>
> This is an entirely subjective assessment, and does not reflect
> operational realities.  These are typically *maximum values* - and they are
> well within operationally-useful timeframes.  Also, the effect of NetFlow
> cache size and resultant FIFOing of flow records is not taken into account,
> nor is the effect on flow termination and flow-record export of TCP FIN or
> RST flags denoting TCP traffic taken into account.
>
>  So for a small hosting(up to 10G), i believe, FastNetMon is best solution.
>>
>
> This is a gross over-generalization unsupported by facts.  Many years of
> operational experience with NetFlow and other forms of flow telemetry by
> large numbers of network operators of all sizes and varieties contract this
> over-generalization.
>
> It is generally unwise to make sweeping statements regarding operational
> impact which are not borne out by significant operational experience in
> production networks.
>
>  Faster, and no significant investments to equipment.
>>
>
> This statement indicates a lack of understanding of opex costs,
> irrespective of capex costs.
>
>  Bigger hosting providers might reuse their existing servers, segment the
>> network, and implement inexpensive monitoring on aggregation switches
>> without any additional cost again.
>>
>
> This statement indicates a lack of operational experience in networks of
> even minimal scale.
>
>  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.
>>
>
> This statement betrays a lack of understanding of NetFlow-based (and other
> flow telemetry-based) detection and classification, as well as the
> undesirability and negative operational impact of stateful IDS/'IPS'
> deployments in production networks.
>
> You should also note that FastNetMon is far from unique; there are
> multiple other open-source tools which provide the same type of
> functionality, and none of them have replaced flow telemetry, either.
>
> Tools such as FastNetMon supplement flow telemetry, in situations in which
> such tools can be deployed.  They do not begin to replace flow telemetry,
> and they are not inherently superior to flow telemetry.
>
> Again, I'm sure FastNetMon is a useful tool in many circumstances.  But it
> would be a much better idea to define FastNetMon positively in terms of its
> own inherent value, rather than attempting to define it based upon
> factually incorrect negative 'comparisons' to other well-established,
> widely-used technologies which have demonstrable track records within the
> global operational community.
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
>

-- 
Regards,
Rob
------------------------------------------------------------
--------------------
Robert Duffy
eSecureData.com Inc.
1478 Hartley Ave.
Coquitlam, BC V3K 7A1
T: (800) 620-1985
F: (800) 620-1986

This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on the contents herein. Any communication received in
error, or subsequent reply, should be deleted or destroyed.