Return of the Unauthenticated, Unfirewalled protocols

Mattias Geniar, Monday, January 23, 2017

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.


Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links