Interesting Christian, you bring two points that I find somewhat related:
importance of the core rules and lack of general acceptance of WAFs.
I feel that overreliance on the core rules somewhat defeats ModSecurity role
as a WAF and blurs the line between WAF and IPS. These days to many
companies, and a few open source projects, claim to offer WAFs while
actually offering little more than an HTTP aware IPS. The frequent use of
ModSecurity with only the core rules helps to make this claim possible if
not plausible. I personally see learning, management and differentiating
security features as keys for enlarging the user base as they differentiate
ModSecurity and not just make it better as would enhanced core rules.
From: Christian Folini [mailto:christian.folini@...]
Sent: Friday, November 13, 2009 10:39 AM
To: Ivan Ristic
Subject: Re: [mod-security-users] What is holding ModSecurity back?
On Thu, Nov 12, 2009 at 09:58:13AM +0000, Ivan Ristic wrote:
> I have this nagging feeling that ModSecurity is not used as widely as
> it could be, and I've been trying to figure out the root cause.
Still a good question. We have talked about this before, but I like
the discussion evolving online this time. This sounds like a real
community evolving. At last.
This is my take on the question. The most important points have been
mentioned before, so I won't repeat them.
I have a special view on ModSecurity, as I work for an enterprise
that uses ModSecurity on 200 seperate Apache instances.
The sale of ModSecurity to Breach was a surprise, leaving Breach
was another surprise, Ivan. This made ModSecurity and the development
look unreliable. Those in the know see the continuity. Those outside
the know just see a strong lead developer who is not looking like
he knows what he really wants.
Signing off IP to a commercial company is not an invitation for
contributions, but I guess everybody is aware of that.
GUIs help to sell stuff. The learning curve is a lot steeper without
a GUI. However, I am a strong believer in rule-writing by hand.
Unless you really understand HTTP and you really understand
ModSecurity rules, you are not able to protect your application.
A GUI only stands in the way. Maybe a better console (speak:
shiny features nowbody needs, but everybody wants) would help.
ModSecurity would have a bigger user base with a decent GUI -
and the quality of the installs would be worse, giving ModSecurity
a bad name.
Not sure this is really true, but at least it is a bold statement.
Core Rules: Extremely helpful. I can't express how much I appreaciate them.
The usability features that allow to manipulate them easier are a big
win. More of that would be very welcome.
A quick glimpse how we use ModSecurity on 200 Instances:
- Core Rules in two variants: log-only and blocking
- Enterprise Rules
- Service-specific Rules
That way we were able to roll out our own rule to detect the known
exploits for CVE-2009-3555 within a few hours. Updates to core rules
are done via a configuration package that is installed on all
servers. Service-specific rules work without a change to the other
rules. If there are false positives, we remove the core rule in question
for a given request pattern in the service-specific section. Thanks to
the late extension in ctl statements, this is very easy now.
What would be great is the community helping to extend Core Rules
and documentation around it. This is where I feel bad as I would have
the know-how to help there, but I do not manage to get my ass up.
One thing I would like to see is a documentation covering every rule,
categorizing it and explaining it in plain English and adding a
command line statement (-> i.e. curl) on how to trigger the rule.
So the core rules are the key to spread ModSecurity.
I do not think opening ModSecurity to run within or in close connection
with IIS will do any good. If you can't sell it to the Apache community
do not even think about selling it to IIS people.
Still I think the uncoupling ModSecurity from Apache would be great,
but for a whole different reason: Power and Flexibility.
If ModSecurity is a standalone process, then you'll be ablt to update rules
live. Seeing Request flow in and out of ModSecurity makes it a real-time
tool. Ultimately, I would want to have a console where I can filter for
requests, block them individually or sandbox them as they come in.
More books on ModSecurity would be really helpful. But then teaching
ModSecurity at the Owasp Europe 2009 conference I got the impression the
interest in basic level ModSecurity knowledge is not really existing.
Either nobody wants the knowhow, or everybody is able to get up and
running with the documentation there is. Or my trackrecord as a teacher
is just so bad, no sane person would pay me money to teach them
Otherwise, I second the idea that WAFs are not taking off and
as long as WAFs are not taking off, ModSecurity won't take off
either. Still I believe the trend goes in direction of whitelisting.
This is where WAFs have an important role to play. Initiatives
to share information between applications and WAFs in order to generate
whitelisting rules are great - but too early.
As long as WAFs are not taking off, it is smart to improve ModSecurity,
step by step. Make it a mature product with years and years of
stable development and a very good track record. One day it might
The best generic advice anyone can give in life is: think for yourself.
--- Mark Burgess
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
mod-security-users mailing list
Commercial ModSecurity Appliances, Rule Sets and Support: