%% LyX 1.4.2 created this file. For more info, see http://www.lyx.org/. %% Do not edit unless you really know what you are doing. \section{Dig into prelude's world} \subsection{Generic, System wide configuration} All Prelude sensors have a common set of options, provided through the Prelude framework. You might modify these options system wide or in the Prelude specific configuration file a client might provide. All options defined system wide might be overriden in the client own Prelude configuration file. These are just template values that the client will use in case the values are not defined in the client own Prelude configuration file. Once the Prelude library is installed, you can tune system wide options using the following configuration files (replace \$PREFIX with your installation prefix, usually /usr or /usr/local): \begin{lyxcode} \$PREFIX/etc/prelude/default/client.conf \$PREFIX/etc/prelude/default/global.conf \$PREFIX/etc/prelude/default/idmef-client.conf \end{lyxcode} \paragraph*{\$PREFIX/etc/prelude/default/global.conf} This is the common configuration file used by all Prelude programs (sensors, prelude-manager). It provides a system wide template for common IDMEF attributes used by sensors. All of theses 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 with a high number of sensors. The heartbeat-interval option defines how often a Prelude client should send a heartbeat (the default is 600 seconds). You can define IDMEF attributes to be carried by events emitted by the programs using the framework. 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 with a high number of sensors. \begin{itemize} \item node-name: Name of the equipment (usually the name of the machine this sensor is running on). \item node-location: Location of the equipment (could be a city, or a country). \item node-category: The type of node the clients are runing on (usually hosts). \end{itemize} You might also want to define one or several node-address section, containing the following option: \begin{itemize} \item address: The address of the equipment. \item netmask: Netmask for this address. \item vlan-name: Name of the Virtual Lan to which the address resides in. \item vlan-num: Number of the Virtual Lan to which the address resides in. \item category: Type of address represented (usually ipv4-addr or ipv6-addr). \end{itemize} \paragraph{\$PREFIX/etc/prelude/default/client.conf} In this configuration file, you can configure the connection string that clients, which need to connect to a Prelude Manager, will use. You can use boolean '\textbackslash{}\textbar{}\textbackslash{}\textbar{}' (OR) and '\&\&' (AND) to set up a redundant configuration environment. Note that whatever you specify here, any events sent through the Prelude framework are 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: \begin{lyxcode} server-addr~=~x.x.x.x \end{lyxcode} Connect and send events to x.x.x.x. \begin{lyxcode} server-addr~=~x.x.x.x~\&\&~y.y.y.y \end{lyxcode} Connect and send events to both x.x.x.x and y.y.y.y. \begin{lyxcode} server-addr~=~x.x.x.x~||~y.y.y.y \end{lyxcode} Connect and send events to x.x.x.x, or fallback to y.y.y.y if x.x.x.x failed. \paragraph*{\$PREFIX/etc/prelude/default/idmef-client.conf} This file includes both \$PREFIX/etc/prelude/default/global.conf and \emph{\$PREFIX/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). \subsection{Prelude Manager} 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). The server is a high availability server 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 accross clients. Prelude Manager can listen on an UNIX domain socket, or on an IPv4 or IPv6 address. The default is to listen on an UNIX domain socket. You might change this using the listen command line option or configuration directive. \begin{lyxcode} listen~=~unix \end{lyxcode} Will listen on /tmp/.prelude-unix UNIX domain socket (this is the default). \begin{lyxcode} listen~=~unix:/tmp/myfilename \end{lyxcode} Will listen on /tmp/myfilename UNIX domain socket. \begin{lyxcode} listen~=~x.x.x.x \end{lyxcode} Will listen on the specified IP address. \paragraph{Reporting} Once an event has been processed, the Manager uses Reporting Plugins to convert alerts from Prelude binary IDMEF format, to various output formats. There are several Reporting Plugins: \begin{itemize} \item db - A database Plugin (MySQL and PostgreSQL). \item xmlmod - An XML Reporting Plugin. \item textmod - A text Reporting Plugin. \item relaying - A plugin relaying alert to another set of manager. \item smtp - A commercial plugin sending textual alert through your SMTP server. \item (see prelude-manager --help for others) \end{itemize} A reporting plugin might be loaded several times, so you could have two db reporting plugin loaded and addressing different database (this is true for most plugin categories). In order for a plugin to be loaded several times, you need to provide it with the name of each instance. If you don't provide a name, then default is used. Here is an example: \begin{lyxcode} \#~prelude-manager~-{}-textmod~-{}-logfile~stderr~-{}-textmod~MyInstanceName -{}-logfile~/var/log/prelude.log \end{lyxcode} Or from the configuration file: \begin{lyxcode} {[}textmod]~logfile~=~stderr {[}textmod=MyInstanceName]~logfile~=~/var/log/prelude.log \end{lyxcode} Will load an instance of the textmod reporting plugin named default, which will log to stderr; and another instance named MyInstanceName? logging to /var/log/prelude.log. \paragraph*{Database} In order for prelude-manager to report to a database, you need to use the db reporting plugin. Additionaly, you need to provide this plugin with several arguments: \begin{itemize} \item type : The type of database (mysql or pgsql). \item host : The hostname where the database is listening (default is localhost). \item port : The port where the database is listening, if applicable. \item name : The name of the database to use. \item user : The username to use in order to connect to this database. \item pass : The password to use in order to connect to this database. \end{itemize} \begin{lyxcode} prelude-manager~-{}-db~-{}-type~mysql~-{}-host~localhost~-{}-name~prelude -{}-user~prelude~-{}-pass~XXXXXX \end{lyxcode} Or from the configuration file: \begin{lyxcode} {[}db]~ type~=~mysql~ host~=~localhost~ name~=~prelude~ user~=~prelude~ pass~=~XXXXXX \end{lyxcode} \paragraph*{Relaying} Prelude Managers can also act as a relays to another Manager using the relaying plugin. Relaying Managers control a set of Analyzers, and relay alerts and messages received from theses analyzer to another Parent Manager. This is a very useful feature when a network is divided into sub-networks. \begin{lyxcode} prelude-manager~-{}-relaying~-{}-parent-managers~\char`\"{}x.x.x.x\char`\"{} \end{lyxcode} Started this way, the prelude-manager will connect to the specified parent manager (x.x.x.x in this example). Note that you can specify more complex connection information, like: \begin{lyxcode} prelude-manager~-{}-relaying~-{}-parent-managers~\char`\"{}x.x.x.x~\&\&~y.y.y.y\char`\"{} \end{lyxcode} Relaying information to x.x.x.x and y.y.y.y, or even: \begin{lyxcode} prelude-manager~-{}-relaying~-{}-parent-managers~\char`\"{}x.x.x.x~||~y.y.y.y\char`\"{} \end{lyxcode} Relaying information to x.x.x.x or 'y.y.y.y' if x.x.x.x goes down. This option might also be specified from the prelude-manager configuration file: \begin{lyxcode} {[}relaying]~ parent-managers~=~x.x.x.x~\&\&~y.y.y.y \end{lyxcode} \paragraph*{Smtp} A commercial SMTP plugin is available from PreludeIDS Technologies. This plugin provide the ability to send textual alert as mail. Please check the Corporate Modules page for more information. \paragraph*{Reverse relaying} Under certain conditions (an example of this are DMZ network), it might be difficult for an administrator to allow a set of analyzers on a given network to contact a manager located on another network. However, if connections to the analyzer network are permited, you might use Reverse Relaying to solve your problem. In this situation, the manager connects to the Analyzer in order to receive the information.\\ \includegraphics[width=1\columnwidth]{images/prelude-reverse-relaying} \begin{lyxcode} prelude-manager~-{}-child-managers~\char`\"{}x.x.x.x\char`\"{} \end{lyxcode} from the command line option, or in the prelude-manager configuration file: \begin{lyxcode} child-managers~=~\char`\"{}x.x.x.x\char`\"{} \end{lyxcode} will make prelude-manager connect to x.x.x.x and retrieve events from it. Connection strings are also supported, as specified in the Relaying section above. Prelude Managers can also act as a relays to another Manager using the relaying plugin. Relaying Managers control a set of Analyzers, and relay alerts and messages received from theses analyzer to another Parent Manager. This is a very useful feature when a network is divided into sub-networks. \paragraph*{Filtering events} The idmef-criteria filtering plugin allow you to filter events basing on specific IDMEF-Criteria. A filtering plugin might be used to decide whether a specific action should be taken. \begin{lyxcode} prelude-manager~-{}-idmef-criteria~-{}-rule~'alert.classification.text~== User~login~successful'~-{}-rule~'alert.assessment.impact.severity~== high'~-{}-hook~relaying{[}default] \end{lyxcode} or from the configuration file: \begin{lyxcode} {[}idmef-criteria]~ rule~=~alert.classification.text~==~User~login~successful rule~=~alert.assessment.impact.severity~==~high~ hook~=~relaying{[}default] \end{lyxcode} Will forward any events 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. In order to learn more about the available IDMEF Path, please have a look at the IDMEFPath. More documentation on how to setup IDMEF criteria is available on the IDMEFCriteria page. \paragraph{Event Suppression} The thresholding filtering plugin allow you to suppress events based on their content. \begin{lyxcode} prelude-manager~-{}-thresholding~-{}-path 'alert.classification.text,alert.source.node.address.address'~-{}-limit 3600~-{}-count~1~-{}-hook~relaying{[}default] \end{lyxcode} or from the configuration file: \begin{lyxcode} {[}thresholding]~path~=~alert.classification.text, alert.source.node.address.address limit~=~3600~ count~=~1~ hook~=~relaying{[}default] \end{lyxcode} 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. \begin{lyxcode} prelude-manager~-{}-thresholding~-{}-path 'alert.classification.text,alert.source.node.address.address' -{}-threshold~3600~-{}-count~10~-{}-hook~relaying{[}default] \end{lyxcode} or from the configuration file: \begin{lyxcode} {[}thresholding]~path~=~alert.classification.text, alert.source.node.address.address~ threshold~=~3600~ count~=~10~ hook~=~relaying{[}default] \end{lyxcode} Will forward every tenth event within 3600 seconds with the unique alert.classification.text, alert.source.node.address.address value combination to the default instance of the relaying reporting plugin. You can also combine threshold and limit, so that once the threshold is reached once, further events with the same value will be suppressed, until the limit expire. In order to learn more about the available IDMEF Path, please have a look at the IDMEFPath. More documentation on how to write IDMEF criteria is available on the IDMEFCriteria page. \paragraph*{Stacking Filtering Plugins Together} The ability to stack plugins, allows you to create more complex abilities in how you use the plugins. We'll use the example below, to show how idmef-criteria, thresholding and smtp can all be combined (ie. stacked) to enhance your reporting. Example: \begin{lyxcode} {[}smtp]~ sender~=~prelude@mycompanyname.com~ recipients~=~me@mycompanyname.com~ smtp-server~=~mailserver.mycompanyname.com {[}thresholding=sudotest]~ path~= alert.classification.text,alert.target(0).node.address(0).address~ threshold~=~1~ seconds~=~3600~ hook~=~smtp{[}default] {[}idmef-criteria-filter=sudotest]~ rule~=~alert.classification.text~==~'SUDO~Command~Executed'~ hook~=~thresholding{[}sudotest] \end{lyxcode} In the above example, we have created an instance of the idmef-criteria-filter called 'sudotest'. It looks for 'SUDO Command Executed' in an IDMEF alert, and when it matches, it passes this to the 'sudotest' instance of the thresholding plugin (this can be seen via the 'hook = thresholding{[}sudotest]). The 'sudotest' instance of the thresholding plugin, will then keep track of this 'SUDO Command Executed' text, along with the target node's IP address. The threshold of '1', combined with the seconds of '3600', will suppress further of these messages with those two criteria from being passed to the smtp plugin for one hour after one has been seen. After that time period, messages with that text and target node address will generate another smtp message - before being suppressed for one hour again. Note: This does not affect other plugins, such as the database, as that is not hooked in our example. Finally, the email is sent as the 'sudotest' instance of the thresholding plugin hooks the smtp{[}default] plugin. Basically, the stacking of plugins in this example allowed us to look for certain IDMEF criteria, then both email on it matching, and suppress the number of emails generated for this match for a certain time period. \paragraph*{Report plugins failover} 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 support it). Failover is a prelude-manager feature allowing to store alerts in case the reporting plugin fails. This is especially useful when the reporting plugin rely on another program (example: database). If the protected reporting plugins fail, for any reason, to process the message, the failover subsystem will backup it as well as future messages and then will periodicaly try to re-initialize the plugin, and to process backed up message. As an example, if you activate report plugins failover for the db plugin, and that you stop the underlying database. Message going to the plugin will be saved, and processed as soon as the db plugin is sucessfuly reinitialized (in this case, when the database goes up again). \begin{lyxcode} -{}-failover~db~-{}-failover~db{[}MyPluginInstance] \end{lyxcode} or from the configuration file: \begin{lyxcode} failover~=~db~ failover~=~db{[}MyPluginInstance] \end{lyxcode} Will both activate failover for the default instance of the db plugin, and for the MyPluginInstance? of this same plugin. 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. \paragraph*{Other configuration options} \begin{itemize} \item daemon : Start prelude-manager as a daemon. \item pidfile : Write the prelude-manager PID to the specified file. \item config : Specify an alernate configuration file. \end{itemize} Please check the prelude-manager --help output, or have a look to the prelude-manager configuration file for an exhaustive list. \subsection{Prelude-LML} Prelude-LML, or Prelude Log Monitoring Lackey, 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. \begin{itemize} \item Some example platforms are: \begin{itemize} \item Unix syssdtems \item Switches and routers \item Firewalls \item Printers \item Others systems which can log in Syslog format (like Windows NT/2K/XP with tools like Ntsyslog) \end{itemize} \end{itemize} By placing Prelude-LML on a network and configuring other machines to send log messages to the Syslog daemon, it is possible to monitor an entire network of machines? logs. \begin{itemize} \item Prelude-LML has two modes of operation: \begin{itemize} \item Watch log files on the host where it is running (syslog or any other). \item Receive UDP syslog messages from other hosts on the network. \end{itemize} \end{itemize} Prelude-LML?s primary function is log analysis. Logs on a local system or logs monitored over the network (if configured to accept syslog messages from other hosts) can be processed and analyzed in order to discover security anomalies. Prelude-LML has a plugin system which actually performs all analysis and monitoring. One of these plugins, called Pcre, is a regular expression engine powered by the PCRE (Perl Compatible Regular Expression) library. This plugin is used in Prelude LML to match a set of regular expressions (in common terms, signatures). Each ruleset provides regular expression matching for a particular purpose. Therefore, the Netfilter ruleset ?watches? for netfilter messages, and the GRSecurity ruleset ?watches? for GRSecurity messages. The configuration file tells Prelude-LML what analysis plugins to load and use to process logs. Here is a non exhaustive list of logs that Prelude-LML Pcre plugin has rulesets for: \begin{itemize} \item APC Environmental Monitoring Unit \item arpwatch \item F5 Big-IP \item Cisco PIX \item Cisco Router \item Cisco VPN Concentrator \item Clam Antivirus \item Dell OpenManage \item GRSecurity \item Honeyd \item IPChains \item IPFW \item Checkpoint IPSO \item mod\_security \item Norton Antivirus Corporate Edition \item NetApp? ONTAP \item Netfilter \item Windows NT/200x/XP \item PAM \item pcAnywhere \item SentryTools? Portsentry \item Postfix \item ProFTPd \item QPopper \item SELinux \item Sendmail \item GNU Shadow Utils \item Squid Proxy \item OpenSSH sshd \item GNU sudo \item Open Source Tripwire \item Vigor \item Vpopmail \item Linksys WAP11 \item Webmin \item WU-FTPd \item Exim \item Oracle \item tftpd \item P3Scan \item D-Link Wireless Router \end{itemize} With the power of PCRE (the regexp engine that the signature engine uses), writing additional rules is an easy task. \paragraph*{Multiple log files, different format} If you use multiple log file with different formatting, you can configure LML so that it know how to handle each log format. This is done using a format section, in the PreludeLML configuration file: \begin{lyxcode} {[}format=syslog]~ time-format~=~\char`\"{}\%b~\%d~\%H:\%M:\%S\char`\"{} prefix-regex~=~\char`\"{}\textasciicircum{}(?P.\{15\})~(?P\textbackslash{}S+) (?:(?P\textbackslash{}S+?)(?:\textbackslash{}{[}(?P{[}0-9]+)\textbackslash{}])?:~)?\char`\"{}~ file~=~/var/log/messages~ file~=~/var/log/auth.log~ udp-server~=~0.0.0.0:514 \end{lyxcode} Additionally, LML can accept different format from a single log source (be it a file, or the UDP server). As an example, using the following configuration, LML will know how to parse any of the specified format from /var/log/mylogfile and UDP 0.0.0.0:514: \begin{lyxcode} {[}format=syslog]~ time-format~=~\char`\"{}\%b~\%d~\%H:\%M:\%S\char`\"{}~ prefix-regex~=~\char`\"{}\textasciicircum{}(?P.\{15\})~(?P\textbackslash{}S+) (?:(?P\textbackslash{}S+?)(?:\textbackslash{}{[}(?P{[}0-9]+)\textbackslash{}])?:~)?\char`\"{}~ file~=~/var/log/mylogfile~ udp-server~=~0.0.0.0:514 {[}format=apache]~ time-format~=~\char`\"{}\%d/\%b/\%Y:\%H:\%M:\%S\char`\"{}~ prefix-regex~=\char`\"{}\textasciicircum{}(?P\textbackslash{}S+)~-~-~\textbackslash{}{[}(?P.\{20\})~\textbackslash{}+.\{4\}\textbackslash{}]\char`\"{} file~=~/var/log/mylogfile~ udp-server~=~0.0.0.0:514 \end{lyxcode} The format section allow several option: \begin{itemize} \item prefix-regex \end{itemize} This tell LML how to handle the log header. With this option, you can bind variable used by LML to fill specific fields in the generated IDMEF Alert. Variable that you can use are: \\ \begin{tabular}{|c|c|} \hline Variable& Usage\tabularnewline \hline \hline timestamp& Bind to the DetectTime? information of an IDMEF Alert\tabularnewline \hline hostname& Bind to the Target node information in an IDMEF Alert\tabularnewline \hline process& Bind to the Target process name in an IDMEF Alert\tabularnewline \hline pid& Bind to the Target process pid in an IDMEF Alert\tabularnewline \hline \end{tabular} \\ Here is an example of how it work, using the following prefix-regex: \begin{lyxcode} prefix-regex~=~\char`\"{}\textasciicircum{}(?P.\{15\})~(?P\textbackslash{}S+) (?:(?P\textbackslash{}S+?)(?:\textbackslash{}{[}(?P{[}0-9]+)\textbackslash{}])?:~)?\char`\"{} \end{lyxcode} Together with the following log entry: \begin{lyxcode} Dec~30~20:09:03~hacklab~honeyd{[}5711]:~this~is~a~log~entry \end{lyxcode} When LML parse this log entry using the above prefix-regex, the timestamp, hostname, process, and pid variable will be set to the following value: \\ \begin{tabular}{|l|l|} \hline Variable& Value\tabularnewline \hline \hline timestamp& Dec 30 20:09:03\tabularnewline \hline hostname& hacklab\tabularnewline \hline process& honeyd\tabularnewline \hline pid& 5711\tabularnewline \hline \end{tabular} \\ Each of these value will be assigned in the relevant IDMEF fields of the generated alert. Please note that 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. \begin{itemize} \item time-format \end{itemize} Should be set so that LML know how to format the timestamp in your log entry. This will be used to match the timestamp vaiable content defined through the prefix-regex option.\\ \begin{tabular}{|c|>{\raggedright}p{0.7\columnwidth}|} \hline Sequence& Description\tabularnewline \hline \hline \%\%& The \% character\tabularnewline \hline \%a or \%A& The weekday name according to the current locale, in abbreviated form or the full name.\tabularnewline \hline \%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.\tabularnewline \hline \%C& The century number (0-99).\tabularnewline \hline \%d or \%e& The day of month (1-31).\tabularnewline \hline \%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.)\tabularnewline \hline \%H& The hour (0-23).\tabularnewline \hline \%I & The hour on a 12-hour clock (1-12).\tabularnewline \hline \%j & The day number in the year (1-366).\tabularnewline \hline \%m & The month number (1-12).\tabularnewline \hline \%M & The minute (0-59).\tabularnewline \hline \%n & Arbitrary whitespace.\tabularnewline \hline \%p & The locale?s equivalent of AM or PM. (Note: there may be none.)\tabularnewline \hline \%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 behaviour is undefined.\tabularnewline \hline \%R & Equivalent to \%H:\%M.\tabularnewline \hline \%S & The second (0-60; 60 may occur for leap seconds; earlier also 61 was allowed).\tabularnewline \hline \%t & Arbitrary whitespace.\tabularnewline \hline \%T & Equivalent to \%H:\%M:\%S.\tabularnewline \hline \%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.\tabularnewline \hline \%w & The weekday number (0-6) with Sunday = 0.\tabularnewline \hline \%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.\tabularnewline \hline \%x & The date, using the locale?s date format.\tabularnewline \hline \%X & The time, using the locale?s time format.\tabularnewline \hline \%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).\tabularnewline \hline \%Y & The year, including century (for example, 1991).\tabularnewline \hline & \tabularnewline \hline \end{tabular}\\ 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 is used. The E modifier specifies that the input string may contain alternative locale-dependent versions of the date and time representation: \\ \begin{tabular}{|c|>{\raggedright}p{0.7\columnwidth}|} \hline Sequence& Description \tabularnewline \hline \hline \%Ec & The locale?s alternative date and time representation. \tabularnewline \hline \%EC & The name of the base year (period) in the locale?s alternative representation. \tabularnewline \hline \%Ex & The locale?s alternative date representation. \tabularnewline \hline \%EX & The locale?s alternative time representation. \tabularnewline \hline \%Ey & The offset from \%EC (year only) in the locale?s alternative representation. \tabularnewline \hline \%EY & The full alternative year representation.\tabularnewline \hline \end{tabular}\\ The O modifier specifies that the numerical input may be in an alternative locale-dependent format: \begin{tabular}{|c|>{\raggedright}p{0.7\columnwidth}|} \hline Sequence& Description\tabularnewline \hline \hline \%Od or \%Oe& The day of the month using the locale?s alternative numeric symbols; leading zeros are permitted but not required.\tabularnewline \hline \%OH& The hour (24-hour clock) using the locale?s alternative numeric symbols.\tabularnewline \hline \%OI& The hour (12-hour clock) using the locale?s alternative numeric symbols.\tabularnewline \hline \%Om & The month using the locale?s alternative numeric symbols.\tabularnewline \hline \%OM & The minutes using the locale?s alternative numeric symbols.\tabularnewline \hline \%OS & The seconds using the locale?s alternative numeric symbols.\tabularnewline \hline \%OU & The week number of the year (Sunday as the first day of the week) using the locale?s alternative numeric symbols.\tabularnewline \hline \%Ow & The number of the weekday (Sunday=0) using the locale?s alternative numeric symbols. \tabularnewline \hline \%OW & The week number of the year (Monday as the first day of the week) using the locale?s alternative numeric symbols. \tabularnewline \hline \%Oy & The year (offset from \%C) using the locale?s alternative numeric symbols.\tabularnewline \hline \end{tabular} \begin{itemize} \item file \end{itemize} A file to monitor, this option might be set several time if you want to monitor multiple files with this format. \begin{itemize} \item udp-server \end{itemize} Create an UDP server that is able to handle this format, and which listen to the specified address. \paragraph*{Ruleset Tuning} In order to get the best performance out of Prelude-LML, you need to tune it post-install. The most important thing to realize about the default Prelude-LML rulesets is that there are a wide range of devices supported, most of which are probably not even present in your environment. Each of these device rulesets that you leave turned on sap CPU cycles from the LML parser. The easiest way to ensure that LML runs efficiently is to turn off those rulesets you don't need. There are two places to do this: \begin{itemize} \item In pcre.rules, comment out the rulesets that don't apply. \item In single.rules, comment out the stand-alone rules that don't apply. \end{itemize} The largest performance gain you'll see will be from pruning single.rules. Each of the rulesets in pcre.rules has a required regex to allow events to be processed by them. single.rules rules, on the other hand, are individually evaluated for every incoming log line, and those regexes are larger and more complex than the pre-ruleset regexes on each of the other rulesets. Another thing you can do to speed up LML is to study and understand your per-device event rates and rearrange the ordering of the rulesets in pcre.rules to give preference to high event-rate devices. For instance, in Linux-heavy environments, you might places the rulesets that match the regex=kernel and regex=sshd pre-ruleset regex at the top of your ruleset list. In an environment where you were mostly monitoring PIX firewalls, you'd put the regex=\%PIX line at the top. This ensures that the high-rate events will hit a match and be removed from the parsing queue more quickly, resulting in better overall performance. \paragraph*{Using more than one Pcre (modifying prelude-lml.conf and plugins.rules)} In some case you will try to split your logfile and match differents rules on the multiple log files. In order to do that you must change the prelude-lml.conf and plugins.rules. By default if you do not specify a Pcre name, there will be only one Pcre named default. Example : \begin{itemize} \item You have two syslog files \char`\"{}first.log\char`\"{} and \char`\"{}second.log\char`\"{} and you have three rules files \char`\"{}1.rules\char`\"{} \char`\"{}2.rules\char`\"{} \char`\"{}3.rules\char`\"{} \item You need to create two different Pcre instance : \end{itemize} plugins.rules original : \begin{lyxcode} \#~filename~plugin-name-list~pcre-option~regex~\#~ ~~{*}~~~~~~~~Debug~~~~~~~~~~~~-~~~~~~~~~~~.{*}~ ~~{*}~~~~~~~~Pcre~~~~~~~~~~~~~-~~~~~~~~~~~.{*} \end{lyxcode} plugins.rules new file : \begin{lyxcode} \#~filename~~~~~~~~~~~~plugin-name-list~pcre-option~regex~ ~~/var/log/first.log~~Pcre{[}first]~~~~~~-~~~~~~~~~~~.{*} ~~/var/log/second.log~Pcre{[}second]~~~~~-~~~~~~~~~~~.{*} \end{lyxcode} And the new prelude-lml.conf : \begin{lyxcode} include~=~/usr/local/etc/prelude/default/idmef-client.conf \#next~you~specify~the~files~that~you~will~check~(if~you~do~not~put \#files~in~prelude-lml.conf~nothing~will~be~check) \#syslog~time-format~=~\char`\"{}\%b~\%d~\%H:\%M:\%S\char`\"{}~ prefix-regex=~\char`\"{}\textasciicircum{}(?P.\{15\})~(?P\textbackslash{}S+) (?:(?\textbackslash{}S+?)(?:\textbackslash{}{[}(?P{[}0-9]+)\textbackslash{}])?:~)?\char`\"{} file=~/var/log/first.log~ file=~/var/log/second.log {[}Pcre=first]~ ruleset=~/usr/local/etc/prelude-lml/ruleser/1.rules~ ruleset=~/usr/local/etc/prelude-lml/ruleser/2.rules {[}Pcre=second]~ ruleset=~/usr/local/etc/prelude-lml/ruleser/2.rules~ ruleset=~/usr/local/etc/prelude-lml/ruleser/3.rules \end{lyxcode} And when you lauch prelude-lml you should see : \begin{lyxcode} Subscribing~plugin~pcre{[}first]~ Monitoring~/var/log/first.log~ Subscribing~plugin~pcre{[}second]~ Monitoring~/var/log/second.log \end{lyxcode} \paragraph*{Filtering specific events} In order to filter certain events, you need to create a rule dedicated to matching the event you wish to filter out. As an example, if you want to skip all PAM events concerning a successful login by alex, triggered by the following log entry: \begin{lyxcode} Apr~10~16:40:05~bigamd~sshd(pam\_unix){[}10566]:~ session~opened~for~user~alex~by~(uid=0) \end{lyxcode} You could add the following rule before the one triggering an alert: \begin{lyxcode} regex=session~opened~for~user~alex~by~(\textbackslash{}S{*})\textbackslash{}(uid=(\textbackslash{}d{*})\textbackslash{});~last \end{lyxcode} The last keyword tell the engine that further processing should stop if this rule is matched. Please note that rules are evaluated from top to bottom, so this must be inserted before the rule that actually match. \paragraph*{Creating and contributing rules} Rulesets that you contribute to the Prelude-LML maintainer should follow these guidelines: \begin{itemize} \item Avoid using .+ or .{*} in regex entries unless actually neccessary. Doing so will make your rule CPU-costly to implement. \item Avoid capturing variables which you don't use. This causes unneccessary memory consumption. \item At a minimum, include regex, classification().name, assessement.impact.severity, assessment.impact.type, impact.description. \item If it's correct for this application, use the last keyword. \item Put only a single field on each line of your rules. \item Include a sample log entry with each rule. \item Gather as many pieces of data, and fill as many IDMEF fields as possible from the log entry. \item If a similar rule exists in another ruleset (same function, different software), use the classification().name from the other rule. \item Use only the actual log message, none of the syslog headers (this generally includes timestamp, originating node, originating process, and pid). \item Submit new rulesets to the prelude-devel mailing list for consideration. \end{itemize} Below you will find a listing of most of the IDMEF fields Prelude-LML accepts. Where you see an item listed with (), it means that item is indexed. Indexing starts at 0, so, for example, an event with multiple targets would have the first target listed as target(0), followed by whatever IDMEF fields you use. See the existing rulesets for examples. \begin{itemize} \item regex: A PCRE regex that should be matched to trigger the alert. \item classification.text: The name of the alert, from one of the origins listed below. \item classification.reference().origin: The type of reference. The permitted values are: unknown, vendor-specific, user-specific, bugtraqid, cve, osvdb \item classification.reference().name: A exactly one string containing the name of the reference from the source. If classification.reference().name=bugtraqid This could be a bugtraqid \item classification.reference().meaning: A brief manager (or the human operator of the manager) description of the alert \item classification.reference().url: A URL at which the manager (or the human operator of the manager) can find additional information about the alert. The document pointed to by the URL may include an in-depth description of the attack, appropriate countermeasures, or other information deemed relevant by the vendor. \item assessment.impact.severity: An estimate of the relative severity of the event. Possible values are: info, low, medium, high. \item assessment.impact.completion: An indication of whether the analyzer believes the attempt that the event describes was successful or not. The permitted values are: failed, succeeded. \item assessment.impact.type: The type of attempt represented by this event, in relatively broad categories. The permitted values are: admin, dos, file, recon, user, other. \item assessment.impact.description: May contain a textual description of the impact, if the analyzer is able to provide additional details. \item source().node.address().address, target().node.address().address: Address that has been attacked/Address that issued the attack. There can be more than one. \item source().node.address().category, target().node.address().category: The type of address provided. Possible values: unknown, atm, e-mail, lotus-notes, mac, sna, vm, ipv4-addr, ipv4-addr-hex, ipv6-addr, ipv6-addr-hex, ipv6-net, ipv6-net-mask \item source().node.address().vlan\_name, target().node.address().vlan\_name: The name of the Virtual LAN to which the address belongs. \item source().node.address().vlan\_num, target().node.address().vlan\_num: The number of the Virtual LAN to which the address belongs. \item source().node.name, target().node.name: The name of the equipment. This information MUST be provided if no Address information is given. \item source().node.category, target().node.category: The domain from which the name information was obtained. Possible values are: unknown, ads, afs, coda, dfs, dns, hosts, kerberos, nds, nis, nisplus, nt, wfw \item source().node.location, target().node.location: The location of the equipment. \item source().spoofed, target().decoy: An indication of wheter the source/target is a decoy. The permitted values are: unknown, yes, no. \item source().interface, target().interface: May be used by a network-based analyzer with multiple interfaces to indicate which interfaces this source/target was seen on. \item source().service.name, target().service.name: The name of the service. Whenever possible, the name from the IANA list of well-known ports SHOULD be used. \item source().service.port, target().service.port: The port number being used. \item source().service.protocol, target().service.protocol: The protocol being used. \item source().service.portlist, target().service.portlist: A list of port numbers beeing used. \item source().user.category, target().user.category: The type of user represented (unknown, application, os-device). \item source().user.user\_id(). target().user.user\_id(). Create a new UserId? inside an User object (that may contain several UserId?). \item source().user.user\_id().type, target().user.user\_id().type: The type of user information represented (current-user, original-user, target-user, user-privs, current-group, group-privs, other-privs). \item source().user.user\_id().name, target().user.user\_id().name: A user or group name. \item source().user.user\_id().number, target().user.user\_id().number: A user or group number. \item source().process.name, target().process.name: A process name \item source().process.pid, target().process.pid: A process number \end{itemize} \subsection{Prelude-Import} Prelude-Import is a commercial extension available from PreludeIDS Technologies. Please check the Corporate Modules page for more information. Prelude-Import is a tool whose purpose is to import data from applications that report events in a specific format. It can also be used to emit alert from a security shell script. As of now, three different alerts format are supported: \begin{itemize} \item IDMEF XML: Import IDMEF-XML and convert it to the native Prelude-IDMEF format. \item Nessus XML: Import Nessus vulnerability scan XML report. \item IDMEF Object: A Prelude specific IDMEF format, very handy for textual representation. \end{itemize} \paragraph*{Importation options} \begin{itemize} \item dry-run - Print the result without sending the data. \item verbose - Print information regarding what is done. \item format - Force the input to be interpreted using the specified format. \item text-output - Dump the imported events to the specified file. \end{itemize} Please check prelude-import --help output for more options. \paragraph*{Importing data} Prelude-Import will automatically probe the type of file you provide it on the command line, and use the appropriate plugin for importing each file. Here is the command to use in order to import a file, or a set of file: \begin{lyxcode} prelude-import~~~ \end{lyxcode} You might also specify - for stdin, but it then become mandatory to manually specify the input format using the format command line option. \paragraph*{IDMEF XML file importation Example} Prelude-Import come with a set of test file. Here we're going to import idmef-example-12.xml, which contain an heartbeat. Since the -v (verbose) argument is provided, PreludeImport will print information on each imported IDMEF attribute. The generated event won't be sent since the dry-run option was specified. \begin{lyxcode} \$~prelude-import~-v~-{}-dry-run~tests/idmef-xml/idmef-example-12.xml Using~'idmef-xml'~to~handle~'tests/idmef-xml/idmef-example-12.xml': ~~Created~path~heartbeat.messageid=abc123456789~ ~~Created~path~~~heartbeat.analyzer(0).analyzerid=hq-dmz-analyzer01~ ~~Created~path~heartbeat.analyzer(0).node.category=dns ~~Created~path~heartbeat.analyzer(0).node.location=Headquarters~DMZ Network~ ~~Created~path~heartbeat.analyzer(0).node.name=analyzer01.example.com~~ ~~Created~path~heartbeat.create\_time=0xbc722ebe.0x00000000~ ~~Created~path~heartbeat.additional\_data(0).type=real~ ~~Created~path~heartbeat.additional\_data(0).meaning=\%memused~ ~~Created~path~heartbeat.additional\_data(0).data=62.5~ ~~Created~path~heartbeat.additional\_data(1).type=real~ ~~Created~path~heartbeat.additional\_data(1).meaning=\%diskused~ ~~Created~path~heartbeat.additional\_data(1).data=87.1 \end{lyxcode} \paragraph*{Importing Nessus Vulnerability assessment} Using PreludeImport, you can also generate events for every vulnerability reported by the Nessus vulnerability scanner. Nessus data might be used to warn the analyst about a new machine property (new port opened/closed), and to regularly check and issue alert when new vulnerability are found by Nessus. \begin{lyxcode} yoann@arwen~\textasciitilde{}/dev/prelude/svk/branches/private/prelude-import~\$ \textasciitilde{}/dev/prelude/bin/bin/prelude-import~-v~-{}-dry-run tests/nessus-xml/nessus.xml Using~'nessus-xml'~to~handle~'tests/nessus-xml/nessus.xml': Created~path~alert.analyzer(0).version~ Created~path~alert.analyzer(0).node.name~ Created~path~alert.analyzer(0).ostype~ Created~path~alert.analyzer(0).osversion~ Created~path~alert.detect\_time~ Created~path~alert.source(0).node.address(0).address~ Created~path~alert.source(0).user.category~ Created~path~alert.source(0).user.user\_id(0).name~ Created~path~alert.source(0).user.user\_id(0).type~ Created~path~alert.target(0).node.name~ Created~path~alert.target(0).node.address(0).address~ Created~path~alert.target(0).service.port~ Created~path~alert.target(0).service.name~ Created~path~alert.source(0).spoofed~ Created~path~alert.assessment.confidence.rating~ Created~path~alert.assessment.impact.completion~ Created~path~alert.classification.text~Sending~IDMEF~message. Created~path~alert.target(0).service.port~ Created~path~alert.target(0).service.name~ Created~path~alert.source(0).spoofed~ Created~path~alert.assessment.confidence.rating~ Created~path~alert.assessment.impact.completion~ Created~path~alert.classification.text~ Sending~IDMEF~message. Created~path~alert.target(0).service.port~ Created~path~alert.target(0).service.name~ Created~path~alert.source(0).spoofed~ Created~path~alert.assessment.confidence.rating~ Created~path~alert.assessment.impact.completion~ Created~path~alert.classification.text Sending~IDMEF~message. Created~path~alert.target(0).service.port~ Created~path~alert.target(0).service.name~ Created~path~alert.source(0).spoofed~ Created~path~alert.assessment.confidence.rating~ Created~path~alert.assessment.impact.completion~ Created~path~alert.classification.text~ Sending~IDMEF~message. {[}snip] \end{lyxcode} \paragraph*{Generating events from the shell} Using the IDMEF-object Prelude internal format, it is trivial to generate events from a security shell script. Here is an example: \begin{lyxcode} \$~echo~\char`\"{}~ >~alert.messageid~=~blah~ >~alert.classification.text=This~is~an~event~generated~from~the~shell >~\char`\"{}~|~\textasciitilde{}/dev/prelude/bin/bin/prelude-import~-v~-{}-dry-run~-{}-format idmef-object~- Using~'idmef-object'~to~handle~'-':~ ~~Created~object~alert.messageid=blah~ ~~Created~object~alert.classification.text=This~is~an~event~generated from~the~shell~ \end{lyxcode} \subsection{Prewikka} Once you have successfully installed Prewikka. You will need to do some initial configuration to get it going and customized as you want it. You will first want to login as admin and set your password to something other than the default. \begin{itemize} \item Users permissions \item Alert listing \item Agents listing \item Browsable statistics \end{itemize} \subsection{High Availability Prelude Central Services } This is an example configuration utilizing two machines to provide a high availability pair for the central Prelude services, which include: PreludeManager, PreludeCorrelator, Prewikka, and Mysql. Heartbeat will control the failing over of hard failures, such as a machine going down or total loss of connectivity. Both servers will maintain an up-to-date set of databases, and either can take over at a moments notice as the primary. You will need to use some form of monitoring, such as Nagios to handle service failures - thus alerting you when a manual failover is required (such as if a particular service dies, but the hardware remains operational and reachable). Things that are assumed: \begin{itemize} \item You will need at least two ethernet interfaces per server (and two servers). \item Assumes you have eth0 configured with IP/hostnames on both boxes. This example uses preludecentral\_1 and preludecentral\_2, and a VIP (virtual IP) with associated hostname, such as preludecentral. Make sure you also add the VIP/hostname to DNS/host/etc., as this is what you expose to your clients/relays/agents/etc. \item This document assumes high availability for fault tolerance, not for performance. Although you could stagger which services are offered where, etc. \end{itemize} \paragraph*{MySQL Multi-Master Replication Configuration} {*}{*}{*}You must have installed MySQL v5.x or above. Some features to avoid collisions in multi-master replication are only available in MySQL v5.x{*}{*}{*} \begin{itemize} \item Setup secondary ethernet interfaces \begin{itemize} \item Setup eth1 on each server to be an unused private network for use by your HA pair. \item Connect with a crossover cable between them. \end{itemize} \item Make the following additions on both servers in /etc/my.cnf, under {[}mysqld] section: \end{itemize} \begin{lyxcode} wait\_timeout=259200~ interactive\_timeout=259200~ max\_connections=200 log-bin=<\$HOSTNAME>-mysql-bin~\#change~hostname~to~be~each~machines~hostname server-id=\{1,2\}~\#set~one~server~for~1~and~the~other~for~2 auto\_increment\_increment=2~ auto\_increment\_offset=\{1,2\}~\#set~one~server~for~1~and~the~other~for~2 \#~Timeouts~and~max~connections~have~been~increased~to~handle~a~client \#disconnect~issue. \#~Various~other~settings~can~be~adjusted~to~the~specs~of~your~machine, \#such~as~buffer~sizes,~log~sizes,~etc. \end{lyxcode} \begin{itemize} \item Change datadir in /etc/my.cnf to be on a partition of its own of acceptable size, edit /etc/fstab, and add \char`\"{}async,noatime\char`\"{} as options for the partition used for the MySQL database directory. \item Run mysql on each server: \begin{itemize} \item Enter at prompt: GRANT REPLICATION SLAVE on {*}.{*} TO some\_replication\_user IDENTIFIED by 'putreplicationpasswordhere'; \end{itemize} \item Add to the end of the mysql binary line in the start section of /etc/init.d/mysqld \begin{itemize} \item --relay-log=\textless{}\$HOSTNAME\textgreater{}-relay-bin \#make sure to specify the correct hostname \end{itemize} \item From each server's mysql command-line: show master status; \item From each server's mysql command-line: change master to master\_host='\textless{}other hosts eth1 private ip address\textgreater{}', master\_user='\textless{}username setup earlier for replication\textgreater{}', master\_password='\textless{}password used earlier for replication\textgreater{}', master\_log\_file='\textless{}output of 1st column from above step on other server', master\_log\_pos=\textless{}output of 2nd column from above step on other server\textgreater{}; \item Restart mysqld on each of the servers \item Configure a root mysql password from the mysql command-line (only needs to be done on one server): \begin{itemize} \item SET password for root@localhost=password('putmysqlrootpasswordhere'); \item FLUSH PRIVILEGES; \end{itemize} \end{itemize} \paragraph*{Prelude Central Components} \begin{itemize} \item You must install libprelude, libprelude-db, PreludeManager, PreludeCorrelator and Prewikka on both machines. \item All of the central Prelude services should have the same configuration files on both servers (ie. prelude-manager, prelude-correlator, apache, etc.) \item When importing the prelude and prewikka schemas to their respective databases, it only needs to be done on one of the servers, it will be replicated to the other automatically. \item Copy over profiles (if you have a Prelude Central already setup) or register for all profiles needed: correlator, manager, prewikka. Do this on one server, then copy those profiles/directories under /usr/local/etc/prelude/profile/ of the other machine in the HA pair. \item Edit /usr/local/etc/prelude/default/global.conf, make 'Node Name' the name of the VIPs hostname on both. Copy over to other HA server. \item Your web server and MySQL should be set to start automatically on boot. Prelude Manager and Correlator should NOT be set to start automatically on boot, as Heartbeat will handle these two services. \end{itemize} \paragraph*{Setting up the Heartbeat Pair} \begin{itemize} \item Heartbeat Configuration \begin{itemize} \item Install heartbeat, and all packages necessary such as stonih, pils, etc. that are required by your package manager. \item Configure heartbeat to start on boot. \item Create /etc/ha.d/ha.cf debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 auto\_failback off deadtime 30 bcast eth1 eth0 node preludecentral\_1 node preludecentral\_2 \item Create /etc/ha.d/haresources preludecentral\_1 IPaddr::192.168.1.25 prelude-manager prelude-correlator \begin{itemize} \item Use your primary hostname, assumes 192.168.1.25 is your VIP, and that you called your init scripts prelude-manager and prelude-correlator \end{itemize} \item Create /etc/ha.d/authkeys; make sure to chmod 600 it auth 1 1 sha1 some\_password \end{itemize} \item Set the Heartbeat service to start on boot automatically. \end{itemize} \paragraph*{Service Monitoring} \begin{itemize} \item Setup SNMP monitoring with something such as Nagios \begin{itemize} \item For the VIP hostname/IP \begin{itemize} \item Ping \item Apache \item Prelude Manager \item Prelude Correlator \item Prewikka Ctl \item TCP Port 4690 \end{itemize} \item For each hostname/IP of the pair \begin{itemize} \item Ping \item Diskspace \item MySQL \item Heartbeat \end{itemize} \end{itemize} \item Set the snmpd service to start on boot automatically. \end{itemize} \paragraph*{Clients / Relays / Agents} \begin{itemize} \item Make sure all clients, agents, relays, etc. connect to your VIP hostname/IP. \end{itemize} \section{Troubleshooting} \subsection{Libprelude} \begin{itemize} \item I get \char`\"{}TLS server certificate is NOT trusted\char`\"{} \end{itemize} Answer: You most probably used the \char`\"{}sensor analyzer profile\char`\"{} instead of the \char`\"{}receiving analyzer profile\char`\"{} on the registration-server command line. You can find more information about your problem here: http://thread.gmane.org/gmane.comp.security.ids.prelude.user/1926/focus=1927 Typical case: When you register a sensor, don't register it to the sensor itself! \begin{lyxcode} sudo~prelude-admin~register~NAME~...~ sudo~prelude-admin~registration-server~NAME \end{lyxcode} But register it to your prelude-manager, example: \begin{lyxcode} sudo~prelude-admin~register~NAME~...~ sudo~prelude-admin~registration-server~prelude-manager \end{lyxcode} \begin{itemize} \item How can I validate a IDMEF message ? \end{itemize} Answer: First run prelude-manager with XMLmod and activate the DTD validation option. Then, generate an exhaustive list of alerts supported by the sensor and correct any error. Open a bug on the ticket system, and ask a review of the alert dumped by the debug plugin. \subsection{Libpreludedb} libpreludedb has a problem with prelude-manager. in start time of run of prelude-manager you see this message \char`\"{}error initializing libpreludedb\char`\"{} in compiling time you should enable perl , mysql , python option such as this: make WITH\_PERL=1 WITH\_PYTHON=1 WITH\_MYSQL=1 and for libprelude you should compile with: make WITH\_PERL=1 WITH\_PYTHON=1 \subsection{PreludeManager?} ... \subsection{Prelude-LML} \begin{itemize} \item I get an error concerning auth.log when starting prelude-lml? \end{itemize} Answer: This is due to some systems using authlog or secure for the same purpose. To remedy this issue just edit prelude-lml.conf to point to the correct auth log depending on your system. \begin{itemize} \item I get an error \char`\"{}End from FAM server connection\char`\"{} after some time, and no more alert are sent? \end{itemize} Answer: This is due to FAM, the best way to get prelude-lml working correctly is by recompiling the prelude-lml without FAM (./configure --disable-fam). FAM just help getting files checked when there are modifications, without FAM, prelude-lml will check files modification every second. \begin{itemize} \item Prelude-LML warn that it could not match prefix against log entry or that there is no appropriate format defined for log entry \end{itemize} Answer: This warning mean that wiki:PreludeLML was unable to find a matching format (defined in the prelude-lml configuration file) for the input log. The log entry will still be processed by the signature engine, but wiki:PreludeLML won't have access to the following information: \begin{itemize} \item The log entry timestamp (Bound to the DetectTime? information of an IDMEF Alert). \item The log entry hostname (Bound to the Target node information in an IDMEF Alert). \item The log entry process (Bound to the Target process name in an IDMEF Alert). \item The log entry pid (Bound to the Target process pid in an IDMEF Alert). \end{itemize} In order to fix this problem, you need to configure an appropriate format section in the configuration file that instruct PreludeLML how to parse a given log format. \subsection{Prewikka } \begin{itemize} \item Prelude Database shema version too old error message? \end{itemize} Answer: You must change the mysql shema using a pre-made script : \begin{lyxcode} >mysql~-u~prelude~prelude~-p~< /usr/share/libpreludedb/classic/mysql-update-14-1.sql~syntaxe~:~mysql -u~~~-p~< /usr/share/libpreludedb/classic/mysql-update-14-1.sql \end{lyxcode} NOTE: Sometimes the path would be /usr/local/share/. . . \begin{itemize} \item I have issues with Prelude and apache configuration since I want Prewikka in a sub-directory. \end{itemize} Answer: You are already using your web server for something else and you want to have an access using http://www.mycompany.xx/prelude : \begin{lyxcode} Alias~/prelude/prewikka~/usr/share/prewikka/htdocs/~ScriptAlias /prelude/~/usr/share/prewikka/cgi-bin/prewikka.cgi~ ~ ~~AllowOverride~None~ ~~Options~ExecCGI ~~~ ~~~~AddHandler~cgi-script~.cgi~ ~~ ~~Order~allow,deny~ ~~Allow~from~all~ \end{lyxcode} \begin{itemize} \item Abnormal Offline Agents and MySQL table 'Prelude\_Analyzer' is full \end{itemize} Answer: If checking the mysql log you find that : \begin{lyxcode} MySQL~Query~error:~The~table~'Prelude\_Analyzer'~is~full \end{lyxcode} Then you may need to alter a setting in my.cnf (maybe back it up first) So find the line \begin{lyxcode} innodb\_data\_file\_path~=~ibdata1:10M:autoextend:max:128M \end{lyxcode} and try changing it to read: \begin{lyxcode} innodb\_data\_file\_path~=~ibdata1:10M:autoextend \end{lyxcode} After a restart of mysql, prelude-manager, lml etc. hopefully this will bring your prewikka back online. (With thanks to Yoann on prelude-user mailing list)