[prev in list] [next in list] [prev in thread] [next in thread]
List: loadbalancing-l
Subject: RE: [loadbalancing] Re: [load balancing] f5 transparent
From: "Iztok Umek" <iztok () si-con ! com>
Date: 2006-08-08 21:16:13
Message-ID: 002001c6bb2f$e0eaa950$0201a8c0 () mollie
[Download RAW message or body]
Jay,
Since you seem to be familiar with Netscaler, how does it deal with 0-day
type of D/DoS attacks? Say quick propagating worms.
SYN cookies is great but there is way more to D/DoS protection then SYN
cookies. Worms can cause DoS attack yet they complete they SYN/SYN-ACK/ACK
cycle and do look as "normal" traffic from that perspective. Not to mention
that the mere usage of SYN cookies can expose your unit to being DoSed.
We all know that 0-day is a term that many use in different ways. For me it
means that box "out of the box" has certain capabilities to protect your
network from such attack without the need to upload special signatures that
you got from your vendor the same day.
Behavioral DoS seems to be the way to go in this field.
I would rather stay in the LB field however. How does LB in question achieve
GSLB?
What methods are available for GSLB solution in Netscaler (or any other
GSLB)? How do you make sure that if I am redirected to one datacenter and
server that I stay there for the rest of my session and if by any chance I
get different DNS result and end up at different location, how do you know I
am at the wrong place and I need to return to my original server and how do
you get me there?
> -----Original Message-----
> From: owner-lb-l@vegan.net [mailto:owner-lb-l@vegan.net] On
> Behalf Of Jay Bivens
> Sent: Tuesday, August 08, 2006 11:12 AM
> To: lb-l@vegan.net
> Subject: [loadbalancing] Re: [load balancing] f5 transparent
>
> Correction: without the MSS limitations
>
>
> On 8/8/06 10:19 AM, "Jay Bivens" <wjbivens@digitalme.com> wrote:
>
> > Iztok,
> >
> > It's probably safe to say that the NetScaler could perform a better
> > Dos/DDoS protection then an IPS solution. It used to be that the
> > NetScaler could handle 1.2 Gbps of SYN requests before maxing out.
> > I'm sure that number has gone up since the old days.
> >
> > And of course this isn't using the drop the first SYN
> packet trick or
> > IP database, this is just with SYN cookie technology with the MSS
> > limitations so it pretty much superior to most IPS
> solutions out there
> > regarding this kind of attack.
> >
> > Sincerely,
> >
> > Jay Bivens
> > IronPort Systems
> >
> >
> > On 8/8/06 2:01 AM, "Zafer Berber" <zafer@prolink.com.tr> wrote:
> >
> >> your right, i dont want use like this topology, but customer wants
> >> try like this and he wants compare with netscaler,
> becauase he tested
> >> netscaler in transparent mode behind router and he want
> from me put
> >> the bigip like netscale and compare the results then this network
> >> diagram not usable customer know this, he only want
> tthis, so if i
> >> can use bigip transparent mode, how can i do this, do i
> need set self
> >> ip or vip ip address? could you explain me please
> >>
> >>
> >> regards
> >>
> >> zafer
> >>
> >> On Saturday 05 August 2006 14:20, Iztok Umek wrote:
> >>> If it is not simple SSL offload to provide IPS capability but to
> >>> provide load balancing as well, then the original solution is ok,
> >>> with exception that then yes I would put it behind
> firewall and use
> >>> two IPS (or IPS that supports multiple segments) to
> handle it (one before FW one behind FW).
> >>>
> >>> Actually I would go even step further in my security paranoia and
> >>> not only use IPS inspecting the traffic but have good SSL
> offloaded
> >>> with application firewall module to do the job. I would always
> >>> suggest you have good IPS with DoS/DDoS protection in
> front of the
> >>> firewall as your firewall is a precious resource that
> needs protecting as well.
> >>>
> >>> Issues come in financial institutions where it is
> required that you
> >>> keep encrypted traffic until it hits the servers. In such
> case, what do you do?
> >>>
> >>> You have two options. Use IPS with capability to inspect
> SSL traffic
> >>> without terminating it (they do exist - look under Server
> side SSL
> >>> Inspection). And/or use SSL offloader with good
> application firewall
> >>> module that allows backend encryption.
> >>>
> >>> This is now general SSL application loadbalancing and protection
> >>> debate on the architecture. Nothing really to do with
> specific implementation.
> >>>
> >>> In the security field we've noticed that attacks against
> SSL servers
> >>> is becoming an increasing type of evasion technique.
> >>>
> >>>> -----Original Message-----
> >>>> From: owner-lb-l@vegan.net [mailto:owner-lb-l@vegan.net]
> On Behalf
> >>>> Of Hamish Marson
> >>>> Sent: Friday, August 04, 2006 12:31 PM
> >>>> To: lb-l@vegan.net
> >>>> Subject: [loadbalancing] Re: [load balancing] f5 transparent
> >>>>
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Iztok Umek wrote:
> >>>>> You are using Load balancer to simply decrypt the traffic
> >>>>
> >>>> so IPS can
> >>>>
> >>>>> look at it and you are not load balancing it at all?
> >>>>>
> >>>>> Waste of resources. You need to deploy IPS solution capable
> >>>>
> >>>> of working
> >>>>
> >>>>> with SSL offloading engine. This way you don't even have to
> >>>>
> >>>> terminate
> >>>>
> >>>>> SSL before it hits the server.
> >>>>>
> >>>>> Here is my suggestion:
> >>>>>
> >>>>>
> >>>>> Router --- IPS --- Firewall ---
> >>>>>
> >>>>>
> >>>>> SSL Webserver
> >>>>
> >>>> Personally I'd recommend against doing it this way...
> The IPS and
> >>>> the SSL offload should be behind the firewall. You could have
> >>>> another IPS external to the firewall of course as well.
> >>>> The router should be configured to do filtering of RFC private
> >>>> addressing etc and other 'easy' stuff. e.g. drop M$
> ports known to
> >>>> contain problems such as SQLServer, DCOM, etc.
> >>>> Or you could run full-blown cisco firewall code on it.
> >>>>
> >>>> BTW This isn't simply using the SL offload to provide
> IPS capability.
> >>>> It's also offloading the SSL to a hardware solution (Assuming
> >>>> you're using something bigger than a 1500). Which means your
> >>>> webserver can handle much more traffic that if it had to
> do the SSL
> >>>> itself in software.
> >>>>
> >>>>
> >>>> Hamish.
> >>>> -----BEGIN PGP SIGNATURE-----
> >>>> Version: GnuPG v1.4.2 (GNU/Linux)
> >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >>>>
> >>>> iD8DBQFE03ZR/3QXwQQkZYwRAiOAAKC3pm4nv9TwBmdqp9QlRTD6iZvmAwCfa8o5
> >>>> uji254tEsnIyoDImZ0b4VSE=
> >>>> =ks16
> >>>> -----END PGP SIGNATURE-----
> >>>>
> >>>> ____________________
> >>>> The Load Balancing Mailing List
> >>>> Unsubscribe:
> mailto:majordomo@vegan.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:majordomo@vegan.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:majordomo@vegan.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:majordomo@vegan.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:majordomo@vegan.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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic