headers
Verachten Bruno | 1 Aug 15:27

Working with 2.0.0-rc-2

Hi,

I read a few articles on mod-security and decided to test the
application.
I chose the 2.0.0-rc-2 version. Unfortunately, rule examples (got-root
and mod-security) are written in 1.x format.
I understand some kind of rules aren't rewritable in 2.0.
Is there any date scheduled to release that kind of rules in 2.0?

Thanks in advance,

Bruno Verachten

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Ivan Ristic | 2 Aug 14:32
Picon

Informal ModSecurity Survey

Hi,

I am trying to get a better understanding of how ModSecurity is
deployed and used. Being an open source product, download of which is
not restricted or controlled, it is difficult to know the user base. I
would appreciate if you could spend a moment to write (and sent to my
*private* email address) an email to describe your deployment model. I
am interested in things such as:

1. Are you deploying ModSecurity embedded or as part of a reverse
proxy? How many instances do you have installed?

2. What do you use it for? Do you use it for general-purpose web
application hardening, monitoring, logging, just-in-time patching,
dealing with spam, etc?

3. What versions of Apache are you using and on what platforms?

4. What are the features you would like to see in future releases of
ModSecurity? For example: GUI, rules, management, centralised
operation, hardware appliance, ...

Also please feel free to add anything else you think is important.

I appreciate your help,
Ivan

--

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Pepper | 2 Aug 16:52

Bug: apachectl -L, SecFilter* missing

	I installed mod_security 1.9.4 from source in httpd 2.2.3 via 
apxs (very easy). I am having trouble getting my rules active, and 
was checking to see if the directives were enabled via "apachectl 
-L", which lists available configuration directives.

	Unfortunately, the SecFilter* directives do *not* show up in 
"apachectl -L" output (although "apachectl -M" does show the module 
loaded, and I my security log is growing, so I know at least one 
directive is enabled). Another user has confirmed the problem in his 
Apache.

	This looks like a bug, with mod_security not properly 
registering its directives.

						Regards,

						Chris Pepper
--

-- 
Chris Pepper:               <http://www.reppep.com/~pepper/>
Rockefeller University:     <http://www.rockefeller.edu/>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Verachten Bruno | 2 Aug 17:37

Working with 2.0.0-rc-2

Hi,

Sorry if there is a duplication, but I never received the email I posted
yesterday. 

I read a few articles on mod-security and decided to test the 
application.
I chose the 2.0.0-rc-2 version. Unfortunately, rule examples 
(got-root and mod-security) are written in 1.x format.
I understand some kind of rules aren't rewritable in 2.0.
Is there any date scheduled to release that kind of rules in 2.0?

Thanks in advance,

Bruno Verachten

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Ryan Boyd | 2 Aug 21:44
Picon
Favicon

Basic auth failure monitoring

Hello,

I would like to be able to monitor authorization failures using
modsecurity 1.9.x and apache 2.2.x

Ideal goal:
If more than x number of auth failures occur in a given period of time
from the same IP, pass and log.  View auth failures in modsecurity
console.

Realistic goal:
If an auth failure occurs, pass and log.  View auth failures in
modescurity console and determine problem there based off reporting.

Attempt 1:
If Authorization header is presented by the client, but a 401 response
code is returned, pass and log.  This represents a failed login attempt.
Because of where different modules hook into apache, I believe
mod_authn_basic (using mod_authnz_ldap) is catching and fully handling
the request before modsecurity is seeing it.  Only if an
authentication/authorization is successful does modsecurity see the
request.

Attempt 2:
Use custom 401 error handler to add a 'Auth-Failure' header to response.
Use OUTPUT in modsecurity to look for that Auth-Failure value and log,
pass.  However, modsecurity can't see the full response of a 401 error
page.  If it could and performed certain actions, the situation exists
where infinite recursion could happen.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ryan Barnett | 2 Aug 22:00
Picon
Gravatar

Re: Basic auth failure monitoring

Did you compile modsecurity with the "-DENABLE_EARLY_HOOK" flag?  This will allow modsecurity to take action much earlier in the request loop.
 
Details here -
 
This might allow you to do Attempt #1.  This flag is not needed if you are running Apache/ModSecurity as a reverse proxy, but is needed if it is embedded.
 
FYI - I use custom 401 CGI ErrorDocuments to handle these tasks.  Granted keeping a history of auth failures is a bit kludgy as I have to write to temp files and then quickly read them when another attempt is made.  The scripts will do some counting on past failure attempts and then decide whether or not to email me.
 
<Shameless Plug>
I talk about creating this "Authentication Failure Awareness" with Apache in my book "Preventing Web Attacks with Apache" - http://www.amazon.com/gp/product/0321321286/ref=sr_11_1/104-3305153-0137508?ie=UTF8
</Shameless Plug>
 
--
Ryan C. Barnett
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
 
On 8/2/06, Ryan Boyd <rbisd <at> rit.edu> wrote:
Hello,

I would like to be able to monitor authorization failures using
modsecurity 1.9.x and apache 2.2.x

Ideal goal:
If more than x number of auth failures occur in a given period of time
from the same IP, pass and log.  View auth failures in modsecurity
console.

Realistic goal:
If an auth failure occurs, pass and log.  View auth failures in
modescurity console and determine problem there based off reporting.

Attempt 1:
If Authorization header is presented by the client, but a 401 response
code is returned, pass and log.  This represents a failed login attempt.
Because of where different modules hook into apache, I believe
mod_authn_basic (using mod_authnz_ldap) is catching and fully handling
the request before modsecurity is seeing it.  Only if an
authentication/authorization is successful does modsecurity see the
request.

Attempt 2:
Use custom 401 error handler to add a 'Auth-Failure' header to response.
Use OUTPUT in modsecurity to look for that Auth-Failure value and log,
pass.  However, modsecurity can't see the full response of a 401 error
page.  If it could and performed certain actions, the situation exists
where infinite recursion could happen.

Anyone have any suggestions for handling this?  Granted, I could do all
the handling within the 401 handler, but I would really like these sorts
of requests to appear in my modsecurity console installation, combined
with all other 'bad' requests.

Thanks much,

-Ryan


---
Ryan Boyd
Web Architect
Information & Technology Services
Rochester Institute of Technology
585-475-5573
rbisd <at> rit.edu


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Permalink | Reply | 2 comments |
headers
Ryan Boyd | 2 Aug 22:21
Picon
Favicon

Re: Basic auth failure monitoring

Thanks Ryan for the quick response.  No, I don't have the early hook enabled (though I have read the list exchange on the topic)-- unfortunately, I need to have modsecurity at both hooks in the process.  I understand that the 'several hooks' feature is something in development.
 
While the 401 method works, I would really like to consolidate these sorts of alerts in with other alerts in our installation of the modsecurity console.  THowever, I may resort to just doing the email alerts method as you've discussed.
 
<response to shameless plug>
Actually, I have read your book pretty much cover-to-cover.  It's a great read -- perhaps I should read that chapter again though to see if theres anything I've missed.
</response to shameless plug>
 
Thanks,
 
-Ryan
 
---
Ryan Boyd
Web Architect
Information & Technology Services
Rochester Institute of Technology
585-475-5573
 
 

From: Ryan Barnett [mailto:rcbarnett <at> gmail.com]
Sent: Wednesday, August 02, 2006 4:01 PM
To: Ryan Boyd
Cc: mod-security-users <at> lists.sourceforge.net
Subject: Re: [mod-security-users] Basic auth failure monitoring

Did you compile modsecurity with the "-DENABLE_EARLY_HOOK" flag?  This will allow modsecurity to take action much earlier in the request loop.
 
Details here -
 
This might allow you to do Attempt #1.  This flag is not needed if you are running Apache/ModSecurity as a reverse proxy, but is needed if it is embedded.
 
FYI - I use custom 401 CGI ErrorDocuments to handle these tasks.  Granted keeping a history of auth failures is a bit kludgy as I have to write to temp files and then quickly read them when another attempt is made.  The scripts will do some counting on past failure attempts and then decide whether or not to email me.
 
<Shameless Plug>
I talk about creating this "Authentication Failure Awareness" with Apache in my book "Preventing Web Attacks with Apache" - http://www.amazon.com/gp/product/0321321286/ref=sr_11_1/104-3305153-0137508?ie=UTF8
</Shameless Plug>
 
--
Ryan C. Barnett
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
 
On 8/2/06, Ryan Boyd <rbisd <at> rit.edu> wrote:
Hello,

I would like to be able to monitor authorization failures using
modsecurity 1.9.x and apache 2.2.x

Ideal goal:
If more than x number of auth failures occur in a given period of time
from the same IP, pass and log.  View auth failures in modsecurity
console.

Realistic goal:
If an auth failure occurs, pass and log.  View auth failures in
modescurity console and determine problem there based off reporting.

Attempt 1:
If Authorization header is presented by the client, but a 401 response
code is returned, pass and log.  This represents a failed login attempt.
Because of where different modules hook into apache, I believe
mod_authn_basic (using mod_authnz_ldap) is catching and fully handling
the request before modsecurity is seeing it.  Only if an
authentication/authorization is successful does modsecurity see the
request.

Attempt 2:
Use custom 401 error handler to add a 'Auth-Failure' header to response.
Use OUTPUT in modsecurity to look for that Auth-Failure value and log,
pass.  However, modsecurity can't see the full response of a 401 error
page.  If it could and performed certain actions, the situation exists
where infinite recursion could happen.

Anyone have any suggestions for handling this?  Granted, I could do all
the handling within the 401 handler, but I would really like these sorts
of requests to appear in my modsecurity console installation, combined
with all other 'bad' requests.

Thanks much,

-Ryan


---
Ryan Boyd
Web Architect
Information & Technology Services
Rochester Institute of Technology
585-475-5573
rbisd <at> rit.edu


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Permalink | Reply | 1 comment |
headers
Ryan Barnett | 2 Aug 22:51
Picon
Gravatar

Re: Basic auth failure monitoring

Comments inline...

On 8/2/06, Ryan Boyd <rbisd <at> rit.edu> wrote:
Thanks Ryan for the quick response.  No, I don't have the early hook enabled (though I have read the list exchange on the topic)-- unfortunately, I need to have modsecurity at both hooks in the process.  I understand that the 'several hooks' feature is something in development.
 
Yeah, I guess there are valid situations where you would want to have modsecurity plugged into other request phases.  I know that the 2.0XX version has many different hooks in the request loop.  I haven't personally used the early_hook to identify the impact of my existing rulesets (to see of this breaks anything).  I have a bunch of rcustom ulesets for proxies web apps and using this may break those...

 
While the 401 method works, I would really like to consolidate these sorts of alerts in with other alerts in our installation of the modsecurity console.  THowever, I may resort to just doing the email alerts method as you've discussed.
 
I had some conversations with Ivan about this type of "state" or historical monitoring and the concensus was this would indeed best be suited for a process within the Console instead of within ModSecurity itself since the Console will have all of the log data to correlate events.  With that being said, the 2.0XX version of ModSecurity does implement some state tracking capabilities (see the SecDataDir directive) with the use of transaction scoring and Operators.  In the 1.9 branch, it was essentially all or nothing for blocking requests if they matched a rule.  With 2.0XX you can set up essentially weighted scoring for each filter that they hit and then set a threshold for action.  This sounds like it might be able to address your 401 issues, but you would have to test.
 
That is actually a very practical test to run :)  I will check this out myself to see if I can create a ModSecurity 2.0XX ruleset for idenitfying failed basic auth requests and setting a threshold of say 5 failures before the specific action is taken.
 
As an aside - did you see Ivan's email earlier today requesting feedback on how users are using ModSecurity?  In it, he also asks about feature requests.  You should list the intrusion correlation functionality in the Console.

 
<response to shameless plug>
Actually, I have read your book pretty much cover-to-cover.  It's a great read -- perhaps I should read that chapter again though to see if theres anything I've missed.
</response to shameless plug>
 
Cool.  Glad you liked it.  As with any tech book, they age pretty quickly so I already have a bunch of ModSecurity updates that I am planning to include is a future revision.
 
Let me know if you need any other assistance.

--
Ryan C. Barnett
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
 

 
Thanks,
 
-Ryan
 
---
Ryan Boyd
Web Architect
Information & Technology Services
Rochester Institute of Technology
585-475-5573
 
 

From: Ryan Barnett [mailto:rcbarnett <at> gmail.com]
Sent: Wednesday, August 02, 2006 4:01 PM
To: Ryan Boyd
Cc: mod-security-users <at> lists.sourceforge.net
Subject: Re: [mod-security-users] Basic auth failure monitoring

 
Did you compile modsecurity with the "-DENABLE_EARLY_HOOK" flag?  This will allow modsecurity to take action much earlier in the request loop.
 
Details here -
 
This might allow you to do Attempt #1.  This flag is not needed if you are running Apache/ModSecurity as a reverse proxy, but is needed if it is embedded.
 
FYI - I use custom 401 CGI ErrorDocuments to handle these tasks.  Granted keeping a history of auth failures is a bit kludgy as I have to write to temp files and then quickly read them when another attempt is made.  The scripts will do some counting on past failure attempts and then decide whether or not to email me.
 
<Shameless Plug>
I talk about creating this "Authentication Failure Awareness" with Apache in my book "Preventing Web Attacks with Apache" - http://www.amazon.com/gp/product/0321321286/ref=sr_11_1/104-3305153-0137508?ie=UTF8
</Shameless Plug>
 
--
Ryan C. Barnett
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
 
On 8/2/06, Ryan Boyd <rbisd <at> rit.edu> wrote:
Hello,

I would like to be able to monitor authorization failures using
modsecurity 1.9.x and apache 2.2.x

Ideal goal:
If more than x number of auth failures occur in a given period of time
from the same IP, pass and log.  View auth failures in modsecurity
console.

Realistic goal:
If an auth failure occurs, pass and log.  View auth failures in
modescurity console and determine problem there based off reporting.

Attempt 1:
If Authorization header is presented by the client, but a 401 response
code is returned, pass and log.  This represents a failed login attempt.
Because of where different modules hook into apache, I believe
mod_authn_basic (using mod_authnz_ldap) is catching and fully handling
the request before modsecurity is seeing it.  Only if an
authentication/authorization is successful does modsecurity see the
request.

Attempt 2:
Use custom 401 error handler to add a 'Auth-Failure' header to response.
Use OUTPUT in modsecurity to look for that Auth-Failure value and log,
pass.  However, modsecurity can't see the full response of a 401 error
page.  If it could and performed certain actions, the situation exists
where infinite recursion could happen.

Anyone have any suggestions for handling this?  Granted, I could do all
the handling within the 401 handler, but I would really like these sorts
of requests to appear in my modsecurity console installation, combined
with all other 'bad' requests.

Thanks much,

-Ryan


---
Ryan Boyd
Web Architect
Information & Technology Services
Rochester Institute of Technology
585-475-5573
rbisd <at> rit.edu


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users 


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Permalink | Reply | 0 comments |
headers
Ivan Ristic | 2 Aug 23:48
Picon

Re: Working with 2.0.0-rc-2

On 8/2/06, Verachten Bruno <Bruno.Verachten <at> atosorigin.com> wrote:
> Hi,
>
> Sorry if there is a duplication, but I never received the email I posted
> yesterday.

SourceForge have recently upgraded the mailing list software, which is
now smart enough not to send a copy to the original author. (Yay! :)

> I read a few articles on mod-security and decided to test the
> application.
> I chose the 2.0.0-rc-2 version. Unfortunately, rule examples
> (got-root and mod-security) are written in 1.x format.
> I understand some kind of rules aren't rewritable in 2.0.
> Is there any date scheduled to release that kind of rules in 2.0?

Yes. It is realistic to expect v2.0 to be finalised (with complete
documentation and rule examples) in September. In general, if you want
to use 2.x as you would 1.9.x it's pretty straightforward (it is
mostly that the directive names have changed). For example: there is
no more SecFilter, and SecFilterSelective is called SecRule. These
changes probably cover the majority of the rules. Of course, new
features are only available in 2.x.

I promise to write a blog post on this subject very soon!

--

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Ivan Ristic | 2 Aug 23:55
Picon

Re: Bug: apachectl -L, SecFilter* missing

On 8/2/06, Chris Pepper <pepper <at> reppep.com> wrote:
>         I installed mod_security 1.9.4 from source in httpd 2.2.3 via
> apxs (very easy). I am having trouble getting my rules active, and
> was checking to see if the directives were enabled via "apachectl
> -L", which lists available configuration directives.
>
>         Unfortunately, the SecFilter* directives do *not* show up in
> "apachectl -L" output (although "apachectl -M" does show the module
> loaded, and I my security log is growing, so I know at least one
> directive is enabled). Another user has confirmed the problem in his
> Apache.
>
>         This looks like a bug, with mod_security not properly
> registering its directives.

I don't think that's an ModSecurity issue. In my tests invoking httpd
with -L shows only directives of statically compiled modules. The
directives of modules loaded as DSOs do not appear on the list.

--

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |

Gmane