Hardening Rackspace Cloud Server for WordPress : Part 3

We are ending our ongoing discussion on the topic Hardening Rackspace Cloud Server for WordPress, to make it improbable to get hacked ever. Unless you have been targeted, it is actually quite rare to get the Server hacked (not WordPress), if the basic points of security are maintained. Without reading the previous articles, probably it will be difficult to understand what we have talked about so far :

1. Hardening Rackspace Cloud Server for WordPress : Part 1
2. Hardening Rackspace Cloud Server for WordPress : Part 2

You can read an interesting guide to Make WordPress Scalable. It has relationship with this final episode of the Hardening Rackspace Cloud Server for WordPress Series. Website with pure HTML pages are not only easy to scale, its easier, cost saving way, less vulnerable to the hacking efforts and Google actually loves pure HTML pages. If you can change the $PATH and the names of the contents served from wp-content,  wp-includes – that is great.

Hardening Rackspace Cloud Server for WordPress : Using Load Balancer and/or Reverse Proxy Server in Front

Whatever setup you’ll have, basically there will be one server which is important for generating content and holds the main files of WordPress. Instead of exposing the bare IP of the server or server group, it is a good idea to add a load balancer in front of your nodes / servers. Apart from making the script kiddies fool by using the different IP address, a load balancer can perform HTTP caching. You will always get a great header response if you use a load balancer. If FTP server is one in number, use round robin algorithm. Do not resolve DNS with main server’s IP – that is, do not add your main server’s IP on Cloud DNS settings. It will be meaningless for the security purpose – we want to pass public internet traffic only via the Load Balancer’s IP. In case of server failure where no nodes are available, Load Balancers serve a nice custom page.

Google bots hugely dislike servers to be down – so adding at least two servers (where one is another’s pure HTML copy) is not a bad idea. However, round robin will not work fine for the best page speed. If you want to use nginx reverse proxy, you can read our guide on Reverse Proxying with Nginx.

On the WordPress side, MySQL Database Server and wp-config.php are common targets of the scripted attacks. chown and chgrp the file to the privileged user, not to the Database Server user name. Probably you’ll require a more liberal chmod value – chmod is of lesser importance on our setup as others are not the World in our case plus we have protected the wp-config.php from .htaccess and .htaccess is also protected.

You will get some details on editing my.cnf file on our Optimizing MySQL Database Performance guide. Probably you will love to load balance your MySQL server, you need to bind the IP on that file. Obviously you can use FQDN instead of bare IP. As you are closing the Ports to access over HTTP and masking MySQL server’s real IP, with proper settings; without the private key, it is actually impossible to login to the server, even with the right username and password.

Hardening Rackspace Cloud Server for WordPress : Monitor the Activities of the Plugins and Themes

Best is to use custom Plugins and Themes, at least modified Plugins and Themes. The Plugins and Themes can give API based access to your database, eventually can perform sql injection. Another weak point is any kind of web form – comment or whatever form when hosted on the same server and can access the database.

Either close the comment forms after a period or specially on a particular post when you notice lot of spammy comments on a certain post. It is better either to offload the comments to Discuss like service or fully close it. Weighing the risk of tracking, data sniffing, keyword sniffing, possibilities of redirection and increase in Page loading speed – its better to not allow comment at all.