Re: DDOS, IDS, RTBH, and Rate limiting

2014-11-20 Thread Robert Duffy
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 rdobb...@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 rdobb...@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.


Re: DDOS, IDS, RTBH, and Rate limiting

2014-11-20 Thread Robert Duffy
I've been using NTOP for couple of years.  I'm mostly looking for something
that can quickly detect DDoS attacks in a datacenter environment.  Thanks
for the suggestions.  Ill check them out.

On Thu, Nov 20, 2014 at 6:50 PM, Tim Jackson jackson@gmail.com wrote:

 I highly recommend pmacct and it's in-memory tables. Lightweight, easy to
 query and super fast.

 You can also easily run multiple aggregates of traffic to find what you are
 interested in, tag common interface types to easily filter traffic..

 Or you can use pmacct to insert this into whatever database you want, AMQP
 or MongoDB..

 My current favorite is using an IMT table for DoS detection and another for
 aggregates for interesting traffic types and querying this every X minutes
 and inserting it into ElasticSearch. Kibana makes the most powerful netflow
 dashboard ever.

 --
 Tim
 On Nov 20, 2014 6:39 PM, Roland Dobbins rdobb...@arbor.net wrote:

 
  On 21 Nov 2014, at 9:19, Robert Duffy wrote:
 
   What open-source NetFlow analysis tools would you recommend for quickly
  detecting a DDoS attack?
 
 
  I generally recommend that folks get started with something like
  nfdump/nfsen or ntop.  There are other, more sophisticated tools out
 there,
  but these allow one to get up and running quickly, and to gain valuable
  operational experience with which to evaluate more sophisticated tools,
 if
  they're needed.
 
  ---
  Roland Dobbins rdobb...@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.


Re: NIST NTP Server List

2014-10-29 Thread Robert Duffy
It's up from Vancouver, Canada.  No 404 from here.

On Wed, Oct 29, 2014 at 10:16 AM, Stuart Sheldon s...@actusa.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Yeah, it looks like it's down

 stu



 On 10/29/2014 10:14 AM, Brian Christopher Raaen wrote:
  The list of NIST NTP servers is down for me, is anyone else seeing this?
  I'm getting a 404 error
  http://tf.nist.gov/tf-cgi/servers.cgi
 

 - --
 No problem is so big or so complicated that it can't be run away from!
   -- Charles M. Schulz
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iQIcBAEBCAAGBQJUUSEKAAoJEFKVLITDJSGSY8gP/jCGC2BT8oTmDLnxNVslL8wo
 VF1gB4WZm7xzJZk4PW/MbAn06TRADZGlO7d80a4lSBEAWTiq913d1G0LeXiRCgn6
 o6dbgVjOgZWZ54J9jLwcSKaW6r0oXHO/DZ9PHKuZ0/t5A8I1YCiOQAD3fnBv2zmA
 PZjcKfGo3kuDfmdrJTGRKvvIWQkGno150XUzLjpC6DYd46zx8MrqXnuZLRatdPr+
 pE/Z0moX35VUpC9y0pFrG9Pa2jjAIXRLbnDo6c8cp6noVGfQW+Xe8rX4+O7ddd27
 CatcjsGKpiGd6Z1MtXvID5JBINHqsmqOgSRLpj62xl7MvSFMEyjeEyRVol+sxOj5
 OBVObg4Pl4S7LrAJ1Bi9oK+CUW64E4jXpBfLejb+unv0jKF4RJSDec2ENskqkTb5
 Z/p4kjlFAd9aWq37HVYKbm2DcK/XR4kzra4IgQ+LI1MWfLpm+voKxFVzWP/OxAxq
 ItYpQQ+tCtwAzQ245T7LvuWYXhIA/HiTct2DObEL6w/m2KPk8++zu0Zw5LZRWRAH
 FPhsOWwd0fw0i4dlGBCFnMvHzLrqvB64pA7H8x/X+V+vyAdELUXwAYn0lrFfgoJc
 WXZn99og5vqQnmv6r0ScGSoZER0lWpjaMIrkZoI8Pm5wS3fmjXpMhknlHqT8yPS/
 pGJ4SQoXrVv0dPy65cpo
 =POmY
 -END PGP SIGNATURE-




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