JBoss Application Server v7.0
jboss,application,server | Javamazon:
JBoss Application Server v7.0
JBoss Application Server v7.0
When you first download JBoss, it comes as an easy-to-install zip file. Upon installation, you can easily deploy EJBs, web applications and a whole array of services. However, you may be suprised how easy it is to compromise the services. JBossSX can fix that by securing those functions.
Secure the Jmx Console
Both the jmx-console and web-console are standard servlet 2.3 deployments that can be secured using J2EE role-based security. Both consoles ship with a skeleton configuration, allowing an administrator 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 servlet URI to role specification, and the specification of the JAAS configuration which defines how authentication and role mapping is performed.
To secure the JMX Console using a username/password file:
Locate the JMX Console web.xml file. On JBoss AS 5.x, this is located in the server/PROFILE/deploy/jmx-console.war/WEB-INF directory. On JBoss AS 6, this is located in the common/deploy/jmx-console.war/WEB-INF directory.
Edit web.xml and uncomment the security-constraint block. See the important security note – CVE-2010-0738 below.
Edit the server/PROFILE/deploy/jmx-console.war/WEB-INF/jboss-web.xml (AS5) or common/deploy/jmx-console.war/WEB-INF/jboss-web.xml (AS6) file and uncomment the security-domain block. The security-domain value of jmx-console maps to the server/PROFILE/conf/login-config.xml JAAS configuration file, which defines how authentication and authorization is to be performed.
Edit the server/PROFILE/conf/props/jmx-console-users.properties file and change the users and passwords as desired. They will need the JBossAdmin role as specified in the web.xml file to run the JMX Console.
Secure a Web Application In JBoss
Securing web resources basically involves setting some stuff in the web deployment descriptor, and in jboss-web.xml. You also have to do a little prep work to the server itself to configure a security domain for JBoss SX. These instructions assume that you have JBoss AS installed, and you have a server instance created with at least Tomcat included. The “default” instance is a good choice here. The variable ${jboss.dist} refers to the location you extracted/installed JBoss AS to, and ${server.name} cooresponds to the name of the server instance you are configuring for security. The first part of these instructions refers to setting up JBoss SX for security, and the second part deals with setting up the web application for security using basic authentication.
Remove the Invokers or Secure the Invokers
HTTP Invokers
If you want to remove the HTTP invokers (which are used if you ‘tunnel’ your requests through HTTP) simply remove the according deployments/directories from the …/deploy/ directory.
Please be aware that HTTP invokers are something different than the Tomcat HTTP Connector (the HTTP invokers need the HTTP connector but the HTTP connector does not need the HTTP invokers).
HTTPInvoker for JNDI, EJB and JMX
Simply remove the …/deploy/http-invoker.sar/ directory from your configuration all together.
HTTPInvoker for JMS
Remove the …/deploy/jms/jbossmq-httpil.sar directory completly.
Other invokers
There are a lot of other invokers bound to different ports. If you don’t need them you may remove them. Otherwise secure them if they are reachable by folks you don’t fully trust.
Remove or restrict RMI ClassLoading service
There is a simple http service that supports requests for classes for RMI dynamic class loading, org.jboss.web.WebService. The configurable attributes for the WebService MBean service are as follows:
Port: the WebService listening port number. A port of 0 will use any available port.
Host: Set the name of the public interface to use for the host portion of the RMI codebase URL.
BindAddress: the specific address the WebService listens on. This can be used on a multi-homed host for a java.net.ServerSocket that will only accept connect requests to one of its addresses.
Backlog: The maximum queue length for incoming connection indications (a request to connect) is set to the backlog parameter. If a connection indication arrives when the queue is full, the connection is refused.
DownloadServerClasses: A flag indicating if the server should attempt to download classes from the thread context class loader when a request arrives that does not have a class loader key prefix.
DownloadResources (4.0.3+) : A flag indicating if the server should attempt to download non .class file resources using the from thread context class loader. Note that this is generally a security risk as it allows access to server configuration files which may contain security settings.
ThreadPool (4.0.2+): The org.jboss.util.threadpool.BasicThreadPoolMBean instance thread pool used for the WebServer class loading. Typically this is used with the mbean service dependency injection syntax as shown in the example configuration.
Secure JBossMQ (Need to change to JBoss Messaging)
To configure security on JBoss MQ there are a few steps you need to take. These involve the following:
- Identify a security domain to use for messaging.
- Configure your MDB:s to use security credentials when reading from the message queues / topics.
- Use the authenticated connection methods when connecting to the messaging service from your clients.
- Configure security on the topics and queues.
Remove HSQLDB
JBoss 3.2 and 4.0.x
- remove the descriptor for the HSQLDB datasource DefaultDS by deleting deploy/hsqldb-ds.xml;
- in conf/login-config.xml, comment out the <application-policy> declaration with the name “HsqlDbRealm”;
- remove the HSQLDB libraries by deleting lib/hsqldb.jar and lib/hsqldb-plugin.jar.
Several services rely on the datasource:
- JBossMQ;
- EJBTimerService;
- HiLoGenerator.
After removing the datasource you should either:
- configure another datasource with the JNDI name DefaultDS;
- go through all the references in the various descriptors and change them to reference another datasource.
Using JBoss Behind A Firewall
JBoss comes with many socket based services that open listening ports. In this section we list the services that open ports that might need to be configured to work when accessing JBoss behind a firewall.
Set Up A Keystore or SSL Setup
Generate keystore file with your own password : quick setup
$ keytool -genkey -keystore /data01/jboss/server/xxx/conf/keystore -alias jbossAdmin $ keytool -list -keystore /data01/jboss/server/xxx/conf/keystore
Limit Access to Certain Clients
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.
1.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.
2.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
How to Run JBoss with a Java Security Manager
By default the JBoss server does not start with a Java 2 security manager. If you want to restrict privileges of code using Java 2 permissions you need to configure the JBoss server to run under a security manager. This is done by configuring the Java VM options in the run.bat or run.sh scripts in the JBoss server distribution bin directory. The two required VM options are as follows:
java.security.manager: This is used without any value to specify that the default security manager should be used. This is the preferred security manager. You can also pass a value to the java.security.manager option to specify a custom security manager implementation. The value must be the fully qualified class name of a subclass of java.lang.SecurityManager. This form specifies that the policy file should augment the default security policy as configured by the VM installation.
java.security.policy: This is used to specify the policy file that will augment the default security policy information for the VM. This option takes two forms: java.security.policy=policyFileURL and java.security.policy==policyFileURL. The first form specifies that the policy file should augment the default security policy as configured by the VM installation. The second form specifies that only the indicated policy file should be used. The policyFileURL value can be any URL for which a protocol handler exists, or a file path specification.
Both the run.bat and run.sh start scripts reference an JAVA_OPTS variable which you can use to set the security manager properties.
Categories:
Application,
JBOSS,
WEB SERVER
0 comments:
Post a Comment