Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This morning i received from the auditors a scanner result for our jboss server and we need to solve three important issues, but honestly i was googling for a while and nothing found. if any one know or have any clue how to solve, i will appreciate. We are running jboss 5.0.1 on (windows 2003 x64)

Scan vulnerability:

   .- JBoss HttpAdaptor JMXInvokerServlet is Accessible to Unauthenticated Remote Users
   .- JBoss EJBInvokerServlet is Accessible to Unauthenticated Remote Users.
   .- TLS Protocol Session Renegotiation Security Vulnerability

Thanks in advance.

share|improve this question

migrated from stackoverflow.com Jun 6 '11 at 13:57

This question came from our site for professional and enthusiast programmers.

add comment

2 Answers 2

up vote 2 down vote accepted

http://yourservernamehere:8080/invoker/EJBInvokerServlet

If you've left your configuration as is, the above is available you have a problem.

The reason you don't want to do it is pretty clear, it allows anyone to invoke any servlet they want that is on your system.

The short answer is, find it in your web.xml and disable it.

A Tomcat Specific article about the why: http://www.astrahosting.com/blog/2009/09/16/chapter-14-tomcat-security-disabling-an-invoker-servlet/

share|improve this answer
2  
Mitigating the TLS Protocol Session Renegotiation Security Vulnerability depends on what you're using as your web front end. If you're running ssl on jboss, you'll need to upgrade your JVM to a version of java greater than or equal to 1.6.0_22 (if you need tls renegotiation support) or versions 1.6.0_19-1.6.0_21 (if disabling TLS renegotiation entirely is ok for your site). –  mahnsc Jun 11 '11 at 17:38
add comment

JBoss has horrifically insecure defaults, and is a terrific pain in the ass to lock down (a lot of files to touch, and crummy documentation spread all over creation on a collection of sites). It's worse than the first versions of IIS were back in the mid-1990s.

IMHO it should never be exposed directly to the internet - it's just too easy to screw up, and you never know when an upgrade will introduce a new open-to-the-world "feature".

So, to lock it down, put a proxy in front of it and pass only the application URL patterns you know you want the world to see. We are using nginx as a proxy on Linux talking to JBoss servers on Windows x64, but there are a lot of options in this area. Even ARR on IIS7 works well in this scenario.

share|improve this answer
    
more of a rant than an answer. –  Mark W Jul 11 at 9:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.