mod-security-users — General discussion about mod_security

Re: [mod-security-users] When will we see 1.8?

[Mark <ad...@as...>]

Ivan Ristic wrote:

> Mark wrote:
>> When will mod_security 1.8 be released? The idea that 1.7.6 may miss
>> chroot at times, as you explained on your site, worries me some.
>
>   I should have all planned work completed in a week. I will release
>   1.8dev2 then. I will encourage people to use 1.8dev2 to test
>   it out, and release 1.8 2-4 weeks after 1.8dev2.
>
>   The 1.8dev2 will be of a good quality, though. It has been in the
>   works for a long time and it wasn't rushed.

Not to rush you either, but how is 1.8 coming along? I am preparing a brand
new production server; and, if at all possible, I'd like to include 1.8 on
there. With April drawing to a close and all, I thought I inquire once more.
:)

Thanks,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] hello

[Ivan R. <iv...@we...>]

Noraan For Hosting wrote:

> Hello
>  
> I have mod_sec in my server
>  
> I don't want any of my client run perl or cgi scripts
>  
> what I must add on the modules

   You don't need mod_security for that. Assuming you
   have a default configuration simply remove all cgi-bin
   directories (in the configuration and from the file
   system) and you're done.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Mod_Security and Submit Form

[Ivan R. <iv...@we...>]

Darrell T wrote:

> 2. When text in our form moves to a second line and 
> SecFilterForceByteRange is set to 32 126 ... mod-security produces 
> "Access denied with code 500."  This problem is eliminated with 1 126 
> but I am hoping to keep the ByteRange at 32 126

   SecFilterForceByteRange works on all data that is examined, and
   it only accepts once data range at the moment. I plan to support
   multiple ranges in the future.

   However, you can define ranges using regular expressions. Try this
   in addition to SecFilterForceByteRange 1 126):

   SecFilterSelective SOMETHING_HERE "[\x01-\x09\x0b-\x0c\x0e-\x1f]+"

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Mod_Security and Submit Form

[Mark <ad...@as...>]

> From: Darrell T
> To: mod...@li...
> Sent: Monday, April 19, 2004 1:42 AM
> Subject: [mod-security-users] Mod_Security and Submit Form
>
> Hi,
> I ran into two problems when clients submit a message via our
> submitform.php.
>
> 1. When a word submitted in our form (contact.php) ends with
> "rm" such as term, I get the response below.
>
> mod_security-message: Access denied with code 500.
> Pattern match "rm\x20" at POST_PAYLOAD

Taking a wild guess here, but did you define a SecFilter, to prevent "rm -rf
/", or the like? In that case, you may want to prefix \b to the rm string,
or \s (assuming Perl regular expressions are followed).

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

[mod-security-users] Mod_Security and Submit Form

[Darrell T <bkk...@sb...>]

Hi,
 
I ran into two problems when clients submit a message via our submitform.php. 
 
1. When a word submitted in our form (contact.php) ends with "rm" such as term, I get the response below.
 
  mod_security-message: Access denied with code 500. Pattern match "rm\x20" at POST_PAYLOAD  
 
2. When text in our form moves to a second line and SecFilterForceByteRange is set to 32 126 ... mod-security produces "Access denied with code 500."  This problem is eliminated with 1 126 but I am hoping to keep the ByteRange at 32 126
 
Any Suggestions
 
Thanks
 

Re: [mod-security-users] Logo

[Ivan R. <iv...@we...>]

Mark wrote:
> Just a quick question: is it allowed to place the "mod security protected"
> logo on my site? If not, do you have a logo for that purpose?

  Sure, go ahead. It's designed specifically for that purpose :)

  You can also use this page as a template for your error page:
  http://www.modsecurity.org/%2d%2d

  To have the unique id for a request you will have to have
  mod_unique_id included in Apache.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] hello

[Noraan F. H. <maz...@ho...>]

Hello=20

I have mod_sec in my server=20

I don't want any of my client run perl or cgi scripts=20

what I must add on the modules=20

Plz reply me=20
Thanks=20

[mod-security-users] Logo

[Mark <ad...@as...>]

Just a quick question: is it allowed to place the "mod security protected"
logo on my site? If not, do you have a logo for that purpose?

Thanks,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] SecUploadDir Question

[Ivan R. <iv...@we...>]

Jeremy Junginger wrote:
> Thanks Ivan,
> 
> That fixed things right up.  Do you guys compile any other modules into a
> high-security apache webserver?  Right now, I'm playing with mod_security,
> mod_headers, mod_ssl, and mod_dosevasive.  Let me know if you have seen any
> other modules of this nature, and thanks again!

  mod_setenvif and mod_rewrite tend to be very useful too.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

RE: [mod-security-users] SecUploadDir Question

[Jeremy J. <jj...@ac...>]

Thanks Ivan,

That fixed things right up.  Do you guys compile any other modules into a
high-security apache webserver?  Right now, I'm playing with mod_security,
mod_headers, mod_ssl, and mod_dosevasive.  Let me know if you have seen any
other modules of this nature, and thanks again!

-Jeremy

-----Original Message-----
From: Ivan Ristic [mailto:iv...@we...]=20
Sent: Friday, April 09, 2004 11:14 AM
To: Jeremy Junginger
Cc: mod...@li...
Subject: Re: [mod-security-users] SecUploadDir Question


Jeremy Junginger wrote:
> The following two directives are giving me trouble, and I'm unable to=20
> capture POST data:
>=20
> SecUploadDir /usr/local/apache/upload
> SecUploadKeepFiles On
>=20
> It yields the following error:
>=20
> Syntax error on line 1255 of /usr/local/apache/conf/httpd.conf:
> Invalid command 'SecUploadDir', perhaps mis-spelled or defined by a=20
> module not included in the server configuration
>=20
> Line 1255:      SecUploadDir /usr/local/apache/upload
>=20
> I am using mod_security 1.7.6 and have created the=20
> /usr/local/apache/upload dir with 755 privs.  Any insights you can=20
> provide would be very helpful.

  That functionality is only available in the 1.8 branch. Download the
  nightly CVS snapshot and try with that (1.8dev1 is pretty old by now
  and will soon be replaced with a new development release).

--=20
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] SecUploadDir Question

[Ivan R. <iv...@we...>]

Jeremy Junginger wrote:
> The following two directives are giving me trouble, and I'm unable to capture
> POST data:
> 
> SecUploadDir /usr/local/apache/upload
> SecUploadKeepFiles On
> 
> It yields the following error:
> 
> Syntax error on line 1255 of /usr/local/apache/conf/httpd.conf:
> Invalid command 'SecUploadDir', perhaps mis-spelled or defined by a module
> not included in the server configuration
> 
> Line 1255:      SecUploadDir /usr/local/apache/upload
> 
> I am using mod_security 1.7.6 and have created the /usr/local/apache/upload
> dir with 755 privs.  Any insights you can provide would be very helpful.

  That functionality is only available in the 1.8 branch. Download the
  nightly CVS snapshot and try with that (1.8dev1 is pretty old by now
  and will soon be replaced with a new development release).

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] SecUploadDir Question

[Jeremy J. <jj...@ac...>]

The following two directives are giving me trouble, and I'm unable to captu=
re
POST data:

SecUploadDir /usr/local/apache/upload
SecUploadKeepFiles On

It yields the following error:

Syntax error on line 1255 of /usr/local/apache/conf/httpd.conf:
Invalid command 'SecUploadDir', perhaps mis-spelled or defined by a module
not included in the server configuration

Line 1255:      SecUploadDir /usr/local/apache/upload

I am using mod_security 1.7.6 and have created the /usr/local/apache/upload
dir with 755 privs.  Any insights you can provide would be very helpful.
Thanks!

-Jeremy

Re: [mod-security-users] mod_security seems to make Apache crashes when a file is uploaded

[Ivan R. <iv...@we...>]

> I am using mod_security 1.7.6 with Apache 2.0.49 on Solaris 8 with
> OpenSSL 0.9.7d
> When a pdf file is uploaded it makes the Apache child process
> crashes.

  FYI, I've received information the crash happens even when
  mod_security is not enabled, therefore this isn't a mod_security
  problem.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] When will we see 1.8?

[Ivan R. <iv...@we...>]

> Can you tell me, though, what are the conditions the parent process ID != 1?
> The children, of course, have the PPID of the 'mother' Apache process; but
> the parent itself always seems to have PPID 1. Are you referring to Apache
> being started from within a new shell, or something?

   I haven't been able to pin-point that. My guess is that is a problem
   with timing since the ppid of the main process must, eventually,
   become 1. In the end I switched to a new, reliable, approach.

   BTW, I've also added a check to v1.8. If chroot fails for any
   reasons, Apache will refuse to serve requests.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] When will we see 1.8?

[Mark <ad...@as...>]

Ivan Ristic wrote:

> Mark wrote:

>> When will mod_security 1.8 be released? The idea that 1.7.6 may miss
>> chroot at times, as you explained on your site, worries me some.
>
>   I should have all planned work completed in a week. I will release
>   1.8dev2 then. I will encourage people to use 1.8dev2 to test
>   it out, and release 1.8 2-4 weeks after 1.8dev2.

Thanks.

Can you tell me, though, what are the conditions the parent process ID != 1?
The children, of course, have the PPID of the 'mother' Apache process; but
the parent itself always seems to have PPID 1. Are you referring to Apache
being started from within a new shell, or something?

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] When will we see 1.8?

[Ivan R. <iv...@we...>]

Mark wrote:
> When will mod_security 1.8 be released? The idea that 1.7.6 may miss chroot
> at times, as you explained on your site, worries me some.

  I should have all planned work completed in a week. I will release
  1.8dev2 then. I will encourage people to use 1.8dev2 to test
  it out, and release 1.8 2-4 weeks after 1.8dev2.

  The 1.8dev2 will be of a good quality, though. It has been in the
  works for a long time and it wasn't rushed.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] When will we see 1.8?

[Mark <ad...@as...>]

When will mod_security 1.8 be released? The idea that 1.7.6 may miss chroot
at times, as you explained on your site, worries me some.

Thanks,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] can't seem to get notification working...

[Ivan R. <iv...@we...>]

> So the only way I could get this to work is to comment the above code and 
> recompile suexec.  Obviously this is probably a bad idea but I just did it 
> to prove the point.
> 
> Any ideas on how to make this work without hacking suexec?

  I've modified the Apache 1.x branch to work with suexec. I chdir
  to the script folder first and then execute it with a relative
  filename. Works for me here, but you still have to satisfy all
  other suexec requirements (such as DOC_ROOT).

  Give it a try, and if it makes sense I'll do in in the
  Apache 2.x branch too.

  Download link here:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/mod-security/mod_security/apache1/mod_security.c?rev=1.82

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Outlook Web Access 2000

[Ivan R. <iv...@we...>]

Mathew Davies wrote:

>>-----Original Message-----
>>From: Ivan Ristic 
>>Sent: 06 April 2004 11:07
>>To: Mathew Davies
>>Cc: mod...@li...
>>Subject: Re: [mod-security-users] Outlook Web Access 2000
>>Mathew Davies wrote:
>>
>>>Has anyone managed to successful use mod_security and mod_proxy
>>>with Exchange 2000 OWA ? If so whats the secret
>>
>>   Do you have a specific problem with it?
> 
> Yes as all the links seems to be generated as absolute
> I can list my inbox contents by visting url
> http://external.com/username/inbox/?cmd=contents
> but all the linnks in this are coded to internal server ie if
> i had an messages called test1 the link in my inbox is
> http://internal/username/inbox/test1.eml
> which when I try click on it, it redirects to that it doesn't work as 
> it is an internal address.

   That's not a mod_security problem.

   One solution is to have internal servers generate external
   addresses. One way to do this is to actually install servers
   to respond to "external.com" and to have a proper, public IP
   address, and then install a gateway in front to re-route
   all TCP packets to port 80 to the proxy instead of going
   to Exchange directly.

   Or, if you can't/don't want to do that, you must put a
   mechanism in place to rewrite links in real-time. mod_proxy_html
   can do that for you.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

RE: [mod-security-users] Outlook Web Access 2000

[Mathew D. <mat...@ip...>]

>=20-----Original=20Message-----
>=20From:=20Ivan=20Ristic=20
>=20Sent:=2006=20April=202004=2011:07
>=20To:=20Mathew=20Davies
>=20Cc:=20m...@li...
>=20Subject:=20Re:=20[mod-security-users]=20Outlook=20Web=20Access=202000
>=20Mathew=20Davies=20wrote:
>=20>=20Has=20anyone=20managed=20to=20successful=20use=20mod_security=20an=
d=20mod_proxy
>=20>=20with=20Exchange=202000=20OWA=20?=20If=20so=20whats=20the=20secret
>=20=20=20=20Do=20you=20have=20a=20specific=20problem=20with=20it?
Yes=20as=20all=20the=20links=20seems=20to=20be=20generated=20as=20absolute=

I=20can=20list=20my=20inbox=20contents=20by=20visting=20url
http://external.com/username/inbox/?cmd=3Dcontents
but=20all=20the=20linnks=20in=20this=20are=20coded=20to=20internal=20serve=
r=20ie=20if
i=20had=20an=20messages=20called=20test1=20the=20link=20in=20my=20inbox=20=
is
http://internal/username/inbox/test1.eml
which=20when=20I=20try=20click=20on=20it,=20it=20redirects=20to=20that=20i=
t=20doesn't=20work=20as=20
it=20is=20an=20internal=20address.

-mat

______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20
______________________________________________________________________

Re: [mod-security-users] Outlook Web Access 2000

[Ivan R. <iv...@we...>]

Mathew Davies wrote:

> Has anyone managed to successful use mod_security and mod_proxy
> with Exchange 2000 OWA ? If so whats the secret

   Do you have a specific problem with it?

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] Outlook Web Access 2000

[Mathew D. <mat...@ip...>]

Has=20anyone=20managed=20to=20successful=20use=20mod_security=20and=20mod_=
proxy
with=20Exchange=202000=20OWA=20?=20If=20so=20whats=20the=20secret


Mat

______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20
______________________________________________________________________

Re: [mod-security-users] How to block access for such requests

[Purl G. <pur...@pu...>]

"Tkachenko Alexei [AlexAT]" wrote:

(snipped)

> I have in my audit_log the following attempt:
> 69.143.19.149 - - [04/Apr/2004:21:32:08 +0300] "SEARCH
> /\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x0

> How can I block access for strings \x02\xb1 and \x90\x90?

 
Alex, I am sorry to write there is nothing you
can do about this, and I do mean nothing.

Please read a series of articles in the
"alt.configuration.apache" newsgroup with
subject titles,

"Rewriting long URIs from viruses... shortening log files" (Leon Dang)
"Capture 414 Error - Webdav Exploit" (Purl Gurl)
"Bug Report Submitted - Webdav Exploit" (Purl Gurl)

Those are posted over the past few days and today.
You will read technical details in those articles.

I submitted a bug report to Apache Org on this.
Below my signature you will read that report
and responses. Currently, I sent a heated private
response to Apache Org on this.

Brass tacks is there is absolutely nothing you can
do about Webdav exploits, which is the source of
your log entries. 

Should something new come up, I will inform all readers
on this email list.


Kira (Purl Gurl)

http://nagoya.apache.org/bugzilla
Bug report 28193:

Webdav exploit comes in as SEARCH request method with an "URI" in
excess of thirty-thousand bytes. This method is not recognized by
Apache 1.3.x series, thus cannot be "captured" for any usage. This
series of Apache only recognizes a 414 error; URI too long.

I have discovered through testing and newsgroup discussions, the
Webdav Exploit cannot be captured by httpd directives, htaccess,
mod_rewrite, mod_security nor custom access log directives such
as setting an environment variable to limit log entry length.

Otherwords, Apache 1.3.x series is completely vulnerable to
a Denial Of Service attack employing the Webdav Exploit. My
logs show this exploit hitting six times in one second and
does cause Apache to slow down during those hits. A person
could change the timing on the C program Webdav Exploit to
send hits at such a rate to easily effect a DOS attack on
Apache servers running the 1.3.x series.

There are no facilities included in Apache 1.3.x to deal
with this exploit; Apache processes and responds with a
414 error before any directives or modules can be employed.
With mild modification to the Webdav program, any Apache
server running the 1.3.x series could be easily taken down
with a Denial Of Service attack using the Webdav exploit.

Kira


------- Additional Comments From Kira 2004-04-05 02:27 -------

I need to add IP Address blocking via directives
cannot be used to defeat Webdav exploits. There
is simply no mechanism in Apache 1.3.x to prevent
these Webdav exploits. Apache is wide open for
abuse by Webdav exploits should someone realize
there is no known defense mechanism for DOS
attacks employing this exploit; any byte length
can be sent at any timing intervals, and Apache
accepts it consuming CPU resources and memory
at an alarming rate. Just a matter of time
before a "script kiddie" figures this out.

Thanks for taking time to read my bug report,

Kira


------- Additional Comments From Joshua Slive 2004-04-05 03:11 -------

I'm not a security expert, but there are two issues I should point out:

1. If there is a security vulnerability here, it should be reported to
sec...@ap..., not the bug database.

2. I don't immediately see any vulnerability.  As this page mentions:
http://httpd.apache.org/security_report.html
Apache cannot do anything about denial of service attacks where attackers
simply use a big pipe to blow over the server with content.  You can do
this simply by sending thousands of GET requests.  No need for any special
webdav exploit.  This would only be a real vulnerability if apache is using
resources that are not in proportion with the size of the inputs.

(The only potential issue I see here is that an attacker can fill up the logs.
This is annoying, but hardly very dangerous.  It could be dealt with using
a piped-logging program that filters out these requests.)

If, after reading that, you still believe you have found a security hole,
please contact the appropriate security report address.

Thanks for using Apache!


------- Additional Comments From Kira 2004-04-05 04:40 -------

Resolved, invalid?

This is a bug. This is an inability to hook
into selected error conditions. With the
advent of Webdav exploits, is critically
important for administrators to capture
and deal with an error 414 conditon.

Apache 1.3.x affords no ability to deal
with this exploit. This is a bug. No
administrator can deal with this exploit
under current software conditions.

You have dismissed this as "resolved invalid"
in lieu of any discussion, in lieu of any
comments coming in from others. It is clear
by time stamps you spent little, if any time,
considering the ramifications of this bug.

Strikes me your decision is both premature
and done so without research. You should at
least allow a bit of time for other comments
to come in, to fully assess the impact of
this clear bug in Apache 1.3.x series.

Premature dismissal of a bug report, in lieu
of discussion and comments, defeats the whole
purpose of bugzilla reporting. I am clearly
dismayed you dismiss bug reports so lightly.
Doing so discourages others from reporting
problems for which resolution may prove
highly beneficial.

In this case, it is exceedingly clear an ability
to hook into an error 414 condition is very
critical, very needed.

Certainly I will think twice before investing
time and effort into reporting an item I believe
may benefit our Apache community.

[mod-security-users] How to block access for such requests

[Tkachenko A. [AlexAT] <al...@tk...>]

Peace be with you,

I have in my audit_log the following attempt:
69.143.19.149 - - [04/Apr/2004:21:32:08 +0300] "SEARCH
/\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x0
2\xb1
\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1
\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02
\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02
\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1
\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1
\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02
.....................
\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
.....................

How can I block access for strings \x02\xb1 and \x90\x90?
I tried "\x90\x90" and "\\x90\\x90" but I still can access site via
http://www.somedomain.com/\x90\x90

-----
Regards,
Alex A. Tkachenko
www.DOMEN.com.ua
mailto:in...@do...
ICQ: 280497086
 

Re: [mod-security-users] Webdav Exploit - What Rule To Catch?

[Purl G. <pur...@pu...>]

Ivan Ristic wrote:

(snipped a lot)
 
> > However, I am having difficulties capturing these Webdav
> > exploits before Apache sends a 414 error response. Those
> > "SEARCH" request methods are slipping by mod_security.

>   There's no way around it at the moment. I think
>   you should be able to use mod_rewrite to detect
>   and reject that request.
 
For those following this topic, you will find a series
of articles in the "alt.apache.configuration" newsgroup
under my moniker, "Purl Gurl" along with others,

"Rewriting Long URIs...."
"Capture 414 Error...."

I have submitted a bug report to apache on this problem
with the Webdav exploit, nagoya.apache.org - bugzilla.
It is bug report 28193 for those wanting to follow along.

Thanks to Ivan for all his help and his great module.
Already seeing log entries created by his module! Each
one being someone trying to exploit our family server.

Great work, Ivan!


Kira