Methods To Lock Down WordPress wp-admin, and Accessing it Using SOCKS5 Proxy
It’s as simple as this: have SSH listen on the standard port 22, and when you check your server logs, you see all sorts of random people trying to login to your server. Same thing goes for any content management system with an obvious admin URL. A good example is WordPress. Unless you do some voodoo hacks to change the location of URLs, it can be accessed from example.com/wp-admin or example.com/wp-login.php
The htpasswd way!
The easiest thing to do is lock down the wp-admin folder with an htpasswd On Apache you follow a similar directive.
It’s even easier on a shared hosting environment. Simply login to the Web host’s admin console, fire the app icon that says something similar to “password protect directories”, password protect the wp-admin directory, and you’re done. From next time on, when you go to example.com/wp-admin it will prompt for a second layer of authentication before it brings up the WordPress login screen
This is good enough for most cases, however, it still doesn’t stop people from accessing example.com/wp-login.php, because the wp-login.php file is on the root of WordPress directory. (Note that in this case, once WordPress authentication is successful, it will still throw the htpasswd authentication pop-up before redirecting you to wp-admin.) Naturally, it makes many of us uncomfortable seeing people trying guess work.
Let’s take an easy example. Install the Limit Login Attempts plugin (it helps you set a limit to the number of failed logins from a particular IP address, and based on that bans it for a set period of time).
What’s interesting is you still see access attempts from random IPs even after setting the htpasswd… because from example.com/wp-login.php, the htpasswd kicks in only if the WP authentication succeeds (as I mentioned).
Open the settings page of Limit Login Attempts plugin and you can see total lockouts .
So, people can keep the guess-work business going as long as they keep changing their IP address after Limit Login Attempts bans their IP for a time frame.
The real obvious thing to do is password protect the wp-login.php file too. The downside is, the admin console of a shared hosting service most probably won’t have a dedicated application to handle that — the “Password Protect Directories” app seems to be only good for, well, directories.
The clue lies in the wp-admin/.htaccess file that app creates. Fire your Web host’s file manager application, open that file — it should look somewhat like this:
AuthType Basic
AuthName "protected area"
AuthUserFile /path/to/.htpasswd
AuthGroupFile /path/to/.htgroup
Require group myNewGroup
Require user myNewUser
Why not use the same username/password to protect wp-login.php. Open .htaccess file on the root directory of WordPress and append the following in it:
<Files wp-login.php>
AuthType Basic
AuthName "protected area"
AuthUserFile /path/to/.htpasswd
AuthGroupFile /path/to/.htgroup
Require group myNewGroup
Require user myNewUser
</Files>
Simple, isn’t it?
This way we save the unnecessary processing load on PHP and MySQL for unauthorised access requests. However, the Web server connection remains open (for a while, at least) for htpasswd authentication.
Apache .htaccess when you have a static IP
What is we want the Web server to close the connection with an error as soon as it detects an unauthorised access — bypassing the password prompt?
The job becomes a bit easier if you have a static IP address from where you always login. Then by appending the following directives in .htaccess files of WP’s root directory:
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from xx.xx.xx.xx
</Files>
…and wp-admin subdirectory:
Order Deny,Allow
Deny from all
Allow from xx.xx.xx.xx
…(where xx.xx.xx.xx is your dedicated IP) you take care of the issue.
Well, if you don’t have static IPs (in case of most DSL broadband connections) or you need to login from different places (office, home, friends’ place, etc.), this is not a solution, is it? (Yes, you can login to your Web host’s backend and keep changing/appending the the new IPs in the .htaccess files, before making a pass at the WP login — a major pain in the neck, I would say.)
But this, or the htpasswd method, is the best you can do on shared hosting environments, unless your Web host also gives you SSH access.
Using Socks5 proxy
We’ll create a SSH tunnel, and use it as a socks5 proxy for Firefox to tackle the situation.
ssh -C2qTnNv -D 8888 username@example.com
After you authenticate with your password, it won’t return you the prompt (like you’d expect from a typical ssh connection.) The argument that’s important is -D 8888, which basically tells ssh to create a tunnel between port 8888 of your localhost (127.0.0.1) and the IP address of example.com. We also added the verbose mode with the -v so that we can see all activities on the session.
<<SNIP>>
debug1: Next authentication method: password
user@example.com's password:
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (password).
Authenticated to example.com ([xx.xx.xx.xx]:22).
debug1: Local connections to LOCALHOST:8888 forwarded to remote address socks:0
debug1: Local forwarding listening on ::1 port 8888.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 8888.
debug1: channel 1: new [port listener]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
<<SNIP>>
Now before we can use this tunnel to access WP login (or generally visit websites), we need to set the proxy in Firefox. Go to the browser proxy settings dialogue and enter the IP details.
-------
Cheers
