Blogging Techstacks

Suppressing the X-Powered-By Header in JBoss

Back before PCI, we used to be able to display things like the type and version of the web server software we were running on our sites.  We wanted everyone to know that we were using Apache or IIS or Netscape Enterprise Server.  We wanted to make sure that NetCraft could view that information, too.  Software writers, both commercial and open-source, easily accomodated our wishes, setting version information up right in the header.  For some, outputting this information in a Server header and footer page was not enough, so a new HTTP Header was introduced called "X-Powered-By".  Unfortunately, displaying the OS, Web, or App Server information is considered an information disclosure vulnerability now so we all need to now configure our servers so this information is not provided.

JBoss inserts an X-Powered-By header in every HTTP response header; typically providing juicy bits of information like the Servlet specification that JBoss complies with, the JBoss app server version number, a build number, and the version of tomcat or jboss web that the app server utilizes.  If you need to know how to suppress the X-Powered-By header in JBoss, read on and note that the technique varies depending upon the version of JBoss you are running.

JBoss 4.2.X

Suppressing the X-Powered-By header in JBoss 4.2.x can be done by modifying the web.xml file located in ${jboss.home}/server/${server.instance.name}/deploy/jboss-web.deployer/conf/.  For example, if you are using the 'default' instance and running jboss 4.2.3 from /usr/local, the path to the configuration file would be /usr/local/jboss-4.2.3.GA/server/default/deploy/jboss-web.deployer/conf/.  Locate the Common Filter Configuration line (line 25 on a stock 'default' server instance configuration file) and comment out the lines for the init-param, param-name, and param-value entries.  Example below

  <!-- ================== Common filter Configuration ==================== -->
    <filter>
       <filter-name>CommonHeadersFilter</filter-name>
       <filter-class>org.jboss.web.tomcat.filters.ReplyHeaderFilter</filter-class>
    <!--   <init-param> -->
    <!--      <param-name>X-Powered-By</param-name>  -->
    <!--      <param-value>Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807     181439)/JBossWeb-2.0</param-value>  -->
    <!--   </init-param>  -->
    </filter>

Restart JBoss and the header will no longer show up.

JBoss 5.0

The web.xml file that needs to be updated is located in a different location than with JBoss 4,2 but the technique is the same. To suppress the X-Powered-By header under JBoss 5.0, comment out the init-param, param-name, and param-value line entries from the web.xml located in ${jboss.home}server/${server.instance.name}/deployers/jbossweb.deployer/.

  <!-- ================== Common filter Configuration ==================== -->
    <filter>
       <filter-name>CommonHeadersFilter</filter-name>
       <filter-class>
          org.jboss.web.tomcat.filters.ReplyHeaderFilter</filter-class>
    <!--   <init-param>  -->
    <!--      <param-name>X-Powered-By</param-name>  -->
    <!--      <param-value>Servlet 2.5; JBoss-5.0/JBossWeb-2.1</param-value>  -->
    <!--   </init-param>  -->
    

Once you have made the configuration changes, restart JBoss so they can take effect.

JBoss 6.0

In order to suppress the X-Powered-By header in JBoss 6, you no longer make changes to web.xml files but instead modify the catalina.properties file included with your server instance.  Edit the catalina.properties file located in ${jboss.home}/server/${server.instance.name}/deploy/jbossweb.sar/.  Locate the property named: org.apache.catalina.connector.X_POWERED_BY and set its value to false.  Restart the server and you're all set.

---

Related Content
Tomcat/JBoss: Suppressing Server Identity - Part One
Tomcat/JBoss: Suppressing Server Identity - Part Two

Two New HOWTO's Added

I've added two new HOWTO documents to the Techstacks HOWTO Guides site.  They are search-engine friendlier posts pulled from this blog dealing with common administrative activities regarding the Apache Web Server and Tomcat/JBoss.  The two documents added are: 

1. HOWTO: Disable HTTP Methods in Apache
2. HOWTO: Secure SSL in Tomcat and JBoss

This brings the total number of HOWTO documents to ten!  Disable HTTP Methods in Apache is a fairly straightforward use of mod_rewrite rules to disable methods on a site.  Secure SSL in Tomcat and JBoss details what needs to be done to disable weak and anonymous encryption ciphers from a Tomcat (or app server derived from Tomcat) implementation.

Thanks a lot for visiting today!

JBoss: Clustered Node Startup Failures

As far as I can tell, JBoss clustering is based on functionality provided by another JBoss project called JGroups. We recently ran into an issue where half of our six identically configured application servers would simply not start. As the servers were all generated from the same base image, server configuration was not thought to be the culprit. All nodes were on the same subnet so we were a bit puzzled. In the logs on the servers, we same messages that looked like the following:

ERROR [org.jgroups.protocols.pbcast.GMS] [some_host:some_port] received view <= current view; discarding it (current vid: [some_host:some_port|4], new vid: [some_host:some_port|4])

and/or

WARN [org.jgroups.protocols.pbcast.NAKACK] [some_host:some_port (additional data: 19 bytes)] discarded message from non-member some_host:some_port (additional data: 19 bytes)

When setting up a cluster of jboss servers, even though the docs don't really require it, your network administrators will appreciate it when you place all these servers on the same subnet. This is because JGroups uses IP Multicast pings to maintain membership in the cluster and network administrators HATE IT when you multicast across subnets. When you have dual NICs in your servers set to fail on fault, it's really nice when the primary NICs on each box is plugged into the primary switch but it's even nicer when half of your boxes are plugged into switch A as their primary and the other half are plugged into Switch B as their primary. However, when half are plugged into one switch and the other half are plugged into another switch, you need to be able to pass multicast ip traffic between these two switches, which was the problem in our case. So, if you should happen to come across this condition, you might want to check to see if multicast IP is enabled on your switches and if your primary and secondary switches are passing multicast traffic between them.