Tomcat: Restricting Access by IP

This is the fourth in my series detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

A couple items have struck me in wading around in the Tomcat docs and configuration files: the flexibility and power of Tomcat, along with the fact that there are often multiple ways to do quite a few things when it comes to configuring Tomcat. Restricting access to applications and content available via Tomcat is no exception: there are at least three ways to accomplish this. For now, primarily in the interest of getting our dev environment up and running as quickly as we can, we’ll take the simplest approach. As with access logging, we’ll configure a valve within ./cfusion/runtime/conf/server.xml. This valve will restrict access to only requests coming from the localhost:

<Host name="localhost" ... >

See the docs for details on this valve, but it is very straightforward: just a regex identifying the IP addresses to be allowed. Requests from any addresses not listed in the allow attribute will be blocked.

Clearly, you’d not place such a restriction on a production box, but in a dev environment I typically do not want to allow access to other boxes under normal circumstances. You’ll note that this is an all-or-nothing approach; in reality, it is more likely that we will want to at least open access to specific folders for specific addresses occasionally. This approach won’t provide that flexibility but we will return to this topic for another approach later in this series.

Make the change shown above, bounce your server, and verify that access from other systems on your network are no longer able to access pages/apps on your dev box.

Tomcat: Configuring Access Logging

This is third in my series of posts detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

Access logging in Tomcat is fairly straightforward to set up, and the official docs are very understandable. The default configuration installed with ACF10 includes an entry for access logging in ./cfusion/runtime/conf/server.xml. Toward the bottom of the file, find the <Host> element and its child access log <Valve> element.

<Host name="localhost" ... >

Most of what’s shown there is easy to understand. A couple of items are worth touching on:

  • the pattern attribute specifies what gets logged for each request; as noted in the docs “common” and “combined” are short-cuts for standard sequences of commonly-used field
  • the fileDatePattern attribute is used to specify the naming mask for the log file; it also specifies the frequency at which the log files are rotated if the logs are specified as being rotatable. Where this mask goes to the day level, access logs will be specified each day.
  • I’ve temporarily set up the access logs to be created in the /tmp folder just for convenience as I work through configuring; I will change this to have the logs created in a more standard (and more secure) location as I get closer to wrapping this up.

Configure your logs as needed, restart the server, bounce a couple requests off it, and verify that the access logs are present and functional.

Tomcat: Disabling Directory Listings

This is the second in a series of posts detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

I will focus my initial configuration efforts on some basics for securing the Tomcat/ACF10 stack, addressing things I know the security scanning services on our network look specifically for. I will start with disabling directory listings provided by default when a browser requests a URL for a directory without a default document. In this post (and all future posts in the series, unless I specifically indicate otherwise), I will use paths based upon my installation of ACF10 in the default location on Mac OS X systems. By default ACF10 is installed in /Applications/ColdFusion10; you can translate as needed for your installation.

To disable directory listings, find the <servlet> element within file ./cfusion/runtime/conf/web.xml. Within that element, find (or insert) an <init-param> element with a child <param-name> element with a value of listings. Set the <param-value> element to false.


Restart the server, and we can check this one off our list.

Exploring Tomcat and ColdFusion 10

With the recent availability of a pre-release version of Adobe’s ColdFusion 10 CFML engine, I am going to be doing a bit of comparative exploring to see how this upcoming version lines up against the current 9.01 version. My intent is to install and configure ACF10 on one or more of my development systems in a manner where it can run alongside the currently-installed ACF9 so that I can get a feel, in particular, for any performance differences between these two versions and to ensure that when ACF10 is officially available, any compatibility issues with our CFML-based applications have been addressed.

My current development systems are Mac OS X and Linux boxes, running ACF 9.01 under Apache’s Web server. I will install ACF10 in a stand-alone mode in order to be able to run both servers concurrently. In this mode, ACF10 will be running with the bundled Apache Tomcat server for use as both its application server (replacing the JRun application server historically used with ACF) and as its Web server.

The first portion of this effort, then, will focus on getting ACF10 and Tomcat configured to function as needed in my development environment. With that in mind, I will be exploring the following Tomcat-related configuration needs and blogging about them (as well as anything else of interest I stumble into) in the coming days:

You can see that list is a mix of security-related settings and configuration settings related to how our application folders are structured (and the desire to run these applications through both the new Tomcat/ACF10 stack and the old Apache/JRun/ACF9 stack).

In terms of structure, all of the applications reside in a folder outside of the Apache webroot, and are found via a set of aliases. The folder structure below that top-level folder is set up as follows (with their corresponding application URL’s listed in parens):

  • appGroup1
    • common
    • app1a (http://localhost/app1a/)
    • app1b (http://localhost/appab/)
    • app1c (http://localhost/app1c/)
  • appGroup2
    • common
    • app2a (http://localhost/app2a/)
    • app2b (http://localhost/app2b/)
    • app2n (http://localhost/app2n/)
  • app3 (http://localhost/app3/)
  • shared

Within each of the application groups “appGroup1” and “appGroup2”, the “common” folder contains assets shared by the applications in the corresponding group; this folder is aliased into each of the individual applications within the group to appear as if it were nested below the application folder (e.g., http://localhost/app1a/common, http://localhost/app1b/common). All of the applications reference the “shared” folder as a root level folder “/shared” (i.e., as http://localhost/shared).

Further, most of the applications have a default document that relies on SSI to function properly as part of the applications’ respective authentication and security framework. I also do all of testing and prototyping in a folder immediately off of my home folder; I will need to have that folder served by Tomcat/ACF10 just as it is currently under the other stack.

Finally, a caveat: I am a complete noob when it comes to Tomcat, so I will be learning as I go. I am almost certainly going to find sub-optimal ways to make portions of the work. If you see such mis-steps and have recommendations for other and/or better ways, please point them out in the comments on each post.

We have our work cut out for us. Stay tuned.