CloudPassage Halo — 5 January 2015 Release
The 5 January 2015 release of CloudPassage® Halo® features the ability to apply log prefixes to iptables rules, significantly improved accuracy for Linux vulnerability scans, and other enhancements and fixes.
New Features and Improvements
Log prefix capability for iptables policy rules
When creating or editing a Halo firewall policy for Linux, you can now—for each rule—optionally specify a string to be inserted at the beginning of the log message that is written to the firewall log when the rule is matched. (Logging must be enabled for that rule in order for the event to be created.)
The string can be up to 29 characters long and can include spaces and special characters.
One use case for this feature is to allow log-based intrusion detection to more easily detect and alert on the matching of specific individual firewall rules. For example, If you apply the prefixes "Inbound Drop" and "Outbound Drop" to your default-drop inbound and outbound policy rules, respectively, log messages from the matching of either of those rules will contain those identifying strings.
You can then create a log-based intrusion detection policy that specifies that the firewall log file should be scanned and that a Halo event should be recorded if either of those patterns appears.
Improved accuracy for vulnerability scans
This release includes significant improvements to the accuracy of software vulnerability scan results on all Linux platforms.
Enhancements to Halo reporting
Search filters now support selection of multiple values
On the Reports page in the Halo portal, multiple selection is supported for all search filters that have a drop-down list of values to select from. You add values to the filter one-by-one, by opening the list and clicking a value in it. You can remove a value from the filter by clicking the small "x" beside the value in the filter.
Enhancements to the Halo REST API
Log prefix capability now supported through API
The new log prefix capability (see Log prefix capability for iptables policy rules) is also available through the Halo REST API. The firewall rule object (in the Firewall Rules API endpoint) now contains a
log_prefix field that appears in the response JSON for each of the endpoint's GET methods. To set a prefix, include the field with the desired value in the request JSON for the "Add a new firewall rule..." or "Update a firewall rule" methods.
All search filters support multiple values, use OR logic
The set of search filters available for performing a server search on the "Servers" or "Saved Searches" endpoints has been normalized. All filters now can accept multiple values to search for, and the searches consistently use OR logic on the multiple values, meaning that if any one of the specified values for a filter matches, the search passes that filter.
Windows File Presence check now supports the asterisk wildcard
In Configuration Security Monitoring, the File Presence rule check now supports the use of an asterisk (
*) at the end of the supplied file path. Its function is the verify that the final folder in the path is not—or is—empty.
The following issues are among those that remain unresolved as of this release. Any known workarounds are described.
- IE8 not supported for Halo reporting. The Halo reporting service does not function for a user who has logged into Halo using Internet Explorer 8.
Workaround: Log in with a more recent version of IE or with a different browser, or use the Halo API to construct server searches.
- Editing file integrity baseline expiration. If you want to change the expiration value when editing or re-baselining an existing baseline, the new expiration date is now calculated from the current date, rather than from the original baseline-creation date. However, if you keep the same setting (number of days) for the expiration value, the re-calculation does not occur and the expiration date remains based on the original creation date.
Workaround: Select a different expiration value and save the baseline. Then re-edit the baseline and specify your desired expiration value.
- False-positive file integrity security events can occur in Linux systems in which the
prelinkutility regularly resolves links to dynamic libraries in executable files and stores the results in the executable files, thereby modifying them. This action can create differences between the servers of a scan group and the baseline (golden master) server, thereby causing the false positives.
Workarounds. Take either of the following steps:
- Manually run
prelinkon the baseline server before running the baseline scan. That should eliminate most or all false security events related to
- Turn off pre-linking on all of your servers.
- Manually run