Sandfly 5.1.1 - Important Performance Upgrade and Yescrypt Support
S
Steve Busko
started a topic
16 days ago
Sandfly 5.1.1 is released and includes an important bug fix which will improve database efficiency. It also includes new yescrypt support for our agentless password auditing, plus new detection modules for debugger attacks, thread masquerading, host system information, and more.
The database bug fix offers significant performance improvement and we recommend you read that section carefully before upgrading.
Database Bug Fix
We fixed a bug where raw result JSON was not being deleted when events automatically expired. The only way this data would delete is if the customer selected "Delete All" results. Because the raw result JSON was not being deleted automatically, this bug could lead to continuous database growth even though old results appeared to be deleted after the data retention period expired.
Sandfly 5.1.1 has scripts to go in and delete this old data during the upgrade. However, if you have many old results this can take a long time and cannot be backgrounded. You will need to wait until the clean-up operation completes before the system comes up after upgrade.
We recommend you do "Delete All" results in the UI before you do the upgrade. If you do not need the results this will ensure an instant upgrade happens. Deleting all results is shown in our documentation:
If you require the old results, you will need to wait until the upgrade process completes. Depending on the result totals and server hardware, this can take some time to finish as the database is scrubbed of old data.
With this bug fixed, it will result in significantly smaller database storage needs and system performance will be faster as well.
Yescrypt Password Algorithm Support
We sponsored the open source porting of the Yescrypt password algorithm to Go and made this available in our agentless password auditor.
Sandfly is unique as we work as a Linux EDR, but also can do things on remote systems to be proactive about security. One of our proactive features is our ability to audit users directly on endpoints and find default, weak, and custom passwords agentlessly that will lead to immediate compromise.
Newer Linux distributions have moved to using the Yescrypt algorithm by default. Yescrypt is a modern hashing algorithm with protections in place to make dedicated hardware brute forcing much harder. We worked with the designers of Yescrypt over at Openwall to implement the algorithm for use in Sandfly. We also sponsored this work as an open source project so others can make use of the algorithm in their own Go code.
Sandfly can now audit passwords on modern systems running Yescrypt to legacy distributions using older SHA512, MD5 and other algorithms. This includes extremely difficult to monitor embedded systems which very often have default passwords creating a significant security risk to organizations.
New Detection Modules
We have added in many new detection capabilities detailed below.
Alert on Linux kernels version 3
OS Identify Signatures and Custom Detection
Sandfly always runs our os_identify module when we connect to a host. This module pulls over all basic operating system information such as hardware, distribution versions, CPU details, memory, disk mounts, network interfaces, performance data, plus much more. It functions as an asset inventory. Now, customers can build sandfly modules against any of these parameters such as kernel versions, CPU bugs, hardware types, and more to generate alerts.
We have included the following modules to provide an example of the capability to customers:
policy_cpu_bugs_meltdown - A sample template to show you how to search for specific CPU bugs you want to know about. This demonstrates searching for the Meltdown CPU bug, but can be altered to search for any or all bugs. This is not enabled by default, but can be used to build custom sandfly modules for your needs.
policy_kernel_version_notable - Another template to allow you to search for specific kernel versions of interest operating in your environment.
policy_kernel_version_release_2_or_older - A policy module that will show you any system running old 2.x Linux kernels. Disabled by default.
policy_kernel_version_release_3 - Another policy module that will show you any Linux kernels that are version 3. Disabled by default.
These modules demonstrate this new capability which can be cloned and used by teams to search for any attribute we collect in the os_identify data. We collect extensive data and are here to assist customers if they need any help in customizing them for their needs.
Threat Detection
We have improved and added in new detections for the following:
process_masquerade_kernel_thread_flag_mismatch - A process is running that is trying to impersonate a kernel thread. This builds on our existing threat detection modules for this attack by leveraging new Linux kernel flags present in 6.x kernels.
process_running_debugger_anti_debugging - Spots a process that has attached a debugger function to itself to prevent other debuggers from being used against it. This is often done for anti-debugging in malware to prevent runtime analysis.
process_running_debugger_attached - A process is running with an active debugger attached. This could indicate someone is trying to steal confidential data such as passwords, cryptographic keys, or confidential data from a process.
process_running_debugger_attached_state - Like previous, another way to detect a process is running with a debugger attached.
process_shell_running_ssh_command_invocation - A shell was invoked directly from ssh instead of using the normal user login shell. This is a suspicious way to invoke a shell and often is done to prevent command history and other auditing. This check is disabled by default due to false alarm risk on older CentOS systems. For modern systems it can be enabled and provides reliable detection of this problem.
recon_process_list_root_gid - Get a recon listing of all processes running with the root group ID (GID). Useful for drift detection profiling if you want to spot new root owned processes running.
recon_process_list_root_uid - Like above, but recon list for the root user ID (UID) running a process. Again, useful for drift detection of new root owned processes running on a host.
process_match_groupname_status - A template to allow you to find any process running with a specific group name. For instance, finding all processes running under a web server group. This template provides examples of how to do this search for custom sandfly use.
SSH Banned Key Zone Violation
When a banned key is seen inside a SSH Security Zone, the zone will show a new Banned Key Violation tag even if the key is tagged as authorized in that zone.
Get a Free License Today
If you have not tried Sandfly, get your free license below:
Steve Busko
Sandfly 5.1.1 is released and includes an important bug fix which will improve database efficiency. It also includes new yescrypt support for our agentless password auditing, plus new detection modules for debugger attacks, thread masquerading, host system information, and more.
The database bug fix offers significant performance improvement and we recommend you read that section carefully before upgrading.
Database Bug Fix
We fixed a bug where raw result JSON was not being deleted when events automatically expired. The only way this data would delete is if the customer selected "Delete All" results. Because the raw result JSON was not being deleted automatically, this bug could lead to continuous database growth even though old results appeared to be deleted after the data retention period expired.
Sandfly 5.1.1 has scripts to go in and delete this old data during the upgrade. However, if you have many old results this can take a long time and cannot be backgrounded. You will need to wait until the clean-up operation completes before the system comes up after upgrade.
We recommend you do "Delete All" results in the UI before you do the upgrade. If you do not need the results this will ensure an instant upgrade happens. Deleting all results is shown in our documentation:
Deleting Results
If you require the old results, you will need to wait until the upgrade process completes. Depending on the result totals and server hardware, this can take some time to finish as the database is scrubbed of old data.
With this bug fixed, it will result in significantly smaller database storage needs and system performance will be faster as well.
Yescrypt Password Algorithm Support
We sponsored the open source porting of the Yescrypt password algorithm to Go and made this available in our agentless password auditor.
Sandfly is unique as we work as a Linux EDR, but also can do things on remote systems to be proactive about security. One of our proactive features is our ability to audit users directly on endpoints and find default, weak, and custom passwords agentlessly that will lead to immediate compromise.
Newer Linux distributions have moved to using the Yescrypt algorithm by default. Yescrypt is a modern hashing algorithm with protections in place to make dedicated hardware brute forcing much harder. We worked with the designers of Yescrypt over at Openwall to implement the algorithm for use in Sandfly. We also sponsored this work as an open source project so others can make use of the algorithm in their own Go code.
Sandfly can now audit passwords on modern systems running Yescrypt to legacy distributions using older SHA512, MD5 and other algorithms. This includes extremely difficult to monitor embedded systems which very often have default passwords creating a significant security risk to organizations.
New Detection Modules
We have added in many new detection capabilities detailed below.
OS Identify Signatures and Custom Detection
Sandfly always runs our os_identify module when we connect to a host. This module pulls over all basic operating system information such as hardware, distribution versions, CPU details, memory, disk mounts, network interfaces, performance data, plus much more. It functions as an asset inventory. Now, customers can build sandfly modules against any of these parameters such as kernel versions, CPU bugs, hardware types, and more to generate alerts.
We have included the following modules to provide an example of the capability to customers:
policy_cpu_bugs_meltdown - A sample template to show you how to search for specific CPU bugs you want to know about. This demonstrates searching for the Meltdown CPU bug, but can be altered to search for any or all bugs. This is not enabled by default, but can be used to build custom sandfly modules for your needs.
policy_kernel_version_notable - Another template to allow you to search for specific kernel versions of interest operating in your environment.
policy_kernel_version_release_2_or_older - A policy module that will show you any system running old 2.x Linux kernels. Disabled by default.
policy_kernel_version_release_3 - Another policy module that will show you any Linux kernels that are version 3. Disabled by default.
These modules demonstrate this new capability which can be cloned and used by teams to search for any attribute we collect in the os_identify data. We collect extensive data and are here to assist customers if they need any help in customizing them for their needs.
Threat Detection
We have improved and added in new detections for the following:
process_masquerade_kernel_thread_flag_mismatch - A process is running that is trying to impersonate a kernel thread. This builds on our existing threat detection modules for this attack by leveraging new Linux kernel flags present in 6.x kernels.
process_running_debugger_anti_debugging - Spots a process that has attached a debugger function to itself to prevent other debuggers from being used against it. This is often done for anti-debugging in malware to prevent runtime analysis.
process_running_debugger_attached - A process is running with an active debugger attached. This could indicate someone is trying to steal confidential data such as passwords, cryptographic keys, or confidential data from a process.
process_running_debugger_attached_state - Like previous, another way to detect a process is running with a debugger attached.
process_shell_running_ssh_command_invocation - A shell was invoked directly from ssh instead of using the normal user login shell. This is a suspicious way to invoke a shell and often is done to prevent command history and other auditing. This check is disabled by default due to false alarm risk on older CentOS systems. For modern systems it can be enabled and provides reliable detection of this problem.
recon_process_list_root_gid - Get a recon listing of all processes running with the root group ID (GID). Useful for drift detection profiling if you want to spot new root owned processes running.
recon_process_list_root_uid - Like above, but recon list for the root user ID (UID) running a process. Again, useful for drift detection of new root owned processes running on a host.
process_match_groupname_status - A template to allow you to find any process running with a specific group name. For instance, finding all processes running under a web server group. This template provides examples of how to do this search for custom sandfly use.
SSH Banned Key Zone Violation
When a banned key is seen inside a SSH Security Zone, the zone will show a new Banned Key Violation tag even if the key is tagged as authorized in that zone.
Get a Free License Today
If you have not tried Sandfly, get your free license below:
Get Sandfly
Upgrading Sandfly
All customers are encouraged to upgrade to receive the important database bug fix, plus new password auditing and detection modules.
We are here to help with any questions. Please see our documentation on the new features and capabilities:
Sandfly Documentation
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.