Log Correlation Engine 4.2
Administration and User Guide
May 14, 2014Table of Contents
Introduction ... 4
Standards and Conventions ... 4
Components of the Log Correlation Engine ... 4
IDS Collection and Correlation ... 5
IDS Collection Only ... 5
Prerequisites ... 6
Supported Operating Systems/Platforms ... 6
Licenses ... 6
SecurityCenter ... 6
Secure Shell Public Keys ... 6
Secure the Log Correlation Engine Server System ... 6
LCE Server Installation ... 7
Getting Started ... 7
Installation Location ... 7
Installing the Package ... 7
Files and Layout ... 13
Base Directories ... 13
The admin Directory ... 13
The daemons Directory ... 13
The db Directory ... 13
Installing the License ... 13
Hostname Determination ... 13
Key Installation ... 14
Upgrading the License ... 14
Configuration ... 15
The lce.conf File... 15
LCE Configuration ... 15
Pointing to a New “Plugins” Directory ... 23
Adding Log Correlation Engine Client Information ... 23
Debug Mode ... 24
Correlation Statistics ... 25
Utilizing Tiered LCEs ... 26
Configuring the Primary LCE Server ... 26
Configuring the Auxiliary LCE Server ... 26
Syslog Considerations ... 26
Sending Syslog Messages to Other Hosts ... 26
syslog Compliant Messages ... 27
Content of Forwarded syslog Messages ... 27
Storing All Logs with “save-all” ... 27
Different File System ... 28
Multiple Plugin Matches per Log File “multiple-matches”... 28
Quick Example ... 28
The rules.conf File ... 28
Email Syntax ... 29
Syslog Syntax ... 29
LCE Rule Filters ... 29
LCE Shell Command Options ... 31
Email/Alerting/Execution ... 31
LCE Operations ... 32
Starting LCE ... 32
Halting LCE ... 33
Restarting LCE ... 33
Determine LCE Status ... 33
Operating the stats Daemon ... 33
Updating Plugins (PRM Files) and TASL Scripts ... 33
Automatic Plugin (PRM Files) and TASL Updates ... 33
Updating Individual PRM Files ... 34
Excluding PRM Files ... 35
Excluding TASL Files ... 35
Managing Client Configuration Files ... 35
Upgrading LCE ... 35
Additional Features ... 36
Importing LCE Data Manually ... 36
User Tracking ... 37
Working with SecurityCenter ... 38
Adding the LCE to SecurityCenter ... 38
Configuring Organizations ... 40
Analyzing Security Events ... 41
Identifying Vulnerabilities ... 41
TASL Scripts ... 41
Full Text Searches ... 42
For More Information ... 43
Appendix 1: Sample lce.conf File ... 44
Appendix 2: Sample LCE rules.conf File ... 55
Appendix 3: Troubleshooting ... 59
Appendix 4: Manual SC4/LCE Key Exchange ... 60
Appendix 5: Non-Tenable License Declarations ... 62
Introduction
This document describes the installation, configuration, and administration of Tenable Network Security’s Log Correlation Engine 4.2 for both standalone and SecurityCenter deployments. Please email any comments and suggestions to [email protected].
If the LCE is to be managed by Tenable’s SecurityCenter, knowledge of SecurityCenter operation and architecture is assumed. Familiarity with system log formats from various operating systems, network devices, and applications and a basic understanding of Linux and Unix command line syntax is also assumed.
Standards and Conventions
Throughout the documentation, filenames, daemons, and executables are indicated with a courier bold font such as
gunzip, httpd, and /etc/passwd.
Command line options and keywords are also indicated with the courier bold font. Command line examples may or may not include the command line prompt and output text from the results of the command. Command line examples will display the command being run in courier bold to indicate what the user typed while the sample output generated by the system will be indicated in courier (not bold). Following is an example running of the Unix pwd command:
# pwd
/opt/local/lce #
Important notes and considerations are highlighted with this symbol and grey text boxes.
Tips, examples, and best practices are highlighted with this symbol and white on blue text.
Components of the Log Correlation Engine
Note that some features described in this document are only meaningful if LCE is deployed with SecurityCenter.
The Log Correlation Engine (LCE) has three basic components: the client, the daemon/server component (lced) and the user interface (SecurityCenter GUI).
Throughout this document, the LCE daemon/server component will be referred to as the LCE server, while the GUI component will be referred to as SecurityCenter for simplicity.
The LCE client is installed on hosts to monitor and collect events that are forwarded on to the LCE server daemon. When received by the LCE server, events are both stored as raw logs and normalized and correlated with vulnerabilities (if applicable). The SecurityCenter UI makes both the raw and normalized event data available to the user for event analysis and mitigation.
LCE users work with log data from a wide variety of sources. Each organization can make queries to one or more LCE servers that contain events from a wide variety of devices including firewalls, servers, routers, honeypots, applications, and many other sources. The LCE supports many types of agents including:
Windows, Linux, and Unix system and application logs
Check Point OPSEC events
Cisco RDEP events
Cisco SDEE events
NetFlow
Splunk
Sniffed TCP and UDP network traffic (Tenable Network Monitor)
Sniffed syslog messages in motion
File monitoring (Linux, Unix, and Windows)
LCE has many signature processing libraries to parse logs and can normalize and correlate most network IDS devices, as well as messages from SecurityCenter. The LCE supports the following IDS sources:
IDS Collection and Correlation
Bro
Cisco IDS
Enterasys Dragon
HP TippingPoint
IBM Proventia (SNMP)
Juniper NetScreen IDP
McAfee IntruShield
Fortinet IDS events
Tenable’s Passive Vulnerability Scanner (PVS)
Snort (and Snort-based products)
TippingPoint’s syslog event format must be modified to use a comma delimiter rather than a tab delimiter before it can be processed by the LCE.
IDS Collection Only
AirMagnet
Check Point (Network Flight Recorder)
Portaledge
Toplayer IPS
There are thousands of normalization rules that support most operating systems, firewalls, network routers, intrusion detection systems, honeypots, and other network devices. The list of officially supported log sources is frequently updated on the Tenable web site.
Prerequisites
It is important to ensure that the prerequisite requirements for LCE are met before beginning installation. These requirements include:
A CentOS/RHEL OS platform with all unnecessary services disabled
LCE license
LCE management installation (SecurityCenter)
LCE clients (if applicable)
Secure Shell (SSH) key generation
Supported Operating Systems/Platforms
The LCE server component is available for the Red Hat Enterprise Linux (RHEL) and CentOS 5.x and 6.x operating systems for 32-bit and 64-bit platforms. One or more LCE servers can be installed to operate with a single SecurityCenter or LCE Manager.
The LCE server can be installed on the SecurityCenter’s host system, but this configuration is not recommended for performance reasons. If you are using the LCE Manager to manage the LCE server, they can both be installed on the same system without as much of a performance impact since it does not have any of the vulnerability data that SecurityCenter manages.
Licenses
LCE servers are licensed to the specific hostname of the system it is to be installed on. There is no licensed limit to the number of events or IPs that the LCE can be configured to monitor.
There are different licenses available for the LCE based on the total amount of storage used by the LCE. The licenses are based on 1 TB, 5 TB, and 10 TB storage sizes. The maximum number of silos available to each license size is 103, 512, and 1024, respectively. There is no difference in the LCE software that is installed, just the maximum storage size that can be used by the LCE. Data silos are always limited to a maximum size of 10 GB per silo.
SecurityCenter
If the LCE is to be managed by SecurityCenter, you must download and install SecurityCenter, which is available from the Tenable Support Portal. Please refer to the SecurityCenter documentation for more information on installation and
configuration.
The current versions of both products are required to ensure complete feature integration between LCE Server and SecurityCenter.
Secure Shell Public Keys
LCE analysis is provided to SecurityCenter through the use of command execution across a Secure Shell (SSH) network session. When SecurityCenter queries a LCE server, it invokes a SSH session to the configured LCE server. All execution and analysis of LCE data occurs on the LCE server.
SSH public keys are configured such that SecurityCenter can invoke commands on the LCE server. Non
system-administrator accounts are used to perform these queries. The trust relationship is only needed from SecurityCenter to the LCE server.
Secure the Log Correlation Engine Server System
It is recommended that the server operating system be locked down before installation to ensure that no unnecessary services are running. The only service that is required to support remote users is SSH. While the LCE daemon is operational, it will listen by default on UDP port 514 for syslog messages, UDP port 162 for SNMP, TCP port 601 for reliable syslog service messages over TCP, TCP port 31300 for the LCE API (needed if LCE clients are operational), and TCP port 31302 for load balanced LCE servers.
The system running the LCE can operate a syslog daemon, but the syslog daemon must not be listening on the same port(s) that the LCE server is listening on.
LCE Server Installation
If the LCE server is to be managed by SecurityCenter, you must upgrade SecurityCenter to version 4.6.2.2 or greater to use the new functionality in LCE 4.2. Please contact Tenable Support at [email protected] if you have any questions regarding upgrading SecurityCenter.
Getting Started
Before beginning the LCE installation, it is important to understand the high-level steps required to facilitate a successful installation. These steps are typically performed in the following order:
1. Download the LCE server RPM and confirm the integrity of the installation package by comparing the downloaded MD5 checksum with the one listed in the product release notes.
2. Install the LCE server RPM.
3. Copy the LCE license key (lce.key) to /opt/lce/daemons
4. Execute the post install script to configure LCE (/opt/lce/tools/lce-post-install.sh) 5. Start the LCE daemon (service lce start)
6. If the LCE server is to be managed by SecurityCenter, use the SecurityCenter’s web interface to add it as a resource.
Installation Location
The installation file may be placed anywhere on the installed system. The installation steps described below assume execution from the same directory where the installation package is located.
Installing the Package
To ensure consistency of audit record time stamps between the LCE and SecurityCenter, make sure that the underlying OS makes use of the Network Time Protocol (NTP) as described in:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sect-Date_and_Time_Configuration-Command_Line_Configuration-Network_Time_Protocol.html
If you are upgrading from a previous version of LCE, please skip this section and see the section titled “Upgrading the Log Correlation Engine” below. Please follow the instructions in this section for new installations.
As the root user, install the LCE RPM using the following command: # rpm -ivh lce-4.2.x-es6.x86_64.rpm
An example is shown below:
Preparing... ########################################### [100%] 1:lce ########################################### [100%] The installation process is complete.
Please refer to /var/log/lce_upgrade.log to review installation messages. This is a new installation. To configure LCE, please run:
/opt/lce/tools/lce-post-install.sh
# /opt/lce/tools/lce-post-install.sh
Beginning in LCE 4.2 you will need to run the post install script “/opt/lce/tools/lce-post-install.sh” as shown above. This script will prompt for additional information to complete the initial configuration of the LCE server. The script will attempt to locate a valid license key as /opt/lce/daemons/lce.key and will prompt for the location of the key if it does not exist in that location. The script will then determine if specific ports are open and available for use. Next, the script will prompt for networks to include and exclude for statistical analysis. The database directory will be checked for validity and the approximate free disk space will be reported. If necessary (for example, if there is insufficient disk space), a different directory may be entered. The IP address and names of syslog sensors are also entered at this time. See the configuration output below for an example:
--- LCE CONFIGURATION
--- TENABLE NETWORK SECURITY
http://www.tenable.com [email protected] Copyright 2003-2013
Welcome to the LCE configuration!
This will assist you in configuring your newly installed LCE. It should take about a minute to complete.
Press ENTER to continue
The configuration script has detected that LCE is currently running. It is being shut down so that the configuration can be completed... Stopping LCE Indexer [ OK ] Stopping LCE Report Proxy [ OK ]
--- LCE CONFIGURATION : Key File
---
We will now check /opt/lce/daemons/lce.key for validity...
LCE is unable to find a valid key/license in: /opt/lce/daemons/lce.key It is possible that:
* the file doesn't exist or is not a license file, * the license has expired, or
* the license does not belong to this server. Enter the full path to your license file, or,
just press ENTER when you have copied it to: /opt/lce/daemons/lce.key >>
The key in /opt/lce/daemons/lce.key is valid!
--- LCE CONFIGURATION : Activation
--- In order to receive plugin updates, the Log Correlation Engine
must be activated.
Please enter your activation code:
--- LCE CONFIGURATION : Interface Ports
--- LCE listens for data on a number of ports.
LCE will check now to be sure that none of those ports are in use.
If any of the ports are in use, you may reconfigure LCE to use a different port, or stop the service using the port.
The LCE ports will now be checked for validity... Press ENTER to continue
...checking the syslog port (udp port 514)...
...checking the reliable syslog port (tcp port 601)...
...checking the LCE client-server communications port (tcp port 31300)...
...checking the snmp port (udp port 162)...
...checking the LCE load balancing port (tcp port 31302)...
--- LCE CONFIGURATION : Networks
--- LCE contains a statistics engine for anomaly detection, and a correlation engine for advanced alerting.
For best performance, these engines need to know what internal network ranges to track in your log data, as well as what network ranges NOT to track.
First, please configure the networks you wish to INCLUDE in analysis. Press ENTER to continue
--- LCE CONFIGURATION : Networks to include
--- Current include-networks:
--- ---
Network ranges may be specified in two ways:
1. IP/Netmask - for example, 192.168.0.0/255.255.0.0 2. IP/CIDR - for example, 192.168.0.0/16
Please enter a network range to include (or press ENTER to quit). >>
--- LCE CONFIGURATION : Networks
--- Next, please configure the networks you wish to EXCLUDE in analysis. Press ENTER to continue
--- LCE CONFIGURATION : Networks to exclude
--- Current exclude-networks:
--- ---
Network ranges may be specified in two ways:
1. IP/Netmask - for example, 192.168.0.0/255.255.0.0 2. IP/CIDR - for example, 192.168.0.0/16
Please enter a network range to exclude (or press ENTER to quit). >>
--- LCE CONFIGURATION : Vulnerability Reporting
---
LCE will provide reports to SecurityCenter containing vulnerability information. This is done over a secure connection requiring a
username and password. Default ones are provided, but it is recommended that you choose your own now if you have not done so already.
The username and password will be the same as the ones you enter into SecurityCenter when you add this LCE as a passive scanner for
vulnerability information.
The current USERNAME is "username"
Press ENTER to use this name, or enter a new one now. >>
The current PASSWORD is "passwd"
Press ENTER to use this password, or enter a new one now. >>
--- LCE CONFIGURATION : Database Directory
---
Depending on your license, each LCE may store anywhere from 250 GB to 10 TB of data in the event database.
The database directory will now be checked for validity... Press ENTER to continue
The current database directory (/opt/lce/db/) has 4 GB free.
If you would like to change the database directory, you may enter it now, or simply press enter to continue using the current selection.
>>
--- LCE CONFIGURATION : Syslog Sensors
---
All events analyzed and stored by LCE have an associated sensor name. For events without a sensor name in the data itself, LCE may still assign a sensor name you designate based on the IP address of the sender.
If you wish to name IP addresses as particular sensor names, you may do so now.
This can also be updated later by modifying /opt/lce/admin/syslog_sensors.txt. The current configured Sensors are:
---
IP Address = "" Sensor Name = ""
Please enter the IP address of the next Syslog Sensor, or press ENTER to quit entering Syslog Sensors:
>>
Done entering Syslog Sensors.
--- LCE CONFIGURATION : Complete
---
Congratulations! LCE configuration has been completed.
To begin collecting and analyzing data from your network in just minutes, please refer to the LCE Quick Start Guide. The LCE Administration and User Guide provides a detailed discussion of advance configuration items in /opt/lce/daemons/lce.conf, including:
- Database archiving - Syslog forwarding
- Automatic plugin updates
- Load balancing across multiple LCE servers - NAT setup for LCE clients
- IDS sensors
- Processing of usernames and hostnames - Statistical anomaly parameters
Note: If you are running this script directly instead of through the rpm install, you will need to manually restart the LCE services yourself by running:
"service lce restart"
After you have accumulated a week of data or more, you should run the statistical anomaly engine by running:
"service stats restart"
Press ENTER to complete the configuration The installation process is complete.
Please refer to /var/log/lce_upgrade.log to review installation messages. #
Once this data is entered, the initial configuration is complete. More detailed configuration may be performed by editing the /opt/lce/daemons/lce.conf file to include syslog forwarding, load balancing across multiple LCE servers, NAT setup for LCE clients, and other advanced settings.
For more information on large scale deployments, please refer to the Log Correlation Engine 4.2 High Availability Large Scale Deployment Guide.
The installation process will create a user and group named “lce” and install the LCE to the /opt/lce directory. All files will be installed with the user and group of “lce” except for the actual lced daemon, which is set-user-id root. This must be started as the “lce” user, and once the daemon has bound to the appropriate port(s) it will drop privileges. If the lced
daemon terminates abnormally for any reason, the system will automatically restart the daemon and add a warning to the LCE logs.
Files and Layout
Base Directories
Within the /opt/lce directory are some main tools and various sub-directories including, of particular interest: admin,
daemons, and db.
The admin Directory
This directory contains all of the LCE’s log files. There is a subdirectory named log that contains various log files. System log file names are based on the format of year and month date such as 2012May.log. Log files in the main log directory are general LCE log system files. Within subdirectories of the log directory are logs for specific aspects of the LCE such as clientmanager, indexing, stats, queries, and imports.
The daemons Directory
This directory holds the actual lced binary, its configuration files (lce.conf and rules.conf), and several helper functions to update the LCE plugins. The LCE Client Manager binary and support files are also located within this directory and its subdirectories. The license key must also be placed in this directory and renamed to lce.key.
Within this directory is the plugins directory that contains all of the libraries used by the LCE to parse events. When the LCE loads, it will load all libraries in this directory unless they are disabled.
Within the lce.conf file, the plugins-directory keyword is used to specify the location of the active directory containing the LCE plugins. Information about LCE plugins and writing them is included in a separate document entitled “Log Correlation Engine Log Normalization Guide”.
The db Directory
As the LCE is operating, it keeps all of the event data in the db directory. Each silo will be labeled with a
lce(number).ndb and its log_store and db_index_c directories.
When a silo is “rolled” and is no longer the active silo, there will also be a cache and an index field. For example, silo #5 would have lce5-cache and lce5-index directories. These will contain the results from previous cached queries and indexing.
Installing the License
Hostname Determination
The LCE uses the hostname (not the domain name) of the system it is being installed on. To determine the hostname needed for a LCE license, simply run the hostname tool and report what is returned. For example:
# hostname badger #
Key Installation
By default, the demo or commercial license key file for the LCE must be placed on the system running the LCE and moved to the /opt/lce/daemons directory. The installation script will prompt for the name and location of the key file if it is not already in place and properly named during installation. It is recommended that you put the license key in place after the rpm package has been run, but prior to running the post install script.
If a key must be installed manually, it must be named lce.key. It must be readable by user and group “lce”. The lced
process will generate an error at run time if the license is not valid. From the directory where the key was copied to initially, in this example named tenable-lce255-16-33.key, run the following commands with the appropriate key name:
# cp tenable-lce255-16-33.key /opt/lce/daemons/lce.key # cd /opt/lce/daemons
# chown lce:lce lce.key # chmod 640 lce.key # ls -l lce.key
-rw-r--- 1 lce lce 1285 May 3 15:14 lce.key # /sbin/service lce start
#
Use of a file transfer program that utilizes “secure FTP” (SFTP) or “secure copy” (SCP) via SSH to transfer the ASCII key file to the correct location (/opt/lce/daemons/) is recommended if the key originates on a remote system.
Upgrading the License
It is possible to upgrade from your silo license to one with a higher capacity (e.g., 1 TB to 10 TB). A replacement license key file will be required. To upgrade your license:
1. Stop the LCE service.
2. Replace the existing /opt/lce/daemons/lce.key with the new, upgraded license key.
3. Edit the file /opt/lce/daemons/lce.conf to change the number of silos to an appropriate number for your configuration.
4. Start the LCE service.
To verify what key is currently installed, use the grep command to examine the LCE’s log file in /opt/lce/admin/log. The line with the most recent date will indicate the maximum number of silos permitted with the license:
# grep “number of silos” /opt/lce/admin/log/2013Apr.log
Apr 26, 13 07:41 (LCE Daemon) lced - number of silos is 103 Apr 26, 13 07:41 (LCE Daemon) lced - number of silos is 512
Apr 26, 13 07:41 (LCE Daemon) lced - number of silos is 1024
The number of silos can indicate the type of license in use. For example, 103 silos indicates a 1 TB license, 512 silos indicates a 5 TB license, and 1024 silos indicates a 10 TB license, when the maximum silos for a license are used.
Configuration
The lce.conf File
The /opt/lce/daemons/lce.conf file is used to specify all LCE configuration parameters. Any changes to this file must be performed using a text editor. For changes to go into effect, either the lced process needs to be restarted or only reload the lce.conf file by using the script and commands below. This will reload the LCE configuration file and restart the ancillary LCE services without halting LCE completely.
# /opt/lce/tools/lce-reload-conf.sh # service lce_indexer restart
# service lce_query restart
# service lce_report_proxy restart # service stats restart
LCE Configuration
Unless noted otherwise, the following options are specified in the /opt/lce/daemons/lce.conf file:
Option Description
LCE Basic Configuration Options
key-file Path to the LCE’s demo or commercial key file.
database-directory Specifies the location of the LCE database directory. This can be reconfigured to make use of directories on another filesystem that may have more disk space. Ensure that the “lce” user has permissions to write and read from any directories outside of /opt/lce.
silo-size Specifies the maximum amount of data from matched log events that will be stored in one indexed file (silo). Uses an “M” extension to specify megabytes. For example, 10240M specifies the maximum silo size of 10 Gigabytes. Extensions of “G” specify gigabytes. For example, 1G specifies 1 gigabyte. By default, this is set to 10G.
Note that the filesystem must support the file size selected within this setting.
number-silos Specifies the number of silos that lced will create. The maximum number of silos that can be created is 1024 for a 10 TB license, 512 for a 5 TB license, and 103 for a 1 TB license. When configuring this setting, consider the silo-size setting and maximum disk space available for storage. Example: 1 TB is available for storage and silos
configured for 10 GB would allow for a maximum of 102 silos before disk exhaustion.
store-unnormalized-logs Enabling this option will store non-matching logs in the event database. When stored in this manner, these logs are available to be searched from SecurityCenter text search feature as an “unnormalized” event type.
server-address This option allows you to specify the network interfaces that lced will listen on. More than one interface may be specified on separate lines as in:
server-address 127.0.0.1 server-address 172.0.0.2
addresses.
public-server-address If the server is run from behind a device performing network address translation (NAT), and the LCE clients that it manages are on the public side of the device, the public-server-address field must be populated with the NAT address so that the managed clients can connect to it. The LCE Client Manager will use, in order of preference: the
public-server-address setting, the server-address setting, or the first IP that it finds LCE using that is not 127.0.0.1.
When this setting is used, all managed clients on either side of the NAT device must use this defined address to connect.
server-port This option specifies the port number that lced listens on. By default, it is set to 31300, but may be reset to another value.
client-assignment-rule If a LCE server is multi-homed or the environment has multiple LCE servers, this setting may be set to configure connecting clients from a particular network to the appropriate LCE interface or server.
syslog-listen-port LCE listens for UDP syslog traffic on the standard port of 514 by default. If the
environment requires the LCE to listen on a different port, this setting may be changed.
tcp-syslog-port This setting determines the port to listen on for reliable syslog messages via the TCP protocol.
syslog-sensors-file For logs received via syslog, a sensor name can be assigned to each IP address sending data to LCE. This sensor name will be associated with all logs from the designated source, regardless of whether or not another sensor name is extracted from the log text.
IDS LCE has the ability to receive IDS events from multiple sources. In addition to being normalized and stored in the log database, each event will be checked against any SecurityCenter vulnerability databases. If a host is vulnerable to attack, the event is marked as such, allowing rules to trigger on this scenario so that the information can be distributed to the affected administrators.
For each IDS sensor, a sensor name and type must be defined as in the example below. The supported types are Snort, Bro, RealSecure, Dragon, IntruShield, Juniper, NetScreen, NFR, Fortinet, PVS, LCE, Cisco, Sensor, and TippingPoint-SMS.
sensor-name Name to be used within the SecurityCenter logs.
sensor-type IDS sensor type. Advanced Configuration Options
log-processors This option leverages multicore processors and determines how many threads will be dedicated to log processing.
It is recommended that this setting be no higher than the number of CPU cores in the LCE host system. This is an upper-limit, and should not be changed unless you have greater than 8 total cores (e.g., a dual quad-core CPU system).
For systems with hyper-threading technology, the value may be scaled accordingly.
additional-query-memory The requests. By default, up to about 1 gigabyte of memory is used. For systems with large lce_queryd process is responsible for high-performance processing of all query amounts of available memory, the additional-query-memory option can be used to allocate additional memory for the query daemon. This will increase the number of query results that can be cached, improving response time during event analysis in SecurityCenter. The option can be specified in kilobytes, megabytes, or gigabytes by appending a “K”, “M”, or “G” to the value.
Do not set his value above 1500M on 32-bit systems.
disk-alert-percentage When enabled, the disk-alert-percentage option generates an alert when the LCE is in danger of running out of disk space to store logs. When disk usage reaches the specified percentage of capacity, a daily TASL alert will be generated.
Event Rules Specifies actions to execute in response to particular log events or other conditions. Note: This option is configured in the /opt/lce/daemons/rules.conf file. discover-hosts This option enables or disables host discovery. When set to yes, new hosts on the
network will be discovered and reported based on log data.
hosts-learning-period This option determines how many days a host has not been seen before an alert will be generated. A setting of at least 1 or 2 days is recommended. After that, any host that was not discovered during the period will be alerted on as new. Without this setting, LCE would “discover” all of your hosts that are currently running and are not really “new”.
report-frequency The frequency, in minutes, in which the report file will be generated and updated on disk. The default is 60 minutes.
report-lifetime The lifetime of a report in days. The report will be cleared after this amount of time. The default is 7 days.
reporter-user The username that SecurityCenter will use to log in and collect reports from the reporter module. This username was created when the post install script was run, but can be updated in the configuration file if necessary.
reporter-password The password that SecurityCenter will use to log in and collect reports from the reporter module. This password was created when the post install script was run, but can be updated in the configuration file if necessary.
reporter-port The port on which the reporter module will listen for requests to generate and send report files. The default port is 1243.
ssl This section lists the filenames for the server key certificate authority, and server certificate. ssl { key_file /opt/lce/reporter/ssl/serverkey.pem ca_file /opt/lce/reporter/ssl/cacert.pem cert_file /opt/lce/reporter/ssl/servercert.pem }
save-database When the maximum number of silos has been reached and an older silo must be overwritten for the next silo roll, the silo to be overwritten can first be saved for future use.
This option specifies whether or not to save the normalized database file.
If there is insufficient disk space on the silo archive device, LCE will no longer attempt to save a silo before overwriting. If this occurs, log messages will be generated warning of the event. The event alerting functionality of LCE can be leveraged to automatically notify concerned individuals (e.g., email alert) when this sort of event occurs. Please reference the section of this document titled “The rules.conf File” for more information.
save-index This option specifies if the index files are to be saved. The save-database option must be enabled for this option to be useful.
save-raw This option specifies if the lce#.raw files are to be saved. These files contain the original matched log messages before normalization.
location This option specifies the location to save the data for the previous three options. The location setting allows the silo to be saved to any mounted volume or other physical location.
auto-update-prms
auto-update-tasls The LCE. The auto-update-prmsauto-update-tasls keyword allows PRM files to be updated automatically by keyword does the same for TASL scripts. If the value
is set to “yes”, files will be updated on each silo roll, or every three days, whichever comes first. The /opt/lce/daemons/lce_update_plugins.pl script allows both PRM and TASL scripts to be updated from the command line.
proxy-address proxy-user proxy-password
Proxy address and credentials used for both manual and automatic updates of LCE plugins. accept-letters accept-numbers additional-valid-characters max-username-characters
LCE keeps track of network users on the basis of their usernames. These options set restrictions on which usernames are considered valid. Any usernames failing to match the specified criteria are disregarded and “invalid” is reported as the user for the associated log entries.
accept-letters: This is a yes/no option that specifies whether alpha characters [a-zA-Z] are allowed.
accept-numbers: This is a yes/no option that specifies whether numbers [0-9]are allowed.
max-username-characters: Specifies the maximum number of characters allowed in a username.
additional-valid-characters: Specifies which special characters are considered valid for usernames. By default, the following characters are considered valid:
The “dash” character, as in “-”
The “underscore” character, as in “_”
The “dot” character, as in “.”
The “at sign” character, as in “@”
b.j-smith@a_b.com
Only the special characters that are specified with the additional-valid-characters setting are considered to be valid.
The semicolon character, “;” is not permitted in this context.
excluded-users-file This option allows you to specify a text file that contains a list of users whose activity you do not want tracked. This is useful for application user accounts that are not used to log into the system.
trusted-plugins-file This keyword allows you to specify a text file that lists the plugins for which user tracking will be enabled.
max-memory-usage cache-results-days pre-cache-file
When a log message is defined in a plugin, LCE provides the option of specifying a hostname instead of an IP address for the srcip and dstip fields. In this case, LCE automatically attempts to resolve the provided hostname to an IP address using DNS. Since the same hostname is typically encountered multiple times, caching the results of lookups can greatly increase performance. These options configure DNS caching in LCE. The max-memory-usage option can go up to 360K domain names. The
cache-results-days option specifies the number of days to cache a hostname-to-IP mapping before updating the result with a new lookup.
Hosts listed in the pre-cache-file are looked up and stored when LCE starts. The format for the file is one hostname per line, a line of hostnames separated by a space, or a combination of the two formats.
For example: tenablesecurity.com
tenable.com blog.tenable.com www.tenable.com nessus.org
excluded-domain-name
excluded-domains-file A particular hostname or all domain names with a certain extension can be excluded using the exclude-domain-name option. In this case, the matching hosts are looked up at every occurrence. The excluded-domains-file option can be used to maintain a more extensive list of domains to exclude by directing LCE to read the list of domains from a file. The file is read when LCE starts up; therefore, changes to the list will not be read until LCE is restarted.
lce-load-balance-status-port When the LCE server is configured to offload log data to auxiliary servers, TCP port 31302 is the default port used. Uncomment and change the setting here to change the port on which the LCE server communicates.
primary-lce-address When used as an auxiliary LCE server, this setting designates the IP address and port of the primary LCE server in the format of ipaddress:port on which it listens for status data. The port setting is optional when the primary is using the default of port 31302.
lce-load-balance-local-addr When there is more than one network interface available to receive data from the primary LCE, enter the IP address of the interface to use. Otherwise, the default interface’s IP address will be used. This can be used to balance bandwidth between multiple interfaces.
mirror-mode Optionally, instead of receiving a subset of logs, this LCE may register itself as a mirror and receive ALL logs processed by the primary LCE, effectively creating a live backup of the primary database. To enable this mode, uncomment this line.
virtual-ip-address This is the IP address used by devices such as syslog sensors and clients to send data to LCE.
virtual-ip-interface When specifying a virtual-ip-address, also specify an existing network adapter on which the LCE will bind the virtual IP defaults to eth0.
virtual-router-id If you have a VRRP solution deployed or plan on adding one in the future to the same network your LCE is deployed on, use this option to specify a router ID for the LCE cluster, that differs from your other VRRP setup.
load-balance-key When load balancing between primary and auxiliary LCE servers, all messages are encrypted. To enhance security, a user-specified key may be added. Uncomment the option and enter a 32 character encryption phrase.
Allowed characters are alphanumeric and the following characters: [].^$()|*+?{}/#_-~!@%=`'<>:|&\",
forward-syslog This option allows you to specify one or more syslog servers to which events are forwarded.
The format of the option is “forward-syslog IP:port,exclude_header”. If no port is included, UDP 514 is assumed. The exclude_header option determines if the LCE header is included on the syslog record that is forwarded. When set to “1”, only the original log is forwarded without any information that it was forwarded from the LCE server. The default is to include the LCE header when forwarding logs.
If you have more than one syslog server, specify each on as separate line as follows: forward-syslog 192.168.10.10
forward-syslog 192.168.10.50:1234,0 forward-syslog 192.168.20.30:514,1 This option is turned off by default.
checksum-forward Each time the active silo changes, an MD5 checksum is generated for the previous silo. This allows the integrity of the .raw and .db data files to be checked at a later time. This option allows the MD5 checksums to be forwarded to one or more off-site locations. You may specify multiple addresses to forward checksum data on separate lines as shown:
checksum-forward 192.168.10.10 checksum-forward 192.168.20.30
A new event is logged whenever a set of MD5 silo checksums is calculated. The event has type “lce” and name “silo-MD5-checksums”. The same message is also logged to the save-all file.
max-tasl-queue-memory To maximize performance on multi-processor and multi-core systems, correlated TASL events are processed in parallel to receive regular incoming events. Since some TASL scripts can run for an extended period of time, the primary event processor can potentially receive many TASL-triggering events while a TASL script is still being executed. In this case, the TASL job is stored in a queue for later processing. This
option defines the maximum size of this queue. On systems with extremely large volumes of data, setting the maximum queue size higher results in increased
performance. If a TASL script that can be sampled is triggered while the queue is full, its callback functions will not be executed.
sampleable-tasls-file This option allows you to specify a file listing the filenames of TASL scripts that can be ignored when the system is busy and the processing queue has reached the specified maximum amount of memory.
plugins-directory Specifies the directory where active PRM files are stored.
correlation-scripts-directory Specifies the directory where TASL scripts are stored.
log-directory Specifies the location of where the ISO compliant LCE log files will be created.
pid-file When the lced process starts, it will store its process ID file in the file specified here.
die-file While the lced process is running, it will periodically check for the existence of this file. If it is found, a graceful exit will be performed.
report-directory This setting specifies the full path to the directory that stores reports.
add-delimiter The setting is to allow non-standard frame delimiters for logs received via reliable syslog. By default, only the linefeed character is recognized. Others may be specified with the proper ASCII decimal value (0-255). To use multiple delimiters, enter each on a separate line.
port-restricted-ids-correlation IDS events are correlated with vulnerabilities based on matching the event’s IP address, port, protocol, and ID. Ports 0, 22, and 445 are common for client-side applications. LCE does not require those three ports to match for correlation. Enabling this option will cause the specified ports to be considered for correlation.
override-sensor-name The sensor name can be set by the source of the log, the configured sensor name of the client or syslog source, or the plugin that normalizes the log. If this option is enabled, the sensor name will always be that of the configured client or syslog source.
auto-authorize-clients-time LCE Clients version 4 and greater must be authorized by the LCE administrator to send data after the client attempts to connect to the LCE server. Enable this option to automate authorization for a specified number of minutes after LCE server startup or reconfiguration. This automatically authorizes clients that have never previously tried to connect to the LCE server for 10 minutes after startup.
Debugging Options
save-nonmatched If this keyword is enabled, LCE will create a file named notmatched.txt in the database directory and fill it with log events that have not matched any LCE plugin. This is an excellent way to analyze events that may be inadvertently ignored. There is a hardcoded limit of 2 GB for this option in addition to the number of events specified.
save-all Specifics a log file where all events (not just the ones matched with a LCE plugin) are stored. This log file does not rotate and must be managed by the logrotate process. Note that this will require significantly more disk space than just keeping the events that match plugin criteria. This option is most useful when used in conjunction with
With the store-unnormalized-logs option introduced in LCE 4.2, the save-all option is only useful if a text version of all incoming logs is desired.
debug block Uncomment this section for additional logging generated by the lced process.
WARNING - the debug logic is extremely verbose and several Tenable customers have created log files greater than 4 GB. These logs are purely for diagnostic purposes. It is recommended to only use this debug mode when directed by Tenable support.
client block This block of keywords specifies credential information for a LCE client. Clients may be configured as a single IP address, a CIDR range, ranges in the third and fourth octet of an IP address, or a range specified by the start and end IP addresses. This option is not exposed in the configuration file by default.
This option is only for clients prior to version 4.0 connecting to LCE Server 4.0 and newer. Newer clients are managed using the LCE Client Manager. For more information about the configuration, see the section of the document titled “Adding Log Correlation Engine Client Information”.
Statistics Daemon Configuration Options (stats_options)
event-directory Directory containing the LCE events.txt file.
log-directory Log files are named according to date and stored in the specified directory.
syslog-alert The stats daemon will generate syslog messages to one or more recipients. By default, a local address of 127.0.0.1 is used to send messages to the lced services. However, more than one syslog server can be configured on separate lines in the following format:
syslog-alert 127.0.0.1 syslog-alert 192.168.10.10
stddev-threshold This keyword specifies the minimum standard deviation that must occur for an event before an alert will be generated for it. The higher this number, the more statistically significant a sequence of events needs to be before an alert is raised.
stddev-unit-threshold If an event occurs more or less than 5.0 standard deviation units, an alert will be generated. Setting this value higher will cut down on any sequence of events that occur close to the standard deviation.
iteration-threshold This keyword specifies the number of iterations (days) per-event are required before alerts will be generated. If a large amount of LCE data is already present, set this number to a low value or even to zero. The stats daemon can be started to read in all or just part of the existing LCE data. If you have NO LCE data, leave this value around 7 so the stats daemon will not alert on anything until it has 7 days of event data.
nhits-frequency-threshold If an event occurs less than 10% of the time then an alert will be generated. Even if an event may be statistically significant, that sequence of events may also occur periodically. For example, 50% of the time you are within a standard deviation, however, occasionally (the other 50%) you have outliers 2 and 3 standard deviations away. Those outliers may be the cause of 90% of the alerts generated in this case. Setting this value to 10, 20, or other values would only alert for hours that were both out of the allotted standard deviation, and also are event counts that have not occurred before. Network Range
include-networks
Make sure this range matches IP addresses that are considered
“internal” from an event perspective. Starting with LCE 3.6.1, this range is used by a number of TASL scripts and the Stats daemon to define inbound/outbound/internal specifications for LCE events. Prior to 3.6.1, these ranges were solely used by the Stats daemon.
This is different from the “Directions” filter on the SecurityCenter 4 events page, which uses the logged-in user’s managed ranges to determine event direction.
The following sections define your internal network range. All networks specified in the first section are included, while the exclude-networks block is used to make exceptions.
exclude-networks Provides exceptions to the “include-networks” directive ranges specified above.
Pointing to a New “Plugins” Directory
To reconfigure the LCE to use only a sub-set of the plugins it is shipped with, create a new directory in the
/opt/lce/daemons directory. For example, we can create an active-plugins directory. The plugins-directory
keyword in the lce.conf file will need to point to this new directory as shown below: plugins-directory /opt/lce/active-plugins/
The desired plugins must be manually copied into this new directory and then the lced process restarted.
Adding Log Correlation Engine Client Information
This option is only valid for LCE clients prior to version 4.0 connecting to LCE Server 4.0 and newer. Newer clients are managed using the LCE Client Manager. See the LCE 4 Client Guide for details, available from the Tenable Support portal.
To configure a LCE client, add the IP address it will be connecting from and a secret key it will be using to connect with. The shared secret key may contain any ASCII character except a semicolon (;) or space ( ).
The LCE only supports one type of remote authentication that is based on the shared secret.
All client designations are specified inside the lce_options section of the lce.conf file. The following example shows an LCE client connecting in from different individual IP addresses with different shared keys:
client 192.168.3.7 {
client-auth auth-secret-key s3kret }
client 192.168.2.1 {
client-auth auth-secret-key myp455word }
Multiple clients can be added using a variety of methods. The client directive supports a single IP address, an IP address range (e.g., 10.0.0.1-10.0.0.255 or 10.0.0.1-255) and the use of CIDR notation (e.g., 172.20.1.1/26). The following examples show an IP range and a CIDR address block used to define the client addresses. Each example also shows how to define multiple secret keys, any of which may be used when configuring the clients for connecting to the LCE server from the included IP address range.
client 192.168.16.1-192.168.16.5 { client-auth auth-secret-key s3kret client-auth auth-secret-key s3kr3tpa$$ }
client 172.20.101.190/26 {
client-auth auth-secret-key s3kret client-auth auth-secret-key t0ps3kr3t }
The client directive can be configured with an optional sensor-name field. This field defines a default sensor name to be reported for logs from particular clients that do not provide a sensor name to their associated plugin rule. An example of this designation is shown below:
client 172.20.1.1 {
client-auth auth-secret-key tenable sensor-name TNS2012
}
To view a sample of the version 3.x LCE Clients configuration, see the version 3.x Clients Configuration section in the lce.conf.v3_clients file located in the /opt/lce/admin directory of your LCE server.
Debug Mode
The lce.conf file can also include a variety of debug information. Information about plugins loaded, LCE client status, and operation are all written to the current log file. To place the LCE into debug mode, uncomment the following section of the lce.conf file:
debug { lce-api { client-auth packets-event packets-all } matches {
match-success match-failure match-applied } silo { silo-switch silo-addition } match-tree { tree-construction tree-matches } load-balancing { status-msg data-msg connections high-availability } }
The lce-api keyword logs all remote client authentication attempts. Enabling this can be helpful when diagnosing remote agent problems. The matches and match-tree keywords detail how a message is analyzed by the existing plugins. This is a good way to diagnose if a particular plugin is not matching. Lastly, the silo debug keyword logs when a silo is rotated and indexed.
Enabling these debug messages is a great way to learn how the LCE operates, however, they generate a lot of information and can create multi-gigabyte log files.
If the lced daemon terminates abnormally for any reason, the system will automatically restart the daemon and add a warning to the LCE logs.
Correlation Statistics
Runtime statistics pertaining to logging and correlation are collected including:
Logs/bytes per second
Number/percentage of logs matched/unmatched
Number of events correlating with vulnerabilities
Number/percentage of logs from clients, syslog, and IDS
Number of TASL alerts generated
This information is logged once per hour and is written both to the application log and to the normalized database under the event name “LCE-Server_Statistics” (type “lce”).
Example Correlation Statistics Output:
An average of 50 logs are being received each second. A total of 5,778 logs (521,046 bytes) have been received.
2,232 logs have been matched by plugins (38.63%). 3,546 logs did not match (61.37%). Log source breakdown: 5,774 from clients (99.93%), 2 via syslog (0.07%), 0 from IDS
devices (0.00%).
No log events have correlated with vulnerabilities. 2 TASL alerts have been generated.
Utilizing Tiered LCEs
Beginning with LCE 4.0, multiple LCEs may be configured in a tiered system. This allows for one LCE to be designated as the primary LCE, which can send incoming log messages to one or more auxiliary LCE servers (depending on load requirements, which are automatically calculated on a regular interval). This distributes the storage and processing of the log messages among up to 256 different LCE servers. Taking advantage of this configuration allows for all the LCE clients and log sources to be configured for a single LCE server, and that primary LCE server load balances the incoming requests between itself and its auxiliary servers. Additionally, clients may be configured to send their logs directly to an auxiliary server, bypassing the primary LCE if there is a need to do so. One example would be if you want all firewall logs to go to a specific LCE for storage, then they would have their logs point to that specific LCE, bypassing the primary LCE. Load balancing messages and logs sent between the primary and auxiliary LCEs are encrypted. To provide additional encryption, the load-balance-key option may be configured. This option can use a phrase between 1-32 characters. When set, all of the connected LCEs must be configured with the same passphrase in their lce.conf files.
When using tiered LCE servers, each one must be configured in SecurityCenter in order to be queried. If SecurityCenter user only has access to three out of four LCE servers in a group, that user will receive incomplete results based only on the data stored in the three LCE servers to which the user has access.
Configuring the Primary LCE Server
The primary LCE server listens on TCP port 31302 (by default) for status data from auxiliary LCE servers. The listening port of the primary LCE server may be changed by modifying the lce-load-balance-status-port option in the
lce.conf file. There may only be one primary LCE server configured in a group, and servers may not play a dual role of primary and auxiliary. Unless the server is specifically configured to be an auxiliary LCE server, it considers itself a primary LCE server and listens on port 31302 (by default).
Configuring the Auxiliary LCE Server
When configured as an auxiliary LCE, the server will accept log files sent to it by the primary. To enable the auxiliary mode, configure the primary-lce-address setting in the lce.conf file with the IP address and port number of the primary LCE. If the primary LCE is running on the default of 31302, adding the port number is not required. Append the IP address with a colon (:) and the port number, such as 192.168.1.20:65444 if the primary LCE server is listening on the alternate port of 65444.
Note that when utilizing tiered LCE servers, processing of log-related options such as syslog forwarding, storing not-matched logs, and similar are performed on the server processing the logs. Such options must be configured identically on all the LCE servers for consistent results.
Syslog Considerations
Sending Syslog Messages to Other Hosts
The LCE can be the focal point of your entire log aggregation strategy. If a Storage Area Network, syslog server, or some other type of log aggregation solution is deployed in your network, the LCE can be configured to send a copy of any received message to one or more syslog servers. These messages include any message received from any client. To configure the LCE to forward these messages, simply enter a line for each syslog server in the lce.conf file with the
forward-syslog keyword. The actual syslog service is not used to forward the messages. All packet generation is handled by the lced process.
The format of the forward-syslog option is IP:port,exclude-header. The IP is the address of the syslog server to which the messages are sent. The port indicates the UDP port in which the receiving syslog server is listening. If this is
not declared, the default UDP port of 514 is used. The exclude-header option determines if the LCE appends a custom header to indicate if the messages are sent from the LCE server or not. When omitted or set to “0”, the header is
appended. When set to “1”, the header is not added and only the original log message is sent without indication that it was forwarded from the LCE server.
The following is an example section of the lce.conf that forwards messages to multiple syslog servers. The first line forwards to UDP port 514 and appends a LCE server header to each entry. The second forwards to UDP port 1234, and appends a LCE server header to each entry. The third forwards to UDP port 514 and strips the LCE server header, sending the original logs to the syslog server.
forward-syslog 192.168.10.10
forward-syslog 192.168.10.50:1234,0 forward-syslog 192.168.20.30:514,1
syslog Compliant Messages
Logs forwarded by the LCE will retain the original syslog alert level and facility, if one was present. If one was not present, the LCE assigns a log level of “auth.warning”.
Typically, LCE clients do not send syslog compliant messages. If a LCE client were configured to monitor a log file that retained an original message’s syslog alert level and facility, then this would be retained if forwarded by the LCE. This allows for a remote syslog server that is receiving events from the LCE to process the received messages and place them in specific files. Depending on the type of syslog server, it may be possible to place logs from a router into one file, operating system logs into another and so on.
Content of Forwarded syslog Messages
When the LCE forwards a message, it also adds any matched information to the log file as shown below if configured to do so:
Jun 30 17:45:36 lce: [not-matched] 0.0.0.0:0 -> 172.20.1.1:0 ::
<37>sshd(pam_unix)[15322]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=172.20.1.1
The “::” characters are used to separate LCE’s heading from the original message. In this case, the message would also have been sent with a syslog facility of <37> since that was the facility of the original message.
Additionally, notice that the LCE tagged the example event above with a not-matched keyword. This means that the LCE did not possess a .prm file to process the log. If it did, the matched event name would be present in the same location. If configured to strip the LCE headers from the forwarded syslog messages, only the original log message is sent to the remote syslog server.
Storing All Logs with “save-all”
Many organizations have regulatory requirements to save all of their log data for 30 days or some other length of time. It may also be part of that requirement that the data not be manipulated, normalized, or otherwise processed in case it must be used in a legal proceeding. Any exculpatory evidence in the original logs must not be missing as well.
The LCE’s method of storing data in silos for high-speed normalization and analysis by many different administrators is not the best place to keep one central log file. The LCE has means to save every message, even ones that do not match a certain plugin to a central log file.
This log file is saved with the save-all keyword in the lce.conf configuration file. The save-all keyword merely specifies the path and output directory of a given log file. It defaults to the location of /opt/lce/db/lce.log which is in the same directory as the silos.
As the LCE daemon receives events through the API or from syslog, it will save the message into the file specified by the save-all keyword. This log file will grow very large. Maintain rotation and compression of these logs with the
logrotate program that is already installed on all Linux systems supported by the LCE.
Different File System
Since the lce.log file will grow to extremely large sizes, it is highly recommended to place this file on a different physical file system. If the LCE server is placed on a system with two hard drives, consider creating physically separate partitions for both the LCE silo data and the lce.log files.
If your network has use of a Storage Area Network (SAN), consider using this to store the lce.log file. Many times, these storage devices can be mounted through a network file system (NFS) or Windows file share (SMB) resource. Make sure that write permissions from the LCE server are available and there is sufficient network bandwidth to send the data, if you use a SAN.
Multiple Plugin Matches per Log File “multiple-matches”
By default, the LCE daemon will stop processing a log file as soon as one match has been made. This behavior may be overridden by adding the multiple-matches keyword in the lce.conf file. With this feature enabled, the LCE daemon will attempt to exercise the entire plugin set across every log message. This behavior is useful for extracting multiple forms of information out of a log file. For example, there may be a plugin that looks for a generic user login failure and another that looks for a login failure for user “root”. Without the multiple-matches keyword, only one of the plugins will match, even though both are valid.
Even more so than with normal LCE operation, be sure to remove unneeded libraries with the multiple-matches keyword enabled, otherwise, the LCE’s performance can be diminished.
Quick Example
Tenable implemented this feature when a customer was encountered who had a firewall log with NAT addresses. For each transaction, the firewall logged the external Internet address, the customer’s Internet address and their internal RFC1918 address. What they wanted was the ability to type in any of the IP addresses in question to produce a report of the history. For example, a student may receive 192.168.20.10 via DHCP inside a high school. The school’s public IP address at the firewall may be 64.64.64.64 and the student may have been attacking a web site at 99.99.99.99.
These “public” addresses were chosen at random and are in no way intended to be example organizations or potential targets. We did not want to use RFC1918 addresses as example external addresses.
For any network browsing, a firewall log may have all three IP addresses. Without the multiple-match keyword, there is only one pair of IP addresses that can be matched on. However, with it enabled, two rules can be used to process the same log file and extract the specific IP addresses.
In the customer’s case, they decided to log “external to public IP” and “public IP to internal IP” firewall logs. They generated two LCE events for each firewall log event. However, when they added in the DHCP logs, they were able to use the IP address of a potential attacked target to get the actual internal IP address and MAC address. When someone outside of their network contacted them and complained of a spammer, worm, or malicious activity, they were able to type in the IP address of the target, see which public IP was in use at the time, and then see which internal IP addresses were related.
The rules.conf File
The rules.conf file, like lce.conf, is located in the /opt/lce/daemons directory and is used to configure active response operations used by the LCE daemon. LCE rules are configured to analyze LCE event content and fire if preset conditions are met. Active responses include the ability to send automatic emails (sendemail), syslog alerts
Email Syntax
sendemail -subject "$Name" -body "$Log" -to "[email protected],[email protected]"
Syslog Syntax
sendsyslog 172.20.1.1 -message "$Log"
Custom Command Syntax
my_custom_firewall_reconfig_command -block $sip
LCE Rule Filters
The following fields are optional filters. A plus sign signifies that events matching the specified values will receive rule application, while a minus sign signifies that matching events will not. If no “+” filter is used, all events are matched by default for the field, unless excluded specifically with the “-” filter. Multiple values can be specified for any filter.
Do not use spaces to precede LCE rules. If there is a space at the beginning of an option, that option will be ignored.
Option Description
IPS This filter allows for the search of IP addresses that are or are not present as either source or destination. The following five formats are supported for both +IPS and -IPS:
172.16.1.1/255.255.255.0
172.16.1.1/32
172.16.1.1-255
172.16.1.1-172.16.1.255
172.16.1.1
SrcIPS This filter will search for source IP addresses that are or are not present. The following five formats are supported for both +SrcIPS and –SrcIPS:
172.16.1.1/255.255.255.0
172.16.1.1/32
172.16.1.1-255
172.16.1.1-172.16.1.255
172.16.1.1
DstIPS This filter will search for destination IP addresses that are or are not present. The following five formats are supported for both +DstIPS and –DstIPS:
172.16.1.1/255.255.255.0
172.16.1.1/32
172.16.1.1-255
172.16.1.1-172.16.1.255
172.16.1.1
Events Considers both the primary and secondary event names. The “Events” field allows spaces in event names (because Nessus IDS signatures contain spaces), and thus events must only be separated by commas and not spaces. Spaces, commas or both may be used to separate entries in the other fields.
