mod-security-users — General discussion about mod_security

[mod-security-users] chroot and mod security

[<jim...@rc...>]

All,

I am new to mod_security, I have to say I am very impressed 
with the features and power in the application.  I have the 
code running on:
redhat 9.0 patched
apache 2.0.48
mod_security 1.7.4

I need to run a chroot for the apache server.  I have the 
code installed with the default path /usr/local/apache2.  I 
am using the SecChrootDir directive but I can't seem to get 
it right.  I will see a directory doesn't exist or like 
message in the logfile.

Shouldn't the chroot'd jail be /usr/local/apache2?  

Thanks in advance.

Regards,
Jim

[mod-security-users] Apache/PHP Configuration

[L. C. L. <CL...@Xy...>]

Can someone tell me the difference between RH 8.0 Apache's default
configuration for PHP handling:  

    <Files *.php>
       SetOutputFilter PHP
       SetInputFilter PHP
       LimitRequestBody 524288
    </Files>

And what the mod_security docs suggest for the Apache/PHP configuration:  

    AddHandler application/x-httpd-php .php  

I'm using the vanilla RH 8.0 Apache/PHP configuration, but with regard to
mod_security's dynamic request handling, I'm wondering what is best.  

TIA!



Sincerely,  

L. Christopher Luther  
Technical Consultant  
Xybernaut Solutions, Inc.  
(703) 654-3642  
cl...@xy...  
http://www.xybernautsolutions.com  

PGP Public KeyID:  0x21261B88

CONFIDENTIALITY NOTE:  This communication contains 
information that is confidential and/or legally privileged.  
This information is intended only for the use of the individual 
or entity named on this communication. If you are not the 
intended recipient, you are hereby notified that any disclosure, 
copying, distribution, printing or other use of, or any action 
in reliance on, the contents of this communication is strictly 
prohibited.  If you receive this communication in error, please 
immediately notify us by telephone at (703) 631-6925. 

============================================
Unsolicited commercial e-mail will automatically be 
reported to the appropriate abuse@ - without exception.
============================================

RE: [mod-security-users] How to disable this?

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

Thank you!

-----Original Message-----
From: Ivan Ristic [mailto:iv...@we...] 
Sent: 10 ????? 2004 ?. 22:55
To: Tkachenko Alexei
Cc: mod...@li...
Subject: Re: [mod-security-users] How to disable this?


Tkachenko Alexei wrote:

> Let I have "SecFilter /somedir".
> With CGI-Telnet Version 1.0 user can perform the following:
> 1) cd /
> 2) ls /somedir - get's error
> 3) ls somedir - and get content of the somedir.
> 
> Is there any way to prevent this?

   No, not really. You see, once you allowed your users to have
   CGI access you have also given them permission to read the
   contents of various folders on the server.

   You can write rules to stop users from using shell-emulators
   but, ultimately, knowledgeable users will always be able to
   get around them.

   The only proper solution is to to use cgiwrap for CGI
   scripts and the safe mode/open_basedir restrictions for PHP.

   If you still want to continue with mod_security, you should
   look into the source code of the shell emulator and make note
   of the variable names it uses to pass commands to the server.

   Then, add a filter to watch for those. cgitelnet, if I
   recall correctly uses 'a' for action and 'c' for command.

   This filter will reject requests with a parameter 'c' that
   start with "ls"...

   SecFilterSelective ARG_c "^[[:space::]*ls"

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

Re: [mod-security-users] How to disable this?

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

Tkachenko Alexei wrote:

> Let I have "SecFilter /somedir".
> With CGI-Telnet Version 1.0 user can perform the following:
> 1) cd /
> 2) ls /somedir - get's error
> 3) ls somedir - and get content of the somedir.
> 
> Is there any way to prevent this?

   No, not really. You see, once you allowed your users to have
   CGI access you have also given them permission to read the
   contents of various folders on the server.

   You can write rules to stop users from using shell-emulators
   but, ultimately, knowledgeable users will always be able to
   get around them.

   The only proper solution is to to use cgiwrap for CGI
   scripts and the safe mode/open_basedir restrictions for PHP.

   If you still want to continue with mod_security, you should
   look into the source code of the shell emulator and make note
   of the variable names it uses to pass commands to the server.

   Then, add a filter to watch for those. cgitelnet, if I
   recall correctly uses 'a' for action and 'c' for command.

   This filter will reject requests with a parameter 'c' that
   start with "ls"...

   SecFilterSelective ARG_c "^[[:space::]*ls"

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

[mod-security-users] How to disable this?

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

Let I have "SecFilter /somedir".
With CGI-Telnet Version 1.0 user can perform the following:
1) cd /
2) ls /somedir - get's error
3) ls somedir - and get content of the somedir.

Is there any way to prevent this?

Re: [mod-security-users] Directory traversal directive not working

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

> I am testing mod_security with 2.0.48 on Solaris 8.
> mod_security as been setup as a DSO.
> My problem is that the very simple directory traversal directive ( below)
> does not work:
> SecFilter "\.\./"
 >
 > ...
>  
> Am i missing something?

   The Apache is normalizing the path before mod_security
   gets to it (you can see it in the debug log if you increase
   the verbosity of the log). If you try something like:

   /cgi-bin/modsec-test.pl?p=123/../456

   it will work. Apache only normalizes the data on the
   left hand of the question mark character.

   For some time now I've been thinking whether to move
   mod_security processing into an earlier stage but there
   are so many advantages and disadvantages that I haven't
   made the decision yet.

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

[mod-security-users] Directory traversal directive not working

[<lde...@ne...>]

Hi,

  I am testing mod_security with 2.0.48 on Solaris 8.
mod_security as been setup as a DSO.
My problem is that the very simple directory traversal directive ( below)
does not work:
SecFilter "\.\./"

The other directives preventing SQL injection or XSS work fine for me.
I have configured mod_security to return a HTTP 500 error and i am testin=
g
the directory traversal directly from the command line with the runtest.p=
l
script.
Exemple:
./run-test.pl webserver1:666 ./03-evasion-traversal.test

I get a HTTP error of 404 instead of 500.

Here 's the request received in the log file:
[08/Jan/2004:18:20:25 +0100] 17.30.5.160 SSLv3 DHE-RSA-AES256-SHA "GET
/cgi-bin/dummy/../modsec-test.pl/keyword HTTP/1.0" 4954
( Just to show it has not been altered between the client and the server)

Note that I have tested the request through a SSL tunnel because Apache
only listens on a SSL port.

Running mod_security in debug mode gives me this:
[08/Jan/2004:18:31:08 +0100]
[webserver1/sid#188130][rid#21a528][/cgi-bin/modsec-test.pl/keyword]
Checking signature "\.\./" at THE_REQUEST

It's strange cause I don't see any  "regex_result: 17 is_allow: 0"
that i see for the other rules. Exemple:
[08/Jan/2004:18:31:08 +0100]
[webtest1/sid#188130][rid#21a528][/cgi-bin/modsec-test.pl/keyword]
check_sig_against_string: string
: /cgi-bin/modsec-test.pl/keyword regex_result: 17 is_allow: 0

Am i missing something?

Thanks in advance,
Luc

Here 's my complete configuration

############################################################

# Turn the filtering engine On or Off
 SecFilterEngine On

# Make sure that URL encoding is valid
 SecFilterCheckURLEncoding On

# Only allow bytes from this range ( ASCII caracters from 32 to 126)
# Avoid some of the buffer overflow attacks
 SecFilterForceByteRange 32 126

# Default action for security filters
 SecFilterDefaultAction "deny,log,status:500"

# Mask the signature of the server
 SecServerSignature "Microsoft-IIS/6.0"

# The audit engine works independently and
# can be turned On of Off on the per-server or
# on the per-directory basis
 SecAuditEngine RelevantOnly

# The name of the audit log file
 SecAuditLog /var/log/httpd/audit_log

# SecFilterDebugLog /var/log/httpd/modsec_debug_log
# SecFilterDebugLevel 0

# Should mod_security inspect POST payloads
 SecFilterScanPOST On
 SecFilterSelective THE_REQUEST "///"
 SecFilterSelective THE_REQUEST "/\.\.\.\."

# Prevent path traversal (..) attacks
 SecFilter "\.\./"

# WEB-MISC Apache Chunked-Encoding worm attempt
 SecFilter "CCCCCCC\: AAAAAAAAAAAAAAAAAAA"

# WEB-MISC WEB-INF access
 SecFilterSelective THE_REQUEST "/WEB-INF"

# WEB-MISC weblogic view source attempt
 SecFilterSelective THE_REQUEST "\.js\x70"

# Weaker XSS protection but allows common HTML tags
 SecFilter "<( |\n)*script"

# Prevent XSS atacks (HTML/Javascript injection)
 SecFilter "<(.|\n)+>"

# Prevent SQL injection attacks
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"

Re: [mod-security-users] The directory traversal problem

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

> As Ivan wrote on webappsec, putting together a repository
> with regexes and other snippets for mod_security would be
> a good idea.

   I'm half way there. The most boring bits of the (web)
   application are completed and I expect to have the rule
   database running (in a beta version) by the end of
   January.

   On a similar note, I've joined the WAS TC committee:
   http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=was

   to work on a specification for Web server/application
   protection. I expect the rule database to be compatible
   with the WAS spec. once it is completed.

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

[mod-security-users] The directory traversal problem

[Ulf H. <me...@op...>]

I haven't tested this, but the following regexes should be helpful when trying to combat directory traversal:

  ^[/\]
  \.\.

The first matches any string that begins with "/" or "\" characters (like in "/etc/passwd"). The second matches any string with two dots in a row (which of course disallows legitimate filenames like "ulfs.nice.document..doc", but it also catches malicious things like "../../../../../../etc/passwd").

Any other ideas?

As Ivan wrote on webappsec, putting together a repository with regexes and other snippets for mod_security would be a good idea.

// Ulf

-- 
___________________________________________________
Check out the latest SMS services @ http://www.operamail.com, which allows you to send SMS through your mailbox.

Powered by Outblaze

Re: [mod-security-users] Restriction to / dir

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

Ulf Harnhammar wrote:
>>  ModSecurity can scan parameters for suspicious strings but it's
>>  not foolproof. It needs something distinctive to act upon. For
>>  example, protecting "/boot" is easy. But the root "/" - not simple.
> 
> 
> What about this regular expression?
> 
>   ^/[^/]*$
> 
> It will match strings that begin with a slash and then have zero
 > or more characters that are something else than slashes.

   That will work if you use it like this:

   SecFilterSelective SCRIPT_FILENAME "^/[^/]*$"

   but, again, that only covers the files executed and/or served
   by Apache. In my earlier email I was referring to various scripts
   that allow file download, accepting filenames as parameters.

   For example:

   http://www.xyz.com/cgi-bin/download.php?filename=/etc/passwd

   If you know about this script you can secure it (either by making
   sure it works properly, or by using mod_security to look after it).
   But in a shared hosting environment when you have customers uploading
   arbitrary scripts with arbitrary parameters crafting a filter to
   catch those / downloads is pretty difficult (without creating a
   large number of false positives, that is).

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

Re: [mod-security-users] Restriction to / dir

[Ulf H. <me...@op...>]

>   ModSecurity can scan parameters for suspicious strings but it's
>   not foolproof. It needs something distinctive to act upon. For
>   example, protecting "/boot" is easy. But the root "/" - not simple.

What about this regular expression?

  ^/[^/]*$

It will match strings that begin with a slash and then have zero or more characters that are something else than slashes.

I think it might be useful for people who want to restrict mod_security to only allow files from the top-dir, or for that matter, to restrict it to files in other dirs than the top-dir.

// Ulf Harnhammar
   kses - PHP HTML/XHTML filter (no XSS)
   http://sourceforge.net/projects/kses

-- 
___________________________________________________
Check out the latest SMS services @ http://www.operamail.com, which allows you to send SMS through your mailbox.

Powered by Outblaze

Re: [mod-security-users] Restriction to / dir

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

>>>  What kind of restriction? Do you mean the root (/) of the
>>>  file system, or the root of the web server?
> 
> 
> Yes, I meant the root of file system.
> With /boot I can block access to the /boot dir but I'm not sure
> how can I block the upper (root) dir.
> 
> 
>>>  Both are possible. You don't need mod_security, mod_access
>>>  (built-in) already supports that with Allow and Deny
>>>  directives.
> 
> 
> seems not possible.
> how can I block root system dir with deny directive?

   Like this:

   # First you block everything
   <Directory />
      Order Deny,Allow
      Deny from all
   </Directory>

   # Then allow what you want
   <Directory /home/www>
      Order Deny,Allow
      Allow from all
  </Directory>

  The code above will tell the web server not to serve
  files that are not in the /home/www subdirectory (/, /boot, whatever).

  If you want a solution to prevent someone from exploiting a
  vulnerable script and trick it into serving a file from the
  root of the file system: the only real protection is to
  chroot the web server or your scripts (if we are talking CGI,
  use the safe mode for PHP).

  ModSecurity can scan parameters for suspicious strings but it's
  not foolproof. It needs something distinctive to act upon. For
  example, protecting "/boot" is easy. But the root "/" - not simple.

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

[Fwd: Re: [mod-security-users] Issue uploading files via http with Apache2, php 4.3.4, and mod_security.]

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

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

Re: [mod-security-users] A few requests :)

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

> I got a few friends that like to test out my filter and stuff with the 
> newest gadgets (retina for one) on my webserver.
> Can you make a keyword in mod_security that lets me take away the 
> protection/logging for certain ip's or ip ranges?

   That's easy, put this on top of your riles:

   SecFilterSelective REMOTE_ADDR "IP_ADDRESS" allow


> And while you are at it, can you make a black list as well? meaning that 
> i want to log everything from a certain ip.

   Can you be more specific? What does "everything" mean? Do you
   want to trigger the audit log only for a specific IP address?


> Also, a keyword in mod_security that makes the logs more readable to 
> *programs* wouldn't hurt.

   What stopping programs from reading the current format?

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

[mod-security-users] A few requests :)

[root <ro...@da...>]

Situation:
I got a few friends that like to test out my filter and stuff with the =
newest gadgets (retina for one) on my webserver.
Can you make a keyword in mod_security that lets me take away the =
protection/logging for certain ip's or ip ranges?

And while you are at it, can you make a black list as well? meaning that =
i want to log everything from a certain ip.

Also, a keyword in mod_security that makes the logs more readable to =
*programs* wouldn't hurt.=20

maybe something like:

[warning 31]
IP: 123.123.123.123
Browser: Internet Explorer 15.0 (15.0 would at least fix the security =
bugs in it....we hope!)
Request: GET /that_pron_picture.jpg
Referer: www.christianchurch.org
[/warning 31]


I realize that im asking for 3 changes at once but you can maybe can =
take a look at these requests?

thnx ivan. and great job! :D

Re: [mod-security-users] Issue uploading files via http with Apache2, php 4.3.4, and mod_security.

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

mod...@bs... wrote:
> I'm running on FreeBSD 4.9 STABLE, I installed Apache 2.0.48,
 > PHP 4.3.4, and mod_security 1.7.3 from the ports.

   Can you please try 1.7.4:

   http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz

   A problem matching your descriptions existed in (probably all,
   but confirmed for 1.7.3) versions before 1.7.4 and it was fixed.

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

[mod-security-users] Issue uploading files via http with Apache2, php 4.3.4, and mod_security.

[<mod...@bs...>]

I'm running on FreeBSD 4.9 STABLE, I installed Apache 2.0.48, PHP 4.3.4, and mod_security 1.7.3 from the ports.

I added the following to my httpd.conf file to enable mod_security

LoadModule security_module    libexec/apache2/mod_security.so

<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 /var/log/httpd-audit.log
    # Debug level set to a minimum
    SecFilterDebugLog /var/log/httpd-modsec_debug.log
    SecFilterDebugLevel 0

    # Should mod_security inspect POST payloads
    SecFilterScanPOST On

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

</IfModule>

SecFilter DynamicOnly
SecFilterSelective REMOTE_ADDR "^xx.xx.xx.xx$" nolog,allow
SecFilter "drop[[:space:]]table"
SecFilterSelective COOKIE_sessionid "!^(|[0-9]{1,9})$"

When using a php script to upload files via http I get 64% of the file and
then it finishs as if successful, however the file is corrupt and will not
display correctly, the file size is 64% of the original size.  When I
disable mod_security in my httpd.conf file everything works fine.

If you would like to see my log files or the php script please let me
know.

Regards,
Kevin

RE: [mod-security-users] Restriction to / dir

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

Peace be with you,

>>   What kind of restriction? Do you mean the root (/) of the
>>   file system, or the root of the web server?

	Yes, I meant the root of file system.
	With /boot I can block access to the /boot dir but I'm not sure
how can I block the upper (root) dir.

>>   Both are possible. You don't need mod_security, mod_access
>>   (built-in) already supports that with Allow and Deny
>>   directives.

	seems not possible.
	how can I block root system dir with deny directive?

>>   If I understand what you're asking then this should probably
>>   do it:
>>
>>   SecFilter "/boot/?"

	Yes, something like this but I need solution for upper - root
dir.
	Is it just SecFilter "/" ?

-----
Regards,
Alex A. Tkachenko

Re: [mod-security-users] Restriction to / dir

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

Tkachenko Alexei [AlexAT] wrote:
>
> Is it possible to set restriction to the / dir ?
> How?

   What kind of restriction? Do you mean the root (/) of the
   file system, or the root of the web server?

   Both are possible. You don't need mod_security, mod_access
   (built-in) already supports that with Allow and Deny
   directives.


> And how to set both / and without / sections (like SecFilter /boot,
> SecFilter /boot/) in this case?

   If I understand what you're asking then this should probably
   do it:

   SecFilter "/boot/?"

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

[mod-security-users] Restriction to / dir

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

Peace be with you,

Is it possible to set restriction to the / dir ?
How?

And how to set both / and without / sections (like SecFilter /boot,
SecFilter /boot/) in this case?

Thank you!..

-----
Regards,
Alex A. Tkachenko

[mod-security-users] apache2 mod_perl chroot problem!

[Henning M. <Hen...@gm...>]

Hello *,

I have got problems running an apache-2.0.47-prefork with
modperl-1.99_09_20030807 and mod_security-1.7.4.
I've define a VirtualHost which is defined using the file attached to the
bottom.
This VHost works fine. My mod_security section looks like:
LoadModule security_module    modules/mod_security.so
If I now add:
<IfModule mod_security.c>
SecChrootDir /jail
</IfModule>
The static pages work very good, but if I do a request like:
https://myserver.com/bin/login.pl the server delivers an empty (0 Bytes)
file login.pl for download.
My Filesystem looks like:

/webapp/system/static.html
/webapp/bin/login.pl
and the same (copies) in:
/jail/webapp/system/static.html
/jail/webapp/bin/login.pl

Please help, what do I wrong?

Henning



<IfDefine SSL>
<IfDefine !NOSSL>
<VirtualHost _default_:443>
        DocumentRoot "/webapp/system"
        ErrorLog /var/log/apache2/error_log
        TransferLog /var/log/apache2/access_log

<Directory "/webapp/system">
    Options -FollowSymLinks
    Allow from all
</Directory>

<IfModule mod_alias.c>
        <IfModule mod_perl.c>
                Alias /bin/          "/webapp/bin/"
                PerlModule Apache2
                PerlModule Apache::compat
                PerlModule ModPerl::RegistryBB
                PerlSetEnv DB2INSTANCE db2inst1
                Perlrequire /webapp/startup2.pl
                PerlSwitches -T
                <Directory /webapp/bin>
                        SetHandler  perl-script
                        PerlSendHeader On
                        PerlResponseHandler ModPerl::RegistryBB
                        Allow from all
                        Options ExecCGI
                            SetEnv
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/db2inst1/sqllib/lib
                            SetEnv LIBPATH "/home/db2inst1/sqllib/lib"
                            SetEnv DB2INSTANCE "db2inst1"
                </Directory>
        </IfModule>
</IfModule>
        SSLEngine on
        SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile /etc/apache2/ssl.crt/server.cert.cert
        SSLCertificateKeyFile /etc/apache2/ssl.crt/server.cert.key
        SetEnvIf User-Agent ".*MSIE.*" \
                 nokeepalive ssl-unclean-shutdown \
                 downgrade-1.0 force-response-1.0
        CustomLog /var/log/apache2/ssl_request_log   ssl_combined
</VirtualHost>
</IfDefine>
</IfDefine>

Re: [mod-security-users] [OT] Japanese spammer

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

Tomoyuki Sakurai wrote:

> kawaneba.net, aka mutoh, is one of well-known Japanese spammers.
> 
> If you are a mail admin, you can safely block all traffic from the
> following rDNS.
> 
> (tokyo|tokushima|fukuoka|osaka|okayama|kyoto).ocn.ne.jp
> yournet.ne.jp
> ap.net-access.jp
> 
> If you are concern anout FP, just reject with 4xx in SMTP session. The
> spammer don't care about SMTP reply code, anyway.
> 
> | Received: from p2220-ipad68marunouchi.tokyo.ocn.ne.jp
> | ([220.96.32.220]:4774 helo=79.14.26.18)

   I've now restricted the posting privilege only to list members,
   so this shouldn't happen any more.

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

[mod-security-users] [OT] Japanese spammer

[Tomoyuki S. <ml-...@tr...>]

kawaneba.net, aka mutoh, is one of well-known Japanese spammers.

If you are a mail admin, you can safely block all traffic from the
following rDNS.

(tokyo|tokushima|fukuoka|osaka|okayama|kyoto).ocn.ne.jp
yournet.ne.jp
ap.net-access.jp

If you are concern anout FP, just reject with 4xx in SMTP session. The
spammer don't care about SMTP reply code, anyway.

| Received: from p2220-ipad68marunouchi.tokyo.ocn.ne.jp
| ([220.96.32.220]:4774 helo=79.14.26.18)

-- 
Tomoyuki Sakurai - Tomi -

[mod-security-users] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=96=B0=82=EA=82=C8=82=A2=96=E9=82=CD=81u=90=87=96=82=89=A4=81v=81c?=

[DXLove <er...@ka...>]

<=8E=96=8B=C6=8E=D2><=91=97=90M=8E=D2>
DXLove 
=94z=90M=92=E2=8E~=8A=F3=96]=82=CC=95=FB=82=CD=89=BA=8BL=82=CC=83=81=81[=83=8B=
=82=C5=91=97=90M=82=B5=82=C4=89=BA=82=B3=82=A2=81B
pa...@ka...
=93=8C=8B=9E=93s=91=E4=93=8C=8B=E6=8F=E3=96=EC2-6
TEL090-8174-2533

=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=
=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F
=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=
=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0
=81=A1=81=A0=81=A1=94N=93=E0=8A=A9=8D=90=95=C2=93X=81I=94=84=82=E8=90=D8=82=EA=
=83S=83=81=83=93=81I=81=A1=81=A0=81=A1
=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=
=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0=81=A0

=82Q=94N=8A=D4=83A=83_=83=8B=83g=83V=83=87=83b=83v=82=F0=89c=8B=C6=82=B5=82=C4=
=82=A2=82=DC=82=B5=82=BD=82=AA=81c
=8A=A9=8D=90=92=CA=92m=82=F0=8E=F3=82=AF=95=C2=93X=82=B5=82=DC=82=B7=81B
=94N=93=E0=82=B7=82=D7=82=C4=93=8A=82=B0=94=84=82=E8=91=E5=8F=88=95=AA=81I=8A=
=AE=91S=96=B3=8FC=90=B3=82=C5=82=B7=81I
=82=A8=91=81=82=DF=82=C9=82=A8=90\=82=B5=8D=9E=82=DD=89=BA=82=B3=82=A2=81B

http://220.106.2.94/dvd/

=8C=C0=92=E8=81I=91=81=82=A2=8E=D2=8F=9F=82=BF=81I=81I
18=8D=CE=96=A2=96=9E=82=CC=95=FB=82=CD=82=B2=89=93=97=B6=89=BA=82=B3=82=A2=81=
B
=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=
=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F=81=9E=81=9F  

Re: [mod-security-users] mod_security: Invalid character detected [252]

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

> I installed mod_Security on a server, and for the moments, all the pages 
> works fine. Now, I have some little issues that I describe above 
> (extracted from the audit_log file).
> Anybody can help me on this issue...??

   You've configured mod_security to reject requests containing
   characters that fall outside the 32-126 range (inclusive). And there
   are such characters in the example request you gave us.

   For example:

     /images/buttonse/inkassoausk%FCnfte.gif

   contains %fc (252)

   Change this line:

     SecFilterForceByteRange 32 126

   into:

     SecFilterForceByteRange 32 255

   and your problems will go away.

   FYI, future releases will include the ability to specify several
   ranges of acceptable characters, not only one as right now.

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