AS 4.2.0 binding to localhost

[ryan.campbell]

In an effort to make JBoss more secure by default, the following issue was addressed in 4.2.0.CR1:

http://jira.jboss.com/jira/browse/JBAS-4119

Now if you just type "run.sh", JBoss will default to binding to localhost. This decision was the result of a discussion on the jboss-dev list here:

http://lists.jboss.org/pipermail/jboss-development/2007-February/006100.html

Unfortunately, this will not do anything to improve out-of-the-box security. The user will just add the -b option and be on their way without any thought. There is nothing in adding the "-b" option that prompts the user to secure their JMX console or anything else. Scenario:

1. User types run.sh, tries to hit "myhost.com"
2. User scratches head, realizes JBoss now binds to localhost by default
3. User curses JBoss, uses ./run.sh -b myhost.com
4. User once again has unsecured JMX Console

The problem is, the user is not forced to consider security. All we did was create an inconvenience.

[ryan.campbell]

We could address this by only allowing connections to jmx-console from localhost, or any other methods which require configuration on the user's end. At least we could have a chance to have something like this:

******
Before uncommenting this, see http://wiki.jboss.org/SecureJBoss
******

A smarter option would cause JBoss to refuse to listen on anything but localhost with an unsecured JMX console unless you pass the "--unsecure" option.

[mazz]

Its the user's job to decide if allowing unsecured access to JMX Console is allowed under any circumstance - its not our job to deny such access without it being a configurable setting.

That said, we should at least spit out very loud warnings in the logs if we detect unsecured access outside of "localhost".

I think the solution to this is to:

log.warn("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
log.warn("!!!!! WARNING !!!!!!");
log.warn("! YOU ARE ALLOWING UNSECURED ACCESS TO JMX CONSOLE !");
log.warn("! PLEASE SEE http://jboss.com/SecureJBoss FOR MORE INFO !");
log.warn("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");

At least you can't miss that when you start the server every time (assuming someone looks at the logs every now and then - which you would assume someone would before putting a JBossAS instance in production that is accessible to the world)

[starksm64]

The point of the change was to not be the source of the unsecure, globally available access. We were getting security exploit postings over this issue. Logging a message is not effective either.

Inconvience is the point. If your trying to access the server remotely, then you have to change something and the release notes document why localhost is the default. It was argued that it would be more inconvient to completely disallow access to the jmx console by configuring it to only configure users without valid permissions to access the consoles. The argument for localhost was that testsuites would not be broken, as well as allowing the typical localhost deployments used by developers.

[anil.saldhana]

My solutions:
a) Allow the user to only install via the installer. Here we can force the user to choose an admin /passwd.
b) Do not include the jmx-console/web-console anymore with the default distribution. Let it be an on-demand download with an installation notes mandating security of the consoles.

[starksm64]

a) possibly. The testsuite setup would also need to run to lay down the default with security configured in accord with the testsuite.
b) would have to be all jmx invokers and this would also break the testsuite.

[ryan.campbell]

I'm skeptical that the existing approach will actually push users to read any documentation. All they will do is type ./run.sh --help and find the -b option.

I agree inconvenience is the point, so long as it actually accomplishes the goal of forcing users to deal with the security implications. The current approach does not go far enough.

[mark.cox]

I'm skeptical that the existing approach will actually push users to read any documentation.

Binding to localhost does at least stop us being insecure by default and is something we do in Red Hat Enterprise Linux with servers such as sendmail.

However we've also discussed a better solution -- having HTTP Basic authentication turned on by default for any consoles, with no username and password configured. A user browsing the console for the first time (if they don't use the installer) would be prompted to log in and when failing to log in a custom "403 Authentication Required" response would be displayed and could point them at the documentation. Using the installer would by default give the user the ability to setup this user/password.

[dimitris]

First of all, better don't make assumption about how users will react to the change. If jboss binds to 0.0.0.0 since year 1999 and now this has changed to localhost, I think this is already a big change and will at the very least make people wonder why's that. Release notes and blogging will help explain the problem, too.

Second, for the really naive users without any jboss knowledge that just unzip jboss, throw in a webapp, and they are done, or the case where a jboss server is installed by default and is just waiting there, unused, this measure offers some really basic but essential protection. Remember that we received negative comments about "remotely accessing a default jboss installation" and this is what we are fixing here.

From the point where somone starts messing with command line parameters and configuration options he/she must assume responsibility for his/hers doings.

I agree we can assist a user to create a more secure environment, but this is done either in the installer, or some post installation script. Besides, there are many points you need to secure, not just the jmx-console.

In my understanding, if we lock up everying in the default developer-oriented .zip distro, we'll just manage to enrage developers. And don't forget that the .zip distro IS primarily made for developers.

In a production environment where you'll have to make quite a few configuration changes before installing/testing/fine-tuning a server, securing the server is really one of the standard items in your checklist.

[ryan.campbell]

First of all, better don't make assumption about how users will react to the change. If jboss binds to 0.0.0.0 since year 1999 and now this has changed to localhost, I think this is already a big change and will at the very least make people wonder why's that. Release notes and blogging will help explain the problem, too.

We are both making assumptions about how users will react. The difference is you are being optimistic, and I am being pessimistic. I agree veteran users will notice a change, but they are likely not the source of our "problem."

If the goal is to provide legalistic arguments that we are secure by default, the status quo is fine. If the goal is to reduce the perception that we are insecure, we won't make any progress with the existing solution.

I completely agree it is the job of the deployer to secure the jmx-console and other vulnerable access points, but they are consistently not doing their jobs and we are getting the blame.

[dimitris]

I'm pessimistic, too, in that creating a locked up static config will make more damage in our reputation for being developer friendly, than do good in our reputation for being unsecure.

And AFAIK. the user perception that we are "unsecure" came from a default installation. If you check the jboss forums people rarely complaint about an unsecure jboss - most of them know what they are doing.

There is so much you can do with a static configuration that needs to satisfy everyone. If there is no tools support for altering a jboss configuration at installation time, this is not a problem of the .zip distro. It's the problem of the tool.

[wuschelz]

I have just upgraded a system to the new Jboss Version.

We start this Jboss Instance with JbossService and now i'am wondering whereto give the parameter -b hostname.

I was thinking about bringing the b Option into the run.bat but i failed.

Do you have any sugestions.

greetz
wuschelz

[0bshaffer]

Can anyone recommend a fix for wuschelz's question?

I've created a JBoss service using javaservice.exe and I've run into the same issue, where it only binds to the localhost address.

TIA

[nrichards]

wuschelz, obshaffer,

Did either of you guys manage to figure out how to use the jboss service with the -b option?

Thanks,
Neil

[robsteranium]

This might help:

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss42FAQ