WordPress is one of the most commonly used publishing platforms on the Internet, and that widespread usage makes it a favorite target for hackers. WordPress is also grounded in the LAMP stack, itself a widely used platform for serving websites of all kinds. The net problem for coders, publishers and web designers is that WordPress hosting, while robust with features and easy to use, is rife with opportunities for break-ins. Securing a WordPress installation therefore requires a bit of advance planning and commitment to staying current with both updates and news regarding attacks. Let’s take a look at some things publishers can do to reduce the risks that may go along with operating a WordPress system.
One of the most common mistakes folks make with WordPress installations is setting excessively permissive rights on the installation folders. It doesn’t help that the default WordPress install asks users to open permissions up and then throttle them down after the install is completed. It’s always wise to go back through the installation to make sure that only folders that need full permissions, such as those expected to receive uploaded content, have them.
Widgets and Plugins
A major attraction of WordPress is its ability to accommodate a host of widgets and plugins. Unfortunately, a lot of installations get overloaded with these add-ons. Users often try them out and then forget about them. Also, maintainers of such code sources frequently fall by the wayside and stop updating them. It’s a good idea to conduct an audit at least once a year of the add-ons that are running on top of a WordPress installation to make sure everything is still being maintained and properly patched. When in doubt, it’s prudent for users to throw questionable plugins and widgets out.
The entire software stack running WordPress is a full set of desirable targets for hackers. Programmers may need to put on their admin caps and go to work at the operating system level to see that installations aren’t vulnerable from odd angles. This means making sure that MySQL, PHP, Apache and Linux are all kept up-to-date.
If someone is running WordPress on a server, there’s a pretty good chance they’re running more services on the system than are absolutely necessary to deliver a web page. For example, coders may want to turn off all mail services if a system is not receiving or sending mail from WordPress. Almost all operating systems install more services than are needed, so conduct an audit of the services running on the OS and turn off anything that isn’t of immediate use.
While obfuscation is of debatable value in defending against attacks, it may be prudent to change the headers that a WordPress installation and LAMP server are sending. Lazier hackers often use automated scanning systems that probe sites just to see what responses they get. Typically, sites are configured to give up a lot of vital information regarding the software underpinning their operation. By going into the configuration files for both Apache and WordPress, coders can significantly reduce the amount of information that’s being given up voluntarily. While this will do nothing to deter committed attackers, it will at least avoid attracting drive-by and automated attacks.
Scanning the ports that are open on any computer is an essential part of handling security. Port scanning serves two purposes. First, it allows coders to identify unused ports that can be closed. For example, if a programmer has disabled the email services on a system, they can readily turn off the IMAP and SMTP ports. Secondly, port scans can allow admins to identify malicious code that’s already present on a server. Many attackers open up ports to communicate with their code, and spotting a port that has opened up for no reason is a good way to get a start on turning back an active attack.
Disable Reporting of Errors
It’s important to not disclose more information about a site than is necessary. If a programmer is not actively doing development on an installation at a given time, error reporting through PHP should be turned off. Programmers can go into the wp-config.php file and switch error reporting to 0 in order to accomplish this.
The more complex usernames and passwords are, the less likely they’ll be compromised. Users should avoid employing any term in a password that can be found in a dictionary. It’s also prudent to avoid using number combinations that can easily be guessed, such as birth years from 1900 onward. When possible, try for passwords at least 8 characters in length. The longer the better, but the key is to utilize more complex combinations of numbers, letters and other characters.
The prefix “_wp” is the default for tables placed in the database to support WordPress. This is another case where it may be wise to not do the bad guys’ homework for them. Changing the default prefix for a WordPress system will minimize the damage that can be inflicted by drive-by and automated attacks.
Dealing with all the demands of securing WordPress can feel like a lot of work. One solution is to simply make the job someone else’s problem. By moving a site to a dependable WordPress hosting system, programmers can leave the complex task of updating operating systems, servers and the underlying installation to a third party. It’s wise, however, to check with the hosting provider to ensure that updates will be regularly applied. Likewise, publishers may want to ask around and find out how well service providers have handled these tasks in the past.
Diligence and thoroughness are the keys to keeping a WordPress system safe from potential attacks. By tightening a system down to the minimal requirements to keep pages running optimally, programmers can avoid opening up some of the most obvious avenues for attacks. With a bit of planning, any publisher can achieve this goal.