The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Mod_sec problems with wordpress

Discussion in 'Security' started by nowhere, Apr 2, 2013.

  1. nowhere

    nowhere Member

    Joined:
    Sep 21, 2012
    Messages:
    14
    Likes Received:
    0
    Trophy Points:
    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:
    Of course disabling rule 1234123404 it's possible to update a post.
    Is anybody facing the same situation?

    Thanks
    Cotus
     
  2. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,446
    Likes Received:
    195
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Not seeing that here. I assume by this part of the error: "/wp-admin/post.php" that you're posting via the QuickPress section of admin area? If not, please provide steps and I'll try to duplicate.
     
  3. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    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.
     
  4. A.Djamel

    A.Djamel Registered

    Joined:
    Mar 25, 2013
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    Hi,

    yes ruleset (1234123404 and 1234123440) block wordpress and joomla post in admin area, you can just use ConfigServer ModSecurity Control to disabel these rules per domain or in global server.

    Best Regards.
     
  5. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    cPanel Access Level:
    DataCenter Provider
    +1 for configserver modsec control plugin.
     
  6. nowhere

    nowhere Member

    Joined:
    Sep 21, 2012
    Messages:
    14
    Likes Received:
    0
    Trophy Points:
    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
     
  7. ThinIce

    ThinIce Well-Known Member

    Joined:
    Apr 27, 2006
    Messages:
    346
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    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?
     
  8. eurorocco

    eurorocco Well-Known Member

    Joined:
    Jun 23, 2003
    Messages:
    99
    Likes Received:
    0
    Trophy Points:
    6
    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
     
    #8 eurorocco, May 6, 2013
    Last edited: May 6, 2013
  9. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,446
    Likes Received:
    195
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    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.
     
  10. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    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/
     
  11. nowhere

    nowhere Member

    Joined:
    Sep 21, 2012
    Messages:
    14
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    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
     
  12. nowhere

    nowhere Member

    Joined:
    Sep 21, 2012
    Messages:
    14
    Likes Received:
    0
    Trophy Points:
    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
     
  13. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    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.
     
  14. eurorocco

    eurorocco Well-Known Member

    Joined:
    Jun 23, 2003
    Messages:
    99
    Likes Received:
    0
    Trophy Points:
    6
    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!
     
  15. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    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.
     
  16. MojoCreations

    MojoCreations Active Member

    Joined:
    Feb 14, 2012
    Messages:
    28
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    QuizKnows...which rules did you disable? I am having the same issue with Wordpress and ModSec, i can't save posts/pages or update plugins
     
  17. quizknows

    quizknows Well-Known Member

    Joined:
    Oct 20, 2009
    Messages:
    940
    Likes Received:
    55
    Trophy Points:
    28
    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.
     
Loading...

Share This Page