Massive Brute-Force Login Attack and Distributed Denial of Service Attack
For the first time in more than 3 years, we have suffered from a Distributed Denial of Service Attack (DDOS) caused by a Massive Brute-Force Login Attack.
In an ongoing effort to make you aware of security and performance concerns, we wanted to inform you of an event that brought all websites down for about 2 hours.
Yesterday, there was a massive brute-force login attack targeted at websites with WordPress. This brute-force login attack is engineered, in the end, to perform a Distributed Denial of Service Attack. Due to the nature of the attack, memory consumption on targeted servers has increased. In some cases this has resulted in degradation of performance, and unresponsive servers. This is due to a high volume of http requests (the failed login attempts) which can cause some servers to start swapping memory to disk, and possibly run out of memory. LiquidWeb’s monitoring team has been proactively restoring service to managed servers which have been affected.
Not only has LiquidWeb taken proactive steps to reduce the impact of this event by deploying a new ModSecurity rule to servers, we have also implemented another security plugin and will be installing it in each website. This new LiquidWeb rule will block http requests to the WordPress login page after 10 failed login attempts at the server level. The attacking IP address will then be blocked for less than a day. Our new security plugin will only allow 1 or 2 attempts to login, then it will block the offender’s IP address for many days. We can unblock anybody that gets accidentally blocked from using an incorrect login.
We are using a security plugin called Wordfence. Wordfence scans your site for viruses, malware, trojans, malicious links, protects your site against scrapers, aggressive robots, fake Googlebots, protects against brute force attacks and much much more.
We also use The Sucuri Security SiteCheck Malware Scanner plugin for WordPress. It enables me to scan your WordPress site using Sucuri SiteCheck right in your WordPress dashboard. SiteCheck will check for malware, spam, blacklisting and other security issues like .htaccess redirects, hidden eval code, etc.
Sincerely,
Ocala Website Designs & Hosting
More information:
WordPress is a popular publishing platform which is known for its robust features, numerous templates, and large support community. Unfortunately, due to such popularity, WordPress is also constantly subject to attempts at exploiting vulnerabilities. Ensuring WordPress and any associated plugins are installed with the most current versions is an important means of securing your site. However, ModSecurity provides a significant amount of further security by providing an application firewall.
ModSecurity (also known as “modsec”) has proven itself useful in a variety of situations, and again this is true in assisting with WordPress brute force attempts resulting in a Denial of Service (DoS) attack. While a number of WordPress plugins exist to prevent such attacks, custom modsec rules can prevent such attacks for all WordPress installations on a server. Modsec immediately filters incoming HTTP requests, which assists against taxing server resources.
These rules will block access for the offending IP address for 5 minutes upon 10 failed login attempts over a 3 minute duration. These rules have been automatically updated in the custom rules for Liquid Web’s ServerSecure service. For customers without ServerSecure, these rules can be added to their custom modsec rules. To accomplish this, edit your custom modsec user rules and append the file with the rules provided below. For CPanel servers, this file is likely located at /usr/local/apache/conf/
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134
<Locationmatch "/wp-login.php">
# Setup brute force detection.
# React if block flag has been set.
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.'"
# 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:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"