Secure the RabbitMQ management UI

The fix/etc/rabbitmq/rabbitmq.conf

# Bind the management UI to loopback; reach it via SSH tunnel
management.tcp.ip = 127.0.0.1
management.tcp.port = 15672

# If it must be on a network, use TLS and a private interface
# management.ssl.port = 15671
# management.ssl.ip = 10.0.1.5
# management.ssl.cacertfile = /etc/rabbitmq/tls/ca.pem
# management.ssl.certfile = /etc/rabbitmq/tls/server.pem
# management.ssl.keyfile = /etc/rabbitmq/tls/server.key

sudo systemctl restart rabbitmq-server

Why it matters

The management plugin — enabled by default — serves a web UI and a full HTTP API on port 15672. It is not a status page. Through it you can create and delete users, change permissions, read queue contents, purge queues, publish arbitrary messages, and change broker configuration. It is the entire administrative surface of the broker, over HTTP.

Two things make it a frequent finding:

• The port is well known, so scanners look for it, and a /api/overview request identifies it instantly.
• It’s HTTP by default, so credentials — including the admin’s — cross the network in cleartext unless you configure TLS.

Combined with a weak or default account (see replace the guest user), an exposed management UI is broker takeover through a browser.

Reach it over a tunnel, not the internet

The best posture for most deployments: bind it to loopback and reach it through an SSH tunnel.

# from your workstation
ssh -L 15672:localhost:15672 admin@broker
# then browse http://localhost:15672

That reuses SSH’s authentication, needs no exposed port, no certificate, and no additional firewall rule. The management UI is an administrative tool used occasionally by a few people — it does not need to be on the network at all.

If it must be reachable, use TLS and restrict it

If a tunnel genuinely doesn’t fit — a shared ops team, an existing reverse proxy — then put it on a separate TLS port (15671), bind it to a private interface, and firewall it to admin addresses. Never leave it on plaintext 15672 on a routable interface.

Behind a reverse proxy, terminate TLS there and pass through to loopback 15672, and make the proxy require authentication of its own if you can. The management API supports it, but defence in depth on an admin surface is cheap.

The HTTP API is the same surface

Don’t over-focus on the web UI and forget the API underneath it. Everything the UI does, the API does — /api/definitions exports the entire broker configuration including user password hashes, and /api/queues/.../get reads messages. A scoped monitoring user for dashboards is fine; the admin API is not something to expose.

If you only need metrics, the Prometheus endpoint (port 15692, via the rabbitmq_prometheus plugin) exposes metrics without the administrative surface — a better thing to point monitoring at than the management API.

Verify it worked

Check where the management UI is bound:

rabbitmq-diagnostics listeners | grep -iE 'http|management'

Want 127.0.0.1 or a private interface — not 0.0.0.0.

Test from another host — it should not be reachable:

curl -s --connect-timeout 5 http://your.broker:15672/api/overview -o /dev/null -w '%{http_code}\n'
curl -sk --connect-timeout 5 https://your.broker:15671/api/overview -o /dev/null -w '%{http_code}\n'

A timeout is the goal. A 401 means it’s reachable but asking for auth — better than 200, still exposed. Confirm it’s not plaintext if it is reachable:

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

Any success over plain http means admin credentials cross the wire in cleartext.

Check the definitions endpoint specifically — it’s the worst thing to expose:

curl -su admin:PASS http://localhost:15672/api/definitions | grep -o 'password_hash' | head -1

That confirms the endpoint returns password hashes — which is why it must never be reachable from an untrusted network.

Before you apply this

Binding the management UI to loopback breaks remote access to it — which is the point, but it means anyone who was using it over the network now can’t, and they’ll notice immediately. Set up and document the SSH-tunnel workflow before you flip it, so “how do I get to the dashboard now” has an answer ready.

Monitoring that scrapes the management API breaks too. Dashboards and alerting that poll /api/queues or /api/overview stop when you restrict the port. Find them first:

sudo grep -c '/api/' /var/log/rabbitmq/*.log 2>/dev/null
rabbitmqctl list_connections user peer_host | grep -i mgmt

Point them at the Prometheus endpoint instead, or give them a loopback path and a monitoring-tagged user rather than reopening the admin port.

Don’t disable the management plugin to secure it unless you truly don’t use it — some tooling and the rabbitmqadmin CLI depend on it. Binding it to loopback keeps it usable over a tunnel while removing the exposure, which is almost always the better trade than turning it off entirely.

Related

• Replace the guest user — the account that would log in here.
• Restrict network listeners — the port this binds.
• Scope vhosts and permissions — the tags that gate management access.