Last week I was approached by a client. Their website had crashed for some reason and she needed help bringing it back up. The website consisted of a Wordpress blog with an online storefront running in a LAMP environment on Ubuntu 14.0.4, and should have had more than adequate server resources to run efficiently. But for some strange reason, this little website was constantly running at anywhere from 78-95% of RAM capacity, even during hours you would expect to see minimal traffic.
Checking Ubuntu’s log using the command,
grep sshd.\*Failed /var/log/auth.log | less
I found that remote users from all over the globe were trying to log into the backend at a rate of about once a second. Suddenly this peculiar strain of resources started to make sense. The patterns I saw was clearly indicative of a Brute Force Attack.
I consulted one of the company’s web designers that manages most of the Wordpress-side of the website and discovered that it was also under attack. Similarly, unknown users were attempting to login through the wp-admin.php portal at the same rate as the attempts at the backend.
Digging deeper into the site’s history, I discovered that these attacks had started months prior, after one of the company’s interns downloaded a plugin called “Google Analyticator” that was loaded with malware. After this initial infection, the company’s Web team attempted to clean up the site and protect it using various virus scan and firewall plugins. But no matter what they did, the attack continued.
Eventually, the owner of the company moved the website to a new hosting company in hopes of putting an end to the attack, but to no avail. The attackers followed the website to its new IP address and continued their assault, eventually overloading the website to the point of crashing it and halting all online sales for the company. This is where I come into the story.
Soon after taking the job and diagnosing the problem as a Brute Force Attack, a news article was brought to my attention: http://www.scmagazine.com/isil-sympathizers-defacing-wordpress-websites-fbi-says/article/408040/
Mind you, I have no inclination to believe that ISIS sympathizers were behind these attacks, as the technologies to implement these attacks are easily accessible and widely used, but the symptoms matched exactly. It seems that when that intern downloaded the defunct plugin, a line of malicious, executable code was injected into site, telling these bots to target it. And when the site migrated to the new server, that beacon moved with it.
I discovered that the ultimate goal of the attack was to gain access to the site, create a new account with administrative privileges, and ultimately take control of the website. To what end, I did not intend to find out.
I tried running several malware scans including ClamAV and Sucuri Security, but nothing was detected. If that mal plugin had indeed injected malicious code into the site’s cache, then it was obviously undetectable by ClamAV’s and Sucuri’s definitions.
Acting quickly, I implemented a dynamic firewall on the backend using iptables and ip6tables that would automatically detect attacks and block malicious IP addresses. Watching the logs, this seemed to be helping, but a few subnets were able to find a way around the firewall and continue their assault.
As more drastic measure were obviously necessary, I decided to change the SSH configurations, changing the port from default (22), and tightening authentication requirements.
This worked beautifully. The attacks on the backend stopped immediately.
With the backend secure, it was time to lockdown Wordpress. By consulting the recent FBI public service announcements and Sucuri’s website, I learned that these attacks could be deflected on the frontend by changing Apache’s httpd configuration and the .htaccess files in the assailed web directories. Further research indicated that the use of .htaccess login credentials or a Captcha box at the wp-admin.php login portal was in most cases enough to deter these Brute-Force bots.
Seeking the most user-friendly and cost-effective solution for my client, I decided to implement Sucuri’s cloud-based firewall ($10/month to have a team of security professionals on call seemed more doable than telling my client to shell out hundreds on an Apache technician).
Within an hour of setting up the Sucuri’s CloudProxy, the attacks ceased on the Wordpress side.
I have never experienced an attack on one of my own sites, but after going through this ordeal with my client, I will absolutely be implementing these measures on my own site, and recommend the same precautions to anyone running their own business on the web.
If you are experiencing a similar attack on your website, here are some of the resources I used to stop the Brute-Force attacks.
IPTABLES resouces:
http://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/
SSHD configuration:
http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
Apache httpd and .htaccess:
http://httpd.apache.org/docs/2.2/howto/htaccess.html
http://www.javascriptkit.com/howto/htaccess.shtml
http://www.mnxsolutions.com/apache/blocking-wordpress-brute-force-attacks-against-wp-login-php.html
Example Brute Forcer scripts and information:
https://github.com/lanjelot/patator
Questions? Personal stories? Additional tips for securing your website? Leave ‘em in the comments.
janainaart
germansingergirl
tangentwithtanner
ellievsbear
areudirty
romaincrisis
vaporwave