Hardening RabbitMQ

RabbitMQ’s default posture is better than most people assume and worse than they notice. The famous guest/guest account exists — but out of the box it can only connect over loopback, so a fresh broker is not quite the open door it looks like. The trouble starts when someone needs a remote client to authenticate and lifts that restriction without understanding what it was for.

And RabbitMQ carries a second attack surface most services don’t: it runs on the Erlang virtual machine, whose clustering mechanism — if reachable and its shared secret is weak — is a direct path to running code on the host.

7 controls

Replace the RabbitMQ guest userA universally known credential, one setting away from remote useSeverity: critical
Restrict RabbitMQ network listenersThe clustering ports reachable from outside are a path to the hostSeverity: critical
Protect the RabbitMQ Erlang cookieThe cookie plus a reachable dist port is code execution as rabbitmqSeverity: high
Enable TLS for RabbitMQCredentials and message bodies cross the network in plaintextSeverity: high
Scope RabbitMQ virtual hosts and permissionsOne credential can read, reconfigure and drain every queueSeverity: high
Secure the RabbitMQ management UIA full broker admin console, findable on a well-known portSeverity: medium
Set RabbitMQ memory and disk limitsUnbounded queues exhaust the host and block the brokerSeverity: low

Version

rabbitmqctl version

4.3.2 is current (June 2026). The 4.x line is where you want to be; 3.x has reached or is nearing end of community support depending on the minor. As with everything on this site, patch before you tune — a hardened broker on an unsupported release is still unsupported.

The four ports

RabbitMQ listens on more than the one port people think about, and each is a distinct exposure:

Port	Purpose	Who should reach it
5672	AMQP (plaintext)	Your applications — or nobody, if you use TLS
5671	AMQP over TLS	Your applications
15672	Management UI / HTTP API	Admins only, ideally not at all remotely
25672	Erlang distribution (clustering)	Only other cluster nodes
4369	epmd (Erlang port mapper)	Only other cluster nodes

The last two are the ones people forget, and they’re the dangerous ones — see the Erlang cookie page and network listeners.

Where the config lives

Modern RabbitMQ (3.7+) uses /etc/rabbitmq/rabbitmq.conf (a simple key = value sysctl-style format). An older advanced.config (Erlang terms) still exists for settings the new format doesn’t cover.

rabbitmqctl environment | head -40          # effective config
rabbitmq-diagnostics status                 # listeners, memory, alarms
rabbitmq-diagnostics listeners              # exactly what's bound

rabbitmq-diagnostics listeners is the one to trust — it shows what the running node actually bound, which is what an attacker sees, not what a file says.

Reloading

Some settings apply at runtime via rabbitmqctl; listener, TLS and clustering changes need a restart:

sudo systemctl restart rabbitmq-server

Restarting a broker drops every connection and channel — clients must reconnect, and a broker that’s a single point of failure for a queue means a brief outage for whatever depends on it. Plan restarts.