Tenable Log Correlation Engine 6.0.9 Release Notes (06-02-2021)

Note: This release includes a fix for a potential vulnerability. For more information, see the Tenable Product Security Advisory.

Note: If you are upgrading from any version earlier than 6.0.0, upgrade directly to 6.0.x. See Upgrade Notes for detailed information about supported upgrade paths.

New Features

• New configuration attribute web_UI__login__client_CA_cert_path (string type), replacing webserver__login_requires_client_cert (Boolean type).

• Additional configuration attribute validation:

  • check that {cloud_vuln_upload__IP_or_FQDN custom_plugins_provider__IP_or_FQDN DNS_cache__domains_to_not_resolve

    DNS_cache__FQDNs_to_resolve_greedily} do not contain any characters illegal in a FQDN or domain name, and that neither '.' nor '-' is first or last character;

  • check that all characters in exclude_users and the "sensor" field of {syslog_sensors intrusion_detect_sensors} are ASCII, printable, and not whitespace;

  • ensure that {debug minimum_trace_level syslog_message_terminator_characters crypt_syslog__authorized_fingerprints} can be assigned only values legal for respective attribute.

• Added check-client-policies, a utility script that checks for several common errors (malformatted paths, illegal MD5 hashes, etc.) in .lcp files. This script may be invoked anytime from console, after you have sourced /opt/lce/tools/exigent-sessions.bashrc in that session. It is also invoked by diag, with output going to the policies.txt section of diag report.

• New filesystem_proc_filehandles.txt section in diag report, to help diagnose inter-application disk contention issues.

• Additional actions now afforded by the lce_crypto_utils utility:

  • --print-privkey

  • --print-PKCS12

  • --save-as-PKCS12

Changed Functionality and Performance Enhancements

• The rebuild_logs utility has been moved to under /opt/lce/tools/ for a more consistent deployment directory structure.

• The diag utility now gathers more per-process and per-thread info; in particular, cumulative delay due to block I/O waits is now reported.

• Revised mutex locking scheme in the lced daemon's event persistence module, to reduce lock contention and therefore inter-core communication overhead.

• Previously, server-side SSL credentials for uploading vulnerability reports toTenable Security Center and for securing interaction with Log Correlation Engine Web UI were shared. This arrangement has been problematic, insofar as the act of rotating credentials used for the one purpose would invariably break the other. Now, while server-side SSL credentials for uploading vulnerability reports to Tenable Security Center remain in /opt/lce/reporter/ssl/, the server-side SSL credentials for securing interaction with Log Correlation Engine Web UI are stored in the separate /opt/lce/credentials/web_UI/ location.

Bug Fixes

• The lced daemon would discard its previous reading of activeDb size on failure to acquire a new reading; this could lead to inaccuracies in activeDb trim action scheduling.

• In certain cases showids would enter dynamic halt state while saving an alert, and fail to relinquish its PostgreSQL connection.

• The lce_queryd daemon would retrieve total event count from the *_hhourly rollup tables even given a too-narrow query timespan; as result, total event count shown in upper right-hand corner of Tenable Security Center's Event Analysis summary pages could be inaccurate for queries covered much less than 1 week, at sites with relatively low inflow volume.

• Because of the extremely conservative default value False of the data_sync_retry setting in its configuration, PostgreSQL can mistakenly infer disk record corruption from a single spurious I/O fault report from the OS. This behavior is not a PostgreSQL bug nor an LCE bug, but each manifestation occasions significant (30 to 60 minutes) unscheduled downtime. To prevent this issue, LCE installer will now set data_sync_retry to True.

• When the source IP of packets received from an Log Correlation Engine client changes (as can happen with DHCP and several other scenarios) from A to B, LCE should update said client's IP to B in its internal roster; instead, Log Correlation Engine would record a new client with IP B, and retain the record of same client at A. Overall result was apparently duplicate client roster entries.

• Certificate authentication of WebUI logins worked in some particular cases, but did not work in the general case.

• Some values of the web_UI__password__minimum_lifetime__hours configuration attribute could interfere with a newly created user changing password from the temporary SA-assigned password to normal.

• The lce_wwwd daemon could reserve up to 7 PostgreSQL DB connections, contributing to an out-of-connections error condition in certain rare circumstances; fixed so that lce_wwwd uses no more than 2 PostgreSQL DB connections.

• Policy editor failed to honor the setting to not monitor subdirectories, if selected.

Security Enhancements

• Prevent Cross Site Request Forgery (CSRF) on login screen by authenticating anti-CSRF tokens.

• Upgraded OpenSSL libraries to 1.1.1k .

• Removed support for the deprecated TLSv1.1 protocol variant.

Upgrade Notes

• If you are upgrading from a version earlier than Log Correlation Engine 4.8.4, upgrade to Log Correlation Engine 4.8.4 before upgrading to Log Correlation Engine 6.09.
• If you are upgrading from Log Correlation Engine 5.0.x, upgrade to Log Correlation Engine 5.1.1 before upgrading to Log Correlation Engine 6.0.9.
• If you are upgrading from Log Correlation Engine 4.8.4 with high availability configured, use the method described in Migrate Your High Availability Configuration to LCE 6.0.4 or Later in the Tenable Log Correlation Engine User Guide.
• If you are upgrading from 6.0.4 with high availability configured, use the method described in Migrate Your High Availability Configuration to LCE 6.0.5 or Later in the Tenable Log Correlation Engine User Guide.

• If you are upgrading from Log Correlation Engine 5.x.y or 6.0.0, run:

  rpm --nopreun -Uvh lce-6.0.9-el6.x86_64.rpm

• If you are upgrading from Log Correlation Engine 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, or 6.0.5, after the rpm command completes, run:

  nohup /opt/lce/tmp/upgr606-rebuild-hhourlies &

  Note: The upgr606-rebuild-hhourlies script takes approximately 2.5 minutes to run per activeDb silo.

• If you are upgrading from Log Correlation Engine 6.0, 6.0.1, or 6.0.2, after the rpm command completes, run:

  nohup /opt/lce/tmp/upgr603-rebuild-silos &

  This command rebuilds your pre-existing event silos in the new format (which takes up less disk space and improves query performance). As each silo is rebuilt, it will automatically become available for querying again. The upgr603-rebuild-silos script will take 25-30 minutes to rebuild each pre-existing silo; it prioritizes silos with the most recent events.

  Note: If you are upgrading from Log Correlation Engine 6.0, 6.0.1, or 6.0.2, run /opt/lce/tmp/upgr606-rebuild-hhourlies first, then upgr603-rebuild-silos.

• If you are upgrading from Log Correlation Engine 4.8.4, 5.1.1, 6.0, 6.0.1, 6.0.2, or 6.0.3, you may be prompted to run /opt/lce/tmp/restore_per-client_decisions.sql when the upgrade utility completes. If you receive this prompt and you performed explicit client authorizations (without the aid of client assignment rules or the auto-authorization setting) or specified custom sensor names for individual Log Correlation Engine clients, run:

  source /opt/lce/tools/source-for-psql-shortcuts.sh

  psqlf /opt/lce/tmp/restore_per-client_decisions.sql

  This script applies the changes you made to your upgraded Log Correlation Engine.

  Note: If you did not perform explicit client authorizations or specify custom sensor names for individual Log Correlation Engine clients, you do not need to run /opt/lce/tmp/restore_per-client_decisions.sql

Supported Platforms

• Red Hat Enterprise Linux 6 64-bit / CentOS 6 64-bit

• Red Hat Enterprise Linux 7 64-bit / CentOS 7 64-bit