lce_options {
# Do not modify the "Quick-install" area prior to installation! # Quick-install customizations
# End of quick-install customizations
# <--- Basic Configuration Options ---> # <--- License Key Location --->
key-file /opt/lce/daemons/lce.key
# <--- Active Data Storage --->
# The database-directory partition should contain enough free disk # space to store the specified amount of active data.
database-directory /opt/lce/db/
# The silo-size variable specifies the maximum amount of # data from matched log events that will be stored in one # indexed file. This may be set to at most 10GB. The option # must be specified in kilobytes, megabytes, or gigabytes # by appending a 'K', 'M', or 'G' to the value. For example, # 512M indicates a 512 megabyte maximum silo size.
# The 'number-silos' variable specifies the number of silos. # With a silo-size of 1G and number-silos set to 3, the
# system would use a maximum of 3 gigabytes of total storage. silo-size 10G
# The 10 terabyte, 5 terabyte, and 1 terabyte LCE licenses support # a maximum of 1024, 512, and 103 silos, respectively. The 250GB # license supports a maximum of 25 silos.
number-silos 1024
# The next setting provides the option of storing non-matching logs in # the event database. When enabled, these events will appear in
# SecurityCenter under the "unnormalized" event type. Opting to store # the logs in this manner will make them available for text searches, # but will require additional disk space.
store-unnormalized-logs yes
# <--- Network Setup --->
# The next section determines the interfaces on # which LCE will listen for both syslog messages and # connection requests from clients. For each address
# specified, LCE will utilize the corresponding interface. # If this option is used, all clients must be configured # to connect to one of the addresses below. If no addresses # are specified, LCE will listen on all available interfaces. # server-address 127.0.0.1
# If the server is run from behind a device performing # network address translation as it will be seen from # the clients, then the public-server-address field
# must be populated with the address to which the clients # should attempt to connect.
# public-server-address 127.0.0.1
# The server-port option allows specification of a port # number on which LCE will listen for connection requests # from clients. The clients must be configured to connect # to the port indicated below.
# server-port 31300
# If your LCE server is multi-homed or you wish to
# have more control over the destination IP that LCE 4.x # clients will be assigned when they first connect to this # server, then you may specify rules here to override # the other server assignment logic.
# When new clients first connect, the LCE server will search # this list, and assign the designated LCE server IP or hostname # to the client automatically.
# Client ranges may be specified as IP/cidr or IP/netmask. # Server assignments may be IP:port or hostname:port, where # the port is optional and defaults to the port specified in # server-port above.
#
# For example, this assigns all 203.0.113.x clients to a server named # My_LCE_Server, on port 5000:
# client-assignment-rule 203.0.113.0/24 My_LCE_Server:5000
# <--- Syslog Configuration --->
# The syslog-listen-port option allows the user to # specify a non-default UDP syslog port. Normally this # is port 514, and if it is not specified, LCE will # default to listen on port 514 for each server-address # interface specified above.
# syslog-listen-port 514
# The following option allows specification of the port # number on which to accept reliable syslog messages. # tcp-syslog-port 601
# 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.
syslog-sensors-file /opt/lce/admin/syslog_sensors.txt
# <--- IDS Configuration --->
# The Log Correlation Engine 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 Security Center # 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, IntruVert, IntruShield, Juniper, NetScreen, NFR, Fortinet, # PVS, LCE, Cisco, TippingPoint-Sensor, and TippingPoint-SMS.
# IDS 192.168.1.2 {
# sensor-name Corporate_Snort # sensor-type Snort
# }
# <--- Advanced Configuration Options ---> # <--- CPU, Memory, and Disk Utilization --->
# The Log Correlation Engine is capable of leveraging multiple # processor cores in order to process a number of incoming logs # in parallel, yielding higher throughput. The following setting # limits how many threads will be dedicated to log processing. # For maximum perfomance, this should generally be set to or above # the total number of CPU cores available on your system. For systems # utilizing hyper-threading technology, the value can be scaled
# accordingly. log-processors 8
# The lce_queryd process is responsible for high-performance processing # of all query requests. By default, up to about 1 gigabyte of memory # is used. For systems with large amounts of available memory, the # following 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.
# Note that this value should never be set above 1500M on 32-bit # systems.
# additional-query-memory 1G
# The following option allows an alert to be generated when LCE becomes # in danger of running out of disk space to store logs. When disk usage # reaches the specified percentage of capacity, the LCE-High_Disk_Usage # event will be added.
disk-alert-percentage 75
# <--- Event Rules --->
# To specify actions to execute in response to particular log events # or other conditions, edit /opt/lce/daemons/rules.conf.
# <--- Data Archiving --->
# 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. The following options # determine whether the database, index and original log text are # saved. Valid options for each setting are "yes" and "no". The # location setting allows the silo to be saved to any mounted volume # or other physical location.
# Saving the database alone is sufficient to allow most queries on the # archived data. Retaining the original log text in addition will
# permit the use of the Raw Syslog tool. Saving the index will allow # queries on archived data to execute much faster, but consume # additional storage space.
# save-database yes # save-index yes # save-raw yes
# location /opt/lce/silo_archive/
# <--- Automatic Updates & Proxy Settings --->
# The 'auto-update-prms' keyword allows PRM files to be automatically # updated. When enabled, LCE will update the installed PRM files with # the latest versions from Tenable, as well as download any newly # published plugins. Both this and the TASL update are launched # whenever a silo rolls, or every 3 days, whichever occurs first. auto-update-prms yes
# The 'auto-update-tasls' keyword allows TASL scripts to be # automatically updated. When enabled, any TASL scripts currently # installed will be updated with the latest versions from Tenable. To # ensure that only desired TASL scripts are used, newly available # scripts will not be installed. These can be obtained manually, or # with the /opt/lce/daemons/lce_update_plugins.pl script.
auto-update-tasls yes
# The following options configure both the automatic and manual update # processes to use a web proxy server when downloading files from
# Tenable. When these values are commented out, proxy use is disabled. # proxy-address 192.168.10.10
# proxy-user username # proxy-password password
# <--- Username Management --->
# The Log Correlation Engine keeps track of network users on the basis # of their usernames. The following section sets restrictions on which # usernames are considered valid. Any usernames failing to match the # below criteria are disregarded, and "invalid" is reported as the user # for their associated logs.
accept-letters yes accept-numbers yes
additional-valid-characters -_.@ max-username-characters 20
# The following setting defines a list of usernames whose IP addresses # are not tracked. These usernames will appear with their associated # logs, but LCE will not generate alerts when the users with a matching # name switch to a new IP address.
excluded-users-file /opt/lce/admin/untracked_usernames.txt
# In order to apply user tracking only to appropriate logs, a list of # trusted plugins is provided in the following file. If a plugin is not # on this list, any specified username will appear with the associated
# log if it matches the above criteria, but otherwise will not be # tracked. Each plugin is specified in the file by its plugin ID. trusted-plugins-file /opt/lce/admin/trusted_plugins.txt
# <--- DNS Caching --->
# 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. The following section # configures DNS caching in LCE. The cache-results-days option # specifies the number of days for which 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. 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.
max-memory-usage 100M cache-results-days 10 pre-cache-file /opt/lce/admin/hostlist.txt excluded-domains-file /opt/lce/admin/excluded_domains.txt # excluded-domain-name .edu # excluded-domain-name tenablesecurity.com # <--- Load Balancing --->
# The following section allows users to offload log data that this LCE # receives to other LCE servers. This can be done manually, but using # this mechanism ensures the best steady-state load balancing and # simplifies configuration because all clients may be specified in the # primary LCE. Auxiliary LCEs only need to know how to connect to the # primary LCE. To set this LCE as an auxiliary LCE, read further. LCE # servers may only be primary or auxiliary, but not both.
# It is acceptable to leave this commented if this is the primary LCE; # the default lce-load-balance-status-port is 31302.
#
# This port is the local listen port for status data from auxiliary # LCEs.
# lce-load-balance-status-port 31302
# To specify that this LCE is an auxiliary LCE to which logs should be # forwarded, uncomment this line. This specifies the primary LCE IP
# or hostname, followed by a colon and the port on which it listens for # status data. If the port is unspecified, the status port defaults to # 31302 (same as the example). If you specified
# lce-load-balance-status-port 31302 in your primary LCE, and your # primary LCE is on 192.168.1.20, then you will specify here: # primary-lce-address 192.168.1.20:31302
# To specify a local interface for receiving data from the primary LCE, # enter an IP address below. Otherwise, the default will be selected. # This can be used to balance bandwidth between separate interfaces,
# lce-load-balance-local-addr 192.168.1.19
# Load balancing messages between Primary / Aux LCEs are encrypted. # To provide additional encryption, a user-specified key may be
# added to the built-in encryption. The key should be between 1 and 32 # ASCII characters, and must be the same for all Primary / Aux LCEs # in the server pool. To use the additional key (strongly recommended), # uncomment the following line and replace p@ssw0rd_eXampl3 with your
# desired 1-32 character encryption phrase.
# Allowed characters are alphanumerics and the following characters: # [].^$()|*+?{}/#_-~!@%=`'<>:|&\",
# load-balance-key p@ssw0rd_eXampl3
# <--- Data Forwarding --->
# One IP address/port may be specified per forward-syslog keyword # which will forward any log event regardless of method
# (OPSEC, log file, syslog, windows events, etc.) to a syslog # server. LCE forwards each event to multiple syslog servers # when multiple lines with the forward-syslog keyword are # included.
#
# The forward-syslog format should be: # forward-syslog IP:port,exclude_header
# Exclude_header is optional and defaults to 0. If changed to a 1, the # LCE header will NOT be prepended to logs that are forwarded - only # the original log is forwarded and the receiver will not be able to # identify that it came from LCE.
#
# forward-syslog 192.168.10.16 # port defaults to 514
# forward-syslog 192.168.20.12:27691,1 # custom port without header # Each time the active silo changes, an MD5 checksum is generated for # the previous silo. This allows the intgerity of the .ndb data files # to be checked at a later time. The following section allows the MD5 # checksums to be forwarded to one or more off-site locations. The IP # address list may include any syslog servers.
# checksum-forward 192.168.10.10 # checksum-forward 192.168.13.63
# <--- TASL Performance --->
# In order to maximize performance on multi-processor and multi-core # systems, correlated TASL events are processed in parallel to the # receiving of 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. The following 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 designated as being sampleable is # triggered while the queue is full, its callback functions will not # be executed.
# The following file contains the filenames of TASL scripts that are # designated as being sampleable, which results in the behavior
# described above.
sampleable-tasls-file /opt/lce/admin/sampleable_tasls.txt
# <--- File & Directory Settings ---> plugins-directory /opt/lce/daemons/plugins/ correlation-scripts-directory /opt/lce/daemons/plugins/ log-directory /opt/lce/admin/log/ pid-file /opt/lce/daemons/lced.pid die-file /opt/lce/daemons/lced.die # <--- Miscellaneous Options --->
# The below keyword can be used to specify non-standard frame # delimiters for logs received via TCP syslog. This
# option can be used with certain products such as NetScreen # that utilize a special delimiter. By default, only the # industry-standard linefeed character is recognized. Other # delimiters must be specified with the corresponding ASCII # decimal value (0-255).
# add-delimiter 0
# In general, IDS events are correlated with vulnerabilities based on a # match between the event's IP address, port, protocol, and ID. The # vulnerability port is usually 0, 22, or 445 for client-side
# applications and credentialed audits. Since these may refer to # client side, web server, or other vulnerabilities, by default, LCE # does not require those three ports to match for correlation. When # the following option is enabled, the vulnerability port will always # be considered.
# port-restricted-ids-correlation
# <--- Debugging Options ---> # As events are sent to LCE, if a signature does not exist # for the log event, the data from the log will be stored in # a file named 'notmatched.txt' in the configured database # directory. The maximum number of log entries that will be # stored in the file is specified by the 'save-nonmatched' # variable below. In addition, there is a hard file size # limit of 2GB. If either the specified entry limit or the # 2GB file size limit is exceeded, notmatched.txt will be # deleted and opened again to store subsequent new events. # The save-nonmatched option is useful for seeing what kinds # of events are not being matched by the LCE plugins.
# save-nonmatched 20000
# The 'save-all' keyword allows all log events to be stored in a # specific file. When used with the 'logrotate' facility and storing # this file on a different physical file system, or possibly a
# by LCE. The 'save-all' keyword specifies the location of this # file. Any event sent to LCE or collected by an agent will be
# stored in the file specified. Please consult the LCE documentation # for advice on configuring the 'logrotate' facility to store data for # a specific length of time, specific size of data, or to simply create # rotating log files.
# save-all /opt/lce/db/lce.log
# The following section should be completely uncommented 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 diagnostics.
# # debug { # lce-api { # client-auth # } # # matches { # match-success # } # # silo { # silo-switch # } # # match-tree { # tree-matches # } # } } stats_options {
# Quick-install stats customizations
# End of quick-install stats customizations # Directory containing the LCE events.txt file event-directory /opt/lce/db/
# Log files are named according to date and stored in # the following directory
log-directory /opt/lce/admin/log/stats/ # Syslog alerting
# 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.
syslog-alert 127.0.0.1
# The minimum standard deviation that must occur for an event # before we'll alert on it. The higher this number, the more # statistically significant a sequence of events needs to be # before an alert is raised.
# If an event occurs more/less than 5.0 standard deviation units # then we'll alert. Setting this value higher, will cut down on
# any sequence of events which occur close to the standard deviation. stddev-unit-threshold 5.0
# The number of iterations (days) per-event required before # we'll start alerting for an event. If a large amount of LCE # data is already present, this number should be set low 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,