A system is as secure as its weakest component taking the message broker into account. As RabbitMQ instances can be used to carry sensitive application data or affect the stability of an entire system, we need to make sure that our RabbitMQ deployments are secured properly.
The topics covered in this chapter are as follows:
- Types of threats
- Authentication
- Authorization
- Secure communication
- Penetration testing
There are several aspects in which the security of the message broker is affected. RabbitMQ hasn't been planned to be exposed on the Internet initially; however, a number of security concerns exist even with in-house deployments of the message broker. We will stay away from this fact and not make assumptions on whether the broker instances under consideration are accessible via the Internet or not.
Let's consider again the standard three-cluster diagram (along with an additional remote broker instance) that we have been using so that we can see what security issues may arise in practice:
We can apply the following mechanisms in order to mitigate the identified threats:
- Authentication: This allows you to identify who connects to the message broker.
- Authorization: This allows you to determine the set of privileges and permissions for the authenticated user.
- Secure communication between the clients and the broker: By default, messages are exchanged by the senders/receivers and broker instances in an unsecure manner; however, RabbitMQ provides you with a mechanism to establish secure SSL communication.
- Secure communication between cluster nodes: Communication between the cluster nodes in the form of Erlang messages is also unsecure, and SSL communication can be established between instance nodes in a RabbitMQ cluster.
- Secure communication between remote nodes: As federation links and shovels provide a mechanism to mirror messages across instances over the WAN in a client-server fashion in an unsecure manner, you can establish SSL communication between them as well.
- Message encryption: If, by some chance, you cannot reliably secure all the message broker communication channels using SSL, you can encrypt the messages that are sent between the sender and consumer using a proper encryption mechanism (for example, asymmetric encryption with the RSA algorithm using a key of proper length, 2048, 4096, or others). Depending on the mechanism used and performance requirements of the application, there could be a trade-off between security and performance. This applies to the previous cases when SSL communication takes place as well.
- Proper client settings: When we discussed performance tuning, we discussed a number of settings for resource utilization of the broker. Many of them can be applied in order to mitigate DoS or DDoS attacks that target resource exhaustion on the message broker by means of sending excessive number of messages, creating a huge number of connections (thus preventing other clients from connecting), or sending an excessive number of AMQP messages.
- Physical security: Physical access to the workstations where the message broker is deployed should be properly restricted, and the disks where Mnesia tables reside should be properly encrypted in order to mitigate the risk of data leakage in case of theft (typically, in cases where the message broker stores sensitive data passed through messages).
- Plugin security: Plugins can also expose vulnerabilities, so it is important to use plugins from trusted sources that are updated on a regular basis or at least do proper verification that the plugin isn't doing something malicious.
Vulnerability databases such as CVE (Common Vulnerabilities and Exposures) along with other resources on the Internet could prove to be good sources of information regarding known issues against which you can check production deployments of the broker for possible security issues.
In the next sections, we will demonstrate other basic types of attacks and how to get protection against them. Apart from the techniques, we will demonstrate that you need to make sure that you have a message broker upgrade plan set in place. The RabbitMQ team provides security fixes with upcoming releases of the message broker.