Mod_sec problems with wordpress

nowhere

Member
Sep 21, 2012
14
0
1
cPanel Access Level
Root Administrator
Hi,
is anybody having problems with some defaults ruleset (especially 1234123404 and 1234123440) and wordpress?
Actually all Wordpress installation on my server can no more update a post.
Looking in log I've found stuff like this:
[Sun Mar 31 16:39:02 2013] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 406 (phase 2). Pattern match "(?:\\\\b(?:(?:type\\\\b\\\\W*?\\\\b(?:text\\\\b\\\\W*?\\\\b(?:j(?:ava)?|ecma|vb)|application\\\\b\\\\W*?\\\\bx-(?:java|vb))script|c(?:eek:pyparentfolder|reatetextrange)|get(?:special|parent)folder|iframe\\\\b.{0,100}?\\\\bsrc)\\\\b|on(?:(?:mo(?:use(?:eek:(?:ver|ut)|down|move|up)|ve)| ..." at ARGS:content. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "117"] [id "1234123404"] [msg "Cross-site Scripting (XSS) Attack"] [data "src=\\x22http:"] [severity "CRITICAL"] [tag "WEB_ATTACK/XSS"] [hostname "www.domainname.ext"] [uri "/wp-admin/post.php"]
Of course disabling rule 1234123404 it's possible to update a post.
Is anybody facing the same situation?

Thanks
Cotus
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
Basically it's seeing something like script followed by http:// in your POST data.

I'd add this to your modsec2.user.conf, or a whitelist file if one is called as an includes from modsec2.user.conf

<LocationMatch "/wp-admin/post.php">
SecRuleRemoveByID 1234123404 1234123440
</LocationMatch>

This will whitelist those rule IDs for that file only.
 

nowhere

Member
Sep 21, 2012
14
0
1
cPanel Access Level
Root Administrator
Hi,
thanks to all.
Actually I've disabled ruleset 1234123404 and 1234123440 in global server via ConfigServer ModSecurity Control and it is possible again to post/edit post into admin area of wordpress and joomla installations.

Who does maintains and updates these ruleset? cPanel?
How can i know if these rulesets are updated so we don't need to disable them in order to work with Wordpress?

Regards
Cotus
 

ThinIce

Well-Known Member
Apr 27, 2006
352
9
168
Disillusioned in England
cPanel Access Level
Root Administrator
I do remember it being said a while back by a staff member that the default rules should not interfere with the day to day operations of the most popular scripts.

If this is indeed the case, should such instances be filed as bugs when encountered?
 

eurorocco

Well-Known Member
Jun 23, 2003
99
0
156
I'm using the default modsecurity (mod_security) ruleset and it's nasty for Wordpress and Drupal. Cpanel not suitable for PHP applications? Customers are quite unhappy about it. I'm looking for a ready made ruleset friendly to these apps, but cannot find. Help! Can someone point me to best ruleset conf files? Or is mod_security to be disabled altogether? THANKS! ER
 
Last edited:

Infopro

Well-Known Member
May 20, 2003
17,113
507
613
Pennsylvania
cPanel Access Level
Root Administrator
Twitter
I'm using the default modsecurity (mod_security) ruleset and it's nasty for Wordpress and Drupal. Cpanel not suitable for PHP applications? Customers are quite unhappy about it. I'm looking for a ready made ruleset friendly to these apps, but cannot find. Help! Can someone point me to best ruleset conf files? Or is mod_security to be disabled altogether? THANKS! ER
Can you list a few of the rules you're having issues with, from your logs? I'm just curious which you're having problems with.
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
Don't disable modsec entirely. Your customers will be even more upsed when their stuff is hacked all the time.

the gotroot (atomicorp) rules are very well tuned to avoid most false positives. I highly recommend them as opposed to the normal OWASP / core rule set. The OWASP/core rule set is good if you're experienced in configuring ModSecurity, but if you're not, atomicorp's rules are probably better for you.

https://www3.atomicorp.com/channels/rules/delayed/
 

nowhere

Member
Sep 21, 2012
14
0
1
cPanel Access Level
Root Administrator
Can you list a few of the rules you're having issues with, from your logs? I'm just curious which you're having problems with.
This is an example with relative logs:

RULE 1234123415 (just happened today)
Code:
Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:send[2208]. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "92"] [id "1234123415"] [msg "SQL Injection Attack"] [data "insert into"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"]
[26/Jun/2013:14:21:39 +0200] Ucrc00JHtpIAAGEPI6kAAAAL 151.42.228.136 7224 66.71.183.12 80
--f0d4b121-B--
POST /wp-admin/media-upload.php?type=image&tab=type&post_id=2168 HTTP/1.1
Host: domain.it
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: domain.com.it/wp-admin/media-upload.php?post_id=2168&
Cookie: wordpress_cea28b29f36e017f280ff8073e6f84bb=admin%7C1372411442%7Ce530ad641df0d71f8a035ca1711f1300; __utma=115865375.1080318674.1333129564.1372177205.1372237335.335; __utmz=115865375.1369395694.309.25.utmcsr=pino.ceniccola.it|utmccn=(referral)|utmcmd=referral|utmcct=/; wp-settings-1=hidetb%3D1%26editor%3Dtinymce%26urlbutton%3Dnone%26align%3Dnone%26imgsize%3Dfull%26mfold%3Do; wp-settings-time-1=1372239512; PHPSESSID=084df0d375968bef61ac87bea5b8ca64; __utmc=115865375; wordpress_test_cookie=WP+Cookie+check; wp-settings-time-3=1372238062; wp-settings-3=urlbutton%3Dnone%26uploader%3D1%26editor%3Dhtml; wordpress_logged_in_cea28b29f36e017f280ff8073e6f84bb=admin%7C1372411442%7C9b925128a544ceb99081cb6c459419cd
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------175071955824836
Content-Length: 1652

--f0d4b121-I--
post%5fid=2168&%5fwpnonce=ce6d05648c&%5fwp%5fhttp%5freferer=%2fwp%2dadmin%2fmedia%2dupload%2ephp%3fpost%5fid%3d2168%26&attachments%5b2208%5d%5bmenu%5forder%5d=0&attachments%5b2208%5d%5bpost%5ftitle%5d=dettagli%5ftest&attachments%5b2208%5d%5bimage%5falt%5d=&attachments%5b2208%5d%5bpost%5fexcerpt%5d=&attachments%5b2208%5d%5bpost%5fcontent%5d=&attachments%5b2208%5d%5burl%5d=&attachments%5b2208%5d%5balign%5d=none&attachments%5b2208%5d%5bimage%2dsize%5d=full&send%5b2208%5d=Insert+into+Post
--f0d4b121-F--
HTTP/1.1 404 Not Found
X-Powered-By: PHP/5.3.23
X-Pingback: domain.it/xmlrpc.php
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Last-Modified: Wed, 26 Jun 2013 12:21:39 GMT
Cache-Control: public
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

--f0d4b121-H--
Message: Access denied with code 406 (phase 2). Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:send[2208]. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "92"] [id "1234123415"] [msg "SQL Injection Attack"] [data "insert into"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"]
Action: Intercepted (phase 2)
Stopwatch: 1372249299048753 422966 (- - -)
Stopwatch2: 1372249299048753 422966; combined=1010, p1=148, p2=850, p3=0, p4=0, p5=12, sr=0, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.7.2 (/http://www.modsecurity.org/).
Server: Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips mod_bwlimited/1.4 mod_perl/2.0.6 Perl/v5.10.1
Engine-Mode: "ENABLED"
RULE 1234123404 disabled globally since some months
RULE 1234123440 disabled globally since some months
Actually I don't have easy logs to find for them as they're off since some months
 

nowhere

Member
Sep 21, 2012
14
0
1
cPanel Access Level
Root Administrator
FYI
today after a lot of problems I've disabled globally also "RULE 1234123435"

Maybe I should remove all default rules as I'm already using delayed "gotroot" .
Bad side about gotroot is that I had to remove some rules after installation as they are only for registered users so now I'm always worried when I have to update delayed gotroot rules
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
If you're using the "gotroot" rules, you should disable the "default" rules entirely. The atomicorp (gotroot) rules are much less likely to cause false positives.
 

eurorocco

Well-Known Member
Jun 23, 2003
99
0
156
I´m using the default rules. I go into WHM, mod_security, edit config, click Default. But right now I have one group of customers getting blocked. They´re using Wordpress, probably using áéíóúÁÉÍÓÚñÑ characters. I the Atomic gotroot delayed okay for the Cpanel webserver? Do they happily coexist? Perhaps a one rules file to paste into the WHM? THANKS A LOT!
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
It is usually best to run the Gotroot (atomic) rules instead of the default rules.

I have gotten both to work at the same time, but I did disable a handfull of the default rules which caused problems with wordpress.
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
I honestly don't remember off of the top of my head. I know one had to do with sequential non-alpha characters. Just tail -f your apache error log while trying to post, and it'll tell you the rule ID that's stopping you. Comment out the line(s) for that rule, or make a location match exemption.

This is really easy if you have your IP handy. If you're posting from 123.123.123.123 just log into a root SSH terminal and run this:

Code:
tail -f /usr/local/apache/logs/error_log | grep 123.123.123.123
Then in your browser try the post. When it fails, go back to your terminal and it'll tell you the rule ID causing you problems.

Assuming you're handy with grep / vim, you should be able to handle the rest from there. Be sure to restart apache after modifying or excluding any rules before re-trying your post.

If you need more help let me know.