In the IoT they often don’t give much importance to the security aspects of the communcation. Proof of this is that many of the latest DDOS (Distributed Denial of Service) attacks have been launched by hacked Internet-connected smart devices.
In the previous posts, you learned how to configure mosquitto to receive messages published by clients and to forward them to all the subscribers. Today I’m going to show you how to configure the application security of your MQTT broker.
The first step to make our broker secure is to require clients who are connecting to authenticate themselves. In this way, only authorized clients can send/receive messages.
Open the mosquitto.conf file and, first of all, disable the anonymous access setting to false the corresponding parameter.
The list of the users authorized to connect to the broker is defined in a dedicated file. The name of this file is configured with the password_file parameter (in the example below, the file containing users and passwords is named “pwdfile”, stored in the same folder of mosquitto):
Using the mosquitto_passwd.exe command you can create (-c) the file and add a new user (“luca”). The command will ask to type the user’s password twice:
If you need to add additional users, you can run the command again, without the -c option:
mosquitto_passwd.exe pwdfile sara
Let’s try the new configuration. First run mosquitto specifying the configuration file (mosquitto.exe -c mosquitto.conf), then try to publish a message as you learned in the previous tutorials:
You can see that the connection is refused because of the client is not authorized: we indeed didn’t specify any users and anonymous access was disabled.
Try to run the command again, this time specifying the correct user and password and you’ll find that the message will be correctly published:
mosquitto_pub.exe -u <utente> -P <password> -t home/bedroom/temp -m 19
After having defined who can connect to the broker, it’s now time to define what a user can do once connected. Again, the configuration of the ACLs (access control lists) is in a dedicated file, whose name is configured with the acl_file parameter:
The ACL file contains blocks with the following structure:
- the first line, user <nomeutente>, that defines the user the following ACLs are applied to
- one or more lines, topic <read|write|readwrite> <nometopic>, that define which actions the user above can do on the specified topic
Let’s see an example, a file in which we define a user (writeclient) that can send messages to the secure/data topic and a user (readclient) that can read those messages. Both the two users can in addition send an receive messages from all the open/# topic (for an explanation about the use of wildcards read my previous post):
(lines starting with # are comments)
Let’s now try to send a message using the readclient user, who’s not allowed to do that:
The client doesn’t get any error message, but in the mosquitto logs you can clearly see that the publish command was denied, consistent with the configured ACLs.
If instead the right users are specified, the message is correctly routed from the publishing client to the subscribing one:
It’s very important to secure our broker, especially if it’s connected to a public network (for example if it’s available on the Internet). In today’s blog post you learned how to define users and grants in mosquitto.