Sandfly Blog
Sandfly 1.6.1 is released and has some
The install procedure for Sandfly has been greatly simplified. You now need to run one script on the server and enter some basic information and it will complete the cryptographic key generation and write out configuration files. Server install is now an under 5 minute process (with most of that time waiting to generate the cryptographic keys).
When Sandfly adds a host, it was using a SHA256 fingerprint of the system’s SSH key. This is the same procedure all SSH clients use to detect if the remote host is identical to what you used to previously connect to it.
Sandfly however uses it also to know a host it is connecting to is known even if it changes its IP address between scans. In this way, you can be in a very dynamic environment but Sandfly will always be able to know what hosts are there and update the results correctly. Basically, we track hosts by SSH fingerprint, not by IP address or even hostname.
This works great except if a host happens to be using the same key as other hosts on the network. Re-using SSH keys for hosts is never advised, but it can happen under a couple cases:
In the above cases, Sandfly would see the same SSH key and update that system as if it were the same host. This meant that systems with duplicated host keys for whatever reason would stomp on each other’s results when Sandfly ran each time.
Now we have changed this behavior. We still use the SSH key fingerprint, but also combine it with other host attributes when we login to create a unique ID that will be different even if you are behind load balancers, or re-imaging systems.
With the above explanation out of the way, this update takes your old Host IDs and updates them to the new method automatically. When you do this update we will do this behind the scenes, but with some caveats:
This should all be transparent to you when you re-start after the update. If you have any problems, please contact us for support.
We have added caching for process checks that gives them almost a 50% speed boost. They were already fast, but now have become even faster and use less CPU on the remote hosts when running.
Customers reported that the syslog entries being generated were returning the Docker container name (a hex value) instead of the Sandfly server name into their SIEM and syslog management systems. We have fixed this so you will see the Sandfly server hostname now as part of the syslog entry.
All time values internally for Sandfly have always been in UTC time to avoid timezone issues and give consistent time logging. We have now updated the syslog generation code to also UTC timestamp all syslog entries we generate. SIEM/Syslog aggregators will now see this UTC timestamp as part of each syslog entry they receive.
In Sandfly 1.6.0 we introduced enhanced attributes for Operating Systems that gives a lot more details about the host, hardware, and CPU. On some systems there were permission problems causing this to fail. We have fixed this so that if permission problems happen, we simply don’t collect this data and you get the standard attributes only. This is not common, but can happen on some hosts depending on how they are configured.
We have updated the documentation to include a list of threats detected by Sandfly, and all they keywords that can be returned in the results. This can be useful to customers building out parsing for their SIEM products and want to know what values are available:
Due to the changes to the install scripts, you must pull the latest changes from GitHub or things will break. The newest scripts update your keys and config data to a new format for future use.
Please read the upgrade information, paying attention to running this command from inside the sandfly-setup directory.
This update is preparing for some more features in the future. Thanks for using Sandfly.