[WEB SECURITY] thoughts on WAF deployment options?

Tue Apr 22 18:10:25 EDT 2008

Imperva isn't OoB, IIRC...  They have 2 modes, in-line, or reverse proxy.

Rafal (Ralph) M. Los
IT Security - Response | Mitigation | Strategy

E-mail:  rafal at ishackingyou.com
Direct:  +1 (404) 606-6056
 - gPGP:    0xFFC63B33
 - Blog:    http://preachsecurity.blogspot.com
 - Web:     http://www.ishackingyou.com
 - LinkedIn:http://www.linkedin.com/in/rmlos

--------------------------------------------------
From: "Arian J. Evans" <arian.evans at anachronic.com>
Sent: Tuesday, April 22, 2008 3:58 PM
To: "Ryan Barnett" <rcbarnett at gmail.com>; "WASC Forum" 
<websecurity at webappsec.org>
Cc: <joe at cyberlocksmith.com>
Subject: Re: [WEB SECURITY] thoughts on WAF deployment options?

>> One correction - Breach's WebDefend is out of line (you had it in the
>>  inline transparent bridge group).
>
> Thanks.
>
> To clarify my post (correct me again if wrong): Mod runs inline proxy
> only, and WedDefend OoB. (I knew there was another OoB product
> I'd seen besides Imperva, but couldn't remember it)
>
> To be clear -- I am not working with Breach WebDefend products.
> The *only* WAF I've worked wtih recently is F5, though I've worked
> with most of them on the market over the last 7 years.
>
> I *have* heard multiple positive things about WebDefend's technology
> from both technical peers at VARs, and several customers I work with.
>
> While second-hand info, they are opinions from smart folks, hence
> my recommendation to put that on the investigation list.
>
> btw// I hear a lot of *talk* about Modsecurity, but I don't know anyone
> who actually runs it (another topic of discussion).
>
> Thanks for catching me. Cheers
>
> -ae
>
>
>
>>
>>  On 4/22/08, Arian J. Evans <arian.evans at anachronic.com> wrote:
>>  > <inline> I wrote a paper on this about 5 years ago, that
>>  > continues to evolve and maybe it's finally time to release it.
>>  > I've held off because I didn't want to alienate any WAF vendors.
>>  >
>>  > Disclaimer at bottom
>>  >
>>  > On Tue, Apr 22, 2008 at 9:56 AM, Joe White <joe at cyberlocksmith.com> 
>> wrote:
>>  > > Hey guys, I am hoping this thread does not spiral out of control 
>> over
>>  > >  the contention that a WAF is not really a "firewall".  =)
>>  >
>>  > No worries. I beat that dead horse previously because of all the
>>  > recent uninformed garbage about Layer 3 "firewalls" and webappsec.
>>  > On to the meat:
>>  >
>>  > >  Seriously, I am currently evaluating WAFs for a large SaaS 
>> deployment
>>  > >  and am curious to get your thoughts on benefits of various 
>> deployment
>>  > >  options.  Here are my thoughts to get the ball rolling.
>>  >
>>  > FWIW -- you are not alone. I've been talking too/work with a lot of
>>  > folks in your shoes.
>>  >
>>  > >  re:  out-of-band deployment
>>  > >  This seems attractive on the surface and potentially offers the 
>> least
>>  > >  obtrusive to the existing architecture but upon closer examination, 
>> I
>>  > >  am not convinced it makes sense because
>>  > >   1)  relying on TCP Resets (RST) to block attacks is problematic at 
>> best
>>  > >   2)  requires extra expense/installation of a network tap. 
>> Otherwise
>>  > >  you have one more device asking for a span/mirror port that is 
>> prone
>>  > >  to 'clipping' of data once the ports it is mirroring get spikes in
>>  > traffic, etc.
>>  >
>>  > OoB is the most common deployment I've seen in the real
>>  > world.  I have had experience, and confirmed, over and over,
>>  > that all of the WAFs tend to crash & burn on production systems.
>>  >
>>  > With no exceptions. The only thing I've seen vary is the frequency
>>  > with which they fail. It's a tough problem though. People do CRAZY
>>  > things with their webapp syntax, and those things have to parse it.
>>  >
>>  >
>>  > >  re:  in-line (Layer 2) bridge deployment
>>  > >  I am told from WAF vendors that this is the most common deployment
>>  > >  scenario when a dedicated WAF appliance is used.  As I investigate
>>  > >  this further, it seems to be the most robust option given the
>>  > >  redundancy and load balancing options for deployment and since the
>>  > >  bridge can be configured to fail open.
>>  >
>>  > No one has stats on "common deployment scenarios". My
>>  > observations are split 50% roughly between OoB (Imperva)
>>  > and inline proxy (F5, Mod, Breach, and Citrix).
>>  >
>>  >
>>  > >  re:  reverse proxy deployment
>>  > >  I am conflicted on this because I fear that it may add more 
>> complexity
>>  > >  to the network architecture than any of the other options but I am
>>  > >  also intrigued by the possibility of session protection that the 
>> proxy
>>  > >  option offers in terms of digitally signing cookies, etc.
>>  >
>>  > I do not know of anyone who has gone this route, that
>>  > has meaningful web app traffic (short of a few small
>>  > companies) that has succeeded. I know a lot of folks
>>  > that have failed. A very large bank recently told me
>>  > they did this and loved it , but then they told me that
>>  > they just started rolling it out 2 weeks ago. Knowing
>>  > how poor performance and uptime is for the WAF they
>>  > are rolling out, I seriously doubt they find success.
>>  >
>>  > So you could still keep checksum/state of cookies OoB or
>>  > L2 mode, vendors argue. But they can't and don't. Too
>>  > expensive performance-wise.
>>  >
>>  > There are some really smart things that can and
>>  > must be done inline, but the only vendor I've heard
>>  > tell me a smart inline story regarding uptime and
>>  > failover is F5. (note disclaimer below)
>>  >
>>  > I've heard nothing bad about F5 inline re: outages,
>>  > but I have many horror stories from the others.
>>  >
>>  >
>>  > >  re:  ModSecurity (multiple deployment options)
>>  > >  We have lots of Apache expertise and philosophically, I am prone to
>>  > >  support the open source model but at what point does ModSecurity
>>  > >  become impractical?  How many Apache servers in the web farm does 
>> it
>>  > >  take for ModSecurity to become too much of an administrative 
>> burden?
>>  >
>>  > n+ 1 is a burden, IMO, for something this complicated.
>>  > I know of hardly anyone running mod in production,
>>  > minus a few government sites that rarely get it configured
>>  > properly w/out weeks (or months) of consulting time.
>>  >
>>  > >  any thoughts?
>>  >
>>  > Yes, and they are:
>>  >
>>  > 1) YMWV (your milage will vary)
>>  >
>>  > Pick a few scenarios, and make sure you test in your environment.
>>  > This is the only way to achieve success.
>>  >
>>  > 2) Imperva & F5 seem to have the most clients.
>>  >
>>  > 3) I get nothing but excellent feedback about Breach's webdefend 
>> solution.
>>  >
>>  > 4) Another important facet is how you want to deploy,
>>  > e.g. "Magic Elf" mode or "Virtual Patch" mode.
>>  >
>>  > Many vendors like Imperva and Citrix cling to this
>>  > "magic elf mode" where they magically secure and
>>  > block everything. Imperva has some notion of policies
>>  > that some clients have told me don't work. I'm not
>>  > sure what the Citrix solution looks like today, but
>>  > the marketing 1.5 years ago was fairly insane.
>>  >
>>  > There's a big difference between point-fixing issues
>>  > you know about, and full on magic-elf inside the
>>  > box configuring it mode.
>>  >
>>  > Disclaimer: I work for a company that is partnered
>>  > with F5, and Breach, and could be partnered with
>>  > other WAF vendors in the future.
>>  >
>>  > Anyone who knows me professionally knows that
>>  > this will not change my candor and honesty about
>>  > the strengths and weaknesses of said products.
>>  >
>>  > Good subject. I'd like to see more case studies
>>  > and bakeoffs by competent folks. (none of the
>>  > online securty/infoworld mag type reviews I've
>>  > seen have any useful webappsec facts).
>>  >
>>  > There's some folks on this list that have performed
>>  > bakeoffs of WAFs recently, and hopefully they
>>  > can publish info, but I believe the vendors have
>>  > tied the hands of everyone I've talked to (so they can't)
>>  >
>>  > What a shame. I think the database industry
>>  > does this same thing though too. Probably
>>  > most software companies avoid bakeoffs that
>>  > are out of their configuration control, for
>>  > legitimate reasons.
>>  >
>>  >
>>  > --> Contact me offline if you want to have a
>>  > more candid discussion including specifics
>>  > about what vendor deployments I am aware
>>  > of that have succeeded and failed.
>>  >
>>  > Cheers,
>>  >
>>  > --
>>  > --
>>  > Arian J. Evans.
>>  >
>>  > I spend most of my money on motorcycles, mistresses, and martinis. The
>>  > rest of it I squander.
>>  >
>>  > ps - Remember to block Finger.
>>  >
>>
>>
>> > ----------------------------------------------------------------------------
>>  > Join us on IRC: irc.freenode.net #webappsec
>>  >
>>  > Have a question? Search The Web Security Mailing List Archives:
>>  > http://www.webappsec.org/lists/websecurity/
>>  >
>>  > Subscribe via RSS:
>>  > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>  >
>>  >
>>
>>
>>  --
>>  Ryan C. Barnett
>>  ModSecurity Community Manager
>>  Breach Security: Director of Application Security Training
>>  Web Application Security Consortium (WASC) Member
>>  CIS Apache Benchmark Project Lead
>>  SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
>>  Author: Preventing Web Attacks with Apache
>>
>
>
>
> -- 
> -- 
> Arian J. Evans.
>
> I spend most of my money on motorcycles, mistresses, and martinis. The
> rest of it I squander.
>
> ps - Remember to block Finger.
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> 

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]