ModSecurity Auto Updater

[Secmas]

Hi

this sounds a wield question, but we do not have those folder to be 770, but no errors like one mentioned above?

we just mkdir those folders and that is it...

If you are using GotRoot rules without modifying the MODSEC2.USER.CONF as I said in my page, then the 770 has to be used in order for the rules to save the info that the rules are generating, that is why (ikillbill) you don't need to chmod that directories, as you have modsec2.user.con as in my web site. So, you are ok with that.

Sergio

 

[Secmas]

It's maybe due to that you are still using old verson of MOD_SECURITY.
Recompile with latest easyapache build and let see.

9xlinux,
no, that is not the case.

It is because you have your GotRoot rules installation to use that directories in order for them to work. Check in your modsec2.user.conf if you are using the following commands:

SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogType Concurrent

If you are, then you need to REM them out or delete that lines from your modsec2.user.conf

The problem using that two lines is that all the rules activities are written in that directories but you will never see them again in your WHM MODSECURITY GUI nor CSF will work blocking them. On the other hand, your /var directory will fill up very quickly as this directories will be saving a lot of data in there.

That directories are only used for people that has installed the ASL Hardening service and it is not for cpanel.

Sergio

 

[kris1351]

Your script is forcing you to run from /tmp which is fine, but there is a major issue with it. When it cleans up the files that are unpacked you are using the rm -rf /tmp it looks like which wipes EVERYTHING out of the /tmp.

 

[Secmas]

Your script is forcing you to run from /tmp which is fine, but there is a major issue with it. When it cleans up the files that are unpacked you are using the rm -rf /tmp it looks like which wipes EVERYTHING out of the /tmp.

If you look closely I don't use "-rf" as you said, I only use "-f" so, it will not wipe all the TMP directory. Also, I have declared what to delete, again, please look at the script and it says:

echo "Cleaning up"
rm -f $RULEFILE
rm -f /tmp/apachechk

meaning that only will be deleting one (1) file.

Sergio

 

[Secmas]

May 16/2010, read in this post:


1. NEW PUNTAPIRATA-BADOMAINS.TXT
2. NEW VALUES FOR PCRE COMMANDS IN MODSEC2.USER.CONF


1. New domains added:
I have uploaded the new Puntapirata-Badomains.txt, with more than 3,500 spam domains used in blogs, forums, forms, etc. This last week the activity in my servers blocking spam was more than the normal thing, how was yours?


2. New values for PCRE commands:
If you have installed the new ver 2.5.12 in your servers and used the new two commands for PCRE recursion, you will need to modify the values, Brian Rectanus from Breach and Owasp, gave me a nice lesson on why I need to lower that values, here is an excerpt of what he is suggesting:

"For example, using a simple aaaaaaaaaaaaaaaaaab style pattern in a parameter payload repeated 50 times makes a request go from .1 seconds to 5.5 seconds with a bad regex and 150,000 limit set. Making the pattern repeat 100 times yields 22.4 seconds to process it! During this time the Apache process is using 100% of one CPU core. This is on a 2.6Ghz dual core box w/4g RAM..."


He also recommended to read the following information:
Regular expression Denial of Service - ReDoS - OWASP

So, the new values that I am testing now are as follows:

SecPcreMatchLimit 50000
SecPcreMatchLimitRecursion 5000

With this settings I am getting just a few PCRE errors now, but I feel comfortable with that after reading Brian suggestions.

If you had my initial values, I recommend to change them as soon as possible.

Best Regards,

Sergio

 

[rligg]

Did you run the script a few times?

This is what I did:
1. Run the script until it uploaded all the modules that perl needs.
2. I modified PHP.INI and added the two command lines as I wrote before and each one with a number of 10,000,000 if you fail to add this lines PCRE will continue with the error.
3. Then I modified MODSEC2.USER.CONF to add the other two lines
4. Restarted APACHE and everything was working again.

You will see a lot of PCRE errors in your WHM ModSecurity GUI but don't worry, they will dissapear.

Regards,

Sergio

I have followed this but I still get the error for a particular site. I made sure they have no custom php.ini. I'm baffled.
Is placement in the php.ini and mdsec user conf important?

When I run the following, it seems the ruleset is right:

PCRE version 8.02 2010-03-19
Compiled with
UTF-8 support
Unicode properties support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

Yet I still get: ModSecurity: Rule execution error - PCRE limits exceeded (-8)

I have updated the per modules like 7 times.

 

[Secmas]

I have followed this but I still get the error for a particular site. I made sure they have no custom php.ini. I'm baffled.
Is placement in the php.ini and mdsec user conf important?

When I run the following, it seems the ruleset is right:

PCRE version 8.02 2010-03-19
Compiled with
UTF-8 support
Unicode properties support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

Yet I still get: ModSecurity: Rule execution error - PCRE limits exceeded (-8)

I have updated the per modules like 7 times.

Hello Rligg,
would you mind to share with us what is the IP that is triggering this rule?

I have seen that some CRAWLS from Google or any other searcher triggers this error, but is because the way they try to spider your site.

Also, it will be good to see what values have you set in your modsec2.user.conf file for PCRE.

Regards,

Sergio

 

[rligg]

user.conf pcre contents:

SecPcreMatchLimit 50000
SecPcreMatchLimitRecursion 5000


#Generic attack rules pcre format
#cross site scripting attempt IMG onerror or onload
SecRule REQUEST_URI "\<IMG.*/\bonerror\b[\s]*="


The error happens when any ip hits a specific link.

 

[Secmas]

user.conf pcre contents:

SecPcreMatchLimit 50000
SecPcreMatchLimitRecursion 5000


#Generic attack rules pcre format
#cross site scripting attempt IMG onerror or onload
SecRule REQUEST_URI "\<IMG.*/\bonerror\b[\s]*="


The error happens when any ip hits a specific link.

How is your php.ini? Do you have the following two lines in it?

pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000

I have added this two lines at the end of my PHP.INI, just check if you have it.

 

[rligg]

Yes I have those two lines in my php.ini

 

[Secmas]

Yes I have those two lines in my php.ini

Well, in that case I will suggest to test what value could be used in your MODSEC2.USER.CONF file command:
SecPcreMatchLimitRecursion 5000

I really don't like the idea to increase the values as I mentioned in a prior post, due to this article:
Regular expression Denial of Service - ReDoS - OWASP

OTOH, it will be a good idea to check why that specific site is triggering the PCRE error and fix it from the source.

Sergio

 

[rligg]

Well, in that case I will suggest to test what value could be used in your MODSEC2.USER.CONF file command:
SecPcreMatchLimitRecursion 5000

I really don't like the idea to increase the values as I mentioned in a prior post, due to this article:
Regular expression Denial of Service - ReDoS - OWASP

OTOH, it will be a good idea to check why that specific site is triggering the PCRE error and fix it from the source.

Sergio

Well that is very hard to do. pcre effects many blog type sites where articles are posted via php.

PCRE limits exceeded (-8)
What does the (-8) represent here?

 

[Secmas]

Well that is very hard to do. pcre effects many blog type sites where articles are posted via php.

So, set the values on both commands in MODSEC2.USER.CONF to use 50,000 and check what happens.

 

[Secmas]

July 19/2010, read in this post:

1. NEW PUNTAPIRATA-BADBOTS RULE.
2. ATTACKS FROM THE LAST WEEKS.
3. PUNTAPIRATA-BADOMAINS.TXT FILE UPDATED.

1. New section added:
In PuntaPirata.com we have added a new section called "ModSec Rules", we will like to share rules that you can add into your own modsecurity rules. The first rule that we have added is one to block bad bots or crawlers. We have seen that a lot of people uses .HTACESS to block this type or attacks but using .HTACESS will only block this for one site only, while the rule that we have wrote can do that on a server wide basis, this includes a file that you can update yourself to include your own bad bots or strings that are found on the User-Agent.

If you have any rule that you want to share, please let me know.

2. Attacks from the last weeks:
A few days ago, we saw an attack to the AWSTAT.PL file. ModSecurity took rid of them but is interesting to see that an oldie is live again.

3. PuntaPirata-Badomains.txt update:
Since our last update, we have collected more than 6,500 domains that spammers are trying to write in any kind of post or forms, the update is already in our site.

Regards,

Sergio

 

[lorio]

./updaterules.sh: line 82: cd: /usr/local/apache/conf/modsec_rules/modsec: No such file or directory

This was mentioned before. The poster didn't stated what he changed that the script run outofthebox again.

Might be just a problem with tar and extracting.
When using CENTOS 5.5 i686 and tar (GNU tar) 1.15.1 the extracting
isn't creating the missing subdirectory modsec inside modsec_rules.

1.The script backups the old modsec_rules directory.
2.Creates a new modsec_rules directory.
3.Unpacks the rules archive from tmp to the modsec_rules directory.
4. The script tries to cd /usr/local/apache/conf/modsec_rules/modsec

The subdirectory modsec is not there because it wasn't created.

The files offered at http://downloads.prometheus-group.com/delayed/rules/
are not packed with a subdirectory modsec.

Would be nice if someone could comment if that is only the case with the delayed rules.

 

[Secmas]

This was mentioned before. The poster didn't stated what he changed that the script run outofthebox again.

Might be just a problem with tar and extracting.
When using CENTOS 5.5 i686 and tar (GNU tar) 1.15.1 the extracting
isn't creating the missing subdirectory modsec inside modsec_rules.

1.The script backups the old modsec_rules directory.
2.Creates a new modsec_rules directory.
3.Unpacks the rules archive from tmp to the modsec_rules directory.
4. The script tries to cd /usr/local/apache/conf/modsec_rules/modsec

The subdirectory modsec is not there because it wasn't created.

The files offered at http://downloads.prometheus-group.com/delayed/rules/
are not packed with a subdirectory modsec.

Would be nice if someone could comment if that is only the case with the delayed rules.

Hello Lorio,
thanks for letting me know about this issue with my script, a fix will be available shortly.

I have been using my script with the payed subscription and it does include the modsec directory.

Regards,

Sergio

 

[Secmas]

@ Lorio,
a new UPDATER script has been uploaded, it checks if the directory "modsec" is created or not and acts accordingly.

Please download the new ver. 1.04 and let me know your toughts.

Regards,

Sergio

 

[lorio]

@Please download the new ver. 1.04 and let me know your toughts.

Sorry for answering late. Looks fine. Except for choosen name of the dirpath var ;-) Think this will save you some questions about why it isn't working.
Thanks for improving the script.

 

[Secmas]

Sorry for answering late. Looks fine. Except for choosen name of the dirpath var ;-) Think this will save you some questions about why it isn't working.
Thanks for improving the script.

I really appreciate your input and that is why the var name

Regards,

Sergio

 

[GaryT]

I'm quite confused on this, I do wish to try, Now I have already installed mod_security via easy apache, Now how do you update the rules ? I don't quite follow it properly.

Is there just one cmd to run via ssh or..... ?


Thanks