Adding extra protection to your WordPress Admin Page

Yo, I recently installed WordPress since it is a waste to let a good yearly shared hosting idle.

After installation, I got this idea to limit access to the WP admin page. I use a VPN to make sure that the admin page can be able for me only.

For more information kindly read this article.

Hope it helps to some folks out there. :slight_smile: :smiley:

If you’ve got a second VPN/static IP at home/work/etc it’s worth adding that IP too, just incase you need to get on and your VPN is down.

Although you could always go in and remove the .htaccess file via the control panel I guess (unless that has the same IP restriction) :wink:

you are right. hehe. I believe you can add multiple allow in htaccess for a range of IP addresses. I haven’t tried that though.

Am I doing this right if I’m using Nginx? :thinking:

location ~ ^/(wp-admin)/
deny all;
} is your machine’s local ip. You cannot connect with that. Use your public IP address or Static IP If you have one.

I use the “Password Protected” Plugin. It also allows ip whitelisting :slight_smile:

Password Protected – WordPress-Plugin | Deutsch

I use Duo / Google Authenticator for two factor as well as locking down IPs :slight_smile:

1 Like

I prefer the VPN way. It saves a lot of CPU/RAM resources since your WP will not execute checking for valid IP connection which causes some I/O, RAM, CPU resources.

Using the VPN limit IP approach you to save some resources. Once Apache found that the connecting IP is not allowed. It will drop the connection thus saving you some CPU cycles (checking MySQL) and some RAM which can be used to serve other visitors.

Just make sure to add several VPN IPs or hope your vps/server/ip provider never changes it without you noticing.

I use ApisCP security :joy:
I keep Fortification on Max for the Wordpress install, meaning they can’t install shit. Althought they could add code to the pages :thinking:

@nem can you add some insight to this?


Enabling MAX mode is like UAC in Windows, it’s an added layer of authentication to restrict file uploads that’s enforced by traditional DAC permissions in the OS. Splitting permissions between the account owner and WP user makes it easier to establish audit trails, i.e. if a file is uploaded within WP directly without using FTP/SFTP, it’s tagged with a different UID than if it gets uploaded using FTP (Fortification mode on).

There’s a feature in the panel aptly called “Audit” that generates a list of such files or directories that have lax permissions.

On that topic too applying rules to deny PHP execution of /wp-content/uploads, /temp, and other media locations goes a long way in stymying drive-by hackers. Something as simple as this would work assuming mod_php,

 <DirectoryMatch "/(?:var/www|home/[^/]*)/.+/(.*/)?(?:wp-content/uploads/|wp-content/cache|cache/|sites/default/).*$">
    RemoveHandler .pl .py .cgi
    RemoveType .php
    AllowOverride None

In addition having some form of brute-force protection in front of /wp-login.php or any high-value URI (/xmlrpc.php also) is good insurance as those are typically abused. I run protection with a lower threshold against these URIs.

Most mod_security rules are overkill and getting applied non-deterministically to all URIs only hurts performance. One nice feature is the ability to pass all file creation to a third-party binary like ClamAV to determine if it’s clean. You can proactively block malware before it makes its way onto the server assuming another tool like fail2ban bans these IPs before they can do further harm.

Set reasonable worker limits and monitor outages through something like Monit. Limits are intended to prevent resource monopolization and alert you of extremes. Having 20 PHP-FPM pool processes on a site that normally uses 1-2 concurrently makes it too easy to mask problems.

WordPress plugins like WordFence that rely specifically on WordPress to work happen too late in the processing axis to be viable. If it’s all that you have, then it’s better than nothing, but in most single-user setups compromising one file elsewhere would allow an attacker to compromise WordFence. The only thing worse than being insecure is having a false sense of security. There’s performance concerns with it beyond this scope as well.

Above all the most important pieces of the puzzle:

  • Use cryptographically complex passwords

  • Always keep your plugins and themes up to date. If a plugin or theme doesn’t work with PHP 7.4 but does with 7.3, then it’s time to junk it as this hints at deeper problems in craftsmanship of that product. You wouldn’t buy a house from a carpenter that only leaks when it’s raining.

1 Like

I just use Cloudflare Access via Cloudflare For Teams :grin: