Return of the Unauthenticated, Unfirewalled protocols

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, January 23, 2017

Follow me on Twitter as @mattiasgeniar

People are starting to realise that having insecure, unauthenticated and unfirewalled services running on the internet is a bad idea. Who knew, right?

What started with a MongoDB ransom is quickly spreading to new services that are equally easy to “exploit".

Insecure Defaults

It’s already been covered in great detail that service defaults are tremendously important. I’m the kind of sysadmin that likes to be explicit in server configs, not trusting default settings. Some argue that it’s pointless and a waste of time, that system packages have good sane default values.

Well here’s a little packaging secret: the ones doing the packaging aren’t necessarily the ones creating the software. It’s often a voluntary job, helping others with good RPM or DEB packages to use. And while I’m certain packagers do a reasonable effort to create secure default values, they might be missing important gotcha’s.

UX vs. Security

Case in point: if you install Memcached on a Red Hat or CentOS machine, it will by default listen to all interfaces.

Super convenient as most users run their Memcached services on different servers. It’s good UX. But as Memcached is an unauthenticated protocol, it also allowed anyone to connect to your Memcached instance and read/write data to it, flush the cache, … if it’s not firewalled properly.

Where should the trade-off be between UX and security? In order for a technology to become widely adopted, UX is arguably more important. However, as adoption grows, everyone quickly realises that_ _security _should_ have been the priority.

Securing data

MongoDB servers worldwide have been held ransom. Attackers have already moved on to other services like Redis & ElasticSearch.

I feel it’s incredibly important to highlight these are data storage engines. They’re databases. They hold your company’s and clients’ data. This is your business.

If you’re going to secure any service, it had better be the ones holding all the data.

Next Up

As an attacker, what else can you hold ransom? Or phrased differently: what other services hold important customer data that is worth extracting?

I’ll give you some ideas:

  • Cassandra
  • RabbitMQ, ActiveMQ, ZeroMQ, …
  • Beanstalkd
  • Collectd
  • Logstash
  • Neo4j

Note that _most _of these services have support for authentication, it just needs to be configured explicitly.

Raising awareness

In a way, these ransom attacks are a good thing: they raise awareness to the acute problem that is an unauthenticated and unfirewalled service.

There’s nothing wrong with a protocol that doesn’t support authentication. It probably does so for good reason (simplicity, performance, …).

There’s also nothing wrong with unfirewalled services, some just need this (think webservers, mailservers, …).

But there is a problem when those are combined and start to hold important company data.

It’s almost as if an entire new generation of sysadmins have come online, started a few services here and there and called it a day. That’s not what sysadmins do. That might be something developers do when they lack time or resources to contact dedicated sysadmins.

Let’s hope these recent attacks cause a shift in the way these services are managed and highlight the need for skilled sysadmins and managed services.

Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.