What is MQTT?

I recently had to explore MQTT. I had never heard of this protocol before. However some helpful resources provide a clear explanation what MQTT is about.

MQTT is a machine-to-machine (M2M)/”Internet of Things” connectivity protocol that uses a lightweight publish/subscribe messaging transport. MQTT works on top of TCP/IP and by default uses port tcp/1883.

A quick search on Shodan reveals that there are a lot of devices publicly available, primarily in the US and Asia.

The publish/subscribe method in MQTT consist of a client subscribing to receive messages that are distributed by a broker. These messages are received from a device that is publishing its content to the broker. Theses messages are linked to so called topics. The simplest way to look at this is to consider topics as a “resource”.

Security within MQTT

The MQTT protocol does not include a lot of security features by design. This doesn’t mean that it’s insecure, it just requires additional wrapping or configuration settings to be secure.

Authorization (publish/subscribe)

A mis-configured publish / subscribe setup can grant access to all topics (content) for clients or can lead to the pollution of the messages that are distributed by the broker. How do you fix this? By using authorization and implement topic permissions on the broker side.

The permissions need to include the topic and what operations (subscribe or publish) are allowed. The article MQTT Security Fundamentals: Authorization describes how you can tackle the authorization problem within MQTT.

One of the features of brokers is to grant permissions on wildcard topics. These wildcards should be avoided because it prevents you from maintaining fine-grain control on authorising access to specific topics (resources).

Authentication

Closely related to authorization is authentication. MQTT supports authentication by providing for example username and password fields in the CONNECT message. The mechanism that is used after submitting the authentication credentials for granting or denying acces then further depends on the implementation of the broker.

Important to know is that authentication credentials are sent in clear text.

Additionally the broker itself needs to be secured. If an intruder is able to compromise the broker they can capture or extract the authentication credentials (certificates etc.). This is no different as compared to other “centralised” authentication methods.

Encryption

MQTT traffic is by default in plain text, including its authentication credentials. Obviously this is not a good idea.

MQTT traffic can also be encapsulated in TLS. This is then called “secure-mqtt” and uses the port tcp/8883.

Take care that when you use TLS to always use the latest TLS version and to validate the full certificate chain.

Isolation

Hooking up IoT devices (regardless if they use MQTT) on a public network is never a good idea. This is also the case for MQTT devices. Network isolation is a must for IoT devices. As a rule of thumb :

• Firewall all the MQTT components (clients, brokers, …);
• Put them on a separate network, isolated from your normal office network;
• Log the connections going to your brokers. Do this either via the firewall or via netflow.

Conclusion

If you plan on using MQTT then

• Put those devices on a firewalled network, isolated from the Internet and from your office network;
• Use TLS for transportation;
• Harden the brokers and monitor the access to the brokers (log review, netflow traffic);
• Do not use wildcard authorization;
• Implement a strong authorization schema for the topics;
• Use certificate authentication on the brokers.