Back to my Page
Secure WordPress Setup
This page will document how to setup a secure WordPress installation (2.9 based) containing:
- Site served over HTTPS/SSL (Full and Partial)
- Webserver authentication based on WordPress Users
- Safe Configuration - General hints on configuration considerations
- Database
- Remote Connections
- Cookies / SSL
- Hashes / Security Keys
This will create a WordPress setup that can be accessed via SSL and with a valid username and password only. If no such username and password is provided, the server will display it's standard forbidden page. This setup is fitting for a closed blog only, maybe an extranet or similar. But some of the considerations made here might be fitting for a public blog as well.
For Hardening, please read here: Hardening WordPress
Considerations
- External Links / LinkBacks (Trackbacks, Pingbacks and Refbacks) do not make sense in a closed environment, or do they? How to deal with referers? External links redirector with POST form autosubmit based on javascript? Incorporation of an additional public redirect script then?
- WordPress own cron mechanism won't work. How to deal with that? Can it be replaced with the system's cron?
- WP-Cron explained by Otto; WP-Control Plugin
- Remote connections should be blocked. Gather a list of configuration values. How to update then? What are the options, should it make sense to provide another update method by uploading zip files as admin?
- Constant WP_HTTP_BLOCK_EXTERNAL set to true will block all requests but localhost. WP_ACCESSIBLE_HOSTS is a comma separated list of hostnames to allow additionally (function block_request()).
- for preventing version checks see: HTTP Filter
- Plugin: Disable WordPress Core Update
- Plugin: Disable WordPress Plugin Updates
- Plugin: Anonymous WordPress Plugin Updates
- SSL configuration values should be gathered, how to force the connection over SSL?
- XMLRPC. How does it integrate with authentication? Is it possible to provide XMLRPC only to certain users as well?
- Flash uploads. Flash does not support authentication for uploads. This has implications, it should be considered how to deal with that and the alternatives.
- WordPress Security Keys. What does that mean and for what are they good? Do they help with password hashing?
- It makes sense to harden the PHP installation with suhosin.
- How to prevent Brute-Force attacks on HTTP? Can HTTPD already take care of it?
- Is caching enabled via SSL? Are there any issues to be expected?
- Enable logging. Plugins? Syslog?
SSL Configuration
- As long as only the transport of passwords is done over SSL but cookies are not marked as secure cookies, using SSL for logins only does not make any sense (written down from memory, resources missing but existing).
- Blog URL can be forced to SSL in wp-config and the WP_SITEURL constant.
- Does it take precedence over the FORCE_SSL_LOGIN constant?
- Does it take precedence over the FORCE_SSL_ADMIN constant?
- Additionally, .htaccess/server configuration can be used to force on SSL.
WordPress Security Keys
The configureable security keys are used for the encryption of cookies related to authentication/logging in. Because cookies are transfered in public and stored on the users computer this feature should be used.
The additional nonce key is used in the creation of the nonces which are a countermeasure against replay attacks (XSS) or CSFR.
| Security Keys
|
| Name
|
Since
|
Usage
|
| AUTH_KEY
|
2.6
|
encryption of which cookie ?
|
| SECURE_AUTH_KEY
|
encryption of which cookie ?
|
| LOGGED_IN_KEY
|
encryption of which cookie ?
|
| NONCE_KEY
|
2.7
|
Salt for nonce
|
See Also
Tickets on the run
- #9008 - add a home_url() function to enforce http/https scheme
- #9207 - redirect_to wp-admin Should Force SSL If FORCE_SSL_ADMIN is enabled (still applies?: pending)
- #11009 - request of files over non-ssl while having an ssl-admin (reference to remote data problems: pending)
- #11010 - adapt to https use (still applies?: pending)