Now that we have seen how to secure our message broker, we also need to test that our setup is indeed in place and really prevents attackers from bringing down the message broker or stealing messages. For this reason, you can build your own custom tool for penetration testing of the message broker, which performs the following functions:
- It checks whether the guest/guest user is present and it can perform administrative activities.
- It tries to brute-force passwords for an existing set of users, either based on a password generation policy or using a predefined password database.
- It tries to access prohibited vhosts from a particular set of users.
- It uses nmap to check whether the management console and RabbitMQ communication ports are visible; this step may include checks on ports that are exposed by RabbitMQ plugins.
- It checks the RabbitMQ configuration settings, authentication mechanism, and currently-set limits such as minimum free disk space, memory limits, or maximum number of channels. (Most of these options were covered when we discussed the performance tuning of the message broker.)
- It checks the maximum limit per user as specified by the operating system, for example, this could be the maximum number of processes or file descriptors that can be used for the user that runs the RabbitMQ instance. In Linux, this could be checked against the
etc/security/limits.conffile.
More features can be derived from the following article that covers several security considerations and resource utilization settings for production deployments of RabbitMQ: https://www.rabbitmq.com/production-checklist.html
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.