Public Service Announcement

Creating Strong Passwords

Posted on by Tarus

For obvious reasons I’ve been creating some new passwords lately, and I wanted to share my method for creating strong passwords that are easy to remember yet hard to guess.

Of course, Randall Munroe set the bar with this comic:

xkcd Password Strength comic

It does make a lot of sense, but the method has its critics. Attackers can and do use random word generators which can break such passwords more quickly, even with, say, substituting “3” for “e”, etc.

There is also a good argument to be made that we should all be using password managers that generate long random passwords and not really creating passwords at all.

Then there is the very good idea of using two factor authentication, but that tends to augment passwords more than replace them.

In normal life you have to have at least a few passwords memorized, such as the one to get into your device and one to get into your password manager, so I thought I’d share my technique.

I like music, and I tend to listen to pretty obscure artists. What I do is to think of a random lyric from a song I like and then convert that into a password.

For example, right now I’m listening to the album Wet Tennis by Sofi Tukker. The track that gives me the biggest earworm is “Original Sin” which opens with the lyric:

So I think you’ve got
Something wrong with you
Something’s not right with me, too
It’s not right with me

If I were going to turn that into a password, I would come up with something like:

sItUgswwysnrwm,2inrwm

Looks pretty random, and contains lower case and upper case letters, a number and a special character. At 21 characters it isn’t quite as long as “correcthorsebatterystaple” but you can always add more words from the lyrics if needed.

Just thought I’d throw this out there as it works for me. The only thing I have to remember is not to hum the song while logging in.

Rhythmbox: Repeat One Song

Posted on by Tarus

I use Linux Mint as my default desktop environment. One of the reasons I started using it was that the default applications for many functions were the default applications I would choose if I were making a distro.

Their choice for music player used to be Banshee. I really liked Banshee – it reminded me of the early versions of iTunes before that application became too complex. Unfortunately, Banshee is no longer under active development, and the last release was back in 2014.

As the underlying libraries have changed and matured, Banshee has not kept up. For example, if I plugged in my handy Banshee would hang if the MTP mount was being accessed elsewhere. Mint recently decided to switch to Rhythmbox, and I’ve finally made the decision to start using it.

One of the things I’ve learned about open source is to be patient learning a new app. The reason there are often numerous open source solutions for various tasks is that people do things differently, and it can take awhile to understand how a particular application is designed to work. I’ve found that many features I thought were lacking in Rhythmbox were there, just implemented differently than I expected. If the feature is, indeed, missing, you can often add it with a plugin.

I’ve recently been exposed to the music of Imogene Heap, starting with her album Sparks. I really like the sixth track “Lifeline” and I wanted to listen to it a couple of times on repeat. There is a repeat button on the menu, so I clicked it, but that just repeats the playlist. In other apps you can click that icon multiple times and it will rotate through various options: i.e. repeat playlist, repeat song, etc. Not so with Rhythmbox.

A quick search and I found a plugin hosted on Github to add this feature. I downloaded the repository, unzipped the file, and then copied it to ~/.local/share/rhythmbox/plugins/. I then went to Tools -> Plugins and enabled “Repeat One Song” (no restart of the app needed). Now, under the Edit menu, I have the option to repeat the current song.

Repeat One Song Screenshot

Not quite as nice or intuitive as clicking on a button, but it works.

While I see this as a great example of the awesomeness of open source, it also brought out the downside of free software. There was this comment:

This should not be a plugin.. It should be there by default if rhythmbox wants to call itself a music player.

Seriously? A bunch of people write a complex piece of software, give it away for free, build in a way to extend it, but no, that’s not enough. This guy isn’t satisfied that these folks didn’t cater to his every need, even though edumucelli has gone to the trouble to add it.

Free software isn’t a free solution, and I just wanted to post this to remind people, including myself, that often it takes an investment of time to really get to understand how an application works.

In open source, often our first goal is to make something that works before we make something that is easy to use. I’m not proud of this, but quite frequently the motivation behind the developers of free software is to solve a problem important to them and it just happens to be useful to others. And even companies that focus heavily on UI and try to build intuitive interfaces can get it wrong. I’ve had to work with recent versions of iTunes and find it rather difficult to do simple things, although I’m certain that if I used it more I would learn what I needed to do, just like I have with Rhythmbox.

Which I’ve grown to like. It works well with my mobile device and I’m eager to watch it improve even more in the future.

Privacy and Trash

Posted on by Tarus

Meet Sam. Sam is in his early twenties and grew up in Lake Mills, Wisconsin. He graduated from the University of Wisconsin in Madison in 2012. He is currently on vacation in Athens, Greece, with his girlfriend Sara. They managed to find an amazing deal on American Airlines from Minneapolis to Athens for $200 for the both of them, but with taxes and fees that ballooned up to nearly $850.

I have a copy of Sam’s resume, his Gmail address and his phone number. I know how long he’ll be gone and what seats they will be sitting in on their return. In fact, I know a lot more about Sam and Sara (Facebook and its ilk are ubiquitous) but I’m a little uncomfortable revealing as much as I have, so I’ll stop.

It is all because of this:

Sam Boarding Pass

With all the focus recently on the security of devices like those that make up the Internet of Things, what is often forgotten is that traditional paper has huge security issues in today’s connected world.

Airlines still insist on printing first and last names along with record locater codes on boarding passes. That is often all that is required to access a particular reservation. From there you can get information such as e-mail addresses and phone numbers.

This reminds me of when credit cards first came out and to use one the merchant would take an actual imprint of the card on carbon copy paper. Since that included the shopper’s name, complete card number and expiration date, it became easy for thieves to steal this information. At least now almost all receipts include, at most, the last for digits of the card (in case you were wondering, Sam used a Mastercard ending in 3286).

The genesis of this post arose from a more malicious reason. I fly a lot and over the years commercial air travel (which is the only air travel I can afford) has become less of a special occasion and more like taking a bad bus trip. People use the “seat back pocket” as their personal trash can, to the point that I almost never use it myself, even when I get upgraded to first class. Nasty. On this trip, the duration from when the last person got off the inbound plane until we started boarding our flight was less than ten minutes, so trust me when I say little was cleaned between flights.

I don’t blame the airlines. Consumers have spoken, and what they want is cheap airfare, so it is up to us to be respectful of our fellow passengers.

Anyway, when I see folks like Sam leave information like this as trash, I am so tempted to do things like reassign his seat to one in the middle next to the lavatory (it’s an 11 hour flight), or to cancel his flight completely. Lucky for him I believe in karma, and I just can’t bring myself to do it.

The basics of security involve two things: something you have and something you know. We need to apply this to everything that needs to be secure. I get so frustrated with systems in the United States, such as the new “chip” cards being used for credit and debit. Introduced a decade ago in Europe, their systems use “chip and PIN” – something you have, your card, and something you know, your PIN. In the US we are moving to “chip and signature” – something you have, your card, and something anyone can fake in a heartbeat, your signature.

(sigh)

This is especially touchy since two summers ago my spouse had her purse stolen. We immediately canceled and closed all of the accounts, but they were still able to get over $2000 out of our checking account. They used a paper check from another theft and then they cashed it at the bank using her ID. The bank forgot the “something you know” part of security even though they were quite aware that our account had been compromised and the account number changed. Only after the fact did they offer to “flag” transactions on our account for extra scrutiny, and now neither of us carries paper checks, although thieves could probably guess our bank from our ATM debit cards (we did get our money back from the bank).

So be careful. Buy a good shredder. If you need to dispose of paper when traveling, tear it into tiny bits and drop it in the nastiest trash can you can find … and not in the seat back pocket.

The Importance of Contributor Agreements

Posted on by Tarus

One thing that puzzles me is the resistance within the open source community to contributor agreements. This was brought into focus today when I read that the OpenSSL Project wants to migrate to the Apache 2.0 license from the current project specific OpenSSL license.

In order to do that they need permission from all of the nearly 400 contributors of the project over the last 20+ years, and contacting them will be a huge undertaking. If one person refuses to agree, then they will either have to abandon the effort, or locate that person’s contribution and either remove or replace it.

Many years ago we found out that a company was using OpenNMS in violation of our license. When our lawyer approached them about it, they claimed that they were only using those parts of the code for which we didn’t hold copyright. At that time, early versions of OpenNMS were still copyright Oculan, the company that started the project, and not OpenNMS. Since Oculan wasn’t around anymore it took us awhile to track down the intellectual property, but in the end David and I were able to mortgage our houses to purchase that copyright so that now the project can control all of the code and defend it from license abuse in the future.

But the question arose about what to do moving forward, specifically how should we deal with community contributions? In the past companies like MySQL required all contributors to sign a document with phrases like “You hereby irrevocably assign, transfer, and convey to MySQL all right, title and interest in and to the Contribution” which seemed a little harsh.

I posed this question to the Order of the Green Polo, the de facto project administrators, and DJ Gregor suggested we adopt the Sun Contributor Agreement that we now call the OpenNMS Contributor Agreement, or OCA. This was a straightforward document that asked two things.

First, you attest that you have the right to contribute the code. This is more important than you know, because it helps remove liability from the project should the contribution turn out to be encumbered in some way, such at the author writing it as part of their job and thus it is actually the property of the employer. We allow both individuals and companies to sign the OCA.

Second, you assign copyright to OpenNMS while retaining copyright yourself. This introduces the concept of “dual copyright”. Now some critics will say that this concept hasn’t been tested in court, but there is a long history of authors sharing copyright. Considering that Oracle maintained the agreement in the form of the Oracle Contributor Agreement, it appears that their lawyers were satisfied.

I claim responsibility for the license under which these Contributor Agreements are published: the Creative Commons Attribution-Share Alike License. When DJ suggested the Sun Contributor Agreement I noticed that there wasn’t any license on the agreement itself. I didn’t want to just copy it and change “Sun” to “OpenNMS”, so I contacted Brian Aker who had just moved to Sun with the MySQL acquisition and asked him about it. Soon thereafter the Agreement was updated with the license and we adopted our version of it.

Once we adopted the OCA, I was tasked with tracking down anyone who had ever contributed to OpenNMS outside of the company or Oculan and asking them to sign it. They all did, but I can tell you that I had a hard time tracking down a number of them (people move, e-mails change). I don’t envy OpenSSL at all.

I hope this story illustrates the importance of some sort of Contributor Agreement for open source projects. They don’t have to be evil, and in the end getting your copyright and licensing issues completely sorted out will make managing them in the future so much easier.

Electronic Devices and CPB

Posted on by Tarus

With the change in administration in the United States, Customs and Border Protection (CBP) have modified their behavior to include actions with which I don’t agree. These include forcing a US citizen to unlock his mobile device, even though it was a work device and contained sensitive information. I set out to come up with how I will deal with this situation should it arise in the future.

TL;DR My plan is as follows: before I enter the United States, I will generate a long, random password and set that as the encryption password for my laptop and my handy. I will then ssh into an old iMac I have on my desk, store the password in a file, and then shut the computer down. At that point I will not be able to access the information on my device until I return to the office and power on the system.

UPDATE: The EFF has published a detailed guide to help understand your rights at the border.

First off, let me say that until recently I’ve always respected CPB. They have a tough job and everyone I’ve ever met while returning from my travels has been efficient, competent and friendly.

But after the recent “Muslim Ban” fiasco I’ve come to realize that my experience is not universal. I think one of the main problems is this idea that the Constitution stops at the CBP desk, and until you are past it you really aren’t “in America” and thus the Constitution doesn’t apply.

I don’t agree with this interpretation, but it can probably be traced to the actions taken by the US government after 9/11 and the creation of the prison at Guantanamo Bay.

Prior to that, when “bad hombres” were captured by the US government, they fell into one of two categories: criminals or prisoners of war. How each class was treated was fairly well defined. Criminals were processed according to the rule of law, and the treatment of POW’s was covered under the various Geneva Conventions.

The US government decided that those two classifications were inconvenient, and so they ventured into the murky waters of “enemy combatant” and Guantanamo. Their logic goes that since Guantanamo isn’t in the US, US law doesn’t apply, and since these people aren’t members of a foreign country’s military force with which we are at war, then they aren’t POWs. So, the US gets to make up its own rules about how these people are treated.

This is dangerous for a number of reasons. Since nothing is really codified about the treatment and rights of the detainees at Guantanamo, the rules are arbitrary. Also, this opens the door for other countries such as Russia to do similar things without fear of international repercussions. The US has survived for so long because things like this are not supposed to happen, yet here we are.

This thought now extends to the border. Even though a US citizen is being questioned by another US citizen, in the role of a representative of the US government on US soil, somehow the rules of the Constitution are suspended. It’s arbitrary and I don’t buy it. The Constitution codifies a right to privacy in the Fourth Amendment, and it doesn’t go away when entering the country. And it definitely extends to mobile devices, which in today’s world are probably the most personal item people own.

So how can people like me, with almost no political power, resist this threat to our freedom?

I’ve always done little things, like opting out of millimeter wave scans at airports and getting a pat down instead (I’m not shy). If everyone did this the whole system would collapse, and they would find better ways of dealing with security than the security theater we have now. Seriously, if the Israelis don’t use it, it ain’t worth using.

When I turned to the problem of dealing with CBP, my main thoughts went to two devices that I use when traveling: my handy (mobile “phone”) and my laptop. I figured the easiest thing to do would be to just wipe them before coming into the country, but that presents some logistics problems.

For example, I could make a backup of my handy, copy it to a server at home, and then wipe it. The problem is that I have 64GB of storage on the device and I doubt I could transfer a backup in time over, say, a hotel Wi-Fi connection. One of my coworkers uses an iPhone and they thought about wiping their phone and just restoring it from iCloud when they were in the country, but then CBP could require that he turn over his iCloud password.

On my laptop I use whole disk encryption, but I thought about just rsync’ing my home directory and then deleting it before leaving, then again there is the WiFi issue and I really don’t want to have to deal with copying everything back when I’m home.

Then it dawned on me that if I didn’t know the encryption password, then I couldn’t reveal it. The problem became how to create a secure password that I couldn’t remember yet get it back when I needed it.

While my main desktop computer runs Linux Mint, I keep an old iMac on my desk mainly to run WebEx sessions and for those rare times I am forced to use a piece of software not available for Linux. It’s connected to the network, so I can access it remotely. But, if I can access it, I would be lying if CBP asked me for my password and I said I couldn’t retrieve it. Unlike the US Attorney General, I refuse to perjure myself.

Then it dawned on me that I could shut the iMac down remotely and have no way to turn it back on. Thus I could store a passphrase on it, retrieve it when I was back in the country, but until then I would be unable to unlock my devices.

That became the plan. So, the next time I’m returning from overseas, I’ll generate a new, random password. I’ll set that as the whole disk encryption password on my laptop and the encryption password on my handy (note that this is different from the screen-lock password). This will also tie up all of my social network passwords since I use complex ones and store them on those devices. Well, with the exception of my Google account, but since I use two-factor authentication I should be safe as my handy is the device that generates the codes (and I won’t carry any of the backup codes). As long as both of those devices stay powered on, I’ll be able to use them, but once I power them off they will be useless until I get to the office, power on the iMac, and retrieve the passphrase. Note that in order to do that, I’ll be firmly in the US and anyone who wants me to unlock my devices will need a court order.

Which I would respect, unlike CBP. I think the scariest part of the whole “Muslim Ban” incident was when CBP refused to honor court orders. America is built on three branches of government, and when the Executive branch ignores the orders of the Judicial branch we are all in trouble.

I had a two other problems to address, one of which is done. If I’m in the US but my handy is locked, how would I make calls? I might need to call my ride home, etc. To that end I bought a cheap “feature” phone and I’ll just move the SIM card to it when we land.

ZTE Feature Phone

The second issue is that while I should be on solid legal ground concerning my electronic devices, there is nothing preventing CBP from holding me for a long time. Thus the final step is to find an attorney and execute a G-28 form allowing them to represent me. I’m not sure if I need a civil rights lawyer or an immigration lawyer but I’m looking into it. My goal is to be able to notify my attorney when I am coming back into the country, and then send an SMS to them when I am through immigration. If that doesn’t arrive within two hours of my scheduled arrival, they need to come and get me.

I think the thing that bothers me the most about this whole process is the need for it. I’m not a tinfoil-hat conspiracy guy but the actions of the new government have me worried. As I use open source software almost exclusively I know I’m safer than most when it comes to surveillance, and I also don’t expect to run into any problems being an older, white male. But I’d rather be safe than sorry, and the only thing necessary for the triumph of evil is that good men do nothing.

2017 Europe: Three SIM card

Posted on by Tarus

Just a short post to praise the Three SIM card I bought in the UK several years ago.

I tend to buy unlocked phones and so when I travel I like to get a local SIM card, mainly for data. For this trip this was going to prove difficult, as I’m visiting five countries in nine days.

One thing I like about my Three SIM is that it never gets disabled. As long as I have a balance I have never had a problem, although I do travel enough that I end up using it at least once every six months or so. I am not able to top up the card on the Three website since I don’t have a UK credit card, so I simply use Mobiletopup.co.uk to get a £20 voucher from Paypal. Using that I just buy an “All in One 20” add-on which gives me 12GB of network access, 300 minutes and 3000 SMS messages – way more than I need. I turn that on before I leave the US and my phone works when I land.

What’s wonderful about it is that the plan is valid in any EU country. So far this trip I’ve used it in London, Helsinki and Tallinn, and I expect it to work in Riga and Brussels. I have yet to experience any network issues, although I have not moved far outside of major metropolitan areas.

I have no idea if Brexit will change this plan, but I sincerely hope not. So much of the technology I use in my life comes with headaches that I am grateful when things just work. Thanks Three.

Strong Encryption and Death

Posted on by Tarus

I try to use strong encryption wherever I can. While I doubt it will keep my thoughts from prying eyes forever, at least it should make peeking a little harder.

But it dawned on me: what happens when I die? I want to let my business partners see what is on my encrypted desktop and I know my wife will need access to the files on my systems at home. I could share them with her now, but my passphrases are complex and she isn’t very familiar with the operating systems I use.

Now I’m not planning on dying any time soon, in fact I want to live until I am at least 95 and a half. Why that age? Because that is when Halley’s Comet will return. I saw the comet when I was living in California in 1986 and I could care less about seeing it again, but I do want to be the old guy they interview:

“Back in ’86, now that’s 1986 for you young folks, I was livin’ in Los Angeles. The comet was too dim to see in the city, so we drove out to Joshua Tree …”

Halley's Comet 1986

So, how do I safely pass on my important passphrases? This is the solution I chose.

I created a file called “deathnote.txt” which I then encrypted using GPG:

gpg --encrypt --recipient tarus@opennms.com \
    --recipient alice@example.com \
    --recipient bob@example.com deathnote.txt

This will encrypt the file so that both Bob and Alice can read it (and I can too). I then sent it to several friends unrelated to them with instructions that, upon my death (but not before), please send this file to Bob and Alice. I also remembered to include a copy of my GPG private key:

gpg --export-secret-keys -a tarus@opennms.com

Just in case they can’t find it on my systems.

This does require a certain level of trust in my friends, but I am blessed with having several I can count on. As long as I remember to keep it updated this should provide a secure way to pass on this important information, although I hope no one has to use it any time soon.

Move to Let’s Encrypt – it’s soooo easy!

Posted on by Tarus

This weekend I wanted to play around with setting up Nextcloud on my home network (we already use it at work and it is awesome). Since I am planning on putting personal information into that app, I wanted to make sure that access to it was encrypted end-to-end.

This meant setting up SSL on my home web server. Now, it used to be that you either had to use a self-signed certificate (which could cause problems) or you had to spend a bunch of money on a certificate from a recognized Certificate Authority (CA).

Enter Let’s Encrypt. Launched in April of this year, Let’s Encrypt provides free certificates that are recognized by most of the things you need to recognize them.

I had been putting it off since dealing with certs is, quite frankly, a pain. You have to fill out a request, send it to the CA, get back a key file, install it in the write place, etc. Even with a free one I didn’t have time for the hassle.

I shouldn’t have worried – with Certbot it is dead simple. Seriously.

Certbot Screen

I went to their site (as directed from the Let’s Encrypt site) and just followed the instructions. I downloaded a script which downloaded all the required dependencies via apt, answered a few questions, and, bam, I had a functioning web server running SSL. They even prompted me if I wanted all requests to port 80 (http) to be redirected to port 443 (https) and when I said “yes” it did it for me.

The whole process took a couple of minutes.

Amazing stuff. The certificates are only good for 90 days, but they even include an automated way to update them.

Certbot Certificate Renewal

As more and more of our personal information becomes digitized, it is extremely important to use strong encryption. In the past this could be inconvenient if not outright difficult, but you really don’t have an excuse with Let’s Encrypt. Use it.

Horizon 16.0.4 Security Release

Posted on by Tarus

In response to the Apache Commons library that OpenNMS uses, version 16.0.4 has been released to help secure against a remote exploit.

The exploit involves Java Remote Method Invocation (RMI) which listens on port 1099 by default. In my previous post I pointed out that if that port is inaccessible, then the exploit can’t happen.

What 16.0.4 does is limit RMI to only listen on localhost. While that will prevent remote exploits even in the event port 1099 is blocked via the firewall, it doesn’t completely solve the problem. To fix the root cause of the issue will require changes to Apache Commons, and we are ready to upgrade to the fixed version as soon as it is available.

We tend to be very internally critical of security issues within OpenNMS, and some people complained that my last post wasn’t technical enough. So I’m hoping to correct that with this one, but if you don’t care about such things you should probably skip it (grin). I have started updating the Security Considerations page on the wiki with details about securing OpenNMS in general, and that will have better information for people interested in security and OpenNMS than this blog post.

While blocking external access to port 1099 will secure OpenNMS against this attack for most people, it doesn’t prevent people who have access to the machine from exploiting the vulnerability. This is called a “privilege escalation” attack vs. a “remote exploit”, as a “normal” user can now have rights (i.e. root access) if they are locally on the machine. Most of our users tend to limit shell access to the server, so this shouldn’t be a problem, but in environments that rely heavily on directory services such as LDAP, the default may be to allow non-privileged access to certain users (say, the “IT Group”) that aren’t involved in maintaining OpenNMS.

And there is also the slim chance that there is a vulnerability in our webUI that could allow a user access to the system. We, of course, don’t know of any and we take great care to prevent it, but simply hoping to limit access to the server as a way to prevent this exploit is insufficient.

So, to prevent it entirely, we are removing RMI. It was introduced in the first iteration of the OpenNMS Remote Poller, but real world installation found that getting the proper ports open was a real pain. So instead the remote poller now talks over HTTP/HTTPS (with the latter being the most secure). Most networks have ports 80 and 443 open, so that made things a lot easier.

Until that is introduced (most likely with Horizon 17), it is still a good idea to limit access to the OpenNMS server to only essential people.

Note that Java Management Extensions (JMX) also use serialized objects and thus could be vulnerable. OpenNMS has a JMX port (18980) but it is bound to localhost by default. In fact, all ports are bound to localhost by default in 16.0.4 except for the webUI, port 8980.

There are a number of other steps you can take to harden your OpenNMS server. I’m planning on detailing them on the wiki, but start with only doing a minimal operating system install. The less software on the system, the smaller the chance one will have a vulnerability.

Also, OpenNMS currently runs as the “root” user. This is due to the fact that it needs access to ICMP traffic as well as port 162 for SNMP traps. Both of these require root by default. With some “stupid kernel tricks” you can run OpenNMS as a non-root user, but it has not been heavily tested. We have a detailed list of issues for running as non-root on our Jira instance.

Sorry to drone on about this, but we take security extremely seriously at OpenNMS. We also have to labor under the misconception that Java is inherently unsafe. It is not true, although people still have nightmares from the early issues with client-side Java applets. The Java in OpenNMS is server-side and we don’t use applets, and the language is used securely in a tremendous amount of software.

For comparison, WordPress, an application I love, is currently estimated to run 25% of the world’s websites. It is written in PHP, a language that has a huge track record of security exploits, and many of the spam e-mails I get link to compromised WordPress sites.

It is possible to secure WordPress (we use it for all of our websites as well) but it takes some diligence. We will remain as diligent as we can concerning the security of OpenNMS, and we will continue to take steps to make it even more secure.

OpenNMS RMI Exploit

Posted on by Tarus

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.