RabbitMQ Security Review

RabbitMQ creates a default user called guest with well known default credentials on every fresh install, and the loopback_users setting confines that account to localhost connections until it is changed to none, a change RabbitMQ’s own documentation says is very strongly recommended against.

Why RabbitMQ security comes down to virtual host permissions, user tags and what the broker exposes

RabbitMQ’s access control documentation grants every permission as a triple of regular expressions, one each for configure, write and read, on a per virtual host basis: the pattern ‘.*’ matches every resource name in that vhost and the pattern ‘^$’ matches nothing, stopping the operation outright. Every install also creates a default user called guest with well known default credentials, and RabbitMQ’s own documentation confines that account to localhost connections through the loopback_users setting, calling the alternative, removing that restriction, very strongly recommended against. We test what each user’s three patterns actually cover against what their application needs, and whether guest, or an account like it, can be reached from anywhere but localhost.

The management plugin serves its browser UI and HTTP API from the same listener, port 15672 by default, gated by five tags, none, management, policymaker, monitoring and administrator, layered on top of ordinary vhost permissions rather than replacing them; the documentation is explicit that being an administrator does not itself grant access to exchanges, queues or bindings. TLS support is configured separately again: the AMQP listener needs listeners.ssl.default set to run on port 5671, with ssl_options.verify set to verify_peer and ssl_options.fail_if_no_peer_cert set to true before a client without a certificate is rejected, while the management plugin takes its own management.ssl.port, normally 15671. We test which tag each account holds against what it can actually see or change through the UI and API, and whether either listener still accepts a connection with no certificate at all.

Clustering runs on distributed Erlang, and RabbitMQ’s clustering guide describes every node and CLI tool authenticating to the others with a shared secret, the Erlang cookie, normally kept in a file that must be readable only by its owner; epmd, listening on port 4369, tells a connecting node or CLI tool which port, typically 25672, a named node is actually using for that traffic. Plugins such as shovel and federation move messages between brokers over their own AMQP connections, authenticated with credentials that commonly sit inside the source and destination URIs and are stored as runtime parameters. Amazon MQ and CloudAMQP put the same permissions, TLS and plugin questions behind a managed control plane with a different testing boundary, and for the wider family of cache and streaming platforms this scope splits from, see our NoSQL, cache and streaming security review.