DDoS appliances reviews needed

Thu Aug 27 09:48:31 UTC 2015

hi ya ramy

- ddos mitigation is NOT one appliance or cloud scrubber ...
  you'd require multiple layers of different ddos mitigation methodologies

On 08/27/15 at 08:22am, Ramy Hashish wrote:
> 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

> On Wed, Aug 26, 2015 at 8:53 PM, alvin nanog <nanogml at mail.ddos-mitigator.net>
> wrote:
...
>     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
#
# DDoS-Mitigator.net
# DDoS-Simulator.net
#