PUBLICATION HISTORY

Version	Date	Modification
V 5.1	13/09/2019	Updates to take changes in Prelude 5.1 into account
V 5.0	07/09/2018	Updates to take changes in Prelude 5.0 into account
V 4.1	21/07/2017	Updates to take changes in Prelude 4.1 into account
V 4.0	27/02/2017	Updates to take changes in Prelude 4.0 into account
V 3.1	14/09/2016	Updates to take changes in Prelude 3.1 into account
V 3.0	20/05/2016	Updates to take changes in Prelude 3.0 into account
V 2.1	21/08/2015	Updates to take changes in Prelude 2.1 into account
V 2.0	20/10/2014	Initial version

Introduction

Object

This guide presents:

• The Prelude SIEM product;
• The configuration files:
• • General configuration: global.conf, client.conf, idmef-client.conf, tls.conf
  • Prelude SIEM modules configuration:
    • Prelude Manager;
    • Prelude LML;
    • Prelude Correlator;
    • Prelude GUI;
  • An example of multi-tenant configuration.

Scope of this document

This document is applicable to:

• Prelude SIEM version 5.2;
• Operating systems:
  • CentOS/Redhat version 7 - 64 bits;
• Databases:
  • PostgreSQL version 9.2 and newer;
• External sensors:
  • Suricata version 4.0 and newer;
  • Samhain version 3.1 and newer;
  • OSSEC version 2.8 and newer;

Audience for this document

This document is mainly dedicated to the following teams:

• The Prelude SIEM integration team;
• The Prelude SIEM support and deployment team;
• The Prelude SIEM administration team;
• The Prelude SIEM users.

References

This section gives links for the web page on Prelude SIEM product and operating systems:

• Prelude SIEM: https://www.prelude-siem.com and https://www.prelude-siem.org
• Operating systems:
  • CentOS/Redhat: http://www.centos.org

Prelude SIEM: The security monitoring

Prelude SIEM is an open-source security monitoring solution. Its objective is to centralize all security events of an information system and to offer a homogeneous vision to the operators. Prelude SIEM collects, normalizes, sorts, aggregates, correlates and reports all security-related events independently of the product brand or license giving rise to such events.

Figure: Features of Prelude SIEM

Prelude SIEM presents a specificity almost unique in the SIEM community: it implements the IDMEF format. This format is defined in an RFC since 2007 at the IETF and allows homogenizing the way a security alert is presented. Through the use of this format and its interconnection library, it is easy to make other tools communicate with Prelude SIEM. Beyond its capacity to analyze any type of log (system logs, log streams, flat files, etc.), Prelude SIEM also benefits from a native support with a number of HIDS and NIDS sensors; with the best known being Snort, Samhain, OSSEC and Suricata.

Prelude SIEM is available in three versions:

• Prelude OSS: Free, public and open-source version, released under GPL V2 license. Prelude OSS implements the event management part of Prelude (SEM). Since version 5.2, Prelude OSS also makes it possible to store, display and analyze raw security information (SIM). This version is intended for small parks of limited size (<10 machines), students, research organizations, as well as for testing by users interested in acquiring Prelude SIEM. The performance of Prelude OSS is highly limited by the volume of data analyzed.
• Prelude SIEM: Professional version based on the open-source version Prelude OSS and that greatly enhances its performance. Prelude SIEM offers many additional features (ticket management, dynamic statistics, geolocation, archiving, etc.) and capabilities to be deployed and operated easily and efficiently on complex and large-scaled parks of machines.
• Prelude SOC: Fully scaled version, mainly for Security Operational Center (SOC) usage. Necessary modules for an operational security center, in addition to Prelude SIEM, are: Prelude MAP (network topological representation), Prelude CTI (Cyber Threat Intelligence) and Prelude NOC (performance and availability monitoring).

Prelude SIEM modules

The following figure shows how Prelude SIEM’s modules communicate together:

Figure: Event tracking between Prelude SIEM modules

The path of an event between the different Prelude SIEM modules is as follows:

1. The application generates a log and sends it to Prelude LML (either under file form or through a Syslog connection);
2. The log is analyzed by Prelude LML (thanks to its set of rules). If this log is considered suspicious, Prelude LML creates an IDMEF alert and sends it to its manager (Prelude Manager that can be chained to another Prelude Manager instance);
3. Prelude Manager performs the filters and treatments that are configured and then inserts the event into the database;
4. Prelude Correlator receives the alerts from Prelude Manager;
5. If several raw alerts match a correlation scenario, a correlation alert is generated and sent to Prelude Manager;
6. Prelude Manager also writes correlation alerts into the database;
7. Prelude GUI connects to the database via LibPreludeDB in order to read information and sends it to a browser.

In parallel, Prelude Manager can receive alerts from other sources:

1. A third-party intrusion detection sensor sends its alerts to Prelude Manager (e.g. OSSEC, Samhain, Suricata, etc).

Prelude SIEM bus configuration

This chapter describes general configuration of Prelude SIEM.

Each configuration file applies the following formalism:

• A tag, to indicate a section: [name]
• A section with configuration variables: key = value or key
• A section containing only variables
• A comment with at the beginning of the sentences: #

[prelude]
# Commentaire à propos de la section (un commentaire, commençant par #)
# Commentaire à propos de la variable
tcp-keepalive-time = 7200 (une variable)
# Commentaire à propos de la variable
tcp-keepalive-probes =
# Commentaire à propos de la variable
tcp-keepalive-intvl = 75

Introduction

All Prelude SIEM agents have a common set of options, provided through the Prelude SIEM framework. You might modify these system wide options or in the specific configuration file a client might provide.

All options defined system wide might be overridden in the client own Prelude SIEM configuration file. These are just template values that the client will use in case the values are not defined.

Once the Prelude SIEM library installed, you can tune system wide options using the following configuration files:

• /etc/prelude/default/global.conf
• /etc/prelude/default/client.conf
• /etc/prelude/default/idmef-client.conf
• /etc/prelude/default/tls.conf

The following sections explain in detail how to configure these files.

Global configuration file: global.conf

This is the common default configuration file for all Prelude SIEM programs (sensors, agents, and Manager) using libprelude. It provides a system wide template for common IDMEF attributes used by sensors.

All of these settings are optional, but keep in mind setting them will help you to keep track of where an event is coming from, especially in a distributed environment witha high number of sensors.

This file is located in /etc/prelude/default/global.conf

[prelude] section

The heartbeat-interval option defines how often a Prelude SIEM client should send a heartbeat. The default is 600 seconds, namely 10 minutes.

heartbeat-interval = 600

You can define IDMEF attributes to be carried by events emitted by the program:

• analyzer-name: Name for the analyzer (by default, this is set to the profile name used by the sensor);
• node-name: Name of the equipment (usually the name of the machine this sensor is running on);
• node-location: Location of the equipment (could be a city, or a country);
• node-category: The type of node the clients are running on (usually host).

Note

All of these settings are optional.

The following table shows the possible values of node-category option:

Possible values for node-category option

Value	Details
unknown	Unknown or not relevant
ads	Windows 2000 Advanced Directory Services
afs	Andrew File System (Transarc)
coda	Coda Distributed File System
dfs	Distributed File System (IBM)
dns	Domain Name System
hosts	Local hosts file
kerberos	Kerberos realm
nds	Novell Directory Services
nis	Network Information Services (Sun)
nisplus	Network Information Services Plus (Sun)
nt	Windows NT domain
wfw	Windows for Workgroups

[Node-Address] section

You might also want to define one or several [Node-address] sections, containing the following options:

• address: The address of the equipment;
• netmask: Netmask for this address;
• VLAN-name: Name of the Virtual LAN to which the address belongs;
• VLAN-num: Number of the Virtual LAN to which the address belongs;
• category: Type of address represented (usually ipv4-addr or ipv6-addr).

The following table shows the possible values of category option (by default, defined to unknown):

Possible values for category option

Values	Details
unknown	Unknown address type
srm	Asynchronous Transfer Mode
e-mail	Electronic mail address (RFC 822)
lotus-notes	Lotus Notes e-mail address
mac	Media Access Control (MAC) address
sna	IBM Shared Network Architecture (SNA)
vm	IBM VM (“PROFS”) e-mail address
ipv4-addr	IPv4 host address in dotted-decimal notation (a.b.c.d)
ipv4-addr-hex	IPv4 host address in hexadecimal notation
ipv4-net	IPv4 network address in dotted-decimal notation, slash, CIDR (a.b.c.d/nn)
ipv4-net-mask	IPv4 network address in dotted-decimal notation, slash, network mask in dotted-decimal notation (a.b.c.d/w.x.y.z)
ipv6-addr	IPv6 host address
ipv6-addr-hex	IPv6 host address in hexadecimal notation
ipv6-net	IPv6 network address, slash, CIDR
ipv6-net-mask	IPv6 network address, slash, network mask

Client/Manager configuration file: client.conf

This is the default configuration for programs linked to a manager (sensors and agents) that use Libprelude.

This file is located in the path /etc/prelude/default/client.conf and contains only one section, which is [prelude].

In this configuration file, you can configure the connection string that clients, which need to connect to a Prelude Manager, will use.

By default this option is uncommented and sets on the localhost IP address.

server-addr = 127.0.0.1

Note that whatever you specify here, any event sent through the Prelude SIEM framework is saved in case the remote Manager goes down. In this case, all events will be saved and the client will periodically attempt to reconnect and flush saved events.

Here are a few configuration examples:

• Connect and send events to x.x.x.x:

server-addr = x.x.x.x

You can use boolean operators ‘||’ (OR) and ‘&&’ (AND) to set up a redundant configuration environment.

• Connect and send events to both x.x.x.x and y.y.y.y:

server-addr = x.x.x.x && y.y.y.y

• Connect and send events to x.x.x.x, or fallback to y.y.y.y if x.x.x.x failed:

server-addr = x.x.x.x || y.y.y.y

• Connect and send events to x.x.x.x on specific port, or fallback to y.y.y.y*and *z.z.z.z if x.x.x.x failed:

server-addr = x.x.x.x:port || y.y.y.y && z.z.z.z

This mean the emission should occur on x.x.x.x:port or, if it fails, on y.y.y.y and z.z.z.z (if one of the two hosts in the AND fails, the emission will be considered as failed involving saving the message locally).

The following settings instruct the operating system when to consider a connection dead in case sent data is left unacknowledged.

These options are operating system specific, and might not work on certain platforms. In case you modify these settings on an unsupported system, a warning message will be issued when the agent starts.

Under Linux, the default system wide configuration is:

tcp-keepalive-time = 7200
tcp-keepalive-probes = 9
tcp-keepalive-intvl = 75

• tcp-keepalive-time represents the number of seconds the connection needs to be idle before TCP begins sending out keep-alive sensors;
• tcp-keepalive-probes represents the number of non-acknowledged packets to send before considering the connection dead;
• tcp-keepalive-intvl represents the interval between subsequent keepalive sensors.

The average time to notice a dead connection can be calculated using:

connexion échouée = tcp-keepalive-time + (tcp-keepalive-probes * tcp-keepalive-intvl)

Configuration example:

tcp-keepalive-time = 60
tcp-keepalive-probes = 3
tcp-keepalive-intvl = 10

Using the above settings, a dead connection will be detected within 90 seconds.

You can set priorities for the ciphers, key exchange methods, macs and compression methods using TLS options (only available with GnuTLS 2.2.0 or higher) by setting the tls-options option.

The default setting is “NORMAL”.

tls-options = NORMAL

The following table shows the possible values of tls-options option:

Possible values for tls-options option

Value	Details
NORMAL	Enables all “secure” ciphersuites. The 256-bit ciphers are included as a fallback only. The ciphers are sorted by security margin.
SECURE128	Enables all “secure” ciphersuites with ciphers up to 128 bits, sorted by security margin.
SECURE256	Enables all “secure” ciphersuites including the 256 bit ciphers, sorted by security margin.
EXPORT	All the ciphersuites are enabled, including the low-security 40 bit ciphers.
NONE	Nothing is enabled. This disables even protocols and compression methods.

Note

Much more settings might be enabled or disabled using this option: please see gnutls_priority_init(3) for more details.

IDMEF Client/Manager connection: idmef_client.conf

This file located in the path /etc/prelude/default/idmef_client.conf and includes both /etc/prelude/default/global.conf and /etc/prelude/default/client.conf configuration files:

include = /etc/prelude/default/global.conf
include = /etc/prelude/default/client.conf

It is often used as the template by clients that need to connect to a Prelude Manager. You probably should not modify this file directly (use global.conf and client.conf).

TLS Client/Manager connection: tls.conf

This file located in the path /etc/prelude/default/tls.conf allows to configure several TLS specific options.

Default size of the client/server generated private key:

generated-key-size = 2048

Number of days the authority certificates (server side) will remain valid. These certificates are only used in order to sign client certificate.

Use 0 for the maximum possible value.

authority-certificate-lifetime = 0

Number of days the generated certificates (client side) will remain valid. These certificates are only used in order to authenticate and encrypt client/server communication.

Use 0 for the maximum possible value.

generated-certificate-lifetime = 0

Prelude SIEM modules configuration

This chapter explains the configuration of Prelude SIEM modules.

Sections are important, and things won’t work correctly if they are not uncommented. For example you need to uncomment [db] section if you want the database plugin to be loaded.

Prelude Manager configuration

Prelude Manager is a high availability server that accepts secured connections from distributed sensors or other managers and saves received events to a media specified by the user (database, logfile, mail, etc). It is capable of handling large number of connections, and processing large amounts of events. It uses a per client scheduling queues in order to process events by severity fairly across clients.

The configuration file is located in /etc/prelude-manager/prelude-manager.conf.

Generic confguration

This file includes the global.conf configuration file:

include = /etc/prelude/default/global.conf

[prelude] section

Using the global [prelude] section, where you can define Prelude SIEM related options, you can define option of matter for Prelude Manager, and most specifically in the context of relaying, TCP/IP options that influence the behavior of when the operating system should consider a connection dead in case sent data is left unacknowledged.

Refer to the section Client/Manager configuration file: client.conf to configure this section.

General configuration

Prelude Manager can listen on a UNIX domain socket, or on an IPv4 or IPv6 address. The default is to listen on an UNIX domain socket. The listen option configures the address where the Prelude Manager server is listening on.

Multiple listen addresses are supported. If value is unix, or unix:/path/to/unix/socket, a UNIX domain socket will be used.

• Listen on /tmp/prelude-unix UNIX domain socket (this is the default value):

listen = unix

• Listen on /tmp/myfilename UNIX domain socket:

listen = unix:/tmp/prelude-manager.socket

• Listen on the specified IP address and port:

listen = <IP address>:<port>

The IP address specified is compatible with ipv4 and ipv6. By default this option is uncommented and setting on the localhost IP address.

listen = 127.0.0.1

You might set the user and group ID as which Prelude Manager will run. In order to use this option, Prelude Manager must be run initially as root.

user = prelude-manager
group = prelude

You can customize the number of second Prelude Manager wait for an incoming client to successfully authenticate before dropping a connection. The default value is 10 seconds.

connection-timeout = 10

Scheduler settings for Prelude Manager

On systems with many concurrent sensors sending events to Prelude Manager, Prelude Manager might have a hard time keeping up with the demand for events reporting.

The Prelude Manager scheduler allocate reporting time per sensor, allowing to define the maximum number of events processed for one sensor before processing others sensors events (in case a sensor is sending a continuous events burst, this prevent other sensors starvation).

By default, for each sensor connected, a maximum of 100 events will be processed before processing others sensors events.

Additionally, priority will be given to events depending on their priority. Assuming there is enough events of each priority, 50 high priority message will be processed, 30 medium, and 20 low (totaling the maximum of 100 described above).

You might use the sched-priority option in order to change this setting:

sched-priority = high:50 medium:30 low:20

When the number of events waiting to be processed exceeds the defined amount of reserved memory (default is 1 Megabyte), Prelude Manager will start storing events on disk:

sched-buffer-size = 1M

TLS options

Refer to the section Client/Manager configuration file: client.conf for TLS option.

Refer to the section TLS Client/Manager connection: tls.conf to customize the parameters of Diffie Hellman key exchange.

Relaying setting

If you want this Manager to retrieve messages from another Manager (useful if the other Manager is located within a DMZ):

child-managers = <IP address>

Example:

child-managers = 10.0.0.54

Prelude Manager will be connected to 10.0.0.54 to retrieve events from this host.

You can use booleans in order to specify more complex connections.

The following table is a recap of boolean operators usage:

Relaying configuration with boolean operators

Boolean operator	Details
||	OR operator: selects only a host among several in order of priority.
&&	AND operator: selects all hosts at the same time
|| and &&	Selects the hosts in order of priority

Using the AND operator:

child-managers = x.x.x.x && y.y.y.y

Example:

child-managers = 10.0.0.60 && 10.0.0.64

Prelude Manager will be connected to both 10.0.0.60 and 10.0.0.64 host to retrieve events from them. If the connection to one of the hosts fails, the relaying will be ineffective.

Using the OR operator:

child-managers = x.x.x.x || y.y.y.y

Example:

child-managers = 10.0.0.60 || 10.0.0.64

Prelude Manager will connect to 10.0.0.60 to retrieve events from this host or 10.0.0.64*if *10.0.0.60 goes down.

Using both AND and OR operators:

child-managers = x.x.x.x || y.y.y.y && z.z.z.z

Example:

child-managers = 10.0.0.56 || 10.0.0.60 && 10.0.0.64

This mean Prelude Manager will connect to 10.0.0.56 or, if it fails, on 10.0.0.60 and 10.0.0.64. If one of the two hosts in the “AND” expression fails, the relaying will be ineffective.

Refer to the section Plugins configuration for parent managers configuration.

Protection against possible failures

Under certain conditions, you might want to activate failover for a given reporting plugin (as of the time of writing, only the db reporting plugin supports it). Failover is a Prelude Manager feature allowing storage of alerts in case the reporting plugin fails.

This is especially useful when the reporting plugin relies on another program (example: database).

If the protected reporting plugin fails for any reason to process the message, the failover subsystem will backup it as well as any future messages. It then will periodically try to re-initialize the plugin, and process any backed up messages.

As an example, if you activate report plugins failover for the db plugin, and then you stop the underlying database, messages will be saved and processed when the database will be restarted.

You might use this option multiple times for different plugins.

failover = <nom_du_plugin>

Example from the configuration file:

failover = db

Note

It is not necessary to activate failover for the relaying plugins since the internal subsystem for this plugin will always failover in case of failure.

Prelude Manager plugins configuration

Prelude Manager provides three plugins categories in order to carry out different actions:

• Normalization plugins;
• Reporting plugins;
• Filtering plugins.

Normalization plugins configuration

For each incoming event, Prelude Manager will run a number of normalization routines: sanitize address, services information, etc.

[normalize] section

When the normalizer sees an incoming IPv4 mapped IPv6 address, the default behavior is to map it back to raw IPv4. For example, ::ffff:192.168.0.1 will be mapped back to 192.168.0.1

If you do not want IPv4 mapped IPv6 addresses, un-comment the following option:

keep-ipv4-mapped-ipv6

Alternatively, if you wish for any input IPv4 addresses to be converted to IPv6, un-comment the following option:

ipv6-only

Prelude Manager normalizer can add geolocation information to events when libmaxminddb support is enabled, and the path to the maxminddb database is provided:

geoip-database = /path/to/geoip_mmdb_file

Reporting plugins configuration

Once an event has been normalized, Prelude Manager uses reporting plugins to export this IDMEF event into various output formats.

A same event can be exported through several plugins (for instance, database insertion and email sending), even through several instances of the same plugin (for instance, insertion in two databases), but won’t be exported several times through the same instance of a plugin.

A number of reporting plugins are available:

Available reporting plugins

Plugin name	Details
relaying	A plugin relaying alerts to other managers
db	A database plugin (MySQL, PostgreSQL, SQLite)
xmlmod	An XML reporting plugin
debug	Allow to report alerts as text in a file, or to dump these alerts to stderr
textmod	A text reporting plugin
smtp	Send textual alert through your SMTP server

Note

Check the prelude-manager --help output for others.

[relaying] section

Prelude Manager can act as a relay to another Manager by using the relaying plugin. Relaying managers control a set of analyzers, and relay alerts and messages received from these analyzers to another parent manager. This is a very useful feature when a network is divided into sub-networks.

parent-managers = <Adresse IP>

Example:

parent-managers = 172.25.104.56

Started this way, Prelude Manager will connect to the specified parent manager localized by the 172.25.104.56 IP address.

You can use a boolean expression, with “AND” and “OR” operators.

parent-managers = x.x.x.x || y.y.y.y && z.z.z.z

Example:

parent-managers = 10.0.0.56 || 10.0.0.60 && 10.0.0.64

[db] section

In order for Prelude Manager to report to a database, you need to use the db reporting plugin. Additionally, you need to provide this plugin with several arguments:

Options of the db reporting plugin

Option	Description
type	Type of database (mysql, pgsql or sqlite)
file	only use for SQLite database. Sets path giving access to the database file
host	Hostname where the database is listening on (default is localhost)
port	Port where the database is listening on, if applicable
name	Name of the database to use
user	Username to use in order to connect to this database
pass	Password to use in order to connect to this database.

Note

If you use SQLite database, you need to initialize only two variables, which are type and file. MySQL and PostgreSQL don’t use the file variable.

Default configuration file:

[db]
type = <database type : mysql | pgsql | sqlite3>
#file = <path/to/dbfile/idmef.sql>
host = <host of the database>
port = <port of the database if necessary>
name = <database name>
user = <database username for the authentication>
pass = <password associated with the username>

Example:

[db]
type = mysql
#file = /var/lib/sqlite/sqlite-prelude.db
host = localhost
port = 3306
name = prelude
user = prelude
pass = prelude

Note

You might want to store alerts in case the db reporting plugin fails. Refer to the section Protection against possible failures

[XmlMod] section

The Xmlmod plugin allows to report alerts as IDMEF XML in a file, or to dump these alerts to /dev/stdout. The default behavior is to write output to /dev/stdout.

Disable output file buffering. Uncomment the following option will prevent XML alerts to be truncated and thus make real-time parsing easier:

disable-buffering

Uncomment the following option will tell Xmlmod to check generated XML against IDMEF DTD:

validate

The format option tells Xmlmod to produce a pretty, human readable XML output:

format

/dev/stdout value displays alerts on standard output:

logfile = /dev/stdout

File in which alerts will be generated in xml format:

logfile = /var/log/prelude/prelude-xml.log

Example of a prelude-xml.log file containing a heartbeat under XML format:

<IDMEF-Message>
  <Heartbeat>
    <Analyzer analyzerid="2042155273290843" name="prelude-manager"
manufacturer="http://www.prelude-siem.com" model="Prelude Manager" version="4.0.0"
class="Concentrator" ostype="Linux" osversion="4.9.10-200.fc25.x86_64">
      <Process>
        <name>prelude-manager</name>
        <pid>8116</pid>
        <path>/usr/bin/prelude-manager</path>
      </Process>
    </Analyzer>
    <CreateTime ntpstamp="0xd765276a.0x53251000">2017-02-24T11:04:26.324784+02:00</CreateTime>
    <AdditionalData type="string" meaning="Analyzer status">
      <string>starting</string>
    </AdditionalData>
    <AdditionalData type="string" meaning="Analyzer SHA1">
      <string>bc0db58a488d850a0b29a678fc1df62db14d74e3</string>
    </AdditionalData>
    </Heartbeat>
</IDMEF-Message>

[Debug] section

The Debug plugin allows to report alert as text in a file, or to dump these alerts to standard output. The default behavior is to write on the standard output:

logfile = /dev/stdout

Report alerts as text in a file:

logfile = /var/log/prelude/prelude-debug.log

You can specify the name of the IDMEF object to print (you might select multiple objects). If no object is provided, ‘Debug’ will print out the entire message.

object = alert.classification.text, alert.source(0).node.address(0).address

[TextMod] section

The TextMod plugin allows to report alerts as text in a file, or to dump these alerts on the standard output. The default behavior is to write on the standard output.

logfile = /dev/stdout
logfile = /var/log/prelude/prelude-text.log

Example of text file generated:

********************************************************************************
* Alert: ident=8aca6390-fc52-11e3-8eff
* Classification text: Remote Login
*
* Creation time: 0xd7552147.0xba79a000 (2017-02-24 12:21:59.728418+02:00)
* Detection time: 0xd755212b.0x00000000 (2017-02-24 12:21:31.0+02:00)
* Analyzer time: 0xd7552147.0xba7bd000 (2017-02-24 12:21:59.728452+02:00)
* Analyzer ID: 2042155273290843
* Analyzer name: prelude-manager
* Analyzer model: Prelude Manager
* Analyzer version: 4.0.0
* Analyzer class: Concentrator
* Analyzer manufacturer: http://www.prelude-siem.com
* Analyzer OS type: Linux
* Analyzer OS version: 4.9.10-200.fc25.x86_64
* Process: pid=5633 name=prelude-manager path=/usr/bin/prelude-manager
* Analyzer ID: 1779818670852139
* Analyzer name: prelude-lml
* Analyzer model: Prelude LML
* Analyzer version: 4.0.0
* Analyzer class: Log Analyzer
* Analyzer manufacturer: http://www.prelude-siem.com
* Analyzer OS type: Linux
* Analyzer OS version: 4.9.10-200.fc25.x86_64
* Process: pid=7710 name=prelude-lml path=/usr/bin/prelude-lml
* Analyzer name: sshd
* Analyzer class: Authentication
* Analyzer manufacturer: OpenSSH
* Node[unknown]: name:preldue-doc
* Process: pid=5655 name=sshd

[script] section

The script plugin allows to execute commands depending on the received alerts. If an IDMEF path is prefixed by a $ symbol, it will be replaced by the corresponding value in the alert.

• command: Path of the script to be executed

Basic configuration example:

[script]
command = /bin/echo $alert.classification.text

The error output of the script is located in /var/log/messages.

[smtp] section

The SMTP plugin provides the ability to send textual alerts via e-mail using three options:

• sender: e-mail sender address;
• recipients: e-mail recipient address;
• smtp-server: SMTP server address.

Basic configuration example:

[smtp]
sender = prelude@myhostname
recipients = recipient1@hostname, recipient2@hostname
smtp-server = localhost

By default, the SMTP plugin sends an e-mail containing the whole IDMEF event. If you wish to send a subset of the information, you may customize the content of the generated e-mail through several options:

You can define a specific subject to use with e-mail notification. The subject can include information from the event using IDMEF path.

subject = Alerte : $alert.classification.text

You can define a specific message body to use for e-mail notification. As with the “subject” option, the template can include information from the event using IDMEF path.

Additionally, you can provide a template for the message body of the e-mail notification. As for the “subject” option, the template can include information gathered from the event using IDMEF path.

template = /chemin/vers/mon/template

A template example is available in:

template = /usr/share/doc/prelude-manager(-pro)/smtp/template.example

Template file example:

***
* http://127.0.0.1:8000/alerts/alerts/AlertSummary?analyzerid=$alert.analyzer(-1).analyzer
id&messageid=$alert.messageid
* $alert.classification.text : $alert.source(0).node.address(0).address ->
$alert.target(0).node.address(0).address
*
* Create Time: $alert.create_time
* Sensor: $alert.analyzer(-1).name - $alert.analyzer(-1).node.name -
$alert.analyzer(-1).node.address(0).address
*
#if $alert.correlation_alert.name
* CorrelationAlert name: $alert.correlation_alert.name
#end if
***

Explanation: when an alert is received, the SMTP plugin retrieves the information from the alert to include it in the generated message.

The mechanism also works with correlation alerts, but other options need to be filled in. A correlation alert containing several alerts already received, the SMTP plugin must connect to the alert database to retrieve the information of the simple alerts in order to include them in the body of the mail:

dbtype = <database type : mysql | pgsql | sqlite3>
dbhost = <host of the database>
dbname = <database name>
dbuser = <database username for the authentication>
dbpass = <password associated with the username>

Example:

dbtype = mysql
dbhost = localhost
dbname = prelude
dbuser = prelude
dbpass = passwd

If you have specified your database settings above, you can also use the correlated-alert-template option, which is like the “template” option but is specific to correlated alerts retrieved from database. Commented by default:

correlated-alert-template = /path/to/my/template

Example:

correlated-alert-template = /usr/share/doc/prelude-manager(-pro)/smtp/template.example

[smtp] section

The SNMP plugin provides the ability to send textual alerts via SNMP using these options:

SNMP plugin options

Option	Description
traphost	Trap recipient. A specific port may be given using the suffix :port, eg.*localhost:16162*. To force the use of an IPv6 transport, add a udp6: prefix and put IPv6 addresses between brackets, e.g.: udp6:[::1].
version	Protocol version to use (either v1, v2c or v3)
community	SNMP community (v1/v2c only)
sec-name	Security username
sec-level	Security level (either noAuthNoPriv, authNoPriv or authPriv)
auth-protocol	Authentication protocol (either MD5 or SHA1)
auth-key	Authentication passphrase
priv-protocol	Privacy protocol (either DES or AES)
priv-key	Privacy passphrase
engineid	Identifiant du moteur SNMP, en hexadécimal. L’identifiant doit être composé de 5 à 32 caractères, et être unique au sein du réseau. Si cette option n’est pas renseigné, un identifiant sera généré aléatoirement à chaque démarrage du manager.

Configuration example:

[snmp]
traphost = localhost
version = v3
community = public
sec-name = sec-name-not-configured
sec-level = authPriv
auth-protocol = SHA1
auth-key = snmp-authentication-key
priv-protocol = AES
priv-key = snmp-privacy-key
engineid = 0x1234567890

Filtering plugins configuration

Two filtering plugins are available:

• IDMEF Criteria Filtering Plugin: Filtering events;
• Thresholding Filtering Plugin: Event suppression and thresholding.

For further explanations on IDMEF-Criteria and IDMEF-Path refer to Annex: IDMEF criteria and paths.

[idmef-criteria] section

The idmef-criteria filtering plugin allows you to filter events based on specific IDMEF-Criteria :

A filtering rule (i.e. an instance of the plugin) might be used to decide whether a specific action should be taken:

rule = <IDMEF criteria>
hook = <plugin name>

The hook option can take the following values:

• either the name of a reporting plugin, for instance “db”;
• the name and the instance of a reporting plugin, for instance “smtp[myinstance]”;
• or the special value “reporting” explained below.

The rule option takes an IDMEF criterion.

Example:

[idmef-criteria]
rule = alert.classification.text == 'User login successful' && alert.assessment.impact.severity == high
hook = relaying[default]

This configuration will forward any event matching the defined criteria to another manager. There may be several relaying managers, that’s why the instance name is defined here.

The rule argument might also be a filename containing the rules:

rule = /path/to/myfile.rule

[thresholding] section

The thresholding plugin allows suppressing events similar to previously received events, based on their IDMEF values.

Example from the configuration file:

path = alert.classification.text, alert.source.node.address.address
limit = 3600
count = 1
hook = relaying[default]

This configuration will relay one event with a given alert.classification.text, alert.source.node.address.address value combination during 3600 seconds. Further events with the same combination will be suppressed during this period.

path = alert.classification.text, alert.source.node.address.address
threshold = 3600
count = 10
hook = relaying[default]

This configuration will relay every tenth event with the same alert.classification.text, alert.source.node.address.address value combination during 3600 seconds.

Note

Limit and threshold might be combined, allowing to setup a limit as soon as the first threshold is reached.

Application of filtering rules in regards to reporting

It is possible to chain filtering rules by using hooks, in which case the condition of a filtering rule will be verified if its own condition is verified, as well as at least one of the rules “hooked” on it.

The use of a reporting plugin for a given event depends on the following rules:

• if a filtering rule declared a hook on the special value “reporting” and if its condition is not verified, then the event is ignored;
• if no filtering rule declared a hook on the reporting plugin, then the event will be processed by the plugin;
• if at least one filtering rule having declared a hook on the reporting plugin is verified, then the event will be processed by the plugin; otherwise, it will be ignored.

Advanced configuration example:

Declaring several plugins and chaining them allows you to create more complex filtering capabilities. In the example below, filtering, thresholding and SMTP plugins are combined to enhance your reporting.

Example:

[smtp]
sender = prelude@mycompanyname.com
recipients = me@mycompanyname.com
smtp-server = mailserver.mycompanyname.com

[idmef-criteria]
rule = alert.classification.text == 'Login Attempt'
hook = smtp

[idmef-criteria=sudotest]
rule = alert.classification.text == 'SUDO Command Executed'
hook = smtp

[thresholding]
path = alert.classification.text
limit = 60
count = 10
hook = reporting

[thresholding=sudotest]
path = alert.classification.text, alert.target(0).node.address(0).address
limit = 3600
count = 1
hook = idmef-criteria[sudotest]

In the example above, five plugin instances have been declared:

• one instance of the smtp reporting plugin, tasked to send events by email;
• two instances of the idmef-criteria filtering plugin, tasked to ignore the events which don’t match the given classifications;
• two instances of the thresholding filtering plugin, tasked to limit the number of events to process.

At the reception of an IDMEF event, an email will be generated if all the following conditions are met:

• its classification is “Login Attempt” or “SUDO Command Executed”;
• the threshold of 10 alerts having the same classification has not been reached during the last minute;
• if the classification is “SUDO Command Executed”, no alert with the same classification and target address has been received for the last hour.

In this example, the stacking of plugins allowed us to filter on a certain IDMEF alert type, to send an email in case of a match, while avoiding sending too many email in certain particular cases.

Prelude LML configuration

Multiple log files can be used with different formatting. You can configure Prelude LML so that it know how to handle each log format.

This is done using a [format] section, in the Prelude LML configuration file: /etc/prelude-lml/prelude-lml.conf.

The configuration file of Prelude LML begins by include the configuration file of IDMEF.

include = /etc/prelude/default/idmef-client.conf

This file includes both files global.conf and client.conf located respectively in the path /etc/prelude/default/global.conf and /etc/prelude/default/client.conf. It is often used as the template by clients that need to connect to a Prelude Manager. Then, there is several sections to configure.

[prelude] section

Address where the Prelude Manager server is listening on. If value is 127.0.0.1, the connection will occur through a UNIX socket.

This entry is commented. The default is to use the entry located in the Prelude system wide clients.conf (/etc/prelude/default/clients.conf). You may overwrite the default address for this sensor by uncommenting this entry.

server-addr = 127.0.0.1

[normalize] section

First thing to do is to define the prefix-regex and time-format corresponding to the log message within a [format] section. If not specified, the default syslog format define in RFC 5424 will be used.

Example configuration for syslog output:

• Each [format] section might have several log source entries: file, udp-server, tcp-server or tcp-tls-server;
• If a log source is listed across different formats, then the first matching format for a given log source will be used.

[format=syslog]
time-format = "%b %d %H:%M:%S"
prefix-regex = "^(?P<timestamp>.{15}) (?P<hostname>\S+) (?:(?P<process>\S+?): )?"
file = /var/log/mylogfile
udp-server = 0.0.0.0:514

[format=apache]
time-format = "%d/%b/%Y:%H:%M:%S"
prefix-regex = "^(?P<hostname>\S+) - - \[(?P<timestamp>.{20}) \+.{4}\] "
file = /var/log/mylogfile
udp-server = 0.0.0.0:514

The [format] section allows to define several options:

• prefix-regex;
• time-format;
• file;
• charset;
• udp-server;
• tcp-server;
• tcp-ssl-server;
  • tls-mode;
  • tls-key-file;
  • tls-cert-file;
  • tls-ca-file;
  • tls-trusted-fingerprint;
  • tls-trusted-name;
  • tls-verify;
• idmef-alter;
• idmef-alter-force.

prefix-regex

This options tells to Prelude LML how to handle the log header. With this option, you can bind variable used by Prelude LML to fill specific fields in the generated IDMEF alert.

The prefix-regex variable should contain PCRE named sub patterns to pick out the information available in your syslog’s prefix.

The available field names are:

• hostname;
• process;
• pid;
• timestamp.

Here is an example of how it works. Use the following prefix-regex:

prefix-regex = "^(?P<timestamp>.{15}) (?P<hostname>\S+) (?:(?P<process>\S+?)(?:\[(?P<pid>[0-9]+)\])?: )?"

With the following log entry:

Feb 27 14:14:03 prelude-doc emacs[4057]: file 'preludesiem-configuration' saved

When Prelude LML parses this log entry using the prefix-regex, the timestamp,**hostname**, process, and pid variables will be set to the following values:

prefix-regex variables

Variable	Usage	Value
timestamp	Bind to the Detect Time information of an IDMEF Alert	Feb 27 14:14:03
hostname	Bind to the Target node information in an IDMEF Alert	prelude-doc
process	Bind to the Target process name in an IDMEF Alert	emacs
pid	Bind to the Target process pid in an IDMEF Alert	4057

Each of these values will be assigned in the relevant IDMEF fields of the generated alert.

time-format

This option should be set so that Prelude LML knows how the timestamp is defined in your log entry. This will be used to match the timestamp content defined through the prefix-regex option.

Example:

time-format = "%b %d %H:%M:%S"

The following table shows all sequences and options you might use to configure time-format:

Descriptors of field time-format

Sequence	Description
%%	The % character
%a or %A	The weekday name according to the current locale, in abbreviated form or the full name.
%b or %B or %h	The month name according to the current locale, in abbreviated form or the full name.
%c	The date and time representation for the current locale.
%C	The century number (0-99).
%d or %e	The day of month (1-31).
%D	Equivalent to %m/%d/%y. (This is the american style date, very confusing to non-americans, especially since %d/%m/%y is widely used in Europe. The ISO 8601 standard format is %Y-%m-%d.)
%H	The hour (0-23).
%I	The hour on a 12-hour clock (1-12).
%j	The day number in the year (1-366).
%	The month number (1-12).
%M	The minute (0-59).
%n and %t	A whitespace
%p	The locale’s equivalent of AM or PM. (Note: there may be none.)
%r	The 12-hour clock time (using the locale’s AM or PM). In the POSIX locale equivalent to %I:%M:%S %p. If t_fmt_ampm is empty in the LC_TIME part of the current locale then the behavior is undefined.
%R	Equivalent to %H:%M.
%S	The second (0-60; 60 may occur for leap seconds; earlier also 61 was allowed).
%T	Equivalent to %H:%M:%S.
%U	The week number with Sunday the first day of the week (0-53). The first Sunday of January is the first day of week 1.
%w	The weekday number (0-6) with Sunday = 0.
%W	The week number with Monday the first day of the week (0-53). The first Monday of January is the first day of week 1.
%x	The date, using the locale’s date format.
%X	The time, using the locale’s time format.
%y	The year within century (0-99). When a century is not otherwise specified, values in the range 69-99 refer to years in the twentieth century (1969-1999); values in the range 00-68 refer to years in the twenty-first century (2000-2068).
%Y	The year, including century (for example, 1991).

Some field descriptors can be modified by the E or O modifier characters to indicate that an alternative format or specification should be used. If the alternative format or specification does not exist in the current locale, the unmodified field descriptor isused.

The E modifier specifies that the input string may contain alternative locale-dependent versions of the date and time representation.

Descriptors of the time-format field with the E modifier

Sequence	Description
%Ec	The locale’s alternative date and time representation.
%EC	The name of the base year (period) in the locale’s alternative representation.
%Ex	The locale’s alternative date representation.
%EX	The locale’s alternative time representation.
%Ey	The offset from %EC (year only) in the locale’s alternative representation.
%EY	The full alternative year representation.

The O modifier specifies that the numerical input may be in an alternative locale-dependent format.

Descriptors of the time-format field with the O modifier

Sequence	Description
%Od or %Oe	The day of the month using the locale’s alternative numeric symbols; leading zeros are permitted but not required.
%OH	The hour (24-hour clock) using the locale’s alternative numeric symbols.
%OI	The hour (12-hour clock) using the locale’s alternative numeric symbols.
%Om	The month using the locale’s alternative numeric symbols.
%OM	The minutes using the locale’s alternative numeric symbols.
%OS	The seconds using the locale’s alternative numeric symbols.
%OU	The week number of the year (Sunday as the first day of the week) using the locale’s alternative numeric symbols.
%Ow	The number of the weekday (Sunday=0) using the locale’s alternative numeric symbols.
%OW	The week number of the year (Monday as the first day of the week) using the locale’s alternative numeric symbols.
%Oy	The year (offset from %C) using the locale’s alternative numeric symbols.

Note

The timestamp variable is specific in that you have to specify an additional time-format option, so that LML is able to parse the time representation.

file

Specify a file to monitor, this option might be set several time if you want to monitor multiple files with this format.

Example:

file = /var/log/messages
file = /var/log/auth.log

Additionally, you can specify a pattern. Prelude LML will search all the pathnames matching pattern according to the rules used by the shell.

file = /var/log/*/*.log

udp-server

Create a UDP server that is able to handle this format, and which listens to the specified address. The addressing used for udp-server is only ipv4.

This requires the configuration of rsyslog.conf file besides prelude-lml.conf

prelude-lml.conf

udp-server = 127.0.0.1:2000

We set a local IP address followed by a port number, that means syslog server in other words Prelude LML is listening on port number 2000.

Note

The port used mustn’t be specific, however, it must be outside of the range [0-1024] if you execute Prelude LML as a non root user.

Example of a syslog server configuration:

The file rsyslog.conf:

*.* @10.0.0.54:2000

The hostname might be followed by a colon and the destination port number.

In the example, messages are forwarded via UDP to the machine addressed with 10.0.0.54, the destination port is 2000. The messages will not be compressed.

The following table is a brief summary of the rsyslog configuration file:

Important data for rsyslog configuration

Value	Explanation
10.0.0.54	IP address
2000	Port used (optional)
.	All messages for all priority levels
@	One @ character is use for udp
@@	Two @ characters is use for tcp
. @127.0.0.1	This rule would redirect all messages to a remote host which the IP address is 10.0.0.54

When you run Prelude LML you should see:

$ prelude-lml
27 Feb 12:03:58 (process:27929) INFO: PCRE plugin loaded 661 rules.
27 Feb 12:03:58 (process:27929) INFO: Listening for syslog message on 127.0.0.1:2000/udp.
27 Feb 12:03:58 (process:27929) INFO: Connecting to 127.0.0.1:4690 prelude Manager server.
27 Feb 12:03:58 (process:27929) INFO: TLS authentication succeed with Prelude Manager.
27 Feb 12:03:58 (process:27929) WARNING: /var/log/httpd/access_log does not exist.

tcp-server

Create a TCP server that is able to handle this source, and which listens to the specified address. The addressing used for tcp-server is only ipv4.

tcp-server = 10.0.0.42

The TCP server configuration is the same as UDP server. However, do not forget to put two characters @ instead of one.

tcp-ssl-server

This option creates a TCP/SSL server listening at the specified address. The addressing used for tcp-tls-server is only ipv4.

tcp-tls-server = 10.0.0.43

Available TLS modes

Two TLS modes are available:

• x509: x509 based certificate authentication;
• anonymous: Anonymous TLS connection using ANON-ECDH or ANON-DH.

These two modes can be combined, and the default value is x509.

tls-mode = x509 anonymous

Client and certificate

Several parameters have to be defined when TLS mode is used. These parameters concern the client key and the certificate files:

The client key parameter:

tls-key-file = /chemin/vers/client.key

The certificate file parameter:

tls-cert-file = /chemin/vers/client.cert

The certificate authority files parameter:

tls-ca-file = /chemin/vers/server.ca

TLS verification option

When a list of trusted fingerprint and/or a list of trusted name is provided, the connecting client has to match one of the provided fingerprint or name, otherwise the connection will be refused.

The optional parameter below allows to define a trusted client fingerprint:

tls-trusted-fingerprint = SHA1:ae:8a:e5:97:66:2d:6d:cd:85:29:05:95:31:84:81:f1:27:3b:d1:73

To define a list of trusted client fingerprints, the tls-trusted-fingerprint parameter must be defined several times.

tls-trusted-fingerprint = SHA1:ae:8a:e5:97:66:2d:6d:cd:85:29:05:95:31:84:81:f1:27:3b:d1:73
tls-trusted-fingerprint = <another fingerprint>
tls-trusted-fingerprint = <another fingerprint>

If this option is used, then the connecting peers have to match one of the specified fingerprints. The SHA1 and MD5 format are accepted.

The optional parameter below allows to define a list of trusted client names:

tls-trusted-name = <client name>

The value can takes into account wildcards, and the DNSName / IPAddress subject alternative name PKIX extension.

To define a list of trusted client names, the tls-trusted-name parameter must be defined several times.

tls-trusted-name = <client name>
tls-trusted-name = <another name>
tls-trusted-name = <another name>

Note

Both of these parameters can be used simultaneously.

The client certificate verification option can take two possible values:

• client-cert-required: the client has to provide a valid certificate for the authentication to succeed;
• client-cert-optional: the client may connect without providing a valid x509 certificate.

The value is set to client-cert-required by default. That means the client has to provide a valid certificate.

tls-verify = client-cert-required

idmef-alter

Prelude LML allows you to include static values into events generated using a given format.

[format=syslog]
idmef-alter = alert.analyzer(-1).node.location = my localization

Using the example above, any events generated from a syslog format source will have the alert.analyzer(-1).node.location set to my localization, unless the path is already set. An analyzer is the emission source of an alert. It can be a service (webserver, PAM, ssh, anti virus, etc.). analyzer(-1) means that the last element of an analyzer list will be selected.

Note

idmef-alter will never overwrite an IDMEF path that is already set.

idmef-alter-force

Identical to idmef-alter field but you might use the idmef-alter-force option in case you want to overwrite a path that is already set.

charset

For each file added to a format, a character encoding can be specified using the charset option.

Example:

[format=MyFormat]
charset = ISO-8859-1
file = /var/log/messages
file = /var/log/secure
charset = UTF-8
file = /var/log/auth.log
file = /var/log/syslog
udp-server = 127.0.0.1:2000

The following table recaps the example above:

Charset	Source	Explanation
ISO-8859-1	file: messages	This will set the character set for “messages” and “secure” to “ISO-8859-1”
	file: secure
UTF-8	file: auth.log	This will set the character set for “auth.log”, “syslog” and UDP server to “UTF-8”
	file: syslog
	udp-server: 127.0.0.1:2000

Table: Charset usage example

Note

If no character encoding is specified, the system will attempt to automatically detect the encoding used. If the detection fails, then system wide default (retrieved from locale LC_CTYPE) will be used.

LC_CTYPE selects character classification, case conversion, and other characterattributes.

A number of charset are possible to configure:

Examples of charset

Charset	Definition
Windows-1252 also called CP1252	Windows-1252 or CP-1252 is a character encoding of the Latin alphabet, used by default in the legacy components of Microsoft Windows in English and some other Western languages.
ISO 8859-1	Latin alphabet No. 1, is part of the ISO/IEC 8859 series of ASCII-based standard character encoding. It is generally intended for “Western European” languages. It is the basis for most popular 8-bit character sets, including Windows-1252 and the first block of characters in Unicode.
ISO 8859-15	8-bit single-byte coded graphic character sets. Latin alphabet No. 9, is part of the ISO/IEC 8859 series of ASCII-based standard character encoding. It is informally referred to as Latin-9. It is similar to ISO 8859-1, and thus generally intended for “Western European” languages, but replaces some less common symbols with the euro sign and some letters that were now deemed missing.
UTF-8	UTF-8 is a variable-width encoding that can represent every character in the Unicode character set. It was designed for backward compatibility with ASCII and to avoid the complications of endianness and byte order marks in UTF-16 and UTF-32. UTF-8 has become the dominant character encoding for the World Wide Web, accounting for more than half of all web pages.

Global settings

log-max-length

Specifies the maximum length of logs, in bytes. If the log exceeds this size, it will be split into several parts, each one processed successively and independently from one another.

Log rotation

Logrotate allows you to limit the size of log files in /var/log/.

For each log file, logrotate achieves 2 simultaneous operations:

• rotation: it archives the log file under another name and deletes the oldest archive;
• compression: it potentially compresses the log file before archiving it.

Prelude LML configures the rotation of log files following two criteria:

• max-rotation-size-offset;
• max-rotation-size-offset.

max-rotation-size-offset

Specifies the maximum difference, in size, between the interval of two log files rotation. If this difference is reached, a high severity alert will be emitted. The K (kbytes) or M (mbytes) suffix must be used for size definition.

max-rotation-size-offset = 1K

Note

It is necessary to indicate the unit in kbytes or mbytes.

max-rotation-time-offset

Specifies the maximum difference, in seconds, between the interval of two log files rotation. If this difference is reached, a high severity alert will be emitted.

max-rotation-time-offset = 300

warning-limit

Maximum number of warnings a given source should emit in case it can not parse log entry with the provided prefix-regex and time-format:

• -1: unlimited number of warning;
• 0! no warning at all;
• X: print at most X warnings.

Example for unlimited number of warnings:

warning-limit = -1

Some logs with a prefix not parsable are generated intentionally. When running Prelude LML, warnings are printed in the console:

27 Feb 07:50:33 (process:24720) WARNING: no appropriate format defined for log entry:
'De75c v9 2d1:2d9:5v6 devel5 sshd[17554]: Failed password for akarade from 12.34.56.78
port 4214'.

TLS settings

dh-prime-length

Number of bits for the prime used in the Diffie Hellman key exchange. The value should be one of 768, 1024, 2048, 3072 or 4096. The default is 1024.

dh-prime-length = 1024

dh-parameters-regenerate

How often to regenerate the parameters used in the Diffie Hellman key exchange. These should be discarded and regenerated once a day, once a week or once a month, depending on the security requirements, the default is 24 hours.

dh-parameters-regenerate = 24

Be careful, the generation is a CPU intensive operation. The value is in hours, 0 disables regeneration entirely.

[Pcre] section

This section defines the PCRE rules entrance point location.

ruleset = /etc/prelude-lml/ruleset/pcre.rules

This variable might be set several times if you want to define multiple PCRE entrance point locations.

ruleset = /etc/prelude-lml/ruleset/pcre.rules
ruleset = /etc/prelude-lml/ruleset/second-pcre.rules

Note

The directory where all rulesets are included is also called ruleset.

[Debug] section

This plugin issues an alert for each packet, careful to the logging activity it generates.

[Debug]

Trigger reports in the console.

stderr

stderr means standard error. It’s an output stream typically used by programs to output error messages or diagnostic.

For example, when running Prelude LML, an attempt made to log into the account is failed intentionally:

$ ssh root@localhost

Prelude LML prints the debug message in the console:

Debug: log received, log=May 23 10:42:51 localhost sshd[3726]: Failed password for root
from 127.0.0.1 port 44953 ssh2

Note

To use this feature, uncomment the line of plugin configuration in the file /etc/prelude-lml/prelude-lml.conf

Plugins configuration

Plugins configuration allows you to define how data are routed by Prelude LML. The configuration is made in the plugins.rules file located in the path /etc/prelude-lml/plugins.rules.

There are four fields to fill to configure a plugin:

• source;
• plugin;
• pcre-option;
• regex.

The logs source matching source, with input data matching regex, will be sent to the defined plugin.

Application examples:

# source             plugin  pcre-option     regex
*                    Debug   -               *
*                    Pcre    -               *
/var/log/auth.log    Plugin1 -               [Ll]ogin|[Aa]uthentication
/var/log/secure      Plgn    -               123.0.4*

The next paragraphs evoke the various possibilities for each field.

source

source should be one of the following choices:

Possible sources to configure a plugin

Variable	Description
*	Data from any sources (logfile, UDP listener, etc) is sent to “plugin”.
REGEXP	Data which sources match regular expression REGEXP is sent to “plugin”.
address:port/udp	Data received from this machine is sent to “plugin”.
/path/to/logfile	Data from this logfile is sent to “plugin”.

plugin

This field corresponds to the plugin name to use. Prelude LML comes with two plugins in the plugins.rules file:

• Debug;
• Pcre.

Note

The plugins must be called with the same name that in their section, in the /etc/prelude-lml/prelude-lml.conf file.

pcre-option

pcre-option is unsupported at the moment. The value is a dash character by default.

regex

This field allows to define the regular expression that the input data must match to be sent to the plugin.

Example:

[Ll]ogin|[Aa]uthentication

Using more than one PCRE plugin

In some cases you will try to split your log file and match different rules on the multiple log files. In order to do that you must modify the /etc/prelude-lml/prelude-lml.conf and /etc/prelude-lml/plugins.rules files. By default if you do not specify a Pcre name, there will be only one Pcre named by default.

Example:

• You have two syslog files in the following path:
  • /var/log/auth.log;
  • /var/log/syslog.
• You have three rules files:
  • ssh.rules;
  • nagios.rules;
  • sendmail.rules.

You need to create two different Pcre instances.

plugins.rules new file:

# source             plugin          pcre-option     regex
/var/log/auth.log    Pcre[first]     -               [Ll]ogin|[Aa]uthentication
/var/log/syslog      Pcre[second]    -               *

The logs sources matching auth.log file, with input data matching [Ll]ogin|[Aa]uthentication, will be sent to the Pcre[first] plugin. In the same way as, the logs sources matching syslog file, with all input data, will be sent to the Pcre[second] plugin.

New prelude-lml.conf:

[Pcre=first]
ruleset = /etc/prelude-lml/ruleset/ssh.rules
ruleset = /etc/prelude-lml/ruleset/nagios.rules

[Pcre=second]
ruleset = /etc/prelude-lml/ruleset/nagios.rules
ruleset = /etc/prelude-lml/ruleset/sendmail.rules

When you run Prelude LML you should see the loading of two modules:

23 May 15:23:18 (process:5158) INFO: PCRE plugin loaded 589 rules.
23 May 15:23:18 (process:5158) INFO: PCRE plugin loaded 11 rules.
23 May 15:23:18 (process:5158) INFO: PCRE plugin loaded 13 rules.
23 May 15:23:18 (process:5158) INFO: PCRE plugin loaded 2 rules.
23 May 15:23:18 (process:5158) INFO: PCRE plugin loaded 13 rules.
23 May 15:23:18 (process:5158) INFO: Connecting to 127.0.0.1:4690 prelude Manager server.
23 May 15:23:18 (process:5158) INFO: TLS authentication succeed with Prelude Manager.
23 May 15:23:18 (process:5158) INFO: /var/log/syslog: resuming log analyzis at offset 14989.
23 May 15:23:18 (process:5158) INFO: /var/log/auth.log: resuming log analyzis at offset 17834.

Prelude Correlator Configuration

Prelude Correlator is configured in the prelude-correlator.conf file located in the path /etc/prelude-correlator/prelude-correlator.conf.

The plugins might be configured in this file with some variables.

[general] section

This section allows to define criteria.

Only attempt to correlate input events that match the following criteria:

[general]
criteria = <IDMEF criteria>
grouping = <IDMEF path>

The criteria entry allows you to filter events based on specific IDMEF fields.

Several Prelude SIEM components use IDMEF criteria in order to provide IDMEF filtering capability.

The criteria syntax:

<IDMEF path> <operator> <value>

Example:

criteria = alert.classification.text == 'User login successful'

You can also use boolean AND/OR operators:

criteria = 'MySensor' && ('alert.assessment.impact.severity = 'high' ||
alert.assessment.impact.completion = 'succeeded')

Note

If the criteria variable is disabled, so Prelude Correlator receives all alertscoming from Prelude Manager.

The following table shows a list of available operators for criteria:

Available operators for criteria

Operator symbol	Meaning
=	Case sensitive equal
=*	Case insensitive equal
!=	Case sensitive not equal
!=*	Case insensitive not equal
~	Case sensitive regexp
~*	Case insensitive regexp
!~	Case sensitive, non matching regexp
!~*	Case insensitive, non matching regexp
<	Lesser than
<=	Lesser or equal than
>	Greater than
>=	Greater or equal than
<>	Case sensitive sub-string
<>*	Case insensitive sub-string
!<>	Case sensitive not sub-string
!<>*	Case insensitive not sub-string
||	OR (boolean)
&&	AND (bolean)

The grouping entry can be used to segment correlation depending on the value of an IDMEF field.

Example:

grouping = alert.analyzer(-1).node.location

This configuration makes it so that two alerts not originating from the same geographical location won’t be correlated with each other.

Note

This feature should be used with caution, as the number of correlation contexts in memory will rise proportionally with the number of different values for the chosen IDMEF field.

[BruteForcePlugin] section

This section is commented by default, this implies that this plugin will be enabled.

To disabled it, uncomment those lines and set the disable option to false.

[BruteForcePlugin]
disable = false

[BusinessHourPlugin] section

[BusinessHourPlugin]
disable = true

This plugin is disabled by default, as it can be very verbose.

[OpenSSHAuthPlugin] section

[OpenSSHAuthPlugin]
disable = false

[EventScanPlugin] section

[EventScanPlugin]
disable = false

[EventStormPlugin] section

[EventStormPlugin]
disable = false

[EventSweepPlugin] section

[EventSweepPlugin]
disable = false

[WormPlugin] section

[WormPlugin]
disable = false
repeat-target = 5

repeat-target is the number of times a source repeats actions taken against it recently

The default value is set to 5.

[CIArmyPlugin] section

[CIArmyPlugin]
disable = false
reload = 604800
uri = http://cinsscore.com/list/ci-badguys.txt
timeout = 10
filename = /var/lib/prelude-correlator/prelude-correlator/ciarmy.dat

reload is the frequency (in seconds) at which the database CIArmy must be downloaded and reloaded. By default, the database is reloaded once a week.

Note

If reload is set to 0, that means reloading is disabled.

uri is the server address where the CIArmy database is loaded from.

The timeout variable defines the maximum allowed time (in seconds) for downloading the database.

filename defines the location of the file containing the database.

[DshieldPlugin] section

[DshieldPlugin]
disable = false
reload = 604800
uri = http://www.dshield.org/ipsascii.html?limit=10000
timeout = 10
filename = /var/lib/prelude-correlator/prelude-correlator/dshield.dat

[SpamhausDropPlugin] section

[SpamhausDropPlugin]
disable = false
reload = 604800
uri = http://www.spamhaus.org/drop/drop.txt
filename = /var/lib/prelude-correlator/prelude-correlator/spamhaus_drop.dat

[FirewallPlugin] section

[FirewallPlugin]
disable = True
flush-protected-hosts = 3600

The flush-protected-hosts variable allows you to define how much time a given target hosts should be considered as protected when a firewall drop is noticed for this machine.

By default the value is set to 3600.

[python_rules] section

In this section, you can specify where your python rules belongs.

paths = /etc/prelude-correlator/rules/python

This will load all python files under this folder and if a Python class has the same name as the python filename, it will be loaded as a rule.

[include] section

If you need to organize your configuration files, you can load other configuration files in this section.

conf.d/*.conf

Prelude GUI configuration

This section explains how to configure the Prelude GUI.

Several configuration files exist, and are located in /etc/prewikka/:

• prewikka.conf;
• conf.d/alerts.conf;
• conf.d/auth.conf;
• conf.d/external_app.conf;
• conf.d/logs.conf;
• conf.d/riskoverview.conf.

All .conf files can contain the same sections. In this case identical sections are merged:

• If an option appears in only one section, it is taken into account;
• If an option appears in several sections, it’s the value in the last imported file (according to the order above) that is used.

Note

Both these points are valid only if the sections with the same name are not commented.

Main configuration

The main configuration is made in the /etc/prewikka/prewikka.conf file.

[general] section

The help_location option defines the URL used for building the contextual help link.

help_location: http://doc.prelude/rst/${lang}/${path}

The heartbeat_count option defines the number of heartbeats to analyze in the heartbeat analysis view:

heartbeat_count: 30

If the offset between two heartbeats is off by more than the specified offset (in seconds), the analyzer will be represented as offline. The offset is defined by heartbeat_error_margin option:

heartbeat_error_margin: 3

This option allows to open external links in a new window (references, IP lookup, and port lookup):

external_link_new_window: yes

Enable the links giving more information about an IP / domain, a port, a protocol, and a reference on an alert (no by default):

enable_details: no

Enables display of the python traceback on error (set to yes by default):

enable_error_traceback: yes

Script link providing more details about an IP or a domain of an alert:

host_details_url: https://www.prelude-siem.com/host_details.php

An IP address will be passed as an argument in the URL as:

https://www.prelude-siem.com/host_details.php?host=127.0.0.1

Script link providing more details about a port and protocol for an alert:

port_details_url: https://www.prelude-siem.com/port_details.php

A port and a protocol will be passed in argument in the URL as:

https://www.prelude-siem.com/port_details.php?port=2048&protocol=tcp

Script link providing more details about the reference of an alert.

reference_details_url: https://www.prelude-siem.com/reference_details.php

The origin of the reference, its name, as well as its URL will be passed in argument in the URL as:

http://www.prelude-siem.com/reference_details.php?origin=vendor-specific&name=MyName&url=http://vendor-site.com

When the number of classifications, sources or targets exceeds the defined value, an expansion link will be provided to look up the remaining entry.

The default values for these options are the following:

max_aggregated_source: 3
max_aggregated_target: 3
max_aggregated_classification: 10

Asynchronous DNS resolution

The asynchronous DNS resolution requires the python modules:

• twisted.names;
• twisted.internet.

While rendering view containing address scheduled for asynchronous DNS resolution, it ispossible that the rendering terminate too fast for all DNS requests to complete.

The dns_max_delay setting determines the Prelude GUI behavior. The possible values are the following:

• -1: No DNS resolution performed;
• 0: Sends results to the client immediately;
• x: Waits at most x seconds, then sends results to the client, ‘x’ being an integer.

By default, the value is fixed to 0.

dns_max_delay: 0

Default language to use. By default, the Prelude GUI is set in English:

default_locale: en_GB

The supported locales are:

Available languages for Prelude GUI

Value	Associated language
de_DE	German
en_GB	English
es_ES	Spanish
fr_FR	French
it_IT	Italian
pl_PL	Polish
pt_BR	Portuguese (brazilian)
ru_RU	Russian

Theme to use. Set to cs by default:

default_theme: cs

There are other supported themes such as:

• blue;
• bright;
• classic;
• cs;
• dark;
• green;
• yellow.

Timezone to use by default when creating a new user:

default_timezone: UTC

Encoding to use. Set to utf8 by default:

encoding: utf8

It is possible to change the encoding according to the selected language.

Refer to the table Languages available for Prelude GUI to see others possible encoding.

Public path to the Prelude GUI in case the application is being served through a reverse proxy, including any necessary port information. Commented by default:

reverse_path: http://example.com/proxied/prelude/

[interface] section

Some interface elements are customizable using the following options:

• software: software name displayed in the top left corner (displays a logo if this option is not defined);
• browser_title: webpage title.
• menu_order: YAML file containing the menu layout. Refer to the section Menu settings.

By default, thoses options are commented:

# [interface]
# software: Prelude
# browser_title: Prelude SIEM
# menu_order: menu.yml

Customizable links

It is possible to add custom links on a host, classification, or date in the respective columns in the alert view.

These links are arranged in 3 different sections:

• [url host]: defines links on a host;
• [url classification]: defines the links on a classification;
• [url time]: defines the links on a date.

Example:

[url host]
link1: http://my-url.com

[url classification]
link2: http://another-url.com

[url time]
link3: http://url3.com

These links will take the form of a button when you click on one of the aforementioned elements. The button text is the name of the key.

The links can contain the variable $value, which will be replaced when the button is generated. The meaning of this variable depends on the section:

Variable	Section	Description
$value	host	IP address / hostname
	classification	Classification name
	time	Analyzer time

Table: meaning of the dynamic links variables

Example:

[url classification]
Search classification: http://google.com/#q=$value

[url host]
Inventory: http://my-assets.com/?host=$value

[url time]
Archive: http://my-archive/?start=$value

It is possible to create several links in the same section by declaring several entries, provided you have a different key for each link.

Example:

[url classification]
Search classification: http://google.com/#q=$value
Knowledge base: http://my-kbbase.com/?event=$value

Databases

[idmef_database] section

The database where the Prelude GUI reads the stored alerts by Prelude Manager.

[idmef_database]
type = <pgsql | mysql | sqlite3>
# for sqlit3, add the 'file' option
# file: /path/to/base/sqlite.db
host = <database host>
name = <database name>
user = <username for the database connection if necessary>
pass = <password associated with the username>

Example:

[idmef_database]
type: pgsql
host: localhost
user: prelude
pass: prelude
name: prelude

[database] section

Database required by Prelude GUI to save user preferences, users, and internal configuration variables.

[database]
type = <pgsql | mysql | sqlite3>
# for sqlit3, add the 'file' option
# file: /path/to/base/sqlite.db
host = <database host>
name = <database name>
user = <username for the database connection if necessary>
pass = <password associated with the username>

Example:

[database]
type: pgsql
host: localhost
user: preludegui
pass: preludegui
name: preludegui

Logging

Prelude GUI generates its own logs. You can activate several log sections.

The log level might be set to:

• all/debug;
• info;
• warning;
• error;
• critical.

If unspecified, the default level is set to warning. The following sections are part of the default configuration of the Prelude GUI.

[log stderr] section

This section allows to report logs of the Prelude GUI on the standard error.

[log stderr]
level: all

[log file] section

This section allows to report debug logs of the Prelude GUI in a file.

[log file]
level: debug
file: /tmp/prewikka.log

In this example, debug logs are now available in the /tmp/prewikka.log file.

[log syslog] section

This section allows to report logs of the Prelude GUI on the syslog format.

[log syslog]
level: info

[log nteventlog] section

This section writes logs of the Prelude GUI to the Windows Event log.

[log nteventlog]
level: info

[log smtp] section

This section allows to report logs of the Prelude GUI by emails.

[log smtp]
level: warning
host: mail.domain.com
from: user@address
to: recipient1@address, recipient2@address, recipientN@address
subject: Subject to use

Crontab configuration

This sections allows to define cron tasks. These cron tasks need to be enabled in Prelude GUI to be executed.

[cron alert] section

This section allows to define the periodic deletion of alerts. The age parameter is used to define the minimal retention period (in days) for alerts. The oldest alerts will be deleted. The default is not to delete any alert. It is possible to define this value per alert severity.

[cron alert]
age: 30
high: 365
medium: 90
low: 30
info: 7

[cron heartbeat] section

This section allows to define the periodic deletion of heartbeats. The age parameter is used to define the minimal retention period (in days) for heartbeats. The oldest heartbeats will be deleted. The default is not to delete any heartbeat.

[cron heartbeat]
age: 7

[cronsearch_history] section

This section allows de define the periodic deletion of search history. The size parameter allow the configuration of the number of saved searches per user. This parameter is set to 10 by default.

[cron search_history]
size: 10

[include] section

This section allows to include files. This section imports additional configuration files for the the Prelude GUI.

[include]
conf.d/*.conf

Menu settings

This section describes how to set Prelude GUI menus.

By default, the /etc/prewikka/menu.yml file is used to customize Prelude GUI’s menus.

The file to use is defined through the menu_order option of the prewikka.conf file.

The format used is YAML, which represents menus in the form of lists and sublists. There are 3 levels of indentation:

1. A menu may have several categories;
2. A category may have several sections;
3. A section can have multiple tabs.

Example:

- name: Menu1
  categories:
      - name: Categorie 1
        sections:
            - name: Section 1
              tabs:
                  - Onglet 1
                  - Onglet 2
            - name: Section 2
              tabs:
                  - Onglet 1
                  - Onglet 2
- name: Menu2
  categories:
      - sections:
            - name: Section 1
              tabs:
                  - Onglet 1

Note

A category may not have a name, the Menu2 category does not.

Keywords can be added at certain levels to further customize the menu.

Keywords available from the menu customization

Keyword	Indentation level	Possible value	Description
icon	1 and 2	Those on http://fontawesome.io/icons/	Allows you to add an icon to the menu entry.
default	1	true	Allows you to define a default menu where the views that do not have an entry in the menu will be stored.
default_tab	3	Name of the default tab (name of the view)	Allows you to set the default tab of a section.
expand	3	true	Allows you to specify that the section contains several views to be displayed in the menu, by unfolding the menu when hovering the mouse.

Example:

- name: Utilisateur
  icon: user
  categories:
      - sections:
            - name: Préférences
              icon: key
              expand: true
              default_tab: Permissions
              tabs:
                  - Changer mot de passe
                  - Timezone
                  - Permissions
                  - Changer e-mail
- name: Autres
  icon: question
  default: true

Additional configuration: external_app.conf file

[appli app1] section

It is possible to declare external applications and display them inside Prelude GUI through an iframe.

These settings are required when importing an application:

Configuration of an external application

Key	Description
permission	Existing or custom permission. Non-existing permissions are created on the fly.
section	Name of the section to store the application. Refer to Menu settings
base_url	URL of the external application
tab	Name of the view tabs, each view can have one or more tabs. Refer to Menu settings
tab_html	URLs for tabs, absolute or relative based on base_url
help	Link provided in the contextual link

Example:

[appli app1]
permission: APP1_VIEW
section: Application1
base_url: http://app1/
tab: tab1, tab2
tab_url: http://app1/tab1, http://app1/tab2
help: http://app1/help.html

Additional configuration: logs.conf file

[elasticsearch] sections

Prelude SIEM uses the Elasticsearch solution for log management. For more information about this solution, refer to its documentation: https://www.elastic.co/guide/index.html

It is possible to configure the date format expected by Elasticsearch. By default, the date format is ISO.

es_timeformat: %Y-%m-%d %H:%M:%S

A section should provide:

• es_type: instance type (“log” in case of logs);
• es_url: URL, with the index, of Elasticsearch;
• es_user: user name required for connection;
• es_pass: password required for login.

Example:

[elasticsearch log1]
es_url: http://my-elasticsearch:9200/index-*
es_type: log
es_user:
es_pass:

It is possible to configure several sections of this type, typically for managing a multi-tenant organization. In this example, “log1” is the name which will be used in the GUI for identifying this instance.

Port 9200 is the default port of Elasticsearch, and must be changed to match the value set when you installed and configured Elasticsearch.

Indexes can contain wildcards.

This section also contain fields defined by the Elasticsearch indexes and those recognized by Prelude GUI. Here, a key can have up to two values, thus enabling the field to be used during a standard query and an aggregated query. If only one field is entered, or if the second field does not match what is found in the result of the aggregated query, the first field will be used:

program: syslog_program, syslog_program.raw
host: syslog_hostname, syslog_hostname.raw
message: syslog_message
timestamp: @timestamp

Note

The configuration file contains, by default, the fields required for logs. However, your Elasticsearch indexes may have more fields. If you want these fields to appear in the Archive interface, it is up to you to add them in the configuration, using the same system as above.

Additional configuration: auth.conf file

The session modules

[session loginform] section

Allows you to log on from the authentication form. The user enters his or her username and password in a standard web form.

The value of the expiration key determines, in minutes, the duration of a session before expiration.

The value of the footer key controls the contents of the page footer. The $version variable will be replaced by the product version.

expiration: 60
footer: Prelude SIEM $version

[session anonymous] section

This section disables the Prelude GUI authentication, so authentication is notrequired. Commented by default to force the authentication.

[session anonymous]

The authentication modules

Retrieve the list of the Prelude GUI users through two kind of backend: database or LDAP.

[auth dbauth] section

Only users in the Prelude GUI database are allowed to connect.

If there is no user with administrative rights defined in the database, the initial userwill be created according to these settings:

[auth dbauth]
initial_admin_user: admin
initial_admin_pass: admin

Additional configuration: alerts.conf file

[datasearch alert] section

This section is used to add complementary fields in the alert table. It is possible to add any IDMEF field.

extra_fields = alert.messageid, alert.classification.text

Additional configuration: riskoverview.conf file

[riskoverview] section

This section is used to enable or disable entries in the Risk Overview.

agents
tickets
archive
threats

Glossary & abbreviations

Glossary

List of terms used by Prelude SIEM. Several terms derive from the IDMEF standard.

Agent

A software or equipment using the Libprelude able to directly generate IDMEF alerts and heartbeats. It can be an analyzer or a manager.

Alert

A data structure describing a security incident technically. It contains information about:

• Its classification;
• The sensor from which it originates;
• The time of detection/creation;
• Its source and its target;
• Its assessment (impact of the event).

It can be a simple alert or the grouping of related alerts into a “correlated alert”.

Analyzer / Sensor

The emission source of an alert message.

This definition can be extended to cover not only Prelude agents (Prelude LML, Prelude Correlator, Snort, Samhain, etc.) but also services (web server, PAM, ssh, antivirus, etc.) that write in logs instead of emitting alerts.

Path

In Prelude SIEM, the paths correspond to a simple syntax that can be used to reference the value of a field in a data structure (IDMEF alert, log entry, incident ticket, etc.). With this mechanism you can update or retrieve the value the path points to.

In particular, all classes and attributes defined in the IDMEF can be converted to paths usable by Prelude SIEM. For instance, the path alert.classification.text can be used to reference the text attribute of the Classification IDMEF class, the latter being an aggregated class of the Alert IDMEF class.

Ruleset

A ruleset is a file containing a set of rules related to the same functional field (software, equipment, etc.).

Libprelude

Libprelude is a programming library that guarantees secure connections between Prelude analyzers (Prelude LML, Prelude Correlator, Snort, etc.) and the Prelude Manager. Libprelude provides an API for communication with Prelude sub-systems. It supplies the necessary functionality for generating and emitting IDMEF alerts and automates the saving and re-transmission of data in times of temporary interruption of one of the system’s components.

LibpreludeDB

The libpreludeDB programming library provides an abstraction layer upon the type and the format of the database used to store IDMEF alerts. It allows developers to use the Prelude SIEM database easily and efficiently without worrying about its type or storage format.

Location

The physical site of one or several nodes.

Example: Paris

Node

An equipment that hosts one or several analyzers/managers, identified by a network address or a name.

Example: 192.168.2.1

Prelude Correlator

Prelude Correlator allows conducting multi-stream correlation thanks to a powerful programming language for writing correlation rules. It has the ability to connect and fetch alerts from a remote Prelude Manager, and correlate incoming alerts based on the provided ruleset. Upon successful correlation, IDMEF correlation alerts are raised.

Prelude GUI

Prelude GUI is the official graphical user interface for Prelude SIEM exploitation. Providing numerous features, it facilitates the work of operators and analysts, and also provides access to external tools.

Prelude LML

Prelude LML is a log analyzer allowing Prelude SIEM to collect and analyze information from all kinds of sources (applications or appliances) emitting logs or syslog messages, in order to detect suspicious activities and normalize them to IDMEF format.

Prelude Manager

Prelude Manager is the heart of Prelude SIEM and is generally called manager. It concentrates all IDMEF messages from agents, be it alerts or heartbeats.

The manager processes the received data in real time by inserting them for example into a database. It can also act as a relay, i.e. forward the messages to another manager. It is also responsible of transmitting alerts to the correlator.

Heartbeat

A message sent in at regular intervals by agents to their attributed managers, in order to indicate their status (starting, running, stopping, etc).

The lack of some number of consecutive heartbeats indicates a failure of either the agent or its network connection.

Syslog

In computing, Syslog is a standard for message logging. It allows separation of the software that generates messages, the system that stores them, and the software that reports and analyzes them.

Abbreviations

Definitions of abbreviations

Abbreviations	Description
API	Application Programming Interface
HIDS	Host Intrusion Detection System
IDS	Intrusion Detection System
IDMEF	Intrusion Detection Message Exchange Format
LML	Log Monitoring Lackey
HMI	Human to Machine Interface
NIDS	Network Intrusion Detection System
PCRE	Perl Compatible Regular Expression
SIEM	Security Information & Event Management
SOC	Security Operations Center
TLS	Transport Layer Security
N/A	Not applicable

Annex: IDMEF criteria and paths

IDMEF criteria

Filter creation with IDMEF criteria

IDMEF criteria are filters on IDMEF fields. Several Prelude SIEM components use IDMEF criteria:

• Prelude Manager is distributed with the idmef-criteria plugin, which can be installed and used with IDMEF criteria. It is possible to define specific actions to be executed based on an incoming event (relaying, storage in a specific database, etc.).
• Prelude GUI allows the user to define criteria in order to filter the results of a search or an analysis.

IDMEF criteria syntax

<IDMEF Path> <operator> <value>

Simple example:

alert.analyzer(-1).name = 'MySensor'

AND and OR operators can be used:

alert.analyzer(-1).name = 'My Sensor' && ('alert.assessment.impact.severity
= 'high' || alert.assessment.impact.completion = 'succeeded')

IDMEF paths

In Prelude SIEM, an IDMEF path is a pointer to a specific value in an IDMEF message.

Using this pointer, you can update or retrieve the value pointed by that path.

Any class specified in the IDMEF RFC can be converted to an IDMEF path.

Mapping an IDMEF class to an IDMEF path

When mapping an IDMEF class to a IDMEF path, you should obey the following rules:

• IDMEF paths must be written in lowercase;
• Subsequent elements of an access path must be separated using dots .;
• Wherever the IDMEF class uses uppercase letters for word separation, Prelude SIEM uses an underscore _;
• In case a path element is a list, you can use a specific index between brackets to access the element, for example: alert.source(0).node.name.

Indexed elements

When accessing a list (e.g.: alert.source, alert.additional_data, etc.), the index must be specified as a number. When retrieving a value, the specified index must exist in the list.

In the context of an assignment, the first unassigned index of the list can also be used. For example, if alert.source(0) and alert.source(1) are defined, you may use either 0, 1, or 2 as the index to assign data, but not 3.

Note

You may also use negative indexes (-1, -2, -n, …) to access elements starting from the end of the list.

In this case, -1 points to the last element of the list, -2 to the penultimate, etc.

Note

Additionally, in the context of an assignment, you might use the >> (append) or << (prepend) operators.

alert.source(>>).interface = eth1
alert.source(-1).node.name = myNode

The example above appends a new source object to the alert.source list, by setting the value of the interface attribute to eth1. It then sets the node.name attribute of this new entry to myNode.

Annex: Configuration files

Global configuration file: global.conf

[prelude]

# This is the default configuration for all programs
# (sensors, agents, and manager) using libprelude.
#
# Entry in this configuration file might be overriden by entry directly
# provided by the respective program configuration file.

#
# Set heartbeat interval, the default value is 600 seconds (10 minutes).
#
# heartbeat-interval = 600


#
# Optional data carried with alert/heartbeats.
#
# analyzer-name = Name for the analyzer
# node-name = Name of the equipment
# node-location = Location of the equipment
# node-category = Type of node:
#
# unknown            Domain unknown or not relevant
# ads                Windows 2000 Advanced Directory Services
# afs                Andrew File System (Transarc)
# coda               Coda Distributed File System
# dfs                Distributed File System (IBM)
# dns                Domain Name System
# hosts              Local hosts file
# kerberos           Kerberos realm
# nds                Novell Directory Services
# nis                Network Information Services (Sun)
# nisplus            Network Information Services Plus (Sun)
# nt                 Windows NT domain
# wfw                Windows for Workgroups


# Address contained by this node,
# You may have several addresses.
#
# [Node-Address]
#
# address = Address of the equipment
# netmask = Netmask for this address
# vlan-name = Name of the Virtual LAN to which the address belongs
# vlan-num = Number of the Virtual LAN to which the address belongs
#
# category = Type of address represented
#
# Permitted values for category are (default to unknown) :
#
# unknown            Address type unknown
# atm                Asynchronous Transfer Mode network address
# e-mail             Electronic mail address (RFC 822)
# lotus-notes        Lotus Notes e-mail address
# mac                Media Access Control (MAC) address
# sna                IBM Shared Network Architecture (SNA) address
# vm                 IBM VM ("PROFS") e-mail address
# ipv4-addr          IPv4 host address in dotted-decimal notation (a.b.c.d)
# ipv4-addr-hex      IPv4 host address in hexadecimal notation
# ipv4-net           IPv4 network address in dotted-decimal notation, slash, significant bits (a.b.c.d/nn)
# ipv4-net-mask      IPv4 network address in dotted-decimal notation, slash, network mask in dotted-decimal notation (a.b.c.d/w.x.y.z)
# ipv6-addr          IPv6 host address
# ipv6-addr-hex      IPv6 host address in hexadecimal notation
# ipv6-net           IPv6 network address, slash, significant bits
# ipv6-net-mask      IPv6 network address, slash, network mask

Client configuration file: client.conf

[prelude]

# This is the default configuration for program client of a manager
# (sensors and agents) that uses libprelude.
#
# Entry in this configuration file might be overriden by entry directly
# provided by the sensors/agents configuration file.


# Try to connect on a Manager listening on 127.0.0.1.
#
# server-addr = x.x.x.x:port || y.y.y.y && z.z.z.z
#
# This mean the emission should occur on x.x.x.x:port or, if it fail,
# on y.y.y.y and z.z.z.z (if one of the two host in the AND fail,
# the emission will be considered as failed involving saving the
# message locally).

server-addr = 127.0.0.1


# The following settings instruct the operating system when to consider
# a connection dead in case sent data is left unacknowledged.
#
# These options are operating system specific, and might not work on
# certain platform. In case you modify these settings on an unsupported
# system, a warning message will be issued when the agent starts.
#
# Under Linux, the default system wide configuration is:
# tcp-keepalive-time   = 7200
# tcp-keepalive-probes = 9
# tcp-keepalive-intvl  = 75
#
# tcp-keepalive-time represents the number of seconds the connection
# needs to be idle before TCP begins sending out keep-alive probes.
#
# tcp-keepalive-probes represents the number of not acknowledged probes
# to send before considering the connection dead.
#
# tcp-keepalive-intvl represents the interval between subsequent
# keepalive probes.
#
# The average time to notice a dead connection can be calculated using:
# tcp-keepalive-time + (tcp-keepalive-probes * tcp-keepalive-intvl)
#
# Here is an example configuration:
# tcp-keepalive-time   = 60
# tcp-keepalive-probes = 3
# tcp-keepalive-intvl  = 10
#
# Using the above settings, a dead connection will be detected within
# 90 seconds.


#
# TLS options (only available with GnuTLS 2.2.0 or higher):
#
# Sets priorities for the ciphers, key exchange methods, macs and
# compression methods.
#
# "NORMAL" option enables all "secure" ciphersuites. The 256-bit
# ciphers are included as a fallback only. The ciphers are sorted by
# security margin.
#
# "SECURE128" flag enables all "secure" ciphersuites with ciphers up to
# 128 bits, sorted by security margin.
#
# "SECURE256" flag enables all "secure" ciphersuites including the 256
# bit ciphers, sorted by security margin.
#
# "EXPORT" all the ciphersuites are enabled, including the low-security
# 40 bit ciphers.
#
# "NONE" nothing is enabled. This disables even protocols and
# compression methods.
#
# Note that much more settings might be enabled or disabled using this
# option: please see gnutls_priority_init(3) for more details.
#
# The default settings is "NORMAL".
# tls-options = NORMAL

IDMEF client configuration file: idmef-client.conf

include = /usr/local/etc/prelude/default/global.conf
include = /usr/local/etc/prelude/default/client.conf

TLS configuration file: tls.conf

#
# Default size of the client/server generated private key
#
generated-key-size = 2048

#
# Number of days the authority certificates (server side) will
# remain valid. These certificates are only used in order to
# sign client certificate.
#
# Use 0 for the maximum possible value.
#
authority-certificate-lifetime = 0

#
# Number of days the generated certificates (client side) will
# remain valid. These certificates are only used in order to
# authenticate and encrypt client <-> server communication.
#
# Use 0 for the maximum possible value.
#
generated-certificate-lifetime = 0

Prelude Manager configuration file: prelude-manager.conf

# Prelude Manager configuration file.
#
# <IMPORTANT>
#
# Sections are important, and things won't work correctly if they are
# not un-commented. For example you need to uncomment [db] if you want
# the database plugin to be loaded.
#
# </IMPORTANT>


include = @LIBPRELUDE_CONFIG_PREFIX@/default/global.conf


# Address where the prelude-manager server is listening on.
# if value is unix, or unix:/path/to/unix/socket, an UNIX domain socket
# will be used.
#
# Multiple listen address are supported.
#
# listen = address:port
# listen = unix:/tmp/prelude-manager.socket
# listen = unix
#
listen = 127.0.0.1


# Sets the user/group ID as which prelude-manager will run.
# In order to use this option, prelude-manager must be run initially as
# root
#
# user = prelude-manager
# group = prelude


# Number of seconds prelude-manager waits for an incoming client to
# successfully authenticate before dropping the connection.
#
# connection-timeout = 10


#
# Scheduler settings for Prelude-Manager
#
# On systems with many concurrent sensors sending events to
# Prelude-Manager, Prelude-Manager might have a hard time keeping up
# with the demand for events reporting.
#
# The Prelude Manager scheduler allocate reporting time per sensor,
# allowing to define the maximum number of events processed for one
# sensor before processing others sensors events (in case a sensor is
# sending a continuous events burst, this prevents other sensors'
# starvation).
#
# By default, for each sensor connected, a maximum of 100 events will
# be processed before processing others sensors events.
#
# Additionally, priority will be given to events depending on their
# priority. Assuming there is enough events of each priority, 50 high
# priority messages will be processed, 30 medium, and 20 low (totalling
# the maximum of 100 described above).
#
# You might use the sched-priority option in order to change this
# setting:
#
# sched-priority = high:50 medium:30 low:20
#
#
# When the number of events waiting to be processed exceeds the defined
# amount of reserved memory (default is 1 Megabyte), Prelude-Manager
# will start storing events on disk:
#
# sched-buffer-size = 1M


#
# TLS options (only available with GnuTLS 2.2.0 or higher):
# sets availables ciphers, key exchange methods, macs and compression
# methods.
#
# "NORMAL" option enables all "secure" ciphersuites, 256-bit ciphers
# included.
#
# "SECURE128" flag enables all "secure" ciphersuites with ciphers up to
# 128 bits.
#
# "SECURE256" flag enables all "secure" ciphersuites including the 256
# bit ciphers.
#
# "EXPORT" all the ciphersuites are enabled, including the low-security
# 40 bit ciphers.
#
# "NONE" nothing is enabled. This disables even protocols and
# compression methods.
#
# Note that much more settings might be enabled or disabled using this
# option: please see gnutls_priority_init(3) for more details.
#
# The default settings is "NORMAL".
# tls-options = NORMAL


#
# Number of bits of the prime used in the Diffie Hellman key exchange.
# Note that the value should be one of 768, 1024, 2048, 3072 or 4096.
# The default is 1024.
#
# dh-prime-length = 1024


# How often to regenerate the parameters used in the Diffie Hellman key
# exchange. These should be discarded and regenerated once a day, once
# a week or once a month. Depending on the security requirements.
#
# Generation is a CPU intensive operation. The value is in hours,
# 0 disables regeneration entirely. The default is 24 hours.
#
# dh-parameters-regenerate = 24


# If you want this Manager to retrieve messages from another Manager
# (useful if the other Manager is located within a DMZ):
#
# child-managers = x.x.x.x
#
# This means the messages should be gathered from x.x.x.x

#
# If you want a given reporting plugin to be protected against possible
# failure, use the failover option. Failover will prevent data sent to
# the report plugin to be lost in case this one fail.
#
# You might use this option multiple time for different plugins.
#
# failover = name_of_plugin


#
# Events normalization parameters
#
# Un-comment the following section in case you want to define any
# normalization parameters:
#
# [normalize]
#
# For each incoming events, Prelude-Manager will run a number of
# normalization routine: sanitize address, services information, etc.
#
# When the normalizer sees an incoming IPv4 mapped IPv6 address, the
# default behavior is to map it back to raw IPv4. For example,
# ::ffff:192.168.0.1 will be mapped back to 192.168.0.1
#
# If you do not want IPv4 mapped IPv6 addresses, un-comment the
# following option:
#
# keep-ipv4-mapped-ipv6
#
# Alternatively, if you wish for any input IPv4 addresses to be
# converted to IPv6, un-comment the following option:
#
# ipv6-only
#
#
# Prelude-Manager normalizer can add geolocation information to events
# when libmaxminddb support is enabled, and the path to the maxminddb
# database is provided.
#
# geoip-database = /path/to/your/geoip_mmdb_file


####################################
# Here start plugins configuration #
####################################

# [relaying]
#
# If you want the message caught by this manager to be relayed.
# You can use boolean AND and OR to make the rule.
#
# parent-managers = x.x.x.x || y.y.y.y && z.z.z.z
#
# This means the emission should occur on x.x.x.x or, if it fails, on
# y.y.y.y and z.z.z.z (if one of the two hosts in the AND fail, the
# emission will be considered as failed involving saving the message
# locally).


# [db]

# The type of database: mysql, pgsql or sqlite3.
# type = mysql

# Only if you use sqlite3.
# file = /your/path/to/your/db/idmef-db.sql

# Host the database is listening on.
# host = localhost

# Port the database is listening on.
# port = 3306

# Name of the database.
# name = prelude

# Username to be used to connect the database.
# user = prelude

# Password used to connect the database.
# pass = xxxxxx



# [XmlMod]
#
# The Xmlmod plugin allows to report alerts as IDMEF XML in a file,
# or to dump these alerts to /dev/stdout.
#
# The default behavior is to write output to /dev/stdout.
#
# Tells Xmlmod to disable output file buffering.
# This will prevent XML alerts to be truncated and thus make real-time
# parsing easier:
#
# disable-buffering
#
#
# Tells Xmlmod to check generated XML against IDMEF DTD:
# validate
#
# Tells Xmlmod to produce a pretty, human-readable xml output:
# format
#
# logfile = /dev/stdout
# logfile = /var/log/prelude/prelude-xml.log



# [Debug]
#
# The Debug plugin allows to report alerts as text in a file,
# or to dump these alerts to /dev/stdout.
#
# The default behavior is to write output to /dev/stdout.
#
# logfile = /dev/stdout
# logfile = /var/log/prelude/prelude-debug.log
#
# You can specify the name of the IDMEF object to print (you might
# select multiple objects). If no object is provided, 'Debug' will
# print out the entire message.
#
# object = alert.classification.text, alert.source(0).node.address(0).address


# [TextMod]
#
# The TextMod plugin allows to report alerts as text in a file,
# or to dump these alerts to /dev/stdout.
#
# The default behavior is to write output to /dev/stdout.
#
# logfile = /dev/stdout
# logfile = /var/log/prelude/prelude-text.log


# [script]
#
# This plugin allows to execute commands depending on the received alerts.
# If an IDMEF path is prefixed by a dollar symbol, it will be replaced
# by the corresponding value in the alert.
#
# command = /path/to/the/script $alert.classification.text


#[smtp]
#
# Sender to use for the mail message.
# sender = prelude@myhostname.
#
# Who the mail should be sent to.
# recipients = recipient1@hostname, recipient2@hostname
#
# SMTP server to use for sending mail
# smtp-server = localhost
#
# By default, the SMTP plugin sends mail containing the whole IDMEF
# event. If you wish to send a subset of the information, you may
# customize the content of the generated mail through several options:
#
# You can define a specific subject to use with mail notification.
# The subject can include information from the event using IDMEF path.
# subject = Alert: $alert.classification.text
#
# You can define a specific message body to use for mail notification.
# As with the "subject" option, the template can include information
# from the event using IDMEF path.
#
# (Template example available in @DOCDIR@/smtp/template.example)
# template = /path/to/my/template
#
# You can provide your database settings here, so that the SMTP plugin
# retrieves alerts linked to received CorrelationAlert from the database.
#
# dbtype = mysql
# dbname = prelude
# dbuser = prelude
# dbpass = passwd
# dbhost = localhost
# Other database options available include dbport, and dbfile (for
# sqlite3 database).
#
# If you have specified your database settings above, you can also
# use the correlated-alert-template option, which is like the "template"
# option but is specific to Correlated Alerts retrieved from database.
#
# (Template example available in @DOCDIR@/smtp/template.example)
# correlated-alert-template = /path/to/my/template


#[snmp]
#
# Trap recipient.
# A specific port may be given using the suffix ":port", eg. "localhost:16162".
# To force the use of an IPv6 transport, add an "udp6:" prefix
# and put IPv6 addresses between brackets. Eg. "udp6:[::1]".
#
# traphost = localhost
#
# Protocol version to use (either v1, v2c or v3).
# version = v3
#
# SNMP community (v1/v2c only).
# community = public
#
# Security username.
# sec-name = sec-name-not-configured
#
# Security level (either noAuthNoPriv, authNoPriv or authPriv).
# sec-level = authPriv
#
# Authentication protocol (either MD5 or SHA1).
# auth-protocol = SHA1
#
# Authentication passphrase.
# auth-key = snmp-authentication-key
#
# Privacy protocol (either DES or AES).
# priv-protocol = AES
#
# Privacy passphrase.
# priv-key = snmp-privacy-key
#
# Engine Identifier, as an hexadecimal string.
# The raw engine ID must be 5-32 characters long and unique across the network.
# If omitted, a new random identifier is automatically generated each time
# the manager starts.
# engineid = 0x1234567890


####################################
# Filtering plugins configuration  #
####################################

# The idmef-criteria filtering plugin allows you to filter events based
# on specific IDMEF-Criteria.
#
# [idmef-criteria]
# rule = alert.classification.text == 'User login successful'
# hook = relaying[default]
#
# Will forward any event that match the defined criteria to the
# default instance of the relaying reporting plugin. The rule argument
# might also be a filename containing the rules. Example:
#
# rule = /path/to/rule.file


# The thresholding filtering plugin allows you to suppress events based
# on their value.
#
# [thresholding]
# path = alert.classification.text, alert.source.node.address.address
# limit = 3600
# count = 1
# hook = relaying[default]
#
# Will forward one event with the unique alert.classification.text,
# alert.source.node.address.address value combination to the 'default'
# instance of the 'relaying' reporting plugin. Further events with the
# same value will be suppressed for 3600 seconds.
#
#
# [thresholding]
# path = alert.classification.text, alert.source.node.address.address
# threshold = 3600
# count = 10
# hook = relaying[default]
#
# Will forward every tenth event per 3600 seconds with the unique
# alert.classification.text, alert.source.node.address.address value
# combination to the 'default' instance of the 'relaying' reporting
# plugin.
#
# Note that limit and threshold might be combined, allowing to setup a
# limit as soon as the first threshold is reached.
#
# By default, we only pass up to 100 occurrences of the same alert
# (same source, target and classification combination) every 2 minutes
# to reporting plugins (eg. to the database).
[thresholding]
path = alert.classification.text, alert.source.node.address.address, alert.target.node.address.address
limit = 120
count = 100
hook = reporting


####################################
# Prelude generic configuration    #
####################################

# [prelude]
#
# This is the global prelude section, where you can define Prelude
# related options. Option of matter for Prelude-Manager, are, most
# specifically, in the context of relaying, the connection options:
#
# The following settings instruct the operating system when to consider
# a connection dead in case sent data is left unacknowledged.
#
# These options are operating system specific, and might not work on
# certain platforms. In case you modify these settings on an unsupported
# system, a warning message will be issued when the agent starts.
#
# Under Linux, the default system wide configuration is:
# tcp-keepalive-time   = 7200
# tcp-keepalive-probes = 9
# tcp-keepalive-intvl  = 75
#
# tcp-keepalive-time represents the number of seconds the connection
# needs to be idle before TCP begins sending out keep-alive probes.
#
# tcp-keepalive-probes represents the number of not acknowledged probes
# to send before considering the connection dead.
#
# tcp-keepalive-intvl represents the interval between subsequent
# keepalive probes.
#
# The average time to notice a dead connection can be calculated using:
# tcp-keepalive-time + (tcp-keepalive-probes * tcp-keepalive-intvl)
#
# Here is an example configuration:
# tcp-keepalive-time   = 60
# tcp-keepalive-probes = 3
# tcp-keepalive-intvl  = 10
#
# Using the above settings, a dead connection will be detected within
# 90 seconds.

Prelude LML configuration file: prelude-lml.conf

##############################################
# Configuration for the Prelude LML Sensor   #
##############################################

include = @LIBPRELUDE_CONFIG_PREFIX@/default/idmef-client.conf


# Address where the Prelude Manager Server is listening on.
# if value is "127.0.0.1", the connection will occur through
# a UNIX socket.
#
# This entry is disabled. The default is to use the entry
# located in the Prelude system-wide clients.conf. You may
# overwrite the default address for this sensor by uncommenting
# this entry.
#
# [prelude]
# server-addr = 127.0.0.1


# FILES TO MONITOR
#
# You should define the log message prefix-regex and time-format within
# a [format] section. If not specified, the default syslog format will
# be used.
#
# The prefix-regex should contain PCRE named subpatterns to pick out the
# information available in your syslog's prefix.
#
# The available field names are:
#   - hostname
#   - process
#   - pid
#   - timestamp
#
# Please see pcrepattern(3) manpage for help writing the prefix-regex.
# In order to set the time-format, please have a look at the strptime(3)
# manpage.
#
# Example configuration for syslog output:
#
# Each [format] section might have several file entries.
# Each [format] section might have several udp-server entries.
#
# If a file or udp-server entry is listed across different formats,
# then the first matching format for a given log entry will be used.
#
# Additionally, you can specify a pattern in a file entry. LML will then
# search for all the pathnames matching the pattern according to the rules
# used by the shell (see glob(7)).
#
# Example: file = /var/log/*/*.log
#


# CHARACTER ENCODING
#
# For each file added to a format, a character encoding can be specified
# using the 'charset' option. Example:
#
# [format=MyFormat]
# charset = ISO-8859-1
# file = /var/log/log1
# file = /var/log/log2
# charset = UTF-8
# file = /var/log/log3
# file = /var/log/*.log
# udp-server = 0.0.0.0
#
# This will set the character set for 'log1' and 'log2' to ISO-8859-1, and
# to UTF-8 for 'log3', any file that matches '/var/log/*.log', and any log
# entry read from the '0.0.0.0' integrated UDP server.
#
# Note that if no character encoding is specified, the system will attempt
# to automatically detect the encoding used. If the detection fails, then
# the system-wide default (retrieved from locale LC_CTYPE) will be used.
#

# ALTERING GENERATED IDMEF EVENTS
#
# Within each format, you might use the 'idmef-alter' option to modify
# generated events:
#
# Example: idmef-alter = alert.analyzer(-1).node.location = MyLocation;
#
# Note that 'idmef-alter' will never overwrite an IDMEF path that is
# already set. Use 'idmef-alter-force' if this is what you intend to do.
#


[format=syslog]
time-format = "%b %d %H:%M:%S"
prefix-regex = "^(?P<timestamp>.{15}) (?P<hostname>\S+) (?:(?P<process>\S+?)(?:\[(?P<pid>[0-9]+)\])?: )?"
file = /var/log/messages
file = /var/log/secure
# udp-server = 0.0.0.0
# tcp-server = 0.0.0.0
# tcp-tls-server = 0.0.0.0

# Two TLS modes are available:
# x509: x509 based certificate authentication
# anonymous: Anonymous TLS connection using ANON-ECDH or ANON-DH
#
# Both modes can be combined, and the default value is x509.
# tls-mode = x509 anonymous

# Path for client key, certificate, and certificate authority files.
# tls-key-file = /path/to/client.key
# tls-cert-file = /path/to/client.cert
# tls-ca-file = /path/to/server.ca

# TLS verification options:
#
# When a list of trusted fingerprints and/or a list of trusted names
# is provided, the connecting client has to match one of the provided
# fingerprints/names, otherwise the connection will be refused.
#
# List of trusted client fingerprints (SHA1 and MD5 formats accepted)
# If this option is used, then the connecting peers have to match one of the specified fingerprints.
# tls-trusted-fingerprint = SHA1:ae:8a:e5:97:66:2d:6d:cd:85:29:05:95:31:84:81:f1:27:3b:d1:73
#
# List of trusted client names (takes into account wildcards, and the
# DNSName/IPAddress subject alternative name PKIX extension)
# tls-trusted-name =
#
# Client certificate verification option (default is client-cert-required):
# client-cert-required: client has to provide a valid certificate for the authentication to succeed.
# client-cert-optional: client may connect without providing a valid x509 certificate.
# tls-verify = client-cert-required



#
# Sample configuration for metalog:
#
[format=metalog]
prefix-regex = "^(?P<timestamp>.{15}) \[(?P<process>\S+)\] "
time-format = "%b %d %H:%M:%S"
file = /var/log/everything/current


#
# Sample configuration for apache:
#
# Note: For apache >= 2.4, you need to force ErrorLogFormat in apache configuration:
#       ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"
[format=apache]
time-format = "%d/%b/%Y:%H:%M:%S"
prefix-regex = "(?P<hostname>\S+) \S+ \S+ \[(?P<timestamp>.{20}) [+-].{4}\] "
file = /var/log/httpd/access_log
file = /var/log/apache2/access_log

[format=apache-error]
time-format = "%a %b %d %H:%M:%S %Y"
prefix-regex = "^\[(?P<timestamp>.{24})\] \S+ (\[client (?P<hostname>\S+)\] )?"
file = /var/log/httpd/error_log
file = /var/log/apache2/error_log


#
# Sample configuration for asterisk:
#
#[format=asterisk]
#time-format = "%b %d %H:%M:%S"
#prefix-regex = "^(?P<timestamp>.{15}) (?P<hostname>\S+) (?:(?P<process>\S+?)(?:\[(?P<pid>[0-9]+)\])? (\S*): )?"
#file = /var/log/asterisk/messages


#
# Specifies the maximum length of logs, in bytes.
# If the log exceeds this size, it will be split into several parts,
# each one processed successively et independently of each other.
#
# log-max-length = 8192


#
# Specifies the maximum difference, in seconds and/or size, between
# the interval of two logfile rotations. If this difference is reached,
# a high severity alert will be emitted. The K (kbytes) or M (mbytes)
# suffix might be used for size definition.
#
#max-rotation-size-offset = 1024
#max-rotation-time-offset = 300


#
# Maximum number of warnings a given source should emit in case it can
# not parse log entries with the provided prefix_regex and time_format.
#
# -1 == unlimited number of warnings
#  0 == no warning at all
#  X == print at most X warnings.
#
# warning-limit = -1


#####################################
# Here starts plugins configuration #
#####################################

[Pcre]

ruleset=@configdir@/ruleset/pcre.rules


# [Debug]
#
# This plugin issues an alert for each packet.
# Careful to the logging activity it generates.
#
# Trigger reporting to the console.
# stderr


#######################
# Global TLS settings #
#######################
#
# Number of bits for the prime used in the Diffie-Hellman key exchange.
# Note that the value should be one of 768, 1024, 2048, 3072 or 4096.
# The default is 1024.
#
# dh-prime-length = 1024
#
# How often to regenerate the parameters used in the Diffie-Hellman key
# exchange. These should be discarded and regenerated once a day, once
# a week or once a month, depending on the security requirements.
#
# Generation is a CPU-intensive operation. The value is in hours,
# 0 disables regeneration entirely. The default is 24 hours.
#
# dh-parameters-regenerate = 24

Prelude Correlator configuration file: prelude-correlator.conf

# This is a template configuration file for prelude-correlator
#

include = /etc/prelude/default/idmef-client.conf

[general]
#
# Only attempt to correlate input events that match the following criteria:
# criteria =
#
# Only correlate input events sharing the same value for the following path.
# Note that this feature should be used with caution, as the number of
# contexts will rise with the number of different existing values.
# grouping =


# Plugin configuration:
#

# [BruteForcePlugin]
# disable = false
#

# Disable BusinessHour correlation by default since it is very verbose
[BusinessHourPlugin]
disable = true

#
# [OpenSSHAuthPlugin]
# disable = false
#
# [EventScanPlugin]
# disable = false
#
# [EventStormPlugin]
# disable = false
#
# [EventSweepPlugin]
# disable = false
#
# [WormPlugin]
# disable = false
# repeat-target = 5
#
# [CIArmyPlugin]
# disable = false
#
# How often in seconds the CIArmy database should be reloaded (download + reload)
# (default: once a week). 0 to disable reloading.
# reload  = 604800
#
# The address to load the CIArmy database from:
# uri = http://cinsscore.com/list/ci-badguys.txt
#
# Define the maximum allowed time for downloading the database
# timeout = 10
#
# Define the path to the database file
# filename = /var/lib/prelude-correlator/prelude-correlator/ciarmy.dat
#
# [DshieldPlugin]
# disable = false
#
# How often the Dshield database should be reloaded (download + reload)
# (default: once a week). 0 to disable reloading.
# reload  = 604800
#
# The address to load the Dshield database from:
# uri = http://www.dshield.org/ipsascii.html?limit=10000
#
# Define the maximum allowed time for downloading the database
# timeout = 10
#
# Define the path to the database file
# filename = /var/lib/prelude-correlator/prelude-correlator/dshield.dat

# [SpamhausDropPlugin]
#
# Note: the python-netaddr package is required for this plugin to work.
# Also, versions 0.7.10 to 0.7.15 (inclusive) are known to be very slow
# due to a bug in python-netaddr.
# See https://github.com/drkjam/netaddr/issues/94 for more information
#
# disable = true
#
# How often the Spamhaus database should be reloaded (download + reload)
# (default: once a week). 0 to disable reloading.
# reload  = 604800
#
# The address to load the Spamhaus database from:
# uri = http://www.spamhaus.org/drop/drop.txt
#
# Define the maximum allowed time for downloading the database
# timeout = 10
#
# Define the path to the database file
# filename = /var/lib/prelude-correlator/prelude-correlator/spamhaus_drop.dat
#
# This plugin will report CorrelationAlert for events / sets of events
# that appear to have passed through a firewall known to protect the
# target machine.
#
# If no firewall ever emit block concerning a given host, then this host
# is considered un-protected, and there is no point in reporting
# CorrelationAlert.
#
# The 'flush-protected-hosts' variable allow you to define how much
# time a given target hosts should be considered as protected when a
# firewall drop is noticed for this machine.
#
# The plugin is disabled by default since it tend to be very verbose

[FirewallPlugin]
disable = True
flush-protected-hosts = 3600

# [python_rules]
# Python rules folder
# paths = /etc/prelude-correlator/rules/python

# Logging configuration might also be defined in this file:
# http://docs.python.org/library/logging.html

# Include additional configuration files
[include]
conf.d/*.conf

Prelude GUI configuration file: prewikka.conf

##########################
# Prewikka configuration
##########################

[general]
# Location of the help server
#help_location: http://doc.prelude/rst/${lang}/${path}

# Number of heartbeats to analyze in the heartbeat analysis view.
#heartbeat_count: 30

# If the offset between two heartbeats is off by more than the specified
# offset (in seconds), the analyzer will be represented as offline.
#heartbeat_error_margin: 3

# Open external (references, IP lookup, and port lookup) links
# in a new windows.
external_link_new_window: yes

# Enables details links (default: no)
enable_details: no
# Enable error traceback (default: yes)
enable_error_traceback: yes
# URL to get details about an host
host_details_url: http://www.prelude-siem.com/host_details.php
# URL to get details about a port
port_details_url: http://www.prelude-siem.com/port_details.php
# URL to get details about a classification reference
reference_details_url: http://www.prelude-siem.com/reference_details.php

# When the number of classifications, sources or targets exceeds
# the defined value, an expansion link will be provided to look up
# the remaining entries.
#
# max_aggregated_source: 3
# max_aggregated_target: 3
# max_aggregated_classification: 10

# Asynchronous DNS resolution (require twisted.names and twisted.internet)
#
# While rendering view containing address scheduled for asynchronous
# DNS resolution, it is possible that the rendering terminate too fast
# for all DNS requests to complete.
#
# The dns_max_delay setting determine Prewikka behavior:
# - [-1] No DNS resolution is performed.
# - [0] Do not wait, immediatly send results to the client.
# - [x] Wait at most x seconds, then send results to the client.
#
# dns_max_delay: 0


# Default locale to use (default is English)
# The supported locales are: de_DE, en_GB, es_ES, fr_FR, it_IT, pl_PL, pt_BR, ru_RU
#
# default_locale: en_GB

# Default theme to use (default is cs)
# The supported themes are: blue, bright, classic, cs, dark, green, yellow
#
# default_theme: cs

# Default timezone to use (default is the local timezone)
# The supported timezones follow the IANA naming convention,
# for instance: UTC, Africa/Abidjan, Europe/Zurich...
#
# default_timezone: UTC

# Default encoding to use (default is UTF8):
# encoding: utf8

# Public path to Prewikka in case the application is being served
# through a reverse proxy, including any necessary port information.
# reverse_path: http://example.com/proxied/prewikka/


[interface]
# Software name displayed in the top left corner (displays logo if not defined)
# software: Prelude

# Webpage title
# browser_title: Prelude

# Path to the file defining the menu entries order:
# menu_order: menu.yml


############################
# Customizable search pages
############################
# Define additional fields to be displayed in search pages

# [datasearch alert]
# extra_fields: alert.source.user.user_id.name, alert.target.user.user_id.name

# [datasearch heartbeat]
# extra_fields: heartbeat.messageid


#####################
# Customizable links
#####################
# Define custom links and paths for which these links may be displayed

# [url host]
# paths: alert.source.node.address.address, alert.target.node.address.address
# label: http://url?host=$value

# [url classification]
# paths: alert.classification.text
# label: http://url?classification=$value

# [url time]
# paths: alert.create_time
# label: http://url?time=$value


############
# Databases
############

# Events DB
[idmef_database]
# type: pgsql | mysql | sqlite3
# For sqlite, add
# file: /path/to/your/sqlite_database
#
type: pgsql
host: localhost
user: prelude
pass: prelude
name: prelude

# Prewikka DB
[database]
type: pgsql
host: localhost
user: prelude
pass: prelude
name: prewikka


##########
# Logging
##########
# - You can activate several log section.
# - Log level might be set to all/debug, info, warning, error, critical.
#   If unspecified, the default level is "warning".

# [log stderr]
# level: info

# [log file]
# level: debug
# file: /tmp/prewikka.log

[log syslog]
level: info

# [log nteventlog]
# level: info

# [log smtp]
# level: warning
# host: mail.domain.com
# from: user@address
# to: recipient1@address, recipient2@address, recipientN@address
# subject: Subject to use


############
# Cron jobs
############
# Define parameters for different cron jobs.
# Cron jobs must be enabled from the GUI to be executed.

# Periodic alert deletion
# [cron alert]
#
# Minimal age in days for alerts to be deleted (default is not to delete alerts)
# age: 30
#
# It is also possible to define this value per severity (default is to use the age above):
# high: 365
# medium: 90
# low: 30
# info: 7

# Periodic heartbeat deletion
# [cron heartbeat]
#
# Minimal age in days for heartbeats to be deleted (default is not to delete heartbeats)
# age: 7

# Periodic search history entries deletion
# [cron search_history]
#
# Maximal number of entries per user to be kept (default is 10)
# size: 10


[include]
conf.d/*.conf

Additional Prelude GUI configuration file: alerts.conf

# ========================= Prelude SIEM Configuration =========================
#
# This file is a part of the Prelude SIEM configurations files.
# Purpose:  Tune the datasearch pages based on alerts data (such as alerts,
#           threats).
#
# ----------------------------------- Alerts -----------------------------------
#
# Add extra columns to any DataSearch page containing data from this type:
#   - Must be a valid IDMEF path (RFC 4765)
#
#[datasearch alert]
#extra_fields = alert.messageid, alert.classification.text

Additional Prelude GUI configuration file: auth.conf

# ========================= Prelude SIEM Configuration =========================
#
# This file is a part of the Prelude SIEM configuration files.
# Purpose:  Tune the authentication process.
#
# -------------------------- Standard authentication ---------------------------
#
# Use the standard login/password authentication with a session expiration time:
#
[session loginform]
expiration: 60
footer: Prelude SIEM $version
#
# --------------------------- Disable authentication ---------------------------
#
# Disable Prewikka authentication:
#
#[session anonymous]
#
# ------------------------------- Users database -------------------------------
#
# Retrieve Prewikka Users through database.
# If there is no user with administrative rights defined in the database,
# the initial user will be created according to these settings:
#
[auth dbauth]
initial_admin_user: admin
initial_admin_pass: admin
#
# List of supported hashing algorithms for passwords, separated by spaces.
# The first one available on the system will be used.
# See http://passlib.readthedocs.io/en/stable/lib/passlib.hash.html
password_schemes: sha256_crypt
#
# List of deprecated hashing algorithms for passwords, separated by spaces.
# Passwords hashed using one of these algorithms will be rehashed
# when the user next logs in.
deprecated_password_schemes: hex_md5

Additional Prelude GUI configuration file: external_app.conf

# ========================= Prelude SIEM Configuration =========================
#
# This file is a part of the Prelude SIEM configurations files.
# Purpose:  Add your external applications and their configurations.
#
# ---------------------------- External applications ---------------------------
#
# Add external applications displayed into an iframe:
#   - section:    text displayed in the menu and to use in menupro.yml
#   - base_url:   initial URL of the external application
#   - tab:        view's tabs, each view can have one or more tab
#   - tab_url:    URL for each tab, can be absolute or relative (to the base_url)
#   - permission: existing or custom access permission (optional)
#   - help:       absolute URL pointing to a help page about the application (optional)
#
#[appli app1]
#section: Application1
#base_url: http://app1
#tab: tab1, tab2
#tab_url: /tab1, /tab2
#permission: CUSTOM_PERMISSION
#help: http://app1/help.html

Additional Prelude GUI configuration file: logs.conf

# ========================= Prelude SIEM Configuration =========================
#
# This file is a part of the Prelude SIEM configuration files.
# Purpose:  Tune the way of retrieving the logs data from an Elasticsearch
#           instance.
#
# ------------------------------------ Logs ------------------------------------
#
# The section below defines a mapping between the fields recognized by Prelude
# and the fields defined in the logs index(es) of the Elasticsearch cluster.
#
# Fields must only use alphanumeric chars, "_" or "-" and must not start with "-".
#
# The first value is the field used during regular searches.
# The second value is the field used for aggregation.
# If omitted, it defaults to the first value.
#
#[elasticsearch log]
#es_url: http://<es-ip>:9200/<index-name-for-logs>
#es_user:
#es_pass:
#es_type: log
#
# Time format expected by Elasticsearch (default is to use ISO formatting)
# Special "@" value that formats the dates/times into UNIX timestamps
#es_timeformat: %Y-%m-%d %H:%M:%S
#
# Default field to use when typing in the search bar
#default_field: message
#
# Fields:
#program: syslog_program, syslog_program.raw
#host: syslog_hostname, syslog_hostname.raw
#message: syslog_message
#timestamp: @timestamp

Additional Prelude GUI configuration file: riskoverview.conf

# ========================= Prelude SIEM Configuration =========================
#
# This file is a part of the Prelude SIEM configuration files.
# Purpose:  Configure the risk overview.
#
# -------------------------------- Risk Overview -------------------------------
#
# Reordering entries will affect the display order of the widgets in the GUI.
# Commenting an entry will disable the display of the widget.
#
# [riskoverview]
# agents
# archive
# alerts

Annex: Prelude SIEM help

Prelude Manager help

NAME
   prelude-manager - Collects and normalize events.

SYNOPSIS
   prelude-manager [options]

DESCRIPTION
   Prelude Manager is a high-availability server which can collect, fil-
ter, relay, reverse-relay, normalize and store events. Events can come
from registered analyzers and/or managers. The common usage is to
store nomalized events into a database, thus this can be extended to
store informations in plain text or xml files.

OPTIONS
   Some prelude-manager option are contextual, they have to be prefixed
   by another.
   --prelude Prelude generic options
   --profile=<name> Profile to use for this analyzer
   --heartbeat-interval=<interval> Number of seconds between two heart-
   beat
   --server-addr=<address> Address where this sensor should report to
   (addr:port)
   --analyzer-name=<name> Name for this analyzer
   --db=<INAME>

      Options for the libpreludedb plugin
      -t, --type=<type> Type of database (mysql/pgsql/sqlite3)
      -l, --log=<file name> Log all queries in a file, should be only
      used for debugging purpose
      -h, --host=<address> The host where the database server is run-
      ning (in case of client/server database)
      -f, --file=<file name> The file where the database is stored (in
      case of file based database)
      -p, --port=<port number> The port where the database server is
      listening (in case of client/server database)
      -d, --name=<name> The name of the database where the alerts will
      be stored
      -u, --user=<user> User of the database (in case of client/server
      database)
      -P, --pass=<password> Password for the user (in case of
      client/server database)

   --debug=<INAME>
      Option for the debug plugin
      -o, --object=<name> Name of IDMEF object to print (no object pro-
      vided will print the entire message)
      -l, --logfile=<file name> Specify output file to use (default to
      stdout)

   --relaying=<INAME>
      Relaying plugin option
      -p, --parent-managers=<address> List of managers address:port
      pair where messages should be sent to

   --textmod=<INAME>
      Option for the textmod plugin
      -l, --logfile=<file name> Specify logfile to use

   --xmlmod=<INAME>
      Option for the xmlmod plugin
      -l, --logfile=<file name> Specify output file to use
      -v, --validate=<xml> Validate IDMEF XML output against DTD
      -f, --format=<format> Format XML output so that it is readable
      -d, --disable-buffering=<boolean> Disable output file buffering
      to prevent truncated tags
      --idmef-criteria-filter=<INAME> Filter message based on IDMEF
      criteria
      -r, --rule=<rule> Filter rule, or filename containing rule
      --hook=<value> Where the filter should be hooked (report-
      ing|reverse-relaying|plugin name)

   --config=<file name>
      Configuration file to use

   -v, --version
      Print version number

   -D, --debug-level=<level>
      Run in debug mode

   -d, --daemon
      Run in daemon mode

   -P, --pidfile=<file name>
      Write Prelude PID to pidfile

   -c, --child-managers=<address>
      List of managers address:port pair where messages should be gath-
      ered from

   -l, --listen=<address>
      Address the sensors server should listen on (addr:port)

   -f, --failover=<boolean>
      Enable failover for specified report plugin

   -h, --help
      Print help

FILES
   /etc/prelude/prelude-manager.conf - the configuration file

BUGS
   This man page hadn’t been proof-read yet.

SEE ALSO
   prelude-adduser(1)

Prelude LML help

NAME

Prelude LML - Analyze and convert "syslog" contents in IDMEF format.

SYNOPSIS

prelude-lml [options]

DESCRIPTION

Prelude LML is a part of the project that deals with host based intrusion detection
aspects through log analysis. It can monitor files created by a syslog daemon coming from
different hosts on heterogeneous platforms, other types of single-line event logs, or
simulate a syslog server on its own. Thus any system generating logs can benefit from the
Prelude LML's analysis engine

OPTIONS

Some Prelude LML options are contextual, they have to be prefixed by another one.

--prelude                         Prelude generic options
   --profile=ARG                   Profile to use for this analyzer
   --heartbeat-interval=ARG        Number of seconds between two heartbeat
   --server-addr=ARG               Address where this agent should report
                                   events to (addr:port)
   --tls-options=ARG               TLS ciphers, key exchange methods,
                                   protocols, macs, and compression options
   --analyzer-name=[ARG]           Name for this analyzer

--debug=[INAME]                   Debug plugin option
   -s, --stderr                    Output to stderr when plugin is called

--pcre=[INAME]                    Pcre plugin option
   -r, --ruleset=ARG               Ruleset to use
   -l, --last-first                Process rules with the "last" attribute first
       --dump-unmatched            Dump unmatched log entry

-h, --help                        Print this help
-v, --version                     Print version number
    --user=ARG                    Set the user ID used by Prelude LML
    --group=ARG                   Set the group ID used by Prelude LML
-q, --quiet                       Quiet mode
-D, --debug-level=[ARG]           Debug mode
-d, --daemon                      Run in daemon mode
-P, --pidfile=ARG                 Write Prelude LML PID to specified file
    --text-output=[ARG]           Dump alert to stdout, or to the specified file
    --dry-run                     No alert emission / Prelude connection
-c, --config=ARG                  Configuration file to use
-l, --log-max-length=ARG          Specify maximum line length for log (default is 8192 bytes).
    --max-rotation-time-offset=ARG Specifies the maximum time difference, in seconds, between
                                  the time of logfiles rotation. If this amount is reached,
                                  a high severity alert will be emitted
    --max-rotation-size-offset=ARG Specifies the maximum size difference between two logfile
                                  rotation. If this difference is reached,
                                  a high severity alert will be emitted
    --warning-limit=ARG           Limit the number of parse warnings reported from sources
                                  (0 suppress, -1 unlimited, or user defined number)
-b, --batch-mode                  Tell LML to run in batch mode
    --metadata=ARG                Specify whether log analysis should begin from 'head', 'tail',
                                  or 'last' known file position. You can also use the 'nowrite'
                                  attribute so that existing file metadata are not overwritten.
                                  The default value is 'last'
    --no-resolve                  Do not attempt to resolve target address (useful for profiling)

--format=[INAME]
  -t, --time-format=ARG            Specify the input timestamp format
  -p, --prefix-regex=ARG           Specify the input prefix format
  -f, --file=ARG                   Specify a file to monitor (use "-" for standard input)
  -u, --udp-server=[ARG]           address:port pair to listen to syslog to UDP messages
                                   (default port 514) -- default protocol
  -w, --tcp-server=[ARG]           address:port pair to listen to syslog to TCP messages
                                   (default port 514)
  -s, --tcp-tls-server=[ARG]       address:port pair to listen to syslog to TCP/TLS messages
                                   (default port 6514)
      --tls-ca-file=[ARG]          Access path of certificate authority file
      --tls-key-file=[ARG]         Access path of private key file
      --tls-cert-file=[ARG]        Access path of certificate file
      --tls-trusted-name=ARG       List of trusted certificate name
      --tls-trusted-fingerprint=ARG List of trusted certificate fingerprint
                                   (MD5 and SHA1 supported)
      --tls-mode=[ARG]             TLS authentification mode, separated by space.
                                   Supported mode are 'x509' and 'anonymous'
                                   (default value is 'x509').
      --tls-verify=[ARG]           Type of certificate verification :
                                   'client-cert-required' or 'client-cert-optional'
  -c, --charset=ARG                Specify the charset used by the input file
      --idmef-alter=ARG            Assign specific IDMEF path/value to matching log entry
      --idmef-alter-force=ARG      Assign specific IDMEF path/value to matching log entry,
                                   even if path is already used

Prelude Correlator help

NAME

    Prelude Correlator

SYNOPSIS

    prelude-correlator [options]

DESCRIPTION

    Prelude-Correlator allows conducting multistream correlations thanks to a powerful programming
    language for writing correlation rules. With any type of alert able to be correlated, event
    analysis becomes simpler, quicker and more incisive.

OPTIONS

    --version             show program's version number and exit
    -h, --help            show this help message and exit
    -c FILE, --config=FILE
                          Configuration file to use
    --dry-run             No report to the specified Manager will occur
    -d, --daemon          Run in daemon mode
    -P FILE, --pidfile=FILE
                          Write Prelude Correlator PID to specified file
    --print-input=FILE    Dump alert input from manager to the specified file
    --print-output=FILE   Dump alert output to the specified file
    -D LEVEL, --debug=LEVEL
                          Enable debug output (optional debug level argument)

    IDMEF Input:
      Read IDMEF events from file

      --input-file=FILE   Read IDMEF events from the specified file
      --input-offset=OFFSET
                          Start processing events starting at the given offset
      --input-limit=LIMIT
                          Read events until the given limit is reached

    Prelude:
      Prelude generic options

      --profile=PROFILE   Profile to use for this analyzer

prelude-admin help

NAME
   prelude-admin - Manage agents accounts

SYNOPSIS
   prelude-admin <subcommand> [options] [args]
   prelude-admin add <profile name> [--uid UID] [--gid GID]
   prelude-admin chown <profile name> [--uid UID] [--gid GID]
   prelude-admin del <profile name>
   prelude-admin rename <profile name> <profile name>
   prelude-admin register <profile name> <wanted permission> <registration-
   server address> [--uid UID] [--gid GID] [--passwd=PASSWD>] [--passwd-
   file=<FILE>]
   prelude-admin registration-server <profile name> [--uid UID] [--gid GID]
   [--prompt] [--passwd=PASSWD>] [--passwd-file=<FILE>] [--keepalive] [--no-
   confirm] [--listen]
   prelude-admin revoke <profile> <analyzerID> [--uid UID] [--gid GID]

DESCRIPTION

   In order for an agent to communicate with a manager, it must be registered.
   Registration involves several steps:
   - Allocating an unique identity for the agent
   - Creating directory to be used by the agent (example: failover purpose)
   - Registering to a remote ’prelude-manager’: get a signed X509 certificate
   that will allow communication between agent and manager using the specified
   permissions.

   All these informations are stored in an agent profile.

   An agent profile is identified by its name. When an agent is started, it
   will load the profile of the same name as the program itself, that is, if
   your agent is named "prelude-lml", the agent will load the profile named
   "prelude-lml".

   The name of the profile can be overriden using the ’--prelude --profile
   name_of_my_profile’ command line option. It is possible to define the pro-
   file name so that you can have several instances of one agent running with
   different permissions, using different profiles.
   Note that profiles are not specific to agents, but are used in all programs
   of the Prelude suite (agents, managers, etc).

   If you are not sure which permission your agent should get, just start it
   and default permissions will be displayed.

OPTIONS
   <profile name> is the default name of the agent you are installing or your
   own defined name.

   If you start your agent without prior registration, a warning is displayed
   including the default profile name on how to register the agent.
   <requested permission> is the permission your agent needs. It is composed
   of permission attributes (idmef or admin) and access type: read/write
   (r/w). By default, an agent need permissions for writing IDMEF to a man-
   ager, and reading administrative command sent to it. That is : "idmef:w
   admin:r".

   <manager address> is the address of the prelude-manager you wish to regis-
   ter. this can either be its IP address or its hostname. If you made a local
   installation, you can write localhost to connect via unix socket.

   Remember to use the correct uid/gid when registering your agent. For
   instance, if you want to register snort (running with snort euid / egid),
   use --uid snort --gid snort.

   add <analyzer profile>
      Setup a new agent user.

      --uid=UID UID or user to use to setup agent files.
      --gid=GID GID or group to use to setup agent files.

   chown <analyzer profile>
      Change analyzer owner.

      --uid=UID UID or user to use to setup agent files.
      --gid=GID GID or group to use to setup agent files.

   del <analyzer profile>
      The delete command will remove the agent files created through "add"
      command. Once this is done, the analyzer can’t be used unless "regis-
      ter" or "add" is called again.

   rename <analyzer profile> <analyzer profile>
      Rename an existing analyzer.

   register <profile name> <wanted permission> <registration-server address>
      Register an analyzer.
      Register and create the analyzer basic setup if needed. It will also
      configure communication of this analyzer with a receiving analyzer
      (like a Manager) through the specified registration-server.

      --uid=UID UID or user to use to setup analyzer files.
      --gid=GID GID or group to use to setup analyzer files.

      --passwd=PASSWD Use provided password instead of prompting it.
      --passwd-file=-|FILE Read password from file instead of prompting it
      (- for stdin).

   registration-server <profile name>
      Start a registration server to register agents. This is used in order
      to register ’sending’ analyzer to ’receiving’ analyzer. <profile name>
      should be set to the profile name of the specified registration-server.

      --uid=UID UID or user to use to setup ’receiving’ analyzer files.
      --gid=GID GID or group to use to setup ’receiving’ analyzer files.
      --prompt Prompt for a password instead of auto generating it.
      --passwd=PASSWD Use provided password instead of auto generating it.
      --passwd-file=-|FILE Read password from file instead of auto generat-
      ing it (- for stdin).
      --keepalive Register analyzer in an infinite loop.
      --no-confirm Do not ask for confirmation on agent registration.
      --listen Address to listen on for registration request (default is
      any:5553).

   revoke <profile name>
      Revoke access to <profile> for the given analyzerID.
      --uid=UID UID or user to use to setup analyzer files.
      --gid=GID GID to group to use to setup analyzer files.

--help
   Print help

preludedb-admin help

NAME
   preludedb-admin - tool to copy, move, delete, save or restore a prelude
   database

SYNOPSIS
   preludedb-admin copy|move|delete|load|save arguments

DESCRIPTION
   preludedb-admin can be used to copy, move, delete, save or restore a pre-
   lude database, partly or in whole, while preserving IDMEF data consistency.
   Mandatory arguments

   copy Make a copy of a Prelude database to another database.

   delete Delete content of a Prelude database.

   load Load a Prelude database from a file.

   move Move content of a Prelude database to another database.

   save Save a Prelude database to a file.

   Running a command without providing arguments will display a detailed help.

EXAMPLES
   Obtaining help on a specific command:
   # preludedb-admin save
   Usage : save <alert|heartbeat> <database> <filename> [options]
   Example: preludedb-admin save alert "type=mysql name=dbname user=prelude" outputfile

   Save messages from <database> into [filename].
   If no filename argument is provided, data will be written to standard output.

   Database arguments:
      type : Type of database (mysql/pgsql).
      name : Name of the database.
      user : User to access the database.
      pass : Password to access the database.

   Valid options:
      --offset <offset> : Skip processing until ’offset’ events.
      --count <count> : Process at most count events.
      --query-logging [filename] : Log SQL query to the specified file.
      --criteria <criteria> : Only process events matching criteria.
      --events-per-transaction : Maximum number of event to process per transaction (default
      1000).

   Preludedb-admin can be useful to delete events from a prelude database :

      preludedb-admin delete alert --criteria <criteria> "type=<mysql> name=<dbname>
      user=<prelude-user> pass=<pass>"

   where criteria is an IDMEF criteria :

      preludedb-admin delete alert --criteria "alert.classification.text == ’UDP packet
      dropped’" "type=mysql name=prelude user=prelude-user pass=prelude-pass"

   This will delete all event with the classification text "UDP packet
   dropped" from the database.

SEE ALSO
   The Prelude Handbook: https://www.prelude-siem.org/projects/pre-
   lude/wiki/ManualUser

   Prelude homepage: http://www.prelude-siem.com/

   Creating filter using IDMEF Criteria: https://www.prelude-
   siem.org/projects/prelude/wiki/IDMEFCriteria

   Prelude IDMEF Path: https://www.prelude-siem.org/projects/pre-
   lude/wiki/IDMEFPath

BUGS
   To report a bug, please visit https://www.prelude-siem.org/

CS GROUP - France

22, Avenue Galilée

92350 Le Plessis-Robinson - France

Tel: +33 (0)1 41 28 40 00

Fax: +33 (0)1 41 28 40 40

www.csgroup.eu