The RabbitMQ Security and Hardening Guide

RabbitMQ carries traffic on three separate channels and each is configured independently: AMQP client connections on 5671/5672, Erlang inter-node distribution on 25672, and the management HTTP API on 15671/15672. Teams routinely enable TLS on the first and leave the other two in the clear, which means cluster replication and administrative credentials cross the network unencrypted.

Turn on TLS for all three, verify with rabbitmq-diagnostics listeners that no plaintext listener survives, and set certificate expiry monitoring. An expired inter-node certificate partitions the cluster, so it belongs on the same alerting as disk and memory.

The default guest account is restricted to localhost out of the box, which is why it survives so long: it looks harmless until the broker moves behind a load balancer, a container network or a Kubernetes service, and localhost stops meaning what it did. Delete it rather than changing its password.

Give every application its own user with its own credential, so that a rotation, a revocation or an audit question can be answered per application rather than per cluster. Human administrators authenticate separately from services.

RabbitMQ permissions are three regular expressions per user per vhost: configure, write and read. The default an application gets during development is .* on all three, which permits deleting every queue in the vhost, and it is almost never narrowed afterwards.

Scope each to the resources the application actually names. A publisher needs write on its exchange and nothing else; a consumer needs read on its queue and configure only if it declares. Getting this right is what turns a compromised application credential into a contained incident.

A vhost is RabbitMQ's isolation unit: separate exchanges, queues, users and permissions, on shared cluster resources. Estates that put every team in the default / vhost have no boundary at all, so one team's runaway queue triggers a memory alarm that blocks every publisher on the cluster.

Give each team, environment or tenant its own vhost, and apply per-vhost limits so one cannot exhaust the cluster for the others. Isolation is a security control and an availability control in the same change.

Two ports should never be reachable from a general network: 25672, which carries Erlang distribution and trusts anything holding the cookie, and 4369, the epmd port mapper. The management UI on 15672 belongs behind a VPN or an authenticating proxy, not on a public address, however strong the password is.

Write the intended reachability down as a short table, then verify it from outside the cluster with a port scan rather than from the firewall configuration. Configuration and reality diverge, and the scan is what an assessment reports.

Security posture on RabbitMQ is mostly a function of version. A cluster inside the supported window takes patches on a normal cadence; a cluster past the community support window has no upstream fix for anything found after that date, whatever the scanner says the severity is.

Keep a current mapping of advisories to the version you run, and treat "no patch exists" as an architectural finding rather than a ticket. The two honest answers are upgrading, or a support arrangement that backports fixes to your series.

The Erlang cookie is the shared secret that authorises a node to join the cluster and issue commands against it. It is frequently checked into a configuration repository in plain text, copied between environments, or left at a value generated years ago, and anyone holding it plus network access to 25672 has full control of the broker.

Store it in the same secret manager as database credentials, make it distinct per environment, and rotate it on a schedule. Scheduled definitions exports belong in version control; the credentials inside them do not.

An auditor asks three questions: who has access, what changed, and when was it patched. A cluster with no definitions history, no retained access logs and no patch record cannot answer any of them, and the assessment finding is the absence of evidence rather than a technical weakness.

Schedule definitions exports into version control so permission and policy changes carry a diff and an author, retain management access logs against the retention period your industry requires, and keep the patch record alongside the CVE mapping from step six.

FIPS-validated cryptography, data residency and air-gapped operation are usually assumed to be handled by the platform underneath, and are usually not verified at the broker. The cipher suite RabbitMQ negotiates, the module it negotiates it with, and where messages come to rest are all broker-level questions.

Confirm them explicitly where the regime applies. It is a short exercise when the answer is yes, and a long one discovered late when the answer is no.