Understanding the Dream

For those of you who may not follow these things, users of the open-source CFML context creation software known as "mod_cfml" should know that the latest release is actually pretty important with regards to security. The mod_cfml software is a group of programs that work together in order to automate the process of creating contexts within Tomcat. Usually the process of creating contexts is a manual job, which is accomplished by editing various configuration files in order to tell Tomcat where to find the files for specific sites and directories (or contexts) when Tomcat receives requests for them. The idea behind mod_cfml is to simplify server management, and make creating contexts in Tomcat happen automatically by passing off configuration information from Apache or IIS to Tomcat so a new context can be made if it doesn't exist yet. Pretty basic stuff.

The problem is that, before this latest release, this process of automating the context creation using mod_cfml could be exploited to create a Denial of Service attack on the system that is running mod_cfml. Using a specially crafted attack that is targeted at mod_cfml, an attacker could potentially issue multiple requests in rapid succession to a vulnerable system. This process would cause many contexts to be created simultaniously, and could potentially overload and/or crash the server.

The newest version of the mod_cfml Tomcat Valve corrects this problem by adding limitors to how quickly new contexts could be created, and how many contexts can be created within a single day time frame. These limitors protect users from the danger that previously existed and the possibility of a DoS attack that specifically targets this issue.

You can install the latest mod_cfml Tomcat valve by shutting down Tomcat, removing the mod_cfml Tomcat valve from the [tomcat]/lib/ directory, and dropping the latest mod_cfml Tomcat valve back into the [tomcat]/lib/ directory. Now, restart Tomcat and you're good to go. Documentation on adjusting the new limitors in the Tomcat valve can be found here:

http://www.modcfml.org/index.cfm/documentation/modcfml-tomcat-valve/config-options/

Railo users who have installed Railo 4.0.3 or newer will already have the latest version of mod_cfml, and OpenBD installers version 3.0 and up will have the latest release. If you are running with an earlier release and haven't updated your mod_cfml Tomcat Valve, you should consider doing so.

I've talked about this a lot in various places, but because I expect to get a few questions about this, I want to create a post where I could fully explain the decision to move from mod_jk to mod_proxy. As of Version 4 of the Railo Installer, mod_proxy_http will be configured by default in Linux Apache installations.

Current Installs Will Continue to Function

If you're comfortable using mod_jk, then there's no reason for you to migrate any of your existing installation to mod_proxy. mod_jk will continue to work just fine with Railo and Tomcat for as long as the Tomcat developer community continues to develop and improve mod_jk. There is no reason to switch if you're comfortable where you are.

Mod_proxy is Simpler to Configure

There are sevaral points to make within this overall "mod_proxy is simpler" point. First, it should be noted that mod_proxy is installed by default in nearly all modern Apache installs. Even Windows version. So as far as "installing" mod_proxy goes, it's incredibly easy because in most cases it's already there! Second, mod_proxy is configured purely by a few commands within the Apache configuration file. Mod_jk has several different configuration files you have to work with. These additional files are the cause for much confusion among users about what to edit, when to change it, and what to change it to in order to do what you want. Once you know the purpose of each file for mod_jk, it's really not very difficult, but it can be daunting to try to figure it out, or if you're on an unfamiliar system, find where those specific files are located. With mod_proxy, you can simply look at the proxy rules, and generally have a pretty good idea of what's going on without having to track down and review separate configuration files.

Mod_proxy is Recommended by Tomcat Dev Team

This article describes in detail the differences between the current connection methods: http://www.tomcatexpert.com/blog/2010/06/16/deciding-between-modjk-modproxyhttp-and-modproxyajp

Note that the article was written by Mark Thomas, a member of the Apache Foundation and Tomcat Developer.

Mod_proxy Fits Better into Future of CFML

There are many features that would be very useful when connecting Apache to Tomcat with regards to the CFML development language. For example, it would be nice if users could have some built-in support for Search Engine Safe URL's without having to add complex mappings to their Apache configurations. It would also be nice to have the ability for Apache to pass on certain aspects of its configuration to Tomcat from within the HTTP protocol. Work in that area has started with the mod_cfml project, but it would be great if mod_cfml could run as a native Apache module instead of as a mod_perl module. Mod_perl is fantastic software, but some users resent having to install it in order to get mod_cfml working in Apache.

With mod_proxy, we can extend mod_proxy's existing functionality and add our own - in much the same way that mod_proxy_ajp and mod_proxy_html extend the base functionality of mod_proxy, we could potentially create a mod_cfml module that is simply an extension of mod_proxy where basic support for CFML pass-throughs are built in directly to the module. This would make installation and configuration even easier then it is currently.

We work a lot with Railo over at Vivio. Railo is an open-source CFML processing engine and offers it's users a built-in web-based "Administrator" for the server as a whole and for each web site that is configured to use it. This blog post will review a couple ways to secure those administrators from prying eyes. Yes, the administrators are password-protected by default, but adding the following will provide yet another layer of security for your sites.

Method One: IIS (site-specific)

The first security method we'll review will use the built-in access controls provided by IIS 7. I'll be using Windows 7 and the IIS Default Website. This method will need to be implemented on each separate site you want to secure.

Start out by going to your site's root directory. Since I'm using the "Default Site" in this example I'll go to C:\inetpub\wwwroot. From here, create an empty directory called "railo-context". The directory itself doesn't matter, only it's name and the permissions we will assign to it. In fact, once the rule is in place, you can actually DELETE the physical directory and the permission rule will remain in place in IIS. The rule is in the web.config for the site, so you can edit it there as well if you want.

Now that the directory has been created open the IIS Manager, and select the site that you're securing. You should see your new "railo-context" directory that you just created listed there:

Next, make sure that the "railo-context" directory is selected and then hit the "Authentication" icon. If you do not see the "Authentication" icon, you will need to go to "programs and features" and make sure that feature is enabled for IIS.

Now we're going to disable "Anonymous Authentication" in IIS. This is what allows interenet users to connect to our sites. Without this authentication enabled for our "railo-context" directory, visitors from the internet will not be able to connect to it.

Now lets test it. Looks like we're good to go!

Method Two: BonCode Connector (server-wide)

The next method we'll review is securing the administrators by using the BonCode Connector. The BonCode Connector has been used by default since Railo 3.3.2, and is installed "globally" by default. This method will block access to the administrators by any connection made through the BonCode Connector - which is nice because you don't have to worry about it for every site you make. If you installed the BonCode connector on your own and did not install it globally, then you will need to configure the BonCode Connector by way of the site-specific config files in the BIN folder of each site. This negates some of the convenience of this method, but it still gets the job done.

Start out by opening a copy of Notepad as the administrator user. This will give you the permissions you need to edit the file. To do this, find the "Notepad" icon in the start menu and right-click it, then select "Open As Administrator". This will open notepad in administrator mode.

From there, if you installed the BonCode connector "globally", or if you installed Railo using a Railo Installer version 3.3.2 or greater, open the following file: C:\Windows\BonCodeAJP13.settings.

Once you have the file open, change the "EnableRemoteAdmin" value to "False", as illustrated below:

Now restart IIS and try to hit the admin URL from a remote machine. Notice how hits from the local IP will pass through this method, but hits from a remote machine will get the "Access from remote not allowed" error message.

IMPORTANT:

It is important to remember that the Railo Administrators will still be available when you use the Tomcat web server on port 8888. To block access to that from remote machines, simply use the built-in Windows Firewall and restrict access to port 8888 to only local access.

Just recently I found myself needing to verify if a server I was working on - which required image manipulation - was actually running in headless mode. On Linux servers, graphical user interfaces (GUI's) aren't usually running because they take up additional resources (like memory) and server administrators usually want to give all the resources they can to actual server processes rather then a GUI which they only use occasionally. However, the JRE that ColdFusion engines run on needs the window processing engines in order to perform graphic manipulation - image resizing, rotating, etc - all require image processing libraries.

The following code bit allows you to see if your CFML engine (Railo, OpenBD, or ACF) is actually running in headless mode. This is useful if you're debugging a pesky image processing problem and you want to make sure your JRE's access to the XORG libraries aren't the problem.

<cfobject  
    action=create  
    name=geObj
    type="JAVA"  
    class="java.awt.GraphicsEnvironment">
<cfset geResponse = geObj.isHeadless()>
<cfdump var="#geResponse#">

The code calls java directly and returns a true or false response if you're running in headless mode or not.

Hope this helps!

Recently I had the opportunityto work with someone who was trying to use the Vivio Installers for Railo and OpenBD on a W2K8r2 Cloud/VPS system running the Plesk Control Panel and they were having trouble getting the connector to work right. The problem they were encountering was the notorious "Calling LoadLibraryEx on ISAPI filter isapi_redirect-(version).dll failed" error. Usually this error means that you're trying to run a 64-bit connector on a 32-bit machine, but since this was W2K8r2, which ONLY comes in 64-bit, this had me stumped for a little bit.

After some digging, I found that Plesk had updated the IIS7 application pools to actually run in 32-bit mode because Plesk's own DLL's were in 32-bit. I found this out by changing the application pools to disallow 32-bit, and then plesks DLL's stopped working. The IIS7 settings are a bit misleading in this area too. The option in IIS7 is to allow 32-bit DLL's, but when you set that, ONLY 32-bit DLL files can run. Instead of "Allow 32-bit", I think the IIS7 setting should say something along the lines of "run in 32-bit mode. Otherwise it sounds like you can run both 32-bit and 64-bit, which you can't.

The Railo and OpenBD installers use the mod_jk DLL that's provided by the Tomcat project, and both the 64-bit and 32-bit versions are shipped with the installers. During the install process, one of the DLL's is renamed with a generic name and used in the IIS7connect.bat scripts. Those scripts are what run the commands and connect Tomcat to IIS using the mod_jk DLL. This works out in our favor, as it makes the fix for this really easy.

When installing OpenBD or Railo on a Windows 2K8 R2 machine that's running Plesk, here are the steps you will need in order to make it work right:

1. During the Railo/OpenBD install process, go ahead and select to have the IIS7 connector installed. This will perform the bulk of the work for you.
2. After the installation, there will be two dll's in the "connector" directory where you installed Railo. The default location to install Railo is c:\railo\ so the connector directory is located by default at c:\railo\connector. The connectors will be named isapi_redirect-1.2.30.dll and isapi_redirect-1.2.30.32-bit.dll
3. Rename isapi_redirect-1.2.30.dll to isapi_redirect-1.2.30.64-bit.dll
   and
   Rename isapi_redirect-1.2.30.32-bit.dll to isapi_redirect-1.2.30.dll
4. Now Restart IIS, and restart the Tomcat service that Railo or OpenBD is running on.
5. Check to see if things are working correctly now.

Further, a "jakarta" virtual directory will be required in each site as we

ll. You'll more then likely have to add this manually to IIS. Documentation on how to add the Jakarta directory is here:

http://trac.getrailo.org/installers/wiki/VivioInstallerWinAddingSites

Future releases of the Windows installer will probably allow for the manual selection between 64-bit and 32-bit, but the option will defauilt to whatever your system type is. That way it's still easy, but allows for some customization for situations like this.