• WordPress brute force increase load on the sql server

    SapnaVishwas Member

    WordPress brute force increase load on the sql server

  • Abhey Member

    Just find that as long as we allow even to access login page, a connection is already established and they can easily also DDoS using bot machines without attempting to brute force to fatigue your server memory resource – it is more than just the normal SYN flood but can be type of Slowloris, Slow HTTP POST DoS having HTTP connection to be established and not duly tear down … they can also intentionally force user account lockout…

    Ideally a CDN like Cloudflare or appl delivery controller can act as fronting or reverse proxy separately beyond the Web server. The Web appl FW is definitely worth considering – including Mod security (even if it is using a plugin for Apache server) that go beyond to deep dive into rules that inspect HTTP literals etc.

  • Ganesh Member
    # BEGIN WordPress
    
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    
    
    
    Order allow,deny
    Deny from all
    
    
    
    AuthUserFile /var/www/clients/client25/somesite.com/web/.htpasswd
    AuthName "Private access"
    AuthType Basic
    require user someone
    
    

    And here ist the .htpasswd:

    someone:$apr1$cgUOc8vC$S0GFcoEbawj/oboIEbJx81 
    
  • Adelaid Member

    We tried the same .htaccess setup on another server with the same results. Something doesnt like the code we’re using.

    The server logs show repeated attempted logins to wp-login.php. Wordfence is blocking their access to the site, but not the access to the file forcing sql to say no hundreds of times.

    Would be an easy fix if it were from a single IP, but i cant blacklist them all fast enough. So i am trying to but a buffer between the attacker and wp-login.php file by using httpauth.

    The cloudflare activation was just a hail mary. It is mainly caching so if you force your “attack bot” not to cache you hit the server directly. That is only a guess though. I thought it would help as well.

    This piece of code helped a little:

    # Start DDOS Security
    
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} =POST
    RewriteCond %{HTTP_REFERER} !^http://(.*)?.mysite.com [NC]
    RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$ [OR]
    RewriteCond %{REQUEST_URI} ^/wp-admin$
    RewriteRule ^(.*)$ - [R=403,L]
    
    

    It reduced the CPU load by 20% or so.

Viewing 3 reply threads
  • You must be logged in to reply to this topic.
en_USEnglish