Dear Nogers,
We are currently evaluating some DDOS detection/mitigation solutions.
Do you have any inputs/experiences on Wanguard from Andrisoft, please ?https://www.andrisoft.com/software/wanguard
Currently we are just interested on the packets/flows sensors with the console for detection and RTBH trigger. Maybe the packet filtering (for scrubbing) will come later.
Best Regards,-Marcel Duregards
Hello!
We have some open source software for this task
https://github.com/FastVPSEestiOu/fastnetmon 
Feel free to ask me
any questions off list.
I can attest that fastnetmon is a great tool for dealing with high pps
or high bandwidth attacks. Pavel thank you so much for sharing this!
Yesterday I deployed fastnetmon at a small non-profit ISP in Amsterdam
(AS8283). From the start of the attack to actually dealing with it by
announcing blackhole route plus /24 wrapper (to draw traffic via that
upstream), only takes four seconds.
Kind regards,
Job
We are currently using Wanguard. Have had it in place for about 6months.
Have not setup BGP peering with my edges to blackhole inbound traffic yet
simply because I haven't had time, but the product itself seems to be
pretty full featured and has lots of options and a pretty reasonable
interface. I've got two netflow sensors running against Huawei NE40
routers with full routes. For now (I get two or three 2G+ DDOS a month)
it's been enough to see the alert and manually blackhole it .
Getting ahold of support can be a bit of a chore, but they do respond, and
the manual is good.
Have you setup the Demo yet?
/rh
+1
+1 from me for WanGuard.
I have this running taking 2x 10G span ports of our network. We are able to
mitigate an attack within 7 seconds (local filtering where transit can
handle) and if it gets to the point that transit can not handle the attack
it moves the /24 related to the attack to a DDoS mitigation cloud.
Once setup correctly. very good product - it's been running for 8 months
now and hasn't had any issues. It's been very reliable.
Richard, I have always found their support team to be great. If I put a
ticket in it's always replied to by the time I wake up. Time Zone is the
killer here being over in .au.
Regards,
Nick
We (AS55803) have also been using WANGuard for well over a year, and as with the other comments.. it has been very reliable and integrates quite well with literally anything you want.
Regards,
Matt.
I'll bite - (roughly) how many times has it triggered and mitigated an actual
DDoS during those 8 months? We probably draw different conclusions from "8
months and 1 DDoS" reliable and "8 months of 5-a-week" reliable...
I think that would definitely depend on how the network is base-lined.
That is sometimes more of an art than a science.
- - ferg
- --
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
Some base numbers as it stands now:
Total Anomalies: ~8000
Total Prefixes in BGP: ~400
We don't mitigate _everthing_ - if our transit can handle the inbound then
it doesn't do anything - just alert and take a pcap dump for further
tuning. If we see congestion, it moves prefixes around to a scrubbing
center to clean the traffic before returning back to us.
This is also just domestic AU, international traffic is on another system
that gets scrubbed 24x7.
We have close to 20 policys & threshold templates for all different
scenarios.
Though I was talking about the stability of the software, whilst dealing
with around 20Gbit raw data.
I've only seen one issue (thinking about it now, I need to raise a Feature
Request for this) - which is the ability to use the number of source IPs as
a metric to compliment pkt/s and bits/s thresholds. Would be nice to
trigger a rule if "total num src IPs" >= 100 + 600M of TCP then start
moving, but if only 600M TCP and 1 SRC IP, then leave it as it is.
Regards,
Nick
We have processed just under a million anomalies with this software, we use the Chelsio cards for filtering. We had some troubles with packet loss on the filter side until we started using those which were a new feature in the latest release.
If you have any questions I would be happy to answer them.
Regards,
Nick Rose | CTO
Enzu Inc
nick.rose@enzu.com
www.enzu.com <http://www.enzu.com/>
We tested it a while back and found that it was fine for single source attacks but fell over with multiple sources. Has that changed?
I have not experienced any problems with multiple source attacks at the same time. This is also including with multiple destinations too.
I guess it really depends on what you expect the product to do, and how you write integration too.
Regards,
Matt.
Aaron,
Do you remember which release or when it was ?
Are you talking about detection or filtering which failed for many sources targeting a single destination ?
Which sensor did you test, packet sensor or flow sensor ?
Thank,
Regards,
- Marcel
We've tried their products off an on for the past 3-4 years. Here are
my impressions:
* UI stuck in 1999. Can't click zoom, drill down, etc.
* Inflexible UI. Want a bandwidth graph with only egress or ingress? Too bad.
* Inexpensive. I don't like that it's licensed yearly, but it's not
too much money.
* Inaccurate flow processing. Do you have iBGP peering sessions
between border routers? WANGuard will struggle mightily to correctly
classify the traffic as internal or external.
* Yes, it runs out of memory quickly during a spoofed SYN flood with
many sources. This is due to setting the Top generator to Full. If you
just want to mitigate and not have any insight into network data, set
this to Extended and you'll be fine. But if you want to use
WANGuard/WANSight as a network intelligence tool as well, you need to
set the generator to Full and it will fall over.
* Doesn't process IPFIX flow data properly. There's an old thread on
the j-nsp list about this. Basically their support claims Juniper is
broken (which I don't doubt) but then refuses to work around the
issue. None of our other flow processing tools have these problems.
* Support is responsive at times and is always cranky. I brought them
two bonafide bugs in their product that they refused to admit. It got
to the point where I asked for my money back and I think someone in
sales lit up their support team. I get the feeling that the support
team is staffed with employees who really don't like their job or
working with customers. A bad combination.
* The TAP generators with Myricom cards work well. The docs say you
can use SolarFlare for TAPs but they don't work at all. Again, they
blame SolarFlare and say that the cards are too complicated....but
fail to update their documentation saying this.
* Doesn't support any kind of layer 7 detection or filtering. It's all
very rudimentary layer 3-4 stuff. Considering how easy it is to block
layer 3/4 attacks on your own, their filtering clusters don't offer
much value.
* No real scale out solution on the detection side. It's basically
scale up your server or use clunky tech like NFS to share out
directories across managers.
* Works well enough to get you a rough idea of what's going on. It's
also decently cheap.
We use it as one part of our attack detection toolset. We don't use it
for on-site attack mitigation. I'd recommend it if you don't want to
use flow data and only want to use it for intelligence on TAP ports.
-richard
(I debated starting a new thread, only to have someone point me to previous ones vs. replying to an old post. I thought the latter was less offensive.)
Did you find anything else near the price range that didn't have these deficiencies?
As an eyeball network, would I have much to worry about regarding non-layer3/4 attacks?
"Considering how easy it is to blocklayer 3/4 attacks on your own, their filtering clusters don't offer much value." I am aware of manual ACLs, but are there other automated methods (near this price range) to handle the 3/4 attacks?
"it runs out of memory quickly" How much memory are we talking here? Reasonable to mitigate that downside by just stuffing more RAM in the box?