LimitAccessToCertainClientsVERSION 24 Created on: 21 Oct, 2004 11:29 AM by unknownMigrationUser - Last Modified: 20 Jan, 2011 4:34 AM by unknownMigrationUser When securing HTTP traffic, you may wish to consider limiting access to clients with a certain IP address. You can do this at many levels.

Limiting client access using Tomcat (Engine, Host, or Context level)To limit client access at a high level, such as the entire server, you may use a Tomcat valve. Tomcat has two valves that filter traffic based on the client IP addresses. They are the RemoteAddrValve and the RemoteHostValve. Both of these valves are extended from RequestFilterValve. For a discussion of how to configure Tomcat valves see http://tomcat.apache.org/tomcat-5.5-doc/config/host.html (Tomcat 5.5) or http://tomcat.apache.org/tomcat-6.0-doc/config/host.html (Tomcat 6.0). Note: The documentation on using these valves when Tomcat is embedded in JBoss is confusing, but it is simple to do. Although Tomcat scans various directories for context.xml.default and context.xml for defaults, to set a valve on a single Tomcat /context you need WEB-INF/context.xml in the application's WAR. An example of context.xml that allows accesses from 127.0.0.x and 10.x.x.x:

For more discussions on context.xml, see Web-App Context Configuration. No editing of the Tomcat server.xml is required unless you're applying valves to Hosts. In the latter, edit either server.xml or jboss-service.xml based on JBoss version: JBoss server.xml or jboss-service.xml versions 4.2.0 and higher 3.2.4 and 4.0.x 3.2.3 and lower /server//deploy/jboss-web.deployer/server.xml /server//deploy/jbossweb-tomcat50.sar/server.xml /server//deploy/jbossweb-tomcat41.sar/META-INF/jbossserver.xml

Limiting client access using a servlet filter (Servlet or url-pattern level)To limit client access to a particular servlet or to requests that match a url pattern, you can use the servlet filter attached to this page. This requires JDK 1.4 or higher. To install, place the attached jar in your WEB-INF/lib directory. If you want to use it in multiple web applications then you can instead put it in your The attached web.xml file is an example that shows how to configure the filter. The main thing to look at is the filter definition:

RemoteHostFilter org.jboss.remotehostfilter.RemoteHostFilter deny 150.0.0.* allow 192.4.5.6,127.0.0.*

This filter is configured by setting the "allow" and/or "deny" properties to a comma-delimited list of regular expressions(in the syntax supported by the java.util.regex package) to which the client IP address will be compared. Evaluation proceeds as follows: If there are any deny expressions configured, the IP will be compared to each expression. If a match is found, this request will be rejected with a "Forbidden" HTTP response. If there are any allow expressions configured, the IP will be compared to each such expression. If a match is NOT found, this request will be rejected with a "Forbidden" HTTP response. Otherwise, the request will continue normally. Don't forget to add an appropriate "filter-mapping" element, or this filter will never be applied.

Post Installation Configuration9.1. Post Installation Security Configuration 9.1.1. Security Configuration: JMX Console, Admin Console, HttpInvoker 9.1.2. Securing the HTTPInvoker 9.1.3. Security Configuration: Web Console 9.1.4. Security Configuration: JBoss Messaging 9.2. Default Database 9.3. Memory Settings for the Enterprise Web Platform 9.4. Run the Application Server as a Service

9.1. Post Installation Security ConfigurationWhen installed from the zip archive, authentication is required to access the majority of JBoss services, including administrative services. Consoles are secured by the JAAS security domain "jmx-console". At installation this security domain has no user accounts. This is to eliminate the possibility of default username/password based attacks. Refer to Procedure 9.1, Create jmx-console, admin-console, and http invoker user account to create a user account to access the consoles. To disable authentication (useful for development, but not recommended for production), refer to Appendix A, Disabling Authentication. When installed via the graphical installer, a JAAS security domain and a user account is created as part of the install process. Even if you change the name of the JAAS security domain during installation, the users are stored in the same place. Follow the instructions in Procedure 9.1, Create jmx-console, admin-console, and http invoker user account to edit your user account, or create a new one.

9.1.1. Security Configuration: JMX Console, Admin Console, HttpInvokerProcedure 9.1. Create jmx-console, admin-console, and http invoker user account This procedure creates user with access permissions to the admin and jmx consoles, and the http invoker 1. Create a user in the default JAAS security domain a. Edit the file

jboss-as-web/server/$PROFILE/conf/props/jmx-console-

users.properties.b. Create a username = password pair.

Default admin user configurationThe commented

admin=admin username and password pair is an example of the

username/password definition syntax. Do not use this for your user account. 2. Grant permissions to user a. Edit the file

jboss-as-web/server/$PROFILE/conf/props/jmx-console-

roles.properties.b. Create an entry for the user of the form:

username=JBossAdmin,HttpInvokerJBossAdmin Grant the user permission to access the JMX Console and Admin Console. HttpInvoker Grant the user permission to access the httpinvoker

ImportantThe authentication system applied to the JMX Console, Admin Console and Web Console does not block brute-force password attacks. It is recommended that in production environments, JBoss servers are protected by firewalls or reverse proxies that include measures to mitigate brute force attacks.

9.1.2. Securing the HTTPInvoker

The HTTP Invoker is a service that provides HTTP and Remote Method Invocation (RMI) access for EJBs and the JNDI Naming service. Secure this service to prevent unauthorized access. Procedure 9.2. Secure the HTTP Invoker 1. Defining security constraints The

server/$PROFILE/deploy/http-invoker.sar/invoker.war/WEB-

INF/web.xml or server/$PROFILE/deploy/httphainvoker.sar/invoker.war/WEB-INF/web.xml file (depending on your server profile) mustdefine a JNDIFactory, EJBInvokerServlet, and JMXInvokerServlet in the security realm. This means that the

security-constraint element should be similar to: HttpInvokers An example security config that only allows users with the role HttpInvoker to access the HTTP invoker servlets /restricted/* /JNDIFactory/* /EJBInvokerServlet/* /JMXInvokerServlet/* GET POST HttpInvoker

2.

Define an associated security domain Add the following to fragment to web.xml: java:/jaas/jmx-console

3.

Binding the jmx-invoker to localhost

NoteBinding the jmx-invoker to localhost is highly recommended for security, but makes it unavailable for use remotely. Edit

server/$PROFILE/conf/jboss-service.xml such that the ServerAddress of the RMI/JRMP

invoker is localhost, as shown in the following code snippet: 4444 localhost ....

4.

Add the following lines to the

server section of server/$PROFILE/deploy/jmx-invoker-

service.xml:5.

6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

1 300 300 60000 localhost 4443 localhost 0 1 false jboss:service=TransactionManager

18. In the

java:/jaas/jmxconsole 30. The security-domain value of web-console maps is declared in the login-config.xml JAAS configuration file which defines how authentication and authorization is done. edit /server/default/conf/login-config.xml Change the path to the web-console-users.properties and the web-console-roles.properties as follows (add props/ to the front of the path)

props/webconsole-users.properties props/web-consoleroles.properties

Saturday, March 20, 2010

Securing JBoss jmx-consoleBoth the jmx-console and web-console are standard servlet 2.3 deployments and can be secured using J2EE role based security. Both also have a skeleton setup to allow one to easily enable security using username/password/role mappings found in the jmx-console.war and web-console.war deployments in the corresponding WEB-INF/classes users.properties and roles.properties files. The security setup is based on two pieces, the standard WEB-INF/web.xml servlet URI to role specification, and the WEB-INF/jboss-web.xml specification of the JAAS configuration which defines how authentication and role mapping is performed.To secure the JMX Console using a username/password file: 1. 2. Locate the jmx-console.war directory. This will normally be in /server/default/deploy directory. Edit /server/default/deploy/jmx-console.war/WEB-INF/web.xml and uncomment the following securityconstraint block

A security constraint that restricts access to the HTML to users with the role JBossAdmin. Edit the roles to what uncomment the WEB-INF/jboss-web.xml/security-domain element secured access to the HTML JMX console.

JMX console you want and to enable

HtmlAdaptor An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application /* GET POST JBossAdmin BASIC JBoss JMX Console JBossAdmin 3. Edit /server/default/conf/props/jmx-console-users.properties (version >=4.0.2) and /server/default/conf/props/jmx-console-roles.properties (version >=4.0.2) and change the users and passwords to what you desire. They will need the JBossAdmin role specified in the web.xml file to run the JMX Console. The only change above should be to jmx-console-users.properties, i.e, set a password.

4.

Edit /server/default/jmx-console.war/WEB-INF/jboss-web.xml and uncomment the following securitydomain block:-

5. 6. 10. java:/jaas/jmxconsole

Security on JBoss16.1. Securing ApplicationsFiltering clients by source IP addresses Requiring authentication and authorization Data transport integrity and confidentiality (SSL) We will explore each one of these in turn

16.2. Filtering Clients by SourceLimit access to web applications by client IP or hostname Configured through Tomcat Valves Different levels: (global), (per virtual host), (per web application)

Configured through a Servlet Filter Simple implementation is provided by JBoss but servlet filters are Java EE AS-independent To limit client access through Tomcat, add a desired in or elements within${jboss.server.home.url}/deploy/jbossweb.sar/server.xml file Limiting per web application can be still done through Tomcat by creating a file${jboss.server.home.url}/deploy/.war/WEB-INF/context.xml:

To limit client access in a application-server-neutral way, configure a servlet filter in WEBINF/web.xml file as follows:

... RemoteHostFilter org.jboss.remotehostfilter.RemoteHostFilter allow 192.168.*,127.*

RemoteHostFilter /*

... A simple implementation of this filter can be found athttp://community.jboss.org/wiki/LimitAccessToCertainClients

16.3. Authentication & AuthorizationSecurity is a fundamental part of any enterprise application. You need to be able to restrict who is allowed to access your applications and control what operations application users may perform. JAAS - Java Authentication and Authorization Service (pure Java) Pluggable Authentication Module framework: JNDI, UNIX, Windows, Kerberos, Keystore Support for single sing-on Role-based access control Separates business logic from A&A Declarative (XML-based) Described in deployment descriptors instead of being hard-coded Isolate security from business-level code For example, consider a bank account application. The security requirements, roles, and permissions will vary depending on how is the bank account accessed: via the internet (username + password), via an ATM (card + pin), or at a branch (Photo ID + signature). We benefit by separating the business logic of how bank accounts behave from how bank accounts are accessed. Securing a Java EE application is based on the specification of the application security requirements via the standard Java EE deployment descriptors. EJBs and web components in an enterprise application by using the ejb-jar.xml and web.xml deployment descriptors.

16.4. Requiring A&AAdding security-constraint in web.xml:

... All Resources Protect all content

/*

MyRole ... Element declares the web resources to be protected and the role required to access those resources. Element is required, and it simply assigns a name to the declared. Element is optional, and it provides textual description of the declared . Element is optional (although, without it the is ignored), and it declares to which URL patterns this security constraint applies. URL patterns can be catch-all ("/*") or they can be repeated to list specific resources. For example:

/MySecureHandler /MySecureArea/* *.jspThe preceding slash (/) character makes the URLs absolute within the web application only. In addition to URL patterns, it is also possible to limit the security constraint to HTTP methods using the element as follows:

... POST

GET If the element is omitted, the default behavior is to apply the security constraint to all HTTP methods. The element indicates the user roles that should be permitted access to this resource collection. The used here must either correspond to the of one of the elements defined for this web application (more on this soon), or be the specially reserved role-name "*" that is a compact syntax for indicating all roles in the web application. If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint. JBoss AS matches role names case sensitively when determining access. Adding login configuration:

... ...

BASIC My Secure Application ... Element configures the login method for the secured resource. In this case we just use HTTP BASIC authentication, but other options for JBoss are: DIGEST,

FORM, and CLIENT-CERT. We will cover some of these later.Declaring security roles:

... ... MyRole

...

All members of MyRole MyRole ... If multiple roles are desired, declare them as follows:

... ... Manager Administrator ... Manager Administrator ... 16.5. Plain-Text Login ModuleAlready enabled by default

WEB-INF/classes/users.properties:

john=secret bob=abc123 mike=passwdWEB-INF/classes/roles.properties:

john=MyRole bob=MyRole,Manager mike=Manager,AdministratorProvided by org.jboss.security.auth.spi.UsersRolesLoginModule configured in file${jboss.server.config.url}/login-config.xml:

... ... Note The properties files users.properties and roles.properties are loaded during

initialization of the context class loader. This means that these files can be placed into any Java EE deployment archive (e.g. WAR), the JBoss configuration directory, or any directory on the JBoss server or system classpath. Placing these files in the ${jboss.server.home.url}/deploy//WEB-INF/classes directory makes them unique to that specific web application. Moving them to ${jboss.server.config.url} directory makes them "global" to the entire JBoss AS instance. To change the names of these files, expand the as follows:

myUsers.properties myRoles.properties16.6. Database Login ModuleFetches login info from a RDBMS Works with existing DB schemas Uses pooled database connections Scales well as the user population grows Does not require server or application restarts on info change Database Login Module depends on our ability to set up (and link to) a JBoss-managed DataSource (database connection pool).16.6.1. MySQL Schema/DB Setup

term#> mysql/bin/mysql -u root -p mysql> CREATE DATABASE Authority; mysql> USE Authority; mysql> CREATE TABLE Users (Username VARCHAR(32) NOT NULL PRIMARY KEY,Password VARCHAR(32) NOT NULL); mysql> CREATE TABLE Roles (Username VARCHAR(32) NOT NULL,Rolename VARCHAR(32) NOT NULL,PRIMARY KEY (Username, Rolename)); mysql> GRANT SELECT ON Authority.* TO authority@localhost IDENTIFIED BY "authsecret";

It is important that the password field be at least 32 characters in order to accommodate MD5digest-based passwords (more on this later). You do not have to create a separate database, nor do you need separate tables, but we assume that we are starting from scratch. The default JBoss AS schema for User/Role information is as follows: Table Principals(PrincipalID text, Password text) Table Roles(PrincipalID text, Role text, RoleGroup text) You also do not need a auth-specific read-only database user, but we create one because it is a good practice. Populate the database. For example:

INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT

INTO INTO INTO INTO INTO INTO INTO INTO

Users Roles Users Roles Roles Users Roles Roles

VALUES VALUES VALUES VALUES VALUES VALUES VALUES VALUES

("john", "secret"); ("john", "MyRole"); ("bob", "abc123"); ("bob", "MyRole"); ("bob", "Manager"); ("mike", "passwd"); ("mike", "Manager"); ("mike", "Admin");

16.6.2. Authority Database Resource

Create deploy/authority-ds.xml:

AuthorityDB jdbc:mysql://localhost:3306/Authority? autoReconnect=true com.mysql.jdbc.Driver authority

authsecret ... Define a database connection pool (resource) that will provide connectivity to the Authority database.16.6.3. Configure DB Login Module

Add to conf/login-config.xml:

java:/AuthorityDB SELECT Password FROM Users WHERE Username=? SELECT Rolename, "Roles" FROM Roles WHERE Username=? Application policy name declares a new policy. We will reference this name in each [web] application that wishes to use it. The required flag means that the login module is required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list Other options are: requisite, sufficient, and optional

Module option dsJndiName: Defines the JNDI name of the RDBMS DataSource that defines logical users and roles tables Defaults to java:/DefaultDS Module option principalsQuery: Defines a prepared SQL statement that queries the password of a given username Defaults to select Password from Principals where PrincipalID=? Module option rolesQuery: Defines a prepared SQL statement that queries role names (and groups) of a given username The default group name is Roles (hard-coded). Defaults to select Role, RoleGroup

from Roles where PrincipalID=?16.6.4. Link to Security Domain

Add to WEB-INF/jboss-web.xml:

java:/jaas/MyPolicyDefault security domain is other, which authenticates against the properties files Security domains declared in conf/login-config.xml are relative to java:/jaas/ JNDI context16.6.5. Securing Passwords

Configure hashed passwords in conf/login-config.xml:

... MD5 hexChange users.properties:

john=5ebe2294ecd0e0f08eab7690d2a6ee69 bob=e99a18c428cb38d5f260853678922e03

mike=76a2173be6393254e72ffa4d6df1030a16.7. FORM-based LoginSession-based Allows Logout - session.invalidate() Automatically expires when the session expires More efficient and secure - single authentication Fully customizable Control the layout of the login page Control the layout of the error page Provide links to "user registration" or "recover password" actions Support for FORM-based login is part of the Java EE specification, and like the rest of JAASbased security, it is independent of the application server With the FORM-based login, the server forces the users to login via an HTML form when it detects the users session is not authenticated This is accomplished by forwarding the users' requests to the login page In case of authentication failures, users are sent to the login error page16.7.1. Login.jsp Form Page

JBoss handler: j_security_check for params j_username and j_password

Login Form Login Form Username:
Password:

To support non-cookie-based-session-tracking, change j_security_check to

which will add JSESSIONID to the request URL if needed.16.7.2. LoginError.jsp Page

Displays the error message if the authentication fails

Login Error Authentication Error Invalid username and/or password. Try again? This page is only shown if user enters invalid username and/or password. Authorization errors (user not in required role) are handled separately.16.7.3. Update Login Configuration

Update in web.xml:

FORM

/Login.jsp /LoginError.jsp 16.7.4. Authorization Failure

Authorization failures are expressed by HTTP 403 status codes Use element to configure HTTP 403 handler in web.xml:

403 /AuthorizationError.jsp 16.8. Configuring JBoss AS for SSLCreate (or import) SSL certificates using keytool Java command-line utility Configure SSL connector in Tomcat Require SSL per application/context using Note Adding support for SSL (Secure Socket Layer) is only useful if JBoss AS acts as a standalone web server. If JBoss AS is fronted by another web server, like Apache HTTPD, then the security of the communication channel becomes the responsibility of that web server. In that case, JBoss AS communicates with the web server over an unsecured channel (plain-text), but the web server still informs JBoss about the security protocol it has negotiated with the end client.

16.9. Creating SSL CertificatesOnly JKS or PKCS12 formats are supported Use JDKs keytool command-line tool Keystore password and certificate password have to be the same (default is "changeit") Certificate alias is "tomcat" Use RSA algorithm for broader support Use JBoss-specific keystore file Use site hostname for certs common name

For example, run the following from within ${jboss.server.home.url} directory:

keytool -genkey -keystore conf/ssl.ks -storepass secret -alias tomcat -keyalg RSA -keypass secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: IT What is the name of your organization? [Unknown]: Secure Org What is the name of your City or Locality? [Unknown]: San Francisco What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=localhost, OU=IT, O=Secure Org, L=San Francisco, ST=CA, C=US correct? [no]: yesRefer to http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html for more info.

16.10. Configure SSL ConnectorAdd (uncomment) in ${jboss.server.home.dir}/deploy/jbossweb.sar/server.xml file:

If you change the port to 443 (or any other port number), make sure that you also set redirectPort="443" in both the non-SSL HTTP and AJP connector elements.

See http://tomcat.apache.org/tomcat-6.0-doc/config/http.html for additional options.

16.11. Testing SSL ConfigurationWhen starting up JBoss AS, the console should print the following lines:

... 14:41:01,002 INFO Coyote HTTP/1.1 on 14:41:02,195 INFO Coyote HTTP/1.1 on ...

[Http11Protocol] Initializing http-0.0.0.0-8080 [Http11Protocol] Initializing http-0.0.0.0-8443

When you point your browser to http://localhost:8443/status you will get a browser warning telling you that the SSL certificate has not been signed by a certification authority that you trust. This is expected, since we signed our own certificate. Skipping the warning should show the SSLprotected page (pad-lock).

16.12. Requiring SSL in AppsAdd within a element (in WEB-INF/web.xml file):

Require SSL CONFIDENTIAL Upon making a request over a non-SSL connection, the browser is automatically redirected to the redirectPort as defined in the element Note The element can be NONE, INTEGRAL, or CONFIDENTIAL. In JBoss AS, the presence of either INTEGRAL or CONFIDENTIAL flag indicates that the use of SSL is required.

16.13. Lab: Application SecurityFilter out clients coming from remote interfaces on One of the virtual hosts One of the deployed applications Protect an application with A&A Plain text Database Secure Passwords

Add support for SSL Require SSL in one or more of the applications To filter clients by their source IP see Section 16.2, Filtering Clients by Source For a virtual host, add to in Tomcats server.xml For a web application, add to in applications WEB-INF/context.xml file To implement authentication and authorization (Section 16.3, Authentication & Authorization): Plain text (Section 16.5, Plain-Text Login Module) Database (Section 16.6, Database Login Module) Securing passwords (Section 16.6.5, Securing Passwords) To add support for SSL (Section 16.8, Configuring JBoss AS for SSL): Require SSL (Section 16.12, Requiring SSL in Apps)

16.14. Securing JMS destinationsBy default in JBoss, every message sent can be accessed by all consumers connected to the destination. To restrict this, we must plug JBM users into JBossSX. Note

JBM_USER and JBM_ROLE tables have been created by the JMSUserManager componentwhen we have set up the persistence to use MySQL. First, declare a new security domain in the conf/login-config.xml file in your server configuration set folder:

... java:/MySqlDS SELECT passwd FROM jbm_user WHERE user_id=?

SELECT role_id, 'Roles' FROM jbm_role WHERE user_id=? ... Then, add the security domain you just created to the configuration of JBM security store that you can find in the deploy/messaging/messaging-jboss-beans.xml:

... JMSRealm ... This is where you need to specify which security domain to use Create now a secured Topic:

jboss.messaging:service=ServerPee r jboss.messaging:service=PostOffice

This is where you say that you want your consumers to have the publisher role. The read property allows the consumer to read messages from the destination. The write property allows the consumer to send messages to the destination. Note The publisher role has been automatically added by the persistence service at table creation. One user that has the publisher role is also created (user_id: dynsub , passwd: dynsub) Finally, If a developer want to use the secured connection for this Topic:

connection = cf.createConnection("dynsub","dynsub");16.15. Securing JBoss ASRunning JBoss AS with low privileges File system security Securing console applications/tools Restricting remote shutdown Protecting twiddle tool Securing other JBoss AS services Running with Java Security Manager Running behind a firewall We will examine each of these in turn.

16.16. JBoss AS System UserDo not run JBoss AS as root / Administrator Deployed applications and services run with the same privileges as the JBoss AS itself Create a low-privileged JBoss system user JBoss, being a Java app, cannot switch its effective user id after starting Running without root privileges forces you to use ports >=1024 (default) on a Unix/Linux system Front JBoss AS with a web server (like Apache HTTPD) or setup firewall-based port forwarding for access over default HTTP(S) ports: 80, 443 Creating low-privileged users for system services is a common practice on Unix/Linux environments. On Windows, JBoss AS would typically be configured to run with a default System account. Also, Windows does not have a concept of privileged ports like Unix/Linux systems.

16.17. File System SecurityJBoss user must have at least read access to all files and directories under

${jboss.home_url}JBoss user must have write access to data/, log/, tmp/, and work/ directories under ${jboss.server.home.url} (under default configuration set)

Depending on the deployed apps' requirements, JBoss user may need write access to parts of${jboss.server.home.url}/deploy dir Other users should in particular have no access to ${jboss.server.config.url} and${jboss.server.home.url}/deploy directories as these often contain sensitive information like database or SSL-certificate passwords. Although supported by NTFS, file system security is often not employed to secure system services like JBoss AS under Windows.

16.18. Securing JMX InvokerUsed by the twiddle tool and the remote shutdown - by default unsecured Simples solution is to remove it No remote shutdown (send TERM signal) No programmatic remote management Secure it by adding an authentication interceptor to the Invoker MBean Just needs to be uncommented In deploy/jmx-invoker-adaptor-server.sar/META-INF/jboss-service.xml (JBoss 3.2.x) ordeploy/jmx-invoker-service.xml (JBoss 4.x and JBoss 5.x) under

${jboss.server.home.url}, uncomment the following:

By default, the security domain java:/jaas/jmx-console authenticates against filedefault/conf/props/jmx-console-users.propertiesThis file is in = format. Roles are not important. To specify the username and password for twiddle or shutdown scripts, use -u -p

command-line switches. 16.19. Securing JBoss ApplicationsBoth jmx-console and web-console are standard web applications Remove if not needed? Filter by IP Use declarative security to require A&A Require SSL Declarative security already present, just needs to be uncommented Requiring authentication and authorization for jmx-console:

Uncomment in web.xml and in jbossweb.xml under${jboss.server.home.url}/deploy/jmx-console.war/WEB-INF/ Set or change the admin password in ${jboss.server.config.url}/props/jmx-

console-users.propertiesRequiring authentication and authorization for web-console: Uncomment in web.xml and in jbossweb.xml under

${jboss.server.home.url}/deploy/management/web-console.war/WEB-INF(JBoss version=4.0.2) Update ${jboss.server.config.url}/login-config.xml such that loads usersProperties fromprops/web-consoleusers.properties and rolesProperties fromprops/web-consoleroles.propertiesAdd a user that belong to JBossAdmin role in the two properties files Restart JBoss for the changes to take effect.

16.20. Securing Hypersonic DBRemove it Undeploy ${jboss.server.home.url}/deploy/hsqldb-ds.xml Provide DefaultDS for services that depend on it (like JMS MQ) Keep it but disable remote access to it Disable jboss:service=Hypersonic Mbean in hsqldb-ds.xml To disable remote access to Hypersonic DB: Edit ${jboss.server.home.url}/deploy/hsqldb-ds.xml Comment out Change in from localhost:1701 to a local resource likejdbc:hsqldb:${jboss.server.data.dir}/hypersonic/localDB Comment out the element in referring to

jboss:service=Hypersonic 16.21. Java Security ManagerRun JBoss AS in a secure sand box controlled by a security policy (file) Control access to resources such as JVM, system settings, file system, and network communication (inbound and outbound) Secure as long as all code is pure Java Disabled by default Hard to configure Slight runtime overhead To enable, edit $JBOSS_HOME/bin/run.conf and add to JAVA_OPTS: * -

Djava.security.manager and * -Djava.security.policy=Enabling the security manager is easy. The hard part is to come up with a suitable security policy. To enable all permissions, start with security.policy:

grant { permission java.security.AllPermission;

};To figure out which permissions you need, you can debug the security manager. Run java -

Djava.security.debug=help to see a list of debugging options. Using Djava.security.debug=all in JAVA_OPTS is the most verbose (probably too verbose), whereas setting java.security.debug to access,failure may be sufficient to determine asuitable security policy.

16.22. Running Behind a FirewallDecide which services need to be visible from the outside world HTTP, HTTPS (unless running behind a web server such as Apache HTTPD) Naming Service: RMI, Registry? SNMP? JRMP Invoker? Protect all other services JMS MQ HA and clustering services in all configuration Listening ports in default configuration: 1098 1099 4444 4445 8009 8080 8083 8093 TCP TCP TCP TCP TCP TCP TCP TCP NamingService RMI Naming Service Registry JRMP Invoker RMI Pooled Invoker Server Tomcat AJP Tomcat HTTP Web Service JMS MQ UIL Server

Additional listening ports in all configuration: 1100 TCP HA Naming Service 1101 TCP HA Naming Service RMI 1102 UDP HA Naming Service AutoDiscovery 1161 UDP Snmp Agent Service 1162 UDP Trapd Service 3528 TCP IIOP Invoker 4447 TCP JRMPInvoker HA 45566 UDP Cluster Partition

16.23. Lab: JBoss SecuritySecure JMX Invoker Test Twiddle and Shutdown Secure JMX Console Require A&A Require SSL Secure Web Console Require local access only

JBoss Application Server Security Vulnerability Notice

This document (3024921) is provided subject to the disclaimer at the end of this document.

EnvironmentJBoss Application Server versions 5.0 JBoss Application Server versions 4.0.1 SP1 JBoss Application Server versions 4.0.2 SP1 JBoss Application Server versions 4.0.3 SP1 JBoss Application Server versions 4.0.5 Novell Identity Manager UserApplication 3.0 Novell Identity Manager UserApplication 3.0.1 SP1 Novell Identity Manager UserApplication 3.5.1 Novell Identity Manager UserApplication 3.6.0 Novell Identity Manager UserApplication/RBPM 3.6.1 Novell Identity Manager UserApplication/RBPM 3.7 Novell Identity Manager UserApplication/RBPM 4.0.1

SituationSymantec discovered a flaw in the DeploymentFileRepository class of the JBoss Application Server. A remote attacker who is able to access the console manager could read or write to files with the permissions of the JBoss AS user. This could potentially lead to arbitrary code execution as the JBoss AS user. (CVE-2006-5750) Please note that the JBoss AS console manager should always be secured prior to deployment, as directed in the JBoss Application Server Guide. By default, the JBoss AS installer gives users the ability to password protect the console manager, limiting an attack using this vulnerability to authorised users. These steps can also be performed manually.

Statement Regarding Security Threat to JBoss Application Server: Red Hat has become aware of a worm currently affecting unpatched or unsecured servers running JBoss Application Server and products based on it.New Update as of 10/22/2011 Jboss announced a new

Here is the JBoss Community note: http://community.jboss.org/blogs/mjc/2011/10/20/sta tement-regarding-security-threat-to-jbossapplication-serverResolution

The quickest and easiest approach to correct this security vulnerability is to; 1. Remove the offending service 2. Secure the JBoss JMX and Web Consoles However, we strongly feel the best approach is to secure JBoss using the following optional procedures; - secure jmx-console and web-console authentication via SSL - secure your Web Application in Jboss Application Server - use a one-way hash to protect the administrative password property file - secure the invokers To remove the offending service use the following steps; 1. Undeploy completely the web-console application by removing the directory deploy/management from the 'default' and 'all' configurations or

2. comment out the DeploymentFileRepository service deployed bydeploy/management/console-mgr.sar in the'default' and 'all' configurations. If console-mgr.sar is packed, unpack it and edit the META-INF/jboss-service.xml descriptor, commenting out the following entry: ... name="jboss.admin:service=DeploymentFileRepository"> ./deploy/management The web-console will still work, without the ability to create alerts/monitors/snapshots.

Secure the Jmx and Web Console's 1. Secure the JMX Console using a username/password file Locate the jmx-console.war directory. Normally found in server/default/deploy in your JBOSS_HOME directory. edit the WEB-INF/web.xml, uncomment the security-constraint block edit the WEB-INF/jmx-console-users.properties or server/default/conf/props/jmx-consoleusers.properties (version>=4.0.2) and WEB-INF/jmx-console- roles.properties or server/default/conf/props/jmx-console-roles.properties (version>=4.0.2) and change the users and passwords to what you desire. Please note: They will need the JBossAdmin role specified in the web.xml file to run the JMX Console. edit the WEB-INF/jboss-web.xml, uncomment the security-domain block. The security-domain value of jmx-console maps is declared in the login-config.xml JAAS configuration file which defines how authentication and authorization is done. 2. Secure the JMX Console using your own JAAS domain edit the WEB-INF/web.xml as above, uncommenting the security-constraint block. Change the role-name value to be the role in your domain that can access the console edit the WEB-INF/jboss-web.xml as in step1, set the security domain to be the name of your security domain. For example, if your login-config.xml has an application-policy whose name is MyDomain then your JAAS domain java:/jaas/MyDomain redeploy the application 3. Secure the web console In the deploy directory, locate management/web-console.war and make the same changes as above to the WEB-INF/web.xml, WEB-INF/jboss-web.xml and the users/groups properties file. The default JAAS domain used by the web-console is java:/jaas/web-console and is defined in loginconfig.xml in the conf directory. You can use a custom JAAS domain or customize the existing domain in the same way as with the JMX console. Typically you would just use the same domain (java:/jaas/jmx-console) as the jmx-console so that you have a single user/role mapping to configure.

Update for 4.0.2 The jmx-console-roles.properties and jmx-console-users.properties files have been moved to server\default\conf\props. The web console,is unpacked already in the default server configuration as deploy/management/console-mgr.sar/web-console.war. Edit the WEB-INF/web.xml and jbossweb.xml files as per securing the JMX console.

A quicker method to secure the Web and JMX console is the following: 1. Navigate to JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/web.xml and uncomment the security-constraint block, add a block after the end of the block. Example: BASIC JMXConsole

2. Navigate to JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xmland uncomment the security-domain block 3. Navigate to $JBOSS_HOME/server/default/conf/props/jmx-console-users.propertiesand change the password for admin 4. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/web.xml and uncomment the security-constraint block 5. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/jboss-web.xml and uncomment the security-domain block 6. Navigate to JBOSS_HOME/server/default/conf/login-config.xml and change the path to the web-console-users.properties and the web-console-roles.properties as follows (add props/ to the front of the path) props/web-console-users.properties props/web-console-roles.properties 7. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/classes/web-console-*.properties and JBOSS_HOME/server/default/conf/props edit as needed 8. Navigate to JBOSS_HOME/server/default/conf/props/jmx-console-roles.properties and JBOSS_HOME/server/default/conf/props/web-console-roles.properties and edit as needed 9. Restart jboss How to secure the JMX-console and Web-console authentication via SSL These steps will redirect jboss admin pages to https://localhost:8443 1. You must first enable http authenication as outlined in the sections previously outlined above 2. Navigate to JBOSS_HOME/server/default/deploy/management/console-mgr.sar/webconsole.war/WEB-INF/web.xml, include the following just before end of tag security-constraint ... CONFIDENTIAL 3. Navigate to JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/web.xml,include the following just before end of tag security-constraint ... CONFIDENTIAL 4. Create a keystore and supply a secure password. (for information on creating a keystore please see TID#3103136 How to install a signed certificate into Jboss for the IDM3 User Application, http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3103136 &sliceId=SAL_Public&dialogID=24642412&stateId=0%200%2024646267 5. Enable SSL in JBoss locate jbossweb-tomcat55.sar file under \jboss\server\YourJBossServer\deploy. In it, find server.xml and open that file in a text editor. Enable SSL by uncommenting "SSL/TLS Connector" or adding the following section if it is not there: maxThreads="100" strategy="ms" maxHttpHeaderSize="8192" emptySessionPath="true" scheme="https" secure="true" clientAuth="false" keystoreFile="${jboss.server.home.dir}/spitfire/conf/jboss.jks" keystorePass="changeit" sslProtocol ="TLS" /> **Note 1: Remember to point "keystoreFile" to the keystore you created. example: ${jboss.server.home.dir}/conf/server.keystore **Note 2: Remember to change the keystorePass="changeit" to your keystore password 6. Restart your JBoss Server and test. When restarting the JBoss Server you should see the server running on 2 ports, your http port and your ssl port https:8443 Securing a Web Application in JBossAS Create a simple security domain for JBoss SX Open the ${jboss.dist}/server/${server.name}/conf/login-config.xml file This file sets up the configuration for the security domains available to applications running in the server. The file contains a few example domains you may want to look at for reference. JBoss SX uses JAAS for the infrastructure of the underlying security

JAAS uses a class called a "login module" to interact with a security store for authenticating credentials. This file basically hooks up a security domain to a JAAS login module. JBoss Application Server comes packed with the "UsersRolesLoginModule". The "UsersRolesLoginModule" allows you to specify user names, passwords and roles in a simple property file. Copy the "jmx-console" domain policy The "jmx-console" security domain policy contains the basics for configuring a UsersRolesLoginModule based security domain. props/jmx-console-users.properties props/jmx-console-roles.properties copy this section to the bottom of the file edit the "name" attribute on the application-policy attribute to "my-web" edit the "userProperties" module-option text value to be"props/my-web-users.properties" edit the "roleProperties" module-option text value to be"props/my-web-roles.properties" save the login-config.xml file. In the ${jboss.dist}/server/conf/props directory, copy the jmx-console-users.properties into a new file called my-web-users.properties, copy the jmx-console-roles.properties into a new file called my-web-roles.properties. open "my-web-users.properties" file, notice that you will see a single entry like: "admin=admin" (The structure is "username=password"). When a user logs into the security domain, the login module will examine the properties data in this file for users. Add a new user, for example"tester=security", to the file under "admin=admin" Save file open the my-web-roles.properties file, notice an entry similar to the following:"admin=JBossAdmin,HttpInvoker". These entries define the roles a user has associated with their account at login. The structure is "username=Role1,Role2,..." the username is the user you wish to assign roles to,and the Roles entries are a comma separated list of roles to assign to that user. Add a new entry to this file, for example "tester=WebAppUser" on a new line below the"admin=....". Save file. Configure the web application for security by adding constraints to the web deployment descriptor. modify the web.xml in the WEB-INF directory of the web application you are securing to add in the following: All resources Protects all resources /*

WebAppUser

WebAppUser

BASIC Test Realm

Note:"security-constraint" is used to define what resources in the web application are protected. "url-pattern" element specifies the URL pattern to protect (example above protects _all_ resources in the web application) "auth-contraint" element specifies which roles have access to the protected resource (example just specifies one role) -This role name must match the name of the role you specified in"my-webroles.properties" file. "login-config" element specifies how authentication occurs with the web application. "auth-method" element specifies how the browser gets credentials from the user. -"BASIC", "DIGEST","FORM", and "CLIENT-CERT" are possible methods to retrieve data from the browser user. The example above uses"BASIC", but this method should not be used in a production environment unless you are using SSL/TLS "realm-name" element just specifies the authentication realm name that is given to the browser for authentication. Configure the jboss-web.xml file to point to the "my-web" application. edit the jboss-web.xml in the WEB-INF directory of the web application you are securing -add the following in the"jboss-web" element: java:/jaas/my-web This instructs JBoss Application Server to connect the web application to the "my-web" security domain we defined in the login-config.xml file earlier. Start the JBoss Application Server In a browser navigate to your application -you should be prompted for username and password. Enter the user and password we created earlier in our example we used "tester" for the username, and "security" for the password. If your set-up is correct, you will be allowed access to the web application. To test, close browser open and navigating back to your application. When prompted, enter no credentials, or "admin" with password: admin, you should not have access to the application Protecting the Administrator password property file You can also use a one-way hash for protecting the admin password property file. In the above section on"Securing a Web Application in JBoss AS we used the following configuration fragment:

props/jmx-console-users.properties props/jmx-console-roles.properties

To add the hash support, you need to add the following options to it: MD5 base64 Now in the usersProperties file, you no longer do user=pass. Instead, you do user=md5(pass). The user is responsible for generating the md5() value, either by themselves or using the following program (please notice that it relies on org.jboss.security.Util, which is in jbosssx.jar). import java.security.MessageDigest; import org.jboss.security.Util; class HashPassword { public static void main(String[] args) {

String password = args[0]; MessageDigest md = null; try { md = MessageDigest.getInstance("MD5"); } catch(Exception e) { e.printStackTrace(); } byte[] passwordBytes = password.getBytes(); byte[] hash = md.digest(passwordBytes); String passwordHash = Util.encodeBase64(hash); System.out.println("password hash:"+passwordHash); } } Securing the Invokers Enabling authentication to the RMIAdaptor service in JBossAS 4.0.x, edit jmx-invoker-service.xml in JBossAS 3.2.x, edit jmx-invoker-adaptor-server.sar/META-INF/jboss-service.xml and uncomment the descriptors section of the invoke operation: The detached invoker entry point invoke The method invocation context invocation org.jboss.invocation.Invocation java.lang.Object

securityDomain="java:/jaas/jmx-console"/> The value of the securityDomain attribute maps to the security domain name found in the conf/loginconfig.xml definitions the same way as the jboss.xml, jboss-web.xml security-domain elements. Enabling authorization to the RMIAdaptor service -An "AuthorizationInterceptor" is available in JBoss. The place the interceptor after the"AuthenticationInterceptor" configuration: * authorizingClass : Fully Qualified Name of a class that does the authorization and contains a method with the following signature "public void authorize( Principal caller, Subject subject, String objectname,String opname)" that can throw a java.lang.SecurityException An example of an authorizing class is the org.jboss.jmx.connector.invoker.RolesAuthorization, which looks for an hardcoded "JBossAdmin?" role in the authenticated subject. securityDomain="java:/jaas/jmx-console"/> authorizingClass="org.jboss.jmx.connector.invoker.RolesAuthorization"/> Starting with 4.0.4.GA, Jboss has an authorization delegate that looks for passwords from a properties file called as "jmxinvoker-roles.properties" in a jar file or can be in the conf directory. securityDomain="java:/jaas/jmx-console"/> authorizingClass="org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization"/> The format of the"jmxinvoker-roles.properties" file is: #Specify the roles that are authorized to access the jmx invoker delimited by comma roles=testRole,testRole1 If you don't succeed in securing the RMIInvoker 1. try placing the security-service.xml in a SAR 2. create a folder named security.sar that has a subfolder named META-INF 3. move your security-service.xml to this folder and rename it to jboss-service.xml

4. Place the security.sar in the deploy-folder New Update as of 10/22/2011 additional information for locking down the Jboss Application Server Here is the link for locking down the different versions of the JBoss consoles: http://community.jboss.org/wiki/SecureTheJmxConsole