Magento is a Falkon favourite; learn how to make use of its powerful features to boost sales by defining related...
Site Security – Protecting Your Website From Hackers
Most of the following steps to secure your website are based around WordPress and making it more secure. However, some of the .htaccess amends can be done for any type of website. The following steps that I’ve been taking to secure all new-development WordPress sites are to prevent from hackers accessing core files maliciously.
Firstly, open up your blog in a new window and put in “/wp-includes/”. If it’s blank, shows an Apache page or a 404 page not found error you’re safe! If you see a long list of files, well you probably guessed that these need to be hidden. Having these open lets anybody see your core files that are located within that directory. To prevent this we can create our own .htaccess file for the wp-includes folder. Within this htaccess file a single line of code will tell the server not to index any file in that folder. To do this simply put the below at the top of your htaccess file in the root.
Options All -Indexes
While we are working with htaccess files, we might as well protect them and the wp-config.php file in the root. In all of the htaccess files that are within your website put in this code:
# protect the htaccess file
deny from all
Within the root htaccess file you’ll need to put the following code to protect the wp-config.php file:
# protect wpconfig.php
deny from all
Let’s break the code down so that we understand it. Firstly the hashtag is a comment line, so anything can be put in this line and will not affect our htaccess file. The second line targets a selected file, in the latter case its the wp-config.php file. Next, we tell the htaccess what order we are setting our privileges in, firstly we are defining what IP addresses to allow, then what IP addresses to deny. We don’t need to allow anybody access to these files, so we can simply put ‘deny from all’ on the penultimate line. The last line is to close the code targeting the specified file.
Next up, we need to log into our wp-admin section with an administrator account. This is so we can delete the ‘admin’ account if there is one. One of the biggest security risks within WordPress is a site that only has admin accounts. These admin accounts are usually set up by default when WordPress is installed, knowing that a site will usually have an admin account gives a hacker a big head start, knowing they don’t have to figure out the username. (If you don’t have an ‘admin’ account you can skip this bit.) To do this, firstly create a NEW user in user control panel, Go for something original that would be hard to guess and create a secure password. You can use the built in WordPress strength meter for this, or one I found http://howsecureismypassword.net/ which will tell you how long it would take a desktop PC to figure your password out. Don’t forget to set the user role to ‘administrator’.
Once done, log out and back in with your new administrator account and access your user accounts once more. You want to delete ‘admin’, you’ll be asked by WordPress what you want to do with all content published under the admin username. You can either delete this (not sure why you would though!) or Transfer it to another user. You want to transfer all content to the new administrator account you have created.
There are a few other amends you can do to your site, with a couple of plugins. Two of which I like to use are User Locker and WP Security Scan. The former will check how many times an account has tried to be accessed if more than 5, it will lock/disable the account. This is useful against brute force attacks. WP Security Scan will let you know whats is a potential security risk on your WordPress website, It checks and does numerous things like:
- Checks database name prefix
- Checks for admin user account
- Hides the current WordPress version
- Turns off WPDB errors
- Removes WP ID META tag from core files
- Checks for wp-admin htaccess files
- Checks latest version of WordPress
We discussed table prefixes and while the plug-in and many other WordPress users out there suggest you should change it, it could throw errors on current sites. WordPress also suggest that you should stick with the current _wp prefix tag. I argue that it should be changed as its quite a big risk, as all WP tables will be called the same it would be easy for a hacker to target a specific table within your WP site. WP Security Scan will do this for you as well, which takes seconds.
Keeping your WordPress website on the latest update will always help to prevent hacks and bugs appearing. Holes will always be filled on new releases, making WordPress ever stronger.
Hopefully this has been useful and will keep those hackers at bay!