Sandfly 4.6.0 receives a long anticipated feature: advanced whitelisting. We have also enabled our powerful SSH hunter for all users even on our free tier. Additionally we have expanded our Linux threat coverage to include new SSH key option checks, credential leak detection, and more.

Advanced Whitelisting

Sandfly comes out of the box ready to detect threats against Linux. However, each customer will have an environment that is unique. Sometimes alerts will happen that Sandfly considers unusual, but are perfectly normal for an end user.

In prior versions, customers were required to disable a sandfly module per-host or across all systems to eliminate false or true positives (a real detection, but not a threat to the environment). With our advanced whitelisting, customers can now be very specific about what they want to ignore and still get relevant alerts when detection happens outside those parameters.

We now offer the following whitelisting options:

• Disable Sandfly - Do not run the sandfly module on this or all hosts (legacy mode).

• Rapid Match - Based on Sandfly Hunter key forensic value.

• Loose Match - Based on loose set of parameters for the alert (e.g. process name and path).

• Strict Match - Based on a tighter list of parameters for the alert (e.g. process name, path, and SHA512 hash).

• Advanced Match - Based on any forensic attribute deemed important (e.g. process name, path, username, binary size, and cryptographic hashes).

Example Whitelist

The new feature is best shown with an example. Here is an alert that normally could be considered malicious, but in this environment is intentional:

Sandfly has identified a process running from a hidden directory:

/usr/.security/monitor

In many cases this would be suspicious, but here it is a security tool running from a hidden directory on purpose. Below we'll describe each whitelist method and how they work in relation to this event.

Disable Sandfly

This is the legacy mode. We simply will disable the sandfly module entirely across all systems. In the above example we will not alert on any process running in any hidden directory across the host or all hosts.

Sometimes this is the best option if you know a particular check is going to cause alerts based on how the local systems are being run. However, this is a bit of a shotgun approach and generally reserved for special cases where the other options are not workable.

Rapid Match Whitelist

Simply select the Sandfly hunter key forensic under the alert for your whitelist. For instance if you wanted to just ignore on this path, you simply click the whitelist button. See image below for an example.

Next, you are taken to the whitelist detail screen where you can see the rule, what hosts it would apply to, optional tags, or enabled against all hosts.

You can also supply a comment so others can see when and why this rule was created.

Loose Match Whitelist

A loose match whitelist will take recommended parameters from Sandfly to make a whitelist that will limit the scope of the alert, but allows some leniency to prevent unnecessary alarms across different hosts.

For instance, a loose whitelist for a process would ignore it if it matches the process name and the process path. A process name from a different path would still generate an alert. We have similar parameters for files, directories, users, log entries, etc.

Going to the review page, we see instead of one simple rule made like our first example, we now have two based on process name and path.

Strict Match Whitelist

Like loose whitelisting, strict whitelisting takes some defaults based on our experience but makes them much tighter. For a process, Sandfly will require the process name, path, and SHA512 hash to match. This is a significantly higher bar for a process to hit to be ignored.

Here you can see the added details needed to meet the strict requirements:

Advanced Match Whitelist

Finally, if you want to build your own custom whitelist based on any Linux forensic attribute, you can do that as well. Simply select advanced:

You will be taken then to the rule builder where you can pick individual forensic attributes to add to the rule:

You can also type in values of interest to rapidly find them. Here we want to find all cryptographic hashes and select them all to be extra paranoid. If this is done, then the on disk hashes of the file and running process binary hashes must match to be exempted from alert:

Once selected we will have a chance to review our rules before saving like above:

Whitelist Ready to Save

At this point our rules are ready to be saved. We just need to apply it to all hosts, an individual host, or hosts by tag. We'll review that process next.

Whitelist Tagging

In all the above examples, you can apply the rule against a single host, all hosts, or against hosts with only a certain tags.

Below we select all systems tagged as "webservers". The new rule would apply to all our systems with this tag only. You can add and remove tags to rules as needed. You can also bulk tag hosts so they get the new rules immediately. Optionally, you can select to apply it to all hosts if you know it's a globally needed rule. The image below shows both options.

To bulk tag systems that have not been tagged already, simply select them from the Hosts menu, the click the Edit Tags menu button.

Enter in your new tag name or select an existing tag:

Select Add Tags and they are added. These systems will now be part of this whitelist group. Any new whitelist rules added with this tag will immediately apply across all hosts with that tag.

Whitelist Summary

Customers can view whitelists under the Whitelists menu. The list shows all whitelisted sandflies and if they apply to all hosts, hosts by ID or hosts by tags. You can also see the comment field summary.

By selecting any entry, there is a summary of the whitelist rule and customers can edit, delete, or disable it as needed.

Free SSH Hunter

Previously we limited our SSH Hunter to licensed customers, but today we are making it available to all users, even on the free tier. You do not need to update your license if you already have one. Simply load Sandfly 4.6.0 and SSH Hunter will be enabled automatically.

SSH key compromise is a serious risk on Linux. Unmonitored SSH credentials allows old keys to remain, malicious keys to be silently inserted, and unauthorized access to rapidly spread. Home and small network users are not exempt from these risks and we want customers to have this additional monitoring free of charge to help secure assets against SSH breaches.

New Linux Threats - Credential Leakage and More

As always, we have expanded our Linux threats detected. We have new checks for SSH key options that can lead to policy violations or other problems. We also include a set of policy modules to search for credential leak threats supplied by a loyal user:

Thoughtbox Custom Sandflies

The new checks are:

policy_process_command_credential_leak - Credential leaks in process command line.

policy_process_at_jobs_credential_leak - Credential leaks in at jobs.

policy_process_cron_credential_leak - Credential leaks in cron jobs.

policy_user_history_credential_leak - Credential leaks in user history files.

Other threat hunting modules have been expanded as well, plus Mitre ATT&CK tags updated to cover brute force and other tactics as detected by our password auditor.

Get a Free License Today

All Sandfly users get advanced whitelisting and SSH Hunter. Licensed customers also get the ability to create custom sandfly modules on the fly for rapid and immediate threat hunting plus much more.

Get Sandfly

Upgrading Sandfly

Sandfly 4.6.0 represents a significant upgrade and ensures Sandfly runs across all your Linux systems with the least amount of noise. Agentless security for Linux is fast, effective, and accurate. All customers are encouraged to upgrade. We are here to help with any questions.

Customers wishing to upgrade can follow the instructions here:

Upgrading Sandfly

If you have any questions, please reach out to us.

Thank you for using Sandfly.