acceptedSecurity Benchmark JBoss Enterprise Application Platform 5.xThis XCCDF benchmark is used for evaluating the security of Red Hat JBoss Enterprise Application Platform 5.x.This content was developed by Red Hat, Inc. for use by JBoss Enterprise Application Platform 5.x Administrators and is released under the GNU Lesser General Public License v3. Copyright Red Hat, Inc. 2012. All Rights Reserved.JBoss Enterprise Application Platform is a popular Java Enterprise Edition application server platform by Red Hat. It is based on the open-source JBoss Application Server, Community Edition. Leveraging robust container architecture, JBoss EAP is capable of hosting a wide variety of applications - anything from simple, static HTML pages all the way to distributed, transaction-based Java Enterprise Edition applications. JBoss EAP is known for being dependable, fast, flexible, and cost-effective.This benchmark provides security guidance on JBoss EAP 5 running on Red Hat Enterprise Linux. OVAL content for this benchmark to be run on other platforms is in development. This document assumes that the reader is familiar with JBoss EAP 5 and Red Hat Enterprise Linux administration. This document also assumes that the baseline configuration of the operating system and JBoss EAP 5 are up-to-date in terms of installed patches. The content within this benchmark was tested for compatibility with multiple SCAP tools on Red Hat Enterprise Linux 5 and 6. The following compatibility matrix shows our results:XCCDFExec v1.1.4 Build 19SPAWAR Compliance Checker v3.0.3OpenSCAP v0.8.2RHEL 5 - i386Fully CompatibleFully CompatibleFully CompatibleRHEL 5 - x86_64Fully CompatibleFully CompatibleFully CompatibleRHEL 6 - i386Additional Dependencies NeededFully CompatibleFully CompatibleRHEL 6 - x86_64Additional Dependencies NeededFully CompatibleFully CompatibleThe recommendations included in this benchmark have been derived from various government and industry sources. All rules include a rationale, validation instructions (for OCIL rules), remediation instructions, references, risk assessments, and NIST/DoD Control mappings. For additional information regarding the JBoss EAP 5 SCAP benchmark, please visit https://fedorahosted.org/scap-security-guide/You may also contact the authors:Bryan SaundersTim FallsJames LopezKenneth Peeplesv1.0Security Benchmark JBoss Enterprise Application Platform 5.xTimothy FallsBryan SaundersKenny PeeplesJames LopezRed Hatsecurity for JBoss Enterprise Application Platform (EAP), version 5Jason WongJesse SightlerJBoss Enterprise Application Platform 5 Security Guide, 2011Mallik, R. (2011, May). Jboss in the Trenches.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfU.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlU.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlU.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guidelines on Securing Public Web Servers (800-44). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJBoss Enterprise Application Platform 5 - Department of DefenseProfile for testing a secure deployment of JBoss EAP 5 in a DoD environment.Warning banner contentThis value contains the content for a DoD warning banner.The DoD warning banner should read: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests—not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."General ConfigurationThe rules in this group validation general configuration items.JBoss Enterprise Application Platform should be a vendor supported versionEvaluated JBoss installation must be a vendor supported version of JBoss Enterprise Application Platform 5. Red Hat typically offers full and production support for the first 7 years following a release. Extended support options can be negotiated with the vendor directly through a separate subscription. Organizations using JBoss EAP must use a vendor supported version with an active support contract.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlFailure to utilize a supported version of JBoss in a production environment can lead to outages, unresolvable problems, no access to security or functional updates, etc.7.5HighCAT I(AV:N/AC:L/Au:N/C:P/I:P/A:P)CM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1To determine the version of JBoss EAP installed, perform the following actions: Execute run.bat --version or run.sh --version located within JBOSS_HOME/binThe output of the command above will display a variety of information; including the version and build information for JBoss.Next, review support documentation and interview JBoss administrators. Work with JBoss administrators to access the Red Hat Network customer portal in order to review and validate active subscriptions (https://access.redhat.com/home). Additionally, ensure the version of JBoss has not reached end-of-life. Organizations using JBoss EAP must use a vendor supported version with an active support contract.Other environments should install a vendor supported version of Red Hat JBoss Enterprise Application Platform and maintain an active subscription. Contact Red Hat directly to subscribe to the JBoss software channel (http://www.redhat.com).Ensure downloaded software is checked against vendor supplied hashes to ensure the software has not been modified in transit. Tools such as sha1sum or md5sum (Linux) or File Checksum Integrity Verifier (FCIV) for Windows can be used to generate hash checksums for downloaded files.Ensure Java Runtime Environment in use is a supported versionEvaluated JBoss installation must use a vendor supported Java virtual machine - i.e., one that has not reached end-of-life. Migration strategies should be developed when end-of-life is impending.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJava installations should be a vendor supported version. If the Java virtual machine in use by JBoss is not supported by the vendor, this may result in outages, unresolvable problems, no access to security or functional updates, etc.7.5HighCAT ICAT I(AV:N/AC:L/Au:N/C:P/I:P/A:P)CM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1To identify the JRE used by JBoss, perform the following actions:Execute run.bat --version or run.sh --version located within JBOSS_HOME/binThe output of the command above will display a variety of information; including the vendor and version information for the JRE in use by JBoss. Search the vendor's website and support documentation to ensure the vendor actively supports the version of Java virtual machine in use. If the software will reach end-of-life within the next year, ensure the organization is developing a migration plan.Java Runtime Environments commonly used with JBoss include:
Sun JRE 1.6.xIBM JRE 1.6.xOpenJDK JRE 1.6.xOrganizations should install a vendor supported Java Runtime Environment.Ensure downloaded software is checked against vendor supplied hashes to ensure the software has not been modified in transit. Tools such as sha1sum or md5sum (Linux) or File Checksum Integrity Verifier (FCIV) for Windows can be used to generate hash checksums for downloaded files.Finally, organizations must develop migration plans for Java Runtime Environments that reach end-of-life within the next year.Ensure all configurations are made to the appropriate server profileProduction environments should utilize the production server profile. Development and test environments should choose the profile that best fits their needs.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlThe JBoss server profiles are preconfigured with various deployed applications. Using a more restrictive profile ensures that less applications are deployed, minimizing the attack surface of the JBoss server and decreasing the amount of trimming that must be performed.3LowCAT IIICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Ensure that all configuration changes and deployments are made to the appropriate server profile. Production environments should utilize the production server profile. Development and test environments should choose the profile that best fits their needs.JBoss administrators should use the profiles as defined in the validation text.Ensure Technology Preview components are disabled in production environmentsRemove the PicketLink technology preview folder. By default, this folder is included at the same level as the JBoss-as folder. If you leave the picketlink folder as originally shipped in the EAP binary, PicketLink is unable to be launched, and subsequently interact with the certified configuration. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlTechnology Preview components are not production-ready, vendor supported JBoss components. They may be incomplete, contain bugs, insecure features or architecture, etc.3LowCAT IIICM-7DCPP-1Delete the JBOSS_HOME/picketlink/ folder.Disable Hot Deployment in productionHot deployment should be disabled on production servers. Hot Deployment allows for automatic deployment of Java applications by simply placing Java applications into the deploy directory.Hot deployments are not a recommended best practice for production environments. By requiring the additional step of restarting the JBoss server, application deployments become more deliberate and purposeful. Additionally, the JBoss Hot Deployment feature has been known to become unstable over time - consuming additional memory and resources.3.0LowCAT IIICM-7DCPP-1Delete the following file:JBOSS_HOME/server/[PROFILE]/deploy/hdscanner-jboss-beans.xmlProduction applications should not implement the default SRPVerifierStore interface for the Secure Remote Password (SRP) protocolThe SRP protocol is a public key exchange protocol similar to Diffie-Hellman. The default implementation of the SRPVerifierStore interface is not recommended for a production security environment because it requires all password hash information to be available as a file of serialized objects.JBoss Enterprise Application Platform 5 Security Guide, 2011Serializing objects is not a recommended practice for Java applications. Object serialization shows poor performance and is not typically scalable for production. Additionally, object serialization creates dependency concerns within the object hierarchy.3LowCAT IIICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview application developers and review application documentation. If deployed applications utilize SRP and/or source code is available for reference, review evidence that the default SRPVerifierStore interface is not in use and that the existing code does not use serialized objects for persistence. Application developers should not use the default implementation for SRPVerifierStore, and should extend it to avoid the use of serialized password objects.Declare an EJB authorization policy for deployed applicationsWhen configuring your application specific security policy, you must declare one (or more) of the following authorization modules in the security domain <policy-module> element.
org.JBoss.security.authorization.modules.DelegatingAuthorizationModuleorg.JBoss.security.authorization.modules.JACCAuthorizationModuleA security domain does not explicitly require an authorization policy. If an authorization policy is not specified, the default jboss-web-policy and jboss-ejb-policy authorization configured in jboss-as/server/$PROFILE/deploy/security/security-policies-jboss-beans.xml is used. If you do choose to specify an authorization policy, or create a custom deployment descriptor file with a valid authorization policy, these settings override the default settings in security-policies-jboss-beans.xml.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlExplicitly referencing one of the identified authorization modules ensures that applications extend the security policies defined in security-policies-jboss-beans.xml. This allows JBoss administrators to set a secure baseline that can be tuned on a per-application basis.3.5MediumCAT IIAC-3,AC-4ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,EBBD-1,EBBD-2,EBBD-3Review possible locations for definition of <application-policy> elements. Specifically, ensure that 'code' attributes for <authorization><policy-module> elements are either 'org.JBoss.security.authorization.modules.DelegatingAuthorizationModule' or 'org.JBoss.security.authorization.modules.JACCAuthorizationModule'.These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlNOTE: This applies even if the application is using Extensible Access Control Markup Language (XACML) Authorization Module.Applications deploying their own security policies must specify one of the following <policy-module> within their 'code' attributes:org.JBoss.security.authorization.modules.DelegatingAuthorizationModuleorg.JBoss.security.authorization.modules.JACCAuthorizationModuleExample:<application-policy name="demo">
<authorization>
<policy-module code="org.JBoss.security.authorization.modules.JACCAuthorizationModule"></policy-module>
</authorization>
</application-policy>Ensure appropriate permissions have been granted to Java Database Connectivity (JDBC) driverThe security manager policy file may require permissions to be set for database drivers. The JBoss administrator can assign permissions to the database drivers that are needed by deployed applications. It is recommended that the most restrictive permissions are added. With some installations, permissions must be granted to database drivers that are not available to deployed applications; such as java.net.SocketPermission.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlDeployed applications requiring access to data sources should have limited permissions to interact with the database drivers.6.2MediumCAT II(AV:L/AC:H/Au:N/C:C/I:C/A:C)AC-3,AC-6ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityJBOSS_HOME/bin/security_cc.policyOther environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Permissions required for JDBC drivers will vary and should be configured according to vendor documentation. In general, JDBC drivers should not be granted AllPermission.The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) to applications accessing defined data sources. This should be done in cooperation with application developers or application documentation. Substitute the directory name of the JDBC driver where [JDBC.DRIVER] is specified in the code sample.// granting permissions to JDBC driver
grant codeBase "file:${JBoss.server.home.dir}/lib/[JDBC.DRIVER]" {
//JDBC specific permissions to be granted go here
};Ensure appropriate DefaultDS is enabledCreate a default data store file for the desired database. Templates are located in JBOSS_HOME/docs/examples/jca.The DefaultDS must not be a HSQLDB.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlTo help ensure robust server operations, a DefaultDS that does not use HSQLDB should be specified. DefaultDS is used by some JBoss components by default.2.6LowCAT III(AV:L/AC:H/Au:N/C:N/I:P/A:P)SC-4ECRC-1Review defined data sources in the JBOSS_HOME/server/[PROFILE]/deploy directory. Data sources will be suffixed as -ds.xml. Search for a data source with a <jndi-name>DefaultDS</jndi-name> element. OS text searching utilities can help find the DefaultDS. The DefaultDS CANNOT be HSQL. An HSQL data source will contain elements like: <driver-class>org.hsqldb.jdbcDriver</driver-class> and <type-mapping>Hypersonic SQL</type-mapping>.Linux: grep -Hri "<jndi-name>DefaultDS</jndi-name>" $JBOSS_HOME/server/[PROFILE]/deploy/*-ds.xmlCreate a default DS file for the desired database at JBOSS_HOME/server/[PROFILE]/deploy/DefaultDS.xml. Examples of this file are located in JBOSS_HOME/docs/examples/jca. The DefaultDS must not be a HSQLDB.Deployed applications must not write data to DefaultDSDeployed applications (other than JBoss default applications) must not write information to the database defined by the DefaultDS data source. These applications must use a database specific to the application.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlSharing databases between applications is a poor security practice that can create injection and leakage vulnerabilities that cross application boundaries.5.1MediumCAT II(AV:N/AC:H/Au:N/C:P/I:P/A:P)SC-4ECRC-1Interview the application developers and/or review source code to identify when data sources are used. Ensure that the application is not storing data within the DefaultDS.Next, review the data source definition files (files suffixed *.xml) used by the deployed user applications to ensure they do not reference the same database used by the DefaultDS.NOTE: Using the same database server is acceptable, however the database must not be the same.Create and deploy a data source in addition to the DefaultDS to store application data. This new data source must not point to the same database as the DefaultDS data source.Data source templates can be found in the JBOSS_HOME/docs/examples/jca/ directory.Ensure default HSQLDB is disabledThe default development HSQL database included with JBoss should be removed.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlHSQL is not meant for production environments - it is there to speed development and enable faster application prototyping. Thus, it is not a full-featured data source intended for production use.2.6LowCAT III(AV:L/AC:H/Au:N/C:N/I:P/A:P)SC-4ECRC-1Delete the following files that refer to the HSQLDB database:JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xmlJBOSS_HOME/common/lib/hsqldb.jarJBOSS_HOME/common/lib/hsqldb-plugin.jarJBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xmlDelete the HSLQDB database files:JBOSS_HOME/server/[PROFILE]/data/hypersonic/*Ensure HSQLDB Security Domain is removedThe security domain for HsqlDbRealm should be removed from the JBOSS_HOME/server/[PROFILE]/conf/login-config.xml file.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlHSQL is not meant for production environments - it is there to speed development and enable faster application prototyping. Thus, it is not a full-featured data source intended for production use.1LowCAT IIISC-4ECRC-1Remove the security domain for HsqlDbRealm in the JBOSS_HOME/server/[PROFILE]/conf/login-config.xml file as shown.<!-- Security domains for testing new jca framework
<application-policy name = "HsqlDbRealm">
<authentication>
<login-module code = "org.JBoss.resource.security.ConfiguredIdentityLoginModule" flag = "required">
<module-option name = "principal">sa</module-option>
<module-option name = "userName">cctest</module-option>
<module-option name = "password">cc1248</module-option>
<module-option name = "managedConnectionFactoryName">JBoss.jca:service=LocalTxCM,name=DefaultDS</module-option>
</login-module>
</authentication>
</application-policy>
-->Ensure the appropriate Java Messaging Service (JMS) persistence configuration file is in useThe [database]-persistence-service.xml file contains the persistence service definition for Java Messaging Service, for the database specified by the [database] in the filename. The database must not be HSQLDB.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlIn order to function properly, JMS should be configured to use the appropriate datastore. Production environments require a persistence service definition for JMS that does not use HSQLDB.2.6LowCAT III(AV:L/AC:H/Au:N/C:N/I:P/A:P)CM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview the JBoss administrators and application developers to determine if JMS is in use. A quick check can also be performed by checking for the existence of the following files:JBOSS_HOME/server/[PROFILE]/deploy/messagingJBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rarIf JMS is installed, a persistence-service.xml file must exist that does not use HSQLDB. This persistence file will be located in the following location:JBOSS_HOME/server/[PROFILE]/deploy/messaging/*persistence-service.xmlCopy the [database]-persistence-service.xml file that corresponds to the database you are using from the JBOSS_HOME/docs/examples/jms directory to JBOSS_HOME/server/[PROFILE]/deploy. Make any required content changes to fit the persistence service to the environment.Ensure Oracle Database persistence plugin is set correctlyWhen using the Oracle Database as the DefaultDS, the database persistence plugin definition must be updated in JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlThis is a performance optimization when using Oracle Database as the DefaultDS.2.6LowCAT III(AV:L/AC:H/Au:N/C:N/I:N/A:P)CM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Review defined data sources in the JBOSS_HOME/server/[PROFILE]/deploy directory. Data sources will be suffixed as -ds.xml. Search for a data source with a DefaultDS element. Review the DefaultDS datasource. If the DefaultDS is Oracle Database, review the persistence plugin located at JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml. The DatabasePersistencePlugin attribute must be configured like below:<attribute name="DatabasePersistencePlugin">
org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
</attribute>When using the Oracle Database as the DefaultDS, the database persistence plugin definition must be updated in
JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml to:<attribute name="DatabasePersistencePlugin">
org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
</attribute>Ensure IBM JRE 1.6 is configured correctlyWhen IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made to ensure compatibility between JBoss EAP and IBM JRE.IBM JRE 1.6 uses a default policy provider which does not work correctly with the JBoss Enterprise Application Platform security policy. The IBM JRE must be reconfigured to use the standard policy provider.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlThe IBM JRE 1.6 default policy provider does not work correctly with the JBoss EAP security policy. Failure to assign the correct policy can lead to system instability.3.5MediumCAT IICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Review the run.bat or run.sh file as appropriate to determine how JBoss Enterprise Application Platform is calling the Java Runtime Environment. By default, these files are configured to locate the JRE installation through the JAVA_HOME environment variable. If the JAVA_HOME environment variable is not configured, you must track the JRE installation path using information from the run.bat/run.sh file and the operating system PATH variables.Open JAVA_HOME/jre/lib/security/java.security and review the entry for policy.provider. If the entry is not set to sun.security.provider.PolicyFile, this is a failure.When IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made for compatibility:Edit the file JAVA_HOME/jre/lib/security/java.security and set the value of policy.provider to sun.security.provider.PolicyFileConfigured security domains are recommended to secure production applicationsSecurityDomain is an extension of the AuthenticationManager, RealmMapping, and SubjectSecurityManager interfaces. A java.security.KeyStore, and the Java Secure Socket Extension (JSSE) com.sun.net.ssl.KeyManagerFactory and com.sun.net.ssl.TrustManagerFactory interfaces are included in the class.JBoss Enterprise Application Platform 5 Security Guide, 2011SecurityDomain is the recommended way to implement security in components, because of the advantages the JAAS Subject offers, and the increased support offered to ASP-style application and resource deployments.3.5MediumCAT IIAC-3,IA,SCECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1Interview JBoss administrators and application developers. Review application documentation. If a need has been identified to secure production applications, JAAS SecurityDomains should be used. Configure and apply SecurityDomains where appropriate for production applications.For example, an <application-policy> (SecurityDomain) can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlTo determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml The allRolesMode must be configured to "strict"The allRolesMode within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml must be set to strict for production environments. This requires the authenticated user to be assigned to one of the web-app/security-role/role-name roles in order to be authorized. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlThis rule enforces strict authorization, requiring authenticated users to be members of defined roles. This allows JBoss administrators to create a simpler, tighter security policy.4.6MediumCAT II(AV:N/AC:H/Au:S/C:P/I:P/A:P)AC-3,AC-6ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1Update allRolesAttribute for the <Realm> element with className="org.jboss.web.tomcat.security.JBossWebRealm" in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Set the attribute value to "strict". By default, the allRolesAttribute is set to "authOnly". For example:<Realm className="org.jboss.web.tomcat.security.JBossWebRealm" certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping" allRolesMode="strict" />Define <security-role> elementsEnable authorization and define <security-role> elements to control access to deployed applications.JBoss Enterprise Application Platform 5 Security Guide, 2011 The specification of <security-role> elements is a recommended practice to ensure portability across application servers and for deployment descriptor maintenance.3.5MediumCAT IIAC-3,AC-6ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1Review the web.xml deployment descriptors for deployed applications. Ensure that <security-role> elements have been define that are referenced by <security-constraint><auth-constraint> elements within the <web-app> root element.Working with application developers (or available documentation), determine the desired roles for controlling access to the deployed applications.Next, create the roles within web.xml.<web-app>
<security-role>
<description>The role required to access restricted content </description>
<role-name>AuthorizedUser</role-name>
</security-role>
</web-app>Finally, require the roles within the application's deployment descriptor, web.xml:<web-app>
<security-constraint>
<auth-constraint>
<role-name>AuthorizedUser</role-name>
</auth-constraint>
</security-constraint>
</web-app>Remove, rename, or comment out the default user accounts from production serversRemove, rename, or comment out the default user accounts defined in .properties files and login-config.xml.JBoss Enterprise Application Platform 5 Security Guide, 2011Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default user accounts makes malicious exploitation more complex.6MediumCAT II(AV:N/AC:M/Au:S/C:P/I:P/A:P)IA-5IAIA-1,IAIA-2,IATS-1,IATS-2Ensure the default user accounts in the default <application-policy> elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml have been removed, renamed, or commented out.
<module-option name="principal">sa</module-option>
<module-option name="userName">sa</module-option>
<module-option name="password"></module-option>
<module-option name="principal">guest</module-option>
<module-option name="userName">guest</module-option>
<module-option name="password">guest</module-option>
Examine the .properties files located within the JBOSS_HOME/server/[PROFILE]/conf/props/ directory.
By default, the following files exist:jbossws-users.propertiesjmx-console-users.propertiesmessaging-users.propertiesEnsure the default user accounts have been removed, renamed, or commented out. This includes:adminkermitguestRemove, rename, or comment out the default user accounts in the default <application-policy> elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml.
<module-option name="principal">sa</module-option>
<module-option name="userName">sa</module-option>
<module-option name="password"></module-option>
<module-option name="principal">guest</module-option>
<module-option name="userName">guest</module-option>
<module-option name="password">guest</module-option>
Remove, rename, or comment out the default user accounts in properties files: JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.propertiesjmx-console-users.propertiesmessaging-users.propertiesThe default user accounts include:adminkermitguest
NOTE: If access is required to the services protected by the <application-policy>, be sure that valid accounts and roles exist!Remove, rename, or comment out the default roles from production serversRemove, rename, or comment out the default role definitions in the default <application-policy> elements.Additionally, remove, rename, or comment out the default role assignments in various properties files from JBOSS_HOME/server/[PROFILE]/conf/props/JBoss Enterprise Application Platform 5 Security Guide, 2011Default configurations are commonly leveraged by attackers to gain entry into closed systems. Renaming, removing, or commenting out default roles can make exploitation more complex. These steps can also prevent inadvertent assignment of permissions.6MediumCAT II(AV:N/AC:M/Au:S/C:P/I:P/A:P)IA-5IAIA-1,IAIA-2,IATS-1,IATS-2Ensure the default role assignments have been removed, renamed, or commented out from the default properties files located in JBOSS_HOME/server/[PROFILE]/conf/props/
jbossws-roles.propertiesjmx-console-roles.propertiesmessaging-roles.propertiesThe default role assignments are JBossAdmin, HttpInvoker, friend, and guest.Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xmlJBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xmlJBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xmlThese role assignments will fall within <auth-constraint> elements and will look similar to the following:<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>Ensure the default role assignments have been removed, renamed, or commented out from the default properties files located in JBOSS_HOME/server/[PROFILE]/conf/props/
jbossws-roles.propertiesjmx-console-roles.propertiesmessaging-roles.propertiesThe default role assignments are JBossAdmin, HttpInvoker, friend, and guest.Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xmlJBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xmlJBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xmlThese role assignments will fall within <auth-constraint> elements and will look similar to the following:<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>Security constraint elements should exist for all URLs in production environmentThe content to be secured is declared using one or more <web-resource-collection> elements. Each <web-resource-collection> element contains an optional series of <url-pattern> elements followed by an optional series of <http-method> elements. The <url-pattern> element value specifies a URL pattern against which a request URL must match for the request to correspond to an attempt to access secured content. The <http-method> element value specifies a type of HTTP request to allow.JBoss Enterprise Application Platform 5 Security Guide, 2011 Whitelisting allowed HTTP methods against all URL's is a recommended security practice to minimize the attack surface of deployed applications. This must be done carefully to ensure that security loopholes are not created, as JBoss allows all HTTP methods by default..6MediumCAT IIAC-3ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1Review application deployment descriptors for indications that <http-method> has been used to whitelist HTTP verbs. Application deployment descriptors will be located at JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/web.xml
All deployed applications should restrict HTTP verbs. JBoss administrators must take care when restricting HTTP verbs, as JBoss restricts no verbs by default. An incomplete whitelist/blacklist combination could allow circumvention of the intended security policy.Implement a whitelist for HTTP methods accepted by each deployed application. This will generally take the form of two separate security constraints.DefaultCacheTimeout must be configured properly for active security domainsSecurity domains in use must use DefaultCacheTimeout less than or equal to 1800 seconds.
If you want to disable caching of security credentials, set this to 0 to force authentication to occur every time. This has no affect if the AuthenticationCacheJndiName has been changed from the default value. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJBoss Enterprise Application Platform 5 Security Guide, 2011Production applications should be carefully evaluated to determine the appropriate level of cache credential timeouts. Overuse of cached credentials can leave applications vulnerable to stale authentication stores.4MediumCAT II(AV:N/AC:H/Au:N/C:P/I:P/A:N)SC-8,SC-9,SC-23ECTM-1,ECTM-2Open the JaasSecurityManagerService Mbean configuration file located at JBOSS_HOME/server/[PROFILE]/conf/jboss-service.xmlFind the element <mbean code="org.jboss.security.plugins.JaasSecurityManagerService" name="jboss.security:service=JaasSecurityManager">Change the <DefaultCacheTimeout> to 1800 or less.snmp-adaptor.sar must not be deployedThe file JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar should not exist. snmp-adaptor.sar is the default deployment package for JBoss SNMP. The manager implements SNMP using joeSNMP, supporting only SNMP versions 1 and 2.The default SNMP package (snmp-adaptor.sar) implements joeSNMP, which itself implements SNMP versions 1 and 2. Both versions of the SNMP protocol have many flaws and known vulnerabilities that can leveraged by attackers. Often these are simple remote exploitations that can be easily used by attackers to penetrate a network.7.5HighCAT I(AV:N/AC:L/Au:N/C:P/I:P/A:P)CM-6,CM-7DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1To determine if SNMP capabilities have been completely removed, check for the existence of the SNMP adaptor located here: JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar/If the exploded SAR exists, joeSNMP has been deployed and SNMP capabilities using this SNMP implementation still exist for the JBOSS server.Delete the directory JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar/Harden Tomcat Connectors: limit maxPostSizeThe Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the connectors can be taken quickly and easily. maxPostSize is the maximum size (in bytes) that the FORM URL parser can handle. Environments that pass large amounts of data through forms (such as file uploads), may need to increase this setting.An overly high setting can create a denial of service vulnerability in which an attacker simultaneously performs several large POSTS - tying up server resources and network bandwidth.6.3MediumCAT II(AV:N/AC:M/Au:S/C:N/I:N/A:C)CM-6,CM-7DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxPostSize attribute. If a maxPostSize attribute is defined, it should be 104857600 or less (100 MB).Ensure that all <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxPostSize attributes (104857600 or less).Harden Tomcat Connectors: limit maxSavePostSizeThe Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. maxSavePostSize is the maximum size (in bytes) that is buffered during CLIENT-CERT and FORM authentication. The default setting of 4096 (4 KB) is sufficient for most environments.An overly high setting can inadvertently create a denial of service vulnerability in which many users are authenticated and tying up server resources.6.3MediumCAT II(AV:N/AC:M/Au:S/C:N/I:N/A:C)CM-6,CM-7DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxSavePostSize attribute. If a maxSavePostSize attribute is defined, it should be 12288 or less (12 KB).Ensure that all <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxSavePostSize attributes (12288 or less).Harden Tomcat Connectors: set server header tagsThe Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The server attribute controls the Server Header tag sent with each HTTP response. The default setting causes the server to return Apache-Coyote/1.1 with each HTTP response.Failure to set the server attribute aids malicious users in fingerprinting a web server. However, the server attribute is also used legitimately by some applications for identification.2.0LowCAT IIICM-6,CM-7DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each HTTP <Connector> element to ensure it defines a server attribute. A server attribute should be defined, and it should be set to something other than Apache-Coyote/1.1.Ensure that all HTTP <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured server attributes (set to something other than Apache-Coyote/1.1).Harden Tomcat Connectors: ciphers attributeThe Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The ciphers attribute controls the what ciphers are used to negotiate secure connections. The default setting causes the server to use the ciphers allowed by the running Java Virtual Machine.In an environment where FIPS mode has been enabled for the JVM, overriding those settings can lead to system instability or the use of non-FIPS algorithms.6.0MediumCAT IICM-6,CM-7DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each <Connector> element that contains a secure=true attribute. Ensure this connector does not define a ciphers attribute and instead inherits ciphers defined by the JVM.Ensure that all secure <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have not defined cipher attributes.Harden Tomcat Connectors: limit connectionTimeoutThe Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. connectionTimeout is the time (in milliseconds) that the container will wait for URI content after receiving a connection. The default setting is 60000.An overly high setting can be easily exploited to create a denial of service condition by tying up server resources.6.3MediumCAT II(AV:N/AC:M/Au:S/C:N/I:N/A:C)CM-6,CM-7DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1Review HTTP <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check to ensure they define a connectionTimeout attribute. The connectionTimeout attribute should be 20000 or less (20 seconds).Ensure that all HTTP <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured connectionTimeout attributes (20000 or less).Securing JBoss platformThe rules in this group are used to secure the JBoss platform and its dependencies.Configure Java Security Manager to use an environment specific policyThe Java Security Manager is a crucial piece of the Java security infrastructure. JBoss Enterprise Application Platform should be configured to load a Java security policy that has been vetted for use in the environment. This precludes the use of the simple default policy that ships with JBoss, but does not preclude the use of preconfigured policy files like the security policy designed for use in a Common Criteria environment (See JBoss Common Criteria Configuration Guide for details).U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlA weak, default, or incomplete Java Security Manager policy file can completely compromise the security of a Java installation by granting excessive permissions to applications running within the sandbox. These permissions can be leveraged (maliciously or not) to run code against the operating system.6.8MediumCAT II(AV:N/AC:M/Au:N/C:P/I:P/A:P)SA-13To load an environment specific security policy, simply append the following line to JBOSS_HOME/bin/run.conf or JBOSS_HOME/bin/run.conf.bat as appropriate (depending on the host operating system).JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==[PATH TO POLICY FILE]"NOTE: Using a prepackaged policy file is acceptable, as long as the policy file has been reviewed for compatibility and security within the current environment.Ensure proper permissions are configured for interactions with JBoss JMX Kernel MBeanJava permissions for MBeans should be carefully restricted to enforce the least privilege principle. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJava permissions for MBeans should be carefully restricted to enforce the least privilege principle. A JMX MBean server might have access to sensitive information and might be able to perform sensitive operations. JMX provides necessary access control that identifies which clients can access that information and who can perform those operations through the use of the Java Security Manager (JSM). An MBean has a management interface consisting of Named and typed attributes that can be read and written, Named and typed operations that can be invoked and Typed notifications that can be emitted by the MBean.3.7LowCAT III(AV:L/AC:H/Au:N/C:P/I:P/A:P)AC-6ECLP-1To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityJBOSS_HOME/bin/security_cc.policyOther environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)Review all JSM permissions granted to MBeans. Grant statements should be limited to specific users and specific methods.For example, permission A in the example below is allowed while permission B is not://Permission A
grant principal javax.security.auth.x500.X500Principal "CN=Administrator,OU=JBoss,O=RedHat,L=Raleigh,ST=NC,C=US"
{
permission javax.management.MBeanPermission
"className#member[objectName]",
"invoke";
}
grant principal javax.management.remote.JMXPrincipal "guest"
{
permission javax.management.MBeanPermission "*", "queryNames";
permission javax.management.remote.SubjectDelegationPermission;
//Permission B
grant {
permission javax.management.MBeanPermission "*","invoke";
}The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for MBeans. This should be done in cooperation with system administrators, application developers and/or application documentation.Ensure proper permissions are configured for deployed applications: java.io.FilePermissionDeployed applications must not be granted file permissions - except to those that are dedicated to the application only. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJava permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting unrestricted access to the host operating system creates a large attack vector for malicious users that have penetrated the JBoss server.6.2MediumCAT II(AV:L/AC:H/Au:N/C:C/I:C/A:C)AC-6ECLP-1To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityJBOSS_HOME/bin/security_cc.policyOther environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy).
Review all permissions granted to user deployed applications. The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications.Grant statements granting file permissions are permitted only when the file permission targets are located within the user application's directory and dedicated for use by the deployed application.
For example, permission A in the example below is allowed while permission B is not://Permission A
grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" {
permission java.io.FilePermission "${JBoss.server.home.dir}/deploy/userApplication/temp.txt", "read";
};
//Permission B
grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" {
permission java.io.FilePermission "/etc/shadown", "read";
};The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.Application access granted to files by java.io.FilePermission must be located within the deployed application's directory path and be dedicated for use by the deployed application. Grant statements in conflict with this guidance should be modified or removed.Ensure proper permissions are configured for deployed applications: java.net.NetPermissionDeployed applications must not be granted network permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJava permissions for deployed applications should be carefully restricted to enforce the least privilege principle.5.2MediumCAT II(AV:L/AC:H/Au:N/C:P/I:P/A:C)AC-6ECLP-1To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityJBOSS_HOME/bin/security_cc.policyOther environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy).
Review all permissions granted to user deployed applications. Grant statements granting network permissions are not allowed and will look similar to the following:grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" {
permission java.net.NetPermission [specific permissions];
};The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.Permissions granted to applications via java.net.NetPermission should be removed.Ensure proper permissions are configured for deployed applications: java.lang.RuntimePermissionDeployed applications must not be granted runtime permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJava permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting RuntimePermission to applications allows these applications to modify classloaders or modify the running security manager. Either of these actions can be used to elevate permissions and increase the number of potential damaging actions that can be taken.6.2MediumCAT II(AV:L/AC:H/Au:N/C:C/I:C/A:C)AC-6ECLP-1To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityJBOSS_HOME/bin/security_cc.policyOther environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)Review all permissions granted to user deployed applications. Grant statements granting runtime permissions are not allowed and will look similar to the following:grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" {
permission java.lang.RuntimePermission [specific permissions];
};The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.Permissions granted to applications via java.lang.RuntimePermission should be removed.Ensure proper permissions are configured for deployed applications: java.net.SocketPermissionDeployed applications must not be granted any socket permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJava permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Most well-designed applications will not need to directly manipulate sockets for network access (access to datasources should be handled through datasources, which can be assigned SocketPermission.).6.2MediumCAT II(AV:L/AC:H/Au:N/C:C/I:C/A:C)AC-6ECLP-1To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityJBOSS_HOME/bin/security_cc.policyOther environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)
Review all permissions granted to user deployed applications. Grant statements granting socket permissions are not allowed and will look similar to the following:
grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" {
permission java.net.SocketPermission [specific permissions];
};The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.Permissions granted to applications via java.net.SocketPermission should be removed.Ensure proper permissions are configured for deployed applications: java.security.AllPermissionDeployed applications must not be granted all permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJava permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Using AllPermissions is essentially disabling the Java security sandbox and is inadvisable in nearly every scenario.6.2MediumCAT II(AV:L/AC:H/Au:N/C:C/I:C/A:C)AC-6ECLP-1To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityJBOSS_HOME/bin/security_cc.policyAdditional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)
Review all permissions granted to user deployed applications. Grant statements granting AllPermission are not allowed and will look similar to the following:
grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" {
permission java.security.AllPermission;
};The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.Permissions granted to applications via java.security.AllPermission should be removed.Ensure default system Java Authentication and Authorization Service configuration is in use for JBoss SeamFor JBoss Seam, the simplified Java Authentication and Authorization Service configuration provided by the Seam Security API must not be used. The default system JAAS configuration should be used instead. Using the default system JAAS configuration ensures user identification and authentication are performed by the JBoss Enterprise Application Platform. JBoss Seam provides additional interfaces for implementing other security functions such as authorization (for example, entity bean permissions). This functionality is controlled by JBoss Seam, and is therefore outside the scope of the evaluated product.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlUsing an administrator specified JAAS configuration enables a more rigorous security posture.5.5MediumCAT IICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Check for components.xml. These files are typically located within the WEB-INF director of a deployed WAR. However, components.xml can also be located within the META-INF directory of a JAR or any JAR directory containing classes with a @Name annotation.Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:<security:identity jaas-config-name="[security domain]"/>The security domain must map to a valid JAAS security domain.Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:<security:identity jaas-config-name="[security domain]"/>Components.xml is typically located within the WEB-INF director of a deployed WAR. However, components.xml can also be located within the META-INF directory of a JAR or any JAR directory containing classes with a @Name annotation.Validate keystore and keystorePasswordURL properties are defined and loaded by Java Security ManagerEnsure keystore and keystorePasswordURL properties exist and are loaded by Java Security Manager.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlA keystore should be setup for production environments. Defining a keystore is a basic step towards implementing security and allowing for the use of public/private key cryptography for JBoss. The keystore should be password protected to protect the integrity of the keystore and prevent unauthorized modification.2.4LowCAT III(AV:L/AC:H/Au:S/C:P/I:P/A:N)SC-28,IA-5ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Ensure the following lines exist within the any loaded policy file:keystore "file:[PATH TO KEYSTORE]";
keystorePasswordURL "file:[PATH TO PASSWORD FILE]";NOTE: The file names and paths may vary.Add the following lines to any loaded policy file:keystore "file:[DESIRED PATH TO KEYSTORE]";
keystorePasswordURL "file:[DESIRED PATH TO PASSWORD FILE]";A typical configuration may look like the following:keystore "file:${JBoss.server.home.dir}/cc.keystore";
keystorePasswordURL "file:${JBoss.server.home.dir}/cc.password";NOTE: The file names and paths may be different. Those shown are the defaults. If the keystore or password file are in different locations, the policy should reflect that.Validate a keystore file for JBoss exists and is accessible to JBossValidate a keystore for JBoss exists and is accessible to JBoss.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlA keystore should be setup for production environments. Defining a keystore is a basic step towards implementing security and allowing for the use of public/private key cryptography for JBoss. The keystore should be password protected to protect the integrity of the keystore and prevent unauthorized modification.3.5MediumCAT IISC-8,IA-5ECTM-1,ECTM-2,IAIA-1,IAIA-2,IATS-1,IATS-2Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:keystore "file:[PATH TO KEYSTORE]";Next, validate that the keystore exists at the specified path and that the JBoss process owner account and JBoss administrators have READ/WRITE access to the keystore.To create a JBoss keystore, run the following command (you will be prompted to create a password):keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE AS DEFINED IN POLICY FILE] -file [PATH TO TRUSTED CERTIFICATE TO IMPORT] -noprompt -trustcacertsSetting permissions will vary by operating system, but typically commands like cacls, xacls, chmod, setfacl, etc can all be used to restrict permissions on the keystore. Only the JBoss process owner and JBoss administrators should have READ/WRITE access to the keystore.Validate a password file for the Java keystore exists and is accessible to JBossValidate a password file for the keystore defined in the properties file exists and is accessible to JBoss.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlA password-protected keystore should be setup for production environments. The password for the keystore should be stored in a password file to facilitate automated startup of JBoss Enterprise Application Platform.3.7MediumCAT IISC-28,IA-5ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:keystorePasswordURL "file:[PATH TO KEYSTORE PASSWORD FILE]";Next, validate that the password file exists at the specified path, that only JBoss process owner account and JBoss administrators have READ/WRITE access to the file, and the correct password for the JBoss keystore is in the file. To add a password file for a JBoss keystore, simply add the plain-text password to a file and then specify that file in a loaded Java Security Manager policy.First, ensure the password file location is identified in the policy file being loaded by the Java Security Manager:keystorePasswordURL "file:[DESIRED PATH TO KEYSTORE PASSWORD FILE]";Next, add the plain-text password to file whose location you just defined.Finally, restrict permissions on the password file so that only the JBoss process owner account and JBoss administrators have READ/WRITE access. Setting permissions will vary by operating system, but typically commands like cacls, xacls, chmod, setfacl, etc can all be used to restrict permissions on the keystore. Only the JBoss process owner and JBoss administrators should have READ/WRITE access to the password file.Validate JBoss keystore is password protectedValidate the keystore loaded by the Java Security Manager is password protected. Password protecting the Java keystore used by JBoss issued to protect the integrity of the keystore. It does not prevent listing the content, but it does prevent modification of the keystore. Private keys within the keystore are still protected by their own passwords to prevent disclosure.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlFailure to protect the integrity of the keystore used by JBoss can result in authorized modification of the keystore and subsequent certificate trust compromises for JBoss.3.7MediumCAT II(AV:L/AC:H/Au:N/C:P/I:P/A:P)SC-28,IA-5ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:keystore "file:${JBoss.server.home.dir}/cc.keystore";Next, access the contents of the keystore using the following command:keytool -list -keystore [PATH TO KEYSTORE]You should be prompted for a password (non-blank).Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:keystore "file:[PATH TO KEYSTORE]";Add a password to the keystore:keytool -storepasswd -keystore [PATH TO KEYSTORE]Ensure jboss alias is trusted within the JBoss keystoreThe jboss alias must be a trustedCertEntry with the JBoss Java keystore. This allows code signed by with the default JBoss certificate to run when using a restrictive policy file.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlA keystore should be setup for production environments with JBoss as a trustedCertEntry for proper functioning of the JBoss Enterprise Application Platform.2.4LowCAT III(AV:L/AC:H/Au:S/C:P/I:P/A:N)IA-5IAIA-1,IAIA-2,IATS-1,IATS-2Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:keystore "file:${JBoss.server.home.dir}/cc.keystore";Next, list the contents of the keystore using the following command:keytool -list -keystore [PATH TO KEYSTORE]The jboss alias must exist as a trustedCertEntry.To ensure the Jboss alias is a trustedCertEntry, the certificate must be imported to the keystore with the proper command:keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE] -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacertsYou can check the result with the following keytool command:keytool -list -keystore [PATH TO KEYSTORE]You should get similar results to those below:Your keystore contains 1 entry
jboss, May 17, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 93:F2:F1:8B:EF:8A:E0:E3:D0:E7:69:BC:69:96:29:C1Alternatively, the Jboss public key can be added to the Java keystore:keytool -importcert -alias jboss -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacertsIf the system Java keystore is used, the password should be changed with the following command. This may affect the functioning of other applications using the system Java keystore.keytool -storepasswd -keystore JAVA_HOME/jre/lib/security/cacertsEnsure applications deployed by JBoss present valid DoD certificates where applicableJBoss applications implementing encryption should present a valid DoD issued X.509 certificate for purposes of identifying the server.Establishing trust between clients and servers is an important part of information security. Presenting a valid X.509 certificate leverages the mutually-trusted DoD Public Key Infrastructure. Failure to present a valid DoD certificate undermines user confidence, presents an inconsistent user experience for security, and creates potential for abuse of trust by malicious entities.3.5MediumCAT IIIA-5IAIA-1,IAIA-2,IATS-1,IATS-2Using a web browser or similar tool, access deployed JBoss applications that implement encryption and certificate exchange. Examine the X.509 certificate presented to the browser by the server. The certificate must meet the following requirements:The certificate must match the domain name of the webserver being accessed. This can be determined by comparing the DNS name used in the browser to the DNS name on the presented certificate.The certificate must not be expired. This can be determined by reviewing the expiration dates on the server's certificate.The certificate must be issued by a DoD approved Certificate Authority. This can be determined by examining the issuing hierarchy of the presented certificate. Valid Certificate Authorities can be found here: https://crl.gds.disa.mil/The certificate must not be revoked. This can be determined by enabling revocation checking on the web browser or manually reviewing the revocation list identified by the certificate.The certificate public key length must be at least 1024 bits.The JBoss administrator must work with the local security manager and certificate registrar to successfully request a certificate from a DoD Certificate Authority.Once a valid X.509 certificate has been obtained from a Certificate Authority within the DoD PKI, the certificate and associated private key can be installed in the JBoss keystore. The following example imports a PCKS12 public/private key pair into a Java Key Store.
keytool -importkeystore -v -srckeystore KEYSTORE.p12 -srcstoretype PKCS12 -keystore NEW_KEYSTORE.jksThe final step is to enable TLS on whichever Tomcat connector is used by the deployed application.
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/NEW_KEYSTORE.jks"
keystorePass="KEYSTORE_PASSWORD" sslProtocol = "TLS" />
Ensure X.509 keystore utilized by JBoss for certificate trusts contains DoD approved Certificate AuthoritiesJBoss applications implementing encryption should utilize the DoD Public Key Infrastructure.Establishing trust between clients and servers is an important part of information security. Validating client X.509 certificates against the DoD Public Key Infrastructure leverages the enterprise trust system. Failure to validate client certificates undermines the enterprise trust infrastructure and makes the JBoss server vulnerable to trust abuse exploits.3.5MediumCAT IIIA-5IAIA-1,IAIA-2,IATS-1,IATS-2Determine which keystore is being used by JBoss. Check for keystore definition lines within any .policy files loaded by the Java Security Manager to determine the path to the keystore. For example:keystore "file:${JBoss.server.home.dir}/jboss.keystore";List the contents of the keystore using the following command:keytool -list -keystore [PATH TO KEYSTORE]All currently active DoD Certificate Authorities must exist as trustedCertEntry. At the time of this writing, there were 39 separate Certificate Authorities controlled by DoD that should be trusted.Download and install the DoD CA certificates. Currently, the CA certificates can be retrieved from https://crl.gds.disa.mil/.The keys can be added to the keystore with a command similar to the following:keytool -importcert -keystore [PATH TO KEYSTORE] -storepass [KEYSTORE PASSWORD] -file [PATH TO CERTIFICATE] -noprompt -trustcacertsEnsure deployed applications requiring authentication utilizes DoD PKI Class 3 or Class 4 certificate and hardware security token or NSA-certified productJBoss applications implementing authentication should utilize the DoD Public Key Infrastructure. The DoD Public Key Infrastructure is designed to use hardware tokens such as the Common Access Card in conjunction with issued X.509 certificates. These tokens are typically protected with a PIN that unlocks access to the private certificate stored on the token.JBoss Enterprise Application Platform Security Guide, 2011Leveraging the DoD Public Key Infrastructure increases the security of an application because the DoD PKI raises the bar for exploitation of user identities. Applications that require authentication and do not utilize PKI must then rely on a less secure form of authentication, such as username and password. Additionally, current DoD guidance requires the use of DoD PKI over username and password.5MediumCAT IIIA-5IAIA-1,IAIA-2,IATS-1,IATS-2There are many options for implementing this rule on deployed applications. Authentication using DoD's PKI can be accomplished using JBoss itself, the webserver underneath JBoss, or a traffic aggregator in front of JBoss. This rule focuses on configuration of JBoss to authenticate users with a PKI. This rule requires multiple steps to validate.First, determine if authentication is required by the deployed application. Review the deployed application's jboss-web.xml (JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/) file to ensure that a security domain has been referenced. For example:<security-domain>java:/jaas/JBossTestRealm</security-domain>Next, review the deployed application's web.xml (JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/) file to ensure that resources within the web application have been identified to be secured. The <auth-method> element MUST contain CLIENT-CERT in order to implement certificate-based authentication. For example:<security-constraint>
<web-resource-collection>
<web-resource-name>TestResource</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>JBossTestRole</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Test realm</realm-name>
</login-config>
<security-role>
<role-name>JBossTestRole</role-name>
</security-role>Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined
in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlCheck the <application-policy> element to ensure it has modules defined for authentication. This <login-module> MUST contain the following attributes:code="org.jboss.security.auth.spi.BaseCertLoginModule"flag="required"Example of a satisfactory element:<application-policy name="JBossTestRealm">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">testUsers.properties</module-option>
<module-option name="rolesProperties">testRoles.properties</module-option>
</login-module>
</authentication>
</application-policy>Additional modules can be included to shape the exact functionality desired. For example, <module>s such as SubjectCNMapping can be included to perform attribute mapping.Finally, the client certificate's Distinguished Name field must be mapped to a certificate alias stored in the a keystore. The keystore will be defined in the JaasSecurityDomain MBean. For example:<mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.ch8:service=SecurityDomain">
<constructor>
<arg type="java.lang.String" value="JBossTestRealm"/>
</constructor>
<attribute name="KeyStoreURL">resource:localhost.keystore</attribute>
<attribute name="KeyStorePass">cleartext-password-that-should-be-masked</attribute>
</mbean>First, setup an <application-policy> that enforces certificate-based authentication. This can be accomplished in the following files:JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlThe <application-policy> should resemble the example below:<application-policy name="JBossTestRealm">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">testUsers.properties</module-option>
<module-option name="rolesProperties">testRoles.properties</module-option>
</login-module>
</authentication>
</application-policy>Next, add the <application-policy> to the deployment descriptors and setup the <security-constraint>.JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml<security-domain>java:/jaas/JBossTestRealm</security-domain>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/web.xml<security-constraint>
<web-resource-collection>
<web-resource-name>TestResource</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>JBossTestRole</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Test realm</realm-name>
</login-config>
<security-role>
<role-name>JBossTestRole</role-name>
</security-role>Define a keystore to be used via the JaasSecurityDomain MBean:JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/jboss-service.xml:<mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.ch8:service=SecurityDomain">
<constructor>
<arg type="java.lang.String" value="JBossTestRealm"/>
</constructor>
<attribute name="KeyStoreURL">resource:test.keystore</attribute>
<attribute name="KeyStorePass">cleartext-password-that-should-be-masked</attribute>
</mbean>Finally, import the client certificates into the keystore using the keytool command. For example:keytool -importcert -alias "DN ON THE CERTIFICATE" -keystore JBOSS_HOME/server/[PROFILE]/conf/test.keystore -file [PATH TO CERTIFICATE]Enable Federal Information and Processing Systems 140-2 (FIPS) compliant cryptographic modules for use by JBoss Java environmentWhile JBoss itself has no need to load FIPS compliant modules, the underlying technologies such as Java and the Apache Tomcat webcontainer do. Utilizing only FIPS compliant modules decreases compatibility with applications that are not FIPS enabled.JBoss Enterprise Application Platform 5 Security Guide, 2011 Enabling FIPS compliant algorithms ensures that the underlying technologies that JBoss works through are using cryptographic modules that have been vetted by NIST for security, stability, and strength. Failure to utilize FIPS certified modules may cause the underlying technologies used by JBoss to utilize older, less secure algorithms. Failure to enable only FIPS compliant modules may also have regulatory consequences, as FIPS 140-2 requires the use of FIPS compliant modules by all federal agencies.4.0MediumCAT IISC-13DCNR-1,ECCR-1,ECCR-2,ECCR-3,ECCT-1,ECCT-2,ECNK-1,ECNK-2Validating this rule is a multi-step process.First, ensure that the FIPS compliant providers are enabled in the Java security files.
For IBM JRE/JDK 6.x:Check for the following provider in the JAVA_HOME/jre/lib/security/java.security file:security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPSNOTE: The FIPS compliant provider MUST be at the top of the list as #1.Ensure the following line exists in the System.Defaults properties file:com.ibm.jsse2.usefipsprovider=trueFinally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImplssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImplFor Sun JRE/JDK 6.x:Check for the following providers in the JAVA_HOME/jre/lib/security/java.security file:security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSSNOTE: The FIPS compliant provider MUST be at the top of the list as #1Next, review the application source code to ensure that the proper constructors are utilized for FIPS compliant algorithms. Review the constructor used to initialize SunJSSE and ensure that the FIPS compliant mode has been enabled.Lastly, perform a packet capture of the TLS handshake to ensure that only FIPS 140-2 algorithms are selected by the server (ServerHello message).As this check is not specific to JBoss, validation steps will vary dependent on the Java vendor in use.For IBM JRE/JDK 6.x:Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPSNOTE: There will be a list of several providers already in place, numbered 1 to X. The FIPS compliant providers MUST go at the top of the list as #1 and #2. The other providers must be re-numbered.Ensure the following line exists in the System.Defaults properties file:com.ibm.jsse2.usefipsprovider=trueFinally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImplssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImplFor Sun JRE/JDK 6.x:Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSSNOTE: There will be a list of several providers already in place, numbered 1 to X. The FIPS compliant provider MUST go at the top of the list as #1. The other providers must be re-numbered.Now the deployed applications must be written to take advantage of the FIPS enabled providers. The Sun SunJSSE provider must be initialized at run-time with the FIPS boolean value as true.Eliminate clear-text passwords: data sourcesEliminate clear-text passwords in data source configuration files. The class org.jboss.resource.security.SecureIdentityLoginModule can be used to both encrypt database passwords and to provide a decrypted version of the password when the data source configuration is required by the server. The SecureIdentityLoginModule uses a hard-coded password to encrypt/decrypt the data source password.JBoss Enterprise Application Platform 5 Security Guide, 2011 Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.3.7MediumCAT II(AV:L/AC:H/Au:N/C:P/I:P/A:P)SC-28ECCR-1,ECCR-2,ECCR-3Review data source file located within JBOSS_HOME/server/deploy/ and subdirectories. Data sources with encrypted passwords will no longer have <user-name> or <password> elements, and will instead reference a <security-domain>.Following the extensive instructions located within Chapter 17, "Encrypting Data Source Passwords" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. While too lengthy to contain here, the summarized steps include:Encrypt the data source password.Create an application authentication policy with the encrypted password.Configure the data source to use the application authentication policy.Eliminate clear-text passwords: Tomcat ConnectorsEliminate clear-text passwords in: Tomcat Connectors.JBoss Enterprise Application Platform 5 Security Guide, 2011 Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.3.7MediumCAT II(AV:L/AC:H/Au:N/C:P/I:P/A:P)SC-28ECCR-1,ECCR-2,ECCR-3Review JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml for evidence of clear-text passwords in Connectors. These Connectors will contain a <attribute name="KeyStorePass"> or a keystorePass attribute as part of the <Connector> element, with a clear-text password. Following the extensive instructions located within Chapter 18, "Encrypting the Keystore Password in a Tomcat Connector" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. While too lengthy to contain here, the summarized steps include:Configure JaasSecurityDomain MBeanGenerate encrypted passwordUpdate the Tomcat service MBeanEliminate clear-text passwords: XML configuration filesUsing password masking, eliminate clear-text passwords in XML configuration files.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJBoss Enterprise Application Platform 5 Security Guide, 2011Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.3.7MediumCAT II(AV:L/AC:H/Au:N/C:P/I:P/A:P)SC-28ECCR-1,ECCR-2,ECCR-3Review configuration files for evidence of clear-text passwords. No clear-text passwords should exist in XML configuration files (password masking should be used instead).Follow the extensive instructions located within Chapter 16, "Masking Passwords in XML Configuration" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. These instructions are too lengthy to summarize here.Change default password: JBoss Messaging MessageSuckerJBoss Messaging ships with a default MessageSucker password located within the Messaging ServerPeer configuration. This password is used by JBoss to create connections and pass messages between nodes.JBoss Enterprise Application Platform 5 Security Guide, 2011 The SuckerPassword ships with a default clear-text password that can be used by attackers to pass messages to default installations of Jboss. The exact content and ramifications of these messages will depend on the listening applications (application logic, input validations, etc.). Failure to change this password can allow an attacker to create connections and pass messages to nodes.7.5HighCAT I(AV:N/AC:L/Au:N/C:P/I:P/A:P)IA-5IAIA-1,IAIA-2,IATS-1,IATS-2Review the Jboss Messaging configuration file for the Messaging ServerPeer located here:
JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-jboss-beans.xml
Ensure the <property name="suckerPassword" > has been changed from the default of "CHANGE ME!".Open the Jboss Messaging configuration file for the Messaging ServerPeer located here:
JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-jboss-beans.xml
Locate the element <property name="suckerPassword" > and change the contents to a new password generated in accordance with your organization's password security requirements, restricting the use of predefined XML entities such as <'>@" or escaping them if you do. For example:<property name="suckerPassword" >Lmf3SdntiDFF6(D5</property>The encrypted version of this password can be added to JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-service.xml by following the directions located in Follow the extensive instructions located within Chapter 16, "Masking Passwords in XML Configuration" of the JBoss Enterprise Application Platform 5 Security Guide, 2011.Change default password: Java cacerts keystoreThe Java cacerts keystore is installed by default with most versions of Java. It contains X.509 public certificates for a set of default commercial Certificate Authorities.To prevent compromise of the server's X.509 trust chains, the well-known default password on the cacerts keystore should be changed. Failure to change this password could lead to the malicious modification of trusted X.509 CA's.This would allow attackers to create connections as trusted entities, sign malicious could as a trusted entity, or create any other number of X.509 certificate abuses.2.6LowCAT III(AV:L/AC:H/Au:N/C:P/I:P/A:N)IA-5IAIA-1,IAIA-2,IATS-1,IATS-2Attempt to access the contents of the Java cacerts keystore at the default location using the following command:keytool -list -keystore JAVA_HOME/lib/security/cacertsIf the cacerts file cannot be found in your JAVA_HOME/lib/security/, try searching the system for the file named cacerts located in the Java install path.You should be prompted for a password (non-blank). Attempt to authenticate using the default password 'changeit'If you fail to authenticate, you will receive a warning message (and the contents of the keystore will still be displayed):***************** WARNING WARNING WARNING ****************** The integrity of the information stored in your keystore ** has NOT been verified! In order to verify its integrity, ** you must provide your keystore password. ****************** WARNING WARNING WARNING *****************Using the default password 'changeit' should fail to authenticate and thus produce the warning. If the default password successfully authenticates, this check fails.Add a password to the default Java cacerts keystore:keytool -storepasswd -keystore [PATH TO KEYSTORE]Ensure Security Audit Appender is enabledThe Security Audit Appender must be enabled. The Security Audit Appender and the Security Audit Provider category together set up the audit infrastructure that allows deployed applications to easily audit authentication and authorization events. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlEnabling the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.4MediumCAT IIAU-12ECAT-1,ECAT-2Ensure the Security Audit Appender is defined within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. By default, the Security Audit Appender exists and just needs to be uncommented.<!-- Security AUDIT Appender -->
<appender name="AUDIT" class="org.jboss.logging.appender.DailyRollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="File" value="${JBoss.server.log.dir}/audit.log"/>
<param name="Append" value="true"/>
<param name="DatePattern" value="'.'yyyy-MM-dd"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%c] (%t:%x) %m%n"/>
</layout>
</appender>Ensure Security Audit Provider is enabledThe Security Audit Provider category must be enabled for production environments. The Security Audit Appender and the Security Audit Provider category together set up the audit infrastructure that allows deployed applications to easily audit authentication and authorization events. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlEnabling the Security Audit Provider category is a necessary component of comprehensive auditing in a secure production environment.4MediumCAT IIAU-12ECAT-1,ECAT-2Ensure the Security Audit Provider category is defined within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. By default, the Security Audit Provider category exists and just needs to be uncommented.<!-- Category specifically for Security Audit Provider -->
<category name="org.jboss.security.audit.providers.LogAuditProvider" additivity="false">
<priority value="TRACE"/>
<appender-ref ref="AUDIT"/>
</category>Ensure Configure SecurityInterceptor logging level is set correctlyProduction environments of JBoss require enhanced auditing on the SecurityInterceptor class. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlEnabling TRACE priority logging on the SecurityInterceptor class is a necessary component of comprehensive auditing in a secure production environment.4MediumCAT IIAU-12ECAT-1,ECAT-2Ensure a category is defined for SecurityInterceptor class with a priority of TRACE within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.<category name="org.jboss.ejb.plugins.SecurityInterceptor">
<priority value="TRACE" />
<appender-ref ref="AUDIT" />
</category>Ensure logging is enabled for Microcontainer bootstrap operationsProduction environments of JBoss require auditing for Microcontainer bootstrap operations. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlLogging Microcontainer bootstrap operations is a necessary component of comprehensive auditing in a secure production environment.4MediumCAT IIAU-3,AU-12ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2Set the priority and appender-ref levels for the Microcontainer bootstrap by adding the <category> block as specified to JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.<category name="org.jboss.bootstrap.microcontainer">
<priority value="INFO"/>
<appender-ref ref="AUDIT"/>
</category>Ensure logging is enabled for web-based requests if required by deployed applicationsIn the event that application requirements dictate additional logging for web-based requests, the AccessLogValve should be enabled.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlIf application owners determine that additional logging of web-based requests is desired, it should be enabled.4MediumCAT IIAU-3,AU-12ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2If logging of web-based requests has been required for deployed applications the AccessLogValve should be enabled. To check the status of the <Valve>, ensure the following element is defined within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml.<Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" />Ensure the following <Valve> exists within: JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. By default, this <Valve> simply needs to be uncommented.<Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" />Ensure all required information is displayed in <layout>The Security Audit Appender must log all identified information. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlLogging full event information to the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.3LowCAT IIIAU-12ECAT-1,ECAT-2Enable server startup and shutdown events by making the following change to JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. Update the ConversionPattern parameter in the Security Audit Appender to show thread information by replacing the default ConversionPattern with the pattern below:<!--The full pattern: Date MS Priority [Category] (Thread:NDC) Message -->
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
</layout>Production applications should not log output to the JBoss consoleTurn off console logging in production. Console logging in a production environment is a needless drain on system resources. JBoss Enterprise Application Platform 5 Security Guide, 2011 Logging to console is a potentially resource intensive activity that should be disabled in production environments. Additionally, disabling console logging removes a potential source of information leakage.3LowCAT IIIAU-9ECTB-1,ECTP-1In order to prevent JBoss from logging to console, open the JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml file. Next, remove or comment out the <appender-ref> element with a ref attribute value of 'CONSOLE'. This <appender-ref> element will be a child of the <root> element, typically located near the end of the document.<root>
<!--Set the root logger priority via a system property. Note this is parsed by log4j,
so the full JBoss system property format is not supported; e.g.
setting a default via ${jboss.server.log.threshold:WARN} will not work.-->
<priority value="${jboss.server.log.threshold}"/>
<!-- appender-ref ref="CONSOLE"/ -->
<appender-ref ref="ASYNC"/>
</root>Ensure JBoss process owner is executing with least privilegeOperating environment permissions assigned to the JBoss process owner should be in compliance with the principle of least privilege.In order to reduce the potential impact of exploitation against the JBoss application server (and the rest of the operating environment), the JBoss process owner should execute with as few permissions as possible in the environment (if the account is not local to the operating system or is distributed across multiple operating systems). Failure to limit permissions can dramatically increase the severity of exploits against the JBoss server, such as the execution of arbitrary code.5.1MediumCAT II(AV:N/AC:H/Au:N/C:P/I:P/A:P)AC-6ECLP-1Work with the JBoss administrator to identify the JBoss process owner account. Determine if the account is local to the host operating system or is elsewhere in the environment. On Red Hat or Linux systems look for a service definition for JBoss within /etc/init.d/. On Windows systems, check for a service definition within the Services console (services.msc). Assuming JBoss is running, either operating system can also determine the JBoss process owner by examining the currently executing process.Next, work with the JBoss administrator to identify the permissions the JBoss process owner executes with. This procedure will vary based on the host operating system. On Red Hat or Linux systems, check the group membership for the account. On Windows systems, review the User Rights Assignments within the Local Security Policy console (secpol.msc).This check fails if the JBoss process owner is not executing with least privileges. The following list identifies common scenario failures:The JBoss process owner is a privileged account such as root or administrator.The JBoss process owner is a member of a privileged group, such wheel, root, administrators, power users, domain admins, backup operators, etc.The JBoss process owner is used by multiple applications via use of username and password or group membership.The JBoss process owner account has unnecessary network access to other operating systems or other network nodes, typically through the use of a directory based account with no logon restrictions.Steps for implementing this configuration will vary dependent upon operating system. On Red Hat or Linux systems, use /etc/group and /etc/passwd to assign the JBoss process owner a unique local account and group (and limit its group membership). Windows systems can create local accounts through the Computer Management console (compmgmt.msc) and User Rights Assignments managed through the Local Security Policy console (secpol.msc)..Deny the JBoss process owner console accessThe JBoss Application Server process owner should not have interactive console login access.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJBoss Enterprise Application Platform 5 Security Guide, 2011In order to limit access in the event of an exploitation of the Jboss or one of its deployed applications, the account owning the Jboss process should be limited in its ability to interact with the supporting operating system where possible. Thus, the JBoss process owner account should not have interactive console access. 4.1MediumCAT II(AV:L/AC:M/Au:S/C:P/I:P/A:P)AC-6Steps for validating this configuration will vary, dependent upon operating system:Red Hat Enterprise Linux: Interview JBoss administrators or review running processes with ps to identify the JBoss process owner account. Next, review the /etc/passwd file to ensure that the JBoss process owner account is not assigned a login shell (the shell field should read /sbin/nologin).Windows: Interview JBoss administrators, review the configured JBoss service, review running process with WMI or task manager to identify the JBoss process owner account. Next, using Local Security Policy Microsoft Management Console or Resultant Set of Policy MMC, ensure the JBoss process owner account has been added to the 'Deny logon locally' security policy and 'Deny log on through Remote Desktop Services' security policy.Steps for implementing this configuration will vary, dependent upon operating system:Red Hat Enterprise Linux: To prevent users from gaining interactive access to the system console, simply ensure that they are assigned no shell interpreter via the /etc/passwd file. For instance, a properly configured passwd entry for the JBoss account owner may resemble this:jboss:x:494:494:JBossAS:/var/lib/jbossas:/sbin/nologinSet JBoss file ownershipAll JBoss Enterprise Application Platform files within JBOSS_HOME should be owned by the JBoss process owner account.To prevent unauthorized modification or disclosure of JBoss configuration settings, all files within JBOSS_HOME should be owned by the JBoss process owner account.3.7MediumCAT II(AV:L/AC:H/Au:N/C:P/I:P/A:P)AC-3ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1Validate file ownership for JBOSS_HOME files and subdirectories . Owner is required to be the JBoss process owner account. The JBoss administrators may have group ownership for operating systems that support it.Use the ls command to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories); JBoss administrators should be the group owners.Steps for implementing this configuration will vary, dependent upon operating system. On Red Hat and Linux, use chown to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories); JBoss administrators may be the group owners.Windows environments can use the explorer GUI or cacls/xcacls to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories).Set JBoss file permissionsAll JBoss Enterprise Application Platform files within JBOSS_HOME should be readable by the JBoss Application Server process owner and JBoss administrators only.JBoss Enterprise Application Platform 5 Security Guide, 2011To prevent unauthorized modification or disclosure of JBoss configuration settings, access to all JBoss related files within JBOSS_HOME should be restricted to the JBoss process owner and JBoss administrators.4.3MediumCAT II(AV:L/AC:L/Au:S/C:P/I:P/A:P)AC-3,AC-6ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1Validate file permissions for JBOSS_HOME files and subdirectories. File permissions should be restricted to READ/WRITE for JBoss process owner and JBoss administrators. Other accounts that may require READ access include version control accounts or process owners for backup software.Red Hat Enterprise Linux: Use the ls command to check basic file permissions. The getfacl command can be useful as well.Steps for implementing this configuration will vary, dependent upon operating system. Red Hat Enterprise Linux: Use chmod to restrict permissions on files to at least 660 for all files in JBOSS_HOME and subdirectories.Windows environments can use the explorer GUI or cacls/xcacls to restrict permissions for all files in JBOSS_HOME and subdirectories.File permissions should be restricted to READ/WRITE for JBoss process owner and JBoss administrators. Other accounts that may require READ access include version control accounts or process owners for backup software.Securing deployed applicationsThe rules in this group are used to secure applications deployed on JBoss EAP. This includes applications that JBoss packages and deploys by default.Ensure JMX Console is either secured or removedThe JMX Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlThe JMX Console should require authentication or be removed. Failure to require authentication may allow unauthenticated users to invoke commands or gather information on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.8HighCAT I(AV:N/AC:L/Au:S/C:P/I:P/A:C)AC-3ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1This rule can be checked for compliance by either:Determine the console is not deployed.To determine if the JMX Console is deployed, check to see if the exploded WAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>).Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlCheck the <application-policy> element to ensure it requires authentication. Example of a satisfactory element:
<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>This rule can be made compliant by either:Require authentication for access to the JBoss JMX Console.First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:
<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xml
JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xml
JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlNext, check the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.Next, review the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow side channel access to malicious users.Finally, configure the usersProperties defined in the application policy to manage accounts. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/jmx-console-users.properties: # A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSXRemove the JBoss JMX Console from deployment.To remove the JMX Console from deployment, delete the exploded WAR located here: JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/Ensure Web Console is either secured or removedThe Web Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlFailure to secure the default consoles against unauthorized access can quickly lead to system compromise. The default consoles included with JBoss are a well-known attack vector that can be leveraged to load malicious code to be executed on the server.8HighCAT I(AV:N/AC:L/Au:S/C:P/I:P/A:C)AC-3ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1This rule can be checked for compliance by either:Determine the console is not deployed. To determine if the Web Console is deployed, check to see if the exploded SAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>).Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined
in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy//management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlCheck the <application-policy> element to ensure it requires authentication. Example of a satisfactory element:
<application-policy name="web-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">web-console-users.properties</module-option>
<module-option name="rolesProperties">web-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>This rule can be made compliant by either:Require authorization for access to the JBoss Web Console.First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:
<application-policy name="web-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">web-console-users.properties</module-option>
<module-option name="rolesProperties">web-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlNext, check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.Next, review the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.Finally, configure the usersProperties and rolesProperties files defined in the application policy to manage users and roles. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/web-console-users.properties:
# A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSXRemove the JBoss Web Console from deployment.To remove the Web Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/management/Ensure Administration Console is either secured or removedThe Administration Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlFailure to secure the default consoles against unauthorized access can quickly lead to system compromise. The default consoles included with JBoss are a well-known attack vector that can be leveraged to load malicious code to be executed on the server.8HighCAT I(AV:N/AC:L/Au:S/C:P/I:P/A:C)AC-3ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1This rule can be checked for compliance by either:Determine the console is not deployed.To determine if the Administration Console is deployed, check to see if the exploded WAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>).Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server
profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlCheck the <application-policy> element to ensure it requires authentication. Example of a satisfactory element (this example leverages the pre-existing jmx-console policy):
<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>Finally, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.This rule can be made compliant by either:Require authorization for access to the JBoss Administration Console.First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:
<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">web-console-users.properties</module-option>
<module-option name="rolesProperties">web-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlNext, check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.Next, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.Finally, configure the usersProperties and rolesProperties files defined in the application policy to manage users and roles. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/jmx-console-users.properties:
# A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSXRemove the JBoss Administration Console from deployment.To remove the Administration Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/The JMXInvokerServlet servlet must be secured against web attacksThe httpha-invoker.sar found in the deploy directory is a service that provides RMI/HTTP access for EJBs and the JNDI Naming service. By default older JBoss versions ship with a default set of <http-method> that allow attackers to bypass the security policy for JMX Invoker.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlRemoving the default <http-method> security constraints allows JBoss to apply configured security settings to all HTTP verbs instead of only those specified. This is a well-known attack vector and failing to remove these constraints may allow attackers to gain authenticated or unauthorized access to the JMXInvokerServlet.8.3HighCAT I(AV:N/AC:M/Au:N/C:P/I:P/A:C)AC-3ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1Review JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar/invoker.war/WEB-INF/web.xml to ensure the following lines have been removed:<http-method>GET</http-method>
<http-method>POST</http-method>Within the JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar/invoker.war/WEB-INF/web.xml file, the following lines must be removed from the web-app/security-constraint/web-resource-collection node:<http-method>GET</http-method>
<http-method>POST</http-method>The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authenticationThe jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. This interface must be made unavailable to unprivileged users which can be done by using the org.jboss.jmx.connector.invoker.AuthenticationInterceptor interceptor for performing identification and authentication using JAAS. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlThe JMXInvokerServlet should require authentication. Failure to require authentication may allow unauthenticated users to invoke commands on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.8.3HighCAT I(AV:N/AC:M/Au:N/C:P/I:P/A:C)IA-2,IA-3EBRU-1,IAIA-1,IAIA-2,IAGA-1Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the <operation> element with child element <name>invoke</name> also contains the following <interceptor>:<interceptors>
<interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
</interceptors>Next, ensure a valid authentication module is enabled for the security domain. For example, the following elements exist within logon-config.xml and implement authentication using the UsersRolesLoginModule:<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/
NOTE: The securityDomain does not have to be called jmx-console.The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authorizationThe jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. Access control for authenticated users must be configured using the interceptors of either org.jboss.jmx.connector.invoker.RolesAuthorization or org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlThe JMXInvokerServlet should require authorization. Failure to require authorization may allow unauthenticated users to invoke commands on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.8.3HighCAT I(AV:N/AC:M/Au:N/C:P/I:P/A:C)AC-3,AC-6ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the <operation> element with child element <name>invoke</name> also contains the following <interceptor>:<interceptors>
<interceptor code="org.jboss.jmx.connector.invoker.AuthorizationInterceptor" authorizingClass="org.jboss.jmx.connector.invoker.RolesAuthorization"/>
</interceptors>Next, ensure a valid authorization module is enabled for the security domain. For example, the following elements exist within logon-config.xml and implement authorization using the UsersRolesLoginModule:<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/NOTE: The securityDomain does not have to be called jmx-console. Deployed applications should display a system use banner upon accessUpon accessing the system, a notification banner, consent to use, or policy warning banner should be displayed to alert system users of the system use details. This may include items such as implied consent to monitor, privacy practices, or liability waivers.Failing to provide adequate notification of system use details to users accessing the system can create legal troubles in the event of a civil lawsuit or criminal investigation.2.0LowCAT IIIAC-8ECWM-1Access all deployed applications to determine if a warning banner is displayed. A code review showing the functional code will also suffice.This warning banner should be presented to the user prior to accessing any deployed application - commercial applications, in-house applications, or applications deployed by JBoss.Create a system use notification message for all users who access the system. This can be done in a variety of ways, but a simple JavaScript alert(); containing a warning message will suffice. This warning banner should be presented to the user prior to accessing any deployed application - commercial applications, in-house applications, or applications deployed by JBoss. The contents of the system use notification should be clear, concise, in keeping with the organizational security policy, and should have been reviewed by the organization's legal team.On DoD systems, the warning banner should read:You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.By using this IS (which includes any device attached to this IS), you consent to the following conditions:-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.-At any time, the USG may inspect and seize data stored on this IS.-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.-This IS includes security measures (e.g., authentication and access controls) to protect USG interests—not for your personal benefit or privacy.-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.Deployed applications should display a classification banner when requiredDeployed applications should present classification banners at the header and footer of each page in accordance with the applicable DoD classification guide for the environment (or in accordance with local security policies).Department of Defense, (1997). Information Security Program (DoD 5200.1-R)Prominent classification banners reduce the risk of inadvertent information disclosure or data spillage across different classification levels.2.0LowCAT IIIAC-8ECWM-1Access all deployed applications to determine if classification banners are displayed in accordance with the authoritative classification guide or local security policies. A code review showing the functional code will also suffice.These classification banners should be presented to the user on all deployed applications - commercial applications, in-house applications, and even default applications deployed by JBoss. The exact banner requirements such as text, color, and placement will vary dependent on the system classification. See the classification guide or local security manager for further guidance.Create system classification banners for all deployed applications. This can be done in a variety of ways, but using a simple linked JavaScript to create header/footer SPAN tags with inline CSS will fit the requirements.Password hashing must be enabled within the appropriate login moduleA Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI).U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlFailure to enable password hashing within a login module can result in plain-text exposure client passwords used for authentication.4.3MediumCAT II(AV:A/AC:M/Au:N/C:P/I:P/A:N)SC-8,SC-9ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xmlAn <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlThe element below should be included within a deployed application's <application-policy><login-module>:<module-option name="hashUserPassword">true</module-option>Add the following child element to any <application-policy><login-module> in use:<module-option name="hashUserPassword">true</module-option>An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlA password hashing algorithm must be defined within the appropriate login moduleA Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI). An <application-policy> can be defined in the server profile or in an application deployment descriptor.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlBy default, a hashing algorithm is not identified for hashing clear-text passwords. DoD organizations should use the SHA algorithm or higher whenever possible to prevent collision attacks against captured password hashes.4.3MediumCAT II(AV:A/AC:M/Au:N/C:P/I:P/A:N)SC-8,SC-9ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xmlAn <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlThe element should be included within a deployed application's <application-policy><login-module>:<module-option name="hashAlgorithm">SHA</module-option> Add the following child element to any <application-policy><login-module> in use:<module-option name="hashAlgorithm">SHA</module-option>An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.JBOSS_HOME/server/[PROFILE]/conf/login-config.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xmlEnterprise JavaBeans Specification v2.1 must be strictly followedThe programming restrictions mandated by the Enterprise JavaBeans Specification v2.1 must be strictly followed. For more information, refer to JSR-000153 Enterprise JavaBeans 2.1 specification. (Section 25.2, pages 562-564).U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlDeployed applications should follow identified standards, procedures, and best practices. Compliance has many benefits, including helping applications stay interoperable with other programs and containers, implementing strong security and code standards, and improving performance and efficiency.6MediumCAT IICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview developers or review product documentation to determine if deployed applications were developed in accordance with Enterprise JavaBeans 2.1 specifications. The list below denotes the restrictions identified by the specification.An enterprise bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.The enterprise bean must not attempt to directly read or write a file descriptor.The enterprise bean must not attempt to obtain the security policy information for a particular code source.The enterprise bean must not attempt to load a native library.The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.The enterprise bean must not attempt to define a class in a package.The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject, Session-Context.getEJBLocalObject, EntityContext.getEJBObject,or Entity-Context.getEJBLocalObject instead.Developers must follow Enterprise JavaBeans Specification v2.1.PolicyThe rules in this group are used to manage JBoss servers in a secure manner. These rules are policy related.Ensure adequate physical protections are in placeThe hardware and software executing JBoss Enterprise Application Platform, as well as the software critical to security policy enforcement must be protected from unauthorized modification including unauthorized modifications by potentially hostile outsiders. Reasonable physical security measures to ensure that unauthorized personnel do not have physical access to the hardware running the JBoss Enterprise Application Platform software must be implemented.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlMany software security precautions can easily be bypassed by personnel with physical access to hardware storing data or executing an application.6.9HighCAT I(AV:L/AC:M/Au:N/C:C/I:C/A:C)PE-1,PE-2,PE-3,PE-7,PE-18PEPF-1,PEPF-2,PECF-1,PECF-2,PEPS-1,PEVC-1Interview JBoss administrators and security personnel. Visually inspect physical security precautions. Review space certifications where appropriate.Implement reasonable physical access controls to protect the hardware running and storing information for JBoss Enterprise Application Platform. Typically, these sorts of protections will include locked doors, locked server cabinets, security alarms, cameras, door guards, etc. What is considered 'reasonable' will scale with the importance of the JBoss server and the sensitivity of the information it processes.Assign a JBoss administratorThere must be one or more competent individuals who are assigned to manage JBoss Enterprise Application Platform, its environment and the security of the information it contains.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlIncompetent, careless, or negligent JBoss administrators can completely invalidate a secure JBoss configuration and create numberless problems for JBoss.8HighCAT IAT-2,AT-3,AT-4PRTN-1,PETN-1Interview JBoss administrators. Review credentials and qualifications. JBoss Administrators should possess a basic level of proficiency with the software.Additionally, they must not be carelessly or willfully negligent, or hostile, and must follow the instructions provided by the administrator documentation.Ensure a minimum level of competency / expertise has been established for JBoss administrators before granting them access to production systems.Ensure documentation and procedures exist (and are followed) for routine administrative tasks.Document incident response proceduresEnsure well developed procedures exist for incident handling. Incidents include any events that are anomalous to the environment, which typically include:
Intrusions (possibly including attempts)Application failuresUnexpected platform activity such as restarts or configuration changesUnusual network traffic to or from the serverMallik, R. (2011, May). Jboss in the Trenches. Planning for incidents prior to real-life scenarios increases incident response time and mitigates damages. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.6MediumCAT IIIR-1,IR-8VIIR-1,VIIR-2Interview JBoss administrators. Review system documentation, incident response documentation, contingency documentation, and any other relevant documentation. Determine if the incident response procedures in place are robust, up-to-date, and clear.Draft formal incident response policies and procedures. Utilize national and international standards such as ISO/IEC TR 18044 or NIST Special Publication 800-61.Perform periodic incident response exercisesProduction environments should exercise incident response procedures at least annually. Environments requiring higher assurances of security should test incident response procedures more often, possibly quarterly or even monthly. Incident response procedures should cover all anomalous events.Planning for incidents and practicing procedures to be followed prior to real-life scenario improves response time and mitigates damages/losses that occur with incidents.4MediumCAT IIIR-3VIIR-1,VIIR-2Interview JBoss administrators. Review system documentation, incident response documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the incident response procedures are meaningfully exercised at least annually.Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.Document disaster recovery proceduresRobust disaster recovery documentation and procedures should exist. This documentation should include provisions for the JBoss platform, deployed applications, required source code, and supporting applications (such as authentication stores or database servers).Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.6MediumCAT IICP-1,CP-2CODP-1,CODP-2,CODP-3,COEF-1,COEF-2Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Determine if the disaster recovery procedures in place are robust, up-to-date, and feasible.Draft formal disaster response policies and procedures. Utilize national and international standards such as ISO 17799 or NIST Special Publication 800-34.Perform periodic disaster recovery exercisesProduction environments should exercise disaster recovery procedures that include provisions for the JBoss platform, deployed applications, and any required source code at least annually. Environments requiring higher assurances of disaster recovery ability should test procedures more often, possibly quarterly or even monthly.Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses. 4MediumCAT IICP-4DCSS-2,COED-1,COED-2Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the disaster recovery procedures are meaningfully exercised at least annually.Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.Identify and document application data flowsIt is recommended to identify and document application data flows. This will allow insight into what paths sensitive information takes through the application environment and what data source connections need to be encrypted.Failure to document an application's data flows reduces security, increases the chance for architectural and configuration errors, and can impede performance. Many applications use network services that are not immediately apparent. 4.3MediumCAT II(AV:A/AC:M/Au:N/C:P/I:P/A:N)SC-8,SC-9,SC-23ECTM-1,ECTM-2Examine application documentation, system architecture documentation, and any other pertinent diagrams. Interview JBoss administrators and application developers. Application data flows should be identified for all deployed applications, including the following information:Relevant protocol information (for instance, TCP traffic should record port information)Traffic destinationPurposeSensitivity of trafficApplicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.Work with JBoss administrators and application developers to document data flows for deployed applications. Information documented should include:Relevant protocol information (for instance, TCP traffic should record port information)Traffic destinationPurposeSensitivity of trafficApplicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.Java permissions for deployed applications should be documented and reviewed prior to deploymentJava permissions for applications should be documented and carefully reviewed prior to deployment. Developers and administrators should strive to balance application permissions and application functionality.Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Careful documentation, along with a thorough review will help prevent needlessly insecure permission assignments for applications. An overabundance of Java permissions can allow applications to circumvent one of Java's strongest security features - the Java Security Manager sandbox.5MediumCAT IIAC-1Review documentation for an application's permission requirements. Review policy files to determine if applications are in compliance with their documentation. In a default JBoss deployment the following policy file will be utilized by JSM (review run.conf or run.conf.bat for more):java.home/lib/security/java.securityAdditional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.Further, documentation should exist for all applications that have been granted specific permissions.Regular backups should be performedJBoss applications and configuration files should be backed up at least weekly, possibly more if needed by the environment.Failure to regularly backup JBoss configuration files and deployed applications can result in extensive downtime or information losses in the event of a disaster or other system outage.6MediumCAT IICP-9DCSW-1,COBR-1,CODB-1,CODB-2,CODB-3,COSW-1,DCWH-1Interview JBoss administrators. Review backup policies, procedures, and other applicable documentation. Review backup media and validate presence of JBoss configuration files and deployed applications. Determine if JBoss configuration files and deployed applications are backed up at least once a week - or as specified by organization documentation.Ensure backups are conducted regularly (at least once a week) in accordance with the organization backup-policy. All JBoss configuration files and deployed applications should be backed up.Auditing policy should existIn order to effectively audit and review system logs, an audit policy should be written to identify data and trends of interest.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlWithout a comprehensive audit policy and review procedures, organizations risk missing critical events or event trends within their environment. These missed events may indicate system anomalies ranging from malicious attacks, system instabilities, system misuse, etc.4MediumCAT IIAU-1,AU-2,AU-3,AU-5ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECND-2Interview JBoss administrators. Review any available auditing documentation. Determine if the auditing policy is comprehensive and the auditing procedures are usable and up-to-date.JBoss system administrators should work security team members to draft a comprehensive audit policy. Along with this auditing policy, a set of written procedures should be created that details what events or trends must be monitored, reactions, etc.Access control policy and proceduresJBoss administrators must have access to guidance regarding account creation, permissions assignments, role assignments, etc.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlA consistent, cohesive access control policy is impossible to attain without a well-documented access control policy and related procedures. Failure to do so typically results in over-assignment of access permissions for users and applications, stale access for users and applications, and other access control misconfigurations that reduce the effectiveness of the security policy.5MediumCAT IIAC-1Interview JBoss administrators. Review all relevant documentation. Determine if an access control policy exists that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. There should be an associated set of procedures with implementation details for specific tasks such as assigning user roles, creating user accounts, or assigning Java Security Manager permissions.Draft an access control policy to address purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. There should be an associated set of procedures with implementation details for specific tasks such as assigning user roles, creating user accounts, or assigning Java Security Manager permissions.Define an appropriate minimum and maximum password length requirementOrganizations should create an authenticator management policy that defines minimum and maximum password sizes for user accounts accessing JBoss and its deployed applications.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlU.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlIn brute force scenarios, passwords of extended lengths increase password security and the length of time required to decrypt the password.However, there are risks associated with requiring passwords of great lengths, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords.5.0MediumCAT IIIA-5IAIA-1,IAIA-2,IATS-1,IATS-2Work with JBoss administrators and security team members to identify and review relevant documentation. Minimum and maximum password lengths should be defined.JBoss system administrators should work security team members to draft a comprehensive password policy. Minimum and maximum password lengths should be defined. Further, accounts may be categorized in order to define varying length requirements for particular types of accounts.
For example:
User accounts shall require password lengths of between 8 and 24 charactersAdministrator shall require password lengths of 24 charactersWeb service accounts shall require password lengths of 24 characters
Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy.
NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.Define an appropriate minimum password complexity requirementOrganizations should create an authenticator management policy that defines a minimum level of complexity for user accounts accessing JBoss and its deployed applications. These requirements should also restrict passwords from containing dictionary words and reusing previous passwords.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlU.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlComplex passwords increase password security and the length of time required to decrypt the password. Additionally, complex passwords are less likely to be found in password dictionaries.However, there are risks associated with requiring overly complex passwords, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords.5.0MediumCAT IIIA-5IAIA-1,IAIA-2,IATS-1,IATS-2Work with JBoss administrators and security team members to identify and review relevant documentation. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words.JBoss system administrators should work security team members to draft a comprehensive password policy. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words. Further, accounts may be categorized in order to define varying complexity requirements for particular types of accounts.
For example:
User accounts shall require passwords containing at least 1 lowercase alphanumeric character, 1 uppercase alphanumeric character, and 1 numberAdministrator accounts shall require passwords containing at least 2 lowercase alphanumeric characters, 2 uppercase alphanumeric characters, 2 numbers, and 2 special characters. Special characters include: !@#$%^&*()Web service accounts shall require passwords containing at least 3 lowercase alphanumeric characters, 3 uppercase alphanumeric characters, 3 numbers, and 3 special characters. Special characters include: !@#$%^&*()
Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy.
NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.Define an appropriate minimum password expiration intervalOrganizations should create an authenticator management policy that defines a maximum password age for user accounts accessing JBoss and its deployed applications.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlU.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlIn combination with password length and complexity, regularly changing passwords can defeat many attacks. If a password or password hash is intercepted by a malicious party, changing the password can remove access or render invalid a cracking attempt on the hash.
However, there are risks associated with frequently changing passwords. Users may take steps to circumvent policy such as using repetitive passwords or using password derivatives. Additionally, changing passwords for system or application accounts introduces an element of configuration risk. Poorly coordinated or documented changes can result in system outages or create other problems.5.0MediumCAT IIIA-5IAIA-1,IAIA-2,IATS-1,IATS-2Work with JBoss administrators and security team members to identify and review relevant documentation. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words.JBoss system administrators should work security team members to draft a comprehensive password policy. Password expiration requirements should be defined. Further, accounts may be categorized in order to define varying length requirements for particular types of accounts.
For example:
Passwords for user accounts must expire every 90 daysPasswords for administrator accounts must expire every 30 daysPasswords for web service accounts must expire every 180 days
Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy.
NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.ArchitectureThe rules in this group are used to manage JBoss servers in a secure manner. These rules are related to deploying a secure architecture.Production JBoss EAP installations should reside on a dedicated platformProduction JBoss servers in production environments should be hosted on dedicated operating systems and not sharing a host operating system with other service applications.Co-locating JBoss EAP with other critical infrastructure components in an organization can have multiple negative impacts on an organization's security posture. Applications sharing host operating systems cumulatively increase the surface area of attack for the other (including indirectly), increase the likelihood of resource contention, and increase the severity of any problems that do occur on the platform at a business process level.5MediumCAT IICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview JBoss administrators, review system documentation and architecture diagrams. Review applications hosted by the same operating system as JBoss. Determine if JBoss Enterprise Application Platform installations are hosted on dedicated operating systems. JBoss installations should not be hosted by the same operating system that may be hosting other organization resources such as name resolution servers, directory servers, or database servers.Installations of JBoss should reside on a dedicated operating system. If not, ensure the configuration, rationale, and risk assessment is well documented. Avoid multiple JBoss instances per serverMultiple instances of JBoss deployed onto a single server should be avoided whenever possible to reduce environmental complexity and administrative burdens. However, occasionally circumstances require that multiple JBoss instances are deployed to the same server. In this scenario, the configurations and justifications should be documented along with the rest of the system's documentation. Mallik, R. (2011, May). Jboss in the Trenches.Multiple JBoss instances on a single server may occasionally become necessary due to resource or design constraints. However, this practice increases the complexity and administrative burden for the application servers - potentially leading to unforeseen problems and increasing chance of misconfigurations.5MediumCAT IICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview JBoss administrators, review system documentation and architecture diagrams. Determine if JBoss Enterprise Application Platform installations are limited to one per server. If they are not limited to one per server, ensure the configuration, rationale, and risk assessment is well documented.Limit JBoss Enterprise Applications Platform instances to one per server if possible. If not, ensure the configuration, rationale, and risk assessment is well documented. Bind multiple JBoss instances per server to different IPsIf multiple JBoss instances are installed, the servers should be set to bind to different IP addresses on the server rather than changing the default port configuration.Mallik, R. (2011, May). Jboss in the Trenches. Binding to different IP addresses eases administrative and maintenance burdens by reducing the number of variables between instances. In turn, this increases reliability and reduces the chances for configuration errors.3.5MediumCAT IICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview JBoss administrators and review system documentation. Examine running JBoss servers and bound ports using commands like netstat. If multiple JBoss instances are deployed to a single server, it is a best practice to bind each instance to its own IP address.If multiple JBoss Enterprise Application Platforms are deployed to a single server, the binding IP address can be specified at server startup using the -b argument to specify the binding IP. Example:run.sh -c public -b 10.10.10.75Packet filtering should be emplaced around JBoss Enterprise Application PlatformJBoss Enterprise Application Platform must operate in a network segment that is logically separated from any other network segment using a packet filtering mechanism. This packet filter must only allow incoming communication that is TCP with destination ports of 8080 or 8443. This packet filter can be resident on the host operating system or a completely separate system entirely. When JBoss Enterprise Application Platforms are clustered, all outgoing communication from the JBoss Enterprise Application Platform instance must be allowed.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlPacket filtering is a basic security technique for securing TCP/IP and UDP/IP communications.9.3HighCAT I(AV:N/AC:M/Au:N/C:C/I:C/A:C)SC-7DCSS-2,EBBD-1,EBBD-2,EBBD-3,EBPW-1,ECID-1Interview JBoss administrators and architects. Review system network diagrams. Work with JBoss administrators to review ipfilter rulesets to ensure the TCP/IP and UDP/IP packet filters are protecting the JBoss Enterprise Platform. The packet filters must only allow incoming communication that is TCP with destination ports of 8080 or 8443. This packet filter can be resident on the host operating system or a completely separate system entirely.When JBoss Enterprise Application Platforms are clustered, all outgoing communication from the JBoss Enterprise Application Platform instance must be allowed.Install and/or configure a TCP/IP and UDP/IP packet filtering device to logically separate the JBoss Enterprise Application Server from other networks. Do not transmit sensitive information over unsecured HTTP connectionsSensitive information should not be transferred over insecure means. This includes plaintext credential information, application information deemed sensitive, or other information that may be valuable to a malicious entity.
The <auth-method> child element specifies the authentication mechanism for the web application. Using the BASIC authentication method causes the exchange of credentials in clear-text.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlJBoss Enterprise Application Platform 5 Security Guide, 2011Sensitive information being transmitted without strong encryption creates possible exposure for the deployed application and users connecting to it.
Plain text transmission of authentication credentials over insecure channels (such as HTTP) exposes credential information to any entity capable of intercepting packets from the connection.4.3MediumCAT II(AV:A/AC:M/Au:N/C:P/I:P/A:N)SC-8ECTM-1,ECTM-2Interview JBoss administrators and application developers. Review application documentation. Descriptive information for sensitive data used by the application should be readily available. Ensure this information is secured with SSL 3.x or TLS. There are multiple ways to secure the connections - the most common being configuration of the Apache Tomcat container (JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml).Real-world tests using a browser, wget, and a packet capture utility may also assist in validating the level of encryption for sensitive information.Applications passing sensitive data should use a secure channel such as SSL or TLS. There are several ways to secure traffic with SSL, the method below uses the underlying Apache Tomcat technology to handle the connection.To setup SSL or TLS, proceed as follows:Ensure a valid keystore is being loaded by JSMLoad the JBoss server's public/private key pair into the keystore Add a secure connector to JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml
<Service name="jboss.web">
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/bp.keystore"
keystorePass="KEYSTORE_PASSWORD" sslProtocol = "TLS" />
</Service>PolicyThe rules in this group are used to manage JBoss servers in a secure manner. These rules are related to general best practices.Use a version control repositoryAll configuration files (such a data sources, custom connectors, etc) and any scripts used for modifications and deployments should be stored in the version control repository. Typical repositories include applications such as SVN or Git.
Additionally, a hash-validated 'Gold' version of the JBoss installation package should also be stored in the version control system.Mallik, R. (2011, May). Jboss in the Trenches. Configuration management is an essential part long-term success for any software application - especially for complex software or collaborative environments. Using a versioning system allows for tighter control and accountability of application server changes.Maintaining a 'Gold' version of JBoss is useful for environments that may need to periodically or dynamically deploy JBoss instances. This can also be useful for static environments that simply desire to have a known baseline to deploy from.5MediumCAT IICM-3,CM-5DCCB-1,DCCB-2,ECPC-1,ECPC-2,DCSL-1,ECSD-1,ECSD-2Interview JBoss administrators and/or platform administrators. Review evidence of version control system and its use.Initiate a version control repository such as Git or SVN for JBoss maintenance and deployments. This will likely be a multi-stage process requiring planning and implementation.Automate JBoss DeploymentsScripts or other software tools should be used to automatically configure and deploy JBoss applications in environments.Mallik, R. (2011, May). Jboss in the Trenches. As much as possible new application deployments to JBoss should be scripted. This increases standardization in deployments and reduces the possibility of errors and misconfigurations. Smaller environments may see less benefit from implementing an automated process.5MediumCAT IICM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview JBoss administrators and review procedural documentation. Determine if applications are deployed to JBoss Enterprise Application Platforms in an automated manner. The level of automation should be assessed vs. the costs for implementation.Utilize custom scripts and/or software to automate application deployments to JBoss. Popular applications in this field include Cargo, ANT, JBoss Tools, and Hudson. Software in this category is quickly evolving and adding new features. Application performance testingEnsure routine performance testing is completed before applications are deployed to production. Establish and document performance profiles.Mallik, R. (2011, May). Jboss in the Trenches. Without adequate performance testing, production applications may fail to perform to expectations - resulting in a denial of service.3.5MediumCAT IISA-3DCSP-1Interview JBoss system administrators and application developers. Review product documentation related to performance testing and load limits. Review policy and procedural documents related to performance testing. Production environments should have documented and established performance profiles. Applications should be performance tested prior to deployment to production environments.Ensure routine performance testing is completed before applications are deployed to production. Establish and document performance profiles. Attempt to test against anticipated peak demands as well as load averages. Individual tests will vary, but commonly consist of testing message throughputs (various message types), application inputs, connections open/closed/expired, data transactions completed, method calls, objects persisted, etc.Monitor JBoss serversJBoss Enterprise Application Platform servers in production environments should be monitored real-time. Information monitored and alarm thresholds will vary. Common monitoring tools include:
JBoss Operations Network (JON)FoglightHP OpenviewNagiosMallik, R. (2011, May). Jboss in the Trenches. Production environments should be carefully monitored to ensure the any problems on the server are detected as quickly as possible. Identifying and isolating a problem when it is small may prevent downtime or other problems on the network.6MediumCAT IIAU-3,AU-6,AU-7,AU-12ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2,ECRG-1Interview JBoss system administrators. Review server documentation and system architecture diagrams. Review documents related to server monitoring. Production environments should have a real-time monitoring solution in place.Research and implement an appropriate monitoring solution for the production environment. Different environments will have different requirements owing to sensitivity to downtime, regulatory requirements, service agreements, and other factors. Be careful when implementing a monitoring solution to minimize performance impact on the servers where possible. Common monitoring tools include:JBoss Operations Network (JON)FoglightHP OpenviewNagiosCommon metrics include:Active threads on the application serverThreads on the front-end http/ajp web connectorDatabase connection poolsJVM metrics such as memory usage and GCsTypical host platform metrics such as available hard drive space, CPU usage, etc. Ensure all downloaded software is authenticSoftware and packages should be downloaded from redhat.com, and hash validated.U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlWithout validating downloaded files are authentic, malicious users may compromise software before it has even been installed. Attackers may redirect traffic to alternate download locations and attempt to trick administrators into downloading modified software.6.2MediumCAT II(AV:L/AC:H/Au:N/C:C/I:C/A:C)CM-6DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1Interview JBoss administrators. JBoss administrators must demonstrate proficiency in securely acquiring JBoss Enterprise Application Platform installation materials.When downloading software, first ensure it is coming from the site you expect it to. For instance, when downloading JBoss Enterprise Application Platform from Red Hat, JBoss administrators should review the X.509 certificate presented by the remote server to ensure the authenticity of the site.Next, JBoss administrators should hash validate files after completed downloads. Hash generation will vary depending on operating system. These hashes should be compared to one of the hashes available on the Red Hat website.Ensure JBoss is configured in accordance with Common Criteria configuration guidesJBoss deployments in government and DoD organizations require JBoss be deployed in a Common Criteria certified configuration. The Common Criteria configuration is a list of technical configuration items, policy requirements, and other configurations required to certify a JBoss installation at the EAL4+ protection level. Red Hat maintains configuration guidance available online to assist administrators during the installation and configuration of JBoss (http://docs.redhat.com/docs/en-US/index.html).U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.htmlBy deviating from a Common Criteria configuration, JBoss will no longer be considered certified against any protection level - this may have legislative or regulatory consequences that must be identified and risk assessed dependent on your environment.6.2MediumCAT IISA-4DCAS-1,DCSR-1,DCSR-2,DCSR-3Interview JBoss administrators and review on-site documentation. Review the JBoss Common Criteria Configuration Guide (available here from Red Hat's website) to ensure JBoss has been installed and configured in accordance with the Common Criteria requirements.Configure JBoss in its Common Criteria certified configuration. The configuration guide can be found here on Red Hat's website.TrimmingThe rules in this group concern trimming JBoss EAP.Unused features should be disabled or deleted: Java Universal Description, Discovery, Integration (JUDDI)Features and services not in use should be removed. JUDDI is an open source Java implementation of the Universal Description, Discovery, and Integration (UDDI v3) specification for (Web) Services.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfJUDDI; An Apache Project. (February 6, 2012). Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sarIn order to completely disable the this component, take the following actions:
Delete this directory:JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sarUnused features should be disabled or deleted: Enterprise Java Beans (EJB) ServicesFeatures and services not in use should be removed.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jarJBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xmlJBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jarJBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml In order to completely disable the this component, Delete the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jarJBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xmlJBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jarJBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml Unused features should be disabled or deleted: Universal Unique Identifier (UUID) GeneratorFeatures and services not in use should be removed. UUID Generator allows for the generation of unique identifiers for hosted Java applications.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sarIn order to completely disable the this component, Delete this directory:JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sarUnused features should be disabled or deleted: Java Message Service (JMS)Features and services not in use should be removed. Java Message Service is a component of Java Enterprise Edition that enables application to send and receive messages. It is a cornerstone service that many distributed applications are built on.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.propertiesJBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.propertiesJBOSS_HOME/server/[PROFILE]/deploy/messagingJBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rarJBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rarJBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xmlValidate changes to the following files:Ensure all elements with references to JMS have been removed from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xmlEnsure the following <property> element has been removed from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>In order to completely disable this component, take the following actions:Delete these files and directories:JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.propertiesJBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.propertiesJBOSS_HOME/server/[PROFILE]/deploy/messagingJBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rarJBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rarJBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xmlMake the identified changes to the following files:Remove all elements with references to JMS from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xmlRemove the following <property> element from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>Unused features should be disabled or deleted: JBoss MailFeatures and services not in use should be removed. JBoss Mail is a deployed package for Java Mail - a set of Java API's implementing an email server supporting the SMTP, POP3, and IMAP protocols.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rarJBOSS_HOME/server/[PROFILE]/deploy/mail-service.xmlIn order to completely disable the this component, Delete the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rarJBOSS_HOME/server/[PROFILE]/deploy/mail-service.xmlUnused features should be disabled or deleted: JBoss SchedulingFeatures and services not in use should be removed. JBoss Scheduling implements a JBoss service that supports scheduling and running jobs for deployed Java applications.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xmlJBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml In order to completely disable the this component, Delete the following files:JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xmlJBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml Unused features should be disabled or deleted: Hypersonic SQL Database (HSQLDB)Features and services not in use should be removed. HSQLDB is the default datasource configured to run with JBoss Enterprise Application Platform out of the box. It is not recommended for production usage.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xmlJBOSS_HOME/common/lib/hsqldb.jarJBOSS_HOME/common/lib/hsqldb-plugin.jarJBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xmlJBOSS_HOME/server/[PROFILE]/data/hypersonic/In order to completely disable the this component, Delete the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xmlJBOSS_HOME/common/lib/hsqldb.jarJBOSS_HOME/common/lib/hsqldb-plugin.jarJBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xmlJBOSS_HOME/server/[PROFILE]/data/hypersonic/Unused features should be disabled or deleted: BeanShell (BSH) DeployerFeatures and services not in use should be removed. The BSH Deployer allows for the hot deployment of one use execution scripts or services.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployerIn order to completely disable the this component, Delete the following files and directories:JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployerUnused features should be disabled or deleted: JBossWSFeatures and services not in use should be removed. JBossWS is a web service framework for use with the JBoss Enterprise Application Platform.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xmlJBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.propertiesJBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.propertiesJBOSS_HOME/server/[PROFILE]/deploy/jbossws.sarJBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.warJBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployerIn order to completely disable the this component, Delete the following files and directories:JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xmlJBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.propertiesJBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.propertiesJBOSS_HOME/server/[PROFILE]/deploy/jbossws.sarJBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.warJBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployerUnused features should be disabled or deleted: SeamFeatures and services not in use should be removed. Seam is an application framework for Java designed to reduce application complexity.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/deployers/seam.deployerJBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployerIn order to completely disable the this component, Delete the following files and directories:JBOSS_HOME/server/[PROFILE]/deployers/seam.deployerJBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployerUnused features should be disabled or deleted: JBoss Internet Inter-ORB Protocol (IIOP)Features and services not in use should be removed. JBoss IIOP implements a standards compliant CORBA server for JBoss.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/conf/jacorb.propertiesJBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xmlJBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/lib/jacorb.jarValidate changes to the following files:In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactorywithjava.naming.factory.initial=org.jnp.interfaces.NamingContextFactoryIn order to completely disable this component, Delete these files and directories:JBOSS_HOME/server/[PROFILE]/conf/jacorb.propertiesJBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xmlJBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/lib/jacorb.jarMake the identified changes to the following files:In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactorywithjava.naming.factory.initial=org.jnp.interfaces.NamingContextFactoryIn JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml, Delete text:invoker-proxy-binding iiopUnused features should be disabled or deleted: MiscellaneousMiscellaneous features and services not in use should be removed.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]deployers/xnio.deployerJBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rarJBOSS_HOME/server/[PROFILE]/deploy/jmx-console.warJBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xmlJBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar JBOSS_HOME/server/[PROFILE]/deploy/management/In order to completely disable these components, Delete these files and directories:JBOSS_HOME/server/[PROFILE]deployers/xnio.deployerJBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rarJBOSS_HOME/server/[PROFILE]/deploy/jmx-console.warJBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xmlJBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xmlJBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar JBOSS_HOME/server/[PROFILE]/deploy/management/Unused features should be disabled or deleted: HTTP InvokersFeatures and services not in use should be removed. HTTP invocation allows the JBoss server to receive and act on remote instructions. This can be useful for administrators - especially in large or distributed environments.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:For HTTP Invoker for JNDI, EJB and JMX:JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sarJBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sarFor JMS HTTP Invoker:JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sarIn order to completely disable HTTP Invoker for JNDI, EJB and JMX, Delete these files and directories:JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sarJBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sarIn order to completely disable HTTP Invoker for JMS, Delete this directory:JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sarUnused features should be disabled or deleted: Java Management Extensions (JMX) InvokerFeatures and services not in use should be removed. The JMX Invoker exposes the JMX MBeanServer interface via Remote Method Invocation compatible interface. This can be useful for administrators - especially in large or distributed environments.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xmlIn order to completely disable this component, Delete these files and directories:JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xmlUnused features should be disabled or deleted: Pooled InvokerFeatures and services not in use should be removed. The org.jboss.invocation.pooled.server.PooledInvoker provides RMI over a custom socket implementation of the Invoker interface.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml Ensure the <mbean> with name attribute of "jboss:service=invoker,type=pooled" has been deleted. In order to completely disable this component, take the following actions:In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the <mbean> with name attribute of "jboss:service=invoker,type=pooled" Unused features should be disabled or deleted: Java Remote Method Protocol (JRMP) InvokerFeatures and services not in use should be removed. The org.jboss.invocation.jrmp.server.JRMPInvoker provides the RMI/JRMP implementation of the Invoker interface.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Ensure the <mbean> with name attribute of "jboss:service=invoker,type=jmrp" has been deleted.In order to completely disable this component, take the following actions:In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the <mbean> with name attribute of "jboss:service=invoker,type=jmrp" Unused features should be disabled or deleted: ClusteringFeatures and services not in use should be removed. Clustering allows deployed applications to run distributed across multiple JBoss Enterprise Application Platform servers.Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimmingDeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdfRemoving unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.3LowCAT IIICM-7DCPP-1Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/JBOSS_HOME/server/[PROFILE]/farm/JBOSS_HOME/server/[PROFILE]/deploy/cluster/Validate this change to the following file:In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":<property name="farmURIs">
<list elementClass="java.net.URI">
<value>${jboss.server.home.url}farm</value>
</list>
</property>In order to completely disable this component, take the following actions:Delete these files and directories:JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/JBOSS_HOME/server/[PROFILE]/farm/JBOSS_HOME/server/[PROFILE]/deploy/cluster/In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":<property name="farmURIs">
<list elementClass="java.net.URI">
<value>${jboss.server.home.url}farm</value>
</list>
</property>OSCAP Scan Resultrootlocalhost.localdomain127.0.0.110.0.2.150:0:0:0:0:0:0:1fe80:0:0:0:a00:27ff:feb7:8903OpenSCAP1.0.800:00:00:00:00:0008:00:27:B7:89:0300:00:00:00:00:0008:00:27:B7:89:03notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.passpassnotcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.passfailnotcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.failnotcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.failpassnotcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.failnotcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.failfailfailfailnotcheckedNo candidate or applicable check found.failfailnotcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.passpasspassfailfailfailnotselectednotselectednotcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.notcheckedNo candidate or applicable check found.35.714283