in which case a hacker will know how to get around it, I'm just asking if someone here with a good quality and current ruleset could PM it to me. I want to compare it to my own ruleset and see what I can add to it.
I've just had an annoying exploit recently and I am looking to try to improve my mod_security ruleset,
I just updated my mod_security rules to version 2 with the new rules from gotroot.com. I simply included them all. I know before with their 1.95 rules I had to sit and delete tons of useless rules as well as having to delete rules that interfered with peoples web apps.
So I figure it may be different with new version. Is anyone here running these rules on a hosting server? Doesn't matter cpanel or whatever, just an average shared server with moistly php/mysql sites.
I have been using mod_security 1.9.x since it first release on apache 1.3 and apache 2.0.x, rules are great and they work perfect with no issues at all with any php-mysql website. Do you recommend using mod_security 2.0 or 2.5 ? (I do know that 2.5 does not work with apache 1.3).
using mod_security, but I believe that I have it installed correctly with some rules that should be generating entries in the security audit log. No matter what I do, I can't seem to get mod_security to generate any sort of log entries.
I am using version 2.1.7. I compiled it with no problems. In my httpd.conf file, I have the following relevant lines:
LoadFile /usr/lib/libxml2.so LoadModule security2_module modules/mod_security2.so Include conf/modsecurity/*.conf
I don't think there are any problems here, as I know it is running directives from the configuration file I edited. This is the file I'm working with:
modsecurity_crs_10_config.conf
Here are the relevant lines from the config file:
SecRuleEngine On SecRequestBodyAccess On SecResponseBodyAccess On SecResponseBodyMimeType (null) text/html text/plain text/xml SecResponseBodyLimit 524288 SecDefaultAction "phase:2,auditlog,log,pass,status:500" SecAuditEngine On SecAuditLogType Serial SecAuditLog logs/modsec_audit.log SecAuditLogParts "ABIFHZ" SecRequestBodyInMemoryLimit 131072 SecDebugLog logs/modsec_debug.log SecDebugLogLevel 3
I know that the config file is being read because when I start apache, the log files (modsec_audit.log and modsec_debug.log) are created. The problem is that the files are empty and remain empty no matter what I do. I have even tried setting permissions on the files to 777.
Here are a couple of rules I created in an attempt to generate log entries:
I put these in the same config file mentioned above. As far as I understand, the first rule should examine the request body (which would include data in POST requests) for the word, "viagra". Since my default action is phase:2,auditlog,log,pass,status:500, such requests should end up in the audit log. However, when I use a form on my site to post the word "viagra", nothing is generated in the log file.
The second rule, as far as I understand, should generate a log entry any time the IP address 1.2.3.4 is sent in the request headers. Instead of 1.2.3.4, of course, I have put in my real IP address. However, when I visit my server and browse pages, nothing is logged. I assume that my requests should generate log entries since I match the IP address.
I am currently running a few small websites that use a CMS. Two are Dragonfly and one is Joomla.
I am getting sporadic errors with both systems that, upon research, seem to be related to Apache and the mod_security module. I am getting the following error:
Code: Not Acceptable
An appropriate representation of the requested resource /somefolder/index.php could not be found on this server.
Well, I'm no idiot (although some people may tend to disagree ) and after some searching, I found that this most likely points to an Apache error. Most solutions suggest to put the following in my .htacess file for the site:
Code: <IfModule mod_security.c> SecFilterEngine Off SecFilterScanPOST Off </IfModule>
It was noted that "SecFilterScanPOST Off" may or not be necessary. I have added the above to the .htaccess for each site (all 3 sites are subdomains) and have also added it to the .htaccess that is in the root folder for the site. Nothing has worked.
So my question is, is it possible that my webhost can override my .htaacess settings with their own? This is the only explanation that I can think of. But of course, I am no expert, which is why I turn to you good folks for help once again.
I installed modsecurity from Addone module in Cpanel
When I try to apply phpshell woork good without a mistakes and I can do anything despite of the presence of protection modsecurity and disable_functions in php.ini.
Is there a particular settings add to the httpd.conf to prevent application phpshell or prevent upload it to the site?
I tried using mod_security and mod_filter together. However, when I try to filter js files, I noticed that certain pages stop working, especially those using ajax.
I have installed a new server with debian lenny 5, ISPConfig 3.0.1.1 and the newest mod_security and implemented the default rules.
I deactivated the rule detecting IP in pageheaders.
Then I got another problem. Some actions of ISPConfig are detected as "remote file access attempt", severity "critical", tag "web attack/file injection" data "/etc/"
detected by rule file crs_40 line 114, id 950005
question: how do I authorize ISPConfig and only ISPConfig to perform such requests on the server?
Trying to use an RBL with ModSecurity but this matches everything whether listed or not. SecRule REMOTE_ADDR "@rbl bb.barracudacentral.org" "log,deny,msg:'POST RBL Comment Spammer'"
What I would like to do is do an RBL lookup and any POST operations.
Any good secure rules for mod_security 2 that work well for shared servers?
Can someone share what rules you are using to secure your shared servers. Have tried a few different sets of rules, but a few customers always end up with errors and disabling it for their domain name doesn't sound like a safer option for them or the server.
I've been having the hardest time getting mod_security on my new CentOS 5.2 64-bit box.
Everything is a straight, simple, standard install - nothing special or custom. Plesk and all the apps that come with it installed fine, everything was going great. Then I tried to compile mod_sec, and things have been nothing but problems. I think I've finally sorted out the problems with the compiler, but now I get this error:
/usr/bin/ld: warning: i386 architecture of input file `.libs/msc_lua.o' is incompatible with i386:x86-64 output
i have search this forum and google.but none of them can help me to instal it.
i have centos with direct admin. first i login via ssh to my server ~ then i wget the latest ver an untar it in ~ and go to /modsecurity-apache_2.5.7 folder and then apache2/ and run: ./configure make make install and config httpd.conf thats it.
is it right or not and how can i test it that is it work fine or not
I have been trying to install mod_security for the last few days and I can't seem to get it working. I'm with Rockmyweb hosting and for some reason although I have it listed in the httpd.conf, it is showing up in my vps control panel (under the security script) that it isn't installed.
Is there some way that I can test to see if it is actually installed or not?
Anyone here have problem with Mod_Security and VBulletin ? Currently running Apache 1.3.x and Vbulletin 3.6.8 patch 2 and want to install Mod_Security on Apache so I want to know if there any conflict with Mod_Security and Vbulletin.
trying to get mod_security installed on my HSphere server, the install goes ok until i try and load rules?
If i just load the exclude.conf rule then php sites work, if i also load rules.conf or any other rules then my php sites get 'connection refused error' ?
I cannot find any thing in logs and there is no log written for mod_security?
here is my modsecurity.conf
Quote:
#If you want to scan the output, uncomment these #SecFilterScanOutput On #SecFilterOutputMimeTypes "(null) text/html text/plain"
# Accept almost all byte values SecFilterForceByteRange 1 255
# Server masking is optional #fake server banner - NOYB used - no one needs to know what we are using SecServerSignature "NOYB"
#SecUploadDir /tmp #SecUploadKeepFiles Off
# Only record the interesting stuff SecAuditEngine RelevantOnly SecAuditLog /var/log/audit_log
# You normally won't need debug logging SecFilterDebugLevel 0 SecFilterDebugLog logs/modsec_debug_log
#And now, the rules #Remove any of these Include lines you do not use or have rules for.
#First, add in your exclusion rules: #These MUST come first! Include /etc/modsecurity/exclude.conf
# Only inspect dynamic requests # (YOU MUST TEST TO MAKE SURE IT WORKS AS EXPECTED) #SecFilterEngine DynamicOnly
SecFilterEngine On
# Reject requests with status 500 SecFilterDefaultAction "deny,log,status:500"
# Some sane defaults SecFilterScanPOST On SecFilterCheckURLEncoding On SecFilterCheckCookieFormat On SecFilterCheckUnicodeEncoding Off SecFilterNormalizeCookies On # enable version 1 (RFC 2965) cookies SecFilterCookieFormat 1
SecServerResponseToken Off
#If you want to scan the output, uncomment these #SecFilterScanOutput On #SecFilterOutputMimeTypes "(null) text/html text/plain"
# Accept almost all byte values SecFilterForceByteRange 1 255
# Server masking is optional #fake server banner - NOYB used - no one needs to know what we are using SecServerSignature "NOYB"
#SecUploadDir /tmp #SecUploadKeepFiles Off
# Only record the interesting stuff SecAuditEngine RelevantOnly SecAuditLog /var/log/audit_log
# You normally won't need debug logging SecFilterDebugLevel 0 SecFilterDebugLog logs/modsec_debug_log
#And now, the rules #Remove any of these Include lines you do not use or have rules for.
#First, add in your exclusion rules: #These MUST come first! Include /etc/modsecurity/exclude.conf
if anyone with Mod_Security knowledge could write up a rule for *@mail.ru.
Anyone running a forum knows that a ton of spam accounts come from somebody@mail.ru (which most of the times bounces).
Also, does anyone know if there is a large number of people who use mail.ru addresses for legitimate purposes? Would blocking mail.ru be like blocking hotmail.com (which obviously I wouldn't do)