BEAM security - best practices to secure a running system?

To be honest… But once the attacker has access to the system they can do anything… I do not need to alter the JVM to read its memory. To sniff network traffic, to get hands on certificates, to well, achieve about everything…

An attacker that came thus far, does not care anymore about the runtime. They care about the tasty stuff. SSH keys, config data (which usually contains passwords for DB or other external services), business data…

While what you say is true, @arnomi is not talking about the system running the VM, instead he is concerned about the VM itself, aka about what you can do when you get access to it without going through the server running the Erlang VM, eg: maybe like guessing the Erlang Cookie or breaking into it from the code(if this is possible!!!)

He is:

Its both. I think I am mostly asking for: What are good arguments against the claim “runnig Beam is not secure”, (which by itself is not a well formulated claim, but one I have heard quite a lot).

And while on the topic, I think its interesting to understand best practices for securing a BEAM based system.

For example, one of the arguments against “you have lost if someone is in your system is: you at least might have monitoring on file level changes and intrusion detection systems. So if you are lucky you might catch this in time.” On the BEAM you cannot easily monitor (if at all) changes applied to the runtime system.

If you remove those debugging capabilities, by for instance not running distributed Erlang and not using run_erl/to_erl, you get into a very similar state as the JVM. You cannot debug, but you also cannot do code injection.

Good point.

Is there anything you can do when running in cluster mode? My guess is the best protection would be to enable SSL for the distribution in which case you would at least need access to a proper certificate for connecting.

Is there anything that can be done from within the VM? For example monitoring code changes and sending notifications if a module gets reloaded?

Yes, I would never expose distributed Erlang to something that could potentially be an attacker without TLS enabled. That would be a very bad idea.

Yes there are ways to monitor, but if an attacker gets access to the node, they can disable the monitors.

Distribution over vpn is another alternative to tls (which I find simpler since no certificate management), wireguard will probably be integrated into the linux kernel “soon” (maybe in 5.0?). There’s also tinc, but it’s slower. I can publish a demo repo with my setup for both, if there is any interest. And if your hosting provider also provides a private network between vms as a service, then it’s even easier.

When I don’t need the distribution, I add

config :kernel, inet_dist_use_interface: {127, 0, 0, 1}

to the config to avoid epmd binding to all network interfaces. I also close all ports by default, and only leave the ones necessary for the application usage open.

Do you have a good blog/video guide on how to tighten / selectively disable security-sensitive BEAM features? I for one I am not at all interested in Distributed Erlang because I am mostly doing small-to-medium apps and I’d like to have the distributed stack fully disabled until it’s very clear that I need it.

And yes, removing debugging (even though that’s an awful idea).

No, not really. If you don’t run distribution and turn off the shell, then the only other entry points into the system are what you create in your application.