Java: Not Even Once
In mid-January of this year we started an initiative to remove Java browser plugins from all employee systems at Etsy, as we feel this is a best practice to be striving towards. To that end, we wanted to discuss the challenges we encountered when removing Java browser plugins in the hope that it will help other organizations with the removal process.
The first question we needed to answer before removing Java was “Who actually needs Java in their browser?” Most organizations face the unfortunate reality that some number of internal systems use Java applets, and that there are groups which use these systems on a daily or weekly basis. In our case, our operations team needed Java to be able to access a group of internal network appliances, such as IPMI console interfaces. Once we identified these requirements, we disabled Java browser plugins across the rest of the organization and set about trying to engineer a safer way for the team to access these network appliances.
Initially, we looked at three approaches:
- Installing the Java plugin in a dedicated browser/browser profile and asking the team to use it to only access the network appliances.
- Writing a wrapper script to copy the Java plugin into the plugins directory, launch a dedicated browser, then remove the Java plugin when the browser closes.
- Using nssecurity to whitelist the hosts that could instantiate Java in the browser.
However, all of these approaches didn’t fulfill our design goals that the approach be safe by default, be easy to maintain, and ideally wouldn’t require the Java browser plugin on the teams laptops at all.
We realized the only way to approach the situation that met our requirements would be to have Java installed in a dedicated, controlled, and isolated environment.
This model is similar to a bastion host, or “jump box”. We opted to use NoMachine as the remote desktop protocol because of the increased performance and usability over low latency links. We have operations engineers located in multiple countries and we also occasionally need to use 3G/4G mobile services to diagnose problems, so this was critically important.
The installation method we followed for CentOS 6 and FreeNX was:
- Install the required packages. All of these come from the standard CentOS repos:
yum install -y jre freenx gnome-desktop gnome-session gnome-panel nautilus firefox fre
(After installation, be sure to replace the provided SSH keys: https://help.ubuntu.com/community/FreeNX#Using_custom_SSH_keys)
- Create a symlink from the Java browser plugin, to the plugins directory used by Firefox:
ln -s /usr/java/latest/lib/amd64/libnpjp2.so
- Now create
with these contents:
FreeNX is now configured!
Each of your users who wants to use the new system needs to do the following steps once to add their user to the NX authentication database:
(NOTE: These steps below follow the Ubuntu FreeNX instructions of using a shared account/SSH key for access to the jump system. In this circumstance the risk was accepted as the network appliances that are the end target also use a shared account, so no additional risk was introduced. Obviously different circumstances will have different security requirements.)
/etc/nxserver/client.id_dsa.keyto your local machine and save it as
- On the jump host, run
sudo nxserver --adduser <username>
This adds your account to the nxserver database. Note: at this step it will also add a key to your
.ssh/authorized_keys2file, if you manage this in your configuration management system it will get overwritten, so you should add the key there.
- On the server again, run
sudo nxserver --passwd <username>
This sets your password in the nxserver database
- Download the “NoMachine Player v4” from: http://www.nomachine.com/preview/download-package.php
- Start the player, click “New connection”.
- Select: Use the NoMachine login, then click the
- Check Use an alternate key and point it to
- Press the
Xtwice and then click the
jumpboxconnection you see.
- Enter your login details.
Create a new session
Create a new GNOME virtual desktop
- You should get a gnome desktop, with a firefox icon.
Using the jump system approach, we’re now able to firewall off these hosts from Internet browsing, we can re-image them on a frequent basis, and we have a very small number of hosts that need to receive Java updates. This approach also allows us to configure our endpoint management software to nuke Java from orbit if the browser plugin ever shows up on employee systems. While we generally abhor single points of failure in our infrastructure, we felt comfortable in this case because the use of configuration management meant that the environment could be quickly rebuilt if needed. Finally, this approach could also be used to isolate other inherently risky technologies when they are still required by certain groups.
In closing, we genuinely hope this helps other organizations facing similar challenges on the road to removing Java browser plugins from the enterprise.