- Purpose of this Guide
- Notes on encryption
- Standalone Mode
- Remove or Disable Example Content
- Send log to a remote server
- Configure granular log level if required
- Run your Instance as non privileged user
- File system permissions of log files
- Deployment Scanner
- Web Subsystem
- Enable SSL Connector
- JSP Regeneration
- Remove and mask informational headers
- Disable stacktrace in response body
- Webservices Subsystem
- Messaging subsystem (HornetQ)
- Management Interfaces
- JGroups Subsystem
This guide is intended for organizations or individuals that are using JBoss Application Server 7 (in standalone or domain mode) on secure production systems.
The format of the examples is XML, all the code is intended as XML fragments of the full configuration file.
Some examples are valid only for a specific operating mode (standalone mode or domain). For more information on the JBoss AS7 operating modes please consult Operating modes.
Running instance of JBoss Application Server 7.2. How to get started with JBoss Application Server 7.2 is in the Getting Started Guide
Before implementing encryption on your data at any level (transmission, storage), understand if encrypting the data is necessary. Using SSL will cost hardware resources and will generally slow down your application server.
Always estimate how important is it to encrypt your data and exactly what data you need to encrypt.
Although it can be a good idea to keep some example content in a test environment, to check if the server is running correctly, it is not a good practice in production.
Removing the samples will prevent an external client seeing what version of the AS you are running and will also prevent the AS instance being affected by future security bugs on this content.
Delete the example datasource shipped with the default configuration:
Disable or remove the welcome-content directory by placing "false" as a value on enable-welcome-root
You can also change the alias name according to your needs.
You can remove the directory holding the sample content:
In Linux as the JBoss AS user:
It is good practice to log the actions on the org.jboss.security class. This category includes all the security related actions on the particular instance of the AS (authentication, failures, administrative changes ..).
It is good to keep these events in a separate file for easy classification and analysis. In this example the file will be called audit.log
Insert a new handler in our logging subsystem
Create a new category and reference the handler created above
Sending logs to a remote location is an excellent way to increase security (preventing log tampering) and improve your application error analysis. Jboss AS7.2 supports a syslog handler designed for this purpose.
Add the syslog handler in your logging subsystem:
In the section:
Add this handler:
For a more detailed explanation of all the parameters in this handler, please consult the Logging Configuration section of the management guide
|Note on Exceptions|
Even though JBoss supports a Syslog handler out of the box, some exceptions are often discarded by many syslog compatible servers because the exception message spans in multiple lines.
Please consult the documentation of your log server to understand if multi line logs are supported.
If your application is handling sensitive data or you are regulated by any data security compliance, you may want to reduce the log level of the sensitive classes of your application to avoid logging sensitive data on production system.
If your log file is for some reason compromised, the attacker may reach sensitive data stored in the logs if the class log level is not set up properly.
In this way you can specify a granular log level for each class that you wish to secure. Refer to Logging Configuration and Subsystem configuration for more details on how to set up the logging subsystem.
This is a global requirement for any mission-critical application, your AS 7 instance should never run as root account in a secure environment.
Please refer to your operating system documentation to understand how to run AS7 as non privileged user.
In order to prevent modifications to your log files, you can restrict the OS permissions to only be readable/writable by the JBoss user.
In order to change the location of your log files you can use this Java property at startup jboss.domain.log.dir and set a different log directory (I.E. /var/log/jboss)
Check the documentation of your operating system to understand how to restrict the access to your files.
In order to secure your datasources, it is good practice is associate them with a security domain.
This example will implement an Oracle datasource and it will delegate the authentication to a JAAS security domain.
Configure a security domain called "oracle-secure" to use with your datasource:
As you can see, between the <authentication></authentication> tags we have defined a username and a password for our database authentication.
defines which module to use and also to flag it as "required". This means that the client cannot pass the authentication if these credentials are not provided correctly.
The password value can be defined in plain-text or in an encrypted format. If you want to use the encrypted value just use Picketbox and provide the password as input:
|Changing the Key|
The result of this operation is an encrypted value, however the key used is hardcoded in the source code, from a security perspective, using a basically public passphrase is exactly the same as non encrypting at all. If you really want to make this secure please change the hardcoded passphrase in Picketbox.
You can possibly change the hardcoded key by modifying the source code of this Class. However, you may need to recompile and test the component yourself.
|Using the Vault|
Also note this article Securing Passwords on how to use the Vault functionality
Finally you can setup the datasource with your security domain
Your AS is now able to expose a datasource, connect to a database and delegate the authentication part to a security domain with an encrypted password.
The deployment scanner scans the file system where your AS instance is running to automatically deploy any new application copied in your deploy directory. If it is not needed, the deployment scanner must be disabled in order to prevent unauthorized files being deployed.
Just configure the scan-interval parameter as -1 , this will configure the deployment scanner to only allow deployments from console or at instance startup.
Enabling the SSL connector for the web subsystem will encrypt everything that is using that particular port
For more information on the connector attributes refer to JbossWeb Configuration Reference
Create an entry in the socket binding group for the port of this new connector, if not present
If you do not need automatic regeneration of JSP pages, set up the Web Subsystem to not regenerate the content automatically. This can prevent someone injecting code in your JSP resources and compiling them without your knowledge.
The "Development" value set to false will prevent JSP resources being automatically generated and force a restart in order to implement the changes.
When a resource is requested from the Web Connector via HTTP, the response contains headers with information about the server which generated the response.
This information can help an attacker to quickly identify which version you are running and consequently tune the attack attempts specifically for your software instance.
In order to hide or mask these headers we can set up the web subsystem with the following:
|Bug on jsp-configuration|
Sometimes the x-powered-by configuration element is not interpreted correctly and the actual property value in tomcat remains set to true.
If this is your case you can override globally this property value with:
And at this point the header should disappear completely.
Please note that this setting will be reflected on the actual response headers only if your application is using the JBoss AS 7.2 Web subsystem JSF library. If your application is using a custom library you must check the relevant documentation of your library version on how to disable this header
You should mask the "Server:" value in the header. By default this header shows the version of our servlet container.
In order to remove it we can set up a global property in this way:
At this stage, the response headers should look like this:
Stacktraces in response bodies are useful for quick debugging in development and test environments. However in production, showing stracktraces can leak sensitive information to the client.
To disable this particular functionality, the display-source-fragment directive must be set to false.
Define the secure WSDL port leveraging on the Web Subsystem ssl connector.Please note that <modify-wsdl-address> needs to be set to true in order for the Webservices subsystem to change all the http:// links in your WSDL file to https://, and instruct the client to go only to the secure version of your resources.
To create a security domain for your Webservices endpoints, you can use different login modules. Please consult the Security subsystem configuration for more detailed informations.
In the example a Database module is used.This security domain will query your database and search if the username/password pair provided to your Webservice by the client are correct.
Reference your new security domain in your code
The annotation SecurityDomain obviously configure the security domain used for authentication purposes.
The annotation RolesAllowed defines which security roles (from your security domain) are allowed to contact this webservice
The annotation transportGuarantee force the SSL/TLS connection
The annotation authMethod defines which method your webservice will use to authenticate the client.
The AS 7 ORB implementation can be secured by enabling SSL encryption in the JacORB subsystem.
First of all, create a security domain that references your keystore/truststore configuration. We'll call it "ssl-domain"
To enable this in JacORB setup the tags security-domain and security.
This configuration enables SSL on JacORB. If you want to lock-down this subsystem more, you can find a huge amount of useful informations on the JacORB Official Documentation Page
Like the other subsystems, the messaging subsystem can be linked to a security-domain in order to delegate encryption or authentication settings.
Reference the name of your security domain after the <hornetq-server> element
As seen before, the security domain can set up the parameters for encryption with SSL or authentication.
In order to have role based authentication inside our queue server you need to setup HornetQ with these directives.
you can restrict the access to particular queue (read/write) or even prevent the creation, deletion of new queues, with a basic role based access control.The match element tells to hornetq which queue address is interested in this authentication setting. To better understand how to setup this parameter, refer to the official HornetQ documentation.
Once the queue name is matched, your client has to be in the defined role in order to perform the desired operation. Usually the best practice is to leverage the security-domain element to validate the role, similar to what can be done in the Webservices or the Remoting subsystem.
|Security of JNDI Lookup for initialContext setup|
When a JNDI lookup is used to get the initialContext, the security aspect of that operation is managed by the Remoting subsytem.
The Messaging subsystem communicates with your client only after the JNDI lookup is successful.
If a messaging cluster is used, authentication must be in place to prevent unauthorized nodes joining the cluster pool.
Setup you password in the <hornetq-server> element:
|Properties at startup|
It is possible to set up the password and the username as java properties, I.E. jboss.messaging.cluster.password.
This way you may simplify the XML configuration management
The CLI connects to the Native Management API. For more information on the Native management API refer to https://docs.jboss.org/author/display/AS72/The+native+management+API
The web interface uses the HTTP API to perform tasks. Please refer to the HTTP API for security related operations
The JGroups subsystem is part of the default JBoss AS 7.2 HA (High Availability) configuration. JGroups is used by other subsystems (I.E. Infinispan) to share data across clusters of Jboss AS.
Unfortunately, the security subsystem is not integrated with the JGroups subsystem. For this reason, you must set up several configuration parameters that may look redundant.
The ENCRYPT protocol uses a keystore in order to encrypt the communication layer of all the other protocols below it.
Before configuring the AS, you must create another keystore to use specifically in JGroups.
Unfortunately, JGroups does not support the keystores generated with the standard JDK keytool. You must create your custom keystore with a java file called KeyStoreGenerator which is included in the demo package of JGroups.
|This example will create a keystore named as specified in FILENAME with the password specified in PASSWORD and a key named MyKey, feel free to experiment with different configuration as described in the JavaDOC of this class.|
Then include the ENCRYPT protocol in the standalone-full-ha of your JBoss AS instance.
|It is preferable in big clusters, to use asymmetric encryption, in that configuration the keystore does not need to be copied across the nodes of the cluster. However, there are several differences and considerations to put in account when choosing symmetric or asymmetric encryption. Read more about it here|
You can move the ENCRYPT element up and down trough the protocols stack, this will configure the subsystem to encrypt only the protocols below the ENCRYPT element.