RabbitMQ Security Best Practices

A poorly secured RabbitMQ broker is a serious risk. An attacker who gains access can read all messages in your queues, inject malicious messages into your system, or delete queues and crash dependent services. This topic covers every major security layer — from network exposure to user access and encrypted transport.

1. Remove or Secure the Default Guest User

The guest user with password guest is the single most common RabbitMQ security mistake. Delete it immediately in any environment reachable from a network:

rabbitmqctl delete_user guest

If you cannot delete it (for example, it is needed for integration tests), at minimum change its password and restrict it to localhost only. The default configuration already restricts guest to localhost, but a misconfigured broker may not enforce this.

2. Create Dedicated Users Per Service

Each microservice or application that connects to RabbitMQ should have its own user with the minimum permissions needed — no more.

# Order service user — can only publish to orders exchange and read from orders queue
rabbitmqctl add_user order-service LongRandomPassword1!
rabbitmqctl set_user_tags order-service  # no management tags
rabbitmqctl set_permissions -p /production order-service \
  "^orders$" \
  "^orders$" \
  "^orders$"

# Analytics service user — read-only from analytics queue
rabbitmqctl add_user analytics-service LongRandomPassword2!
rabbitmqctl set_permissions -p /production analytics-service \
  "" \
  "" \
  "^analytics.*"

If one service is compromised, the attacker's access is limited only to that service's queues and exchanges.

3. Use Strong Passwords

RabbitMQ passwords are hashed using SHA-256 (or stronger) by default. Still, use long random passwords — at least 20 characters with mixed case, numbers, and symbols. Store them in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Kubernetes Secrets) rather than in environment variables in plain text wherever possible.

4. Enable TLS for All Connections

All data transmitted over AMQP is unencrypted by default. Credentials and message bodies travel in plaintext. Enable TLS (port 5671) for all client connections in production.

# rabbitmq.conf
listeners.ssl.default = 5671
ssl_options.cacertfile = /etc/rabbitmq/certs/ca.pem
ssl_options.certfile   = /etc/rabbitmq/certs/server.pem
ssl_options.keyfile    = /etc/rabbitmq/certs/server-key.pem
ssl_options.verify     = verify_peer
ssl_options.fail_if_no_peer_cert = true

verify_peer requires clients to present a valid certificate signed by your CA. fail_if_no_peer_cert rejects clients that do not present a certificate at all. This enables mutual TLS (mTLS) — both sides authenticate each other.

5. Restrict Network Access

Never expose RabbitMQ ports to the public internet. Use firewall rules to allow only trusted IP ranges:

Port 5672  – AMQP     – Allow only from application servers
Port 5671  – AMQP TLS – Allow only from application servers
Port 15672 – Mgmt UI  – Allow only from internal admin IPs or VPN
Port 25672 – Cluster  – Allow only between cluster nodes (internal network only)
Port 4369  – Erlang   – Allow only between cluster nodes

# UFW example (Linux)
sudo ufw allow from 10.0.0.0/8 to any port 5671
sudo ufw allow from 192.168.1.0/24 to any port 15672
sudo ufw deny 5672   # block unencrypted AMQP from everywhere

6. Use Virtual Hosts for Isolation

Separate environments (production, staging, dev) and teams into different virtual hosts. A user granted access to /staging cannot read messages from /production even if their credentials are compromised.

rabbitmqctl add_vhost /production
rabbitmqctl add_vhost /staging
rabbitmqctl set_permissions -p /production prod-user ".*" ".*" ".*"
rabbitmqctl set_permissions -p /staging   dev-user  ".*" ".*" ".*"

7. Secure the Management UI

• Enable HTTPS for the Management UI by terminating TLS at a reverse proxy (Nginx, HAProxy) in front of port 15672.
• Restrict management UI access to admin users only — do not give the management tag to service accounts.
• Consider disabling the Management UI on production nodes and using CLI tools or the HTTP API over HTTPS instead.

8. Monitor for Authentication Failures

Watch the RabbitMQ logs for repeated authentication failure messages:

[warning] PLAIN login refused: user 'admin' - invalid credentials

Multiple failures in rapid succession indicate a brute-force attack. Alert on this log pattern and block the source IP at the firewall.

9. Use External Authentication

For organisations with existing identity infrastructure, use LDAP or OAuth 2.0 authentication instead of RabbitMQ's built-in user database:

# LDAP auth plugin
rabbitmq-plugins enable rabbitmq_auth_backend_ldap

# rabbitmq.conf
auth_backends.1 = rabbit_auth_backend_ldap
auth_backends.2 = rabbit_auth_backend_internal

ldap.servers.1 = ldap.example.com
ldap.port      = 636
ldap.use_ssl   = true
ldap.user_dn_pattern = cn=${username},ou=users,dc=example,dc=com

10. Limit Resource Usage

Set queue and message size limits to prevent a rogue producer from filling your disk and crashing the broker:

# Policy to cap all queues at 100,000 messages
rabbitmqctl set_policy MaxLength ".*" \
  '{"max-length":100000,"overflow":"reject-publish"}' \
  --apply-to queues

# Reject new publishes when the queue is full (instead of dropping old messages)
overflow = reject-publish

reject-publish returns an error to the producer when the queue is full, allowing the producer to handle the backpressure rather than silently losing messages.

11. Keep RabbitMQ and Erlang Updated

RabbitMQ releases security patches regularly. Subscribe to the RabbitMQ release announcements and apply security updates within your maintenance window. Always test upgrades in staging before applying to production.

Security Checklist

• Delete or change the guest user password
• Create one user per service with minimum permissions
• Enable TLS on port 5671 with certificate verification
• Block public internet access to all RabbitMQ ports
• Use virtual hosts to isolate environments and teams
• Enable HTTPS for the Management UI
• Alert on authentication failure log messages
• Set max-length policies to prevent runaway queue growth
• Keep RabbitMQ and Erlang updated to the latest stable versions

Summary

RabbitMQ security starts with deleting the guest user and creating minimal-permission service accounts. Enable TLS on port 5671 for encrypted transport and mutual authentication. Restrict all RabbitMQ ports using firewall rules so only trusted networks can connect. Separate environments using virtual hosts. Monitor authentication failures in logs and alert immediately on unusual patterns. Apply queue length policies to prevent resource exhaustion. Keep the broker patched and current. Layering these controls together protects your messaging infrastructure from both external attackers and internal mistakes.