Control server access: Prompt for credentials (basic auth) on approved networks, allow access to itself, and deny everyone else

To get a site feature from development to production, it goes through four servers:

  1. Development
  2. Quality Assurance (QA)
  3. Staging
  4. Production

Except for the development server, which is localhost, there are times people, other than developers, need access to view a particular site on the QA or staging server. In addition, sometimes you need to test your site externally, whether it’d be a mobile device not connected to the network or an external, automated service. This means that the aforementioned servers need to be publicly accessible, but without being accessible to just anyone.

1. Using basic authentication

The first thing that comes to mind is basic authentication. It’s quick and easy to setup, and it solves the authentication problem, albeit not being the securest option. To implement this, you’d put this in your virtual host file:

1
2
3
4
5
6
7
8
<Directory />
    AuthType Basic
    AuthName "Restricted Area"
    AuthBasicProvider file
    AuthUserFile /var/www/htpasswd/users
    AuthGroupFile /var/www/htpasswd/groups
    Require group groupname1
</Directory>
<Directory />
	AuthType Basic
	AuthName "Restricted Area"
	AuthBasicProvider file
	AuthUserFile /var/www/htpasswd/users
	AuthGroupFile /var/www/htpasswd/groups
	Require group groupname1
</Directory>

2. Setting up permitted users

The user file can be created with something like this:

1
[root@vps ~]# htpasswd -mbc /var/www/htpasswd/users username1 password1
[[email protected] ~]# htpasswd -mbc /var/www/htpasswd/users username1 password1

If you open the users file, you’d see something like this:

username1:$apr1$yP7cevF2$xADK1ANX1XAkqX6uUn.Jj/
username2:$apr1$hfg6JwM7$/mqaQz7aeHryib4EvtxIc.

3. Placing users into groups

You’ll want to assign users to groups, which allows you to approve multiple users without having to reference them individually over and over. You can do this by creating a file with the following contents:

groupname1: username1 username2

Group name followed by space-separated usernames.

4. Dealing with requests to itself

The biggest issue with basic authentication, in my opinion, is that requests to the site originating from the site or server, like a cron job making a cURL request, for example, will now fail unless you also pass a set of credentials in the request, and depending on your application, this may be a huge inconvenience.

[[email protected] ~]# /usr/bin/curl "http://qa.domain.com"
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>

So to get this to work, you’d add credentials to the request:

1
[root@vps ~]# /usr/bin/curl "http://qa.domain.com" --user username1:password1
[[email protected] ~]# /usr/bin/curl "http://qa.domain.com" --user username1:password1

5. Whitelisting the host

To get around having to provide credentials, you could extend your authentication to either provide credentials or be whitelisted. That would look something like this:

1
2
3
4
5
6
7
8
9
10
11
<Directory />
        AuthType Basic
        AuthName "Restricted Area"
        AuthBasicProvider file
        AuthUserFile /var/www/htpasswd/users
        AuthGroupFile /var/www/htpasswd/groups
        Require group groupname1
        Order Allow,Deny
        Allow from 111.111.111.111
        Satisfy any
</Directory>
<Directory />
        AuthType Basic
        AuthName "Restricted Area"
        AuthBasicProvider file
        AuthUserFile /var/www/htpasswd/users
        AuthGroupFile /var/www/htpasswd/groups
        Require group groupname1
        Order Allow,Deny
        Allow from 111.111.111.111
        Satisfy any
</Directory>
  • Order: Whether to allow or deny access by default (using deny here).
  • Allow: Which host can access the site.
  • Satisfy: Whether to require credentials and coming from a whitelisted host, or whether one of the two is sufficient.

6. Moving authentication configuration into an include file

I like things easy and global, which means I’ll most likely put this in an include file so that I can force authentication for an array of sites using different virtual host files, but then only have to update the list of groups and IP address in one file. I’d then include a default authentication configuration in the virtual host files that need it:

1
Include vhosts.d/includes/basic_authentication_master
Include vhosts.d/includes/basic_authentication_master

7. Permitting requests to itself, but requiring valid host and credentials from users

Now, since basic authentication is so simple and insecure, I thought about adding an additional layer. What I was looking for was something like: if the request comes from the server, allow it, otherwise ensure request comes from a whitelisted host, and then still ask for credentials.

Unfortunately, I couldn’t think of a way to implement this using just basic authentication, because Apache’s Satify directive can either be set to any or all, with no condition attached.

To get around this, I placed a rewrite rule above the basic authentication. The rule says to redirect to the main site if the host is not whitelisted:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
RewriteEngine on
RewriteCond %{REMOTE_HOST} !^111\.111\.111\.111
RewriteCond %{REMOTE_HOST} !^222\.222\.222
RewriteRule / http://domain.com [R=302,L]
 
<Directory />
        AuthType Basic
        AuthName "Restricted Area"
        AuthBasicProvider file
        AuthUserFile /var/www/htpasswd/users
        AuthGroupFile /var/www/htpasswd/groups
        Require group groupname1
        Order Allow,Deny
        Allow from 111.111.111.111
        Satisfy any
</Directory>
RewriteEngine on
RewriteCond %{REMOTE_HOST} !^111\.111\.111\.111
RewriteCond %{REMOTE_HOST} !^222\.222\.222
RewriteRule / http://domain.com [R=302,L]

<Directory />
        AuthType Basic
        AuthName "Restricted Area"
        AuthBasicProvider file
        AuthUserFile /var/www/htpasswd/users
        AuthGroupFile /var/www/htpasswd/groups
        Require group groupname1
        Order Allow,Deny
        Allow from 111.111.111.111
        Satisfy any
</Directory>

Once the request makes it passed the rewrite rule, the previously setup authentication scheme will follow suit.

As an added benefit, if anyone attempts to visit the site on the QA or staging server, it will redirect them instead of prompting for credentials, which makes the whole thing even less obvious.

Conclusion

It meets all of my goals, which is making it easy to implement and manage, and it provides reasonable protection from someone accidentally stumbling on the site or someone attempting to view the site when they shouldn’t.

As always, use your judgement to determine whether this solution is right for you, and if you have any questions or suggestions, leave them in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *