Good day all,
Anybody here has experienced a PoC for any anti DDoS appliance, or already
using a anti DDoS appliance in production and able to share his user
experience/review?
We need to collect good reviews from people whom got their hands dirty with
the configuration/attack mitigation, real experience.
Thanks,
Ramy
Is this for publication? What are you paying for such reviews? Who is the audience?
Hi,
Anybody here has experienced a PoC for any anti DDoS appliance, or already
using a anti DDoS appliance in production and able to share his user
experience/review?
only interested in appliance? why not scrubbing services? is it for own use
(industry reviews before purchase) or some article/publication/research?
Best Wishes,
Aftab A. Siddiqui
Hello Aftab,
Sure we are interested in scrubbing centers, and we will have an on premise
appliance as well, but let's make the scope of this thread limited to the
on premise appliances.
If you want to discuss a certain scrubbing center subscription, let's have
this chat offline.
Thanks,
Ramy
hi ramy
Thank you Alvin, I have just remembered that I wanted to reply to your
previous input on Wanguard versus the other vendors in the market, I will
reply this there.
I can't get exactly what you are doing, do you have your own mitigation SW?
If so I would like to know more about it.
hi ramy
>
> > Anybody here has experienced a PoC for any anti DDoS appliance, or
already
> > using a anti DDoS appliance in production and able to share his user
> > experience/review?
> >
>
> only interested in appliance? why not scrubbing services? is it for own
use
> (industry reviews before purchase) or some article/publication/research?see previous similar thread for some "real world reviews by folks"
http://mailman.nanog.org/pipermail/nanog/2015-April/074410.html
i think a "benchmarking ddos lab" would be fun to build and publish
findings..
to test all the ddos appliances from those competitors willing to
participate---
for your "reviewing" or collecing info from folks ..
- what's your metrics that is important to you ?
Our important metrics includes but not limited to the following:
- Ability to mitigate all kinds of volumetric DDoS attacks.
- Ability to mitigate application level attacks for at least HTTP, HTTPs,
SMTP and DNS.
- Time-to-detect and time-to-mitigate.
- False positives.
- Response time to the management plan.
- Ability to sniff packets for further analysis with the support.
- Granularity of detection thresholds.
- Percentage of DDoS attack leakage.
- Multitenancy (We are an ISP)
- what (ddos) problems are you trying to resolve ?
- Fast to detect/mitigate appliance, no problem to work inline.
- do you want to see the ddos attacks in progress and how you're being
attacked
http://ddos-mitigator.net/cgi-bin/IPtables-GUI.pl- do you want 100% automated ddos defense with zero false positives
my $0.02 ddos experiences n summary over the years, aka mitigation in
production use ...my requirement: all tcp-based ddos attacks must be tarpit'd ... ddos
attacks
are now 1% of it's peak a few years ago where "firefox google.com"
wouldn't come up- you must be able to distinguish legit tcp traffic from ddos
attacks
which is ez if you build/install/configure the servers properly
Could you please give more details on this?
i want the attacking zombies and script kiddies to pay a penalty
for
attacking my customer's servers
Could you please give more details about how to tarpit?
hi ya ramy
- ddos mitigation is NOT one appliance or cloud scrubber ...
you'd require multiple layers of different ddos mitigation methodologies
Thank you Alvin, I have just remembered that I wanted to reply to your previous
input on Wanguard versus the other vendors in the market, I will reply this
there.
per your comments on the other posts, its okay to disagree etc, etc ...
everybody has their views .. maybe i wasnt clear enough with what i was saying too
I can't get exactly what you are doing, do you have your own mitigation SW? If
so I would like to know more about it.
you can download the free version for testing ..
http://DDoS-Mitigator.net/Download
...
for your "reviewing" or collecing info from folks ..
- what's your metrics that is important to you ?Our important metrics includes but not limited to the following:
- Ability to mitigate all kinds of volumetric DDoS attacks.
"mitigating all kinds of volumetric DDoS attacks" means you'd probably fail
most of the time ...
the (simulated) ddos attackers can always, 100% of the time, generate more
traffic that you want to defend against in hw or $$$ or time or staff ...
i say, first defend against all the current DDoS attacks you are getting
every minute of every day .... that'd already take lots and lots of time
and $$$ and resources as is ... and volumizing it, to 1,000,000 packets/sec
or more 10M or 100M packets/sec doesn't solve anything ...
imho, the only way to defend against any volumetric ddos attacks that
exceed your bandwidth capacity is to buy more capacity from the ISP
or from (more expensive) DDoS cloud scrubbers
- Ability to mitigate application level attacks for at least HTTP, HTTPs, SMTP
and DNS.
it should be trivial to defend against incoming http/https/smtp ddos attacks
- the so called "10 minute problem"
defending against DNS is almost equally trivial ....
- 53/udp is used for dns queries ...
- 53/tcp is used for zone transfers between primary and secondary DNS servers
thus, all incoming tcp packets to a DNS server are DDoS attacks
except your own primary and secondary dns server ip#
if UDP attacks against DNS servers exceed your bandwidth, again, you have to
buy more bandwidth or have the ISP or the ddos scrubber cloud drop it for you
- limiting replies to incoming udp or icmp is useless since it already
used your bandwidth, cpu, memory, disk and the expensive staff's time
- we're all assuming your DNS server is closed for recursive queries
to prevent DNS amplification attacks ...
- similary fix/patch NTP servers and ntp clients
- if the ISP doesn't want to help defend against incoming UDP/ICMP
attacks, than you're kinda screwed ... time to find a new ISP
similarly, always turn off replies to ping broadcast from the outside to
prevent smurf'ing yourself
- Time-to-detect and time-to-mitigate.
ddos mitigation should be automated ... people cannot watch and defend the
servers watching millions of packets per second flowing thru the servers
more importantlty, if people are looking at the packets and if you're
sending/receiving confidential data, do you really want 3rd party eyeballs
looking at all your packets, and regulations say they should be certified
eyeballs and certified colo facilities too
- False positives.
hard to avoid which requires careful planning and lots of testing
- Response time to the management plan.
why would "management" dictate ddos mitigation policy vs IT security folks
- Ability to sniff packets for further analysis with the support.
too much work ... you have million or gazillion ddos packets per second
to look at and you will NOT be able to see the attack from the legitimate
packets or more importantly, might not care anymore ...
- Granularity of detection thresholds.
seem arbitrary to hit some threshold ...
either it IS a ddos attack or it's NOT ... it should be fairly clear
- Percentage of DDoS attack leakage.
i dont understand the "leakage"
- Multitenancy (We are an ISP)
�
good .... the customers can help you determine legit traffic from
DDoS traffic
- Fast to detect/mitigate appliance, no problem to work inline.
�
as is always the case, anytime you have a server inline, be sure
they are crossed connected so that the other server can take over
in case of hw failure
my requirement: all tcp-based ddos attacks must be tarpit'd ...
...
Could you please give more details on this?
tarpit holds any incoming tcp-based connection attempt open for say 2minutes
during which time the attacking server is stuck
if the zombie ddos attacker sends 100,000 tcp packets/sec against
your webserver or mail server, they'd have to have a lots of kernel memory
( 100,000 packet/sec * 1500byte/packet ) * 120 sec tcp timeout
try sending 100,000 tcp packets/sec for 2 minutes against a
test web server with tarpits properly installed w/ the proper
iptables rules ...
( eg... any incoming tcp packet not on port 80 gets tarpit'd )
100,000 packets/sec is still an itty-bitty ddos attack
Could you please give more details about how to tarpit?
http://NetworkNightmare.net/Tarpits
magic pixie dust
alvin
--snip--
defending against DNS is almost equally trivial ....
- 53/udp is used for dns queries ...
...except when it's not. TCP is an accepted transport for DNS queries and necessary for response sizes > 512 bytes where EDNS is not in use / available.
- 53/tcp is used for zone transfers between primary and secondary DNS servers
thus, all incoming tcp packets to a DNS server are DDoS attacks
except your own primary and secondary dns server ip#
As per above, that's not entirely accurate, though you're welcome to cause some FPs by dropping legitimate DNS queries over TCP. Granted on our own recursive resolvers the percentage of TCP queries is vanishingly small to non-existent, but "all" is not correct.
- we're all assuming your DNS server is closed for recursive queries
to prevent DNS amplification attacks ...
...for different degrees of "closed". I'm assuming $dayjob for at least *some* of the folks on this list entails a service provider network of some sort, where it'd be pretty likely there are some recursive resolvers available to their customers. DNS amplification queries sourced from (or spoofed as) within customer ranges and able to reach the resolvers are still a vector.
Gartner did a report about a year ago. Not free.
https://www.gartner.com/doc/2910217/ddos-comparison-defense-approaches
I assume they don't list their testing methodology right? It always feels like they just read vendor spec sheets.
Steve Mikulasik
