Read more about this book

(For more resources on WordPress, see here.)

IP deny with mod_access

Apache offers a sure-fire way to lock down admin, care of the mod_access module.

Similar to cPanel’s IP Deny Manager, the greater flexibility of hand-coding empowers us to allow or deny all but specified IP addresses, domains, hosts, and networks.

For now, we’ll prevent access to the wp-admin directory pages for all IPs except yours.

Open an htaccess file in your wp-admin directory via your control panel or the terminal:

nano /path/to/WP-root/wp-admin/.htaccess

Add these lines, swapping the IP for yours:

order deny,allow
deny from all
allow from 123.45.67.890

Need access from more IPs? Just add more alongside the first one, single space separated.

But. If your IP address is dynamic, which very often it is, you may find this method a little too effective. If you do become locked out, cruise server-side to switch the IP.

What is my IP?

That old chestnut:

• whatismyip – http://whatismyip.com

IP spoofing

A chestnut gone bad, denying alone won’t protect against man-in-the-middle attacks, so if you got this farthinking that you could have avoided all the SSL stuff after all, no, you were right to do that.

No safeguard is a silver bullet. Deny syntax sure helps though, if you’re not on the move.

 

Password protect directories

Password protection is a way to give access to a directory and its sub-tree to a selected few people and may be used, typically:

• To house private files to which you need access from anywhere
• By developers fine-tuning a new blog theme
• For a client zone on a commercial site
• As an extra layer of protection to, say, wp-login or phpMyAdmin

The procedure is to choose a directory, granting access to specified users. These privileged directory users are separate from, and should not be confused with, your server or WordPress users, the control being governed by Apache rather than by Linux or your WordPress database. That’s a good thing, adding an independent tier of protection.

cPanel’s Password Protect Directories

There are various ways to secure a directory, so let’s start off with the regular control panel option, which in cPanel, is called Password Protect Directories:

1. Browse to the target directory in File Manager, right-clicking and choosing Password Protect (or click through the panel icon if you like).
2. Select the checkbox and give the directory a name to appear on the authentication screen.
3. Save and you are redirected to a confirmation page.
4. Click back to the previous page and add a username and password to access the folder.
5. Save the newly authorized user.

Now you can surf to that folder or some file within, are asked for credentials, and can log in.

So what did we really just do there? Clicked on some shiny icons, added some details, and cPanel interacted a bit over far too many pages. Let’s get geeky, it’s worth it.

 

Authentication with mod_auth

When we protect a folder, cPanel uses Apache’s mod_auth module to amend or create two hidden files, htaccess and passwd. htaccess lives in the folder to protect and passwd lives safely above the web root in the hush-hush htpasswd directory.

Using an example file, we can compare our control panel actions with those using the terminal, interacting directly with mod_auth. Cue screenshots, using cPanel we did this:

And mod_auth creates the ruleset in the htaccess file, which we equally could just type:

AuthType Basic
AuthName "Protect me pretty please"
AuthUserFile "/home/USERNAME/.htpasswds/public_html/protectme/passwd"
Require valid-user

Then we did this:

And mod_auth yawns a bit while it adds credentials to a password file:

johndoe:L9c7m/hO16slA

(John’s password is encrypted, server-side, but he logs in using the plaintext hackth!s.)

Now then. Two points. First, with the syntax learnt or duplicated, it’s quicker to bin the middleman and just use the shell. More importantly, by directly chatting up Apache, we have a better array of security tools. To clarify, let’s take this a step at a time.

The htaccess file

Before we look at the mod_auth syntax that goes in htaccess files, a quick aside …

A quick shout out to htaccess, bless

We’ve met the hidden htaccess file already. It’s essentially a convenient and versatile web configuration file that can be added to multiple directories.

The directives these files contain can equally be placed in other types of files such as those for our virtual hosts (which is tidier, all those directives from htaccess files being in one place). Uniquely, however, rules added in htaccess can be parsed immediately, or in other words, without the need to restart Apache. Feel the power!

One other thing about htaccess: you don’t need root access to add or edit these files. Listen up, shared hosting people, this is very convenient because you don’t have root access (to hack into your co-sharers directories!) to those configuration files, but you do have access to your own jailed (or chroot-ed) web files. And because htaccess files live with your files, you can tweak them at will.

Now back to using htaccess to store that mod_auth syntax …

In this case, for any directory you want to protect, just add or append an htaccess file with your tailored mod_auth directives. Here’s a closer look at the mod_auth syntax, beginning with its type:

AuthType Basic

Pretty basic then and more on that later. For when we navigate to the login page we want some kind of instructional message:

AuthName "Protect me pretty please"

Now the link to the directory’s corresponding password file:

AuthUserFile "/home/USERNAME/.htpasswds/public_html/DIRECTORY-TOPROTECT/
passwd"

And we’ll specify to give access only to users recorded in the password file:

Require valid-user

So far so good. Carry on.

The passwd file

Often referred to as the htpasswd file, here’s the syntax it houses:

johndoe:L9c7m/hO16slA

johndoe is the authorized, or required user. L9c7m/hO16slA is the encrypted form of hackth!s , his password. We use a handy tool, also called htpasswd, to encrypt that.

Add as many usernames and passwords as you like to this file, each on a new line.

The file itself can live and be called whatever you like as long as the AuthUserFile directive corresponds. One thing though: the file should be located above your web root.