mod-security-users — General discussion about mod_security

[mod-security-users] Compilation error on v1.9.2-rc1

[K. C. L. <li...@la...>]

I am trying to compile version 1.9.2-rc1 with Apache1 but received the
following error:

===> src/modules/extra
gcc -c  -I../../os/unix -I../../include -I/usr/src/openssl-0.9.8/include
-O2 -DLINUX=22 -DTARGET=\"httpsd\" -I/usr/include/db1 -DUSE_EXPAT
-I../../lib/expat-lite -DNO_DL_NEEDED -DAPACHE_SSL `../../apaci`
mod_security.c
mod_security.c:710: conflicting types for `my_call_exec'
mod_security.c:694: previous declaration of `my_call_exec'
make[4]: *** [mod_security.o] Error 1

Regards,

Kwong Li
London

Re: [mod-security-users] ModSecurity 1.9.2-rc1 (can now compile against PCRE)

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

Justin Grindea wrote:
> hi,
> 
> I will install it on a quite busy server tonight.
> Have you checked performance, specially when using gotroot's rules, when
> compiled against PCRE?
> Hope we'll get apache2 performance :)

  Yes, you should.


> About the upload script - Is it possible to return a predefined page
> explaining for example a virus
> was found in the attachment, instead of the general 500 error?

  No. But you can use some other (rarely used) error code with
  the ErrorDocument directive to achieve a similar effect.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] ModSecurity 1.9.2-rc1 (can now compile against PCRE)

[Justin G. <web...@sw...>]

hi,

I will install it on a quite busy server tonight.
Have you checked performance, specially when using gotroot's rules, when compiled against PCRE?
Hope we'll get apache2 performance :)

About the upload script - Is it possible to return a predefined page explaining for example a virus
was found in the attachment, instead of the general 500 error?

thanks,
	Justin

ps - This mailing list has a weird setup - When replying a message, the default is to reply to the original
poster, not the list. I always have to change the To: address manually. Please see if it can be changed.



Ivan Ristic wrote:
>   I have released 1.9.2-rc1:
> 
>   http://www.modsecurity.org/download/modsecurity-apache-1.9.2-rc1.tar.gz
> 
>   The instructions how to compile against PCRE are in
>   the manual. It's pretty straightforward. Everything works
>   as expected on my systems. Please give it a go on yours.
> 
>   This release also introduces the DISABLE_SUEXEC switch. Again,
>   it appears to work fine here. Those of you who have complained
>   about suEXEC please test it :)
> 

Re: [mod-security-users] Patch to avoid mod_security execute upload approve scripts with suEXEC

[Michael B. <mb...@co...>]

Hi Ivan,

Sounds fine, thanks.

Michael

On Monday 19 December 2005 20:17, Ivan Ristic wrote:
...
>   Hi Michael,
>
>   You (and other users that complained in the past) have convinced
>   me. In 1.9.2 there will be a compile-time switch DISABLE_SUEXEC
>   to take SuEXEC away. If that works well I will make it the
>   default option in 2.x.
>
>   Thank you for your input.

Re: [mod-security-users] SecUploadApproveScript error

[Michael B. <mb...@co...>]

> Every time is:
>
>  Access denied with code 500. Error verifying files: Received no output
> from the approver script (execution failed?) "/usr/local/bin/phpvalida"
>
> My script is right...what els could generate this error?

Are you using suexec? Please make sure it doesn't stop the script from running. You can check what suexec is doing from its logfile (/var(log/apache/suexec.log or the like).

Kindest regards,
 Michael

[mod-security-users] ModSecurity 1.9.2-rc1 (can now compile against PCRE)

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

  I have released 1.9.2-rc1:

  http://www.modsecurity.org/download/modsecurity-apache-1.9.2-rc1.tar.gz

  The instructions how to compile against PCRE are in
  the manual. It's pretty straightforward. Everything works
  as expected on my systems. Please give it a go on yours.

  This release also introduces the DISABLE_SUEXEC switch. Again,
  it appears to work fine here. Those of you who have complained
  about suEXEC please test it :)

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

[Zach R. <ad...@li...>]

I would definitely let you know if there are any problems.

Zach

Ivan Ristic wrote:

>Zach Roberts wrote:
>  
>
>>I've been known to be wrong about Plesk from time to time since I don't
>>work with it much.
>>
>>At any rate for those of us that use Apache 1.3 for one reason or
>>another would benefit from this.
>>
>>Any ETA on a release or at least a beta?
>>    
>>
>
>  I've made the changes. I will release 1.9.2-rc1 either tonight or
>  tomorrow morning. I am hoping you will give me feedback on the
>  PCRE compilation prior to final 1.9.2.
>
>  
>

[mod-security-users] Re: SecUploadApproveScript error

[Daniel S. <dan...@gm...>]

Solved with patch for suexec

Daniel Schultz <danielws <at> gmail.com> writes:

> 
> Hi all...
> 
> I´m with a doubt...
> 
> My mod_sec in apache is

Re: [mod-security-users] Patch to avoid mod_security execute upload approve scripts with suEXEC

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

mb...@co... wrote:
> Hi,
> 
> this is also a followup to Justin Grindea and "clamav perl scrip and su_exec".
> 
> We faced the same problem and considered it a design error for an upload approve
> script to be called using suEXEC for these two reasons:
> 
> 1. suEXEC executes CGIs as different users, which might                 
>    not have access to the uploaded files (which are usually             
>    in /tmp and owned by www-data:www-data, permissions 600)             
>                                                                         
> 2. suEXEC check 18, "Is the target user/group the same as               
>    the program's user/group?" means for us that we would need           
>    as many upload approve scripts as virtual hosts, each                
>    owned by the user the respective virtual host runs his               
>    CGIs under.                                                          

  Hi Michael,

  You (and other users that complained in the past) have convinced
  me. In 1.9.2 there will be a compile-time switch DISABLE_SUEXEC
  to take SuEXEC away. If that works well I will make it the
  default option in 2.x.

  Thank you for your input.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] SecUploadApproveScript error

[Daniel S. <dan...@gm...>]

Hi all...

I´m with a doubt...

My mod_sec in apache is

<IfModule mod_security.c>
    # Turn the filtering engine On or Off
    SecFilterEngine On

    # Make sure that URL encoding is valid
    SecFilterCheckURLEncoding On

    # Unicode encoding check
    SecFilterCheckUnicodeEncoding Off

    # Only allow bytes from this range
    SecFilterForceByteRange 0 255

    # Only log suspicious requests
    SecAuditEngine RelevantOnly

    # The name of the audit log file
    SecAuditLog logs/audit_log
    # Debug level set to a minimum
    SecFilterDebugLog logs/modsec_debug_log
    SecFilterDebugLevel 0

    # Should mod_security inspect POST payloads
    SecFilterScanPOST On

    SecUploadDir /tmp
    SecUploadApproveScript "/usr/local/bin/phpvalida"
    SecUploadKeepFiles Off

    # By default log and deny suspicious requests
    # with HTTP status 500
    SecFilterDefaultAction "deny,log,status:500"

</IfModule>

My Upload approve script is:

#!/usr/local/bin/php
<?php
$assunto = "UPLOAD DE ARQUIVO";
$de = "Alerta - HospedaVIP";
$emailde = "hos...@ho...";
$headers ="Content-Type: text/html; charset=iso-8859-1\n"; 
$headers .= "From: $de <$emailde>\n";
$headers .= "Reply-to: $de <$emailde>\n";
$mensagem = "UPLOAD DE ARQUIVO: $argv[1]";
mail($emailde,$assunto,$mensagem,$headers);
echo "1 deu certo\n";
?>

*just a script that sends an email telling me that a file was uploaded, then 
prints 1 :)

My debug log:

[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a37bc84]
[/projetos/envia.php] sec_check_access [path=(null)]
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a37bc84]
[/projetos/envia.php] Filtering off for a subrequest
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] sec_check_access [path=(null)]
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] Normalised REQUEST_URI: /projetos/envia.php
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] Parsing arguments...
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] Read 9327 bytes from POST [r=a807a3c]
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] content-type = "multipart/form-data; boundary=------------
---------------7d5bb242c0836"
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] multipart_process_boundary
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] multipart_process_data_chunk: state=0, size=152
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] multipart_process_data_chunk: got attribute name "file"
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] multipart_process_data_chunk: got attribute 
filename "C:\\Documents and Settings\\Daniel Schultz\\Meus 
documentos\\Daniel\\Backups - 17-06-2005\\66041.jpg"
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] verify_uploaded_files: 
executing "/usr/local/bin/phpvalida" to verify "/tmp/20051219-142640-
201.8.167.208-66041.jpg"
[19/Dec/2005:14:26:40 -0200] [www.hospedavip.com/sid#a09b59c][rid#a807a3c]
[/projetos/envia.php] Access denied with code 500. Error verifying files: 
Received no output from the approver script (execution 
failed?) "/usr/local/bin/phpvalida"

----------

Every time is:

 Access denied with code 500. Error verifying files: Received no output from 
the approver script (execution failed?) "/usr/local/bin/phpvalida"

My script is right...what els could generate this error?

Thanks

Daniel

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

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

Zach Roberts wrote:
> I've been known to be wrong about Plesk from time to time since I don't
> work with it much.
> 
> At any rate for those of us that use Apache 1.3 for one reason or
> another would benefit from this.
> 
> Any ETA on a release or at least a beta?

  I've made the changes. I will release 1.9.2-rc1 either tonight or
  tomorrow morning. I am hoping you will give me feedback on the
  PCRE compilation prior to final 1.9.2.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

[mod-security-users] Spec file for RH 7.3 for 1.9.1

[G. R. S. <ge...@pa...>]

For those who need 1.9.1 on RH7.3, try the following specfile. No
guarantees but working on my system.

Summary: Security module for the Apache HTTP Server
Name: modsecurity-apache
Version: 1.9.1
Release: 1.path
License: GPL
URL: http://www.modsecurity.org
Group: System Environment/Daemons
Source: http://www.modsecurity.org/download/%{name}-%{version}.tar.gz
Source1: mod_security.conf
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
Requires: webserver
BuildRequires: apache-devel

%description
ModSecurity is an open source intrusion detection and prevention engine
for web applications. It operates embedded into the web server, acting
as a powerful umbrella - shielding web applications from attacks.

%prep

%setup -q -n %{name}-%{version}

%build
/usr/sbin/apxs -Wc,"%{optflags}" -c apache1/mod_security.c

%install
rm -rf %{buildroot}
mkdir -p $RPM_BUILD_ROOT%{_libdir}/apache
install -m755 apache1/mod_security.so $RPM_BUILD_ROOT%{_libdir}/apache/
mkdir -p %{buildroot}/%{_sysconfdir}/httpd/conf
install -m644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/httpd/conf

%clean
rm -rf %{buildroot}

%files
%defattr (-,root,root)
%doc CHANGES LICENSE INSTALL README httpd* doc/*.pdf util
%{_libdir}/apache
%config(noreplace) %{_sysconfdir}/httpd/conf/mod_security.conf

%changelog
* Sun Dec 18 2005 G. Roderick Singleton <ge...@pa...> 1.9.1-1
- initial RH 7.3 build

-- 
G. Roderick Singleton <ge...@pa...>
PATH tech

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

[Zach R. <ad...@li...>]

I've been known to be wrong about Plesk from time to time since I don't 
work with it much.

At any rate for those of us that use Apache 1.3 for one reason or 
another would benefit from this.

Any ETA on a release or at least a beta?

Zach

Michael Shinn wrote:

> Zach Roberts wrote:
>
>> This sounds like a very good idea. Some of us that use mod_security 
>> do so with cPanel, Plesk, or other commercial control panels in 
>> shared hosting environments and cannot switch to Apache 2 since it is 
>> not supported.
>
>
>
> Apache 2.x is supported by Plesk (and has been for years).
>
>>
>> Keep up the great work Ivan. :)
>>
>> Zach
>>
>> Ivan Ristic wrote:
>>
>>> Some information for those of you using ModSecurity with
>>> Apache 1.3.x:
>>>
>>> I have just completed a round of performance tests. As some of
>>> you already know, the regular expression engine that comes
>>> with Apache 1.3.x is much slower than the one that comes with
>>> Apache 2.x (PCRE). When I say slower I mean *several times*
>>> slower for non-trivial requests.
>>>
>>> However, today I tried something else: I compiled
>>> ModSecurity for Apache 1.3.x against PCRE instead of the
>>> built-in regex library. I only had a very brief time to
>>> test the result but it appears that everything works
>>> well and the regex execution speed is equal to that of
>>> Apache 2.x.
>>>
>>> Chances are I will officially support compilation against
>>> PCRE in the forthcoming 1.9.2.
>>>
>>>  
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through 
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

[Michael S. <mi...@go...>]

Zach Roberts wrote:

> This sounds like a very good idea. Some of us that use mod_security do 
> so with cPanel, Plesk, or other commercial control panels in shared 
> hosting environments and cannot switch to Apache 2 since it is not 
> supported.


Apache 2.x is supported by Plesk (and has been for years).

>
> Keep up the great work Ivan. :)
>
> Zach
>
> Ivan Ristic wrote:
>
>> Some information for those of you using ModSecurity with
>> Apache 1.3.x:
>>
>> I have just completed a round of performance tests. As some of
>> you already know, the regular expression engine that comes
>> with Apache 1.3.x is much slower than the one that comes with
>> Apache 2.x (PCRE). When I say slower I mean *several times*
>> slower for non-trivial requests.
>>
>> However, today I tried something else: I compiled
>> ModSecurity for Apache 1.3.x against PCRE instead of the
>> built-in regex library. I only had a very brief time to
>> test the result but it appears that everything works
>> well and the regex execution speed is equal to that of
>> Apache 2.x.
>>
>> Chances are I will officially support compilation against
>> PCRE in the forthcoming 1.9.2.
>>
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

Re: [mod-security-users] modsecurity and spam in OWA

[Tom A. <tan...@oa...>]

Ivan Ristic wrote:
>   I am not aware of any legitimate use of a NULL byte. Can you
>   provide an example?

I don't recall, but I know I was blocking it and I had to stop for some 
legitimate reason.  The best thing to do is to block it and then see if 
any of your users complain about being blocked.

Tom

Re: [mod-security-users] modsecurity and spam in OWA

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

Tom Anderson wrote:
> Jason Haar wrote:
> 
>> Anyway, I had "SecFilterForceByteRange 32 126" and it blocked that URL
>> as there was a char 228 in there
>>
>> Sooo, what should I block instead? Given the fact that the Webapp needs
>> to present almost any char (i.e. assuming a Subject line could contain
>> any char), could I do an exclusion list instead? i.e. accept everything
>> other than NULL, etc? And if so, can someone tell me what "etc" should
>> actually be? ;-)
> 
> 
> I've found SecFilterForceByteRange to provide false positives on
> anything less than 0-255.  Unless you're running a very simple website,
> you just don't know when a user will enter a valid character outside of
> your arbitrary range.  As you said, many applications require the use of
> almost any character.  I addressed user complaints over a period of
> months, slowly expanding the range, until I was left at 0-255 before the
> complaints stopped.

  That's probably true if you want to have one configuration for
  all sites on a shared hosting server. But if you are controlling
  your own ModSecurity configuration then you surely now the
  character set you are using. And if you need to include all
  sorts of characters you are much better off using Unicode with
  UTF-8 validation feature.


> As far as blocking certain characters, yes you can, but even NULL may
> give false positives.  Whatever that list may be is entirely driven by
> what your site needs to process.

  I am not aware of any legitimate use of a NULL byte. Can you
  provide an example?

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

[K. C. L. <li...@la...>]

On Fri, 16 Dec 2005, Ivan Ristic wrote:

>   In my experience symptoms like the ones you reported occur
>   when the web server experiences very high load (with or without
>   ModSecurity). Since running ModSecurity requires additional resources
>   it may be that it's what tipped the system over the edge so to speak.

Our web server is indeed subjected to quite high load from time to time.

I have just compiled mod_security with Apache v1.3.34 and the high CPU on
one Apache instance occurred about an hour into the restart. Below is a
section of ps showing that PID 29759 was continuously running:

29755 ?        S      0:00 /usr/local/apache/bin/httpsd
29756 ?        S      0:00 /usr/local/apache/bin/gcache 505 /usr/local/apache/logs/gcache_port
29757 ?        S      1:08 /usr/local/apache/bin/httpsd
29758 ?        S      0:52 /usr/local/apache/bin/httpsd
29759 ?        R      7:18 /usr/local/apache/bin/httpsd
29760 ?        S      0:49 /usr/local/apache/bin/httpsd
29761 ?        S      0:56 /usr/local/apache/bin/httpsd
29762 ?        S      1:04 /usr/local/apache/bin/httpsd
29763 ?        S      1:33 /usr/local/apache/bin/httpsd
29764 ?        S      0:43 /usr/local/apache/bin/httpsd
29765 ?        S      1:43 /usr/local/apache/bin/httpsd
29766 ?        S      0:50 /usr/local/apache/bin/httpsd
29768 ?        S      1:21 /usr/local/apache/bin/httpsd
29771 ?        S      1:34 /usr/local/apache/bin/httpsd

ruby:~# /usr/local/apache/bin/httpsd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_rewrite.c
  mod_access.c
  mod_auth.c
  mod_setenvif.c
  apache_ssl.c
  mod_php4.c
  mod_security.c
suexec: enabled; valid wrapper /usr/local/apache/bin/suexec

Apart from reducing the high load, are there anything that could be done
to rectify the problem?

Regards,

Kwong Li
London

Re: [mod-security-users] PHP mail() header injection issues

[Kelson <ke...@sp...>]

Ivan Ristic wrote:
>   That's because you are trying to work it out through the browser.
>   But if you access the form programmatically you can construct
>   any content you like, replacing %0A (encoded \n with three characters)
>   with only one character \n.

One way I tested some of my scripts was to replace a bunch of <input 
type="text"> fields with <textarea></textarea>.  Even just tossing stuff 
in there proved very educational!

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>

Re: [mod-security-users] PHP mail() header injection issues

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

li...@32... wrote:
> on 12/16/05 11:50 AM, Ivan Ristic at iv...@we... wrote:
> 
> 
>>>Thing that has me stuck is this, everytime I try to punch this string
>>>into a sample "From:" field on a test form, when I print the string to
>>>the screen it comes out exactly like that with the "%0A" and all. The
>>>"%0A" is suppose to be converted into a "\n" which is needed of for the
>>>exploit to work. Problem is that POST data does not get unencoded like
>>>GET data on the other end and the PHP mail() just barfs.
>>>
>>>If I try to send the same string with plain old "\n" then it ends up
>>>looking like this "\\n" on the other side because Magic Quotes is
>>>escaping my backslash.
>>>
>>>I am confused as to how the SPAMMERS have been able to successfully pass
>>>the "\n" which is needed in a POST when I can't do it myself.
>>
>>  That's because you are trying to work it out through the browser.
>>  But if you access the form programmatically you can construct
>>  any content you like, replacing %0A (encoded \n with three characters)
>>  with only one character \n.
>>
>>-- 
>>Ivan Ristic
> 
> 
> 
> Ivan,
> 
> What would you recommend as a rule to thwart these attempts?

  How about something like (not tested in real life):

  SecFilterSelective ARGS_VALUES "\n[[:space:]]*(bcc:|cc:)"

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

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

K. C. Li wrote:
>
>>  Is that something that happened to you once, or is it something that
>>  happens every time you turn ModSecurity on? Also, which version of
> 
> We switched it on twice. The first time the high CPU usage occurred a few
> hours into the running. The second time the high CPU usage occurred about
> a day later. But when it occurs, Apache would effectively hang until
> restarted.
>
> ...
>
> The Apache server is quite busy so would probably produce a large amount
> of strace or debugging information. I'll have a read and see what are
> practical to do. Thanks.

  In my experience symptoms like the ones you reported occur
  when the web server experiences very high load (with or without
  ModSecurity). Since running ModSecurity requires additional resources
  it may be that it's what tipped the system over the edge so to speak.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] modsecurity and spam in OWA

[Tom A. <tan...@oa...>]

Jason Haar wrote:
> Anyway, I had "SecFilterForceByteRange 32 126" and it blocked that URL
> as there was a char 228 in there
> 
> Sooo, what should I block instead? Given the fact that the Webapp needs
> to present almost any char (i.e. assuming a Subject line could contain
> any char), could I do an exclusion list instead? i.e. accept everything
> other than NULL, etc? And if so, can someone tell me what "etc" should
> actually be? ;-)

I've found SecFilterForceByteRange to provide false positives on
anything less than 0-255.  Unless you're running a very simple website,
you just don't know when a user will enter a valid character outside of
your arbitrary range.  As you said, many applications require the use of
almost any character.  I addressed user complaints over a period of
months, slowly expanding the range, until I was left at 0-255 before the
complaints stopped.

As far as blocking certain characters, yes you can, but even NULL may
give false positives.  Whatever that list may be is entirely driven by
what your site needs to process.

Tom

Re: [mod-security-users] modsecurity and spam in OWA

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

Jason Haar wrote:
> This may sound like a feature instead of a bug, but I thought it might
> reflect how complex Web security can actually be...
> 
> We use an Apache reverse-proxy to protect a Microsoft Outlook Web Access
> (OWA) server, and I have modsecurity-1.9.1 in there doing it's thing.
> 
> However, I just found it blocked me from reading some nice Asian spam
> someone kindly thought to send me:
> 
> GET
> /exchange/username/Inbox/%E4%B8%8A%E7%BD%91%E9%A1%BA%E5%B8%A6%E6%8C%A3%E7%BE%8E%E5%85%83.EML?Cmd=open
> HTTP/1.1
> 
> (OWA creates links to each msg based on the Subject line)
> 
> Anyway, I had "SecFilterForceByteRange 32 126" and it blocked that URL
> as there was a char 228 in there
> 
> Sooo, what should I block instead? Given the fact that the Webapp needs
> to present almost any char (i.e. assuming a Subject line could contain
> any char), could I do an exclusion list instead? i.e. accept everything
> other than NULL, etc? And if so, can someone tell me what "etc" should
> actually be? ;-)

  I've been thinking about that a lot recently. The solution is
  probably in anomaly detection using statistics or neural networks.

  Here's an interesting paper on the subject:
  http://www.cs.ucsb.edu/~vigna/pub/2005_kruegel_vigna_robertson_CN05.pdf

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] PHP mail() header injection issues

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

Mojo Jojo wrote:
>
> Thing that has me stuck is this, everytime I try to punch this string
> into a sample "From:" field on a test form, when I print the string to
> the screen it comes out exactly like that with the "%0A" and all. The
> "%0A" is suppose to be converted into a "\n" which is needed of for the
> exploit to work. Problem is that POST data does not get unencoded like
> GET data on the other end and the PHP mail() just barfs.
> 
> If I try to send the same string with plain old "\n" then it ends up
> looking like this "\\n" on the other side because Magic Quotes is
> escaping my backslash.
> 
> I am confused as to how the SPAMMERS have been able to successfully pass
> the "\n" which is needed in a POST when I can't do it myself.

  That's because you are trying to work it out through the browser.
  But if you access the form programmatically you can construct
  any content you like, replacing %0A (encoded \n with three characters)
  with only one character \n.

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

[K. C. L. <li...@la...>]

On Fri, 16 Dec 2005, Ivan Ristic wrote:

>   That's not what I did. I simply changed ModSecurity to
>   use PCRE directly, ignoring the regex library that comes
>   with Apache 1.3.x.

Ah, I see. No wonder I couldn't see any option to select which regex
engine to use in Apache or PHP.

>   Hmmm, yours is the first report to mention ModSecurity malfunctioning
>   like that. (And, for the record, I don't get many bug reports either ;)

It is probably our configuration rather than mod_security that is causing
the problem. It is a great idea and we couldn't wait to have it running
properly. Some popular applications such as phpNuke are so full of
security holes that it is a nightmare for any sysadmin.

>   Is that something that happened to you once, or is it something that
>   happens every time you turn ModSecurity on? Also, which version of

We switched it on twice. The first time the high CPU usage occurred a few
hours into the running. The second time the high CPU usage occurred about
a day later. But when it occurs, Apache would effectively hang until
restarted.

>   ModSecurity did you use?

Sorry, I should have given that information initially. It is version
1.9.1.

>   If you are up for it (I am) maybe you can do some of the things
>   listed in the Apache debugging guide:
> 
>   http://httpd.apache.org/dev/debugging.html
> 
>   Starting with strace, for example.

The Apache server is quite busy so would probably produce a large amount
of strace or debugging information. I'll have a read and see what are
practical to do. Thanks.

> > SecFilterSelective REQUEST_METHOD "^POST$" chain
> 
>   ^ Another directive is supposed to come after this one. (It's not
>     something that would have brought a process down, though.)

Sorry, I have omitted it by mistake on copying. It should be followed by:

SecFilterSelective HTTP_Content-Length "^$"

Regards,

Kwong Li
London

Re: [mod-security-users] Performance using ModSecurity with Apache 1.3.x

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

K. C. Li wrote:
>
> That sounds interesting. How does one compile Apache 1.3.x with PCRE
> instead of the built-in regex engine please?

  That's not what I did. I simply changed ModSecurity to
  use PCRE directly, ignoring the regex library that comes
  with Apache 1.3.x.


> While on the subject of response time, we deployed mod_security on one of
> our Apache 1.3.33 servers (PHP-4.4.1, OpenSSL-0.9.8, Apache_SSL and
> mmcache-2.4.4) running Linux 2.2.26. It worked well for anything between a
> few hours to a day before two, and only two, of the Apache child processes
> start eating up CPU time. eg. 45% and 49%. Apache would eventually become
> unresponsive and had to be restarted. Recompiling Apache without
> mod_security would restore it to it's former steady running state. Any
> pointers as what might be causing the high CPU consumption please?

  Hmmm, yours is the first report to mention ModSecurity malfunctioning
  like that. (And, for the record, I don't get many bug reports either ;)
  Is that something that happened to you once, or is it something that
  happens every time you turn ModSecurity on? Also, which version of
  ModSecurity did you use?

  If you are up for it (I am) maybe you can do some of the things
  listed in the Apache debugging guide:

  http://httpd.apache.org/dev/debugging.html

  Starting with strace, for example.



> Please see the Apache configuration section of mod_security at the end.
>
> ...
>
> SecFilterSelective REQUEST_METHOD "^POST$" chain

  ^ Another directive is supposed to come after this one. (It's not
    something that would have brought a process down, though.)

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org