Entries Tagged as 'CFML'

Howto: Mass Rename File Extensions in Linux/BASH

Just recently I had a bunch of HTML files (files with a .html extension) that I wanted to rename to .cfm so that they would be interpreted by Railo. To do this, I created a quick BASH loop and ran it directly in the command line:

for i in *.html;
do mv $i `basename $i html`cfm;
done

The semi-colons at the end of the first two lines will tell bash that you want to enter more commands, and BASH will typically respond by giving you a new line with a greater-then symbol in front of it. So, the output of your loop will look something like this:

myserver $ for i in *.html;
> do mv $i `basename $i html`cfm;
> done
myserver $

The first line creates a "for" loop for every extension you want to change. In my case, since I wanted to change all files with the .html extension, I used .html. The second command creates a subshell (using the ` marks) and uses the basename program to remove the previous "html" entension. The subshell result is then passed back and used in our move command. For example, if you simply typed:

$ basename myfile.html html
myfile.

So the subshell is returning the file name plus a dot. Once that happens the second move command turns into this:

$ do mv $i myfile.cfm

... which is what gets looped over as many times as we need it to in order to rename all the files!

Hope this helps!

 

The Latest mod_cfml Update is Actually Pretty Important

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, like this levitra web, 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.

ddosThe 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.

Why the switch to mod_proxy from mod_jk?

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.

How To Block Access to Railo 3/4 Administrators in IIS 7 (security)

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:

railo-context directory in IIS 7

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.

select authentication in 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.

disable anonymous authentication

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

iis permission denied

 

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:

BonCode Connector Enable Remote Admin

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.

access from remote not allowed

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.

Testing For Headless Mode in ColdFusion (CFML)

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.

Java Thumbs Up LogoThe 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!