Recently, my RSS feed on OpenNMS stories turned up an article listing a possible remote code execution exploit in a number of applications, including OpenNMS.
In it, the researcher shows that it is possible to execute code on the OpenNMS server remotely due to a bug in the Apache commons library, which OpenNMS uses.
We’re a little unhappy that they published this without letting us know first (note that the e-mail address “security at opennms dot org” exists for reporting such things), but it is pretty easy to make sure that your instance of OpenNMS is safe. Simply configure the server’s firewall to disable remote access to port 1099 (it will need to remain for localhost).
I was happy to notice that the example he uses seems to be related to OpenNMS running on Windows. It can be a bit tricky to get OpenNMS to work on Windows, and perhaps the Windows default firewall doesn’t block port 1099 so that it why they noticed it.
It is a good idea to run something like iptables on your OpenNMS server and limit remote access to a minimal set of ports. Technically, the only port you really need access to is 8980, which is the default port for the webUI. I would assume that you would want port 22 for ssh access (unless you want to use the console for all configuration). In addition, port 162 should be open for SNMP trap reception.
That should be it. Now the application needs access to other ports (such as 5817 for events) so those need to remain accessible from localhost (127.0.0.1 or ::1) but that limits all exposure to only people who have shell access to the server, which we assume you limit to those people you trust. Remember to include IPv6 firewall rules if you use it.
An easy test to see if that port is remotely accessible would be to run:
telnet [IP or hostname of OpenNMS server] 1099
from a remote system to see if you can access the port. No connection should be made.
Sorry about this, but as I mentioned this wasn’t revealed to us until after the exploit was public. We are looking in to how we can better protect against this issue from a code change standpoint, but until then simply blocking access to the port will prevent most problems. We do plan to have a code fix in place soon.
If I can make a suggestion, you might want to look into Apache River. The service registrar allows for certificate-based security, and JERI (Java Extensible Remote Invocation) allows for secure remote method invocation as well.
Interesting thing about the Jini registrar is that it doesn’t actually load the proxy classes it returns, so it isn’t susceptible to remote code exploits.