Deployment

Primary Software

SEO

Utilities

Considered

Process

Digital Ocean Specs

WordPress on 14.04
$10/month $0.015/per hour
1 GB/1 CPU
30 GB SSD Disk
2 TB Transfer
Datacenter region: New York
Backup

Trouble Shooting

Theme Installation

While attempting to install the theme, I received the following message. I would need to adjust Apache settings.

Apache server file access via SSH and Nano

$ sudo nano /etc/php5/apache2/php.ini

Altered settings

upload_max_filesize = 50M
post_max_size = 50M
memory_limit = 200M
max_input_time = 150

Server restart

$ service apache2 restart

I was then able to upload and activate the theme without incident.

Downtime

I was searching for the website daily in Google in anticipation that it would show up in the results. When it did, I clicked on the website link and the website displayed an error.

I was able to immediately restart MySQL and the website immediately worked again

$ service mysql restart

I hoped that this would be a one-time error. However, on two consecutive mornings soon after, I clicked on the site and the error was displayed again. I did some research and it turned out that XML-RPC attacks were being carried out against the website. This is a malicious, "brute force" attack in which thousands of requests are sent to a website in a short amount of time, rendering the database unresponsive. The attacks began around the time the website showed up in the Google search engine results and it seemed likely the attack crawler found it that way. I used guidance from the Digital Ocean article How To Protect WordPress from XML-RPC Attacks on Ubuntu 14.04 to protect the website from this kind of attack.

I first accessed the log to verify that an attack of this type had been carried out against the site

$ grep xmlrpc /var/log/apache2/access.log

The log showed that thousands of attack requests had taken place. The Digital Ocean article explains how to identify an attack request. This is a screenshot of just a few of the many requests.

I then put a fix in place to block this kind of attack 

$ sudo a2enconf block-xmlrpc

Finally, I restarted Apache for the fix to take effect

$ sudo service apache2 restart

Though the attack requests would continue to show in the log, the code would no longer be 200.

Apparently, the current configuration can be undone by using the following commands

$ sudo a2disconf block-xmlrpc
$ sudo service apache2 restart

One caveat to the approach that I used is that any service that utilizes XML-RPC will be prevented from functioning, including Jetpack or the WordPress mobile app. Though this website is not using Jetpack, if it were, another option would be to use a Jetpack security feature as outlined in the article Jetpack Protection From Brute Force XML-RPC Attacks.

For further reference:

results matching ""

    No results matching ""