In order for Sandfly to operate, it must connect to your Linux systems over SSH. To enable this, Sandfly will need to access SSH keys that allow it to login with sudo privileges on each host.

To protect SSH keys against compromise, Sandfly uses highly secure elliptic curve cryptography. Keys saved into Sandfly are all encrypted with a public key in such a way that the server cannot decrypt them again even if the entire database were to be compromised. Only the scanning nodes of Sandfly have the ability to decrypt encrypted credentials, and these credentials are only sent to the scanning nodes when the server needs them to do work.

A result of the this architecture is that we have two modes of operation for Sandfly you may wish to consider for your deployment: Standard Security and Maximum Security

Standard Security Mode Installation

A standard security installation runs the Sandfly server and node Docker containers on the same host. This allows a system to be stood up quickly with little overhead for testing and small deployments. The downside of this is that having the server and node containers on the same Virtual Machine (VM) means that the cryptographic keys to decrypt SSH keys are on the underlying host operating system. In the unlikely event of a server compromise and container escape, an attacker could in theory decrypt SSH keys as the node container is also on the same host.

The other disadvantage is that with the server and node on the same system, you may have a harder time deploying Sandfly on isolated segments where heavy firewalls are in place. The node must see the protected hosts and because it is on the same system as the server, this means that the server must also be open on the isolated segment to allow admins to connect to the user interface.

Standard security mode is only recommended for small deployments where you cannot run multiple VMs due to resource constraints.

Maximum Security Mode Installation

The maximum security installation of Sandfly runs the server and nodes on separate systems. The keys to decrypt SSH credentials are only on the node and the keys to encrypt are on the server. The server can only encrypt credentials in this mode and can not access any kind of key material to decrypt them even if the container and host operating system were both completely compromised.

An attacker would need to compromise the server and node systems simultaneously to get both pieces to compromise your SSH credentials stored in the system. As the scanning nodes are designed to only talk outbound and do not require any inbound traffic to work, they are able to be hardened with very strict packet filters and makes compromising to get decryption keys very difficult.

Because the server and node are separate VMs, this mode also works better in heavily isolated networks. You can run nodes inside the segments you want protected and they will talk outbound to the server. You can allow a more open filter for admins to work with the server, but completely deny any inbound traffic to the scanning nodes.

This maximum security is recommended for all users if you have the hardware resources to do it.