General settings¶
Experimental features¶
There are currently no experimental features available in Corelight-update.
exp_features: false
Auto-updating policy settings¶
You can configure Corelight-update to automatically update a policy using a pre-selected configuration file name, and directory path. When auto_updating_policies
is enabled, Corelight-update monitors the directory path /etc/corelight-update/configs/<policy_name>/
for a file as defined in filename
.
On each service interval, Corelight-update checks each path for a policy configuration file, and applies that configuration to the policy. This setting is enabled by default.
auto_update_policies: enable: true filename: db-config.yaml
Note
When auto_updating_policies
is enabled, a configuration file matching the filename setting is required in each policy directory: /etc/corelight-update/configs/<policy_name>/
This filename
setting is also used to monitor the global configuration at /etc/corelight-update/global/<filename>
. If the filename is changed here, the next service interval, or when Corelight-update is executed interactively, the global config file will be created with the contents of the current global configuration.
Note
The global configuration will automatically be updated at the beginning of each service interval, or when Corelight-update is executed interactively. Auto-updating the global config cannot be disabled.
Pushing content to sensors in parallel¶
By default, Corelight-update will deploy content updates to the sensors concurrently. Corelight-update will open a connection to multiple sensors in a policy, push updated content, and cycle to the next sensor, up to the parallel_push_limit
setting.
Content updates are performed in a specified order. To review the order of operations, see Push content for policies. The default for parallel_push_limit
is 10 sensors.
parallel_push_limit: 10
Global-level data sources¶
Corelight-update supports applying a limited selection of data sources at the Global level.
GeoIP database¶
Enables downloading of the Maxmind GeoIP database. The default interval is 1 week.
geoip: enable_maxmind: false interval_hours: 168 account_id: 0 license_key: "" database_directory: "/var/corelight-update/files/all/geoip"
For additional details, see Maxmind GeoIP.
Remote data sources¶
Remote sources are required to be added to each policy configuration. However, any source that’s cached globally, will only be downloaded once. See Remote source settings for details.
Locally managed data sources¶
In addition to downloading content from external sources for your sensors, Corelight-update will also accept content and configurations that are placed locally using specific folder paths. And you can define and deploy the content at a Global-level, or at a Policy-level.
Corelight-update provides separate folders for data sources at the Policy-level and Global-level where you can place pre-formatted content to be processed. The following is a list of folder locations files can be placed for automatic processing:
/etc/corelight-update/global/global-input /etc/corelight-update/global/global-intel /etc/corelight-update/global/global-suricata /etc/corelight-update/global/global-yara /etc/corelight-update/configs/<policy_name>/local-input /etc/corelight-update/configs/<policy_name>/local-intel /etc/corelight-update/configs/<policy_name>/local-suricata /etc/corelight-update/configs/<policy_name>/local-yara
For example, if an intel file is placed in the global-intel
folder, the contents are added to the published intel file for all policies. If an intel file is placed in a policy-named local-intel
folder, the contents are automatically added to the published intel file only for that policy.
The following functions do not require any additional configuration:
All Zeek compatible formatted files in the
global-intel
folder are added to all policies as an intel file.Any Zeek compatible formatted files placed in a
local-intel
folder is added to that policy as an intel file.Any intel files in the
global-intel
,local-intel
, or generated by an enabled integration are automatically merged into a single intel.dat file.
Any Suricata formatted “.rules” or “.rules.tar.gz” ruleset files placed in the
global-suricata
folder are available to all policies.Any Suricata formatted “.rules” or “.rules.tar.gz” ruleset placed in a
local-suricata
folder are available to that policy.Any ruleset file in the
global-suricata
,local-suricata
, or generated by an enabled integration are automatically processed and merged into a single suricata.rules file.
Any Zeek compatible formatted files placed in the
global-input
folder are available to all policies.Any Zeek compatible formatted files placed in a
local-input
folder are available to that policy.Any input files in the
global-input
,local-input
, or generated by an enabled integration, (with the same name) will automatically get merged into a single input file with that name.
Any YARA formatted files placed in the
global-yara
folder are available to all policies.Any YARA formatted files placed in a
local-yara
folder are available to that policy.Any YARA files in the
global-yara
,local-yara
, or generated by an enabled integration are automatically processed and merged into a single yara_rules.yar file.
To review the order that the configurations are processed in, see Order of operations.
Global-level Suricata settings¶
If you maintain a centralized set of Suricata configuration files for ruleset tuning and management, you can configure Corelight-update to automatically download your Suricata configuration files from a remote source, and apply them to the Corelight-update connected sensors.
The Suricata configuration files disable.conf
, enable.conf
and modify.conf
can be applied at a global level, and at a policy level. If a disable.conf
, enable.conf
or modify.conf
exist in the Global config directory, they will be processed for each policy automatically.
To learn about the processing order, see Order of operations.
For information about applying Suricata configuration files at the policy level, see Suricata policy settings.
Each time the Corelight-update service runs, the Suricata rulesets can be processed up to three times for each policy:
Process any enabled Corelight recommended configs,
Process any enabled global-level configs,
Process the Suricata policy-level configs.
For example, to pull a modify.conf
file from GitHub and apply it as part of your Global policy:
remote_global_conf_files:
- name: modify.conf
url: https://raw.githubusercontent.com/fakeuser/conf/main/modify.conf
auth_type: basic
username: fakeuser
encrypted_pass: 8946af417b8c3a13358ac42e6f6fbb3f256e2f5cc778a08...
The supported authentication types are no auth, basic
, or token
. When using the no auth option, leave the auth_type
field empty.
See Using a proxy with Corelight-update for details about using a proxy to download remote sources.
Updating the Global configuration¶
Changes can be made to the global policy using either:
A config file.
The Corelight-update CLI command by using the
--global-settings
switch.
The Corelight-update CLI command supports updating the Global Configuration directly using the --global-settings
switch.
Multiple settings can be updated using a single command.
Update nested settings by using a “.” , for example,
webserver.enable=true
.Other than
remote_global_conf_files
, any setting can be updated using a key=value pair.
For example:
corelight-update update --global-settings verbose=false interval_minutes=30
Note
Making changes to a policy using the CLI bypasses the configuration files. To maintain a copy of the current Global Configuration as a config file, export it to a file. See “Show Options” in the CLI commands.
See the Complete Global Settings below for a list of fields that can be updated directly.
When using a config file, make additions or changes to a configuration file before loading the file into Corelight-update.
To update the global configuration:
Change the settings in the config file.
Update the global configuration. For example:
corelight-update update -global --file /etc/corelight-update/global/db-config.yaml
Warning
When making changes to a policy, the configuration file section being modified must also include any previously defined, non-zero fields. Any fields left undefined will be automatically configured to their zero value.
After updating a configuration, we recommended verifying the global configuration on the console.