Product FAQs

Sandfly is an agentless security platform purpose-built for Linux. 

Sandfly is best understood as a compromise detection or intrusion tactics hunter. This is a shift in how many Endpoint Detection and Response (EDR) systems work as Sandfly specifically hunts for intruder activity the same way a very experienced Linux forensic investigator would. The difference is that Sandfly has a far deeper knowledge of attack tactics than a human investigator and we operate instantly and at a very large scale with minimal performance impacts.

Further, Sandfly is 100% automated to check your systems 24 hours a day to give you instant alerts to trouble. With Sandfly running you have a constant presence on your Linux fleet hunting for intruders and without the risk and hassle of installing endpoint agents. 

If you are an incident responder, Sandfly can be used in a manual mode to instantly assess systems for compromise and pull critical forensic data to speed up your investigation and clean-up. This allows your organization to get back in operation as quickly as possible, saving valuable time and limiting damage.

If you are a Linux forensics novice, Sandfly does the hunting for you and tells you in plain English what the problem is if we do find something that is of concern.

Sandfly was designed to monitor large Linux networks for signs of intrusion and requires a dedicated VM to operate. It can scan most Linux devices as long as they are running SSH which makes it suitable for a broad range of commercial applications.

For personal use, Sandfly can be used to protect small home networks from intrusion but isn't intended to be installed on and protect a single device like a traditional virus scanning product would.

Agentless means that Sandfly does not require installing any agents on your endpoints. As a result, unlike most endpoint-focused solutions available today, it can be rapidly deployed with virtually no chance of disruption or impacts on production systems. We work on legacy systems over a decade old, up to modern cloud based deployments without any modifications to the endpoint. We even work on many embedded and customized Linux applications without any risk to the endpoint stability or performance.

We secure the widest range of Linux systems of any product on the market and protect virtually all distributions of Linux. 

This spans, for example, systems that are 10+ years old up to modern distributions at cloud providers. Sandfly works with Linux versions running Intel, AMD, Arm, MIPS and IBM Power CPUs without any special modifications. We also support embedded systems with MIPS or ARM processors such as Raspberry Pi. Basically, because of its agentless architecture, Sandfly only requires that your Linux hosts be running SSH. 

Sandfly has been tested against the following Linux distributions, but will work on many more:

• CentOS
• RedHat
• Ubuntu
• Suse
• Oracle
• Alma
• Rocky
• Fedora
• Debian
• Arch
• Amazon Linux Images
• Digital Ocean Linux Images
• Microsoft Azure Images
• Raspberry Pi and other embedded systems
• Customized Distributions

If you have a system that Sandfly cannot protect, you will simply get an error message in the management console when you try to add it. There is no harm caused to remote systems in trying and you may be surprised what we do support!

Because we are agentless, we are not tied to the Linux kernel in any way so we work across all of them - including systems over a decade old. This means customers can patch, upgrade or modify their kernel images to their liking and not have to worry about breaking Sandfly, or worry about Sandfly breaking their systems.

As of today, we can work on Linux kernels version 3.2 and higher. This means in practice we can support distributions up to a decade+ old like Red Hat 7 or Centos 7, plus all modern kernels whether in the cloud, on-prem, or even embedded devices with custom builds.

Our goal is to have total visibility across all Linux systems. Gaps in coverage are a security risk. Sandfly covers the widest range of systems of any product.

Yes - Sandfly is compatible and able to run in both private or public Cloud environments. 

Sandfly was developed largely on cloud infrastructure. It works immediately at places like Amazon AWS, Azure, Google Cloud, Linode, Digital Ocean, hybrid cloud, etc. 

More specifically, Sandfly is platform agnostic, not latency sensitive, and doesn’t care where the management server/nodes and your Linux hosts are located. As long as the systems you need to secure allow SSH access then Sandfly can protect them immediately. Whether it’s in the cloud, your own network, or any other configuration, Sandfly will work.

Basically, as many as you have resources to protect. The server/node architecture of Sandfly can be distributed using named queues and jump hosts to scale as needed. Each node for instance can protect many thousands of hosts with minimal hardware resources, and new nodes can be added to scale upwards.

Servers are limited only by the CPU/RAM you wish to dedicate to load scaling. Multiple servers can be used to distribute larger deployments. You can also choose how much and where to store forensic data according to your requirements. For context, we have customers using Sandfly to protect tens of thousands of Linux hosts.

Yes. Sandfly is designed to run across multiple distributed and secured network segments easily. 

Sandfly uses a server/node architecture. The nodes can each have a named queue to service where they reside and traffic is routed automatically to them as needed. For instance, you can have nodes inside AWS, Azure, and on-prem. They can each operate inside firewall perimeters and pass back results to the server without issue. 

We also support SSH jump hosts so you can have Sandfly nodes outside controlled zones and use them to access these areas like other operators. You can even chain jump hosts together to move inside tightly controlled perimeters if needed through multiple hops.

A basic install requires one or more systems capable of running Docker or Podman (Sandfly is Dockerized) with these minimum requirements:

• A server with a minimum 8GB RAM running Linux for smaller deployments and scaling up from there. This server runs the REST API and database.
• A scanning node with a minimum 2GB of RAM running Linux. A node runs multiple containers for performance and redundancy so you can cover thousands of hosts very easily.

We also offer a simple, single host install where both server and node run on the same system. However, for higher security and production performance, we recommend you run each on their own VM. 

To keep install easy and fast, we offer automated installation scripts. They take only a few minutes of your time to set up and run. 

Once installed, you configure the platform by adding the hosts (and their access information) you want to protect, configuring any automated scans you’d like to run, connecting with any external platforms like Splunk - and that’s it. You don’t have to touch any of the secured endpoints. Sandfly will work to start securing them immediately.

Full instructions are available here: 

Sandfly Installation Documentation

Absolutely. Sandfly is unique in the industry because incident responders can use Sandfly to instantly scan and detect compromises even if no prior security monitoring is in place or even if other EDR products are operating but have not detected anything (yes, we've seen this). 

For instance, you can point Sandfly at a cluster of Linux systems and get immediate results back about what they are, and their security status and start handling a situation - without first having to deploy software onto potentially compromised systems. 

Further, once an incident is uncovered, Sandfly has hundreds of modules to help incident response teams investigate the affected systems and pull back almost any kind of critical forensic data from your Linux fleet - agentlessly. This is a unique and powerful feature during a real-world, fast moving incident when minutes matter.

Some examples of things we can help with during an incident:

• Flag all new binaries created over a certain time window (e.g. past four hours).
• Pull all users and their SSH keys.
• Parse SSH keys and use that data to instantly search other hosts for the same key in use.
• Grab hashes of running processes and search across all systems for identical processes either running, or have been seen running in the past.
• Find any file or directory name, cryptographic hash or creator across all hosts instantly.
• Flag suspicious hidden or encrypted binaries anywhere on a file system.
• Grab all processes with network connections and the addresses they are connected to or listening on.
• Do all the above on virtually any version of Linux whether legacy, modern or even embedded systems.

Yes. We have built in connectors that can send data directly to Splunk and Elasticsearch. We also have the ability to send structured syslog directly to other platforms such as Graylog, Q-Radar or any other system capable of ingesting syslog data.

In addition to this, we have a full REST API you can query to pull events as you see fit.

Sandfly offers a free Splunk connector available in the Splunkbase:

Splunk Sandfly Connector

No. Sandfly is completely self-contained. It sends no data back to us and does not ship potentially confidential data from your systems off-site for analysis. Even if an attacker were to compromise our own (Sandfly) systems, it would never reveal any customer operational data. We simply do not collect and store any information to leak. This is intentional.

Sandfly is designed to work on networks that are on the Internet, those heavily segmented or those that are air-gapped. Sandfly easily works in isolation without any need to communicate externally to anyone.

Sandfly easily has the lowest CPU impact of any Linux EDR product on the market. In fact, Sandfly was designed from the beginning to run without making your life worse by consuming massive CPU resources on your critical infrastructure.

Sandfly goes on a host to do intermittent and random security sweeps. These sweeps take normally 30-60 seconds to complete and then vanish. The result is that CPU impacts blend into normal system operation and most users don't report seeing anything unusual even on heavily loaded boxes.

Further, the way Sandfly operates it avoids doing things like massive file scanning, scan on open and similar activities which are extremely expensive in terms of CPU and disk impacts (and work poorly for finding Linux intruders anyway). Sandfly even allows you to tailor the sweep priority level to your tastes. By default we run on a medium-low setting which will rarely ever cause a system impact, but you can lower it even further if you wish with essentially no impact on how we work.

Sandfly connects to the remote Linux systems to be secured using the industry standard SSH protocol. Sandfly supports authentication mechanisms allowed with SSH such as username/password, public/private keys, and SSH key certificates. We can also integrate with a variety of key vault solutions such as Hashicorp or Cyberark.

SSH keys are handled very carefully by the Sandfly platform. 

When you add SSH keys to Sandfly to gain access to your Linux systems, they are immediately encrypted with elliptic curve cryptography using keys unique to your installation. At that point, the SSH data is unrecoverable even if the database contents are completely compromised.

Initiating a Sandfly scan sends the encrypted keys to the scanning node able to access the target Linux system. The scanning node will use its keys to decrypt the credentials for that one instance and when done the encrypted credentials are disposed of. No encrypted keys are written to the disk on the node, and private keys for the node to decrypt credentials are not known by the server. 

With the above, a compromise of both the server and node simultaneously would be required to compromise SSH keys for your systems. As users do not interact with the scanning nodes, these systems can be kept in a highly secure configuration with limited access making it extremely difficult to get both components to initiate a credential theft. 

For customers that do not want any credentials stored, or who use SSH key certificates with short expiration times where storing credentials is not useful, you can deploy Sandfly in our "ad hoc" mode. The ad hoc mode allows you to pass in scan requests with one-time use credentials that are not stored by Sandfly anywhere.

Finally, Sandfly supports key vault integration with various vendors such as Hashicorp, Cyberark, Thycotic and more. We can customize these integrations based on your enterprise needs. Sandfly's key vault integration is unique in that keys are completely encrypted in transit from the key vault so even a total compromise of the Sandfly server cannot leak key details to an attacker.

Yes. Sandfly supports key vault integration with various vendors such as Hashicorp, Cyberark, Thycotic and more. We can customize these integrations based on your enterprise needs. Sandfly's key vault integration is unique in that keys are completely encrypted in transit from the key vault so even a total compromise of the Sandfly server cannot leak key details to an attacker.

No. The forensic engines used by Sandfly are carefully designed to not allow any external commands to be run. This is part of our security model. The engines are purpose built to gather Linux forensic data without relying on any external programs and without allowing an operator to run anything remotely.

Yes. And:

• You can chain together multiple jump hosts to access restricted segments. 
• Incident responders can chain together disposable hosts to access sites to hide where they are operating from. 
• After your investigation, jump hosts can be destroyed.

This capability helps you continue to use segmentation to secure at the network level, and ensures that attackers on remote systems will have a very difficult time determining your operating network if you wish to remain hidden.