[WEB SECURITY] thoughts on WAF deployment options?

Ryan Barnett rcbarnett at gmail.com
Tue Apr 22 17:14:34 EDT 2008

A few other comments (inline below) -

On Tue, Apr 22, 2008 at 3:56 PM, Arian J. Evans <arian.evans at anachronic.com>

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

Can you describe what you mean by "crash and burn?"  Is this from a security
perspective - meaning that failed to properly parse/interpret data and apply
rules, etc... or are speaking from an operational view where a WAF that is
particpating in the communication flow (i.e. - inline) fails.  While both of
these issues are serious, the OoB deployment addresses the later as it will
not impact the normal flow of the traffic.

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

I will second your sentiment here with regards to the "unique" web
applications out there.

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

I guess it depends on what view you are taking here - commercial vs. total
deployments.  Obtaining those types of numbers would be quite challenging.
While I can't provide 100% concrete #s on ModSecurity deployments, I can
provide some correlating data.  We track the number of downloads of Mod
(versions 1.x, 2.1.x and 2.5.x) and this month alone we have had 4663.  I
realize that download stats to not = deployments but it should give some
indications that there are a whole lot of Mod installs out there.

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

See my comment above.  I can confirm that there are many large commercial
organizations running Mod.  It is kind of interesting that both the smaller
orgs (or those with little $$$ - education) are big Mod users and then if go
all the way to the end of the spectrum and look at some of the largest,
global deployments, they too tend to move back towards Mod.  This may be a
byproduct of these shops using Apache and they have every details finely
tuned and they would rather add the ModSecurity module then to add another
piece of hardware (as scale can become an issue).

Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
Author: Preventing Web Attacks with Apache
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080422/4423fcf2/attachment.html>

More information about the websecurity mailing list