Install Redis Server on Ubuntu 16.04

Why would I use redis?

Redis is wonderful for many reasons. I primarily use it for caching web applications like Magento 2 and WordPress. Some other great ways to use it are as a database or a message broker. You should check it out here.

How do I install it?

The official suggestion is to build the package, but I’d much rather install applications from an official package repository (PPA). This simplifies the install, upgrade, and uninstall methods greatly.

First, you’ll need to add the PPA repository to your OS.

sudo add-apt-repository ppa:chris-lea/redis-server

Next, you’ll want to update your repositories.

sudo apt update

After that, run the installation script.

sudo apt install redis-server

Check that everything installed correctly by checking the version, starting the server, and checking the status of your newly installed server.

redis-server --version
sudo service redis-server start
sudo service redis-server status

You can run a few commands to test out your new server by jumping into the redis-cli application that was installed with your server. If not, just install redis-cli and boot it up.

$ redis-cli
127.0.0.1:6379> ping
PONG

When you get that PONG back, it’s quite satisfying. Let’s test saving and retrieving some values.

127.0.0.1:6379> set bears-eat "beets"
OK
127.0.0.1:6379> get bears-eat
"beets"

Final Notes on Web Aplications

Magento 2

You can configure Redis with Magento 2 quite easily for some really great performance benefits. There are a lot of reasons to use Redis over a few other technologies for many reasons, which are outlined quite nicely over in the Magento DevDocs.

WordPress

WordPress can easily cache with Redis with the installation of a single plugin. I love that it’s a single click away from being enabled or disabled. It’s stupid simple installation abstracts all the heavy lifting Redis does and hides the awesome power in the back-end. You’ll really love the performance boost though, and so will your visitors!

 

Prevent XML-RPC Brute Force Attacks – WordPress on Ubuntu 16.04

Overview

In my foray into cloud hosting, I’ve noticed that a few of our servers started to peak in their CPU usage more than what normal web traffic would cause(2-5% and 10-30% on our t2.medium and t2.small AWS EC2 servers respectively). After looking at the Apache2 logs, I found that there was a significant number of hits trying to look for combinations of phmyadmin, db, sql, and many other url keywords. This is obviously bothersome, but we’re all secure, so it didn’t cause much of an issue.

What did cause worry was the sheer number post requests to the /xmlrpc.php file. The IP addresses appear to be located in russia, and there were a handful different IP addresses that all had very similar origins. I’ve obscured the starts, but the IP range was ***.***.204.7-12. There is obviously enough traffic to blip our CPU usage on the medium server and enough to task the small server in a big way. To be more exact, there were ~78,000 requests in the log originating from those IP addresses over the past few days.

Why Is This Happening To Me?

There are many reasons hackers would like to gain access to your hosting server. One of the major reasons may be to steal resources to mine or farm bitcoin or some other cryptocurrency.

XML-RPC allows for very efficient brute force hacking, as it allows for hackers to check many username/password combinations in one single request. This is all at the cost of giving developers access to remote procedure calls.

XML-RPC Solution: Apache2 Deny From All

As I don’t use WordPress mobile, or other applications/plugins that require external access, I’ll be disabling access from external addresses.

The simplest solution to blocking this type of traffic on an Apache2 server is to simply deny access to the /xmlrpc.php file itself. To do this, you just have to add a few lines to your site configuration files in Apache2.

sudo vim /etc/apache2/sites-available/*yoursitehere*.conf

Your VirtualHost configuration should look something like the example below after adding the bolded lines.

<VirtualHost>
#Some stuff
    <files xmlrpc.php>
      order deny,allow
      deny from all
      # you can allow from your own IPs using the following line
      # allow from ###.###.###.###
    </files>
</VirtualHost>

Finally restart Apache2 and you’re on your way to preventing hackers from eating up your server availability.

sudo service apache2 restart

XML-RPC Solution: Security Plugins

Note: This may be a better solution for those of you who wish to use applications that require XML-RPC to function properly.

There are some security plugins that will either deny access to the file, blog IPs that are abusing the service, or will disable XML-RPC altogether. Jetpack is one of those security plugins that will aid in blocking brute force attacks. WordFence and it’s firewall are really great for blocking IP addresses that are abusing your servers with irrelevant traffic.

Conclusion

If you do decide to utilize a security plugin, keep in mind that their scans and extra filtering procedures may have an adverse effect on your servers speed and responsiveness as well. This is sometimes a necessary evil, but you should plan ahead accordingly.

Blocking access to certain system files may prevent you from accessing certain features. However, you may find your site security more important than whatever feature that may be.

After having denied access to the file, we’re back down to our low utilization on the t2.medium server of <1%. I’m glad to see my CPU Credit Balance stabilize!