[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Experience on Wanguard for 'anti' DDOS solutions
- Subject: Experience on Wanguard for 'anti' DDOS solutions
- From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
- Date: Wed, 12 Aug 2015 18:20:26 -0700
- In-reply-to: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
- References: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
hi ramy
On 08/12/15 at 05:28pm, Ramy Hashish wrote:
>
> Anybody here compared Wanguard's performance with the DDoS vendors in the
> market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?
wouldn't the above "comparison" be kinda funky comparing software solutions
with hardware appliances and/or cloud scubbers ??
comparisons between vendors should be between sw solutions,
or hw appliances vs other hw, or cloud vs other clouds
wanguard should be compared with other sw options or vendors using
sflow, netflow, jflow, etc etc
http://www.andrisoft.com/software/wanguard
http://bitbucket.org/tortoiselabs/ddosmon
http://www.github.com/FastVPSEestiOu/fastnetmon
http://nfdump.sourceforge.net
http://nfsen.sourceforge.net
wanguard - software solution using sflow
http://www.andrisoft.com/software/wanguard
arbor ---- hardware/software solutions -- "peakflow"
http://www.arbornetworks.com/products/peakflow
radware -- hardware/software/cloud solutions -- "defenseflow"
http://www.radware.com/products/attack-mitigation-service/
http://www.radware.com/Products/DefenseFlow/
nsfocus -- hardware/cloud solutions
http://www.nsfocus.com/products/
A10 ------ hardware solution
http://www.a10network.com/products
riorey --- hardware solution
http://www.riorey.com/riorey-ddos-products
staminus - hardware/cloud solutions
http://www.staminus.net/shield
# and to add to the ddos confusion ..
akamai/prolexic --- hardware/cloud solution
f5 ---------------- hardware/cloud solutions
http://www.f5.com/resources/white-papers/mitigating-ddos-attacks-with-f5-technology
fortinet ---------- custom ASIC hardware and cloud solution
http://www.fortinet.com/products/fortiddos/ddos-mitigation-appliances.html
- simulated ddos attacks should include:
==
== you are already getting hourly low level DDoS attacks from your script kiddies
== try to defend against those mostly harmless attacks first
==
#
# some trivial benchmark DDoS attacks to generate -- internally only
# - never send DDoS packets outside of your bldg/gateway
#
# DDoS-Simulator.net == generate any DDoS packets per your desires
# - use nc, socat, *perf, nping or hping to generate most of these DDoS attacks
# - use dsniff/arpspoof to break everything
#
within your own network, send few packets per second attacks
within your own network, send x,000 packets per second attacks
within your own network, send xxx,000 packet per second attacks
sustained sporadically over hours/days
- arp-based attacks
- udp-based attacks
nping -v -d1 -c 10000 --data-length 1511 --rate 12345 --udp 127.0.0.1
hping -c 10000 -d 1511 -i u 81 --rand-source -p 123 -S --udp -p 123 127.0.0.1
- icmp-based attacks
ping -c 10000 -s 1511 -i 0.00008 127.0.0.1
nping -v -d1 -c 10000 --data-length 1511 --rate 12345 --icmp 127.0.0.1
hping -c 1 -d 1501 --rand-source --file TeraByteFile.bin --icmp 127.0.0.1
gazillionPingApps
- tcp-based attacks --- ez to send malicious packets and to defend against
# 10,000 random src add
hping -c 10000 -d 1511 -i u 81 --rand-source -xxTCPflags 127.0.0.1
# -S = set SYN flag
# -F = set FIN flag
# -A = set ACK flag
- application layer tests --- http, ssh, mail and 65,532 other ports
hping -c 10000 -d 1511 -i u 81 --rand-source -p 22 -S 127.0.0.1
hping -c 10000 -d 1511 -i u 81 --rand-source -p 25 -S 127.0.0.1
hping -c 10000 -d 1511 -i u 81 --rand-source -p 80 -S 127.0.0.1
hping -c 10000 -d 1511 -i u 81 --rand-source -p 53 -S --udp 127.0.0.1
- these attack the servers or client desktop/laptops
- volumetric attacks -- almost everybody will fail this test
- volumetric attacks are pointless, you'll always fail at some point
ping -f
iperf
socat
- send spam .......................... mitigated separately ...
- send virus and worms to the list ... mitigated separately ...
- cloud solutions
- if you have regulatory compliance requirements, your options
are extemely limited to a few certified amd expensive clouds
- what triggers the packets to go to the cloud for scrubbing
- you do NOT want somebody "looking" at millions of packets to
decide to send it off the cloud for scrubbing or not
- you might NOT want to send everything to the cloud and
incurr un-necessary expenses if you're NOT under xxxGbit/sec
DDoS attacks
- ddos mitigation should be able to distinguish legit traffic
from real ddos traffic
- eg folks downloading or sending 4GB dvd or larger files
- eg silly folks sending 4GB dvd via emails
# simplified way to distinguish legit users from ddos attackers
if web servers are running only "apache",
all other packets to other ports are DDoS attacks
if mail servers are running only "sendmail",
all other packets to other ports are DDoS attacks
if ldap servers are running only "ldap",
all other packets to other ports are DDoS attacks
one way to determine legit web users from web ddos attacks
is to look into apache's error logs for bad URLs
one way to determine legit mail users from mail ddos attacks
is to look into sendmail's error logs for bad things
all servers require ssh, ntp/udp, dns/udp and should
be locked to particular IP# only ... all other
connection attempts are ddos attacks
#
# after you are done comparing all the various DDoS mitigation
# products and solutions, your conclusion might look like:
#
a) what's my ddos mitigation budget for the level of ddos attacks
i'm already getting
b) icmp and udp attacks can only be mitigated at the ISP
- you'd need to find a pro-active ddos mitigating ISP
c) arp attacks can usually be mitigated by properly configured
servers and network infrastructure
d) tcp-based attacks are trivial to mitigate
- i prefer to mitigate with tarpits to counter the
zombie's attacks, requiring their zombie servers to have
huge amts of kernel memory to sustain any tcp-based attacks
e) volumetric attacks are a nuisance and expensive to resolve and
everybody fails volumetric attacks after x,xxxGbit/sec attacks
f) if you have governmental regulatory compliance issues,
you're options are limited to using inhouse distributed colo
or finding certified ddos scrubbers with proper certifications
> Another question, have anybody from the reviewers tested the false
> positives of the box, or experienced any false positive incidents?
any "false positives" for ddos attacks are a bad thing ... especially
if you're not gonna deliver it to the end user b/c the ddos box says
"these are bad packets"
pixie dust
alvin
# DDoS-Mitigator.net/Competitors
# DDoS-Mitigator.net/Mitigation
# DDoS-Simulator.net/Malicious-DDoS
# DDoS-Simulator.net/DDoS-Simulation-Plan
#