« September 2008 | Main | November 2008 »

7 posts from October 2008


JBoss: Changing Default Port Numbers

It is not uncommon to have multiple containers running on the same server in a production environment. I recently needed to deploy a JBoss Application Server instance onto a set of hosts that were already running a production tomcat application and development wanted separate containers. The production tomcat-hosted application was already listening on ports 8009 and 8080, so jboss was not going to be able to listen on those ports unless I assigned a second IP to the servers. If you are load-balancing multiple app servers, setting dedicated IP addresses for second instances of an application container can feel a bit wasteful. Keep in mind a couple things here though.

First off, the JBoss Wiki implies that the preferred mechanism for doing this actually does involve setting a second IP address on the box and executing your new instances run.sh|bat script with the -b switch. This binds that IP address to the second instance and uses all the default ports. In contrast though with what the wiki recommends, and in my world at least, changing the ports involves less people and less time. Less explaining as well to the LAN guys to justify getting those IPs, no tickets requesting DNS entries, etc.

Instructions for changing port assignments in JBoss depends upon the version you are running. Articles detailing changes for JBoss Application Server 4.x and for JBoss Application Server 5.0 are included on this site.

Buy the Book: JBoss in Action: Configuring the JBoss Application Server


Apache 2.2.10 Released

The Apache HTTPd project released version 2.2.10 of the apache web server. The release announcement indicates that a vulnerability in mod_proxy_ftp that could result in cross-site scripting attacks was fixed. In addition to this, the ChangeLog  also indicates that many bug fixes are also included in this release.

Download binaries and/or source at the mirror  closet to you!


TRACE Method Handling - Disabling TRACE

I have many articles posted on this blog for handling http trace methods. Since they are amongst the most popular on this site, I thought it would be helpful to consolidate them into something better suited for reference. Also, since it is a vulnerability that frequently turns up on PCI Compliance scans, I thought it would be useful to provide one base page that searches can be directed to. Less page views for me but hopefully easier searching for everyone else.

To start, I updated the ruby script I wrote to test to see how a site responds to HTTP TRACE requests. The previous script can be found here and below is the update:

#!/usr/bin/env ruby
require 'net/http'

puts "\nEnter the URL for the site"
puts "(Format should be 'http://siteURL/')"
name = gets

url = URI.parse(name)
req = Net::HTTP::Trace.new(url.path)
resp = Net::HTTP.start(url.host, url.port) {|http|
puts "Your iRule Works!! Connection Dropped!"

# Case statement - delivers response based on status code
# returned from site assuming irule not used or needed
statuscode = resp.code
result = case statuscode
when "200": "TRACE is **probably** enabled"
when "301": "Site is responding with a 301 - Redirect for \"/\""
when "302": "Site is responding with a 302 - Redirect for \"/\""
when "403": "TRACE is disabled. 403 Forbidden"
when "404": "TRACE is probably disabled. 404 Not Found"
when "405": "TRACE is disabled. 405 Method Not Allowed Response"
when "501": "TRACE is disabled. 501 Not Implemented Response."
else "Unexpected Response."

From what I've learned in my research over the past few months as well as experimentation on my own sites, you can expect several different types of responses to TRACE requests based upon site platform and site layout architecture.

If you are running IIS4 or IIS5 or any version of Apache, by default the TRACE method is enabled. The best way you can disable it in IIS4 and IIS5 is by installing URLScan. Remediation in apache can be done in two different ways. One method involves setting the TraceEnable directive to Off. This only works if you are running a more recent version, (Apache 1.3.34, 2.0.55 and later). The other mechanism that works on all apache versions that support mod_rewrite involves writing a condition and rule to forbid trace requests:

RewriteEngine on 
RewriteRule .* - [F]

If you are running IIS6 or IIS7, the TRACE method is disabled. If you are running Tomcat, Glassfish, or JBoss Application Server as the front-end for your sites, the TRACE method is disabled by default. The status code returned by IIS6/7 is different from tomcat, however. IIS responds with a 501 status code while tomcat responds with a 405 status code.

If you load-balance your websites with a BigIP, you can write an iRule that will discard all TRACE methods and assign that rule to all of your VIPs. A basic iRule that drops TRACE requests looks something like this:

set default_pool [LB::server pool]
if { [HTTP::method] equals "TRACE" } {
} else {
pool $default_pool

The action that the rule takes when the condition is met is to drop the packet. From a network sniffer standpoint, you will see the BigIP issue a connection reset when a TRACE request is sent to a VIP that is utilizing this particular iRule.

The script above allows me to determine which of my sites are vulnerable to TRACE requests and, depending upon the remediation steps taken, gives me a mechanism for validating those changes. Since all of my sites are front-ended with a BigIP, I can simply utilize the iRule to drop those requests and validate by trapping the connection reset but with the addition of better handling of responses pre- and post-remediation, the script becomes more portable to validate remediation actions for a larger number of possible site configurations. Want to validate that apache is responding as expected after setting TraceEnable to Off? This should do it. Do you want to verify that URLScan is working? This script should do it.

The script should not follow redirects, which is helpful in false-positive determination. However, when a redirect is issued, you should re-run the script against the redirect target. In other words, if "http://yoursite.yourdomain.com/" redirects to "http://yoursite.yourdomain.com/home/", running the script against the former should result in either a 301 or 302 response. So, execute the script against "http://yoursite.yourdomain.com/home/" directly instead.

Instead of coming out with a page for each platform and another page for updates, this page will serve as the anchor page for TRACE and any updates will be made directly to this page instead. All the other pages will be updated to link to this one.