Securing your MQTT infrastructure against DDoS Attacks
IoTIFY’s cloud-based network simulation tool lets you create a swarm of devices to stress-test your IoT infrastructure.
MQTT brokers are engineered to withstand a constant bandwidth flux and serve real-time information to connected clients. As a result of the very nature of the network topology that powers MQTT, brokers are the heart of any IoT application as well as the primary focus of any DDoS attack targeting IoT system. Testing and augmenting the resilience of an MQTT broker are the necessary actions any IoT development team has to face eventually. Especially, if you operate a public MQTT broker, it’s just a matter of time before you will be subjected to some form of a DDoS attack.
How could you measure your IoT infrastructure resiliency against a DDoS attack on the application layer for MQTT?
Just like any public web infrastructure, MQTT systems are also threatened by a variety of attack vectors such as TCP SYN flood, Slowloris. The strategy to deal with such attacks is similar to the common defensive measures taken by existing Web infrastructure. There are other questions one should be able to answer about an IoT infrastructure, such as:
Will your system ever automatically recover from attack?
How much time does my system take to come back up?
How does a failure situation on my broker impact my operations?
There are certain basic counter-measures every MQTT infrastructure should employ to defend against DDoS attack:
Client Authentication: TLS authentication with certificates for every client. The approach is really difficult to implement for a large scale fleet, especially when enrolling and renewing certificates for every client. An alternate is to use at least a unique username/password for each client, which is certainly less secure.
Capacity: What is provisioned capacity for your MQTT broker? Do you have Clustering with network load balancing and client affinity?
Throttling: Due to the very nature of MQTT messaging, it is very easy to amplify a DDoS attack. All the attacker needs to do is to find out which topic is most subscribed by the clients and flood the broker with messages on that topic with a higher QoS message. The throttling and rate limiting must apply not only to per client (using either client ID or IP/port combination) and also on a global basis. Not only does this improves the system stability, it also provides security to end point.
Topic Space partitioning: It is also a good practice to partition topic spaces more elegantly and avoid subscription on global topics unless required.
Proving MQTT resiliency with IOTIFY's network simulator
Let's assume you have built a full proof infrastructure and now looking to roll out to public. How could you guarantee that your system could handle a real life situation? IoTIFY network simulation tool is specially designed to helo you validate your theory into practice. It creates a virtual botnet army of MQTT agents in the cloud, scaling to the number you desire at clients per second or messages per second.
We run on the cloud, and our system scales with your needs. You can simulate both legitimate traffic sources and attacking agents using the same set of tools. Furthermore, you can fine tune your system to defend across a variety of use cases with respect to topic focus, analytic fraud detection, unauthorized connections, etc. We have set forward a free account at www.iotify.io so you can create an account and test it out for free whenever required. If you are looking to simulate more than 100K nodes, please contact us to and we would be happy to work together with you to unleash the beast.
We are eager to know about the resilience of your brokers in order to craft a MQTT DDOS-Resiliency ranking. Let us know!