Security Considerations

From OpenNMS
Jump to navigation Jump to search

This page is designed to cover the security aspects of an OpenNMS installation. Since OpenNMS theorically has views into your entire network, keeping that information safe is very important.


Most users of OpenNMS put the application on a dedicated server. While mainly for performance reasons, it is also a good idea for keeping the system secure. The less software you have installed, the less chance that a vulnerability will be discovered or exploited.

That is also why it is a best practice to install OpenNMS on a minimal install of the operating system. The default install of many popular O/S's can contain a number of unnecessary applications, especially if you use the desktop version, and not only do these take up disk space, they present a possible attack vector. If you install the minimal O/S of your choice and then follow the Tutorial Installation page, the installation process will install any missing packages.

As with any application, limiting access to the system it is running on is a good first step for security. Only people that need shell access should have it.

The main method for limiting external access to the system is by using a server-level firewall. For a fairly exhaustive list of TCP and UDP ports and ICMP datagram types that OpenNMS uses, see Firewall Policy and OpenNMS. While that page is pretty verbose, you can get away with most installs with just ports 22 (ssh), 162 (SNMP traps) and port 8980 (webUI) open. Tighter security is available if you configure the webUI to use SSL. Then you can disable external access to 8980 and replace it with your SSL port of choice (usually 8443). Note that processes such as RTC will require access to the non-SSL port, so you will need to leave that access from the localhost.

Reporting Possible Exploits

If you find an issue with OpenNMS that you believe affects security, please let us know via e-mail to

The Web Server

Tomcat (OpenNMS 1.0.0 to 1.6.0)

This page is obsolete. Please see Jetty instead.

Jetty has replaced Tomcat as the default servlet container for OpenNMS including situations where you run the web UI in a separate JVM. Using OpenNMS with Tomcat is no longer supported.

By default, in its 5.5 incarnation (as used by OpenNMS 1.3.2), a standard tomcat from will start listeners on port 8080 (http connector), 8009 (ajp13 connector) and 8005 (shutdown service). The shutdown service binds directly to the loopback address, so we can effectively ignore this.

ajp13 8009

The ajp connector is only required if you intend to connect to tomcat via ajp13 from apache using mod_jk, mod_jk2 or mod_proxy. Most installations will be happy to turn this off by commenting it out. The configuration directives are found in $TOMCAT_HOME/conf/server.xml thus:

<Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />    

You will need comment these out in the usual way and restart tomcat for this to take effect.

http 8080

In order to restrict access to tomcat's applications, you can use it's remote address filter. For simplicity's sake, it's probably best to configure this at the highest (Engine) level within tomcat's configuration heriarchy, for example, just under the default Engine configuration:

<Engine name="Catalina" defaultHost="localhost">
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192.168.1., 192.168.2."/>

Jetty (OpenNMS 1.8.0 and above)

All recent versions of OpenNMS (1.8.0+) use Jetty as their web server for the web UI and REST interfaces.


By default, Jetty runs HTTP on port 8980 and can also run the AJP protocol on port 8981 so these are the ports that should be protected with firewall rules. If you wish to run Jetty on an alternate port, change the following values in the file. You can also change the local interface that Jetty will bind to. By default, it will bind to all IP interfaces.

###### JETTY WEB UI ######
# If you are using Jetty, this is the port to listen on
org.opennms.netmgt.jetty.port = 8980
# If you want Jetty with AJP support, this is the port to listen on
#org.opennms.netmgt.jetty.ajp-port = 8981
# By default, Jetty will listen on all interfaces. You can set a specific
# bind address here. If you set this to a value other than,
# you will need to update the rtc-client and map-client URLs above. =


If Jetty is configured to use HTTPS then this will open an additional port that can also be configured inside The default port is 8443. The interface that the HTTPS interface binds to can also be configured. Just like HTTP, HTTPS defaults to listening on all IP interfaces.

# Details:
# If you want Jetty to provide an HTTPS listener, this is the port to listen on
# Note that setting this property does NOT disable the plain HTTP listener,
# which is required by Rtcd to post realtime status updates.  If you do not
# wish to allow unsecured HTTP access to the OpenNMS web UI, you must set
# above or use firewall rules to accomplish this.
org.opennms.netmgt.jetty.https-port = 8443
# By default, if configured for HTTPS, Jetty will listen on all interfaces.
# You can set a specific bind address here.
#org.opennms.netmgt.jetty.https-host =

The RTC User

OpenNMS employs a Real-Time Console that allows the opennms daemon to communicate network status updates with the front-end servlet engine in near-real-time. Since all of the servlets are protected by a realm module, the opennms daemon must authenticate to the servlets. A special user, rtc was created for this purpose. In the default configuration, though, it is insecure.

By default, all OpenNMS users are part of the OpenNMS User role. This includes the rtc users. Since the default password for the rtc user is simply rtc, this means anyone who knows this information and has the ability to contact your OpenNMS installation can log in with this user and view your OpenNMS installation. The information contained in your OpenNMS installation is likely not public knowledge and should not be viewable by non-staff. Now, in all fairness, your OpenNMS installation should be protected from the Internet at large if at all possible, but you may have need for it to face the Internet, or you may have internal users who can get to your installation but should not be able to log in.

Lucky for us, changing the password, and even the username, for the rtc user is an easy task. The first place to change this information for versions 1.3.6 and older is the web.xml deployer file. Find the RTC Subscription parameters section in the web.xml file and change it to be the following:

  <!-- RTC Subscription parameters -->  
    <description>The username the RTC uses when authenticating itself in an HTTP POST.</description>
    <description>The password the RTC uses when authenticating itself in an HTTP POST.</description>
      The base of a URL that RTC clients use when creating a RTC subscription URL. 
      IMPORTANT: This URL must NOT contain a slash at the end.       

Set the RTCUSER to your rtc user's username. Next, set the RTCPASSWORD to your chosen password.

For versions 1.3.7 and newer, change the rtc username and password in the file WEB-INF/ if you use Tomcat, or in the file etc/ if you use jetty.

If you change the rtc username, you must make sure the new username is a member of the OpenNMS RTC Daemon role in the etc/ file. Find the lines RTC Daemon
role.rtc.users=RTCUSER, admin

and change RTCUSER to your new rtc user name.

If you're using LDAP Authentication, then you're done. Just make sure the password for the rtc user in your LDAP directory matches what you set above. If you're using the default OpenNMS realm module, you need tt make some additional changes to the file in the OpenNMS configuration directory (/opt/OpenNMS/etc in the Linux RPMs).

If you changed the rtc username as described above, you need to change it in the file as well. In addition, you'll need to change the rtc password in this file. Find the lines below and make the appropriate changes:



Change all instances of RTCUSER to your new rtc user name you set above, and change the RTCPASSWORD to the same password you set above.

That's it. Restart OpenNMS and Tomcat (if you're using it), and you're done.