Securing MQTT

#javaland 2017

www.bestppt.com INTRODUCTION

Dominik Obermaier @dobermai Disclaimer

Obligatory Disclaimer: All security suggestions and guidelines in this talk are collected from real-world projects and experiences.

When in doubt how to apply these techniques in your own projects, please consult a security professional you trust. Key Protocol Facts www.bestppt.com MQTT Protocol Characteristics

Messaging Publish / Lightweight Protocol Subscribe

Binary Data Agnostic Easy Publish / Subscribe

publish: “21°C“ publish: “21°C“ laptop

publish: “21°C“ temperature MQTT-Broker sensor

mobile device Security

www.bestppt.com The mantra of any good security engineer is: 'Security is a not a product, but a process.' It's more than designing strong cryptography into a system; it's designing the entire system such that “ all security measures, including cryptography, work together.

- Bruce Schneier Multiple Security Layers and Aspects

www.bestppt.com Security Layers

Network

Host

Application

Data Network & Secure Communication Reduced Attack Surface Reduced Attack Surface

— Client initiates TCP connection

— Client doesn’t need (and shouldn’t be) addressable from outside

— IPv6 Privacy Mode should be used

— NATs can further decrease attack surface NAT Transport Layer Security (TLS) Network Stack TLS

— Cryptographic protocol

— Provides a secure communication channel between client and server

— TLS handshake initiates TLS session

— Client validates X509 certificate from server TLS Handshake https://commons.wikimedia.org/wiki/File%3AFull_TLS_1.2_Handshake.svg Source: Wikimedia Commons: Best Practices

1 Always use TLS if possible

2 Use Certificates from trusted CAs

3 Always validate the X509 certificate chain

4 Use highest TLS version and secure cipher suites X509 Client Certificates X509 Client Certificates

— Client sends certificate as part of the TLS handshake

— The server is able to verify the identity of the client and can abort the handshake

— Authentication on Transport Layer

— Some brokers can use certificates for authorization The challenge: Provisioning and revocation X509 Client Certificate Provisioning + Revocation

— How to deploy certificates to MQTT clients?

— Works great if PKI is already in place

— Certificate Revocation Lists for small deployments

— Online Certificate Status Protocol for online certificate validation Security Layers

Network

Host

Application

Data Firewall MQTT Ports

MQTT + TCP MQTT + TLS MQTT + Websockets

1883 8883 80 / 443 Official IANA Port Official IANA Port Standard HTTP Ports Firewall Best Practices

— Only listen on defined ports

— Only allow traffic from a specific IP range if possible

— Block all protocols except TCP *

— Create iptables rules for common attacks * ICMPv6 may be needed for IPv6 OS Best Practices (Linux)

— Keep libraries and software updated

— Disallow Root Access and use SSH Keys for SSH

— Setup SELinux

— Install Tools like Fail2Ban, Snort, OSSEC Security Layers

Network

Host

Application

Data Choose your MQTT Broker wisely Broker Selection Broker specific security mechanisms

— Authentication

— Authorization

— Throttling

— Message Size Restrictions Criteria for choosing MQTT brokers Criteria for Broker selection

— What security features does the broker have out of the box?

— Does the broker have a pluggable security mechanism

— Is TLS supported?

— Do security features thwart the broker? Authentication Authentication is the act of confirming the truth of an attribute of a single piece of data or “ entity. - Wikipedia on “Authentication”

But how does Authentication work with MQTT? Authentication Authentication Information

— Username + Password

— Client Identifier

— IP Address

— X509 Client certificate Authorization Authorization and MQTT

— Authorization can restrict Topics a client can publish or subscribe to.

— Black and Whitelists

— Message characteristics also possible to restrict (Retained, QoS) OAuth 2.0 OAuth 2.0

— Only Client Credentials Flow Applicable to MQTT

— Designed for HTTP but also usable for MQTT

— Uses JWT for Access Tokens on CONNECT

— Online (JWKS) and Offline Validation (Signature Validation) Possible OAuth 2.0 Client Credentials Flow Why OAuth 2.0 instead of plain User Credentials? OAuth 2.0 Advantage over Credentials

— MQTT Brokers will never — Brokers are just Resource see a password - Only Servers - Access Tokens Authorization Servers could also be valid for which issue Access Tokens other Resource Servers

— Online and Offline — Authorization information Validation Possible can get encoded in the JWT by using custom — Access Tokens only have a claims limited lifetime and can get revoked Security Layers

Network

Host

Application

Data Payload Encryption Message Data Integrity Security Layers

Network

Host

Application

Data A key concept is that security is an enabler, not a disabler... security enables you to keep your job, security enables you to move into new markets, “ security enables you to have confidence in what you're doing.

- Gene Spafford THANK YOU

QUESTIONS?