[erlang-questions] Supporting a port number in spawn/4

[Oleg Tarasenko]

Hey Amit,

Actually I am maintaining a small project which is dedicated to the topic
above:
https://github.com/oltarasenko/epmdless

See also the article regarding running it in docker:
https://www.erlang-solutions.com/blog/running-distributed-erlang-elixir-applications-on-docker.html

Hopefully it could be interesting for you as well,
Oleg

On Tue, Oct 22, 2019 at 2:11 PM Amit K <klg.amit@REDACTED> wrote:

> Hi Lukas,
>
> It's a great question!
> And actually, choosing between disabling epmd completely and protecting
> communication via TLS, will have somewhat different security benefits.
>
> 1. *Protecting epmd communication via TLS* - This only protects us from
> an attacker that wants to perform epmd impersonation, because TLS here is
> authenticating only the server node to the client node.
> Then perhaps if we have two Erlang nodes on the same machine, let's say
> Node1 and Node2, an attacker can make the client node connect to Node2
> instead of Node1 by returning the wrong port by a simple manipulation of
> the plain epmd traffic, and in that way expose sensitive data to the client
> node, which exists in Node2 but not in Node1. Maybe it's a bit far fetched
> but from my limited knowledge it looks like a possible attack scenario.
> Another thing that the encryption is good for here is probably in
> preventing a covert channel.
>
> 2. *Disabling epmd completely* - This approach eliminates a lot more
> attack vectors actually.
> Just as one simple example, assume for a moment that we have a buffer
> overflow bug in epmd, then using this approach you will not be affected by
> it. By completely disabling an unnecessary service (if it's really
> unnecessary of course, in some situations I assume epmd is very much
> required!) the attack surface reduces much more so it's difficult to list
> in detail everything we'll be protecting against.
> Nevertheless, we all know that it's a good security practice to disable
> unrequired services whenever you can :) and especially ones that listen to
> requests from the outside world.
>
> Regards,
> Amit
>
> On Tue, Oct 22, 2019 at 2:49 PM Lukas Larsson <lukas@REDACTED> wrote:
>
>>
>>
>> On Tue, Oct 22, 2019 at 1:02 PM Amit K <klg.amit@REDACTED> wrote:
>>
>>> Hi Greg,
>>>
>>> Thank you for your feedback!
>>> In general, I think it makes sense to have a solution for this that's
>>> built in to OTP and not have to use an external proxy method.
>>> Going more along the route of what you suggest, a sensible alternative
>>> would be for epmd.exe to be able to accept TLS settings like the Erlang
>>> node (erl.exe) does, and then communication with it will also be protected
>>> by TLS. a quick look at the code makes me  guess that the reason that was
>>> not done originally is that epmd is a small & separate utility written in C
>>> and therefore it doesn't have the "crypto" framework like the other OTP
>>> parts do.
>>>
>>
>> I'm kind of curious about what type of attacks you are trying to protect
>> against? You mention "man in the middle", however, I cannot see how someone
>> could exploit that to do anything but disrupt the distributed erlang
>> connections. Though that could only be a lack of imagination on my part,
>> and when it comes to security we must be extra careful.
>>
>> Lukas
>>
>>
>>>
>>> Regards,
>>> Amit
>>>
>>>
>>>
>>> On Tue, Oct 22, 2019 at 10:54 AM Grzegorz Junka <list1@REDACTED>
>>> wrote:
>>>
>>>>
>>>> On 21/10/2019 21:25, Amit K wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I am very new to Erlang, am considering to use it in a project and I
>>>> have some security concerns.
>>>> I can see it's quite easy to configure TLS for the node-to-node
>>>> communication, but making the name-to-port resolution service (epmd) secure
>>>> seem a bit too complex to me, such as the one suggested here:
>>>> https://www.erlang-solutions.com/blog/erlang-and-elixir-distribution-without-epmd.html
>>>>
>>>> So I was thinking, seeing that there are already options to:
>>>> 1. Start a distributed node without epmd (-start_epmd false)
>>>> 2. Limit a node's port numbers to a specific range (via inet_dist_listen_min
>>>> & inet_dist_listen_max).
>>>>
>>>> Wouldn't it be nice if we could also specify a predefined port to
>>>> spawn/4, to complete that picture? That is allow spawn to look like:
>>>> spawn("Name@REDACTED:Port", Mod, Func, ArgList).
>>>> Then when spawn sees that a port was provided, it can completely skip
>>>> the "epmd resolution" part and proceed with connecting to the target node
>>>> via the provided port.
>>>> Note: I realize that the "Name" becomes slightly redundant when the
>>>> Port is explicit. However this can still be useful - it would be good if
>>>> the implementation will also verify that the port belongs to the provided
>>>> name at the receiving side, so that a node will not accidentally process a
>>>> message that wasn't meant for it.
>>>>
>>>> Again, I'm a complete newbie to Erlang in general, so I may be missing
>>>> something essential here :) But I would love to know what that is, if
>>>> that's the case, or hear your thoughts in general otherwise :)
>>>>
>>>>
>>>> Hi Amit,
>>>>
>>>> There is also another option, run any communication between nodes via IP
>>>> tunnels <https://en.wikipedia.org/wiki/IP_tunnel>. There are some tools
>>>> to automate that
>>>> <https://www.virtualthoughts.co.uk/2019/07/15/application-security-with-mutual-tls-mtls-via-istio/>.
>>>> They are mostly used between docker containers or pods but it's just a
>>>> detail, equally well they can support a microarchitecture build on Erlang
>>>> nodes.
>>>>
>>>> Regards
>>>> Greg
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191022/bd5647e5/attachment.htm>