The ColdFusion and Lucee Lockdown Guides recommend that access is restricted to all administrative areas of the server. This is especially important to do because many security vulnerabilities have been discovered that exploit open access to admin directories. It is fairly easy to accomplish, using a directive in the Apache configuration for example. It would look something like this on ACF:

1
2
3
4

<Location /CFIDE>
  Order Deny,Allow
  Deny from All
</Location>

or this on Lucee:

1
2
3
4

<Location /lucee-context>
  Order Deny,Allow
  Deny from all
</Location>

So far so good, but now anyone needing to administer the server can’t login. They will be denied access by the web server. There are various recommendations for allowing only selective access, for instance from a given fixed IP address at the office of the administrator:

1
2
3
4
5

<Location /lucee-context>
  Order Deny,Allow
  Deny from all
  Allow from 84.16.156.99
</Location>

But what if the server administrator(s) is/are out of the office when they need access to the server? Away at a conference, at a client’s office, or at home? And what if your office doesn’t have a fixed IP address? Should you get one … and then have to remember to change the “allow from” IP address in all of your server configuration files if and when that IP address changes? For a variety of reasons, this doesn’t seem ideal.

There’s another “small” problem here. Best security practice dictates that all access to admin areas should be over an encrypted connection. I cannot ensure that the modem installed here in my office, or wherever else I happen to be when needing to admin my servers, a hotel for instance, is not compromised by a packet sniffer. In fact, I recently installed an update on our modem here specifically for a packet sniffing vulnerability, and I only ran across it by chance. No idea how long that remained unpatched, and I’m simply not prepared to invest the time to learn how to monitor this sort of thing. This implies that I definitely should install SSL certificates and set up secure https access for all administrative areas on each server I maintain. That’s painful.

Put all that together, and it helps to explain why ACF and Lucee servers are often not locked down.

Here’s where SSH tunneling comes to the rescue. In a nutshell, it allows you to securely browse a remote server as localhost, as if the server was under your desk and your keyboard and monitor where connected to it, even if it’s located halfway around the world. The icing on the cake is it is very simple to set up, and the same setup will work for every server you admin!

To use SSH tunneling to gain access to admin areas of your server, the first step to restrict access to any admin area to only localhost, for example:

For ACF:

1
2
3
4
5

<Location /CFIDE>
  Order Deny,Allow
  Deny from All
  Allow from localhost
</Location>

or for Lucee:

1
2
3
4
5

<Location /lucee-context>
  Order Deny,Allow
  Deny from all
  Allow from localhost
</Location>

( While you are at it, restrict port access to only those ports you need to leave exposed, for instance 80, 443 and whatever port you are using for SSH access ).

There are detailed instructions for SSH tunneling all over the web if you want to find out more, but the instructions below should work fine for our purposes.

1. In your web browser, configure the proxy settings to point to “localhost”, a free port on your local machine (we’ll use 60001), using SOCKS5. This should work with any browser. Using Firefox as an example, here’s how to do that:

   • Go to Preferences
   • Click the Advanced icon
   • Click the Network tab
   • Click the Settings button, across from where it says “Configure how Firefox connects to the Internet
   • Select Manual proxy configuration
   • In the SOCKS Host field put “localhost” without the quotation marks
   • In the Port field put the port number you will use, 60001 in our example
   • Select SOCKS v5
   • Click OK

2. ssh into any server you admin using Terminal or Putty, etc. Use the -D flag set to the same port as above, example: ssh -D 60001 user@102.103.108.39

3. You can now access admin areas of the server in this browser using localhost urls such as http://127.0.0.1/CFIDE/administrator/enter.cfm, as long as you remain logged in via SSH. The connection is through an SSH “tunnel”, so between your local machine and the server, all traffic is encypted.

Note that the port chosen is arbitrary. It only has to be available and match in both the -D flag and SOCKS port setting. To revert the browser to normal behavior, simply choose No Proxy in the Network Settings dialog.

What I usually do is leave Firefox configured in this way and reserve it only for SSH tunnelling sessions. And again, once a browser is configured with these proxy settings, you can securely browse any server as localhost by SSH’ing into it with the -D port setting.

Now say you have Fusion Reactor installed and want to ensure access is also restricted. Just leave your firewall configured to leave the ports Fusion Reactor uses closed, and access it, securely, via your SSH tunnel!

Thanks to David Stockton, who until recently worked with the fusion reactor team, for sharing this tip with me.

IMPORTANT NOTE: If you have difficulty logging in, or maintaining a login, particularly to the ACF admin panel, clear the cookies in the browser you are using for SSH tunneling and try again.

In my case, I ran into this after using this technique to manage multiple instance of ACF, particularly on ACF 11. I could log in to the admin panel successfully, but if I tried to modify anything, set a datasource for instance, I was logged out and the action did not complete. The error log contained the message “There was an error while verifying the token. Either the session timed out or un-authenticated access is suspected.”