OSSIM data flow. (

Transcription

1 OSSIM data flow SIMS Project - Security Intrusion Management System ( Author : Joël Winteregg (joel.winteregg@eivd.ch) Supervisor : Prof. Stefano Ventura Institute : Swiss University of Applied Sciences (EIVD) Tcom institute ( Date : 4th October 2005 Document version : 1.0

2 Contents 1 OSSIM software and network data flow Ossim-server and Ossim-agent softwares Architecture data flow with a Snort probe Why using two informations flows? Architecture data flow with an Ntop probe and the agent RRD plugin What s Ntop? Data flow explanations Architecture data flow with a P0f probe What s P0f? Data flow explanations Architecture data flow with a TCPTrack probe What s TCPTrack? Data flow explanations Architecture data flow with a PADS probe What s PADS? Data flow explanations Architecture data flow with a Syslog probe What s an HIDS probe Data flow explanations

3 Chapter 1 OSSIM software and network data flow Some others informations about installation are available in the appendix or on the official OSSIM web site ( 1.1 Ossim-server and Ossim-agent softwares Ossim-agent fetch informations from plugins (probes) log files (ie: file fast.log for Snort), create an alert with informations contained in log files and send it to OSSIM server which use it for a real time process. Ossim-agent is also able to start and stop plugins (probes) connected to it. So, we won t need to start Snort by hand because the Ossim-server web interface (Ossim-framework) will allow us to manage it (start and stop) using a web page. Ossim-server is the core part of OSSIM. Indeed, it containes correlation analysis modules and agent management modules. Ossim-framework is also installed on the server and it make the link between the web management interface (php interface) and Ossim-server. 1.2 Architecture data flow with a Snort probe OSSIM data flow with a Snort probe is illustrated by 1.1 figure. We can see that the IDS 1 is totaly independent from OSSIM client (named: Ossim-agent) and that two informations flows are emit to Ossim-server Why using two informations flows? The flow called SQL request for Snort alerts update is used to put alerts in Snort database ( Snort DB on figure 1.1) on the server side. This database is used to record Snort alerts 2 to allow the 1 Intrusion Detection System 2 using Snort database output plugin 2

4 Figure 1.1: Data flow between a Snort probe and OSSIM server security administator to browse them using ACID 3. This interface provide a perfect alerts search engine and dump viewer for the security administator who want to do a deep analysis on specific alerts. The flow called Alerts for real time process (TCP and OSSIM software protocol) is used by Ossim-server to get alerts information for the real time correlation engine. Theses two redundant data flows are needed to allow a real time process on the server. If you don t want to develop a new output plugin for Snort you will have to use these different flows. Indeed, the MySql Snort output plugin doesn t allow a real time process since a database storage break the real time process. A real time process using a database storage, will imply a high rate of SQL query to discover, as fast as possible, new database entry (alerts). OSSIM s developers better use two different flows rather to develop a new Snort output plugin able to create OSSIM alerts nedded by the real time process of Ossim-server. In such case (new output plugin), the server would have to fetch alerts for the real time process and store them in the Snort DB. OSSIM only use alerts coming from the Ossim-agent for the correlation and analysis process. Informations coming directly from Snort are only used by the Security administator to browse and look for specific alerts. 3 Analysis Console for Intrusion Databases, web interface included in OSSIM and used to browse Snort DB ) 3

5 1.3 Architecture data flow with an Ntop probe and the agent RRD plugin OSSIM data flow with an Ntop probe is illustrated by 1.2 figure. Figure 1.2: Data flow between an Ntop probe (with RRD plugin) and OSSIM server What s Ntop? This real time software is used for network statistics. It provides informations about protocols, datas (recevied and sent) of a specific interface. Statistics are calculated from counters like IP DNSBytes, IP HTTPBytes, etc... which are used to count bytes on the specified interface. Ntop probe include a web server (on port 3000) used as statistics monitor and remote configuration interface. The output RRD 4 plugin is used for OSSSIM heuristique and threshold functionalites. This plugin allow to record Ntop datas in a round robin (oldest values are erased by new one). Then, queries to the RRD database are done by RRDtool 5 used by rrd plugin.pl for heuristique and threshold check for OSSIM. Thresholds and heuristics parameters can be set up from the framework (OSSIM web interface) by the security administator. This configuration will be checked by rrd plugin.pl which will raise alerts when excessive values will be found. 4 Round Robin Database 5 oetiker/webtools/rrdtool/ 4

6 1.3.2 Data flow explanations The rrd plugin.pl Perl script will be used to do the link between Ntop and OSSIM agent for heuristics functionality (Holt-Winter algorithm) and threshold detection. This script will query the round robin database (illustrated by the Ntop/rrd log file on 1.2 figure) using RRDtool. Then, it query the database framework (using SQL query to the server) to fetch threshold and heuristic configuration 6. Now, the Perl script will compare datas coming from configuration to round robin datas (which have been fetched before). Threshold or heuristic excess will be saved in a log file (/var/log/ossim/rrd plugin.log) which will be used by Ossim-agent to generate real time alerts to the server. 1.4 Architecture data flow with a P0f probe OSSIM data flow with a P0f probe is illustrated by 1.3 figure. Figure 1.3: Data flow between a P0f probe and OSSIM server 6 Configuration set up by the security adminisrator using RRD config in the framework Configuration menu 5

7 1.4.1 What s P0f? P0f is an Open Source software used for operating systems (OS) passive detection. P0f check network informations and compare them to its OS finger print database to find the source operating system of datas fetched on the network. It can also do others jobs: 1. NAT and firewall detection 2. Load balancer detection 3. Hope distance (TTL) to the data source (sender) and up time from boot P0f is totaly passive and will never start doing network traffic! Data flow explanations It s a quite simple one. P0f write its logs (OS detected) in /var/log/ossim/p0f.log file. This log file path is given to P0f plugin by the OSSIM agent during P0f start and is set up in the agent plugin configuration (file /etc/ossim/agent/plugins/p0f.xml). Then, OSSIM agent software read the log file and send real time alerts to the server. 1.5 Architecture data flow with a TCPTrack probe OSSIM data flow with a TCPTrack probe is illustrated by 1.4 figure What s TCPTrack? TCPtrack is a sniffer which displays information about TCP connections it sees on a network interface. It passively watches for connections on the network interface, keeps track of their state and displays a list of connections in a manner similar to the unix top command. It displays source and destination addresses and ports, connection state, idle time, and bandwidth usage Data flow explanations TCPTrack data flow look like web display of Ntop informations. Indeed, no alerts are sent from TCP- Track to OSSIM server. TCPTrack only listen on a special port 7 on the loopback interface. Then, during correlation process, OSSIM server will ask for TCP informations to agents (when needed by a correlation directive). The requested agent will then send the server request to its TCPTrack probe (using the loopback). When the agent get the answere, it will send it back to the server which will use it in its correlation process. The agent act like an intermediary module between OSSIM server and TCPTrack. 7 default port,

8 Figure 1.4: Data flow between a TCPTrack probe and OSSIM server 1.6 Architecture data flow with a PADS probe OSSIM data flow with a PADS 8 probe is illustrated by 1.5 figure What s PADS? PADS will identifie hosts (IP and MAC address) and their running services by sniffing the network. It will provide a passive way to find running services on an host without using an active scanner (as nmap 9 ). PADS will display operating systems and running services of hosts in OSSIM framework Data flow explanations PADS software will only report all collected informations in the /var/log/ossim/pads.csv log file (configured in OSSIM PADS plugin config file: /etc/ossim/agent/plugins/pad.xml).ossim agent will then collect these informations and send them to OSSIM server. 8 Passive Asset Detection System 9 Tool also available by OSSIM framework 7

9 Figure 1.5: Data flow between a PADS probe and OSSIM server 1.7 Architecture data flow with a Syslog probe OSSIM data flow with an HIDS 10 Syslog is illustrated by 1.6 figure What s an HIDS probe These probes are used to find specific patterns in log files. As soon as the analysis software find a pattern specified in the unallowed pattern database (black list), it will create an alert and send it to OSSIM server. Like this, it will be possible to bring specific log events (dangerous one) to the monitoring console. Then with the plugin sid, it will be possible to use those events into correlation directive on the server Data flow explanations The parser software (which look for patterns in Sylog file) is natively present in OSSIM s agents. Its code and rules are in the same Python file (/usr/share/ossim-agent/pyossim/parsersyslog.py). This software will analyse Syslog file in real time and send OSSIM alerts to OSSIM server when patterns are detected. 10 Host Intrusion Detection System 8

10 Figure 1.6: Data flow between an HIDS Syslog probe and OSSIM server 9