%% 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{Architecture and Concepts} \subsection{Introduction to Prelude} \subsubsection*{What is Prelude ? Foreword } Prelude was born from the observation that more and more IDS systems each with their own specificity have been made available, but that no framework exists in order to unify information provided by these different systems in order to unify and centralize events. We believe that relying on a single source of information in order to perform security analysis is not sufficient since different analysis methods have different avantages, and that unifying theses methods in a strong and powerful product is the only means to come to a stronger security analysis tool. Prelude is a Hybrid IDS framework, that is, it is a product that enables all available security applications, be they open source or proprietary, to report to a centralized system. In order to achieve this task, Prelude relies on the IDMEF (Intrusion Detection Message Exchange Format) IETF standard, that enables different kinds of sensors to generate events using a unique language. In this context, hybrid means that Host agent data is combined with network information to form a comprehensive view of the network. In the Prelude view, 'hybrid' means that you can combine events detected by any security applications (Network IDS, Log analyzer, Security application, Security shell script, or put simply, anything...provided that it reports security events). Prelude provides a C, Python, and Perl framework so that you can convert existing security applications to use the Prelude system. It also provides some home-made sensors such as a log analyzer (PreludeLML). A Prelude sensor is a program which has the ability of using the Prelude framework. \includegraphics[width=1\columnwidth]{images/framework4} \subsubsection*{Prelude components } \begin{itemize} \item The Prelude library: Framework. \end{itemize} Libprelude is the library that provides the framework used to access the Prelude system. It handles secure communications with one or several prelude-manager collectors, and provides an API (Application Programming Interface) to create IDMEF (Intrusion Detection Message Exchange Format) based events. It also provides important features like failover (saving to a local file for later retransmission, usage of a fallback route), in case one of the prelude-manager servers goes down. Moreover, it gives you the ability to create sensors that read events received by one or a set of prelude-managers. You could for example write an interactive notification system using this feature. \begin{itemize} \item Prelude-Manager: Collects and normalize events. \end{itemize} The PreludeManager is a high-availability server which collects and normalizes information from distributed sensors and stores them into a database (or any kind of user-provided media). It also provides the ability to relay received events to one or several other prelude-manager servers. It also provides you the ability to filter received events so that you can provide specific actions for specific events. \begin{itemize} \item Prelude-LML: Log analyzer, Syslog events collector. \end{itemize} PreludeLML is a signature-based log analyzer monitoring your logfile and received syslog messages for suspicious activity. It handle events generated by a large set of components, including but not limited to: APC Emu, BigIP, Cisco PIX, Clamav, Dell-OM, Grsecurity, Honeyd, ipchains, Netfilter, ipfw, Nokia ipso, Apache ModSecurity?, Ms-SQL, Nagios, Norton Antivirus Corporate Edition, NTsyslog, Pam, Portsentry, Postfix, Proftpd, ssh, etc. Prelude-LML was written in order to easily integrate third party products, most particularly products that can't be modified directly to use the Prelude library. \begin{itemize} \item The PreludeDB library : Easy access to the Prelude database. \end{itemize} The PreludeDB Library provides an abstraction layer based upon the type and the format of the database used to store IDMEF alerts. It allows developers to use the Prelude IDMEF database easily and efficiently without worrying about SQL, and to access the database independently of the type/format of the database. \begin{itemize} \item Prewikka: The Prelude-IDS console. \end{itemize} Prewikka is a professional application providing advanced features like contextual filtering, aggregation, etc. Prewikka is a large step forward compared to Piwi. \subsection{Prelude architecture } \subsubsection*{Simplified architecture} Prelude is divided in several components. Sensors are responsible for intrusion detection, and report events in a centralized fashion using a TLS connection to a 'prelude-manager' server. The prelude-manager server can then process theses events and deliver them to an user specified media (mysql database, postgresql database, XML file, any format provided there is a report plugin for it). The Prelude console can then be used to view theses events. Here is a simple example of how the differents Prelude components interacts:\\ \includegraphics[width=1\columnwidth]{images/prelude-simple-architecture} \subsubsection*{Relaying} Relaying is a feature which allows the prelude-manager program to 'forward' received events to another 'prelude-manager' program. The following ilustration shows this:\\ \includegraphics[width=1\columnwidth]{images/prelude-architecture}\\ In the above example, 'Branch A' of the company only has access to events generated by Sensor A, B and C. However the company 'Security Center' can see events generated both by it's own sensors (D, E and F), as well as the events generated by the others company branch (like Branch A). \subsubsection*{Reverse relaying} On certain networks, it can sometimes be difficult or troublesome to arrange network permissions so that a program can connect to a server out of a given zone (for example, a firewall might not allow DMZ machines to connect outside of their own network). In this specific case, you can configure the external 'prelude-manager' program to connect to another internal 'prelude-manager' located inside the DMZ network, and to read the event emited from it.\\ \includegraphics[width=1\columnwidth]{images/prelude-reverse-relaying}\\ \subsection{Prelude components } \subsubsection*{Sensor: sending information} A Sensor is a program analysing a stream of information, and generating events when malicious activity is detected. Events are described using the IDMEF (Intrusion Detection Exchange Format) standard, although a binary version instead of XML of this standard is used for speed processing reasons in the Prelude implementation. Prelude has a large number of sensors, including, but not limited to Snort, Samhain, PreludeLML (itself including hundred of differents sensors), libsafe, (...). You can check the list of available sensors on the Prelude website in the Download section. If you want to know how to install a sensor, either refer to this handbook, in the section covering installation, or read the installation instructions given by sensors authors. Any sensor must be connected to one or several managers. This can be configured from the system wide Prelude configuration file (which will impact all sensors installed on the system), or on a per sensor basis through their own configuration file or using available command line options. \subsubsection*{Managers: collecting information} The prelude-manager is a high availability server which collects information from distributed sensors or prelude-manager and stores them into a database (or any kind of user provided media). It also provides the ability to relay received events to one or several other prelude-manager servers, and to filter received events so that you can provide specific actions for specific events. The communication between a Manager and its clients is encrypted using SSL. In order for a client to be able to communicate with a Prelude-Manager server, the client needs to be registered. \subsubsection*{Frontends: displaying human-readable information} The frontend provides a means to query the Prelude database, aggregate and filter events, and provides useful statistics about what's going on. It provides a nice interface for the security analyst to see what's going on on the monitored system. Prewikka is the official front-end. \subsection{IDMEF for reporting events } Since Prelude handles events from different kinds of sensors, a generic events description language had to be chosen. Prelude uses IDMEF as the common languages for reporting events. IDMEF started because of the lack of open standard for an Intrusion Detection Systems Exchange Format. The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. The Intrusion Detection Message Exchange Format (IDMEF) is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they deem suspicious. The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation. The IDMEF Experimental RFC is available on IETF website : http://tools.ietf.org/rfc/rfc4765.txt IDMEF is originally intented to be an XML language. However since speed concerns arise when generating and using XML, or when converting events binary data to characters, the Prelude project has written a home-made implementation of the IDMEF specification, using binary structure, and preserving original datatype used to carry specific data. Full IDMEF-XML compliance is preserved since components like PreludeManager and PreludeImport can output and import XML based IDMEF within the Prelude system.