How do you go about protecting a default WordPress installation?
What checklist do you use, best practices, tips and tricks, etc?
Any recommendations on plugins, third-party tools are welcome.
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
There is actually a really good guide to this on the wordpress website - Hardening WordPress.
However my personal short check list is
ModSecurity with the Core Rule Set isn't bad, but it's better to configure it explicitly for every input the app takes, as well as fixup the unescaped output it sends on the outbound. This works best in full proxy mode, but embedded has some other unique advantages. It might be clever to use both, especially since Wordpress is insanely insecure.
One step would be to secure the server (which is usually Apache) which is outlined in the responses of my previous question of Hardening Apache Server
.htaccessfile you can lockdown your wp-admin directory by IP address. This means only IP addresses you specify can access your admin dashboard URLs.
In addition to the great advice above, I have another suggestion: I recently published a Wordpress plugin that you might find helpful. I call it Foresight. It's available for download from the Wordpress Plugin Directory:
(It's also mirrored on github.)
The plugin is pretty simple: all it does is load a "Foresight" link into the "Tools" section of your sidebar when you're logged in as an administrator. If you click on that link, you will be presented with a series of tabbed iframes, each of which displays the newest Wordpress exploits found at the following popular exploit trackers:
This tool isn't particularly fancy or anything. (I think of it as a dumb tool for a smart administrator), in that it's ultimately just loading a bunch of iframes. To use it, you just periodically load it up and browse the exploits, keeping an eye open for exploits in the Wordpress core or plugins that you use. If you find such an exploit, you can then make an intelligent decision regarding how best to proceed.
I made this plugin because, after the recent TimThumb debacle, it became obvious to me that many Wordpress administrators don't keep an eye on the exploit trackers. My hope is that this will make it slightly easier to do so.
I'll add my answer too:
Using HTTPS (there also exists free ssl by "Let's encrypt").
Doesnt type credentials on unknown/public PC/WIFI internet (if I need internet on the fly, I share internet from my mobile to my laptop)
Using secure passwords
having only 1 admin (myself) and assign others as editors,etc...
Subscribing to wpvulndb.com for every-day news.
Checking sites with Pen-Test plugins (like these).
Using Two-Way authorization plugin.
DisplayName - set them different than
Disable warnings on login page(using iThemes plugin)
Brute-force block (using iThemes plugin)
wp-admin url (using iThemes plugin)
Disable PLUGIN/THEME file modifications from dashboard (using iThemes plugin)
In some cases, using IP LOGIN RESTRICTOR plugin (blocks all non-permitted IP if he tries to enter any page in
installing security plugins (like iThemes), which does:
If the specific site is HIGHLY CRITICAL, I use only those plugins and theme**, which's source I've checked line-by-line for security .
Enable automatic updates for CORE & PLUGINS & THEMES !
use "block bad IP/bots" plugin.
installing Activities plugin to inspect activities from time-to-time.
check log-in records for IPs if someone entered from other country.
Log-out if using public internet.
someone might bypass two-way authorisation,
wp-admin backend obfuscations or other restrictions using :
"COOKIE Brute forcing" (instead of user-password checking).
WordPress app on android (doesnt ask for 2-factor details, because has it's way to connect to WP)
JSON-API commands (doesnt ask for 2-factor details or etc...)
You might heard several of these, but they are useless:
wp-* links in source (quite useless, someone just checks any file i.e.
example.com/wp-settings.php for 200 HTTP code).
Hiding WordPress version/readme (useless, because someone might check site source and will understand which version you might be using)
Changing Admin username (useless, anyone can view your usernames at :
yoursite.com/wp-json/wp/v2/users unless you do what I've said in the top)
There are hundreds of articles on this topic. Please read the following articles.
If you can afford it, rent a dedicated server so that other compromised websites that are hosted on the same box as yours don't effect you. You can do all that you possibly can to ensure that your website is secure, but if your host is using an outdated version of Apache or Linux, that alone could be your demise.
Regularly perform a checksum and/or code review on your plugins. It's common for hackers to inject shellcode into your plugins, both because you wouldn't expect it/look for it there and because it will be executed whenever that plugin runs. If you find any plugins you can't verify that you installed, remove it. Keep an eye on the date a plugin was last modified as well, document each modification you make to a plugin.
If you must store passwords, do so securely. Use a strong hashing algorithm with a per-user salt (no two salts should be the same). The users salt (if stored) should be in a separate database. Read this article (OSWASP) on how to store passwords in a secure fashion.
Speaking of databases, use the least privilege rule. Checking if a users credentials are correct doesn't require root privileges.
Be sure to perform validation on all user input. For searches, registration fields, etc. this will be easy, comments/reply not so much. Set a whitelist of valid input, restrict everything else. For example, on your registration page there is no reason to allow anything else but a-z, A-Z and 0-9 on the username field. Everything thing else should be explicitly restricted. From my experience, the easiest way to break into a website (Wordpress or not) is by exploiting incompetent validation. Make use of whitelists and character escaping.
Account for all attack vectors. If you're only doing a Wordpress installation, securing it is relatively easy. However, in the future you may install additional plugins and applications (Forums, e-commerce, analytics, etc.). You must then ensure they are kept up-to-date and that you have secure passwords.
Limit the number of login attempts a user can attempt before being locked out. Personally, I use the aptly named "Limit Login Attempts" but there are quite a few out there, such as Login Lockdown. Some people also use a CAPTCHA on their login page, it's a matter of preference. This will tremendously reduce the odds of a bruteforce attack (an already poor method of penetration) from being successful. Enable the optional logging as well.
If you need additional information, don't hesitate to contact me. I had a lot more to add, but decided to remove it to spare your energy ;)
For self auditing you may find plecost of interest.
Definitely check out http://codex.wordpress.org/Hardening_WordPress for a very comprehensive list of tactics and strategies. Other answers to your question have similarly useful links. Go through each one in turn until you feel like you have adequate coverage.
Also, be VERY aware of which plugins you install and how many. Whereas WordPress is under constant development and peer review, the same not be said of many of these plugins. Each one represents a security risk and must be maintained.
The iThemes Security plugin is pretty good for doing stuff like changing the login names, database prefix, salts and even changing/hiding the admin area and login page. It's also good for checking permissions.
Something I haven't seen too much of is how to protect the xmlrpc.php which is exposed to DoS attacks even if you use the Jetpack plugin and switch "protect" on. I found this code to put in the .htaccess or apache file to only allow xmlrpc.php access by WordPress's IP range.
<files xmlrpc.php=""> Order Deny,Allow Deny from all Allow from 220.127.116.11/18 Satisfy All ErrorDocument 403 http://127.0.0.1/ </files>
Hopefully this is helpful or perhaps someone knows a better way to protect the xmlrpc.php?