On Saturday, January 01, Paul Laudanski wrote:
>
> On Fri, 31 Dec 2004, Ofer Shezaf wrote:
>
> >
> > I must point you to an interesting thread in bugtraq (see excerpts
> > below) - as you can see, people writing rules for mod_security
> > understand that the rules are limited to a specific worm but usually
> > cannot handle potential variants.
> >
> > "Santy" and "phpInclude" emphasize the need for real application
> > security measurements such as code review, application layer
scanning
> > and real time application layer security. Simpler IPS system such as
> > mod_security (as well as commercial products that cost a lot of
money
> > such as CheckPoint Web Intelligence, IntruShield or Proventia)
cannot
> > effectively handle such attacks.
>
> Actually some of the rules like the ones I have written look for what
I've
> found to be quite useful to protect against, characters such as:
>
> '
> %25
> %2527
> ://
These signatures are very much prone to false positives. As an expert
tailoring mod_security for a specific application you can use such
signatures and still be confident you are not blocking legitimate users.
But in many applications I know such signatures will block legitimate
users.
In order to use such signatures you have to carefully use mod_security
location filters and use apache configuration to limit filtering of
specific URLs, which is quite a task.
>
> Filters such as these, that do not filter on "perl" or "wget"
effectively
> catch not just the santy and phpinclude attacks, but all other kinds
of
> GET injections. Based on the sheer number of attacks I've logged,
such
> filters are effectively handling those attacks.
I would argue such as effectiveness measurement. In web site security
catching many is not difficult as so many automatic exploitation
attempts are carried out. The real problems are:
(a) Catching zero day attacks (those that you don't have a specific
signature for)
(b) Catching targeted attacks that points specifically at your web site.
>
> However, one must note that security is not about using a single
source of
> protection, it is the art of security layering that is prudent to
apply.
> mod_security is just a step in that process.
I agree, you are right, and mod_security is far superior to many
commercial solutions out there (though more difficult to implement).
>
> To your point, developers must pay more attention when coding to
ensure
> that variables and arguments are properly sanitized. For PHP sites,
> mod_security has a mechanism to protect against register_globals as
well.
>
> Here are quite a few you can read on:
>
> http://modsecurity.org/documentation/snortmodsec-rules.txt
>
> There are other sources of security that can be applied to Apache,
just as
> mod_dosevasive and mod_require_host.
>
> On the excerpts you've quoted, I can understand and appreciate the
variety
> of attacks that can be formed and sent. If history has taught us
> anything, in the real and online worlds, anything breachable.
>
> However, I'm not so sure that a blanket statement that products, like
> those you mention above, cannot handle such attacks is not a fair one
at
> all. I suggest you read some of the articles on mod_security:
>
> ref: http://modsecurity.org/documentation/index.html
>
> http://www.onlamp.com/pub/a/apache/2003/11/26/mod_security.html
> http://www.securityfocus.com/infocus/1739
> http://modsecurity.org/documentation/apache-internal-chroot.html
> http://modsecurity.org/documentation/php-register-globals.html
>
> In your initial email you discuss real time application monitoring. I
> don't see how mod_security is any different as it inspects GETs and or
> POSTs real time.
I stand corrected. mod_security is a real time application security
solution and is not part of the IPS products group. The reason I
included it in the IPS group is that all the mod_security rules I've
seen regarding Santy and phpInclude do not utilize mod_security
application layer features. All of them could be written as snort rules.
Mod_security is not different from IPS solutions in this case since
unlike networks which are (relatively) simple and static, applications
are complex and dynamic. A real time application security solution has
to provide some sort of a dynamic policy that adapts automatically to
the application. Otherwise security configuration will have to be
performed constantly during the application life cycle.
In other words - for you as a security expert with application knowledge
it is a great solution. For an organization it is impractical.
>
> If santy and phpinclude have accomplished anything positive, I hope
that
> it highlights (no pun intended) to coders the need to refocus on
securing
> their applications.
>
> --
> Regards,
>
> Paul Laudanski - Computer Cops, LLC. CEO & Founder
> CastleCops(SM) - http://castlecops.com
> Promoting education and health in online security and privacy.
>
Received on Jan 02 2005
Intro
