Date: Tue Jan 21 2003 - 16:07:33 EST
The DoS protection in NetScaler is something we are very proud of, and I hope
no person is offended if I describe the technical details here (I try hard not
to 'sell', but this post cries out for accurate details in response...)
Denial of Service attacks come in many forms, but the general idea is to make
your service unavailable to legitimate customers. This can be done by
exploiting protocols (SYN Flood, for example) or by over-eating resources (GET
Flood, for example). Sometimes, the denial of service is unintentionally
perpetrated by the site owner in response to some spoofed attack, thereby
making the DoS attacker very happy.
We have several types of defense against many DoS attacks, and yes, they all
work in the presence of SSL encrypted data, assuming the NetScaler is a
termination point for the SSL traffic. Since we do back-end encryption as
well, all of the NetScaler functions work equally well on encrypted or in-the-
SYN flood protection is provided by a modified version of SYN cookie. We have
re-engineered SYN cookies in a way that overcomes some classic limitations of
the standard SYN cookie (ask me for details) and we can handle enormous rates
of SYN packets. We have seen SYN floods approaching 1 million packets/sec
that do not affect the NetScaler or legitimate traffic. Of course, we are not
a device that can ‘swim upstream’ to implement ACLs (ala Mazu and others), but
we believe ACLs fundamentally help the DoS attacker achieve his goal anyway.
We also have extensive queuing and request rate regulation to protect servers
from any kind of traffic flood. Unlike other devices, we don’t discard any
requests or tell browsers the server is busy. We actually queue the requests,
allowing the server to crank at full speed. This actually speeds up ALL the
requests, since the server doesn’t ever reach a state of performance
degradation due to overload.
Because we can queue these floods, we can do other interesting things while
requests are waiting in the queue. For example, we can prioritize the
requests and feed them to the server in a pre-determined way. This way, your
favorite customers always get to go to the ‘fast’ line if there are lines at
all. Another amazing thing that we can do here is determine if the user is
actually using a real browser… This helps prevent a GET flood from consuming
all of your resources by making sure you prioritize the requests you know are
real while serving the others at a lower rate.
There is also a robust policy engine that can filter requests based on URL
contents, length and other characteristics. This prevents things like Code
Red and Nimda from reaching your servers.
This post is growing very long, so I had better close for now, but if anyone
has questions please ask. And I sincerely apologize if this was too 'salesy'
for the list. :)
Director of Technology Development
Quoting "Bettilyon, Allen" <allenIZZATabout-inc.com>:
> I am interested in the DoS protection that you have implemented. I am
> currently evaluating many different vendors looking for the best DoS
> Are the NetScalar 9000i's doing the DoS protection as well as the SSL
> Do you know how the DoS protection works on the Netscalars? Is it
> signature based or heuristics based? Could it handle a Distributed
> Also, does anyone else out there have any experience with these types of
> products? I am leaning toward the Radware solution, but am definitely
> open to discussion.
> - Allen
> On Tue, 2003-01-21 at 04:35, Andy Gravett wrote:
> > We just recently deployed a pair of NetScaler 9000i's,in a one arm HAP
> > (high availability pair) load balancing solution into one of our clients
> > environments and the results were very interesting (and instantaneous),
> > before the installation we consulted with several vendors Radware, Array
> > to find a suitable solution as our client where trying to use Windows
> > 2000 Advanced Servers inbuilt load balancing which was slow and clunky
> > as well as Server side SSL (again was placing unnecessary stress on the
> > Infrastructure). All the vendors came back to us with solutions but none
> > seemed match the Netscaler, who actually wanted to help design a
> > solution, not just throw a load of money or boxes (rack space is very
> > expensive at a problem).
> > The NetScalers (9000i's) are now doing the SSL Acceleration, compressing
> > the content on the fly, and by virtue of the load balancing has cut the
> > server CPUs to about half.
> > Our client is happy and as their maintainer so are we as this has freed
> > resources and extended the life of their current infrastructure (and
> > meant a lot less support calls to do with problematic software load
> > balancing).
> > There was some modifications needed but these where dealt with
> > efficiently and with little or no downtime (whole installation took
> > about an hour and only half of that was downtime.)
> > Also, we have also implemented DoS protection now as well although we
> > haven't seen an attack yet...but it's nice to know we've got it if we
> > need it. Deployment was handled very professionally and quickly and the
> > NetScaler teams are a great group to work with.
> > If anyone has any further questions, please feel free to contact me.
> > Yours Sincerely
> > Andy Gravett
> > Technical Director
> > HTL Tel: 020 7232 1112
> > 16 City Business Centre Fax: 020 7232 1121
> > London Web: www.htl.uk.com
> > SE16 2XB E-mail:agIZZAThtl.uk.com
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > This Email is intended for the recipient mentioned, it's contents are
> > confidential. If you are not the intended recipient please notify the
> > sender immediately, without copying or onward transmission. In so far as
> > the message in this email contains any form of offer to enter into or
> > vary any contract as email communication is insecure such offer is
> > subject to verification by ourselves, any offer is subject to signature
> > and completion of our standard terms and business conditions.
> > Any views or opinions expressed in this message are those of the author
> > and do not necessarily represent those of Harvey Technologies Ltd or any
> > of its affiliates.
> > ____________________
> > The Load Balancing Mailing List
> > Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
> > Archive: http://vegan.net/lb/archive
> > LBDigest: http://lbdigest.com
> > MRTG with SLB: http://vegan.net/MRTG
> > Hosted by: http://www.tokkisystems.com
> The Load Balancing Mailing List
> Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
> Archive: http://vegan.net/lb/archive
> LBDigest: http://lbdigest.com
> MRTG with SLB: http://vegan.net/MRTG
> Hosted by: http://www.tokkisystems.com
The Load Balancing Mailing List
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2.1.4 : Tue Jan 21 2003 - 16:16:21 EST