Documentation

Architecture

This section is intended for those new to Network Security Monitoring to provide a little background so you can understand where to go next and how best to use the tools.

2. Table of Contents
   1. Network Security Monitoring
      1. Data Collection
      2. Analysis
      3. Escalation
      4. Response
   2. Network Layout
   3. Software Arcitecture
      1. Server
      2. Sensor
      3. Console
      4. Logical Connectivity
      5. Firewall

a. NETWORK SECURITY MONITORING

To help get the most out of Knoppix-NSM it is necessary to discuss a few basic concepts. If you are looking for more insight than what is provided here then take a look at the faq Q1.

Network Security Monitoring is all about awareness of what is happening on the network and being able to respond. The process of NSM can be described in the following way:

1. Data Collection,
2. Analysis,
3. Escalation, and
4. Response.

i. Data Collection

There are a number of tools provided in Knoppix-NSM that collect data for us. Before we discuss the tools, see software architecture, lets first look at what type of data it is that we need to effectively perform subsequent phases. There are four types of data of interest:

• Alert or Event data,
• Full Content data,
• Statistical data, and
• Session data.

Alert Data

Alert data is generated by a system/application that has been told to watch for a predefined set of conditions, eg: NOOP sled typically used in buffer overflows. When an alert has been generated the packet in question is flagged and sent to the analyst for them to begin the analysis phase.

Full Content Data

Full content data is about capturing every packet that passes in front of our sensor and is used by the analyst to view what was going on between the two hosts of interest.

With full content the analyst is able to put an alert into context, determine its validity and understand what data may have been exfultrated, or what system has been compromised and how. Full content data allows the response to be tailored to achieve the best outcome.

Statistical Data

Statistical data is useful to the analyst as it can help to determine normal network patterns and activities. When things deviate from these patterns it may be a sign that something is a going on the shouldnt be. Statistical data is also useful to the analyst as it contributes to the big picture and helps the analyst put alerts into context.

Session Data

The last piece to the puzzle is session data, unlike full content data, session data is only interested in the packet header information, the TCP/IP Quadrupple (SRC IP|DST IP|SRC Port|DST Port) and timestamps. Session data is also very important to the analyst as it helps determine what a particular host might have been doing leading up to and after an alert was triggered. Timestamp informaion is also useful for dertiming timelines, extremely useful if performing network forensics, and correlating other system logs to IDS logs.

ii. Analysis

Analysis if the pulling together of all the information collected and using it to understand what has occured. One of the important aspects of analysis is the timely collection and presentation of information, the tools used for this are described later in this section.

iii. Escalation

Escalation is the process of identifying a real alert and elevating it to a senior analyst for action.

iv. Response

Response is all about action, what do we do once we have determined an incident has occured and is focussed on containment, mitigation and restoring things to normal.

b. NETWORK ARCHITECTURE

Below is a simple diagram of the Network Security Monitoring Architecture that you could use to secure a small sized network. In this diagram the sensors could be monitoring the network segment through passive isolation taps, aggregration taps or port span on the switch. How your sensors are deployed depends on existing network infrastructure, network bandwidth, budget and resources.

The simplest method is an all-in-one server/sensor/console sitting on a hub monitoring the link between your home net and your dsl modem. From here you would see everything entering and leaving your home network. Conversely, the same approach could be used to monitor you own dmz server.

b. SOFTWARE ARCHITECTURE

Knoppix-NSM provides a number of tools that all contribute to the NSM framework, in this section we will highlight the role of each tool and how it fits into the bigger picture.

i. Server

The Server is were all the action occurs, it retrieves data from the sensor, stores it in the database and sends real time alerts to the analyst console. The servers job is not done there, it also sits between the console and sensor to retrieve stream data from full content packet captures

The following tools make up the server, listed in the recommeded start order (names relative to /etc/init.d/ path):

Tool	Service ProvidedOutput
1. apache2	Web server	- data retrieval from the MySQL server for BASE
2. mysql	sguil data storage BASE data storage	- data feed to sguil server and console - data feed to BASE web console
3. sguild	Real Time alert Interface to MySQL database	- output to mysql sguil db - real time alerts to console
ntpd (auto)	Time synchronisation	- time for sensor and consoles

ii. Sensor

The sensor is responsible for collecting the data and passing it to the server for real time alerting and post analysis, with the exception of full content data. The full content data is stored on the sensor and streams are retrieved when called by the analyst console.

The following tools make up the sensor, listed in the recommended startup order (All tool names are with reference to /etc/init.d/ path):

Tool	Data CollectedOutput
1. snortu	Alert Data Session Data (stream4 preprocessor)	- unified output for barnyard processing - database output directly to Mysql BASE db - session logs
2. snortl	Full content data	- binary output to log file for later lookup
3. sancpd	Session data	- session logs
4. sguil-sensor-agent	nil	- parses all log files (except ntop) to the sguil server, also provides access to packet captures
5. barnyard	nil	- parses snort alert logs to sguil_sensor_agent
6. ntop	Statistical data	- volatile statistical data, accessed through web browser

iii. Console

The console is where the analyst will spend all of their time analysing alerts. This may mean anything from pulling down data from the statistical logs, alerts logs and full content data so they can report on what is happening.

The following tools make up the console:

Tool	Purpose
sguil console	Analyst console, interface to alert data, session data and full content data
BASE console	Analyst console (web browser), interface to the BASE DB for access to alert data, also provides statistical data on alerts
Ethereal	2nd interface for viewing full content data, activated by sguil console
Web browser (ntop)	Interface to statistical data from ntop

iv. Logical Connectivity

The diagram below summarises everything that has been discussed highlighting how all the tools plug together to provide the NSM framework, hopefully it makes sense.

v. Firewall

By default the firewall is configured to only allow connections for the servies offered by Knoppix-NSM on the management network. If you are planning to impliment Knoppix-NSM on you production network then you may want to customise/lock down things a little tighter, or allow more services.

The firewall script, /etc/init.d/rc.firewall, is dynamic and will configure the firewall based on the system type that defined in /etc/systemtype. The policies are defined in /etc/default/firewall/{system_type}.

Copyright © www.securixlive.com 2005-2008