There are lots of reasons why people might want to compromise your WordPress site. They range from simple mischief (“look, I hacked into Stanford and my name is now on their web page!”), to financial reasons (“I can now use the site to send out tons of spam through Stanford’s servers and get paid for it by my clients”). Even if all of your content is public, your site is still a target and it’s your responsibility to keep it as secure as possible.
To help keep your site secure, make sure that you:
- Upgrade the software regularly through the WordPress Upgrader.
- Don’t allow people to self-register and become admins.
- Use strong passwords.
- Use WebAuth, if possible, for logging in.
- Set AFS permissions correctly (AFS is the file system where your data is stored).
- Retire the site properly when you no longer need or use it.
Keep the code up-to-date
WordPress is a secure platform to begin with, but as time goes by hackers discover bugs they can exploit to break into your site. Therefore, it's very important to keep the software up-to-date when new versions of WordPress and its plugins are released. See Keep your WordPress site up-to-date.
New users
WordPress can allow anyone to register and create an account on the site. This is great if you want new subscribers to be able to create their own accounts, follow your blog and you have time to monitor new users. Unfortunately, this feature can be exploited by spammers who use these accounts as a foothold for trying to break into your site. If you don't have time to monitor your site and delete spammer accounts, you may want to prevent users from creating their own accounts.
Prevent users from creating new accounts on their own
In the Admin Panel, select Settings > General and verify that the Membership - Anyone can register option is unchecked.
If you are using WebAuth for authentication of new users, only Stanford users will be able to create accounts, which is much safer. However, if you still want to prevent new users from having accounts on the site, in the Admin Panel, select Settings > HTTP Authentication and uncheck Automatically create accounts?
Verify the role is correct
New accounts automatically receive a default role. You should verify that the role is the correct one. At install time, the default role new users receive is that of Subscriber, which allows them to create an account and read the blog, but nothing else.
To verify the default role visit the Admin Panel for your site, select Settings > General and verify that Subscriber is the value for New User Default Role.
Strong Passwords
If you are using local WordPress accounts for administration, make sure that you set strong passwords. If your password is weak, it’s just a matter of time before one of the automated password-guessers running around the internet find it. Stanford’s web servers are probed thousands of times a day.
For advice on choosing a strong password, see SUNet ID Passwords.
Use WebAuth for user authentication
WordPress installed through the WordPress Installer comes with a plugin, called "HTTP Authentication" which integrates WebAuth with WordPress, allowing you to log in using through Weblogin using your regular SUNet ID and password. It’s more secure, and there is one fewer password to remember.
When you installed WordPress, you would have been given the option for WebAuth. If you didn't select it at that time, and would like to enable it after the installation is completed, please submit a Help request.
AFS permissions / file system security
You’ll also want to make sure that the permissions for the WordPress software files installed on AFS (Stanford's distributed file system) are set up correctly. If they are not, they could allow someone else to read your database password, or they could allow someone to write malicious software or modify your files to gain access to the software application.
The correct permissions are set up at install time by the WordPress Installer. If you'd like to double-check, the easiest way to do so is through WebAFS, the Web interface to Stanford's distributed files system called AFS.
Visit https://afs.stanford.edu and under Current AFS Directory Path enter your group or department's cgi-bin directory. For example, for the history department, the correct directory would be /afs/ir/dept/history/cgi-bin. For a group called opensource, the correct directory would be /afs/ir/group/opensource/cgi-bin.
Select the directory where the blog is installed and click on Set Permissions for Folder.
A list of permissions for the folder will be shown. The correct permissions are:
- -admins group: all permissions
- system:dept-admin: all permissions
- system:backup: lookup and read
- system:www-servers: lookup and read
- system:administrators: all permissions
- service.tools: lookup and read
- your group or department's .cgi: all permissions except admin
When it’s time, retire the site
If you no longer need your WordPress website, you should retire it so that it doesn’t become abandoned software. See the Retire your WordPress Site section of this guide.
For help, submit a Help ticket or visit the Stanford University WordPress Community of Practice.
