Web Hosting Talk







View Full Version : mod_security 1.8.4 problem


cannibal
10-30-2004, 02:02 PM
Hi

I installed mod_security 1.8.4 (cpanel/WHM) server

http://www.modsecurity.org/download...ty-1.8.4.tar.gz

and I add this module

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

# Change Server: string
SecServerSignature " "

# Make sure that URL encoding is valid
SecFilterCheckURLEncoding On

# This setting should be set to On only if the Web site is
# using the Unicode encoding. Otherwise it may interfere with
# the normal Web site operation.
SecFilterCheckUnicodeEncoding Off

# Only allow bytes from this range
SecFilterForceByteRange 1 255

# The audit engine works independently and
# can be turned On of Off on the per-server or
# on the per-directory basis. "On" will log everything,
# "DynamicOrRelevant" will log dynamic requests or violations,
# and "RelevantOnly" will only log policy violations
SecAuditEngine RelevantOnly

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

# Should mod_security inspect POST payloads
SecFilterScanPOST On

# Action to take by default
SecFilterDefaultAction "deny,log,status:500"

# Require HTTP_USER_AGENT and HTTP_HOST in all requests
SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"

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

# Weaker XSS protection but allows common HTML tags
SecFilter "<[[:space:]]*script"

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

# Very crude filters to prevent SQL injection attacks
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"

# Protecting from XSS attacks through the PHP session cookie
SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"
</IfModule>



After I restart httpd, no images appears on the sites that hosted on the server and some other pages too

I tried to put SecAuditEngine on (DynamicOrRelevant)

but the problem still there

any ideas ??

BudWay
10-30-2004, 04:01 PM
mod_security is a layer that will block things if you don't set it up right.

Check your audit log for more information why is this happend and what you need to tweak on your rules set.

good luck

sawbuck
10-30-2004, 04:33 PM
If you change SecFilterEngine to off and restart apache do
you still have the problem? Latest version is 1.8.5.
Presume you have read the manual?
http://modsecurity.org/documentation/index.html
If all else fails you can contact Ivan Ristic the developer.

cannibal
10-31-2004, 02:25 AM
yha I set SecFilterEngine off and the problem still there

Blueheaven
10-31-2004, 04:41 AM
if you isntalled mod security with a log file
type pico /var/log/httpd/audit_log
and it will come up with the errors you're getting

if the error still persists, disable mod security altogether by commenting out mod_security in httpd configuration

then if the error is gone, go back and see if you troubleshoot which it error it is using audit_log

sawbuck
10-31-2004, 11:07 AM
Originally posted by cannibal
yha I set SecFilterEngine off and the problem still there
Presuming you restarted apache after commenting it out then the problem is not with mod_security.

Steven
10-31-2004, 11:43 AM
SecFilter "<(.|n)+>"


That will cause alot of problems.

linux-tech
10-31-2004, 01:31 PM
# Very crude filters to prevent SQL injection attacks
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"

You'll want to drop these from your rules as well
phpmyadmin is a very useful tool and will get stopped with these queries.
Any query that tries to "insert user into database" will automatically get stopped
VBulletin will get stopped, etc
The list goes on and on.
If you don't plan on running sql then you can leave those in there, but mysql is becoming more and more popular (and necessary). Leaving those rules in there will just make a mess :)

Steven
10-31-2004, 01:41 PM
Originally posted by linux-tech
You'll want to drop these from your rules as well
phpmyadmin is a very useful tool and will get stopped with these queries.
Any query that tries to "insert user into database" will automatically get stopped
VBulletin will get stopped, etc
The list goes on and on.
If you don't plan on running sql then you can leave those in there, but mysql is becoming more and more popular (and necessary). Leaving those rules in there will just make a mess :)


Please note if you are using cpanel, phpmyadmin will not be affected because it uses an internal version of php and php.ini for cpanel.

cannibal
10-31-2004, 02:12 PM
I change

SecFilter "../" to SecFilter "\.\./"

SecFilter "<(.|n)+>" to SecFilter "<(.|\n)+>"

and its works fine

I tried to use PHPMYADMIN and I add user by vb forum
it was fine no error without removing

# Very crude filters to prevent SQL injection attacks
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"

Steven
10-31-2004, 02:21 PM
You changed the purpose of those rules. Just for info, that rule set will prevent very little attacks.

linux-tech
10-31-2004, 05:03 PM
Originally posted by cannibal
I change

SecFilter "../" to SecFilter "\.\./"

SecFilter "<(.|n)+>" to SecFilter "<(.|\n)+>"

and its works fine

I tried to use PHPMYADMIN and I add user by vb forum
it was fine no error without removing

# Very crude filters to prevent SQL injection attacks
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
Right, as Steve said, if you're using cpanel phpmyadmin won't harm a thing. Outside of cpanel it will.

HOWEVER, try creating a vb user, try actually INSERTING something into the database. That will be stopped by that, because the query is "insert into database values"
You've said no, it can't be done
The same with delete and select.

cannibal
11-01-2004, 06:41 AM
Do you mean If I change

SecFilter "../" to SecFilter "\.\./"

SecFilter "<(.|n)+>" to SecFilter "<(.|\n)+>"

there is no use of mod_security now ??


about the DB I tried to register a user and its works fine.