Skip to main content

wp-login.php and mod security

Comments

45 comments

  • cPanelMichael
    Hello :) You may find this thread helpful: Deny Brute Force WP Login Thank you.
    0
  • quizknows
    Those rules rely entirely on rate limiting and are not very good in my opinion. They are also unnecessarily using two collections instead of one. Here are the current wp-login rules I'm using: #Block WP logins with no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000130,chain,msg:'wp-login request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" #Wordpress Brute Force detection SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134 # Setup brute force detection. # React if block flag has been set. SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'" # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed. SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137" SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
    0
  • cosmin
    Hello! I put this in /usr/local/apache/conf/modsec2.user.conf before last line (Include /usr/local/apache/conf/modsec2.whitelist.conf) but no effect. Any ideea please? In last 2 days we are under continuu attack with /wp-login.php Many thanks!
    0
  • quizknows
    Are you getting any ModSecurity messages in your apache error_log at all? Are you sure that ModSecurity is actually compiled in under EasyApache? (it is possible to have the config files but no module to use them). Also make sure your main directives are set in modsec2.user.conf such as: SecUploadDir /tmp SecTmpDir /tmp SecDataDir /tmp SecRequestBodyAccess On
    And last but not least, you must restart Apache after editing any modsecurity configs, or the changes will not take effect until the next restart of the service.
    0
  • cosmin
    Yes, I have many messages in error_log about modsecurity. I put your lines with /tmp in modsec2.user.conf but no effect.... [COLOR="silver">- - - Updated - - - Nobody say is necesarry to enable "cPHulk Brute Force Protection" from WHM. Now is working :D cPHulk Brute Force Protection cand run in the same time with csf? Not any problem/conflict? Thanks!
    0
  • JaredR.
    There will be a conflict if you enable both cPHulk and the LFD component of CSF. cPHulk and LFD do the same thing and enabling them both at the same time will eventually cause a conflict.
    0
  • quizknows
    [quote="cosmin, post: 1740891">Yes, I have many messages in error_log about modsecurity. I put your lines with /tmp in modsec2.user.conf but no effect.... [COLOR="silver">- - - Updated - - - Nobody say is necesarry to enable "cPHulk Brute Force Protection" from WHM. Now is working :D cPHulk Brute Force Protection cand run in the same time with csf? Not any problem/conflict? Thanks!
    cphulk should be completely irrelevant here, sounds like you got the modsec config straightened out though. [quote="cPanelJared, post: 1740901">There will be a conflict if you enable both cPHulk and the LFD component of CSF. cPHulk and LFD do the same thing and enabling them both at the same time will eventually cause a conflict.
    What conflict are you talking about? They work fundamentally differently, and while it's not necessary to have both, they don't really conflict. I've never seen an issue where having both cPHulk and CSF/LFD running caused any actual problems, this being over 4-5 years on literally thousands of servers. cPHulk will lock out usernames, where as LFD/CSF actually will block IPs in the servers firewall (iptables). Typically I recommend CSF over cphulk, since CSF won't lock you out of root on your own server during a brute force (and yes, I know about the IP whitelist).
    0
  • qwerty
    Does anyone know how to correctly modify these rules to 1) block after 5 unsuccessful attempts instead of 10 2) make it a PERM block not a temporary 5 minute block
    0
  • quizknows
    [quote="qwerty, post: 1745101">Does anyone know how to correctly modify these rules to 1) block after 5 unsuccessful attempts instead of 10 2) make it a PERM block not a temporary 5 minute block
    For the first part: SecRule ip:bf_counter "@gt 10" Change that to @gt 5 (or whatever number) For the 2nd part (block time), this is what sets the 5 minutes: expirevar:ip.bf_block=300 You could raise the number (300s = 5 mins), or probably omit that to just not expire it. However, what I do is just use LF_MODSEC in csf. If they keep trying during that 5 minute window, CSF will block their IP in iptables for you which is better anyway.
    0
  • sahostking
    [quote="quizknows, post: 1739931">Those rules rely entirely on rate limiting and are not very good in my opinion. They are also unnecessarily using two collections instead of one. Here are the current wp-login rules I'm using: #Block WP logins with no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000130,chain,msg:'wp-login request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" #Wordpress Brute Force detection SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134 # Setup brute force detection. # React if block flag has been set. SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'" # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed. SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137" SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"

    Awesome. Just placed this in userdata custom ruleset and it worked instantly. Blocked rules based on this id. Thanks.
    0
  • abdelhost77
    [quote="sahostking, post: 1749261">Awesome. Just placed this in userdata custom ruleset and it worked instantly. Blocked rules based on this id. Thanks.
    It works also for me thanks :) i would like to use the same rule to protect against xmlprc.php attaks, is that possible, what should i modify except filename and rule ID ?
    0
  • quizknows
    You can adapt one of these rules for XMLRPC as follows: #Block XMLRPC no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:4784627,chain,msg:'xmlrpc request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" "chain" SecRule REQUEST_URI "xmlrpc.php"
    This may interfere with some normal uses of xmlrpc but I have not had any complaints. If a customer wants to POST legitimate data to xmlrpc.php they just need to specify something (anything) as a referer in their HTTP headers.
    0
  • abdelhost77
    [quote="quizknows, post: 1760092">You can adapt one of these rules for XMLRPC as follows: #Block XMLRPC no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:4784627,chain,msg:'xmlrpc request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" "chain" SecRule REQUEST_URI "xmlrpc.php"
    This may interfere with some normal uses of xmlrpc but I have not had any complaints. If a customer wants to POST legitimate data to xmlrpc.php they just need to specify something (anything) as a referer in their HTTP headers.
    Please find what i put in mine : #Block xmlrpc with no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000140,chain,msg:'xmlrpc request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" #Wordpress Brute Force detection SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000144 # Setup brute force detection. # React if block flag has been set. SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000145,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'" # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed. SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000146" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000147" SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
    Do you think it is OK ?
    0
  • quizknows
    The first rule will work OK. The reason I used the REQUEST_URI instead of LocationMatch for it is in case someone needs the rule whitelisted it is easier. A locationmatch whitelist won't work right if the rule itself is already in a locationmatch section. Your first rule, and the one you quoted that I posted, will do exactly the same thing. The second one will work, but for the wrong reasons. xmlrpc does not 302 for successful requests like wp-login does. Basically what that 2nd rule would end up doing is simply rate limiting the number of calls that can be made to xmlrpc that result in normal 200 OK returns. If any IP hits an xmlrpc file more than 10 times in 3 minutes it will be blocked from xmlrpc files, regardless of any other attributes of the request. The RESPONSE_STATUS "^302" line is probably not needed at all. Honestly, it's probably not a bad rule to try out.
    0
  • Hedloff
    Does anyone have a working Joomla Brute Force rule? Have tried some before, but I always end up removing it because they cause problems with other extensions/modules inside Joomla.
    0
  • abdelhost77
    ++1 Im also searching for mode sec rules blocking JOOMLA attacks such as : POST /administrator/index.php HTTP/1.0 GET /administrator/index.php HTTP/1.0
    0
  • abdelhost77
    I found this in : [url=http://www.webhostingtalk.com/showthread.php?t=1394692]Using MoSec for Joomla and WP Brute force - Hosting Security and Technology - Web Hosting Talk and it works for me . # Block Joomla scans that are looking for sites to target; frequently they lack both UA and Referer fields SecRule REQUEST_URI "/administrator/index.php" "deny,status:411,id:5000223,chain,msg:'Joomla admin access blocked due to No UA and No referer'" SecRule &HTTP_REFERER "@eq 0" "chain" SecRule &HTTP_User-Agent "@eq 0"
    0
  • quizknows
    [quote="abdelhost77, post: 1777352">I found this in : [url=http://www.webhostingtalk.com/showthread.php?t=1394692]Using MoSec for Joomla and WP Brute force - Hosting Security and Technology - Web Hosting Talk and it works for me . # Block Joomla scans that are looking for sites to target; frequently they lack both UA and Referer fields SecRule REQUEST_URI "/administrator/index.php" "deny,status:411,id:5000223,chain,msg:'Joomla admin access blocked due to No UA and No referer'" SecRule &HTTP_REFERER "@eq 0" "chain" SecRule &HTTP_User-Agent "@eq 0"
    That's my rule :) I can confirm it does stop a fair amount of abusive traffic. This one can help too: # Block Joomla logins with no referring URL SecRule REQUEST_URI "/administrator/index.php" "deny,status:411,id:5000224,chain,msg:'Joomla login request blocked, no referer'" SecRule REQUEST_METHOD "POST" "chain" SecRule &HTTP_REFERER "@eq 0"
    0
  • JacobHansen
    Those rules rely entirely on rate limiting and are not very good in my opinion. They are also unnecessarily using two collections instead of one. Here are the current wp-login rules I'm using: #Block WP logins with no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000130,chain,msg:'wp-login request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" #Wordpress Brute Force detection SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134 # Setup brute force detection. # React if block flag has been set. SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'" # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed. SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137" SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"

    I've attempted adding these to the file: /usr/local/apache/conf/modsec2.user.conf however I am not seeing any effect. I have some earlier logs from mod_security from earlier this morning, however there is an ongoing bruteforce attack going, and adding this rule has had no effect. I have restarted the webserver (running Litespeed). I have confirmed the there is a huge number of login attempts on the same site from the same IP address. The rules show up (although not as one but several) in the ModSecurity Tools rules list. I use CSF and cpHulk is disabled. Any idea why this is not working as intended?
    0
  • quizknows
    I've attempted adding these to the file: /usr/local/apache/conf/modsec2.user.conf however I am not seeing any effect. I have some earlier logs from mod_security from earlier this morning, however there is an ongoing bruteforce attack going, and adding this rule has had no effect. I have restarted the webserver (running Litespeed). I have confirmed the there is a huge number of login attempts on the same site from the same IP address. The rules show up (although not as one but several) in the ModSecurity Tools rules list. I use CSF and cpHulk is disabled. Any idea why this is not working as intended?

    It is possible/probable the attackers are using a referring URL. If you can post some of the domlogs (you can remove identifying domains or IPs) I can take a look. Logins with no referrer should be blocked by the first rule, the 2nd rule will only work if certain IPs are hitting the server repeatedly. It's also worth noting that litespeed has its own engine for processing modsecurity rules which is not always 100% functional. Unfortunately, the documentation on litespeed's implementation of ModSecurity is non-existent last I checked.
    0
  • JacobHansen
    It is possible/probable the attackers are using a referring URL. If you can post some of the domlogs (you can remove identifying domains or IPs) I can take a look. Logins with no referrer should be blocked by the first rule, the 2nd rule will only work if certain IPs are hitting the server repeatedly. It's also worth noting that litespeed has its own engine for processing modsecurity rules which is not always 100% functional. Unfortunately, the documentation on litespeed's implementation of ModSecurity is non-existent last I checked.

    I did not note which sites were being attacked at the time, and the attack seem to have stopped now. So I do not really have the logs. However I stopped it by blocking a few IPs that were repeatedly hitting the server. After blocking these 2-3 IPs in CSF the load of the server dropped from 2.5 to 0.5. I thought the point of the modsecurity rule quoted in my original thread was the block IPs that repeatedly failed to login, so it should work well in this case. Update: I think it may have been a Litespeed issue (updated now), or possibly a conflicting mod_security rule on the server i Originally tried it on. It works correctly on two other servers I have deployed it to at least. Thanks for the help and posting the rule in the first place, it seems to work well!
    0
  • quizknows
    Yes, one of the rules is there for blocking repeat logins from one IP. The code I provided had that in addition to another rule that drops invalid logins (ones that lack referring URLs), so I was talking about that one too. Glad they're helping :)
    0
  • rregister
    I'm having a bit of trouble with this and would appreciate any help you have to offer, though I'm using apache 2.4 and not litespeed. My understanding is that it should work the same...apologies if that is incorrect. Here's what I'm using currently. The first rule, which blocks logins with no referer, works perfectly and I can find it in the apache error_log file. The problem is that the other rule to limit login attempts never seems to process. I've tested it using another IP address that is not whitelisted in CSF (my main IP is) and nothing ever happens. The third rule just does the same thing and is based on the second rule, but applies to xmlrpc.php instead of wp-login.php SecUploadDir /tmp SecTmpDir /tmp SecDataDir /tmp SecRequestBodyAccess On #Block WP logins with no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000130,chain,msg:'wp-login request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" #Wordpress Brute Force detection SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134 SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'" SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137" SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0" #XMLRPC Protection SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000234 SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000235,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000237" SecRule ip:bf_counter "@gt 5" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
    thank you for your time!
    0
  • quizknows
    3 things: You should only need to initialize the collection once (initcol). Try commenting out the 2nd instance of SecAction phase:1,nolog,pass,initcol{snip}, restart apache, and see if that helps. Otherwise (this is just guessing) the 2 rules using both user and ip may conflict a bit. I'd have to check the rule logic on the xmlrpc one. If it doesn't work right after the first advice above, try commenting out the whole xmlrpc block of code and making sure that at least the wp-login stuff works. Last but not least your wp-login block of code is using 2 collections (ip and user) and actually only needs one (ip). Check the revised version I posted on the last page.
    0
  • rregister
    things: You should only need to initialize the collection once (initcol). Try commenting out the 2nd instance of SecAction phase:1,nolog,pass,initcol{snip}, restart apache, and see if that helps. Otherwise (this is just guessing) the 2 rules using both user and ip may conflict a bit. I'd have to check the rule logic on the xmlrpc one. If it doesn't work right after the first advice above, try commenting out the whole xmlrpc block of code and making sure that at least the wp-login stuff works. Last but not least your wp-login block of code is using 2 collections (ip and user) and actually only needs one (ip). Check the revised version I posted on the last page.

    thank you for your suggestions! I've updated my code as follows (and saw your advice on the xmlrpc on the previous page). I still can't get it to lock me out after 10 attempts though. The other 2 blocks are working perfectly. This particular server is using mod_ruid2...could that be a problem? Thanks again. #Block WP logins with no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000130,chain,msg:'wp-login request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" #Block XMLRPC no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:4784627,chain,msg:'xmlrpc request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" "chain" SecRule REQUEST_URI "xmlrpc.php" #Wordpress Brute Force detection SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134 # Setup brute force detection. # React if block flag has been set. SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'" # Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed. SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137" SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
    0
  • quizknows
    Without access to the server itself to check logs and use debug settings it would be hard for me to fix that. Humor me though... in the site's .htaccess, add this line: ErrorDocument 401 default This should bypass custom 404 handling for 401 responses which can sometimes interfere with this. Also check for the existence of files called ip.dir and ip.pag in these locations (they should be in one of them and recently modified): /tmp/ /var/cpanel/secdatadir/
    0
  • rregister
    Without access to the server itself to check logs and use debug settings it would be hard for me to fix that. Humor me though... in the site's .htaccess, add this line: ErrorDocument 401 default This should bypass custom 404 handling for 401 responses which can sometimes interfere with this. Also check for the existence of files called ip.dir and ip.pag in these locations (they should be in one of them and recently modified): /tmp/ /var/cpanel/secdatadir/

    I did find both files /var/cpanel/secdatadir/. only ip.pag timestamp indicates that it was edited today. ip.dir was last edited several days ago. It's still not blocking, but I'm going to try the same code on another vps. thanks for all the help regardless - just blocking the attempts without a referer will go a long way
    0
  • rregister
    Just an update - I still can't get the blocking to work on repeated failed login attempts (with referer). I've now tried it on VPS servers with 3 different hosting companies, all of which are using apache 2.4 with modsecurity 2.9.
    0
  • quizknows
    That's odd. I'm using the same apache and modsecurity versions and the rule is still working fine. Are you adding the rules yourself to modsec2.user.conf and restarting apache after? Are you adding them over a terminal or via WHM?
    0
  • rregister
    That's odd. I'm using the same apache and modsecurity versions and the rule is still working fine. Are you adding the rules yourself to modsec2.user.conf and restarting apache after? Are you adding them over a terminal or via WHM?

    I was initially doing it via WHM, but have since tried it via terminal with the same result. The only thing I can possibly think of is that I'm using ruid2, but I thought those issues were resolved a long time ago... I'm using exactly the rules I posted above, with the only addition being Include /usr/local/apache/conf/modsec2.whitelist.conf SecUploadDir /tmp SecTmpDir /tmp SecDataDir /tmp SecRequestBodyAccess On
    0

Please sign in to leave a comment.