Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 Jun 6 '11 at 13:57

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

up vote 2 down vote accepted


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:

share|improve this answer
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

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 '14 at 9:06
The question was definitely answered. It was a rant AND an answer. Three years later and I stand by it too... JBoss should never be exposed directly to the internet. The attack able surface is huge, and many defaults are still woefully insecure. – rmalayter Jul 26 '14 at 1:53

Your Answer


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.