Hello, folks!
NetFlow v5 and v9 support have just added to FastNetMon:
https://github.com/FastVPSEestiOu/fastnetmon
Now you can catch DDoS attacks and collect data from sFLOW v5, NetFlow
v5/v9 and even from mirror port with PF_RING in one tool
simultaneously!
Will be very glad for feedback and
Hello, folks!
Thank you for a very useful feedback! I'm so sorry for my negative
vision of netflow :( It's nice protocol but I haven't equpment with
ability to generate netflow on wire speed and I use mirror/SPAN
instead.
I competely redesigned attack-analyzer subsystem and can process
sampled
Hello, folks!
Thank you for a very useful feedback! I'm so sorry for my negative
vision of netflow :( It's nice protocol but I haven't equpment with
ability to generate netflow on wire speed and I use mirror/SPAN
instead.
I competely redesigned attack-analyzer subsystem and can process
sampled
On 2 Dec 2014, at 17:18, Pavel Odintsov wrote:
In near future I will add netflow v5 support.
Good job - you should really go for NetFlow v9 when you can, as it
supports IPv6 and MPLS labels.
Next would be IPFIX.
---
Roland Dobbins rdobb...@arbor.net
On the contrary - SPAN nee port mirroring cuts into the
frames-per-second budget of linecards, as the traffic is in essence
being duplicated. It is not 'free', and it has a profound impact on
the the switch's data-plane traffic forwarding capacity.
Unlike NetFlow.
In hosting case
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)?
Not
On 2014-11-22 18:00, freed...@freedman.net wrote:
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
On 11/22/2014 11:18 AM, Denys Fedoryshchenko wrote:
On 2014-11-22 18:00, freed...@freedman.net wrote:
We see a lot of Brocade for switching in hosting providers, which makes
sFlow easy, of course.
Oh, Brocade, recent experience with ServerIron taught me new lesson,
that i can't
do bonding on
On 2014-11-21 03:12, Roland Dobbins 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.
Word stateful has nothing
On 2014-11-21 06:45, freed...@freedman.net wrote:
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
On 21 Nov 2014, at 15:17, Denys Fedoryshchenko wrote:
Word stateful has nothing common with stateful firewall.Stateful
protocol. a protocol which requires keeping of the internal state on
the server is known as a stateful protocol.
Correct - and NetFlow is not stateful, by this definition.
On 2014-11-21 14:50, Roland Dobbins wrote:
On 21 Nov 2014, at 15:17, Denys Fedoryshchenko wrote:
Word stateful has nothing common with stateful firewall.Stateful
protocol. a protocol which requires keeping of the internal state on
the server is known as a stateful protocol.
Correct - and
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
On 2014-11-21 18:41, Peter Phaal wrote:
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
pmacct includes sfacctd which is an sflow collector.. Accessible via
the same methods as it's nfacctd collector or pcap based collector..
--
Tim
On Fri, Nov 21, 2014 at 9:06 AM, Denys Fedoryshchenko de...@visp.net.lb wrote:
On 2014-11-21 18:41, Peter Phaal wrote:
Actually, sFlow from many
Thanks! Most important there is plugin API,so it is easy to write custom
code to do some analysis and on events - actions.
On 2014-11-21 20:32, Tim Jackson wrote:
pmacct includes sfacctd which is an sflow collector.. Accessible via
the same methods as it's nfacctd collector or pcap based
On 21 Nov 2014, at 4:36, Pavel Odintsov wrote:
I tried to use netflow many years ago but it's not accurate enough and
not so fast enough and produce big overhead on middle class network
routers.
These statements are not supported by the facts. NetFlow (and other
varieties of flow
On 2014-11-20 23:59, Roland Dobbins wrote:
On 21 Nov 2014, at 4:36, Pavel Odintsov wrote:
I tried to use netflow many years ago but it's not accurate enough and
not so fast enough and produce big overhead on middle class network
routers.
These statements are not supported by the facts.
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
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
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
What happens when someone spoofs legitimate hosts that your customers use?
On Thu, Nov 20, 2014 at 3:36 PM, Pavel Odintsov pavel.odint...@gmail.com
wrote:
Hello, folks!
I'm author of fastnetmon, thank you for some PR for my toolkit :)
I use this tool for similar type of attacks and we do
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
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
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
WANguard from andrisoft has worked well on this for us.
It supports flow telemetry and mirrored ports both (We use flows
strictly), and does what it says it does.
No complaints.
On 11/21/2014 午後 12:00, Robert Duffy wrote:
I've been using NTOP for couple of years. I'm mostly looking for
On 21 Nov 2014, at 12:08, Paul S. wrote:
WANguard from andrisoft has worked well on this for us.
I believe the thread was focusing on open-source tools.
---
Roland Dobbins rdobb...@arbor.net
I've used the first one, and hacked on the second.
WANGuard, when deployed properly, works amazingly well.
ddosmon is only useful if you have netflow v5 flows (or sflow that can
get converted to nfv5), but also works well when coupled with exabgp /
openbgpd.
I added some per ip limiting /
Roland Dobbins wrote:
On 9 Nov 2014, at 10:37, Jon Lewis wrote:
I'm sure it's not always the case, but in my experience as a SP, the
victim virtually always did something to instigate the attack, and is
usually someone you don't want as a customer.
This may be a reflection of your
Look at the products from RioRey (www.riorey.com). IMHO I think their
technology is much better than some of the other players out here.
On 11/08/2014 07:10 PM, Eric C. Miller wrote:
Today, we experienced (3) separate DDoS attacks from Eastern Asia, all
generating 2Gbps towards a single IP
Eric C. Miller wrote:
Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating
2Gbps towards a single IP address in our network. All 3 attacks targeted
different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes
and stopped as fast as they
Check out Arbour Networks, they produce a range of DDoS scrubbing appliances
that do pretty much what you want.
Regards,
Tim Raphael
On 9 Nov 2014, at 9:10 am, Eric C. Miller e...@ericheather.com wrote:
Today, we experienced (3) separate DDoS attacks from Eastern Asia, all
generating
Here's a thought-provoking video on what Brocade has done with its SDN
software load on the MLX:
http://vimeo.com/87476840 (demo at ~15 minute mark)
I've written it before: if there was a software feature in routers where I
could specify the maximum rate any prefix size (up to /32) could receive,
On 9 Nov 2014, at 8:10, Eric C. Miller wrote:
Does anyone have any suggestions for mitigating these type of attacks?
You can start with S/RTBH (or flowspec, if your platform supports it):
http://tools.ietf.org/html/rfc5635
http://tools.ietf.org/html/rfc5575
On 9 Nov 2014, at 8:59, Frank Bulk wrote:
I've written it before: if there was a software feature in routers
where I
could specify the maximum rate any prefix size (up to /32) could
receive,
that would be very helpful.
QoS generally isn't a suitable mechanism for DDoS mitigation, as the
.
Frank
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins
Sent: Saturday, November 08, 2014 8:28 PM
To: NANOG
Subject: Re: DDOS, IDS, RTBH, and Rate limiting
On 9 Nov 2014, at 8:59, Frank Bulk wrote:
I've written it before
On 9 Nov 2014, at 9:42, Frank Bulk wrote:
There's no doubt, rate-limiting is a poor-man's way of getting the job
done,
but for small operators who aren't as well instrumented (whether that
due to
staff or resources)
You might as well just D/RTBH the victim and have done with it, heh.
This
http://www.andrisoft.com/software/wanguard/ddos-mitigation-protection
https://bitbucket.org/tortoiselabs/ddosmon
https://github.com/FastVPSEestiOu/fastnetmon
I have no idea if any of them actually work.
On 11/08/2014 05:10 PM, Eric C. Miller wrote:
Today, we experienced (3) separate DDoS
On Sat, 8 Nov 2014, Miles Fidelman wrote:
Does anyone have any suggestions for mitigating these type of attacks?
The phrase automated offensive cyber counter-attack has been coming to mind
rather frequently, of late. I wonder if DARPA might fund some work in this
area. :-)
When you're
On 9 Nov 2014, at 10:12, Jon Lewis wrote:
The tricky part is when to remove the route...since you can't tell if
the attack has ended while the target is black holed by your
upstreams.
You can with NetFlow, if you've D/RTBHed the IP in question on your own
infrastructure. NetFlow reports
A quick and dirty win is to get your upstream(s) to kill anything UDP 19 to
your prefixes at their ingress points if it becomes a common thing. You
lose visibility as to when you're getting targeted by that type of attack
again though, which could matter depending on your network.
On Saturday,
How many holes are you going to stick fingers in to stop the flows? Good
luck getting your provider to put in such a filter and make it anything
more than temporary...and then there's still DNS, NTP, SNMP, and other
protocols an attacker can easily utilize when they find that chargen isn't
On 9 Nov 2014, at 10:37, Jon Lewis wrote:
I'm sure it's not always the case, but in my experience as a SP, the
victim virtually always did something to instigate the attack, and is
usually someone you don't want as a customer.
This may be a reflection of your experience and customer base,
I wouldn't have suggested it if I hadn't successfully made these requests
myself. Most attacks don't last long enough to put a dent on billing so
it's in everyone best interest to cull it quickly.
Providing the upstream network is big enough and your attacks aren't huge
pipefills, they will
On Sat, Nov 08, 2014 at 10:37:45PM -0500, Jon Lewis wrote:
On Sun, 9 Nov 2014, Roland Dobbins wrote:
But this kind of thing punishes the victim. It's far better to do
everything possible to *protect* the target(s) of an attack, and
only use D/RTBH as a last resort.
I'm sure it's not always
On 11/8/14 6:28 PM, Roland Dobbins wrote:
On 9 Nov 2014, at 8:59, Frank Bulk wrote:
I've written it before: if there was a software feature in routers
where I
could specify the maximum rate any prefix size (up to /32) could receive,
that would be very helpful.
QoS generally isn't a
Dobbins; NANOG
Subject: Re: DDOS, IDS, RTBH, and Rate limiting
On 11/8/14 6:28 PM, Roland Dobbins wrote:
On 9 Nov 2014, at 8:59, Frank Bulk wrote:
I've written it before: if there was a software feature in routers
where I
could specify the maximum rate any prefix size (up to /32) could
47 matches
Mail list logo
