Securing port 8083

[neilmcc]

Hi,

I'm close to deploying a real-world application on jBoss and have noticed that in v2.4.0, connecting to localhost:8083 gives me a directory listing of jBoss' bin directory. This seems to be a bigish security hole - is there any way to force the generation of a blank web page instaed - or even just point the 8083 "doc base" to a different directory?

[starksm64]

Remove the WebService mbean from the jboss.jcml file. Your clients will not be able to dynamically download RMI classes from EJB jars. I'll have to look into why the bin directory is being listed.

[nuanda]

Hi Scott,

Is there a "standard" way for an application client to access the ejb stubs from the JBoss http service? ...or do you need to set up your own ClassLoader on the client to go and pick them up ? (Currently we just ship the stubs with the client).

re your comment: "I'll have to look into why the bin directory is being listed."

Where do you plan to have the http service's root directory for picking up stub jars ? Doesn't the ejb-jar.xml tag <ejb-client-jar> refer to a relative location within an ear (jar) file (as opposed to the file system) for locating the stubs?

Thanks,

Dave

[starksm64]

JBoss does not use RMI stubs for accessing EJBs. The WebService allows one to download implementation classes associated with your EJBs that you may not want to provide. For example, if an EJB returned an IString interface from one of its methods and used an AStringImpl class to implement IString, the client would not need to have the AStringImpl class as the RMI codebase is set to the WebService URL and would be downloaded from the WebService.

There is no root directory for the WebService. It uses the class loader associated with an ejb jar deployment as well as the JBoss server class loader.

The fact that the bin directory is visible is just a bizare feature that I have not seen before.

[neilmcc]

Scott,

Thanks for the tip. I've tried removing the WebServer mbean, but get this exception on deploying the application. Does this suggest I'm missing the RMI stubs?

[Container factory] javax.management.InstanceNotFoundException: DefaultDomain:service=Webserver
[Container factory] at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1678)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1522)
[Container factory] at org.jboss.util.MBeanProxy.invoke(MBeanProxy.java:80)
[Container factory] at org.jboss.proxy.ProxyCompiler$Runtime.invoke(ProxyCompiler.java:74)
[Container factory] at org.jboss.web.WebServiceMBean$Proxy.addClassLoader(Unknown Source)
[Container factory] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:365)
[Container factory] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:304)
[Container factory] at java.lang.reflect.Method.invoke(Native Method)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Container factory] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:486)
[Container factory] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:464)
[Container factory] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:208)
[Container factory] at java.lang.reflect.Method.invoke(Native Method)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Container factory] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379)
[Container factory] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
[Container factory] at org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:353)
[Container factory] at org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport.java:107)
[Container factory] at java.lang.reflect.Method.invoke(Native Method)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Container factory] at org.jboss.configuration.ConfigurationService$ServiceProxy.invoke(ConfigurationService.java:836)
[Container factory] at $Proxy0.start(Unknown Source)
[Container factory] at org.jboss.util.ServiceControl.start(ServiceControl.java:81)
[Container factory] at java.lang.reflect.Method.invoke(Native Method)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Container factory] at org.jboss.Main.<init>(Main.java:210)
[Container factory] at org.jboss.Main$1.run(Main.java:116)
[Container factory] at java.security.AccessController.doPrivileged(N

[davidthewatson]

I have discovered what may be an even larger security hole via port 8083. If you make a get request against the following URL via mozilla 1.0:

http://yourserver:8083/login-config.xml

JBoss returns mal-formed XML revealing data sources, userids and passwords. I have confirmed this behavior on jboss-3.0.0 and jboss-3.0.2 on a straight install on redhat 7.2 and sunos 5.6. With a default install this looks like:

guest jboss.mq:service=StateManager sa sa jboss.jca:service=LocalTxCM,name=hsqldbDS sysdba sysdba masterkey jboss.jca:service=XaTxCM,name=FirebirdDS guest guest guest jboss.jca:service=XaTxCM,name=jmsra

But, of course with my oracle installation at work, we've just given away the keys to the palace! Hopefully somebody can tell me what to do. I'm specifically interested in how to solve this if getting rid of 8083 as outlined by stark in the above post is not an option.

Thanks,
David