3 ms·
You're not supposed to open the Erlang RPC port to the open Internet, and there is a modicum of security barrier with its cookie if you're so inept as to run Er
by sph 3y ago
You're not supposed to open the Erlang RPC port to the open Internet, and there is a modicum of security barrier with its cookie if you're so inept as to run Erlang on a non-firewalled server on the open Internet.
You don't need security people for basic sysadmin know how.
- stephenr 3y agoYou do apparently need security or basic sysadmin knowhow to understand that not all security threats originate from "the open Internet"
- sph 3y agoSo? How is this specifically relevant to the topic at hand? If you have someone malicious in your internal network that can connect to your Erlang nodes, you have bigger issues that them connecting to your Erlang nodes. I don't see the point of your original comment. Having an out-of-the-box RPC mechanism means you gotta secure it as you secure any other internal service. That's sysadmin 101.
- stephenr 3y ago> I don't see the point of your original comment. Having an out-of-the-box RPC mechanism means you gotta secure it as you secure any other internal service. That's sysadmin 101 Most RPC systems can't inject code into the running system dynamically. That's the point of my original post.
- jandrese 3y agoYeah, but what happens when your local web browser is tricked into opening a socket to the local Erlang instance by a malicious web page? That's the kind of thing that keeps security professionals up all night.
- marksomnian 3y agoIt’s a binary protocol though, which means that this specific scenario isn’t an issue as far as I’m aware (the only ways of making arbitrary JS-controlled network requests are XHR/fetch(), which is only HTTP, and WebSockets, which have a handshake mechanism to ensure that the other side is really expecting a WS connection, which Erlang won’t be).