How to protect your WordPress site from attack and keep it safe and secure.
WordPress powers an astonishing one-third of all websites these days. It has been the CMS platform of choice for our community since the mid-aughts when many of WordPress’s SEO features were implemented. It is therefore relentlessly attacked, largely for SEO spam reasons, but attacks can escalate to much worse.
Is WordPress safe?
The latest version of WordPress is very safe out of the box. Neglecting to update it, however, among other things, can make it unsafe. This is why many security professionals and developers aren’t WordPress fans. WordPress also resembles PHP spaghetti code which is inherently insecure, where WordPress itself warns that vulnerabilities “stem from the platform’s extensible parts, specifically plugins and themes.”
There is no such thing as a 100 percent secure system. WordPress needs security updates to operate safely, and those updates shouldn’t negatively affect you. Turn on automatic security updates. Updating the WordPress core, however, does require that you make sure everything is compatible. Update plugins and themes as soon as compatible versions are available.
WordPress is open source, which entails risks as well as benefits. The project benefits from a developer community that contributes code for the core, the core team patches security flaws found by the community, while hooligans discover ways to pry things open. Vulnerabilities are scripted into scans by exploit applications which can detect what versions of things are running to match known flaws to your versions.
Protect yourself first:
There are things you can do to protect yourself even when you don’t have an administrator role. Make sure you’re working on a secure network with a regularly scanned workstation. Block ads to prevent sophisticated attacks that masquerade as images. Use VPN for end-to-end encryption whenever you’re working at public WiFi hotspots to prevent session hijacking and MITM attacks.
Securely managing passwords is important no matter what role you have. Make sure your password is unique and long enough. Combinations of numbers and letters are not safe enough, even with punctuation, when passwords aren’t long enough. You need long passwords. Use phrases of four or five words strung together if you need to memorize but it’s better to use a password manager that generates passwords for you.
Why is length so important? Put it this way, eight character passwords crack in less than 2.5 hours using a free and open source utility called HashCat. It doesn’t matter how unintelligible your password is, it only takes hours to crack short passwords. Starting at 13+ characters, cracking begins to get insurmountable, at least for now.
If you have an admin user role, create a new user for yourself that’s limited to an editor role. Begin using the new profile instead of admin. That way, wide area net attacks will be centered on attacking your editor role credentials, and if your session gets hijacked you have the admin capacity to change passwords and wrest control away from the intruders. Compel everyone, perhaps through the use of a plugin, to follow a strong password policy.
If you have security experience, perform code audits of your plugins and themes (obviously). Establish the principle of least privilege for all the users. You then are forcing hackers to perform shell popping tricks and privilege escalation which involves attacking targets other than WordPress credentials.
Change file permissions:
If you control the host, provide yourself with a SFTP account through the use of the Control Panel if you have one, or try what administrator user interface you have access to. It may have the side effect of configuring credentials to open a secure shell terminal window (SSH). That way you can perform additional security measures using system utilities and more.
Lock down critical files:
There are a few files that should never be accessed except by the PHP process running WordPress. You can change file permissions and edit the .htaccess file to further lock these files down. To change file permissions, either use your SFTP client (if it has the option), or open a terminal shell window and run the chmod utility command.
$ chmod 400 .wp-config
$ ls -la
This means that only the PHP process running WordPress will be able to read the file, and nothing else. The file should never have the “execute bit” set, like with chmod 700. You should always have zeros in the second and third place — that’s what really locks it down. Verify your changes running the ls utility with -la options and have a look.
Having strict file permission settings means nothing can be written to the file, even by WordPress. You’ll want to grant write permissions back with
$ chmod 600 .wp-config when there is a major WordPress update wherein the config file has modifications. That should happen extremely rarely, if ever.
WordPress login file:
I like to lock down the wp-login.php file using .htaccess rules. Limiting access to only my IP addresses is great for when I work from one statically assigned IP, or a small handful of addresses for myself and some users. It’s not difficult to change the setting if you’re logging in from another location as long as you can obtain a shell on the host. Simply comment out the deny directive, login with your browser, and uncomment it afterwards.
XSS and SQL injection:
By far the scariest attacks that you’ll encounter will be cross-site scripting (XSS) and SQL injection. There are .htaccess query string rewrite rules you can use to stop some of these, and you might be best off using a plugin that will manage this for you. Some security plugins will scan your installation looking for signs of compromise. If you know how to use rewrites, redirect or block query string signatures for attacks you read about or see in your logs.
Some security plugins will scan your installation looking for signs of compromise. Wordfense is a popular security plugin, and it gets regularly updated. Sucuri Scanner has a paid option that will scan your installation. Ninja Firewall is going to try and limit request-base attacks, blocking them before they reach WordPress core. You can also write an application utilizing Google’s new Web Risk API to scan your site’s pages.