RE: [load balancing] Re: DoS Protection

From: Chris Sherwood (csherwoodIZZATrapattoni.com)
Date: Tue Jan 21 2003 - 18:29:35 EST

  • Next message: David Santeramo: "Re: [load balancing] Anyone having/had issues with spontaneous failover on a CSS 11150 with 2 Gigabit ports?"

    Speaking from an admin point of view, I'd have to say that I'm
    incredibly impressed with the NetScaler's DoS/request policy filter
    engine. We originally bought a pair of NS9400's simply for the HTTP
    compression, but they have since replaced our F5 Big/IP HA's as our
    primary load balancer. The HTTP compression module lets the units pay
    for themselves in a matter of months (cut our bandwidth consumption from
    31Mbps to ~14-15Mbps instantly, offsetting the need for additional
    DS3's), but when you throw in the load balancing, SSL acceleration, TCP
    offload, AND DoS protection, these units can't be beat.

    Plus, you don't have to have a networking degree from MIT to use the
    DoS/request policy filter options. With a 2 line command in the
    NetScaler config, we were able to give script kiddies looking for Code
    Red/Nimda variants (cmd.exe, root.exe, etc.) a cute little message.
    Turn off your friendly HTTP error messages in IE and check it out!:

    http://maris.rapmls.com/cmd.exe

    -Chris Sherwood
    Systems Administrator
    Rapattoni Corporation

    -----Original Message-----
    From: shawnIZZATnunleys.com [mailto:shawnIZZATnunleys.com]
    Sent: Tuesday, January 21, 2003 1:08 PM
    To: lb-lIZZATvegan.net
    Subject: Re: [load balancing] Re: DoS Protection

    Allen,

    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-
    clear data.

    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. :)

    Shawn Nunley
    Director of Technology Development
    NetScaler, Inc.

    Quoting "Bettilyon, Allen" <allenIZZATabout-inc.com>:

    > Andy,
    >
    > I am interested in the DoS protection that you have implemented. I am
    > currently evaluating many different vendors looking for the best DoS
    > protection.
    >
    > Are the NetScalar 9000i's doing the DoS protection as well as the SSL
    > decryption?
    >
    > Do you know how the DoS protection works on the Netscalars? Is it
    > signature based or heuristics based? Could it handle a Distributed
    > attack?
    >
    > 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
    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



    This archive was generated by hypermail 2.1.4 : Tue Jan 21 2003 - 18:37:14 EST