4 ms·
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.
by codedokode 4y ago
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 https://github.com/rabbitmq/rabbitmq-server/issues/1661
- im3w1l 4y agoCan't you just block the port in your firewall of choice?
- codedokode 4y agoIn 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.
- datavirtue 4y agoStill on about "accidentally unblocking ports?" Network security is not a "hacky workaround." We don't expose RabbitMQ clusters to the internet. Full stop.
- codedokode 4y agoI 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.
- ikiris 4y agothis 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.
- codedokode 4y agoFor example, I might install RabbitMQ on a dev server. I do not need any clusters there.
- sieabahlpark 4y ago
- 8organicbits 4y agoWhy 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.
- codedokode 4y agoFirewall 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.
- ozim 4y agoI 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.
- datavirtue 4y agoWinner!
- codedokode 4y ago> 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.
- vimwizard 4y agoWhy 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.