-
1. Re: Securing port 8083
starksm64 Sep 19, 2001 10:27 PM (in response to neilmcc)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.
-
2. Re: Securing port 8083
nuanda Sep 19, 2001 10:40 PM (in response to neilmcc)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 -
3. Re: Securing port 8083
starksm64 Sep 19, 2001 11:03 PM (in response to neilmcc)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. -
4. Re: Securing port 8083
neilmcc Sep 20, 2001 7:47 AM (in response to 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
-
5. Re: Securing port 8083
davidthewatson Sep 7, 2002 11:23 AM (in response to neilmcc)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