Securing WordPress on On-Ramp Indiana's Servers
If you've read the installation post, or if you have only read about attacks, you may be aware that running any content management system has implied risks. What are these risks? First, WordPress and all CMS are third-party software. You and I didn't write them, and we don't warranty their fitness for any purpose. Talk to a website expert if you have trouble determining the amount of risk and exposure that is right for you based upon this.
Due to the possibility of remote code execution, sql injection, and file permissions issues, we recommend auditing all web properties regularly. The process below is the foundation a healthy data stewardship should be set upon. Preformed regularly, you can mitigate many of the inherent risks in content management systems such as WordPress. The alternative is to forever be at the mercy of internet terrorism.
First, login to the control panel provided by the website host. Be sure that your web user does not have permissions to write all willy-nilly. I understand that you may need to write to folders sometimes, such as the wp-content folder in WordPress. When you are finished editing the website, lock the gate closed by removing those write permissions. Generally speaking, the web or www user should only need read; not read/execute, as the file type is picked up by the handler mapping in IIS or the deceleration in the apache configuration (sometimes in the .htaccess file in the root of the folder).
Next, find a way to efficiently backup your site. In most cases, you should use FTP so you have a good sense for directory structure, should you have to restore that precious backup. Next, delete your site! You got it, remove all! To pass the test, restore your local copy of the files, and prove that it works. Test it again! Good, that's how painless restoring your site should be. Now repeat the process for SQL/MySQL - this is imperative Every person responsible for producing a website should understand the database is separate from the files that make up the site. Drop and re-create the database as well.
So now that you have validated your Data Restore process, you must now make that a habit. I'd suggest scheduling an ftp backup via command line regularly. As with any backup, archive a few versions based upon your normal protocol. I carry no fewer than 5 days of backup, on the off chance something implodes while I'm out. I like to have 5 weeks.
Now that you know how to backup, you can perform that dance one more time, before we upgrade WordPress to the latest version. That's right, every time it's updated, you'd better update too. The reason why stems from how updates work. Now that the updated code is out there, the bad folks can read the changes, and take advantage of any new found bugs. Based upon version alone many sites get compromised as vulnerability scanners are turned against the whole internet, attacking each vulnerable site as they are found.
The challenge from this process is sometimes the plugins installed in a WordPress site, or the theme itself is getting in the way of progress. The version of WordPress may fix a bug your site depended upon. Often this can be resolved by updating the plugins after updating the WordPress site. Sometimes, there are not any updates, and you must use another module, which will invariably require installation and configuration.
While you are updating and fixing your site, add another plugin to it attack-scanner.com free or paid, to help protect your hard work from malicious attacks. I recommend the Pro version for my favorite feature, and that's the integration with TrustedSec's Project Artillery. For those not in the know, here's enough information to get you started. Keep in mind the free version of attack scanner for WordPress will not permit you to act on threats, only visualize and assess risk.