Technical Stuff

Start from basics

Best Jboss Server Security Guide

Best Jboss Server Security Guide
Best Jboss Server Security Guide
5 (100%) 1 vote

Hello ! As decided, we are starting out the practical session on server security guide

Before going ahead with practical of hardening, if you haven’t read about Introduction to hardening and Part 1 of hardening.

Its my suggestion to first read that blog.

Now Let’s start with it.

Topics covered in this session.

  1. Upgrade Underlying components.
  2. Information Leakage/Disclosure.
  • X-PoweredBy.
  • Server Version.
  1. Custom Error Pages.

   4.    Encrypting Your Data Source Passwords.

 

  1. Upgrade Underlying components JbossWS

The most commonly overlooked item in securing jboss server is that developers and administrators tend to overlook upgrading the modules to latest.

Jboss server should be upgraded to the latest release but we know how difficult this can be.

If you cannot upgrade to the latest release, you should at the very least upgrade to the latest patch release. i.e if you are running the 5.1.0 EAP release you should be running Jboss EAP 5.1.1

The reason I brought up upgrading the components prior to carrying on with the securing server is if you were to upgrade these components later, you would have to start over with hardening Jboss (saves time)

If you followed my earlier suggestion of upgrading this component to the latest (depends on your version ) than you can change

Path :

$JBOSS_HOME/server/$context/deployers/jbossws.deployer/META-INF/stack-agnostic-jboss-beans.xml

Locate the same section but notice the difference in the comment, now you can set the property to "jbossws.undefined.host"

<!--   If 'webServiceHost' is set to 'jbossws.undefined.host', JBossWS uses requesters host when rewriting the <soap:address>

-->

<property name="webServiceHost">jbossws.undefined.host</property>

<property name="modifySOAPAddress">true</property>

Restart Jboss and now you wont have to worry about inadvertently exposing your internal RFC 1918 address.

 

  1. Information Leakage/Disclosure

In this section I will cover how to remove those pesky header responses which disclose the version of Jboss.

If we take a look at the below screenshot you can see just how much information you leak with the default setup.

 

 

  • X-Powered-By:

 

The best way to modify this is actually not to disable it but to change this to something more meaningful to you . To modify this setting the file(s) are located at

Path :

Jboss-4.2.X: $JBOSS_HOME/server/<profile>/deploy/jboss-web.deployer/conf/web.xml

Jboss-5.X.X : $JBOSS_HOME/server/<profile>/deployers/jbossweb.deployer/web.xml

 

Edit the web.xml file.

 

<!-- ================== 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.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CommonHeadersFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

 

Change the above highlighted in Bold to the name of your application and version number, or whatever you like, for the purpose of this we will change this to "CHAMGEME"

<!-- ================== 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>CHANGEME</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CommonHeadersFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

Save the file, restart Jboss Service and now you should see in the header response your version of the X-Powered-By as below in our example.

 

 

(ii) Now let's do the same thing for securing "Server" version. To do so you will need to modify the below file(s) depending on your version of Jboss.

Path :

Jboss-4.2.X: $JBOSS_HOME/server/$context/deploy/jboss-web.deployer/conf/server.xml

Jboss-5.X.X : $JBOSS_HOME/server/$context/deploy/jbossweb.sar/server.xml

Locate the Connector "8080" which is the default HTTP Port

Note: the below changes should be applied to all connectors in use otherwise the responses will be different

<Connector port="8080" address="${jboss.bind.address}"

maxThreads="250" maxHttpHeaderSize="8192"

emptySessionPath="true" protocol="HTTP/1.1"

enableLookups="false" redirectPort="8443" acceptCount="100"

connectionTimeout="20000" disableUploadTimeout="true" />

Add:
server="CHANGEME" so that the connector now looks like the below

<Connector port="8080" address="${jboss.bind.address}"

maxThreads="250" maxHttpHeaderSize="8192"

emptySessionPath="true" protocol="HTTP/1.1"

enableLookups="false" redirectPort="8443" acceptCount="100"

connectionTimeout="20000" disableUploadTimeout="true" server="CHANGEME"/>

After changing this a restart will be required in order for this change to take effect. As you can see below we have now modified the Server information in the response header info.

 

 

  1. Custom Error Pages

The problem of not setting custom error pages is that the default ones generated by Jboss leak some information as per the below, which would undo all of the work done so far.

So are you can see in Jboss 4.2.2 the default version of JbossWeb is 2.0.1 so having the above would leak that we are utilizing a version of Jboss.

To fix this change the following file.

Path :

Jboss-4.2.X: $JBOSS_HOME/server/$context/deploy/jboss-web.deployer/conf/web.xml
Jboss-5.X.X: $JBOSS_HOME/server/$context/deployers/jbossweb.deployer/web.xml

Go to the bottom of the page and add the below code just before the "</web-app>" tag

<error-page>

<error-code>404</error-code>

<location>/error/404.html</location>

</error-page>

<error-page>

<error-code>401</error-code>

<location>/error/401.jsp</location>

</error-page>

<error-page>

<error-code>500</error-code>

<location>/error/500.html</location>

</error-page>

 

  1. Encrypting Your Data Source Passwords

 

Here is a simplistic way to encrypt the password.

This utilizes a hardcoded password within the "SecureIdentityLoginModule" this is just better than using the default clear text password that is normally contained.

This module uses the blowfish cipher along with a derived key, again not the best solution but is recommended by Jboss.

I will explain later what the issue is with this solution

First edit your Data Source file, I will use my test mssql-ds.xml as an example

<?xml version="1.0" encoding="UTF-8"?>

 

<datasources>

<local-tx-datasource>

<jndi-name>MyDefaultDS</jndi-name>

<connection-url>jdbc:jtds:sqlserver://127.0.0.1:1433;DatabaseName=blah;charset=UTF-8</connection-url>

<driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>

<user-name>user</user-name>

<password>strongpassword</password>

<check-valid-connection-sql>SELECT 1</check-valid-connection-sql>

<metadata>

<type-mapping>MS SQLSERVER2000</type-mapping>

</metadata>

</local-tx-datasource>

</datasources>

 

Delete the user-name and password lines highlighted in yellow and add in the line below highlighted in yellow below.

<?xml version="1.0" encoding="UTF-8"?>

 

<datasources>

<local-tx-datasource>

<jndi-name>MyDefaultDS</jndi-name>

<connection-url>jdbc:jtds:sqlserver://127.0.0.1:1433;DatabaseName=blah;charset=UTF-8</connection-url>

<driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>

<security-domain>EncryptedDBPassword</security-domain>

<check-valid-connection-sql>SELECT 1</check-valid-connection-sql>

<metadata>

<type-mapping>MS SQLSERVER2000</type-mapping>

</metadata>

</local-tx-datasource>

</datasources>

Next you will need to add the "EncryptedDBPassword" security-domain to the login-config.xml
Note: the naming of the security-domain does not have to be "EncryptedDBPassword" it just has to be unique and match what is contained within the Data Source and login-config.xml files.

Edit: $JBOSS_HOME/server/$context/conf/login-config.xml

Add in the below section at the bottom just before the "</policy>" tag

<application-policy name="EncryptDBPassword">

<authentication>

<login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">

<module-option name="username">user</module-option>

<module-option name="password">11a2423091bbb7fda922a0652759a259</module-option>

<module-option name="managedConnectionFactoryName">jboss.jca:name=MyDefaultDS,service=LocalTxCM</module-option>

</login-module>

</authentication>

</application-policy>

 

The "managedConnectionFactoryName" MUST match that of your data source file if not you will have AUTH failures I highlighted the line in yellow .

Also you must create an Application Policy for EACH Data Source Entry.

So if you have two Data Source entries in one file you still need two application policies, on for each Data Source.

In order to generate the encrypted & base64 encoded password, you will need to run the below command from the $JBOSS_HOME directory.
Jboss-5.1.X Command :

 

[[email protected] jboss-5.1.0.]# java -cp client/jboss-logging-spi.jar:common/lib/jbosssx.jar org.jboss.resource.security.SecureIdentityLoginModule strongpassword

 

 

The output you should receive is below

Encoded password: 11a2423091bbb7fda922a0652759a259

 

Take the output of the above and place that in the login-config.xml file in the password section of your application policy or security-domain

Thank You !

Happy Learning !!!

If you have doubt or queries, you can definetely comment us or can mail us on [email protected]

 

If you have any recommedation for future blog, You can email us on [email protected]

 

Top Searches :

  1. Introduction to hardening in Middleware.
  2. Hardening In Jboss EAP 5.1
  3. Enable TLS1.2 in Jboss EAP 7
  4. VAPT – Enabling TLS1.1/1.2 in Jboss
  5. VAPT – DISABLING HTTP METHODS
  6. VAPT – HOW TO REMOVE APACHE COYOTE VERSION FROM JBOSS
  7. INSTALLATION OF JBOSS ON LINUX
  8. INTRODUCTION TO JBOSS
  9. INTRODUCTION TO MIDDLEWARE
  10. Thread Dump
  11. Heap Dump.

 

 

Leave a Reply

%d bloggers like this: