hi ramy On 08/26/15 at 12:54pm, Aftab Siddiqui wrote:

...

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 ? - what (ddos) problems are you trying to resolve ? - 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 ... usually, arp-based ddos attacks requires fixing your infrastructure, a ddos appliance may not help you usually, udp and icmp ddos attacks can only be resolved by the ISP or scrubbing centers - if you limit udp/icmp at your appliance, the damage is already done, since those packets used your bandwidth, cpu, memory, diskspace and your time spoof'd source addresses can only be resolved by having the ISP preventing outgoing spoofed address ( fix egress filters ) at their edge routers 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 i want the attacking zombies and script kiddies to pay a penalty for attacking my customer's servers to sustain a 100,000 tcp packets attack requires lots of kernel memory ( 100,000 packets * 1500 byte/packet * 120 seconds ) for 2minute tcp timeouts there are 65,535 tcp they could be attacking ... imho, an ssh-based solution or apache-based solution would be useless ... add another 65,535 udp ports always keep your servers up to date ... patch your OS, apps, etc, etc volumetric attacks can only be resolved by (expensive) ddos scrubbers or installing your own geographcially separated colo in usa, europe, asia like the scrubbers ... if you are high profile target, the ddos attackers probably has more bandwidth than you could afford and the ddos attacks will probably make the evening news magic pixie dust alvin # DDoS-Mitigator.net/Competitors # DDoS-Mitigator.net/InHouse-vs-Cloud # DDoS-Simulator.net #

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@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 #