RabbitMQ exposed to the internet

A RabbitMQ broker reachable from an untrusted network has several distinct ways to go wrong, and they range from bad to very bad. Unlike a database, where the loss is the data, an exposed broker can be a loss of the host — because RabbitMQ runs on the Erlang VM, and Erlang’s clustering is code execution by design.

The paths in, worst last

The management UI. Port 15672 with a weak or default account. If guest still works — which requires loopback_users to have been loosened — or any account has a guessable password, the management API is broker takeover through a browser: read every queue, publish anything, export /api/definitions (which includes password hashes), reconfigure everything.

AMQP with a working credential. Port 5672/5671 plus a known password lets an attacker publish to your exchanges and consume from your queues — injecting work into your systems, or draining and reading the messages flowing between your services. What that’s worth depends on what you send through the broker, and it’s usually more than you’d like.

The Erlang distribution port — the RCE. This is the one that makes RabbitMQ different. Port 25672, reachable, plus a weak or default Erlang cookie, means an attacker connects an Erlang node to yours and runs arbitrary code as the rabbitmq user. Not message theft — a shell. epmd on 4369 is the map that leads there, enumerating your nodes and their distribution ports.

So the severity of an exposed broker depends entirely on what’s exposed and how it’s configured. At best it’s message interception; at worst it’s a host compromise that happens to be running a message broker.

What actually gets brokers compromised

In rough order:

1. loopback_users = none plus exposed ports — someone lifted the guest restriction to fix a remote client, and now guest/guest works from anywhere with admin rights.
2. The management UI on 15672, exposed, over plain HTTP — credentials sniffed, or a weak password guessed.
3. A default or weak Erlang cookie with 25672 reachable — the RCE path, especially on brokers built from images that ship predictable cookies.
4. A real credential reused or leaked from an application config, working because the broker is reachable and TLS was never required.

The shortest path from exposed to closed

1. Delete guest and check loopback_users — and never set it to none.
2. Firewall every port — 5672, 15672, and especially 25672 and 4369. Nothing but your nodes should reach the last two.
3. Fix the Erlang cookie — strong, random, chmod 400, different per cluster.
4. Require TLS and bind the management UI to loopback.

Steps 1 and 2 stop the bleeding in minutes.

Verify it worked

What’s reachable? From another host, sweep the ports:

for p in 5672 5671 15672 25672 4369; do
  nc -zv -w5 your.broker $p 2>&1 | tail -1
done

25672 or 4369 answering from outside your node network is the most serious finding. 15672 answering is next.

Does guest work remotely?

curl -su guest:guest http://your.broker:15672/api/whoami -o /dev/null -w '%{http_code}\n'

200 is a full compromise — an admin credential everyone knows, working remotely.

Were you hit? Look for what an attacker leaves. Unexpected users and permissions:

rabbitmqctl list_users
rabbitmqctl list_permissions -p /

Users you didn’t create, or new admin tags, are findings. Check for unexpected connections and consumers draining your queues:

rabbitmqctl list_connections user peer_host
rabbitmqctl list_consumers

And — because the Erlang path is host RCE — check the host itself:

sudo cat /var/lib/rabbitmq/.ssh/authorized_keys 2>/dev/null
sudo crontab -u rabbitmq -l 2>/dev/null
sudo journalctl -u rabbitmq-server | grep -iE 'nodedown|connection.*attempt|handshake' | tail

New Erlang node connections in the log that you didn’t initiate are the signature of a distribution-port attack.

Before you apply this

Match the response to the path. The three exposures need different reactions:

• If only AMQP or the management UI was reachable with a weak credential, treat the messages and broker credentials as compromised: rotate every user password, and assume the contents of every queue were read.
• If 25672 was reachable with a weak or default cookie, assume host compromise. The attacker had code execution as rabbitmq. Fixing the cookie and firewall does not remove anything they left — check for persistence (SSH keys, cron, unexpected processes) and, if you find any, rebuild the host.

In all cases:

1. Firewall the ports first. Don’t restart the broker — a restart clears the connection and consumer lists that show you what’s currently attached.
2. Rotate everything: every broker user password, the Erlang cookie, and any application credential the broker held. If messages carried secrets — tokens, credentials passed between services — rotate those too.
3. Do not pay a ransom if you find one. As with the MongoDB and Elasticsearch waves, the data is usually gone rather than held.

The durable fix is the checklist, and the Erlang cookie plus the distribution-port firewall are the two that separate “someone read our messages” from “someone owned our host”. Those are the ones to verify first.

Related

• Hardening RabbitMQ — the full checklist.
• Protect the Erlang cookie — the difference between message theft and RCE.