Comment by codedokode | Hacker News Reader

Comment by codedokode | Hacker News Reader

Here is what I dislike about RabbitMQ: by default it opens several ports on external interfaces and doesn't provide an easy way to bind them to localhost only. To be specific, those are epmd port 4369, and RabbitMQ's ports 5672, 15672, and 25672. With help of Google I managed to move three of those ports to localhost, however the cluster communications port 25672 cannot be bound to localhost only. I found an issue on Github and developers' point is that it doesn't make sense to build a cluster from a single node, so you must have this port exposed to whole Internet so that any random stranger can connect to your RabbitMQ instance [1].

So it seems that RabbitMQ wants to advertise how scalable it is by enabling clustering by default and accepting connections from anyone even though it is not secure. It is targeted at large corporations with giant clusters and doesn't care about developers who just need a single instance. Despite my guess that most developers actually do not have a volume of messages that would justify setting up a cluster.

And as RabbitMQ is written in an exotic language (Erlang) I cannot even read the code.

This is the problem not only with RabbitMQ, Elasticsearch also has clustering settings enabled by default, so when you try to run two independent instances, they connect to each other and start exchanging data and creating problems without you expecting it. So annoying and so difficult to disable. In earlier versions, as I remember, they would also try to scan local network and connect to any node they could find.

[1] https://github.com/rabbitmq/rabbitmq-server/issues/1661

Why not use a firewall? That appears to be the suggestion on the docs linked to by that issue.

> 25672: used for inter-node and CLI tools communication [...] Unless external connections on these ports are really necessary (e.g. the cluster uses federation or CLI tools are used on machines outside the subnet), these ports should not be publicly exposed. See networking guide for details.

Individually binding each service to localhost to prevent remote access seems tedious and error prone. What happens if an update exposes a new port? I like to bind to localhost too, but only as a defense in depth measure.

Firewall is unreliable as well. What if someone temporarily disables it and exposes vulnerable services? What if RabbitMQ opens a new port that you forgot to block in a firewall? Firewall is a hacky workaround, not a proper solution.

I wonder what configuration you use - because by default firewalls usually block all incoming traffic unless you make rule to allow traffic or configure specifically to allow all incoming traffic - but with that setting you could just uninstall firewall or turn it off.

I also have not seen RabbitMQ opening anything on my firewalls on installation or during the operation. There are some annoying applications that add firewall rules but RabbitMQ was not one.

If someone is solving issues by disabling whole firewall, his access should be revoked immediately from anything related to infra.

Firewall is a proper solution, learn how to use it properly instead of coming up with excuses.

Winner!

> because by default firewalls usually block all incoming traffic

In Debian by default all connections are allowed. And it makes sense: if you open a port, you probably want to be able to connect to it, otherwise why would you open it?

It doesn't make sense if you open a port (to accept connections) and then block this port with a firewall.

Of course this applies to cases when you have a single node, I understand that you might need firewall if you have several nodes.

why even run a firewall at that point, clearly you put the box on the internet, you want to connect to it.

/s

Are you suggesting to bind to localhost in addition to a firewall, or are you anti-firewall?

The firewall solution to a new/unexpected open port is a default deny rule. That's a commonly used best practice. There's nothing to forget.

> The firewall solution to a new/unexpected open port is a default deny rule.

In case with a single node, it doesn't make sense. If you open a port, you probably want to be able to connect to it, otherwise why would you open it? And if you don't want anyone to connect, then don't open a port. There is no need for a firewall in case with a single node, unless you want custom rules like "only host A can connect to host B".

There should not be "unexpected" open ports. Software should not open ports on external interfaces unless permitted by administrator.

RabbitMQ should just have a switch to disable all unnecessary clustering features, but for some reason they don't want to implement it.

Why would you ever make a rabbitmq node on a VM/server connectable from the internet? You would explicitly have to set up this networking for it to be a problem. In Azure it is for sure a non-issue, would need an explicit security rule(s) set up on subnet and NIC, probably the same thing in AWS.

Can't you just block the port in your firewall of choice?

In theory I could learn Erlang and patch the source code as well, however, I would prefer a proper solution, not a hacky workaround.

It doesn't make sense if you first open the port and then block it with a firewall.

Also, this is a bad idea because firewall config is kept separately from RabbitMQ config, it is easy to forget that you have a RabbitMQ instance exposed to the whole Internet and accidentally unblock the port.

Still on about "accidentally unblocking ports?" Network security is not a "hacky workaround." We don't expose RabbitMQ clusters to the internet. Full stop.

I don't need a cluster, I need a single instance, but RabbitMQ doesn't allow to disable clustering. That's the problem and instead of proper solution people suggest blocking it with a firewall.

this is like setting up a one box kubernetes... like... why?

if you arent a distributed system, why do you even need a multi node messaging system?

there are way better solutions for single node.

For example, I might install RabbitMQ on a dev server. I do not need any clusters there.

Reply on news.ycombinator.com