Restrict RabbitMQ network listeners

The fix/etc/rabbitmq/rabbitmq.conf

# AMQP: bind to the private interface only
listeners.tcp.local = 10.0.1.5:5672

# Management UI: loopback only (reach it via SSH tunnel)
management.tcp.ip = 127.0.0.1

# Erlang distribution: pin the port and bind it to the private interface
distribution.listener.interface = 10.0.1.5

Then firewall everything. The listener config narrows the interface; the firewall narrows the source, and RabbitMQ needs both.

Directives on this page

listeners.tcp.default

The plaintext AMQP listener. Accepts an address:port pair, which is how you bind it to a private interface rather than every interface.

• accepts<port> | <addr>:<port>
• defaultlisteners.tcp.default = 5672
• valid inrabbitmq.conf

rabbitmq.com docs/configure

5672

AMQP 0-9-1 and AMQP 1.0 without TLS.

rabbitmq.com docs/networking

25672

Erlang distribution — inter-node and CLI tool traffic. Reachable from outside plus a weak Erlang cookie is remote code execution as the rabbitmq user, which makes this the most dangerous port on the box.

rabbitmq.com docs/networking

4369

epmd, the peer discovery service used by nodes and CLI tools. Exposing it advertises which nodes exist and on which ports.

rabbitmq.com docs/networking

15692

Prometheus metrics. Useful precisely because it lets monitoring scrape the node without opening the management admin surface.

rabbitmq.com docs/networking

If you see this

Failed to start TCP listener [::]:5672, error: eaddrinuse

Something already holds the port — usually a previous broker that did not stop cleanly. Note the address: [::] is the wildcard, so a listener you meant to bind to one interface is being started on all of them. — rabbitmq/deps/rabbit/src/rabbit_networking.erl

Why the clustering ports are the real danger

Everyone thinks about port 5672. The ports that actually turn an exposure into a host compromise are the two nobody publishes a client for:

Port	What it is	Exposure
25672	Erlang distribution	Reachable + weak cookie = code execution
4369	epmd (Erlang port mapper)	Enumerates nodes and their dist ports

RabbitMQ runs on the Erlang VM, and Erlang nodes cluster by connecting to each other over the distribution protocol on 25672. That protocol, by design, lets one node run code on another — it’s how clustering works. The only thing gating it is the Erlang cookie, a shared secret. So 25672 reachable from the internet, plus a weak or default cookie, is remote code execution as the rabbitmq user — not a message-queue problem, a shell.

epmd on 4369 is the directory: query it and it tells you which Erlang nodes are running and what dist ports they’re on. It’s reconnaissance that leads straight to 25672.

Neither should ever be reachable from outside your cluster’s own network. On a single-node broker, they don’t need to be reachable from anywhere but loopback.

Disable plaintext AMQP if you use TLS

If you’ve turned on TLS, close the plaintext port entirely rather than leaving it open beside the encrypted one:

listeners.tcp = none          # no plaintext AMQP at all
listeners.ssl.default = 5671  # TLS only

Leaving 5672 open next to 5671 means a client can still connect in the clear — the same “offering TLS isn’t requiring it” trap as every other service here.

The management port is not for the internet

15672 serves the management UI and HTTP API. Bind it to loopback and reach it over an SSH tunnel; do not publish it. It’s a full admin surface and it’s a frequent finding on exposed brokers.

Verify it worked

See exactly what the node bound — trust this over the config file:

rabbitmq-diagnostics listeners

Interface: 10.0.1.5, port: 5672,  protocol: amqp
Interface: 127.0.0.1, port: 15672, protocol: http
Interface: 10.0.1.5, port: 25672, protocol: clustering

Anything on 0.0.0.0 — especially clustering or http — is the finding.

Then test from another host. These must all fail from outside your node network:

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

The two that matter most are 25672 and 4369 — a response on either from the internet is a serious finding. Query epmd specifically to see what it leaks:

epmd -d -names -address your.broker 2>/dev/null || nc -w5 your.broker 4369

If that returns node names and port numbers, epmd is exposed.

Confirm plaintext AMQP is closed if you meant to close it:

rabbitmq-diagnostics listeners | grep -E 'amqp\b' | grep -v ssl

No plaintext amqp line means listeners.tcp = none took effect.

Before you apply this

Narrowing listeners needs a restart and disconnects clients on the interfaces you drop. Know who connects and from where first:

rabbitmqctl list_connections peer_host peer_port user | sort | uniq -c

Every peer host there must be able to reach the interface you keep.

The clustering ports have a specific trap: don’t firewall a real cluster into pieces. If this broker is part of a multi-node cluster, 25672 and 4369 must remain reachable between the nodes — firewalling them off from each other partitions the cluster, which for RabbitMQ can mean split-brain and lost messages. The rule is: those ports reachable only between cluster nodes, on the private network — open to the nodes, closed to everything else. On a single node, loopback-only.

# pin the dist port so you can firewall it precisely
# rabbitmq-env.conf:  RABBITMQ_DIST_PORT=25672

Pinning the distribution port matters because it’s otherwise chosen dynamically, and you can’t write a firewall rule for a port that moves.

Disabling plaintext AMQP breaks every non-TLS client at once. Confirm all clients speak TLS and trust the CA before setting listeners.tcp = none — the same staged rollout as TLS. A client stuck on amqp:// gets a connection refused, not a helpful error.

Related

• Protect the Erlang cookie — why 25672 is so dangerous.
• Enable TLS — before you disable plaintext.
• Secure the management UI — the 15672 surface.