Correlation of Heterogenous IDS Alerts for Attack Detection By Nathan Carey Bachelor of Computer Systems Engineering (UQ) - 2000 Thesis submitted in accordance with the regulations for the degree of Master of Information Technology (Research) Information Security Research Centre Faculty of Information Technology Queensland University of Technology March 2004
255
Embed
Correlation of Heterogenous IDS Alerts for Attack Detection · Intrusion Detection, Correlation, Alert Analysis, Attack Signatures . Abstract With the increasing use of Intrusion
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Correlation of Heterogenous IDS Alerts for Attack Detection
By
Nathan Carey
Bachelor of Computer Systems Engineering (UQ) - 2000
Thesis submitted in accordance with the regulations for the degree of Master of Information Technology
1.1 INTRODUCTION...................................................................................... 1 1.2 WHAT ARE INTRUSION DETECTION SYSTEMS ?........................................ 2 1.2.1 DETECTION ALGORITHMS: SIGNATURE VS. ANOMALY............................. 2 1.2.2 SENSOR PLACEMENT: NIDS VS. HIDS.................................................... 3 1.2.3 PROBLEMS WITH IDS............................................................................ 4 1.3 MOTIVATION ......................................................................................... 6 1.4 FOCUS AND CONTRIBUTIONS OF THE THESIS ........................................... 7 1.5 TERMINOLOGY ...................................................................................... 9 1.6 ORGANISATION OF THE THESIS ............................................................ 12
APPENDIX A: IDMEF MODEL AND EXAMPLE MESSAGES ......................... 179 A.1 EXAMPLE SNORT MESSAGE (INDENTED FOR PRESENTATION)...................181 A.2 EXAMPLE DRAGON MESSAGE...............................................................182 APPENDIX B. DATABASE SCHEMA ............................................................ 183 APPENDIX C. FULL GRAPHS OF EACH SCENARIO...................................... 189 C.1 SEQUENTIAL SCENARIO GRAPH WALKTHROUGH....................................191 C.2 SEQUENTIAL WITH BACKGROUND TRAFFIC SCENARIO GRAPH WALKTHROUGH ........................................................................................193 C.3 SIMULTANEOUS SCENARIO GRAPH WALKTHROUGH ...............................195
iv
C.4 SIMULTANEOUS WITH BACKGROUND TRAFFIC SCENARIO GRAPH WALKTHROUGH ........................................................................................197 C.5 BACKGROUND TRAFFIC GRAPH WALKTHROUGH ....................................199 APPENDIX D. SIGNATURES AND EXPERIMENTAL RESULTS ........................ 201 D.1 SIGNATURE FILE..................................................................................201 D.2 SEQUENTIAL RESULTS..........................................................................202 D.3 SEQUENTIAL WITH BACKGROUND TRAFFIC RESULTS..............................207 D.4 SIMULTANEOUS RESULTS.....................................................................211 D.5 SIMULTANEOUS WITH BACKGROUND TRAFFIC RESULTS.........................216 APPENDIX E. RESULTS OF CLUSTER ANALYSIS ......................................... 223 E.1 SEQUENTIAL SCENARIO CLUSTERS........................................................223 E.2 SEQUENTIAL WITH BACKGROUND TRAFFIC SCENARIO CLUSTERS ............227 E.3 SIMULTANEOUS SCENARIO CLUSTERS....................................................230 E.4 SIMULTANEOUS WITH BACKGROUND TRAFFIC SCENARIO CLUSTERS........233
v
List Of Figures
Figure Page Figure 2.1 Target Element Details_______________________________________ 17 Figure 2.2: ADeLe detection part _______________________________________ 21 Figure 2.3: CRIM Flow Diagram _______________________________________ 29 Figure 2.4: CRIM results on ‘Cuppens attack’______________________________ 31 Figure 3.1 : Data Analysis Flowchart ____________________________________ 43 Figure 3.2: Threat Management System model [42] __________________________ 44 Figure 3.3: Generic Alert Analysis Model _________________________________ 48 Figure 3.4: High-level Design__________________________________________ 49 Figure 3.5: Signature Depictions________________________________________ 55 Figure 3.6: Cuppens Attack Signature ____________________________________ 59 Figure 4.1: Basic Architecture__________________________________________ 75 Figure 4.2: The two cases of Alert Agent operation __________________________ 76 Figure 4.3: Control Unit Diagram_______________________________________ 77 Figure 4.4: Administration Console Diagram_______________________________ 79 Figure 4.5: Graphing Screenshot showing tooltips___________________________ 99 Figure 4.6: Summary Window_________________________________________ 100 Figure 4.7: Analysis Console Screenshot _________________________________ 103 Figure 5.1:Test Network Diagram______________________________________ 109 Figure 5.2: TCP Scan Signature _______________________________________ 119 Figure 5.3: Exploit Attack Signatures____________________________________ 121 Figure 5.4: Cuppens Signature ________________________________________ 124 Figure 5.5: DoS Signature____________________________________________ 126 Figure 5.6: Example of DoS Summary (clicking on graph icon) ________________ 155 Figure 6.1: Proposed New Test Network _________________________________ 163 Figure A.1: IDMEF Model Diagram (incomplete) __________________________ 180 Figure C.1: Sequential Scenario _______________________________________ 190 Figure C.2: Sequential with Background Traffic Scenario ____________________ 192 Figure C.3: Simultaneous Scenario _____________________________________ 194 Figure C.4: Simultaneous with Background Traffic Scenario __________________ 196 Figure C.5: Background Traffic________________________________________ 198
In Figure 2.1 we note that just after the element name is described, sub-
elements that are linked to this element are listed. This includes Node, User,
Process, Service and FileList elements. Each one of these are optional with no
occurrence specifications as noted by the ‘?’ after each. After this comes the
attribute definitions of ident, decoy and interface, each of which shows the data
type (in this case, a data type CDATA [character-based data] or a special data
type which can either be yes or no), and the default value if not applied.
The IDMEF Data Type Definition (DTD) is currently in version 1.0, and
caters to a broad range of applications in an extensible and easy to use
manner. The impact of IDMEF messages on our prototype is discussed in
18
Section 3.4. Examples of the IDMEF messages corresponding to the IDMEF
DTD can be found in Appendix A, and are the results of Snort and Dragon
conversion of native alert information to the IDMEF.
The IDMEF DTD model is relatively simple. A diagram of the model is
shown as Figure A.1 in Appendix A. The DTD itself can be found at the
IETF web site [15]. The entire document is 120 pages, therefore not
reproduced here.
The use of a DTD allows each IDMEF message to be easily validated against
the data type and format and makes the coexistence of multiple different
versions of an IDMEF message possible by retaining and validating against an
appropriate DTD. The use of XML and a DTD also allows for easier parsing
and handling of messages than some other formats for encoding information
such as ASN.1.
A protocol for communication called the Intrusion Alert Protocol (IAP) was
proposed at the inception of the IDWG. However, IAP never received
widespread support and no full implementations were developed. In 2001, a
replacement for IAP was proposed, the Intrusion Detection eXchange
Protocol (IDXP).
IDXP was created by students at Harvey Mudd college to encapsulate the
then HTML-based IAP protocol for IDMEF. IDXP uses BEEP (sometimes
known as BXXP) for communication, which is a system for creating
protocols for message handling out of XML schemas. The advantage of this
approach was the re-use of protocol code from the BEEP effort, and a
similar approach to IDMEF in that the entire system was built on XML.
BEEP itself has already been used in multiple protocol efforts which can be
found on its web site [16]. BEEP is extensible, standardised and multiple
implementations of BEEP in different programming languages have already
been developed - mostly due to the ease of implementation.
19
The end result is that the use of XML in the IDWG efforts has allowed for
extensible, easily manipulated messages to be used in the encoding and
transfer of IDS alert messages.
After methods to allow interoperability have been developed, heterogeneous
IDS can be used to advantage in a centralised system performing alert
analysis. As postulated by Goldman [17] a centralised system can also be of
benefit in providing more situational awareness to the user. A monitoring
system with access to many IDS can reduce error rates by relying on IDS
overlapping nature and relying on individual IDS to produce an error
independently of others. With an increased situational awareness, responses such
as firewall blocking or connection dropping can be used with greater
assurance. As such IDS can benefit from the division of labour of the actual
IDS sensor mechanisms from the work of storage and analysis of alerts, and
providing interfaces and messages to users.
The first step in actually analysing IDS alerts is to collect and store this
information from disparate sources. While IDMEF works for supported IDS,
it is not clear how this information is to be collected for other sources that
can be considered relevant, such as system audit logs and traffic analysis.
Erbacher [9] provides details of shell scripts used in the Hummer IDS to
extract security-related information from log files. The information is
gathered from the internal Unix logging subsystem using a simple shell script.
Included in Erbacher’s work is information on how to develop statistics for
such as file access and usage from the NFS process. Further work is required
on how to properly integrate information for multiple different types of
security devices.
2.2 Attack Specification Languages
There have been notable contributions to the development of languages for
describing attacks, intrusions and security incidents in the past decade, with
20
advances in specification, breadth of coverage, syntax and readability. Some
significant examples of the recent work in this field have been included below.
ADeLe’s goal is to combine all the knowledge available for a given attack in a
single readable high-level description [18]. ADeLe was developed within a
French project named Mirador, which also sponsored the work on the
LAMBDA attack specification language by Cuppens and Ortalo [19]. Both
languages while developed independently and simultaneously, share many of
the same concepts. Both contain pre- and post-conditions for the linking of
objects within the language. LAMBDA has an extremely expressive syntax,
and a methodology to represent states and state transitions in the progress of
an attack. LAMBDA is described in relation to Cuppens work in correlation
in Section 2.4.1 below, so only ADeLe is described here.
ADeLe contains three parts: an exploit part, a detection part and a response
part. The part of interest to us in the context of this work, the detection part
(shown in Figure 2.2), contains three sections, called detect, confirm and report.
The detect section specifies three subsections, called events, enchain and context.
The events subsection lists the events observable in the attack. It uses the
IDMEF model to represent these events. The enchain subsection describes the
temporal relationships between the events described in the events subsection.
This temporal relationship allows for the following relationships to be
expressed: sequence of events, unspecified order of events, exclusive choice
or the choice of only one event, subset or the choice of multiple events with
the set and non-occurrence or requiring the absence of an event. ADeLe also
allows for the specification of time constraints between the events if required.
All of these can be combined into a large expression determining the
interrelationships of the events in the attack. The last subsection is the context
subsection, which allows for contextual operations to be performed on
elements within the events in order to test for items such as increasing port
numbers or locating substrings in a field.
21
The last two sections, confirm and report, allow for the specification of what
actions can be performed in order to confirm that the attack has succeeded
and the information to be included in the alert generated when an attack has
been detected. The finished product is very similar in functionality to our own
work, though the development process was different. ADeLe’s detection part,
when combined with the exploit and response parts, provides for an
important example of how to organise the information potentially associated
with an attack. Unfortunately, no new recent work has been published on the
use of ADeLe, perhaps due to the increasing use of the more specific
LAMBDA language in the Mirador project. An example of the detection part
in ADeLe is in Figure 2.2.
Figure 2.2: ADeLe detection part [18]
Sutekh [20] is another language which describes events using a logical set of
preconditions and constraints. According to Pouzol, ‘Sutekh provides
sequence, alternative partial order, negation, event correlation by logical
22
variables, condition verification and alert triggering.’ These functionalities are
defined using logic and declarative semantics that describe the temporal
relationships between events. Sutekh creates signatures using single-alert
building blocks called filters. Each filter consists of a set of constraints on a
field with an incoming event. If all the constraints are satisfied then the event
is matched to the filter. Filters are combined to form signatures using
combinations of the then, or, and, and if_not operators. Filters combined in
this way allow for sequences (then), choice (or), interleaving (and) and
negation (if_not). The final result of these logical operations can be displayed
using graph representations called SigGraphs. Pouzol also provides a way to
use Sutekh to specify a signature in P-Best. This work represents another
system close to our own work, but is unsuitable for our particular application
as it does not use IDMEF for communication and gives little detail on
implementation of the system, preventing external use.
STATL [21] is an extensible state-transition based attack description language
designed to support intrusion detection. The language allows one to describe
computer penetrations as sequences of actions that an attacker performs to
compromise a computer system. The STATL language can be extended to
express the characteristics of a particular domain and/or environment. The
extension process includes the definition of the set of events that are specific to
the particular domain or environment being addressed and the definition of
new predicates on those events.
The STATL language represents attacks as combinations of states and
transitions. States are used to define snapshots of a given system during an
attack. These states utilise only those items that are necessary for the attack
itself, such as login attempts or TCP connections. Transitions between states
have actions associated with them such as the execution of a program, a user
logging in, or a new TCP connection. The actions that affect state are
constrained by assertions, which are essentially filters on actions appropriate
23
to the change in state of the current scenario. For example, an assertion may
require that a TCP connection is opened with a specific destination port or
that an application being executed should be part of a predefined set of
security-critical applications. STATL provides mechanisms for the timing of
scenario events, as well as the insertion of code blocks into the language, in
order to extend its capabilities. STATL has performed well in a wide variety
of applications, including HIDS and NIDS domains, and was used in the
1998 DARPA IDS [22] evaluations. STATL has been used to translate IDS
rules directly into STATL scenarios [21]. STATL was not used in the research
for this thesis primarily due to the focus of the thesis on commodity IDS,
which are not supported under STATL.
Trend Templates Language (TTL), developed by Doyle et al. [24], is a
language that goes beyond signature and anomaly techniques to ‘recognize
patterns more abstract than signatures but more specific to particular events
of interest than anomaly’. TTL uses three different expressions for temporal
relationships, landmark times, temporal intervals and temporal relations. Landmark
times represent times of important events that can only be specified in relation
to other events, and temporal relations specify the same sort of relation, but
are specific to the important timing relations that can characterise sub-events
within a trend template. Temporal relations are used to specify short-hand
expressions to detail intervals that are possible, but lengthy, to express in the
(min, max) relations used by landmark times and temporal intervals. MAITA [25]
extends this base concept by augmenting range expressions to represent
probability distributions and shapes of curves in order to specify more
complex relationships to make the recognition process more accurate and
evasion more difficult. MAITA also uses graph-based displays to show the
progress of processes in its monitoring console. MAITA unfortunately lacked
the focus required in our work on a simple system for specifying signatures
and analysis of commodity systems.
24
MuSigs [26] or Misuse Signatures, is a language designed to express abstract
relationships normally found in misuse detection environments. The concept
is similar to that of STAT scenarios, but used to represent complex intrusions.
In order to facilitate this, a monitor must be used that allows for the concept
of abstract views over audit trails. These abstract views are simply a level of
abstraction above the specific information normally contained in an audit
trail. Examples of these are read/write to file objects, number of failed logins
and abnormal login times. MuSigs represent these abstract events using
acyclic graphs, which are translated into auditing processes using configurable
instructions called system directives. MuSigs are specified using logical semantics
such as in the statement
command= “login” ^ status = “false” ^ num_of_tries = 3 ^ x1 = user
which represents the concept of a user failing to login more than three times.
This method of abstracting the signature process and allowing for user-
configurable directives to enable customisation of the analysis process allows
for the ability to represent and analyse complex intrusions through the use of
combinational logic. It is difficult to specify how these concepts relate directly
to IDS alerts however, and so in this thesis it was decided to use a simple
signature system of patterns of alerts rather than use the combinational logic
of events provided by MuSigs.
While the above systems provide comprehensive solutions to describing
events which can be ascribed to intrusion or misuse, it was identified that a
niche existed for a simple signature system comprising patterns of alerts rather
than events. This meant that the problems of defining and expressing events
themselves could be avoided, and work concentrated on combining alerts
from heterogenous IDS in order to boost detection rates and analysis
effectiveness.
25
2.3 Correlation and Alert Pattern Analysis
Correlation has been an important and typically broad area used in many
different fields of research, leading to a variety of definitions based on the
context of the particular work in which it is defined. Due to these conflicting
definitions, alert correlation is not defined here, discussion on correlation is
defined in this work its impact is left until Chapter 3. A brief description of
the general role of correlation is included below however.
Correlation of alerts generally occurs either in terms of machine-learning
approaches or pattern detection algorithms. Systems using pattern detection
use algorithms to test a given alert stream against some form of pattern,
normally either a simple pattern such as a set, or more complex patterns
specified by systems such as LAMBDA and ADeLe. Machine learning
approaches such as CEP [27] use various algorithms appling fuzzy logic to the
alert stream in order to discover patterns. The end result is the identification
of alerts from the alert stream which together can indicate a multi-step or
complex intrusion.
By allowing the discovery of these sets of alerts, correlation provides us with
the potential ability to see beyond the actual alerts themselves, and determine
trends, find patterns and infer relationships between alerts - capabilities which
a single sensor is unlikely to have. To be effective, correlation is best
performed with multiple, preferably heterogeneous IDS in order to provide a
level of mutually reinforcing independent alert sources.
A related aspect of alert pattern analysis for IDS is the ability to perform alert
reduction to combat alert storms, analogous to event storms produced by
Network Management Systems (NMS) [28]. NMS alleviate this problem with
correlation and aggregation of data, which can also be used in the IDS
domain. Correlation and aggregation is most effective on a centralised server
where all the alerts possible can be used for correlation, and where
aggregation can be performed on the greatest number of alerts possible. Also,
26
the problem of discovering the root cause of a fault is similar to determining
the details of an intrusion, therefore many concepts translate well to the IDS
domain. Much work has been done in this area, including applying Bayesian
network graphs [29], codebook methods [30] and machine learning
techniques [31].
Perrochon et al. [27] have developed an extensive infrastructure for the
specification of methods of event correlation applicable in many different
fields, with IDS a recent extension of this architecture. Their approach, called
Complex Event Processing (CEP), uses what is termed context based correlation
or the correlation of alerts based on their causal and temporal relation to one
another. The language for the representation of these relationships is
primarily focused on defining the relationships between events. Instances of
such relationships are termed patterns. An active pattern in the CEP
architecture is termed a pattern macro and pattern macros are combined with
filters, which allow only the alerts matching the pattern to be passed. These
filters then produce events which are given to maps, which are comprised of
rules. Rules are comprised of a trigger (the pattern used to activate the rule)
and a statement, or a pattern used to express the events which are produced
when the trigger is matched. Maps can maintain state if required. CEP has
recently been used to analyse CIDF data [27] in addition to its use in the
extensive range of applications already demonstrating working prototypes.
Ning, Cui and Reeves [32] use correlation and aim to facilitate the analysis of
large sets of correlated alerts. They perform this correlation by using
prerequisites and consequences of alerts. Attempts are made to match the
consequences of earlier alerts to the prerequisites of later ones. Note that
specifying this relationship differs from related causal correlation work by the
correlation of many more features of alerts, and the usage of graphing
functionality to represent these relationships. The relationships are encoded
using hyper-alerts and hyper-alert graphs. Hyper-alerts are a tuple in the format of
27
(fact, prerequisite, consequence). Hyper-alert graphs are graphs depicting the
causal relationships between these entities. These graphs can become
complex, though this complexity can be managed by the user using graph
reduction algorithms and user interfaces providing drill-down facilities in the
form of focused analysis and graph decomposition. The final result aids the
analysis capabilities of the administrator by providing for the representation
of complex relationships in an easy to comprehend manner. It also has the
ability to easily create hyper-alerts from actual IDS signature data, which in
this case was the RealSecure 6.0 NIDS. Our work differs from this in both
the method of representation of alerts, and the addition of a signature scheme
to automate analysis. We also do not attempt to perform the same level of
assisted manual correlation performed user hyper-alert graphs.
Tidwell et al. specify a model on top of an analysis system extending the
attack tree concept [33]. This model uses preconditions and antecedents in a
hierarchy to specify the process of actions which correspond to an intrusion.
Their analysis system also includes a component designed to specify network
configuration in order to allow it to be used in the detection of attacks, such
as ignoring Windows-based attacks on a Unix host.
Recent work by Morin et al. [8] has provided a comprehensive formal model
of IDS and IDS event correlation. It achieves this by modelling a formal
specification of the relationships between security components and specifying
ways in which this relates to intrusion detection in a model named M2D2.
They argue that alert correlation should take into account:
• characteristics – the characteristics of the network or system on which
the correlator resides,
• vulnerabilities – the database of current vulnerabilities in the system,
• security tools – vulnerability scanners, IDS, firewalls, and
28
• system events – events occurring on the system such as from hosts or
security tools, although these events have different semantics to the
alerts or scans generated from security tools.
In M2D2 the goal is to reduce the number of alerts, reduce the percentage of
false positives in alerts, improve the diagnosis of alerts, and reduce the
number of false negatives in alerts. M2D2 aims to provide all these services
using correlation between the IDS themselves, as well as the underlying
environment, as detailed in the first three bullet points above. M2D2 uses a
relational database to store information from multiple parts of the model. The
schema for the entire model is shown in Appendix B. M2D2 specifies the
levels and interrelationships between functions such as aggregation,
correlation and alert reduction.
M2D2 is expressive enough to handle many concepts in correlation, though
in recent work [8] three examples were discussed, namely:
1. alert aggregation,
2. identification of vulnerable hosts to an attack, and
3. detecting false positives.
The first of these uses alert characteristics, such as aggregating all NIDS alerts
to a specific IP with HIDS alerts of the host with that IP. The second uses
the mapping of vulnerability scans to the attacks being attempted on a
machine by eliminating alerts which do not correspond to vulnerabilities of
the target system. The third reduces false positives, correlating alerts from
multiple IDS which should all trigger an alert from the same event, and
filtering out those alerts that are not corroborated.
As our work focuses solely on the alerts from IDS, not underlying events,
much of the M2D2 model is outside the scope of our research. The formal
29
models of M2D2 combined with the semantics described in work such as
Cuppens [11] means that complete formal systems for correlation are
available for application in the field.
2.4 Research Implementations of Correlation Systems
This section describes full implementations of correlation systems in recent
research. The research given here was used as a benchmark in the evaluation
of the practicality, effectiveness and scope of the end product of this thesis.
2.4.1 Cuppens and Miege
Cuppens et al. have published a number of papers on correlation of IDS
alerts [11, 13, 34, 35]. Cuppens uses IDMEF for an alert representation
format and a centralised database, much the same as this thesis. This work is
generated from the Mirador project, which aims to produce a ‘cooperative
and adaptive intrusion detection platform’. The architecture presented is
known as CRIM.
Figure 2.3: CRIM Flow Diagram
CRIM, shown in Figure 2.3, performs three functions: alert clustering, alert
merging and alert correlation. It aims to reduce the number of alerts
Clustering
Alert Merging
Correlation
Intentionrecognition
Réaction
Alerts Alert clusters
Candidate intrusion plans
Global alerts
Global vision
Alert base management
IDS IDS IDS
30
transmitted to the security administrator. CRIM converts IDMEF messages
into sets of tuples which are then stored in a Prolog database. The insertion
into the Prolog database generates unique ID’s for each element in a
particular alert feature such as source IP. This means that initially when the
database is empty or small, a large number of unique tuples may need to be
stored, but the number of new tuples to be created decreases as the database
size increases.
Cuppens uses the term cluster to refer to a set of alerts that correspond to the
same occurrence of an attack. Clustering functions are applied directly on the
database. The clustering function attempts to recognise the alerts that
correspond to the same occurrence of an attack. These clusters are generated
using similarity functions generated by expert system rules. This requires the
specification of similarity rules for each clustering relationship, such as the
similarity between two alert types. Cuppens specifies four different clustering
types: classification (alert name), time, source and target.
After a cluster has been generated, merging functions generate a single alert
representative of the alerts present in the cluster. One interesting point to
note is that merging is applied after clustering, in order to reduce the
information contained in the alert generated. Cuppens uses these merging
functions on set criteria, such as time, source, target and classification.
After performing clustering and merging, CRIM performs correlation by
mapping alerts to LAMBDA scenarios. These consist of:
• Attack Preconditions : The conditions required for the attack to
succeed.
• Attack Post-conditions: The effects of the attack if it succeeds.
• Attack Scenario: The events that are performed during the attack.
31
• Detection Scenario: The events needed to detect the attack.
• Verifications Scenario: The events needed to check if the attack has
succeeded.
Note that these items are similar to the specification in ADeLe above. A full
description of LAMBDA can be found in Cuppens and Ortalo [19], although
for functional purposes, the details of ADeLe can suffice. The LAMBDA
language can express complex situations easily and is used for the
specification of multi-step signatures. A particular example used in Cuppens
work is the same attack as one used in our experiments in Chapter 5 called
‘Cuppens attack’. The attack involves determining if the user root exists on
the target machine, mounting the root NFS drive and culminates in the
attacker achieving root access on the target machine. Figure 2.4 shows the
table of results generated by CRIM by Cuppens using the IDS Snort and
eTrust. This attack was selected in our work both to attempt to replicate the
results of Cuppens, and to take advantage of the fact that this series of events
produces alerts from multiple IDS, which enables us to test the
heterogeneous alert correlation of our system.
Figure 2.4: CRIM results on ‘Cuppens attack’
32
Cuppens has recently extended the range of abilities of the system by
incorporating plan recognition into the system [11, 35]. Plan recognition and
the correlation of alerts to attack plans in the level described in Cuppen’s
work are at levels beyond that proposed in this thesis, and closer to the model
provided by M2D2 than our work. However the eventual incorporation of
plan recognition into our model is discussed in Chapter 6.
2.4.2 Debar and Wespi
Debar and Wespi have performed work in the aggregation and correlation of
IDS alerts, with the following goals [36]:
1. To avoid the ability of an attacker to perform flooding attacks against
an operator.
2. To allow a user-configurable context to be defined for groups of
alerts.
3. To reduce false positives.
4. To achieve better scalability in IDS deployments.
In this case, alerts are grouped by an ACC (Alert Correlation Component)
which uses correlation (duplicate and consequences) and aggregation (based
on grouping on criteria) relationships to define the situations a system may be
experiencing. IDS sensors themselves are termed probes. In the development
prototype implemented in Tivoli Enterprise Console, the probes used are ISS
RealSecure, Cisco SecureIDS, a proprietary IDS named WebIDS, TCP
Wrapper and a tool named Klaxon. These probes consist of a vast range of
commodity and target-specific IDS and, therefore, represent a good cross-
section of potential probes for such a system.
Some requirements to be met by the ACC include:
33
• Semantics – the ACC should present one alert per attack, even if the
probes have generated multiple alerts for this attack.
• The ACC should be scalable – ACCs can be implemented in a
hierarchy.
• Reactivity – the ACC should allow better management of an intrusion
by automatically retrieving more information if required and
escalating situations if necessary. It should also be able to potentially
modify the setup of a probe and even applying appropriate
countermeasures if deemed appropriate. This set of features is
currently a work-in-progress.
• Proactivity – the ACC should expect certain events such as
vulnerability scans and trigger alerts if these events do not occur.
• Integration – the ACC should be able to be integrated easily into
existing management frameworks to ease the administrative burdens
of IDS monitoring.
• Configurability – the ACC should enable easy reconfiguration of
parameters such as severity, confidence or known intent of hosts
(such as bad or good). This is currently accomplished using
configuration files.
• Performance – the ACC should be capable of handling large numbers
of alerts. NMS normally handle hundreds of alerts per second. The
current prototype ACC was developed with the target of one alert per
second.
The system architecture uses a set of pre-adapters which translate native alerts
into a format compatible with the ACC. These pre-adapters are only needed
34
when the native alert cannot be interpreted by the ACC. The data model
representing alerts is fundamentally similar to the IDMEF data model, but is
implemented differently, using a hierarchical class model instead of XML.
The ACC uses two relationships in the algorithm used to process alerts from
probes. These are correlation relationships and aggregation relationships.
Aggregation relationships group alerts in order to determine a combined
severity level, while correlation relationships link alerts using either explicit
rules programmed into the ACC or configuration information such as
described above. Alerts are pre-processed in order to extract common
information such as probe, source and target, as well as the timestamp of the
alert. The system requires that all probes be synchronised in order to provide
equivalent timestamps.
In the correlation algorithm, a duplicate alert is an alert generated by a cause
already indicated by a previous alert. This entails looking at previous alerts.
The handling of these duplicate alerts depends on the severity of each alert. If
the severity is zero, the duplicate alert is ignored. If the severity is non-zero,
depending on the number of occurrences of the alert and the severity level, a
new alert of higher severity may be generated. The specifications of this may
be configured by the user. This technique is most often used in situations of
floods, where the number of alerts must reach a certain threshold before an
alert is triggered. Alerts can also generate consequences, or a sequence of
potential alerts and the conditions of the linkages between them.
The ACC can detect series of alerts using a situation, or defined groupings of
alerts based on the alert type, source, target or severity. These items can be
specified as a specific token or a wildcard. This concept can be used to detect
series of a lerts on a single host such as port-scans.
This concept of the ACC and implementation of a central data-store and a
centralised administrative console which performs correlation functions is
35
close to our own approach, and also tries to ease the administrative burden by
positioning the ACC within the existing Tivoli management system. This
allows for both easier management within a network management
infrastructure, and a simpler interface for those familiar with Tivoli.
Unfortunately, the expense and infrastructure is outside the realm of many
networks. We aim to produce a system using commodity IDS, with as few
infrastructure requirements as possible, so as to ease eventual
implementations of our system. At this time, our system does not perform
aggregation in any meaningful way, as the focus at this stage is in correlation
and analysis.
2.4.3 Valdes and Skinner
There have been many papers on the Emerald architecture. Recently those by
Valdes and Skinner [37, 38, 39] have dealt with the implementation of
correlation in the Emera ld system, including methods to correlate Emerald
information with Snort, ISS RealSecure and Checkpoint Firewall-1. The
Emerald correlation functionality uses probabilistic methods applied through
Bayesian networks. IDMEF with Emerald extensions is used as a
communication format and, as with virtually all the current implementations
of correlation systems, a centralised database. Alerts can be combined into
meta-alerts if they are part of the same thread or single execution of a suspected
attack. Threads are either generated by EMERALD sensors that understand
the concept of threads or enforced by maintaining a high level of similarity
(see description below) on the alert features from the sensor. The meta-alert
contains extra information such as more information than IDMEF on sensor
placement and description, an anomaly field, priority and the usage of arrays
for information within the normal IDMEF structure.
Due to the use of Bayesian models, the correlation focuses on feature
similarity. The process begins by identifying the similarity in content, then
each overlap in content is assigned a similarity number in the range between
36
zero and one, with one as a perfect match. The level of similarity is related to
the alert feature that is being compared; for example the similarity between
two DNS names must be calculated differently than for two target ports.
When comparing the actual attack name, the preference is to compare attack
classes or large general classifications of signatures, rather than comparing
individual signatures themselves. The expression for overall similarity is:
∑∑
=j j
j jjj
E
YXSIMEYXSIM
),(),(
where X = candidate for matching, Y is the new alert, j is an index over the
alert features, E j is the expectation of similarity for feature j, and Xj and Y j are
the X and Y values for feature j.
Here, the concept of a meta-alert is introduced. This alert is simply a group of
alerts deemed similar by different similarity vectors. These alerts are then
grouped and categorised according to the similarity vectors and levels. Alerts
can then be added to these, or new meta-alerts can be created.
Valdes and Skinner’s work has been tested on live data, and achieved a
reduction of one-half to one-third of the alert volume in a normal traffic
environment, and a fifty-fold reduction in a simulated attack scenario.
2.4.4 Krugel and Toth
Krugel and Toth [40] propose a distributed system for pattern analysis of IDS
alerts in order to distribute processing and allow for fault tolerant processing.
While diametri cally opposed to the concept of a centralized system such as
that found in our architecture they specify a language, ASL, which in many
respects is similar to our own signature scheme. The definitions of patterns
are specified as
ATTACK “Scenario Name” [nodes] pattern
37
where [nodes] is used for identifiers to the nodes represented in a pattern
definition. The pattern itself describes a list of event sets for each node that
appears in the node section. An example of this syntax is contained in the
following example Telnet scenario.
ATTACK “Telnet Chain” [Node1, Node2] Node1{ send (Node2): tcp_connect [DstPort == 23; ] } Node2{ tcp_connect [DstPort == 23;] } In this case, Node1 sends its event to Node2 in a format called a message,
which describes the root event or root of the scenario event tree. In order to
add additional constraints on the information, additional criteria can be
specified, termed node constraints. These node constraints consist of the
temporal constraints on the items in the set, and any dynamic constraints that
can be resolved at this node. Dynamic constraints are based on logical
operators for attributes contained within the pattern, such as comparisons on
the destination port, as contained in the scenario above.
Kruger and Toth also use two separate data repositories for patterns which
have yet to be matched. The message pool holds message instances which can
satisfy local node constraints, while the bypass pool holds messages that are
useful in the node constraints of those nodes close to the root of the pattern
graph. These pools allow for prioritizing of message handling and the routing
of messages between nodes in a pattern graph.
The end result of Kruger and Toths’ work is a scalable infrastructure for
pattern analysis over distributed networks which has been tested on data
gathered for nodes using Tcpdump and Snort.
38
2.5 Commercial Products
Commercial products such as netForensics, Intellitactics NSM and ‘Private I’
provide management frameworks for security devices. They all take data from
heterogenous IDS as well as some other security devices such as firewalls and
perform correlation. The algorithms and outcomes of the correlation process
in each case are, however, unclear. NetForensics provides an infrastructure
very similar to the one presented in this thesis in that it uses Java and XML to
build a modular framework based around a central data store. Intellitactics
and Private I also use frameworks that support a common reporting format,
logging into a database which is then accessed by a viewer. Many of these
systems also support logging of firewalls and syslog data. Due to proprietary
formats and no published research outcomes, it is difficult to design
experiments or testing methodologies for these commercial systems. It was
decided that though these products emulated the architecture of what was
desired in this thesis, there was still a basis for the construction of a similar
framework for use in a signature matching and alert analysis system using
IDMEF. Our work differs from the commercial products in that it has an
open architecture, uses commodity components and has the focus on
correlation and data analysis, especially using our simple signature system.
IDS vendors themselves such as Symantec and ISS, have begun to market
their own products for correlating information from multiple sources such as
firewalls, IDS and virus detection systems. These products, by and large, do
not have extensive documentation available to the public therefore have not
been discussed here. It is known that ISS has a product very similar to our
own work however details on this product were not fully available at the time
of writing.
39
2.6 Summary
In this chapter we have discussed recent work in the field. A number of
approaches have been proposed for event and attack languages to facilitate
correlation involving IDS alerts. These have typically been sophisticated
languages, in many cases involving specialised software and proprietary
systems. The table below summarises the important features of the related
research covered in this chapter.
Research Summary
Cuppens and Miege
CRIM • IDMEF Messages
• Specific clustering vectors
• Sophisticated Attack Specification Language
• Commodity IDS
• Multi-step attack results
Debar and Wespi
ACC
• Correlation defined by specific relationships
• Commodity IDS
• Intelligent predictive analysis
• XML-based alert format (non-IDMEF)
• Integrated with Tivoli Enterprise Console
Valdes and Skinner
Emerald • IDMEF with extensions
• Bayesian analysis of alert features
• Meta-Alerts
• Commodity IDS
Krugel and Toth • Distributed Analysis
• Prioritised Matching
• Specific attack language detailed
• Snort and TCP Dump used in testing
Table 2.1: Research Summary
40
A niche which seems to be under-represented in current research is the ability
to perform simple correlation based on the only the alerts of IDS. While not
as comprehensive as methods used to define and analyse events in general,
the use of IDS alerts requires little additional infrastructure to enable
detection of multi-step attacks across multiple IDS. The work that comes the
closest to a simple system using only IDS alerts is the research by Cuppens on
CRIM (Section 2.4.1) which uses similar techniques. In the research for this
thesis, it was determined that there was a need for a simple commodity
system with an open architecture and signature specification to help aid
analysis, and that additional techniques such as clustering and graphing could
be used to aid analysis by signatures.
The approach adopted in this work intentionally focuses on a minimalistic
approach and a simple signature format specialised for the correlation of IDS
alerts. Also demonstrated are other simple analysis tools in the form of
graphing of alerts and in simple clustering technology. The prototype
implementation is simple and practical, and involves as little added
infrastructure as possible, while still providing the functionality required for
practical alert analysis. The production of a prototype and architecture for
testing the effectiveness of the prototype has produced the contributions
detailed in Section 1.4.
The next chapter introduces the basic concepts behind this research,
including the roles of IDMEF alerts, correlation, signatures and other analysis
methods in a system for IDS alert correlation, and a high level design of the
system that was developed.
41
C h a p t e r 3
HIGH LEVEL DESIGN
In Chapter 2, we analysed the current state of intrusion detection alert
correlation and languages used to achieve this. We feel the potential for alert
correlation and analysis for attack detection using commodity or off-the-shelf
IDS to achieve adequate analysis and representation of patterns of the alerts
generated has not been realised by current research.
Cuppens [41] defines two forms of correlation, implicit and explicit correlation.
“Explicit correlation of events is used when the security administrator is able to express
some connection between events that he knows. This connection may be a logical link based
on knowledge of relations between alerts. It may be also a link depending on the topology of
information system's components.
Implicit correlation of events is used when data analysis brings out some mappings (may be
statistical ones) and relations between events. This approach is mainly based on observing
groups of alerts and extracting implicit relations between them. Many works show that
intrusion detection probes produce groups of alerts according to the configuration data, the
traffic and the topology of information system under surveillance .”
In this work, we use the definition of correlation given in Section 1.5,
however the focus is on explicit correlation for signatures, together with work
on implicit correlation with clustering and graphing used for manual analysis.
The central goals of alert analysis and attack detection in our architecture ease
the administrative burden of manually inspecting the large number of alerts
produced by IDS in the field. In order to achieve these goals, we use the three
technologies of signatures, clusters and graphing combined in a single
prototype. Signatures are used to detect static patterns and provide
deterministic analysis, while clusters can be used to produce groups of related
42
information. Graphing can be used to analyse trends in data and identify
abnormal sequences and groups of alerts by visual means. And all of these
tools should be combined in a single interface to allow an administrator to
easily relate the information provided by each.
In this chapter we build on the concepts detailed in recent work and propose
a system alert correlation using commodity systems. This is accomplished by
using signatures and alert analysis techniques together to provide a
comprehensive view of the operation of IDS within a network. We begin by
describing the challenges of alert correlation of heterogeneous IDS and a
waterfall model for alert analysis. The chapter continues by describing the
alert analysis and correlation model used in the thesis in 3.3, and details on
how IDMEF messages are used in our model in Section 3.4. This is followed
by a discussion of real-time versus off-line analysis and how decisions related
to this have shaped our design, followed by a description in Section 3.6 of the
concepts behind alert signatures used in this thesis. Section 3.7 details how
analysis using clustering and graphing is used, and Section 3.8 shows how the
analysis techniques can be combined to detect attacks. The chapter concludes
with a summary.
3.1 Challenges
As described in Chapter 1, large scale IDS deployments in most cases entail
both a large amount of data, and data from multiple sources in different
network locations, combined with the potential for alerts from heterogeneous
IDS. Currently, analysing this disparate data has been the job of specialised
human administrators; however the sheer volume of information and the
content of the information make this task difficult, if not impossible, when
thousands of alerts per day are received. Tools are available which enable a
user to analyse the alerts from homogeneous IDS. However, these tools are
often little more than graphical interfaces to flat alert log files, and so do not
provide the administrator with any more ability to perform analysis than
43
simply watching an alert log file on a terminal. Some IDS such as Dragon
allow for trending and provide graphing tools, but provide little in the way of
tools to drill-down into the information presented, and provide no method to
automate the process of analysis. Some tools allow for database storage of
alerts for IDS such as Snort and an associated ability to discover trends in
information. They provide summaries and drill down to specific alerts, but no
way to automate the process of analysis, and no way to perform analysis in
real time. These systems also generally use web-based display mechanisms
which allow for increased ability to use the interface from multiple locations,
but hamper usability due to the use of static interfaces.
A solution is needed that provides a way to allow for easy analysis of
heterogeneous IDS alerts as well as the ability to look at specific alerts and
perform automated configurable analysis tasks. An alert correlation system
needs to deal with the fact that intruders are less predictable and attempt to
subvert analysis mechanisms [32] – which means any algorithm must be
accurate as well as tolerant of modification of patterns and models of
intrusion.
3.2 Alert Analysis Waterfall Model
The abstract alert analysis model followed in this work is based on the four
step model in Figure 3.1.
Aggregation
Reduction
Correlation
Induction
Alert NumberInformation Content
Small
Large
Small
Large
Figure 3.1 : Data Analysis Flowchart
44
Data Aggregation (Stage 1) refers to grouping alerts together in order to
reduce the number of alerts logged to the database or processed in later stages
of analysis. Data Reduction (Stage 2) refers to reducing the number of alerts
by removing obvious false positives as well as duplicates. Data Reduction and
Aggregation can be considered complementary processes, and may be
implemented in multiple passes if required. The next step is Data Correlation
(Stage 3) where analysis can establish relationships between alerts. The last
step is Data Induction (Stage 4) where relationships for events not normally
apparent, or missing from the dataset, can be inferred from the data available.
This model is used for the positioning of our work in a framework containing
the core functionality required in an IDS analysis system. Figure 3.2 shows the
model proposed by Scott [42], in his Threat Management System (TMS).
Scott does not describe all the roles of each of the components in the TMS,
but the forms of aggregation, correlation and analysis are analogous to
aggregation, correlation and induction in our model.
Figure 3.2: Threat Management System model [42]
45
Stages 1, 2 and 4 in our abstract alert analysis model are not included in the
work presented here as the focus of this work was on the specification, design
and implementation of correlation components for IDS analysis. The roles of
these stages in our research are described in Sections 3.2.1 through 3.2.4
below. The inclusion of these stages into our design has been considered in
Chapter 6, as extensions to the prototype.
3.2.1 Data Aggregation
The first stage of the model aims to group alerts together using clustering
functions similar to those by Cuppens [7] and Valdes [37]. Alerts should be
grouped by time, classification, source and destination using similarity metrics
or other grouping algorithms. A point to note is that aggregation does not add
data to the dataset, but it can reduce redundancy and analysis workload by
reducing the sheer number of alerts to be processed. As such, this stage must
focus on making certain that aggregation fails safe – i.e. it does not inaccurately
group information, thereby introducing errors into the database.
3.2.2 Data Reduction
After determining which alerts can be grouped together, the purpose of this
stage is to remove redundant alerts. This could be performed by merging alert
groups based on aggregation criteria and deleting the originating alerts or
using signatures to delete alerts based on administrator requirements.
Examples of this could be low-level alerts of no interest, alerts not
appropriate for the environment, such as Microsoft IIS attacks on an Apache
web server, or duplicate alerts. Once again, the goal is to only remove the
information that is definitely not relevant. While the process of removing
alerts is simple, the logic behind the decision to remove an alert can be quite
complex. In many cases, if not performed properly, data reduction can
actually remove information important to data correlation (Section 3.2.3,
below). For this reason data reduction needs to be implemented very carefully
46
if used, and ideally should integrate with Data Aggregation to create a single,
relevant data source for data correlation.
3.2.3 Data Correlation
This stage is the main work of this thesis. With the number of alerts reduced
to a more relevant subset, we can look at which alerts may be correlated.
Correlation can be based on time, IP, location or virtually any field deemed
relevant. We discuss three methods for this correlation in terms of attack
signatures, alert clustering and alert graphing in more detail below. Note that
the first two stages are not required for the proper operation of correlation,
but they are desirable to reduce the number of alerts to be correlated. As
mentioned above, the inclusion of the first two stages and their impact on our
design is discussed in Chapter 6.
3.2.4. Data Induction
This stage generally relies on the proper operation of the previous three,
primarily the correlation stage. At this point, the goal is to extrapolate from
the data either to predict events that have occurred but not been detected, or
would be likely to occur based on the current set of alerts. Induction requires
more complex analysis than that of correlation but the same general principles
apply. The major difference is that induction is used to extrapolate or
interpolate information from the dataset, rather than simply determine
relationships. Examples of this could be predicting the next stage of an attack,
deducing missing components of an attack or determining possible spread of
an attack through the network. Cuppens incorporates many of the features of
this stage in recent papers on correlation [11, 35]. With the implementation of
the correlation stage in this work, future work will include the specification
and design of induction systems based on the results of correlated alerts.
47
3.3 Alert Analysis and Correlation Prototype Model
Our goals have been to design and implement the following, as mentioned in
Section 1.4, based on the model presented above:
1) Signature-matching scheme which is performed on IDS alerts,
2) an experimental platform to test the capabilities of points 1) and 3), and other
algorithms if needed,
3) an alert or cluster analysis capability to facilitate the analysis and correlation of
alerts from heterogeneous IDS,
4) a visualization capability to complement the other analysis methods,
5) methods to use clustering and graphing to facilitate signature discovery, and
6) a convenient user (administrator) interface to provide GUI access to points 1), 3),
4) and 5).
Interoperability is a crucial part of achieving these objectives in order to
provide a common basis for the interpretation of alerts arriving from
heterogeneous IDS and, possibly, other system security components such as
firewalls and host logs. We use IDMEF for this purpose. Given IDMEF is
the only readily available format for the exchange of IDS data and is
furthermore an accepted de facto international standard, it was the obvious
choice for any commodity inter-operability effort. The availability of an
IDMEF plugin for the Snort IDS also allowed for faster prototype
development. Interoperability allows us to exploit the use of heterogeneous
IDS to provide identification and notification of a wider range of alerts than is
possible with homogeneous IDS, and thus perform cross-sensor signature -
based attack detection.
48
This work uses a model based on IDS producing standard alerts to a
centralised database for storage which is then interrogated by a separate
analysis engine. The analysis engine provides sophisticated analysis and
correlation tools for an administrator in order to better identify attacks with
multiple stages, targets or sources than possible using a single IDS. An
administrative interface them uses the features of the analysis engine to
provide information to an administrator. The interaction between these
components is shown in Figure 3.3.
Analysis ConsoleCentral Database
IDS
AlertData
IDS
AlertData
IDMEF Translation Mechanism
Signatures, Clustering, Graphing
Figure 3.3: Generic Alert Analysis Model
Alerts are provided by an IDS are translated to IDMEF before being stored
in a centralised database. Separate components should be used to translate
native IDS alerts, store them in the database, and analyse the information in
the database in order to provide a proper modular architecture. In analysing
the alert information, a scheme to construct signatures to describe attacks has
been developed, as well as clustering functions and methods to graph
information stored in the database, providing the features required in Goals
1), 3) and 4), above. The design of the signature notation and the algorithms
used for the signature matching are addressed further in Section 3.6, while he
49
design of further analysis and clustering functionality is address in Section 3.7.
A convenient user interface is found in the administrative interface which
connects to the database to collect data for the analysis systems. A framework
has been developed allowing the easy incorporation of other algorithms and a
set of experiments described in Chapter 5 which provides the basis for Goal
2).
Control Unit
Alert Agent
IDS
Alert Agent
IDS
Alert Agent
IDS
Alert DatabaseAdministrative Console
IDMEF Alerts
Alert Stream
Figure 3.4: High-level Design
Figure 3.4 shows the high level design containing Alert Agents which handle
transferring IDMEF alerts to the database, a Control Unit which controls
alert entry into the database and can optionally provide information to an
administrator, and an Administrative Console which performs the role of
analysis of the database (refer to chapter 4 for a detailed description of the
implementation of this design). The architecture is similar to that proposed by
Cuppens [13], Doyle [43] and Vigna [23]. All of these works aim for the same
basic goal of centralised alert analysis and correlation.
50
3.4 IDMEF Alert Messages
IDMEF alert messages provide an important tool in the interoperability of
IDS by supplying an extensible format for the expression of information
found in IDS alert messages, especially those found in NIDS. While IDMEF
is a very expressive and extensible format, a ‘least common denominator’
approach is needed for data for alert correlation containing heterogeneous
systems to enable correlation on the largest number of IDS possible. In
addition, the extensibility and flexibility of this format can become a
hindrance when analysis of IDMEF messages is to be performed. This is
mainly due to the conversion of native IDS messages into the IDMEF
format, leaving certain fields incomplete, overused or incompatible with each
other. A common problem [13] is the relationship between the alert names of
different IDS. Other problems can be the resolution of the timestamps on
individual alerts, as well as incompatibility between information from NIDS
and HIDS. This incompatibility manifests itself in the form of different
semantics for source and destination, as well as problems with the scope of
each, as in the fact that a NIDS cannot understand the concept of a user
account. This incompatibility is being resolved in most cases (Chapter 2) by
the specification of abstract events, which are then classified in unique forms
understood by the correlation system. That is, however, outside the scope of
this research. Storage of IDS information in static database tables can be a
problem due to the challenges involved in mapping the flexible XML format
such as encapsulating different constraints on numbers of sub-nodes in a
node, maintaining information of the elements of a node and maintaining a
schema that adequately represents the flexibility of XML without excessive
numbers of tables.
Some options for the storage of IDMEF alerts include:
• The fastest process is to drop alerts from the alert stream directly into
a flat binary file; however this does not provide much usability, as
51
searches must be made through the binary file itself, and individual
items with each alert must be converted each time they are needed.
• Store the information in a flat text file in order to provide human-
readable information, but this information is hard to analyse and
partition.
• Place the alerts in a database, where we can search and partition the
data with greater ease, but with performance issues due to database
insertion and searches.
The last bullet point is of particular interest in the context of this research.
The need for efficient searching and reporting of summary information about
the alerts stored in a data store means that the flat text file can easily become
inefficient with a data set consisting of thousands of alerts.
A database with a schema expressive enough to incorporate all IDMEF
message items can be used, if carefully constructed. This schema contains
multiple relationships and table joins to recreate the full alert, as the XML
DTD contains many ‘one or many’ relationships where a separate table must
be created to store the multiple nodes potentially contained within the XML
message. A diagram of the schema is included in Appendix B. Managing a
large number of tables is difficult, as is real-time searching of the data due to
the number of table joins required to produce the amount of information
normally included in a NIDS alert (time, alert name, source, destination). The
technique used to circumvent this problem when fast results on common
queries are needed is to create a separate table as the result of the request of
time, alert name, source , destination and sensor and perform analysis on this table.
This table can then act as an index into the entire data from the IDMEF alert
when required, and so avoid joins that comprise the entire database of
thousands of alerts, which results in large delays in generating tables.
52
A more comprehensive approach to be implemented in a future version of
the prototype is to store, as per normal, the IDMEF information in the
current comprehensive schema. At the same time adding the most useful
subset of information directly to a separate table when the alert is received by
the database avoids the overhead of having to create the subset table at some
later stage. The advantage of this method is far less computation, due to the
simple selection of components from the XML document rather than post-
processing with computationally and resource intensive table joins.
The issues relating to the use of a database as a central source of information
are particularly well covered in work by Atallah et al. [44] in which they
describe the table-per-token or table-per-event approaches, detailing the
features and disadvantages of each. While Atallah finishes by proposing a
hybrid approach, combining a table of summary information indexing into a
table per token approach, the option to use this approach was not available
here due to the XML issues noted previously.
3.5 Real-time vs. Off-line Operation
Of direct relevance to virtually all aspects of operation from algorithm to
processing load is whether the analysis will be performed in real-time (i.e.
continually updated), or off-line (i.e. when the user requests it). Real-time
analysis is far more useful inasmuch as immediate information is obviously
more relevant to an administrator if it is received as soon as possible after an
event occurs. However, it constrains the algorithms and techniques used in
analysis, as processing load needs to be minimal for fast operation and access
to large amounts of information is not available due to the need to have
immediate access to the information store to ensure low latency of reporting.
In order to focus on providing an infrastructure which promotes
development of useful new algorithms for alert correlation, it was decided
that the design should focus on providing an off-line system whilst still
considering, where relevant, how the system would be implemented in real
53
time, considering the potential benefits of real-time reporting for an
administrator.
Typically an algorithm used for real-time systems is acceptable for off-line
analysis, but the reverse is often not true. Some aspects of signature matching
fall into this category. Algorithms capable of use in real-time and off-line
modes, such as signature matchings’ iterative comparison with a defined
pattern can be performed using real-time data or a large off-line data source
simply by altering the access method and data source to the process
implementing the algorithm. However, certain analysis methods such as
cluster analysis, graphing and machine learning can only be performed off-line
or with a large amount of cached real-time data. As such, some methods still
applicable to real-time application impose significant requirements on a
system if used in real-time, yet very little in off-line mode.
The approach used in this work has been to use techniques which could
eventually be used in a real-time context with the proper infrastructure, yet
implement this in an off-line manner in order to focus on new algorithms and
effectiveness at detection rather than a properly performing real-time
infrastructure. This method, however, means that the current prototype
(described in more detail in Chapter 4) could be deployed in real-time simply
by changing the method of gathering information from the database to a real-
time alert stream and providing enough cached alerts to perform small-period
cluster and statistical analysis in real-time.
3.6 Attack Signatures
Attack Signatures are used as the primary method of attack detection in our
architecture. This is due to the accuracy and simplicity of signatures compared
to data mining and artificial intelligence methods. Attack Signatures are also
the primary method of detection by NIDS themselves, therefore a similar
higher-level analysis method using signatures makes sense. Note that while
our system provides functionality similar to that of ADeLe, the range of
54
functionality was kept intentionally minimalistic, and improved with
additional features only when they were deemed necessary.
Our goals of producing a simple yet functional system for heterogeneous IDS
alert correlation flow through into the specification and usage of signatures
themselves. Attack specification languages such as LAMBDA [21] and CISL
[14] provide the ability to define very complex relationships between events
themselves. They do not, however, satisfy the goal of a simple method of
specification. Attack Signatures are, at their base, a pattern of alerts
corresponding to some connected events, normally an attack.
Having limited features also allows the detection logic to be simple and
efficient. Certain concerns such as unique alert naming are not incorporated
into the signature design, as the likelihood of an alert name being replicated
by another type of IDS is remote. If this were to occur, the names could be
modified in transit by the alert agent in order to make them unique. For
example, if two different IDS produced the same alert name, the type of IDS
could be attached to the end of the alert name such that the end result would
be similar to ‘TCP-Scan-Snort’ or ‘TCP-Scan-Dragon’.
Specification of Attack Signatures is addressed in Section 3.6.1, with a
discussion of the concept of signatures composed of multiple sub-signatures.
An example of an attack signature is also included in order to demonstrate the
practicality of our approach.
3.6.1 Specification
Attack Signatures are composed of alert sequences or alert groups. Alert
Sequences are constructed as an ordered list, where the sequence is
considered matched when the final and any precursor items are satisfied in
the order listed. Alert Groups are a simple set of alerts, where the group is
complete when all members of the group have been matched. Alerts within
the group can be matched in any order.
55
Group Signature
Sequence Signature
Alert 1 Alert 2 Alert 3
Alert 1 Alert 2 Alert 3
Signature Name
Signature Name
Figure 3.5: Signature Depictions
In Figure 3.5 is the depiction the two types of signature. In the upper portion
is a group signa ture. The alerts may arrive in any order. In the lower portion is
a sequence signature, each signature element must be preceded by the one
before it to be valid. These conventions will be used to depict basic signatures
(no special timing or additional features such as weighting used) throughout
the thesis.
Within an Attack Signature, items can be labelled as either mandatory or
optional. Mandatory items are required for the signature to be complete, while
optional items are not required but may add weight to the firing of a signature
as detailed below. Mandatory and optional are used to change the operation
of the detection engine relative to that particular element of the signature. In
the case of a sequence signature, the engine will attempt to match the optional
item as well as any other optional items up to the next mandatory item in the
sequence. This means that if a sequence contained an initial mandatory item,
three optional items, and a final mandatory item, upon matching the first
mandatory item the engine would then detect matches to all the three
optional items in addition to detecting the final mandatory item. In the case of
groups, optional items are included in matching, but not required for firing.
56
This is to enable the use of optional elements to encompass related alerts to
the signature, which may not directly affect its operation, such as login events
after a privilege elevation attack.
Elements of an Attack Signature may also contain weighting if optional items
are included. Weighting allows for the composition of signatures made of
only optional elements, which otherwise would have no criteria upon which
to fire. Each signature must have a threshold firing value assigned to it if
optional alerts are needed for the signature to fire, which can be any positive
integer as defined by an administrator. Then, individual elements of the
signature can be assigned values which, when matched, add up in order to fire
the signature. Arbitrary threshold and element values enable the specification
of situations such as ‘two out of three alerts’ or ‘alert five plus three other
alerts’ which was found to be useful in practice.
Attack Signatures also contain timeout values, both for the signature itself, as
well as elements within the signature. Timeouts are the only current method
for a signature to be removed from the detection engine without firing.
Individual element timeouts are used to timeout the signature based on the
expected time for an element within the alert to be matched. This means that
certain combinations of alerts within a specified time period can be matched,
as well as combinations that may take longer periods. The overall signature
timeout is measured from the first alert matched, and can be used in order to
specify a total timeout. This is useful in the case of group signatures with
longer individual timeout values where the signature may otherwise stay alive
for an undue amount of time without expiring.
Each alert element within the signature can also have a replication factor
associated with it. This is the number of times the alert can be repeated with
the signature, and can be used in cases where many instances of one alert may
correspond to less of another. All these alerts should be associated with one
57
instance of the signature. This is especially useful in Denial of Service (DoS)
type scenarios, with large numbers of alerts overloading the system.
Each signature also contains a netmask section on the target range applicable
for the signature. This allows for ranges of targets, a single host target, or any
host target to be specified, using bit masking on the IP of any alert to be
matched to a signature. An example of this is the common netmask of the
private IP address range 192.168.0.0 and a netmask of 255.255.255.0,
indicating a range of 192.168.0.0-255. In our terms, rather than specify in the
form of a dotted quad (the 255.255.255.0 above) we specify simple the
number of bits to be masked, working from the left, in which case the above
netmask corresponds to 24 bits of netmask. 32 bits of netmask indicates a
single host, and zero bits indicates any host is acceptable.
3.6.2 Multi-Step Signature Composition
A simple set of signatures composed entirely of sequences or groups could be
useful, but many real-world scenarios require combinations of these. One
particular case is in the example of the Cuppens attack [13]. This attack is a
sequence of different alerts, but this sequence may be broken by out of
sequence events. As such, the signature could be specified as a group instead
of a sequence in order to be more encompassing of scenarios, but at the
expense of possible misdiagnosis. A better option would be to create groups
corresponding to the alerts produced in tandem by two IDS and those that
may appear out of sequence. The final signature could then be made up of the
sequence of these groups. We use the concept of alert stream insertion in order
to achieve this. An attack signature may produce an alert when fired, which
can be inserted into the alert stream, and so contribute to another signature.
In this way, an arbitrary number of signatures can be combined with synthetic
alerts in order to produce one final signature, which may itself produce an
alert. The details of this process are discussed in more detail in Chapter 4.
This technique allows for a simple streamlined processing system that is
58
efficient in terms of the matching process but not in terms of overall
processing, considering synthetic alerts must be generated for each signature
used in a composite signature. However, if synthetic alerts are deemed useful
in their own right, then the inefficiency of generating the new alerts is
minimal. This approach is unique in the design of alert analysis systems, and
can be used to generate any number of combinations of alerts for the
specification of a signature.
3.6.3 Example
This example is taken from the experiments that were performed to validate
the operation of the proof-of-concept prototype described in Chapter 5.
Figure 3.6 shows the composition of the three signatures that capture the
pattern of alerts observed when attempting the Cuppens attack. The two IDS
used in our experiments, Snort and Dragon, produce different alerts when
observing this attack, but these alerts can be related to each other based on
their content. Snort produces a specific pattern of alerts:
• FINGER root query,
• two occurrences of RPC portmap listing,
• RPC portmap request mountd, and
• RSERVICES rlogin root.
Dragon produces:
• FINGER:ROOT,
• three DYNAMIC-TCP alerts, and
• an RSH:ROOT alert.
59
The two finger-related alerts can be grouped into a single signature, as can the
remote login alerts. The RPC messages are grouped with the DYNAMIC-
TCP alerts, as these alerts seem to be a catch-all alert Dragon uses in the
absence of other matches. These could indicate errors that Dragon has
noticed, but not had an explicit signature for. We have included a single
DYNAMIC-TCP alert in the group to verify the operation of Dragon that we
expect in this situation. We have used a demonstration signature set from
Dragon, which means the full signature set would be likely to contain specific
alerts in place of these DYNAMIC-TCP alerts much like Snort.
FINGER rootquery
[FINGER:ROOT]
Cuppens Finger Detect
RPC portmaplisting
RPC portmaprequest mountd DYNAMIC-TCP
Cuppens RPC Detect
RSERVICESrlogin root
[RSH:ROOT]
Cuppens Remote Login Detect
Cuppens FingerDetect
Cuppens RPCDetect
Cuppens RemoteLogin Detect Cuppens 3 Stage Detect
Figure 3.6: Cuppens Attack Signature
Figure 3.6 shows the composition of the three signatures used. The first
signature, Cuppens Finger Detect, combines the two finger alerts in the group
format. The second signature, Cuppens RPC Detect combines RPC alerts and a
TCP-related alert in the also in the group format. The third signature, Cuppens
Remote Login Detect is comprised of two remote login related alerts, and the
fourth signature, Cuppens 3 Stage Detect combines the group signatures in a
60
sequence , to provide a single signature whose role is to signal the detection of
the entire attack.
This example does not include the optional/mandatory components,
weighting and priority concepts discussed above. The concepts and the
practical concerns of their use are explained in Chapters 4 and 5 together with
their effect on the design of the detection engine and on the efficiency of
detection of attacks.
3.7 Alert Analysis
In this section we describe the methods used to analyse data in our system,
detailing the algorithms used for signature matching, clustering and graphing.
Information is given on how to combine these techniques to allow for better
manual analysis than that generally available using individual tools for each
task.
3.7.1 Single and Multi-fit Signature Matching
The process of matching a given alert from the alert stream to a signature can
be accomplished in a variety of ways depending on the requirements of the
signatures themselves. We propose two different algorithms for the matching
of alerts to signatures, single-fit and multiple-fit matching. The first has been
implemented in the prototype described and evaluated in Chapters 4 and 5.
Before considering the more significant design details of the signature
matching algorithms, it is useful to present the following definitions:
• The active signature set - this is the set of all partially matched valid
signatures, including signatures during partial stages of matching.
• The open signature set - the set of all attack signatures, which also
contains any active signatures from the active signature set.
61
Essentially, this set is any signature in any stage of matching, which
still requires an alert to fire.
• The candidate alert set - this is the set of alerts comprised of:
o the first unmatched mandatory alert plus every immediately
preceding unmatched optional alert in the case of a sequence
signature, for all sequence signatures in the open signature set,
and
o every unmatched alert in the group in the case of a group
signature, for all group signatures in the open signature set.
This set is the set of all alerts which are required by the set of
open signatures in order to complete.
• The per-alert candidate signature list - this is the priority-ordered list
of open signatures ‘waiting’ for the alert. Each candidate signature list
may contain multiple instances of the same signature in multiple
stages of matching. A specific signatures instance will usually be
present in several of these lists:
o in the case of sequence signatures, the signature will appear in
the signature lists for each optional alert preceding the next
mandatory alert to be matched together with the mandatory
alert itself, and
o in the case of a group alert, the signature will appear in the
signature list for each of its unmatched alerts.
• Alert propagation – when an alert has been superseded by a newer
alert in a matching process, such as the replication factor of an alert
item in a signature becoming full and overfilling. An old alert may be
62
copied or propagated to another signature instance in order that it is not
wasted.
The details of the two signature matching algorithms, single-fit and multiple-
fit, are presented below.
Single-fit signature matching
With a single-fit strategy of matching alerts to signatures, the current alert
from the alert stream is matched against the candidate signature list associated
with that alert, particularly with the first signature in the list i.e., the highest
priority signature in the list. This signature then consumes that alert. Our
system detects overlapped, duplicated attacks of the one identical type as the
open signature set is initialised at start up to include all attack signatures. This
is augmented with additional partially matched signatures as and when a new
partial match occurs.
The system prevents knowledge of the timeouts used by signatures from
being exploited by an attacker. For example, an attacker could attempt to
subvert the system by essentially launching a slow attack or a number of such
attacks. We guard against this situation by deploying two counter-measures:
• detection of overlapped, duplicate attacks - the configurable detection
of overlapped, duplicate attacks as discussed above, and
• alert propagation - our treatment of signature priority and the
propagation of alerts between signatures. As mentioned previously,
matching of the current alert to the open signa ture set takes place
through the candidate signature list for that alert.
The single-fit algorithm initially matches alerts to signatures using a priority-
ordered list of candidate alerts. An alert is tested against the constraints of the
timeouts and netmask to determine if the alert matches that particular
63
signature matching instance. If the alert does not match, the algorithm iterates
through the candidate signatures until an appropriate signature is found. If no
suitable candidate signature is found, the alert is dropped. Otherwise, the alert
has been matched to a signature, and the signature matching instance should
then be updated with the alert information. If this results in the alert
replication factor being exceeded, the oldest alert from the replication set
replaces the currently matched alert in order to be propagated in it’s place and
the process of signature matching continues (though now with the older alert)
through the candidate signature list.
The replacement of an alert may mean the alert which is now attempting to
be matched to another signature is timed such that it occurs before the start
alert of any of the following candidate signatures. In this case, the alert will
not match to any further signature. Two options are valid in this case:
a) Create a new signature matching instance with the old alert, or
b) drop the alert
In our case, if the alert is one of the first alerts in the signature (i.e. in a group
signature or the first mandatory alert in a sequence signature) then a new
signature matching instance is created, otherwise the alert is dropped. This
can lead to, in the case of excessive amounts of replication, a smaller amount
of signatures firing than theoretically expected for a given number of alerts, as
alerts mid-signature may be dropped before a required earlier alert is over-
replicated, and the results of this can be seen in Chapter 5. This would only
occur if timeouts are longer than the actual attack itself, but is relevant in
examples such as the DoS Attack which operated over an unspecified time
period, rather than many attacks which may have discrete steps with fixed
intervals between alerts.
64
This algorithm serves to increase the chance of attack detection of the highest
priority alerts, and give the highest priority to firing as soon as possible with
the newest alerts possible. This is the most useful outcome for an
administrator, as it helps to avoid a malicious attacker manipulating attack
processes to avoid detection through delaying portions of the attack and
timing out alerts that are important.
An example of this can be constructed using four signatures in order of
priority S1, S2, S3 and S4. They use alerts as follows:
• S1 : alerts of type a, b & c,
• S2 : alerts of type a, b, c & d,
• S3 : alerts of type a, c, d & f, and
• S4: alerts of type a, d & f.
In this example, we assume that replication factors of 1 are used for all
signatures, and that they are all sequence-based signatures for simplicity. Two
alerts of type a are received, namely a1 and a2. Due to the priority of
signatures, a1 is associated with S1 and a2 with S2. If alerts of type b & c arrived
soon after, S1 would complete, and leave signature S2 to complete using a2. If
then alerts of type b and c arrived, S2 would have matched to the point of alert
d. If an alert of type d arrived, it would be matched to S2. As such, S3 and S4
would have no alerts whatsoever. If a third alert of type a had occurred during
this time (and after S1 had completed), S3 and S4 would still be left out as a
new instance of S1 would be created as it is the highest priority.
In the contention between the scenario of alerts of type a, c, d and f arriving in
that order (and providing S1 and S2 did not need an a, c, or d [indicating both
are waiting for a b]), S3 would fire rather than S4 due to priority. If S4 had
higher priority, S4 would fire and S3 would not, even though all the alerts are
65
available for a full match to S3. Note that the likelihood of this happening is
low, as in general alerts of type a, c, and d would be taken up by existing or
new instances of S1 or S2.
We can see from this example that high priority short signatures can easily fire
before more complex lower priority signatures, if they have significant overlap
in their alerts. However, if a signature has been rated with a higher priority
than another, it is assumed that the alerts should be allocated to that signature
first. While some signatures are starved of alerts this prioritisation ensures
conformance with the security policy defined by priorities.
Multiple-fit algorithm
Multi-fit allows the current alert to contribute provisionally to multiple eligible
signatures simultaneously until the first of these fires. At that time, the alert’s
contribution to the other signatures is withdrawn and they are rolled back to
their previous status.
In the single fit algorithm, the purpose was to fit individual alerts against one
of a range of signatures, however in the multiple-fit case we maintain a core
list of signatures and apply the alert to all possible signatures. Each
provisional match of alert to multiple signatures is flagged, to be used in the
case of roll-back. These possible alerts contribute to the advance of each one
of the possible signatures. When a signature that contains a flagged alert is
fired, a search is performed for the flagged alert throughout all the signatures
in various partial stages of matching, and the alert is deleted from the
matching process of the other signatures. When a signature fires, it uses the
oldest of any possible alerts that is within the timeouts of the signature.
Essentially, the engine itself should select from the range of signatures the
oldest combination of matching alerts that is within the constraints of the
signature yet still allowing it to fire.
66
Using this approach allocation of alerts to signatures can be made without
problems of higher priority signatures withholding alerts from lower priority
signatures. This is not to say priority is unimportant, however this method
aims to avoid the starvation issues outlined above. In order to support priority
while still enabling starvation avoidance, signatures must be kept in memory
for a short period after being fired, in order that if an alert is recorded such
that a higher priority signature would have fired without the existence of the
lower priority signature, the lower priority signature is ‘rolled back’ in order
that the higher priority signature may fire. The addition of the roll-back
features is the most complex part of the multi-fit algorithm.
This concept can most easily be illustrated in the form of an example,
mirroring the single fit example above.
Four signatures, S1, S2, S3 and S4 use the following alerts:
• S1 : alerts of type a, b & c,
• S2 : alerts of type a, b, c & d,
• S3 : alerts of type a, c, d & f, and
• S4: alerts of type a, d & f.
Two alerts of type a are received, namely a1 and a2. This means that S1 to S4
are all in the first stage of execution, with a2 remaining in the background if
required after a1 has been used. If alerts of type b & c arrived soon after, S1
would complete, and leave signatures S2 to S4 to complete with a2. If another
b and c arrived, S2 would have matched to the point of alert d, and S3 and S4
would require d and f. If an alert of type d arrived, it would be matched to S2
through S4. However, S2 would complete immediately, and therefore remove
alert d and alerts a, b and c from the pool. As such, S3 and S4 would need to
roll-back to the state of no matches. If a third a had occurred during this time,
67
S3 and S4 would be left in the stage of matching only a, but also a new
instance of S1 would be created after the initial S1 had completed as another
possible match.
In the contention between the scenario of alerts a, c, d and f arriving in that
order, both signatures S3 and S4 would be candidates for firing. In this case,
we would give the alert to the signature with the highest priority first, S3. In
the case of two alerts with the same priority, precedence would go to S3 due
to the fact that more alerts have been matched to that alert, making it more
probable that the true signature is S3, rather than S4.
Comparison
A single fit algorithm has the benefit of simplicity and efficiency of
implementation. Flexibility is still possible with the single fit algorithm
because we are able, given the nature of our offline platform, to perform a
range of related experiments in which we can adjust the relative priority order
of signatures used in the matching process and thus test for the varied
outcomes that will result. Multi-fit on the other hand has some advantages,
the main one being that it leaves open the possibility of matches with all
possible signatures until one fires and does so without necessarily burdening
the administrator with details of signature priority (though this can still be
useful). At the same time it has the disadvantage of possibly significant
increases in computational overhead which, in a real-time environment, could
be a problem.
The multiple-fit algorithm allocates alerts to the best fit possible, and allows
for multiple scenarios of alerts to occur without interfering in the operation of
the system. The only known problem occurs in the case of out-of-sequence
alerts, which can upset the iterative process of matching described above.
This problem may be resolved by using a short buffer before the alerts are
fully ‘committed’ to a signature. This problem, as well as the problem of alerts
missing from a signature is dealt with by Cuppens with the concept of a
68
chronicle [11]. This concept may be included in further work on the multiple-fit
algorithm.
Only the single-fit algorithm is used in the experiments and testing performed
in this thesis.
3.7.2 Clustering Analysis
Clusters are groups of alerts which are related by a logical or mathematical
relationship between features of the alert such as time, source, destination or
the sensor which detected it. Using the features of such clusters, we can aid
analysis of alerts by reducing large lists of alerts into discrete groups with
features of interest. This can be used to find those alerts that occur on a single
host, or move between hosts within a certain timeframe, by analysing the
destination of the attack, or even to find spoofing attacks by looking at
sequences of source address. Clusters can also be used to provide feedback on
signatures. If other alerts occur in the same time period on the same host as
those related to a signature, these may conceivably be related. As will be
shown in Chapter 6, clusters themselves can be used to identify a lerts that can
be combined into a signature to simplify the later identification of that
pattern.
Clusters can be gathered in simple fashion by using SQL queries on the alert
database. However, the majority of clusters used here are generated by
iterative comparisons of alerts from within the results of a time-specified SQL
query from within the database. An SQL query is built using the time
constraints specified by the user, including optional constraints on other alert
features such as source or sensor, and produces the set of results in a data
type called a resultset. Our prototype then converts the resultset to a
conventional array data type, and iterates through this array testing each item
based on comparisons with other items in the array. The database is used
primarily as a data storage and retrieval mechanism in this case, and is used to
sort the resultset based on the feature which is being tested. Using this
69
method allows for better performance of the clustering function, as a
database requires many more iterations to complete the comparisons than the
custom program running on the converted resultset. The methods used to
compare the different features of alerts is given below, with further detail in
Chapter 4:
• Time: Difference of time in seconds, forward or backward.
• Source/Destination: An integer is given which is the difference of the
numbers in the IP number of the appropriate alert feature.
• Alert Name: Performed by looking for similarity in names.
• Target Port: Comparisons of the port number of the alert, usually to
detect port scanners.
While clustering and signatures are useful for the administrator, they still
require the specification of ranges and sets of data to be compared in order to
be useful. A method is needed for an administrator to perform manual
analysis just in order to ‘see if everything is working as per normal’. Graphing
of alerts and our GUI (Section 4.6) were introduced to fulfil this need.
3.7.3 Graphing Analysis
The factors deemed important for graphing were time, sensor, alert type and
alert. The graph must provide summary information, and allow for the
administrator to drill-down to investigate alerts of interest. The Hummer IDS
[46] provides sophisticated analysis of multi-node intrusion detection systems
information and can show correlation between alerts in order to determine
attack patterns. Hummer uses force-based vector representations and
histogram based techniques [47] to show these relationships. While this
method is more comprehensive and provides more information than the
70
simple graph views used in our model, we consider the simplicity and
familiarity of our alert graphing system to be sufficient.
3.8 Combining Analysis Techniques to Detect Attacks
The combination of the techniques of signature analysis, clustering, and
graphing allow for comprehensive analysis for an administrator analysing
alerts, and gives a range of options for analysis. Combining these methods
also allows for better management of the strengths and weaknesses of
individual approaches.
As signature -based detection is both faster and less labour intensive, it is used
as the primary means of detection, with clustering and graphing used to
gather additional information after signature detection has been performed.
However, clustering and graphing can be used in order to identify the alerts
which could be used in a signature, and be used to verify that a signature is
complete and contains only those alerts which are needed.
The first method of combining the techniques is using clustering and
graphing to create signatures. It is the ability to specify a signature based on
groups of alerts identified as anomalous. This is achieved by analysing a
gathered set of alerts, identifying those alerts which are relevant (anomalous)
and coding into a sequence, group or combination of the two. The operation
of this can be found in the examples shown in Chapter 5 for each signature.
These signatures can then be tested using the next technique of verifying
signature operation using clustering and graphing.
Clusters can also be used to verify the effectiveness of signatures. A simple
way to achieve this is to create a cluster over the time period +/- five seconds
of the period of the alerts from the signature. If no other alerts are available,
the signature is operating properly. If there are more alerts, and they appear to
be related to those in the signature (same target for example), the alert may
need to be modified to include these new alerts. When a signature has not
71
been fired, looking at the alerts that should occur versus the alerts available
can also indicate whether the signature includes erroneous alerts.
Clusters can also be used to validate or expand on the information in the
graphs displayed, by querying on different features of the alert than currently
displayed. An example of this that is not yet implemented would be to click
on a particular item and have an option “Display a cluster of all alerts with the
same source or destination within the last two minutes”. This can be gathered
currently using only a few clicks of a mouse, but clusters can help produce
this sort of information automatically. As will be shown later in Chapter 5,
certain attacks cannot be currently specified in our signatures, whilst they can
be observed in the graphs provided.
3.9 Summary
The primary goal of alert correlation is the identification of attacks which may
be manifested by alerts across different IDS, either in different physical
locations on the network, or between heterogeneous IDS. The alert features
most relevant to the basic correlation performed in this work are Time,
Source IP, Destination IP, Alert Name and Sensor. Correlation over the
features can be performed in multiple ways depending on the technique used;
in our case either signatures, clusters or graphing.
This chapter has discussed the rationale, methodology and design of the
prototype used for alert analysis. It has discussed the core concepts of attack
signatures, clustering and graphing, as well as their usage and usefulness in an
analysis context. Chapter 4 discusses the implementation of these concepts, as
well as discussing the process of developing the prototype and the testing
involved in its development.
72
73
C h a p t e r 4
DETAILED DESIGN AND IMPLEMENTATION
In order to evaluate the alert analysis and correlation concepts and design
specified in Chapter 3, a prototype has been constructed in Java. The
prototype needed to remain true to the concepts of simplicity and usability,
and provide a demonstrable benefit to the administrator over manual analysis
of IDS alerts. The deployment of the system needed to be straightforward
and the requirements in infrastructure realistic. This chapter describes the
implementation of the prototype that implements the algorithms for signature
detection, alert correlation and alert analysis. The chapter starts with the
requirements for an implementation of the design described in Chapter 3,
then continues by describing the components that make up the prototype.
Following these sections each of the signature matching, clustering and
graphing engines are described in detail and the chapter concludes with a
summary.
4.1 Implementation Requirements
The test IDS to be used in the prototype system needed to be both easily
obtainable, as well as having a useful signature set and, ideally, configurable
signatures. The IDS also needed to be able to run as distinct processes on a
given operating system, in our case Linux. This particular requirement was to
enable the concurrent processing of two different IDS on the same host, in
order to verify the correlation between IDS. Snort was an obvious choice,
being free and open source. This IDS is very useful for research, and also has
a variety of input and output plugins which in our case allow for direct
logging from Snort to IDMEF alert messages. The second IDS, Dragon, was
chosen due to the ease of obtaining an evaluation copy, freely available
signatures equivalent to those on Snort and simple logging format that
allowed for easy translation from Dragon alerts to IDMEF alerts.
74
The operating systems of the machine on which the IDS were to be deployed
needed to be configurable and able to support multiple IDS in an efficient
manner. Linux was used due to the wide range of IDS available as well as high
configurability, reasonable performance and the researcher’s familiarity with
the system.
The programming language, Java, was used due to its widespread deployment
on multiple different operating systems and facilities for deployment over a
web-based infrastructure if required. It also has benefits from a security
standpoint due to strict typecasting and immunity from buffer overflows. Java
supports simple interaction with databases due to the Java Data-Base
Communication (JDBC) layer. Lastly, Java’s close relationship with the
eXtensible Mark-up Language (XML) and object manipulation and libraries to
support multiple techniques of XML interaction makes XML manipulation
far simpler in Java than other languages.
The design of the architecture needed to support IDS that had IDMEF
support as well as those without. It also needed to be able to support the
Intrusion Detection eXchange Protocol (IDXP) communication at a later
time. These considerations required an agent system capable of translating
native IDS messages into the IDMEF and IDXP communication when the
standard was stable and libraries available.
A centralised database allows for easier correlation than distinct databases per
IDS, but agent communication to a centralised database meant expensive
database operations over the network if agents stored information directly to
the database. Instead, a server was created which communicated with the
agents, gathered all alerts available, and stored them in the database locally.
This server could also, at a later stage, perform filtering if required.
75
4.2 Components
The prototype architecture consists of three major components. The Alert
Agent (AA), The Control Unit (CU) and the Administrative Console (AC).
These three components communicate to provide a simple architecture which
allows for the majority of IDS to be integrated easily and effectively.
Control Unit
Alert Agent
IDS
Alert Agent
IDS
Alert Agent
IDS
Alert DatabaseAdministrative Console
IDMEF Alerts
Alert Stream
Figure 4.1: Basic Architecture
We can see from Figure 4.1 that Alert Agents are used to communicate
IDMEF alerts to the Control Unit, which logs those alerts into a central
database which can be accessed by the administrative console. The Alert
Agents should be placed as close as possible to the IDS themselves to help
with access to the IDS logs. The Control Unit and Alert Database should be
on the same host to speed database addition, while the Administration
Console should be placed on its own host in order to provide the best
performance for the a Graphical User Interface (GUI) and improve
performance for the CU and database. This is particularly important in
76
circumstances such as large scale attacks and DoS which require processing of
large numbers of alerts.
We now describe the core components of our architecture.
4.2.1 Alert Agent
IDS Log(IDMEF) Alert Agent Control Unit IDS Alert
(Native) Control Unit
Database Database
Native IDMEF
Translation
Case 1: Direct IDS IDMEF Logging Case 2: Native IDS Alert to IDMEFLogging
Figure 4.2: The two cases of Alert Agent operation
The Alert Agent performs translation of native IDS alerts to the IDMEF
format and communication of IDMEF alerts. As shown in Figure 4.2 it can
either use a native IDS IDMEF output format such as the Snort output
plugin as a simple transport mechanism, or translate to IDMEF from the
native IDS format. Generally native IDS IDMEF messages should be
considered a better data source than converted messages, due to the increased
amount of information that can be gathered at alert time versus post-event
conversion, but the basic information mandatory for an IDMEF message can
be met by virtually any IDS native alert format. The end product is that the
Alert Agent transfers IDMEF standard messages to the Control Unit for
processing and storage. The actual transfer can be an immediate or batch
process depending on the needs of the network and administrator. The Alert
Agent can also be responsible for renaming non-unique names as discussed in
Chapter 3, however this was not required in our prototype due to differences
in Snort and Dragon reporting mechanisms.
77
4.2.2 Control Unit
The recipient of all IDMEF messages is the Control Unit (CU). The CU is
responsible for alert processing and storage as well as, in the future,
implementing any real-time alert analysis or filtering. In the current prototype,
the CU simply stores all information from the AAs in the database. The alert
is stored in the database by a custom IDMEF-DBMS mapping module. A
JDBC connection pool was used in order than large volumes of alerts can be
stored simultaneously, which can be important when spoofing or DoS attacks
occur. The interaction of the components in the CU is shown in Figure 4.3.
PostgresDatabase
IDMEF Item Parsing
IncomingConnections
Connectionsallocated toThread Pool
Item Table Selection & Storage
Key Generation Table Storage
Thread ExecutionIDMEF Alert Stored in
series of tables viaJDBC connection pool
JDBC Connections
Figure 4.3: Control Unit Diagram
The IDMEF-DBMS mapping is static, though the structure is easily changed
to support future versions of IDMEF. In order to provide the speed required,
the IDMEF alert message is treated as a long string as opposed to parsing the
XML document as an object. Elements within the alert are searched for using
the XML delimiters of the IDMEF node. The content within the element is
then read into a new string suitable for either further processing or storage in
the database. For those elements with sub-elements, extra searches are used
through the newly created element string. During the search process, when
the final content of each element is identified, a key is allocated from a key
generation factory. The keys allow for sub-elements to be linked with their
parent element, and for the elements to be linked to a unique alert ID. The
database schema (Appendix B) contains the linkages between items from the
IDMEF message to content in the database. The latency associated with table
78
additions is the primary bottleneck in alert addition to the database. The
thread system and JDBC connection pooling were needed to achieve
acceptable storage rates in the database considering that the test experiments
generated thousands of alerts every time the attacks were run.
The above process allows the IDMEF messages to be decoded from XML
and logged into a relational database, aiding in portability and the
effectiveness of later searches on alert data. The database is expressive enough
to contain all the possible information in an IDMEF alert, though only a
small amount of this is generally used in our analysis. The additional
information not directly used in our analysis is stored for administrators to
use if needed. For performance we use a single table with a relevant subset of
information rather than combining each IDMEF message from the multiple
tables used to store each message. The number of SQL JOIN operations
required to accurately reproduce the IDMEF messages is large and the
expense in processing time makes queries inefficient if performed often. We
use the data from the subset table alert_table shown in Table 4.1, and use the
unique identifier alertdbid to reconstruct IDMEF messages on a per item basis
when required.
Name Type Role alertdbid integer Unique database ID ident string Alert unique ID from IDS analyzerid string IDS sensor name time string Time of detection of alert source string Source IP target string Target IP targetport string Target Port
Table 4.1: Subset table details
4.2.3 Administrative Console
This application allows the administrator to gain access to the alerts stored in
the database. In off-line mode, the simplest form of correlation, the
aggregation and sorting of alerts is performed by SQL queries on the
79
database. The next level, where complex correlation occurs, is performed on
the results of queries on the database from the subset table. A query is used to
specify the range of alerts of interest such as ‘alerts from the past week’.
Other approaches to correlation involving a database [45] use the database
itself for correlation. We contend that this approach offloads processing onto
the database, which overloads an already stressed component in many IDS
that log to databases. Our approach is shown in Figure 4.4. The
administrative console is designed to be the only device actually reading the
database, though there could be multiple consoles running simultaneously.
The console also has rights to alter information inside the database if required
and to perform tasks such as delete old records, merge alert information or
change alert data to add extra information. The administration console allows
the user to initiate signature matching as well as performing cluster analysis
and viewing graphs of the alerts currently available in the system. For better
performance, the ResultSet returned by the database on a query of alerts is
translated into an array. This allows for random access to the data and easy
iteration, neither of which is provided by the JDBC interface. Each of the
analysis methods is discussed in more detail in Sections 4.3 to 4.5.
80
4.3 Signature Analysis Engine
As noted in Chapter 3, there are existing solutions available to describe
security events in such a way as to aid correlation between them. However,
our only requirement from a signature representation language is simpler than
that: it is that the signatures be able to represent the relationships between the
alerts generated by IDS as opposed to generic events. In order to best suit our
specific scope we have developed our own simple signature format for
patterns of alerts. The general requirements for our signatures are:
• The signature must contain information about the relationship
between the alerts comprising the signature. This includes whether
the alerts are a sequence or unordered group, any temporal
constraints on the interval between alerts and the timeout for expiry
of the signature. As discussed below these attributes were
subsequently expanded to include other alert attributes assigned by
the administrator.
• Signatures should be able to generate an alert themselves or be able to
trigger new monitoring processes, so multiple signatures can be
combined in a sequence or hierarchy if necessary.
One property of our system is that signatures can specify what operations to
perform on the stored alerts which contributed to the signature (e.g. store,
delete, merge) as well as any responses to be effected. Our relatively simple
signature specification can accommodate many conceivable relationships of
interest by being able to express signature composition using multiple
signatures without storing redundant information. This section describes the
components and operation of the signature detection engine. It begins by
describing the format of signatures in the prototype, and the data structures
used by the detection engine, and goes on to describe the process of matching
81
to a given signature and some examples of signatures used in the experiments
performed in Chapter 5.
4.3.1 Signature Information
Each Signa ture contains the following information gathered from the
signature list file, summarised in Table 4.2 and discussed in more detail below,
indicated by a number for each field:
No. Signature Field Data Type Details
1 Signature Name Text Name of the signature 2 Signature Type Text Group or Sequence 3 Fire Action Text Type of Action when detected. 4 Fire Content Text Content for Fire Action 5 Netmask Integer Number of bits for Netmask 6 Signature Timeout Integer Seconds for timeout 7 Weighting
Threshold Integer Threshold for firing using
weighting. 8 Priority Integer Priority from 1 – 5 9 Alert Specific Fields a Alert Name Text Name of the alert b Mandatory Field
(optional) (Mandatory / Optional)
Whether an alert is mandatory or optional
c Weight (optional) Integer Contribution to weighting threshold
d Alert Timeout (optional)
Integer Number of seconds before timeout
e Replication (optional)
Integer Number of times alert needs to be repeated before signature fires
Table 4.2: Signature Format
1. Signature Name: A string describing the signature. This can be any
length string at this stage. This name is chosen by the administrator at the
time of creation. The only constraint on these names is that they must be
unique.
2. Signature Type: Whether the signature is a group signature or a sequence
signature. If a sequence, the list of alerts (9) is in order of match.
82
Combinations of groups and sequences cannot be used within the same
signature, but using the newalert fire action (3) a synthetic alert can be
generated by a fired signature, which makes possible the combination of
groups and sequences by using a hierarchy of signatures.
3. Fire Action : What the system is to do when the signature is fired.
Currently the only type used is the newalert class which indicates that the
signature should produce a new alert (a synthetic alert) and place it in the alert
stream. Other types could include a message to the administrator, responses to
the attack or increased logging.
4. Fire Action Content: This field is reserved for content required by (3). For
example, in the newalert case this field is used to store the name of the new
alert to be generated, although in the case of an active response, this might
contain additional details to be given to a firewall. In some cases, this field
may not be used at all.
5. Netmask: This field is used to determine the range of targets applicable to
the signature. Each signature, when an alert is first matched to it, is initialised
with the target IP of this first alert. This IP is then bit-masked with any
further alerts to determine if the IP is within acceptable limits. This mask can
be from zero, implying any target is acceptable, to thirty-two (32) which
implies that only direct matches are acceptable. Any number between these
limits implies an IP subnet range based on the first alert.
6. Overall Timeout: This is the overall timeout for the signature, timed from
the first alert. This is also used as the default timeout for items within the
signature which can be overridden on a per-signature basis discussed in (9). If
the default timeout is used for an alert, the entire signature overall timeout
could be used up with the wait for a single alert, essentially meaning that
individual alerts using the default timeout have no specific timeout. The
timeout is specified as an integer representing the time period in seconds.
83
7. Weight Threshold: In the case where a signature includes optional alerts
and weighting, this is the threshold accumulated weight number at which the
signature is fired. If this field is zero then weighting is not used. Section 4.3.4
describes how this component fits in the signature matching system.
8. Priority: Used in the case of alerts when they can match more than one
active signature, both the time the alert found its first match and the priority
of the alert are used to determine the signature to which the alert is attributed.
At this time, an alert instance can only be matched to a single signature
matching instance. The process matches in decreasing order of priority. In the
event of two equally prioritised signatures, matches on the basis of earliest
signature matching commence first.
9. Signature List: This is the open-ended list corresponding to the alerts
contributing to the signature. Each item in this list contains five fields of
which only Alert Name is mandatory. The other fields are given default values
if not specified explicitly:
a) Alert Name: A string containing the name of the alert to be
matched.
b) Mandatory/Optional: Whether the item is a mandatory contributor
to the signature. If this field is not included (zero or null) then the
item is considered mandatory.
c) Timeout: A field to override the default signature timeout if
required. Absence of this field means the alert is given the default
signature timeout.
d) Weight Contribution: The amount the alert contributes to the
activation of a signature.
84
e) Replication: This number indicates how many repeat instances of
the alert are required for the signature to fire. If more than this
number are received, then the older alerts are distributed to other
signatures. If not specified, this is assumed to be one.
4.3.2 Engine Components
Three data stores (Alert Stream, Active Alerts and Active Signature State Vectors
[ASSVs]) are central to the operation of the signature matching engine:
Alert Stream
The alert stream is the stream of alerts from a data source. This assumes a
serial processing capability of these alerts, either in terms of a sequentially
accessible buffer or similar system, such as the ResultSet interface provided by
JDBC or an array. The alert stream of the prototype, as mentioned, earlier is a
ResultSet converted into an array. The alert stream should support random
access insertion in order to support the newalert option of signatures.
The alert stream, in its simplest form, is the resultset provided back from a
query of all of the alerts currently stored in the database. In practice, a
summary table is produced from the alert information consisting of the alert
time, target IP, target port, source IP and the sensor that detected the alert.
Normally, the administrator defines a time period for the alerts, in order to
manage the large number of alerts IDS can produce in a relatively short
amount of time. The alert stream can also consist of alerts that can be inserted
into the alert stream by the system itself, using the newalert option of a
signature, in order to provide the ability to use combinations of sequences
and groups. The newalert option is immediately handled by the signature
engine without processing any other alerts. This means that synthetic alerts
are generated within the alert stream immediately after the last alert which
contributed to the signature has been processed.
85
In a real time system, the alert stream would work in much the same manner;
however alerts can be received directly from the IDS and are checked
immediately, rather than stored in the database and checked off-line, as in the
current system.
Active Alerts
These form is a special set of data containing the list of candidate alerts
against which the currently processed alert is matched. Initially this will
normally include any leading optional alerts plus the first mandatory alert in
any sequence signature and all the component alerts of a group signature, as
well as later on including the next unmatched alert of a signature sequence
which has previously been partially matched. Each alert item contains the alert
name, the alert timeout and the referring signature. The referring signature is
an internal ID of the instance of signature matching in order to support
multiple signature matching instances in varying stages of operation. The
referring ID allows for multiple instances of the same signature in different
stages of matching.
An issue with this particular method is how to timeout alerts inside the active
list. At this stage whenever a new alert arrives, the active alerts are checked
and removed if they have expired timeouts. This can lead to extended periods
between reaps, though this is not of particular interest in the prototype as this
could easily be changed to time-based checks in future versions.
This aspect of the active alerts list is not relevant in an off-line process except
for when after all alerts from the alert stream have been processed. At this
point all the active alerts can be placed in a special list called the partially
matched signature list which the administrator can then use either to diagnose
signatures that are incorrectly specified (too many items) or to identify items
of interest that may not have fired the signature completely.
86
Active Signature State Vectors List
The Active Signature State Vectors (ASSVs) data store contains the state for
each instance of a signature currently in the process of being matched. This
may include multiple instances of the same signature in different stages of
matching. ASSVs are added to this list when an alert matching the first item
(or one of the first group of items) of an attack signature is found. ASSV’s are
used to store the state of each instance of a signature being matched, and are
referenced in the Active Alerts list.
Only one ASSV exists for each possible state of the signature – for example,
if a sequence signature required 3 alerts to complete, there could only be 3
ASSV’s for that signature in existence at any one point in time:
1. the ASSV of a signature to be started (waiting for the first alert),
2. the ASSV of a signature having received the first alert, waiting for the
second, and
3. the ASSV of a signature having received the second alert, waiting for
the last.
If replication factor is used, then the same three states exist, but each ASSV
would only progress to the next stage when the replication factor for the alert
it is waiting for completes.
Each ASSV contains the following information:
• Attack Signature Name,
• Last matched alert,
• Last matched alert timeout,
87
• Total signature timeout,
• Vote total, and
• List of matched alerts.
These structures allow for an easily accessible set of information to aid in
efficient matching, whilst also enabling the future monitoring of state of
active signatures during real-time operation. This list also contains the
information of the contributing alerts when a signature is fully matched or
dropped due to timeout.
4.3.3 Sequence Matching, Group Matching and Timeouts
As mentioned in Chapter 3, signature may be of two types:
1. For signatures which define sequences, the engine attempts to find a match
for the first item only. When triggered by such a match the next alert in the
sequence is added to the Active Alerts list. An active sequence signature
expires when the timeout for the next alert is reached or the overall signature
timeout is reached.
2. For signatures which define alert groups, the engine must check for each
item in the group. For this reason groups should be kept small, or significant
processing could be required. When an alert within the group is matched, it is
flagged so that it need not be matched again. This means a repeated alert will
create a new active group signature, which is the desired operation at this
prototype stage, though repeat alerts may be attributed to the same signature
in future versions of the prototype depending on context. An example of
what could be achieved is when an alert identical to one previously matched
in a signature is detected it is used to increase the confidence placed in the
alert. This example would be similar to Cuppens clustering, though it is only
used for exact matches to alert name, rather than the more flexible approach
88
by Cuppens. A group signature expires when a timeout occurs on the interval
between alerts (based on the timeout specified for the alert immediately
preceding it), or when the overall signature timeout occurs.
We currently use a first-fit system (based on priority and age of the possible
signature) to determine matching on signatures, which means that the first
signature which matches an alert will prevent any other signatures from
matching it. This has implications for signature ordering and the construction
of signatures, but is not a significant impediment at this stage of research.
Discussion of the requirements and impact of other matching methods is
included in Chapter 6.
4.3.4 Signature Matching Process
The architecture is designed to provide a simple way to match an alert to any
one of the multiple signatures in different stages of partial match.
The process by which an alert is matched to a signature lends itself to a series
of stages with easier and less computationally intensive checks in earlier
stages, whilst more complex checks such as checking relationships between
alerts placed later, in order to improve efficiency.
Initialisation
The first stage, simple matching, uses a simple string comparison on the initial
Active Alerts list (those candidate alerts initialised at startup). This would
normally include the first alert in any sequence and all the component alerts of
a group signature as well as all optional alerts of a sequence signature up to
the first mandatory alert.
First Stage – String match and expiry check
A match of an alert can result in five different cases:
1. The alert can be a valid start alert for a signature, in which case a new
ASSV is created and initialised with the details of the first alert.
89
2. The alert can match a component within the process of matching a
signature without requiring that the alert be removed (such as in the
case of group signatures). In this case, the ASSV should simply be
updated with the information about the new alert and the alert list
should be updated with the alerts to match to the signature in the next
step in the sequence.
3. The alert can be a valid component of a signature. It completes the
signature by completing all mandatory items, satisfying the weighting
threshold if relevant and being within the total signature expiry time
in order to enable the system to fire the signature.
4. The alert can be a valid component of a signature but fails on its
individual alert expiry. In this case if the alert is mandatory the
signature is flagged as invalid and dropped. Any active alerts that are
attributed to the signature’s ASSV are also dropped. The ASSV is
saved in order to provide potential diagnostic information. If
optional, the alert is removed from the active alerts list. If a weight is
associated with this alert and it has already been added to the
signature total, then the total is decremented by the weight of this
alert.
5. The alert can be a valid component of a signature but fails on the total
signature expiry. In this case, the ASSV is flagged as invalid and
dropped. Any active alerts that are attributed to the signature’s ASSV
are dropped also. The ASSV is saved in order to provide potential
diagnostic information.
If for any reason the ASSV is discarded, its information is included in a
special display of all unmatched alerts for the administrator. When an ASSV is
discarded, the alerts which have been matched to it are discarded too. This
can lead to less signatures matching than algorithmically possible. This causes
90
some false negatives when large amounts of alerts are received, and the effects
of this are shown in Chapter 5.
If the alert is a valid match and the ASSV is still valid, they are passed onto
the second stage of processing.
Second Stage – Signature verification and addition/deletion
At this point we check if an alert of the same type has been matched
previously to this signature. In this case the ASSV needs to be updated with
the information of the new alert and may require an older alert to be
propagated if the new alert means the replication factor of the signature is
exceeded. This particular case is especially useful for group-based signatures
in which multiple items can be matched multiple times in a single attack, such
as a DoS attack
Third Stage – Signature check, modification to active alerts
This stage checks to see if all items that are mandatory have been satisfied,
and if the weighting threshold has been reached. It does this after adding the
new alert to the list of alerts and checking the signature for what requirements
need to be satisfied.
At this point, the four items for signature firing need to be checked:
1. Signature/Alert Expiry:
Ensure that all alerts are valid, though this particular check is done when
alerts are matched to an ASSV.
2. Mandatory Items:
Check if all mandatory items have been completed.
3. Weighting Threshold:
91
Check if the combined weighting total is greater than the threshold required.
4. Replication:
Check if all the mandatory items in the signature have the required number of
repeat alerts.
The signature can be fired if all criteria have been completed. If the signature
is not to be fired, then the signature needs to calculate if any appropriate
changes to the active alerts list should be made. In a group signature no action
is required, but for a sequence signature we need to find the next mandatory
alerts in the sequence and any optional alerts that precede it. All these alerts
need to be added to the active alerts list and the old matched alert removed.
4.3.5 Alert Propagation
Of particular relevance to results in Chapter 5 is the concept of alert
propagation. This occurs when an alert is matched to a signature where the
particular alert in the signature has already filled its replication factor. In order
to produce the best chance of a complete match, older alerts are replaced with
the new alert and the older alert is then potentially matched to an older or
new signature (created if no older signature can be found).
We can provide an example of this in the case of two signatures active, called
S1 and S2, needing alerts a, b and c, with a replication factor of 2 for a and
another alert b (not covered in this example). S1 has one a (called a1) while S2
has none. S1 is at a higher priority as it already has one b and one c and is
looking for a second a and b. If two as were to occur (a2 and a3), then a2
would fill S1, while a3 would fill S1 and cause a1 to be progated to S2. If a
fourth a were to occur (a4) then it would fill S1, propagating a2 to S2. If a fifth
occurred, S1 would have a4 and a5, S2 would have a2 and a3, and a new
signature would be created with a1. This new signature can be immediately
eliminated if a1 is too old, and any new alert could cause the new signature to
92
expire. If new alerts were immediately propagated to new signatures, there is
the possibility that S1 could time out based on a1 while still waiting for the
extra b, therefore this method maximises the chance for at least one signature
match.
This alert propagation mechanism errs towards allowing the best chance for
S1 to complete, to the detriment of S2 and any additional alerts.
Alert propagation is also affected by the amount of states a signature can exist
in simultaneously. If a signature could exist in three states (such as the
example discussing ASSV’s in Section 4.3.2) then if each of these states were
had an alert with a filled replication factor, then a new alert would cause a
cascade of alerts (one from each state) to propagate to the next lowest state,
eventually having one alert from the lowest state be removed from any ASSV.
This can cause some alerts to be dropped based on a set of full replication
factors in all available ASSV’s. This occurred in the examples in 5.4.3
Dropped Alerts.
4.4 Clustering Engine
This section describes the second method of analysis provided by the
prototype – clustering analysis.
Clustering analysis, while not as efficient as signature analysis, is a useful tool
in many different scenarios. The first of these is the case of analysing large
volumes of alerts in order to identify patterns of unusual alerts. Clusters can
be used to identify alerts with a close relationship in a number of features, the
most important of these being time. A set of alerts that are unusual occurring
within a short time span of each other could indicate an attack. A set of alerts
closely related in target could be an automated scanning or exploit tool. A set
of alerts closely related in source could indicate a spoofed or zombied attack.
93
Clusters can also be used as a feedback tool for signatures. If signatures are
not being completed, or the administrator is wondering if more alerts should
be incorporated into a single signature, using clustering on the time period
during which the signature fired can identify those alerts that may be related.
By defining a known mathematical relationship in the feature, clustering can
also be used to show the movement of attack tools either through port ranges
or targets. If a tool is known to increment by a certain number in some
integer-based feature, then clustering can be used with this relationship to find
the related alerts across a larger data range than is possible with graphing (due
to display issues). It is also useful to detect stealth and distributed attacks.
4.4.1 Clustering Relationships
We define the following relationships as being useful in clustering alert
analysis:
1. Alerts clustered by range:
This can be used to specify a subset of data as being useful, such as:
• "Give me all alerts from last week" or in a period for statistical
purposes, or
• "Show me all the alerts gathered into minutes from the last two
weeks".
This particular scenario is useful, and can also be easily gathered using the
graphing tool, or simple SQL queries.
2. Alerts by simple sequence:
This can be used to specify sequences increasing, decreasing or similar to each
other. A simple sequence can be defined using a mathematical operation
94
(such as less than, greater than, and equals) and can be applied to alerts of one
of three groups:
• all previous values,
• a buffer of previous values, and
• the closest value by time or data type.
The only mathematical operations possible are those of direct comparison
(such as greater than, less than or equals) which do not require multiple passes
(such as complex mathematical relationships requiring forward and backward
comparisons).
3. Alerts by pattern:
Patterns encompass more complex relationships including information such as
sequences increasing over finite time periods, operations requiring multiple
passes, etc. An example of this could be "Tell me all the alerts that are exactly
15 minutes apart in the last week" or "Give me a list of the average times
between operations on port 80 from C-class 192.168.1.0".
The processes by which each field is compared are:
• Time: Difference of time in seconds, forward or backward. When
searching for this item, an integer is supplied - if the time difference is
less than the integer value, then the alerts are grouped. This is
generally used to find sequential or multi-staged attacks by finding
those alerts within a given time period.
• Source/Destination: An integer is given which is the difference of the
numbers in the IP number of the appropriate alert feature. This is
done by iteratively comparing the four portions of the dotted-quad
95
notation of the feature and evaluating the difference. Differences in
each portion are added together for a total difference. This method is
used in order to easily find scanners or automated tools that iterate
through IP subclasses looking for targets.
• Alert Name: Done by looking for specific matches. Essentially this is
the group of matching alert names. Testing was performed on
comparing the spelling or word content of the alert name string. How
to define these relationships and the benefits of the comparisons were
uncertain.
• Target Port: Comparisons of the port number of the alert, usually to
detect port scanners.
Clusters can also be chained – combining two clusters or performing
clustering on the results of a previous cluster analysis can allow for very
specific results to be obtained; for example, all alerts with the same name
occurring on the same port within two seconds of each other.
4.4.2 SQL and Clustering
When a database is used, a natural question to be addressed is how much of
the data processing required can be performed by the database itself – thereby
reducing the requirements on the analysis engine. While SQL is useful its
range of application in our particular environment is rather limited.
The first major problem of using SQL exclusively for clustering is the lack of
ability to describe complex patterns in data. Being able to effectively respond
to queries such as "Find me all the alerts on destination x with a difference of
exactly fifteen minutes" (perhaps to find a network scan) would require a
query that generated a temporary table of alerts and then iterated through the
entire temporary table for each alert in the first table. While dealing with
datasets of hundreds of rows, this is not a significant problem. As we will see
96
in Chapter 5, a common dataset would include tens of thousands of alerts for
any type of active network for any reasonable amount of time. Even after this
information is returned, we still need to add it into some sort of data structure
for storage.
Exactly the same sort of problem arises when we look at similarity, which is
useful for comparing alert names, rather than basic mathematical
relationships. We can do basic similarity checks using SQL by using like or
range comparisons within the VARCHAR (variable character) datatype in SQL
(all the data from the alert is stored in VARCHARs due to the string nature of
XML). However, we can still only really compare one variable at a time
unless we use multiple OR statements which quickly become unwieldy and
decreases database performance.
The second major problem is the lack of adequate feedback mechanisms.
Essentially when we get a result from the database it is returned as a ResultSet
datatype. Manipulating a ResultSet directly is, however, fraught with danger,
as an incorrectly configured program could write back into the database
which could be potentially dangerous. We also cannot query a resultset
directly, that is, apply further SQL queries on it if desired. If we require more
data, we must issue a completely different query, or add our extra query
information to the query which generated the resultset. This requires multiple
iterations of potentially intensive queries which can quickly become
unacceptably slow. Other minor issues include potential to overload database
server in times of high load, and the lag in queries due to database access
compared to local data.
While some complex systems have been developed that use stored procedures
to perform complex tasks on the data within a database, the question then lies
in whether centralising the processing load is efficient, and whether excessive
programming should be performed on the database at all, considering its
primary task is to store alerts. Using SQL, multiple combined ranges and
97
LIKE can provide good data reduction facilities and can define relationships
of Types 1 and 2 above, enabling the database to behave effectively as a
sophisticated data selection mechanism for an analysis system.
If we analyse the information in a processing layer above SQL, and let SQL
do what it does best (storing and retrieving sets and ranges of data), then we
can leverage SQL to do data reduction via ranges and aggregation using
SORT and GROUP BY commands. We can also use it to get simple
mathematical operations such as less than, greater than, and equals. Full-featured
clustering needs to be performed in a higher processing layer however.
The normal thread of execution of examining alerts to generate a cluster is:
1. Create an SQL statement to define range and any simple relationships.
2. Execute SQL.
3. Reduce SQL resultset based on extra requirements – this may be used if
certain sets of alerts could be deleted but the set cannot be represented in
SQL (this may not be required).
4. Match patterns on resultset, which would generally require conversion to a
conventional array data type. This may require multiple passes depending on
the pattern defined.
5. Match any second level patterns.
6. Generate lists and summary.
A simple example of the clustering process would be to search on all alerts
that have occurred with differences of less than ten seconds between
sequential alerts. This cluster could be used in tracking those alerts which
have occurred sequentially on a single host, which may mean they are related.
98
In this case, a simple SQL query (Step 1) would select all the alerts with the
desired host, in a selected timeframe (for example, 9:00am – 9:15am), and
ordered by time. This query is then executed, and for this example, no Step 3
action is needed. In Step 4, each item needs to be compared to the next item
in the resultset. In the current version of our prototype, each ResultSet is
automatically converted to an array to allow for random access. The resulting
array is then searched iteratively with comparisons performed on the next
alert for each alert in the array. Groups of alerts whose difference from the
next alert is less than the ten second window are created, and stored for any
further processing. In this case, no second level patterns are used (such as
requiring that elements of the group contain a certain priority level or certain
combinations of alerts) and so we skip Step 5, and in Step 6 generate the lists
of each group and a summary of the alerts found.
Examples of the process of generating complex clusters can be found in
Chapter 5.
4.5 Graphing Engine
The Graphing Engine provides a useful service in the system by allowing
quick visualisation of the state of the network (in terms of alerts) at any point
in time, whilst also allowing the user to quickly drill down to specific alerts if
required.
99
Figure 4.5: Graphing Screenshot showing tooltips
As can be seen in the screenshot in Figure 4.5, the graphing window is
actually a split graph showing two different graphs.
The upper graph shows the alert type (numbered) on the left axis, and time
on the lower axis. The alert name can be determined by placing the mouse
over a particular point in the graph, at which point a tooltip pops up (as
shown in the diagram) showing the following:
• time,
• the IDS detected, and
100
• the name of the alert
which are all delimited by ‘**’. The colour of the shape and the shape itself at
the point shows which IDS detected the event. The lower graph shows alert
numbers per unit time (in this case seconds) on a logarithmic scale in order to
achieve best use of graph space. Placing a mouse pointer over a point on the
graph shows the alert name, time and actual number of alerts.
Looking at the graph, patterns of repeated events as well as time periods with
a wide dispersion of alerts can be seen very easily. Groups of alerts close
together can be quickly recognised. Using the tooltips the exact alerts can be
identified. Overlap of two of the same type of IDS logging the same alert can
be observed by noticing those items where two shapes are superimposed. IDS
alert overlap by different types of IDS can be observed where two alerts with
similar names but occur at the same time.
By clicking on a specific point, a summary and list of the alerts contained at
that point will be displayed as shown in Figure 4.6 (Screenshot). The first
three lines consist of the total amount of alerts, the total unique sources of
alerts for that time period, and the total unique targets. It is followed by a
table detailing each alert of that point.
Figure 4.6: Summary Window
101
The table contains a subset of the information contained in each alert, which
is comprised of
• name (First Column),
• time detected (Second Column),
• source IP (Third Column),
• target IP (Fourth Column), and
• target port, which is optional (Fifth Column).
While the graph is simple at this stage, the axis and data to be displayed can be
changed if required. Some other possible forms of the graph, though not
implemented, are:
- graph with or without the alerts attributable to signatures,
- graphing of the alerts only attributable to signatures, and
- the specific graphing of items such as clusters.
Also, while the summary functionality together with the list of alerts works
well in situations of low numbers of alerts, in the case where many alerts
occur in the same second, clicking on a specific time period could produce a
separate graph of the target, destination and alert type. This would avoid the
need to click once for each alert type within a given period, and make analysis
within large time periods easier.
4.6 Prototype Graphical User Interface Usage and Output
A Graphical User Interface (GUI) was developed to aid in the usage of the
signature, graphing and clustering engines. This interface was also used to
102
transfer alert logs and modify signature parameters such as priority to aid in
the signature tuning process.
The three main outputs of the prototype are:
• Graphs. The graphs generated from each experimental scenario are
shown in Appendix C, and are exact copies of the graphs produced
by the prototype.
• Signatures. When the signature matching process is being
performed, the GUI can show the signatures that have matched and
the signatures which have timed out in two different panels
(signatures not matched is optional) in real time. These panels show
the alerts that have been matched to each signature in either the
matched or timed out case, for diagnostic purposes. The results of the
signature matching (not signatures which have not been matched) is
shown in Appendix D for each experimental scenario.
• Clustering. The GUI can initiate a time-based cluster analysis of the
alerts stored in the database, and the output in Appendix E shows the
results on each of the experimental scenarios. Due to the general
length of these clusters, output is directed to standard out (normally
the console) which can be placed into a text file and analysed at a later
time. Future versions would work on producing a graphical
representation of each cluster which could then be drilled down,
much as icons in the graphing engine can currently (see Figure 4.6).
The interface can be used to perform combinational analysis and alert
correlation across heterogeneous IDS. The GUI provides the following
information in five panels (shown as screenshot in Figure 4.7 – note that the
information provided by the prototype during each scenario is included in the
Appendices for reference):
103
• (Upper Left) Graph of alerts with IDS, time, and alert name displayed
as well as a linked graph with alert numbers.
• (Middle Left) Graph of IDS alert relative frequency, mapped to a
logarithmic axis.
• (Lower Left) Legend indicating the colours in the upper graph for
each IDS, as well as each alert type from the left axis of the upper
graph in numerical order, also showing the colour used to display the
alert type in the lower graph.
• (Middle Panel) List of signatures that have completed.
• (Right Panel) List of signatures that have expired but not completed.
Figure 4.7: Analysis Console Screenshot
The GUI shown in Figure 4.7 can be used in many different ways in order to
allow for easier alert analysis. The most common is the use of the signature
104
analysis to identify series of alerts which correspond to user-defined attack
signatures. The progress of signature matching is shown in a window on the
left of the display. When a signature expires but is not complete, it is stored in
a separate list, normally not used, but which can be placed next to the full
signature matching window. An administrator can look at the alerts within
matched and unmatched signatures in order to determine if an attack has
occurred, and any sources and targets involved.
The graphing functionality can also be used to identify trends and series of
alerts that do not correspond to signatures. For example, if a large number of
alerts is observed on a single host, one might assume that an attack is taking
place. By clicking on individual items in the upper graph, the administrator
can drill down and see the alerts within that item and look at the features of
those alerts. Certain attacks such as DoS or IDS alert spoofing attacks can be
observed visually by looking at the number, type and IDS of alerts that have
been stored. Examples of these are given in Chapter 5.
By looking at repeated series of alerts that occur on a graph, patterns of alerts
can be used to create signatures to automate the detection of these alerts. If
the alerts are false positives, the signature can automatically delete them. If
they are actual attacks, they can be brought to the attention of the
administrator easier. Graphing also helps to alleviate the direct need for
clustering. By visual inspection one can normally deduce those alerts close to
one another on the graph, and so close to one another in time.
The prototype is currently used by automatically graphing all of the alerts in
the database (though this can be set to be alerts between dates) and the user
can then identify any patterns through the graph if desired. The user can then
choose to run signature or clustering analysis on the same timeframe as has
been graphed, and have the results of this displayed in text windows in the
GUI. In this manner, all of the tools are integrated to the same dataset, and
the results of each can be correlated by the user.
105
4.7 Summary
Chapter 4 has discussed the issues in implementation of the basic concepts
described in Chapter 3. We have detailed the algorithms involved, as well as
the relationship between the components in the system and how they can
work together. This chapter has defined and detailed the development and
implementation of our proof-of-concept implementation of an IDS alert
correlation system. The next chapter details the methodology, procedures and
results of experimentation on this prototype in order to verify its operation
and determine its usefulness.
106
107
C h a p t e r 5
EXPERIMENTS AND RESULTS
The previous chapters have discussed the fundamental basis for our
prototype and the design and implementation of the prototype itself. The
development of a prototype to test correlation between IDS requires a
method of validating the concepts underlying the prototype as well as
performance outcomes in a variety of test situations. To this end, there was
considerable effort devoted to the design and implementation of an
experimental network. A series of tests were run over this network, in order
to properly examine the response of the system. The network used to test the
prototype went through multiple iterations including the version used to test
the prototype for an early paper on our work [12], although only the final
version is presented here.
This chapter begins by specifying the experimental procedure and rationale
for testing. It describes the attacks performed across the system and the
details of the signatures that were used to detect them. Information is
provided on the testing procedure and how this relates to the reproducibility
of the experiments. This is followed by details of the results of the basic
experiments, whether each attack is detected and the details of detection.
Following on from the base experiment results we detail the consequences of
modifying the different constraints on signatures such as priority, replication
factor and weighting. The chapter concludes with a summary and
commentary on the results produced.
5.1 Experimental Procedure and Rationale
The network was designed to provide a simple way to perform multiple
iterations of tests in order to verify proper operation of the prototype. The
core requirements were:
108
1. Verifiable operation.
2. Reproducibility of results.
3. A range of attacks representative of major types of attack.
4. Testing across different hosts and different IDS.
5. Testing with and without normal background traffic.
With these requirements in mind it was decided to use a switched network
with multiple hosts running multiple IDS, and a set of attacks run in different
modes to test the operation of the prototype. For these experiments, we
decided to use two hosts, each running two separate IDS: Snort and Dragon.
A suite of attacks was run sequentially and simultaneously, with and without
background traffic. The motivation for these decisions follows.
5.1.1 Network and Host Configuration
The network for testing needed to supply the following features:
• Multiple Hosts, and
• Segmented Traffic.
Multiple hosts were required in order to place IDS at different points in the
network as well as enabling attacks to be run from a separate host across a
physical network onto the multiple IDS hosts. Only two separate hosts were
required for the IDS, plus one host for the attacker, totalling three.
109
Redhat Linux 7.2(Host 2)
DragonNIDS
DragonNIDSSnort Snort
AdministrativeConsole
Postgresql Alert Database
Alert Agents Alert Agents
Attacker/Control Unit
XML-DBMSMapper
JDBC
Alert Transfer(after attacks)
FreeBSD 4.5(Host 1)
Switch
Attacks
Figure 5.1:Test Network Diagram
Figure 5.1 shows the logical network diagram. The two hosts, Host 1 and
Host 2, both have Snort and Dragon installed. The Network Time Protocol
(NTP) is used to synchronise times between the two hosts in order to provide
alerts that are identical in time. This is especially important in time-critical
signature-based detection and critical in enabling the ability to correlate alerts
between hosts using the other methods such as graphing and clustering. Snort
logs use millisecond resolution, however Dragon logs use second resolution.
Consequently the default logging mode in the database is second resolution.
Host 1 runs FreeBSD 4.5 while Host 2 runs Redhat Linux 7.2. Both machines
purposely contain open services for clients to connect to, including SSH, FTP
and NFS, which are required for proper scanning using Nmap and a
vulnerability scanner used called Vetescan, two tools used in the attacks used
in the evaluation. A third host running Redhat Linux 7.2 runs attacks against
the two IDS hosts and also stores the alerts for analysis, performing the role
of the Control Unit. The IDS are using standard signature sets. In the case of
Snort, this is the default ruleset provided with Snort 1.8 Beta 3, while in the
case of Dragon, this is the default evaluation copy ruleset combined with the
110
arachnids database of Dragon signatures current as at April 2002. The naming
convention for each IDS is shown in Table 5.1.
IDS Name Description IDS1 Snort IDS running on Host 1. IDS2 Dragon NIDS running on Host 1. IDS3 Snort IDS running on Host 2. IDS4 Dragon NIDS running on Host 2.
Table 5.1: IDS Naming
Segmented traffic was used to ensure the separation of the two IDS hosts
from each other’s traffic in order to avoid duplicate alerts. The only way to
provide this feature was using a switch. This led to certain problems during
the injection of background traffic as, unless the traffic was recorded by
machines using the same MAC addresses of the IDS hosts, traffic would not
be routed to them. This was circumvented using static routing when
background traffic was required. The background traffic itself was captured
live from the Information Security Research Centre (ISRC) network. It
contained a diverse range of alerts. The network does not have any external
traffic occurring on the system. The switch does not have an IP address and is
simply used to segment the traffic between the two hosts. This allows us to
assume that alerts from the two hosts cannot be duplicated across the two
hosts producing redundant alerts. The background traffic was replayed using
Tcpreplay 1.4, using a constant rate of 20MB/sec traffic.
5.1.2 Reproducibility and Testing Procedure
Reproducibility was a primary concern during the design of the test network
and required careful consideration. Tcpdump is often used for packet capture
and replay to allow reproducibility. This does not, however, accurately
represent the traffic occurring across the network. Some IDS may only track
valid TCP connections, and so a Tcpdump session would be classed as stale
packets and completely disregarded. According to Ranum [48], a
benchmarking or testing scenario is very complex, and is generally undertaken
111
without proper concern for how IDS testing methods may produce different
results than the actual execution of attacks. In order to address these concerns
and to be certain of the operation of the attacks, the set of attack tools used
were scripted using Linux bash scripting. This allowed the attacks to be
replayed easily and with essentially nil variation. Four versions of the basic
attack script were used in order to perform attacks simultaneously,
sequentially, and with and without background traffic, to test how the system
was affected by these different circumstances.
When run sequentially, the attacks are spaced ten seconds apart in order to
differentiate the alerts from each different attack. This was particularly
important in the early stages of the work using clustering to enable the
identification of patterns that could be turned into signatures.
When run simultaneously all the attacks are initiated at the same time. Due to
the nature of each of the attack, some attacks finish later than others. The
goal is to attempt to identify the same attacks as those detected sequentially
despite the fact that multiple attacks are in execution at once.
The background traffic, unlike the attacks themselves, was deployed using a
replayed Tcpdump session. The logistical requirements of actually generating
a realistic set of background traffic live at the same time that the attacks were
running was very difficult, and would require profiling of average user
information and activity such as that found in Lundin’s recent work [49]. The
Tcpdump capture was sped up in order to produce a reasonable number and
distribution of alerts, considering the timeframe of most of the experiments
was approximately five minutes. The background traffic itself produced some
alerts due to both IDS being primarily packet-based. As such the scenario of
simultaneous attacks with background traffic produces a wide spectrum and
distribution of alerts for a correlation system. Due to the version of Tcpdump
used to dump the traffic originally only providing static packet dump sizes (in
our case 1500 bytes) the packets when replayed need to be padded using the
112
pad option in Tcpreplay in order that the IDS do not trigger signatures on
mismatched packet lengths. The fact that Tcpreplay replays stale TCP
connections was not as much of a problem for background traffic as for the
attacks themselves, as the requirement for background traffic to be as
reproducible as the attacks themselves was not as strict.
Before each attack run, the logs on each machine are deleted to ensure that
each IDS has no residue alerts from a previous experiment. After the times
are ensured to be synchronized via NTP, each host runs a script to start both
IDS. When this script completes, the attacker host runs the script for the
attack scenario required. The running time of these scripts is between thirty
seconds to one minute and thirty seconds depending on the operating
scenario. After the scenario is complete, the IDS are shutdown and the alert
logs are transferred to a separate host in order to be saved and entered into
the database.
5.1.3 Gathering IDS Alert Logs
As the alert logs of each IDS had been deleted before the scenarios were run,
the logs for each scenario were considered clean of erroneous alerts, and were
stored in separate locations for each scenario. For Snort, these logs were
already in IDMEF format, however the normal alerts were logged in order to
verify the operation of the IDMEF logger. The Dragon alerts were still in
their native format. Two applications are then run to load the alerts into the
database – the first simply sends the Snort IDMEF alerts to the Control Unit,
while the second takes the native Dragon alerts converts them to IDMEF
then sends them to the Control Unit. The messages were then sorted and
summarised to ease searching and the database was backed up and the entries
erased in order that the results from the other experiments could be stored.
When analysis on a particular scenario was required, the database was erased,
and was restored using the information from the relevant scenario.
113
5.1.4 Appendices
Appendices C, D and E contain the output logs produced by the prototype
when run using signatures, clustering and graphing on the scenarios.
Appendix C contains the graphs produced for each scenario, and will be
referred to in the text. These graphs contain three core components, the first
is a graph of when incidents occurred, indexed by time and alert type. In this
graph, triangles, circles and squares (together with their colour) are used to
identify the IDS used to log the attack. The IDS are included as the first four
elements of the legend. The second graph contains information about the
numbers of each alert occurring in the upper graph. Each alert is colour
coded, and included (together with an integer representing the integer type in
the upper graph) in the legend. This lower graph is logarithmic in order that
particularly high numbers of alerts do not obfuscate lower occurring alerts by
skewing the scale.
Appendix D contains the logs produced by the prototype during signature
matching. Due to conflicts with priority and starvation (see Sections 3.7.1,
5.4.1 and 5.5.3), each scenario was examined twice to detect all the attacks.
Appendix D also contains both versions of the signature file required by the
starvation problem in order that the differences can be seen.
Appendix E contains the logs produced by the cluster analysis. Clustering
based on a consecutive alert time differences not exceeding a threshold of
two seconds was performed on each scenario and the results detailed here.
The clusters contain information grouped by alert type such as amount of that
type of alert, time of the first alert and time of the last alert. The notation used
by the prototype is discussed in Appendix E.
5.2 Creating a Basic Signature – Cuppens Attack
In order to detail how the signatures used in the experiments described in
Sections 5.3 and 5.4 were generated, we use the example of producing a
signature for the Cuppens attack and an example of the generic signature
114
discovery process. For simplicity in this case we base the signature discovery
process on the alert stream resulting from the sequential scenario without
background traffic. Table 5.2 shows a cluster analysis summary displaying the
alerts during the scenario, derived from Clusters 6 and 7 from Appendix E.1
(renamed Clusters 1 and 2 for this example).
Observing that in the second cluster is an alert containing the words login and
root, we may wish to investigate the other alerts within a similar time period.
The recent events within an arbitrary period of thirty seconds show multiple
alerts on the same host. Table 5.2 shows the alerts, with the alert name, the
number of alerts, the start time and the stop time displayed for each.
We notice that in the first cluster there are two detections of a ‘finger type’
event, plus some ‘RPC type’ alerts and some ambiguous DYNAMIC-TCP
alerts. We can also see from this that both IDS resident on Host 2 (IDS3 and
IDS4) produce these alerts. From this we can deduce that the chance that this
is a false positive (due perhaps to an erroneously configured alert in an IDS) is
low. Information not included here for brevity, but included in the full detail
of clusters in Appendix E shows that all the alerts have the same source.
Noticing that we have a range of alerts from a single host, we observe that the
timings are close for the alerts in Cluster 1. In Cluster 2, we observe the same
source with a timestamp of approximately ten seconds later than the earlier
alerts. We also notice that again we have two IDS detecting a similar alert,
115
however in this case it is a remote login attempt. Due to the seriousness of a
remote login we can immediately be suspicious of this series of alerts. As
there is seen to be a progression through a finger attempt, RPC alerts and
cumulating in a remote login alert all occur from the same source in a small
period of time, we can assume a connection between them. From this we
might discern an attack has taken place, and after taking whatever action is
appropriate, work at creating a signature to detect this attack in the future.
We note the following properties of the alerts:
• The two finger alerts are related and occur at the same time.
• The RPC portmap type messages appear to be linked as do the
DYNAMIC-TCP messages in the same time period.
• The remote login type alerts are related and occur at the same time.
• All the alerts come from the same host.
• All the alerts occur within fourteen seconds of the initial alert.
From these points, the basic Cuppens signature can be created (without
specific timings or weightings), consisting of three groups of mandatory alerts
containing all the alert types listed above, with default timeouts of ten seconds
and a netmask of thirty-two for a single host. It is anticipated, due to the fact
this is a manual process at this point, that the administrator would likely begin
with default settings for individual alert timeouts, weighting and replication in
order to achieve the best detection chance, possibly in a test environment.
The process above could also be done using graphing by identifying the alerts
manually in the graph, but is more time consuming in this case than the use of
clusters.
116
The general process for discovering an attack and creating a signature is then:
1. Identify a range of alerts which are anomalous (generally through
graphing or perhaps identifying high-priority alerts from the alert
stream). This is normally performed by an administrator noticing an
alert such as the root login alert above, or could be simply a trigger on
those IDS with priorities for alerts, such as Snort. It could also be
identified by using graphing to determine which alerts are not
common in the system.
2. Create a cluster of the alerts over a given time period. This step allows
multiple steps in a multi-step attack such as the Cuppens attack to be
found. Logically, in the Cuppens example, the root login alert is the
culmination of the attack, therefore the target clusters would aim to
encompass alerts before the root login, though in many cases a broad
search before and after would be appropriate.
3. Identify the most conspicuous (or even all) of the alerts within the
clusters generated, to select the range of alerts to be included in a
signature. This is a manual process to identify those alerts that seem
logically grouped, such as the series of alerts above, but could simply
include all alerts in a given cluster. The tuning process (Step 7) aims
to refine the elements and timing of this initial list.
4. Identify the timing of these alerts using graphing or cluster analysis of
the core alerts. This identifies the need for a group or sequence
signature, and also can determine the scope for timeouts for the
individual alerts.
5. Identify the number of alerts within the given time period, to
determine replication factors for each element (this is given in cluster
summaries – such as those in Appendix E).
117
6. Identify the number of hosts affected, if more than one specify the
netmask (once again, this information can be gathered from the
cluster summaries – such as those in Appendix E).
7. Tune the signature based on reapplication of the attack (if available) in
a test environment, or by analysing the performance of the signature
over an indicative time period on real traffic. The tuning of the
signature should focus on the ordering of alerts in a signature, the
impact of replication factors on detection, and whether alerts should
be mandatory or optional together with weightings if appropriate.
Once the basic signature has been analysed and tuned, the other features of a
signature such as priority and what actions should be taken when detected
(such as a new alert) can be determined after the signature has been tuned.
The signature’s impact on other signatures running concurrently (related to
the priority) should also be investigated by analysis of the signatures running
together with a data source containing multiple types of attacks, once again
possibly in a test environment. The usage of the prototype in a test
environment makes tuning of signatures easy, due to the ease of repeatedly
applying signature matching against a database of alerts. The GUI includes
options tailored specifically for modification of signature fields such as
priority for the purposes of such experimentation.
In the future, this will most likely become an automated process enabling an
administrator to select a range of alerts within the alert graph and to ask the
GUI to automatically create a signature.
5.3 Attacks Used in the Experiments
The attacks that were run against the IDS were chosen in order to provide a
range of the types of alerts that could be produced by attacks and to test
different styles of attack. The attacks needed to be as realistic as possible,
therefore all the attacks are generated by tools in use by the ‘hacker’
118
community. For the purposes of this thesis we provide a ‘signature depiction’
which lists the groups and sequences relevant to each attack, without the
additional constraints of timeouts, mandatory/optional, weighting and
replication in order to show the simple pattern of alerts. Each of the basic
signatures was generated using the process outlined in Section 5.2.
The full results, consisting of output produced by the prototype during
experiments with the final tuned signatures (together with the signature file
containing each signature) in each scenario is included in Appendix D.
5.3.1 Attack 1: TCP-Scan
This attack consists of running a port-scanning tool against both target hosts, once alone and
once with an alert spoofing tool used to generate large numbers of alerts in order to attempt to
obfuscate the scan.
Nmap was run against the target machines using the following command
nmap -sS -v -oN nmap.log XXX.XXX.XXX.XXX
The SYN scan should not be logged in many cases, as a SYN scan actually
attempts only to open a connection to a series of specific ports. Individually,
these packets are valid. Together they form an attempt to portscan the target.
If a TCP ACK is received, an RST packet is sent to shut down the connection
immediately. This scan will only be detected as connections to services that
may not exist and an abnormally high number of connections. We expect
multiple NIDS TCP-SCAN alerts over the period of approximately five
seconds, the scanning time of Nmap. If alerts are triggered simply on
connection attempts, multiple connection attempted messages may be
triggered by an Nmap SYN scan.
119
Figure 5.2 shows the basic signature:
ICMP Ping NMAPSCAN Proxy
(8080) TCP-SCAN
TCPScan
Figure 5.2: TCP Scan Signature
The TCP-Scan attack is run in two phases. In Phase 1 a normal scan is run on
both IDS hosts. During this time, an ICMP PING NMAP and a SCAN Proxy
(8080) message are produced by Snort, and a TCP-SCAN alert by Dragon.
These alerts occur randomly, generated at no particular point during the scan
– though are controlled by how many ports are accessed within a certain
period of time inside the engine of each IDS. As such, they are organised into
a group signature to support this randomness.
In Phase 2 the tool Stick is used to perform IDS spoofing against both hosts
whilst scanning them. The Stick tool generates a large number of packets
conforming to random signatures from the Snort ruleset, in order to generate
large numbers of false positive alerts. The aim of this phase is to attempt to
obfuscate the TCP-Scan alerts within a vast range of erroneous alerts in order
to test whether the detection methods can still detect the TCP-Scan. This
signature does not include a component to detect the random alert
component of the Stick tool, as a random alert cannot be expressed in our
model. As such, the scan should be detected across both IDS during this
time, but without being affected by the random alerts from the IDS.
120
5.3.2 Attack 2: Exploits
This attack consists of three exploit tools run against both hosts.
Three different tools were run in this attack:
• the ucd-snmp exploit which aims to compromise certain SNMP
implementations;
• the Cisco border routing exploit, which aims to perform a buffer
overflow on certain versions of the Cisco OS; and
• the Vetescan scanner, which tests for a wide range of vulnerabilities by
connecting to different services and requesting version information in
order to determine if vulnerable or unpatched services are available.
The exact nature of the alerts to be generated here is based purely on the data
gathered during testing, as the IDS do not appear to have any specific alerts
for any one of the exploits executed. However, two distinct patterns of alerts
became apparent when running the exploits independently of any other
attacks. The first was at least one BAD TRAFFIC loopback traffic alert from
Snort, after which two very closely timed alerts appeared in no particular
order: an RPC portmap listing alert, and an SCAN Proxy (8080) alert. After these
alerts there was always an SSH:VERSION-1 alert from Dragon. From this
information, two signatures were created, one for the middle step of two
randomly occurring alerts, and one overall signature in a sequence in order to
capture the entire set of attacks. The two signatures are shown in Figure 5.3.
121
BAD TRAFFICloopback traffic
Exploit Step 2Detection
SSH:VERSION-1
RPC portmaplisting
SCAN Proxy(8080) attempt
Exploit Step 2 Detection
Exploit Full
Figure 5.3: Exploit Attack Signatures
It should be noted that the RPC portmap, SCAN Proxy and SSH alerts are
most likely generated by Vetescan, while the BAD TRAFFIC alert is from the
Cisco Border routing exploit. Neither Snort nor Dragon seems to have
produced an alert from the ucd-snmp exploit.
5.3.3 Attack 3: Cuppens Attack
This attack is comprised of six steps intended to subvert NFS to access files as user root
and using this access to enable remote root logins.
As noted in Chapter 2, recent work by Cuppens [11, 13, 34] has used a
specific multi-stage attack in order to test detection algorithms. Due to the
close relationship of our work to Cuppens, it is a natural step to attempt to
perform the same attack in order to gauge the results obtained by our system
as compared to that of Cuppens. Cuppens notes that Snort detected five
stages of the attack in [34], however, he does not note the names of the five
alerts this produced. We would expect five alerts generated by Snort to
correspond to five stages in the Cuppens attack (noting that Snort does not
produce an alert for Step 5, below). We would also expect multiple alerts from
Dragon which could correspond to multiple stages in the Cuppens attack.
Unfortunately Cuppens does not specify any tools or scripts used in order to
122
produce the set of alerts detected by Snort and E-trust in his work, although
the published steps to the attack are:
Step 1: finger root,
Step 2: rpcinfo <target>,
Step 3: showmount <target>,
Step 4: mount directory,
Step 5: cat “++” > .rhost,
Step 6: rlogin <target>.
On our systems, these commands did not work, presumably due to different
versions of software to that running on Cuppens experimental machines. On
our Redhat Linux 7.2 machine the modified script to run the Cuppens attack
was:
finger [email protected] rpcinfo -p xxx.xxx.xxx.xxx showmount xxx.xxx.xxx.xxx mount -t nfs xxx.xxx.xxx.xxx:/root /mnt/remote -o rw echo ++ | cat - > /mnt/remote/.rhost umount /mnt/remote rlogin xxx.xxx.xxx.xxx -l root As per Cuppens, we would expect Snort to detect five out of the six steps and
Dragon to detect multiple steps, although the particular alerts to be genera ted
by Dragon were unknown.
Unlike many of the other signatures, the Cuppens attack produces a
predictable number and composition of alerts when the attack is performed.
The alerts produced during the sequential scenario are included below for
Some major accomplishments of our architecture and use of the prototype
specifically for Attack Detection have been identified, and are discussed in
Sections 5.8.1 through 5.8.7.
5.8.1 Multiple Machine Attack Detection
We have accomplished the detection of signatures across multiple analysers.
In our experiments, this is manifested in two ways:
1. Attack Description using signatures from different IDS
2. Attack Detection across two machines using alerts from both.
157
Both of these methods use the fact that signatures are essentially host-
independent, with the only requirement being whether alerts should be
filtered based on the netmask component.
5.8.2 Signature Detection of Multiple Attacks
As can be seen in the examples in Section 5.5, we can detect multiple
signatures at the same time using our architecture and algorithm. While
currently alerts can be lost when many alerts are observed or they occur out
of sequence, this can be eliminated by use of the multiple-fit algorithm
described in Chapter 3.
5.8.3 Detection of Multiple Stages of an Attack
We can detect multiple instances of the same attack in different phases, as
well as multiple attacks in the same phase on different hosts. Using the nature
of our signatures, we can also have component signatures describe individual
phases of a full attack, so that we can observe if attacks have been completely
successful.
5.8.4 Distinction of Single and Multi-host Attacks
Using the netmask component, we can distinguish alerts based on their IP
address and only allocate those which are relevant to that signature. The IP’s
of each alert are stored in the ASSV and each alert is printed to screen when
the alert is fired, therefore an administrator can determine which hosts have
been effected easily. This information is also stored in the case an alert is
dropped.
5.8.5 Techniques to Discover Signatures
Using the clustering and graphing techniques, there is an easy process to
creating a signature from a set of alerts. This is described in Section 5.2, and
can be used for any type of attack.
158
5.8.6 Correlation Between Different Analysis Methods
Using graphing, clustering and signatures, we have created a powerful
collection of integrated tools for alert analysis, attack detection and signature
discovery. With all these tools in one simple interface, identification of attacks
and administration of IDS can be made significantly easier.
5.8.7 Investigation of matching algorithms
One particular aspect of alert correlation missing from current research
particularly in signature systems, is investigation into what matching
algorithms are used for those systems using stateful (or multi-stage) matching.
This prototype and experimental process can be used to test the effectiveness
of matching techniques against a range of attacks and with a range of
signatures in different scenarios. In our case, we managed to observe
starvation of signatures based on the single-fit algorithm, as well as dropped
alerts based on the elimination of old ASSV’s. The next logical step is to start
experiments based on the multiple fit algorithm in further work.
5.9 Summary
The result of the testing of the prototype is that we are able to identify large
and small scale attacks of a fixed pattern using signatures. This analysis is
assisted by an experimental platform with allows for signatures to be specified
and successively refined using weighting and optional components.
Replication also allows for user-configurable association of numbers of alerts
with a single signature, to handle situations such as a DoS attack where a large
number of alerts may be present that can all be attributed to a single case of
an attack. The parameters and constraints are all useful in the specification of
our range of signatures, and allow for highly configurable signatures to suit
the requirements of an administrator.
The next chapter, Chapter 6, gives conclusions and commentary on the
results shown here, as well as directions for future work and improvements
on the current testing procedure and the prototype.
159
C h a p t e r 6
CONCLUSION
Chapter 5 described the results of experiments using the prototype system for
attack detection and alert analysis. Here we conclude the thesis by evaluating
the results of the experiments: cataloguing the strengths and weaknesses of
our approach; proposing future work both in evaluating the system; and
suggesting future research directions.
6.1 Evaluation of Results
The most common items of alert information available from IDS, especially
NIDS, are: source, destination, time and classification/name. In our system,
we can also add information about the sensor itself (sensor name) to this list.
While source and destination can be spoofed in an IP environment, the way
in which they are spoofed can be informative in itself. The simplest way to
look for information within a data set such as alerts is to look for clusters, or
abnormally high sets of alerts within a given range of an attribute. One
problem with this is that an attack like Stick can generate a massive number of
dummy alerts. An advantage of this is that, generally, attacks like Stick will
generate different sets of logs on different IDS. In this manner, by using
overlapping sets of IDS, and having IDS reinforce or negate each others data,
we can reduce the effect of IDS flooding tools.
6.1.1 Analysis Methods
Where feasible, signatures allow for very quick and automatic detection of
patterns of alerts indicating multi-stage attacks. This, combined with ease of
use, means that signatures are an obvious choice if the goal is to ease
administrator burden.
160
While the graphing functionality does not have the visualization capabilities of
other research efforts such as Hummingbird [50] or NIVA [51], the interface
does not require special training to use and can be configured to display other
information if so desired. The current graphing method is very much an alert -
centric approach, in keeping with the goal of our research, but could be very
useful using hosts as a primary axis and colouring for the different alert types.
For our purposes alert type, host and number of alerts were the most useful.
Clustering, while useful, is best used when parameters of and constraints on
clustering are known, these parameters being derived from previous analysis
using graphing.
6.1.2 Prototype
In our prototype, the IDMEF DTD was flexible enough to express the
information provided by Snort and Dragon. The conversion of alert formats
was easily performed by the Alert Agents. In fact, most of the information
included by more descriptive loggers (such as Snort) like priority, detailed
timing information and references to background information is not used at
this time. The speed and memory requirements of most methods of handling
XML, such as DOM and SAX, were avoided by treating the XML format as
plain text. This lead to major improvements in speed and memory usage on
both the Alert Agent and Control Unit. At this early stage of correlation, a
simpler format than IDMEF could be used, however IDMEF is an
appropriate standard and provides the ability to contain large reserves of
information, which could be useful in more complex inductive processes.
6.1.3 Signatures
The signature system, while simple, suffers from some significant drawbacks.
The first of these is in the relative complexity of composite signatures and the
computational load on the system. In order to aid in future analysis, it would
be more efficient to allow for basic signatures to include groups and
161
sequences at once to eliminate the requirement of producing a different
signature for each group or signature relationship required.
Most current research either assumes a single match situation, or ignores the
problem of duplicate alerts and signatures contending over the same alert or
event. The impact of these situations on pattern matching and correlation
should be investigated in other systems such as that used by Cuppens or
Debar and Wespi, as attackers are unlikely to work in convenient patterns. An
issue that is discussed in recent work by Cuppens [11, 35] but needs more
research in other correlation systems is the impact of out-of-sequence alerts
and the concept of missing alerts. These problems are addressed in our
concept of optional alerts and Cuppens concepts of chronicles and virtual alerts.
The single-fit algorithm shown here is adequate for the testing of our proof-
of-concept prototype, but a more comprehensive implementation which
allows for multi-fit matching patterns would be required to provide the best
performance in terms of detection. The tradeoffs involved in allocating alerts
to signatures in our current model can be improved with the implementation
of multi-fit. This includes issues such as priority handling, allocation of
discarded replicated alerts and timeouts. Indeed, the algorithms for timeouts
and replicated alerts would need to be less complicated as a hierarchical
approach would be used, which automatically optimises the allocation of
alerts. This was outside the scope of this thesis however. The new version of
Snort (2.0) deals with issues much like those encountered here in terms of
signature matching priority and optimisation. It applies these concepts to
strings to detect a best match to multiple options in packet content, rather
than patterns of alerts.
The focus on cause and effect in systems can distract from the primary focus
of detection in the Intrusion Detection environment. While specifying the
precursor events and consequential events in an event processing system leads
to greater informational content in the detection of a given set of events, the
162
specification for this can be difficult and time consuming. This leads to less
direct application to commodity systems as this form of information is not
readily available for most commodity signature sets. However, modern
systems allow for greater specification in the range and abilities of their
signatures, and also allow for greater documentation on specification and
syntax than was typical previously.
The impact of priority handling and allocation of discarded alerts needs to be
investigated further by more testing using more signatures and concurrent
signature matching. If single-fit matching is continued, the best system using
these features should be determined. This will be a function of the false
positive and false negative rates of different settings for the matching
algorithm as well as specifying a range of desirable outcomes for the matching
of alerts to signatures, such as the desired operation for the propagation of
alerts and the features of candidate signatures which affect this.
A core result of testing the signature system was the realisation that little work
has been done on how to prioritise alert handling and the application of this
to different attack types. Also, more work needs to be done to classify alerts
in terms of the stage of attack they reside in, in order to ease the task of
specifying signatures. The impact of multiple-fit matching on the
prioritisation of alerts (and vice-versa), the minimisation of alert propagation
and the easier determination of best-fit need to be investigated. Multiple fit
matching also allows for alerts to be potentially held in reserve for higher
priority alerts, a concept not dealt with here, but important in further testing.
There is a definite niche for simple signatures to be used with commodity
systems. The current research (aside from that by Valdes and Skinner and
Cuppens et al.) in general either focuses on abstract event-based models, or
does not use commodity IDS. The differences between our approach and that
of Valdes and Skinner and Cuppens were described in detail in Chapter 2, but
163
are centred in our focus on commodity systems, simple signatures and
additional tools for analysis.
6.1.4 Test Network
The test network was designed with the idea of properly testing correlation
over heterogeneous IDS. In this role it performed well, however some
modifications could be made. The testing could have been more
comprehensive if a hub and a switch were used in two sets of tests, in order
to test the IP matching functionality of the system. Running two IDS on a
single host is also an area that could have been improved. With a more
extensive testing infrastructure, the two IDS would be resident on separate
hosts each sniffing the traffic directed at a target host. A simple diagram of
the proposed new network is shown Figure 6.1.
Target Host 1
Hub
Switch
Snort Dragon
Target Host 2
Hub
Snort Dragon
Attacking Host
Figure 6.1: Proposed New Test Network
The switch still segments traffic for the two target hosts, however both IDS
are placed on hubs connected to each target host in order to allow each to
separately analyse the traffic for that host. The switch would be replaced by a
164
hub on those experiments where the IDS are expected to have access to all
traffic from the attacking host.
Another identified issue was if an error occurred to the packet, such as an
ICMP error message, or IP header length error (common if Tcpdump is not
configured to log all packet data), Snort and Dragon would use a ‘first past the
post’ method and alert based on this protocol error rather than the attack
within the packet itself. This meant that in certain circumstances the log
would be completely filled with ICMP error messages from Snort or IP-
length mismatch errors in Dragon, even when attacks were present in the
traffic. Unfortunately, this could not be configured to be ignored in the IDS
without losing alerts required for analysis of attacks such as the DoS attack
and was only avoided by careful implementation of the test network.
6.2 Future Work
6.2.1 Analysis Engine
Further research directions regarding alert based correlation and analysis for
attack detection are as follows:
• Alert Handling Streamlining
The first of these is the streamlining of alert processing by incorporation
of sequence and group signature composition syntax into a single
signature thus avoiding the need for alert stream reinsertion. This will
require the processing system to be redesigned for a more efficient
approach, using multiple levels of alert processing.
• Additional Alert Sources
The processing engine should be enabled to handle alerts from multiple
different alert sources, such as HIDS and firewalls. This will require that
the processing engine be tolerant of the lack of certain alert features such
165
as source IP or target port, and yet also be able to correlate items such as
target IPs into DNS and host names for correlation between NIDS and
HIDS.
• Plan recognition
As shown in research such as Cuppens recent work, a logical extension of
correlation is to perform plan recognition, and allocate the alerts to a
model of intrusion, such as that provided by NATO in the time axis
intrusion model [7]. Plan recognition is different from pure correlation in
that it focuses on finding the intent and future actions of an intruder, and
must be able to extrapolate and interpolate intrusion information from
given data. It resides in the induction stage of the alert analysis model and,
as such, is a natural future direction for this work.
• Multiple-fit signature matching
The multiple fit system described in Chapter 4 will allow for extra features
to be included in matching and will also ideally allow for far greater
accuracy in detection than possible with the current single-fit approach.
However, the implementation of all the concepts involved such as roll-
back, forward prediction and multiple threads of execution makes this a
complex algorithm to implement. Nonetheless, it is the logical extension
of the current algorithm. The improvements in results should make the
effort worthwhile.
6.2.2 Prototype Modifications
Some direct additions to the prototype have been identified during
development and testing, but were either not directly relevant to the focus of
alert correlation and analysis, or were not deemed practical in the timeframe
of this research. These are:
166
• The addition of communication proxies and information channels
which will be dealt with in part by the IDXP protocol, which will be
added to our prototype when an appropriate implementation is
available. Another solution could be use of IDIP [52] for
communication and data management, as a transport layer between
the IDS agents and the Control Unit. Our simple communication is
insecure, but should be an adequate in many cases, especially in
medium and large sized implementations which should already use
secure communication channels (such as Ethernet networks dedicated
to IDS ).
• Implementation in real-time: All the techniques used here could in
essence be applied in real-time. Essentially, all that would be required
is a mechanism to feed information to the processes running on the
console in real-time and a buffer storing recent messages. Signature
systems could iterate through the matching process as they do
currently, but the graphs would be updated periodically with new
information. Clusters would operate as normal on the stored data as
ordering and comparison would be difficult, though not impossible,
to implement in real-time.
• Alert Analysis Model Stages 1 and 2: The function of alert reduction
and aggregation can be implemented at the Control Unit component
allowing for erroneous or potentially related alerts to be deleted or
merged before the singular alerts are entered into the database. This
would reduce the load of storage and analysis of a large number of
alerts.
• Instant Alert Messaging: The ability to specify a response as an
immediate alert to the administrator becomes useful in the event of a
167
migration to real-time analysis, but can also be useful in an off-line
context if desired by an administrator.
• Response Mechanisms: In the case of a signature fired in real-time,
the handling of the alert could be configurable for the signature that
has fired. Common responses could include immediate alerting to the
console as well as TCP connection shutdown, automatic firewall
configuration and access control modification. In most cases the alert
corresponding to the fired signature would still be logged to the
database. Obviously these responses are ineffective in an off-line
scenario.
• Automatic generation of signatures based on selected alerts from a
cluster or graph, as described in Section 5.6, would consist of the
selection of portions of the graph for specification as a signature.
These could then be analysed by the system and an appropriate
signature describing these alerts produced.
6.2.3 Signature System
Some functionally unimportant, but nonetheless useful improvements
identified during testing and development are:
• Redefining the current flat file into a more comprehensive XML
representation could allow for an easy interface to specify signatures
as well as more easily verifiable signature structure by the use of a
DTD to describe the format. This melds well with the model used in
the ADeLe detection language, and work would naturally include
more of the functionality included in this language over and above
that available in the current prototype.
• A focus on the algorithms for matching, rather than the specification
of the language to specify events, could lead to an abstraction oriented
168
algorithm for both events and alerts, which could be equally well used
in both. This system needs to take into account the current levels of
specification of signatures, however, in order to properly match the
algorithm to possible implementations.
• The concept of a knowledgeable attacker who attempts to disguise his
attack has been discussed in very little detail in signature-based
systems, whilst it has been a significant issue in anomaly-based
systems. Signature systems should be able to tolerate out-of-sequence
items even when the ordering of items is considered important. This
will require further testing of the use of optional components, and
perhaps the use of fuzzy logic implemented in a process using a
multiple-fit signature system, as the multiple-fit system should allow
for forward projection and best-fit matching to a range of candidate
signatures.
• Configuring the GUI to configure items such as duplicate attack
detection behaviour and alert propagation behaviour is useful for
repeated testing of algorithms. The configuration of priority via the
GUI has been implemented. The addition of these options, especially
with a GUI facility to alter the signature file, would make iterative
testing far easier in the future.
6.2.3 Analysis System
The graph processing system is currently a static device with little
configurability. The next phase of development in this area would be to have
multiple modes of operation and user configurable displays. The new displays
of the graph system should be
• Graphing with/without alerts attributable to signatures, in order to
provide a less cluttered display, and to allow for analysis on a smaller
dataset after signature-matched alerts have been removed.
169
• Graphing solely of those alerts matched to signatures, to display the
alerts within signatures. This is useful in the case of DoS, scanning or
spoofing attacks.
• Graphing of the alerts in clusters to allow for easier analysis of those
clusters.
• Additional drill-down feature: In the case of multiple alerts in a second,
a graph of a specific item could be displayed with source/target and
alert type.
These are outlined as the new features in the graphing utility most useful at
this time. When the system is implemented in real time, the graph itself can be
updated easily and should be performed periodically, perhaps once every five
seconds.
6.2.4 Testing
There are three areas of testing that have yet to be explored in sufficient
detail. These are:
• Effect of large range of attacks on the system.
The current suite of attacks was chosen to be representative of a range of
different scenarios. However, particularly with the addition of HIDS into
the correlation system, testing should be performed using attacks that
leverage these different data sources which requires different attacks.
Also, there is a wide variety of attack tools available: the specification of
signatures to detect the patterns produced by these tools and subsequent
testing of these signatures is prudent at this time.
170
• Determining error rates.
While the signatures do work at detecting the attacks in each one of the
scenarios, more work must be done on determining the capacity for error
of the system when constraints are modified. This is especially so in the
cases of optional and weighting constraints which can be used to increase
the detection rate, likely to be at the expense of false positives. This could
well be done in conjunction with the testing on new attacks outlined
above. Of particular interest is the relationship between detection rates
and false detection rates in our system, due to the dependence on IDS
providing accurate alerts. In order to properly test this system however,
techniques used in our testing such as DoS and spoofing would need to
be carefully controlled, as these tools can provide different levels and
distributions of alerts depending on the load on the IDS at that point in
time.
• Testing the system against other testing methodologies, such as the
DARPA IDS evaluation tests.
There has been work involved in evaluating the effectiveness of IDS such
as that performed by DARPA in 1998 and 1999. While all of these focus
on the results of IDS, not correlation systems, the use of a system such as
ours may be useful in detecting multi-step attacks otherwise missed by the
IDS used in these tests.
• Testing other algorithms.
One unexpected benefit of our system and prototype is the division of
labour between the different components of the system. This allowed
algorithms to be implemented and tested quickly and effectively, without
extensive redesign of the system. One of the exciting possibilities is the
use of our prototype to enable the testing of a wide range of analysis
171
techniques, in order to gauge the comparative effectiveness of each on a
given set of data. As little data has been published on algorithms for
analysis of signatures with states, this is a particularly useful future avenue
of research.
• Testing the scalability of the system.
In determining the scalability of the prototype, mainly in the area of
signature analysis, there are multiple factors involved including:
§ Scalability of sequences versus groups.
§ Scaling of systems with high replication factor.
§ Scaling of IDS.
§ Scaling of numbers of alerts in active signatures versus processing
time.
§ Scaling of active signatures.
§ Scaling of active alerts.
These tests would be best performed when the introduction of HIDS, other
devices and the implementation of a multi-fit signature algorithm have been
completed, in order to reduce the large amount of re -testing that would be
required after these features have been included.
6.3 Summary
In the thesis, we have encompassed the current work in terms of IDS alert
correlation and analysis and described the core functionality of major
competing research systems.
172
We have contributed a simple specification system for signatures as well as
two proposed algorithms for processing alerts for the signature system, and
detailed the implementation of the single-fit approach.
We have also described how simple clusters and graphing can be used to
enhance the capabilities for analysis of an administrator, and how these can be
used to reinforce or supplement the signature system used in our prototype.
We have detailed the design and implementation of a proof-of-concept
prototype implementing the concepts and algorithms put forward and
presented a testing methodology that can be used to verify the operation of
an alert analysis system.
Finally, we have included conclusions on the results obtained through the
research and detailed the path by which the prototype could be improved.
The end result is a comprehensive analysis of the challenges and some
solutions to the problem of alert analysis and correlation. The challenge now
is to improve on this work, by incorporating the proposed added features and
testing the results in order to ensure that a simple yet powerful system for the
analysis of intrusion alerts by a correlation system can be provided.
173
B I B L I O G R A P H Y
[1] McHugh, J., Intrusion and Intrusion Detection. International Journal of Information Security, 2001. p. 14-35.
[2] Bace, R. and P. Mell, Intrusion Detection Systems. NIST Special Publication on Intrusion Detection Systems. 2001.
[3] Lundin, E. and E. Jonsson, Some Practical and Fundamental Problems with Anomaly Detection, in Proceedings of the fourth Nordic Workshop on Secure IT systems (NORDSEC'99). 1999.
[4] Kahn, C., et al., A Common Intrusion Detection Framework. Submitted to the Journal of Computer Security, 1998.
[5] NATO, NATO Report on Intrusion Detection. 2001. [6] Allen, J., et al., State of the Practice of Intrusion Detection Technologies,
Pittsburgh, PA: Carnegie Mellon Software Engineering Institute. 2000.
[7] Coolen, R. and H.A.M. Luiijf, Intrusion Detection: Generics and State of the Art. 2002, Research and Technology Organisation (RTO), North Atlantic Treaty Organisation (NATO): Cedex, France. 2002 p. 50.
[8] Morin, B., et al. M2D2: A Formal Data Model for IDS Alert Correlation in RAID 2002. 2002.
[9] Erbacher, R.F. and B. Augustine. Intrusion Detection Data: Collection and Analysis, in 2002 International Conference on Security and Management (SAM '02). 2002. Las Vegas, NV.
[10] Patton, S., W. Yurcik, and D. Doss. An Achilles Heel in Signature-Based IDS: Squealing False Positives in SNORT in 4th International Symposium on Recent Advances in Intrusion Detection (RAID 2001). 2001. Davis, CA.
[11] Cuppens, F., et al. Correlation in an intrusion detection process, in Internet Security Communication Workshop (SECI'02). 2002. Tunis.
[12] Carey, N., G. Mohay, and A. Clark. IDS Interoperability and Correlation Using IDMEF and Commodity Systems, in 4th Internation Conference of Information and Communications Security (ICICS). 2002. Singapore.
[13] Cuppens, F. Managing Alerts in a Multi-Intrusion Detection Environment, in 17th Annual Computer Security Applications Conference (ACSAC'01), December 10 - 14, 2001. New Orleans, Lousiana.
[14] Tung, B. The Common Intrusion Specification Language: A Retrospective, in DARPA Information Survivability Conference and Exposition (DISCEX). 2000. Hilton Head, SC.
[15] D.Curry, H.Debar, Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition, http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-10.txt, accessed 17 th August, 2003
[16] BEEPCore.org, Home - beepcore (BEEP Home Page), http://www.beepcore.org/beepcore/home.jsp, accessed 17th August, 2003.
174
[17] Goldman, R.P., et al. Information Modeling for Intrusion Report Aggregation, in 2nd DARPA Information Survivability Conference and Exposition (DISCEX II). 2001. Anaheim, CA.
[18] Michel, C. and L. Me. ADeLe: An Attack Description Language for Knowledge-based Intrusion Detection, in 16th International Conference on Information Security. 2001.
[19] Cuppens, F. and R. Ortalo, LAMBDA: A Language to Model a Database for Detection of Attacks, in Recent Advances in Intrusion Detection, Third International Workshop (RAID 2000), 2000. p. 197-216.
[20] Pouzol, J.-P. and M. Ducasse. From Declaritive Signatures to Misuse IDS, in 4th International Symposium on Recent Advances in Intrusion Detection (RAID 2001). 2001. Davis, CA.
[21] Vigna, G., S. Eckmann, and R. Kemmerer. The STAT Tool Suite, in DARPA Informa tion Survivability Conference and Exposition (DISCEX). 2000. Hilton Head, SC.
[22] Lippmann, R.P., et al. Evaluating Intrusion Detection Systems: the 1998 DARPA Off-Line Intrusion Detection Evaluation, in DARPA Information Survivability Conference and Exposition (DISCEX). 2000. Hilton Head, SC.
[23] Eckmann, S.T. Translating Snort rules to STATL scenarios, in 4th International Symposium on Recent Advances in Intrusion Detection (RAID 2001). 2001. Davis, CA.
[24] Doyle, J., et al. Event Recognition Beyond Signature and Anomaly, in 2001 IEEE Workshop on Information Assurance and Security. 2001. United States Military Academy, West Point, NY.
[25] Doyle, J., et al., The Architecture of MIATA: A Tool for Monitoring, Analysis and Interpretation. 1999, Laboratory for Computer Science, MIT: Boston, MA.
[26] Lin, J. -L., X.S. Wang, and S. Jajodia. Abstraction-Based Misuse Detection: High-Level Specifications and Adaptable Strategies, in Proceedings of The 11th Computer Security Foundations Workshop. 1998.
[27] Perrochon, L., et al. Enlisting Event Patterns for Cyber Battlefield Awareness, in DARPA Information Survivability Conference and Exposition(DISCEX). 2000. Hilton Head, SC.
[28] O'Donnell, S., Network Management: Open Source Solutions to Proprietary Problems, in Proceedings of the 28th SIGUCCS Conference on User Services. 2000, Richmond, Virginia, USA. p. 208-217.
[29] Ohsie, D.A., Modeled Abductive Inference for Event Management and Correlation, in Graduate School of Arts and Sciences. 1998, Columbia University: New York.
[30] Yemini, S., et al., High Speed & Robust Event Correlation, in IEEE Communications Magazine. 1996.
[31] Perrochon, L., et al. Event Mining with Event Processing Networks, in The Third Pacific-Asia Conference on Knowledge Discovery and Data Mining. 1999. Beijing, China.
175
[32] Ning, P., Y. Cui, and D.S. Reeves. Analyzing Intensive Intrusion Alerts via Correlation, in 5th International Symposium on Recent Advances in Intrusion Detection (RAID 2002). 2002. Zurich, Switzerland.
[33] Tidwell, T., et al. Modeling Internet Attacks, in IEEE Workshop on Information Assurance and Security. 2001. United States Military Academy, West Point, NY.
[34] Cuppens, F. Alert Correlation in a Cooperative Intrusion Detection Framework, in 2002 IEEE Symposium on Security and Privacy (S&P '02). 2002.
[35] Cuppens, F., et al. Recognizing Malicious Intention in an Intrusion Detection Process, in Second International Conference on Hybrid Intelligent Systems. 2002. Santiago, Chili.
[36] Debar, H. and A. Wespi. Aggregation and Correlation of Intrusion-Detection Alerts, in 4th International Symposium on Recent Advances in Intrusion Detection (RAID 2001). 2001. Davis, CA.
[37] Valdes, A. and K. Skinner. An Approach to Sensor Correlation, in 3rd International Symposium on Recent Advances in Intrusion Detection (RAID 2000). 2000.
[38] Valdes, A. and K. Skinner. Adaptive, Model-Based Monitoring for Cyber Attack Detection, in 3rd International Symposium on Recent Advances in Intrusion Detection (RAID 2000). 2000.
[39] Valdes, A. and K. Skinner. Probabilistic Alert Correlation, in 4th International Symposium on Recent Advances in Intrusion Detection (RAID 2001). 2001. Davis, CA
[40] Krugel, C. and T. Toth. Distributed Pattern Detection for Intrusion Detection, in Network and Distributed System Security Symposium. 2002. Catamaran Resort Hotel, San Diego, California:
[41] Cuppens, F., et al. Correlation in an intrusion detection process, in S´Ecurit´e de la Communications sur Internet (SECI02). 2003. Tunis, Tunisia.
[42] Scott, S.J., Threat Management Systems: The State of Intrusion Detection. 2002. Snort Web Page http://www.snort.org/docs/threatmanagement.pdf
[43] Doyle, J., et al. Agile Monitoring for Cyber Defense, in 2nd DARPA Information Survivability Conference and Exposition (DISCEX II). 2001. Anaheim, CA.
[44] Atallah, M.J., et al., Database Support for Intrusion Detection. 2000, CERIAS.
[45] Liu, G. and M. Russina. ECA + SQL: A Practical Event Correlation Approach, in International Conference on Communications Technology. 2000.
[46] Erbacher, R.F., X. Teng, and S. Pandit. Multi-Node Monitoring and Intrusion Detection, in IASTED International Conference on Visualization, Imaging and Image Processing. 2002. Malaga, Spain.
[47] Erbacher, R.F. and K. Sobylak. Improving Intrusion Analysis Effectiveness, in 2002 Workshop on Computer Forensics. 2002. Moscow, ID.
[48] Ranum, M., Experiences Benchmarking Intrusion Detection Systems. 2001, NFR Security, Inc.
176
[49] Lundin, E., H. Kvarnstrom, and E. Jonsson. A Synthetic Fraud Data Generation Methodology, in 4th International Conference on Information and Communications Security (ICICS 2002). 2002. Singapore, Singapore.
[50] Erbacher, R.F.F., D. Visualization in detection of intrusions and misuse in large scale networks, in Proceedings of the IEEE International Conference on Information Visualization. 2000.
[51] Nyarko, K., et al. Network intrusion visualization with NIVA, an intrusion detection visual analyzer with haptic integration, in HAPTICS 2002. 2002.
[52] Schnackenberg, D., K. Djahandari, and D. Sterne, Infrastructure for Intrusion Detection and Response, in Proceedings of the DARPA Information Survivability Conference and Exposition (DISCEX). 2000. Hilton Head, SC. p. 3-11
A P P E N D I C E S
Note that in the logs and diagrams below, the names re ferring to the different
IDS do not correspond to those in the text. The references in the text were
modified for readability. The reference ‘IDS1’ in the text corresponds to ‘ids2-
snort’ in the logs, ‘IDS2’ in the text corresponds to ‘ids2-dragon’ in the logs,
‘IDS3’ in the text corresponds to ‘ids3-snort’ in the logs and ‘IDS4’ in the
text corresponds to ‘ids3-dragon’ in the logs.
The appendices included for reference are:
APPENDIX A: IDMEF Model and Example Messages
APPENDIX B. Database Schema
APPENDIX C. Full Graphs of Each Scenario
APPENDIX D. Signatures and Experimental Results
APPENDIX E. Results of Cluster Analysis
179
Appendix A: IDMEF Model and Example Messages
This section shows the format of IDMEF messages that are produced by Snort and Dragon during the attacks. The Snort message is based on Version 0.5 of the IDMEF DTD, which is no longer publicly available, while the Dragon Version uses 1.0, which can be found at http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-10.txt The mismatch between versions does not hamper the operation of the XML-DBMS portion of the prototype, as the information actually used by Snort in IDMEF 0.5 conforms to the requirements of IDMEF 1.0. A diagram of the model (minor sections incomplete) to illustrate the general connections of various fields in an IDMEF message is shown as figure A.1.
2 A PowerPoint graphic of the IDMEF Model by David Chizmadia of Promia, Inc. This
diagram can be found at SiliconDefense at http://www.silicondefense.com/idwg/IDMEF-Model.zip
181
A.1 Example Snort Message (indented for presentation)
The message below is an ICMP Ping NMAP message generated from Snort. Points to note are the sensor (ids3), the time (4:49pm on 23/09/2002), the Source IP (131.181.6.94) and the Target IP (131.181.6.92). Also of note is the <url> field filled in with the web reference for information on the attack, in this case from whitehats.com. <?xml version="1.0"?> <!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.5//EN" "/etc/snort/idmef-message.dtd"> <IDMEF-Message version="0.5"> <Alert ident="1" impact="unknown"> <Analyzer analyzerid="ids3-snort"> <Node> <name>ids3</name>
The example below was generated by the Dragon IDMEF conversion tool. This particular message is generated by the HEARTBEAT alert generated by Dragon on startup (note the ‘ident’ field is ‘1’). As such, it has no source or target. It was generated on host IDS2. It was also generated using a different IDMEF DTD from Snort (1.0 as opposed to 0.5 for Snort), indicated at the beginning of the message. <?xml version=\"1.0\" encoding=\"UTF-8\"?> <!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v1.0//EN” "file:/temp/idmef-message.dtd"> <IDMEF-Message version="1.0"> <Alert ident="1" impact="unknown"> <Analyzer analyzerid="ids2"> <Node> <name>ids2</name> </Node> </Analyzer> <CreateTime ntpstamp=0xc1633dc7.0x00000000> </CreateTime> <Classification origin=\"vendor-specific\"> <name> [HEARTBEAT] </name> <url> none </url> </Classification> <Source> <Node> <Address category=\"ipv4-addr\"> " + '\n' <address> 0.0.0.0 </address> </Address> </Node> </Source> <Target> <Node> <Address category=\"ipv4-addr\"> " + '\n' <address> 0.0.0.0 </address> </Address> </Node> </Target> </Alert> </IDMEF-Message>
183
Appendix B. Database Schema
In Figure B.1 below is the schema for the database, which can be related to
the IDMEF DTD. Refer to Appendix A for the node names and references
to items in the IDMEF message. Not all items are represented in the IDS
IDMEF messages, some aspects of the database have been constructed to
conform to Version 1.0 of the IDMEF Specification, which is far more
expressive than the simple messages used in these experiments by Snort and
Dragon. The names of each element correspond to the names of elements
within the IDMEF DTD, therefore only those items of interest for the
database are described in detail. Also, in the interests of brevity, only a sub-set
of the entire database structure is provided – those tables of direct use in the
experiments, although using the entire schema a complete IDMEF message
may be stored.
Item Name Item Type Notes alertdbid bigint not null key ident character varying (255) not null impact character varying (255) action character varying (255)
Table B.1: Alert Table
Table 1 describes the primary table of the alert, the alert table. This table stores
the alertdbid, or the unique identifier in the database for each alert. ident is the
internal IDS id of the alert. Alertdbid is used as a key by the majority of tables
aside from those linking to sub-tables of the alert.
Item Name Item Type Notes alertdbid bigint not null from alert table type character varying (255) not null meaning character varying (255) not null content character varying (255)
Table B.2: AdditionalData
184
Table 2, AdditionalData is used to store information that is outside the scope
of the IDMEF DTD. In our case, this is used by the Dragon plugin to store
the packet dump produced with each alert Dragon generates.
Item Name Item Type Notes nodeid bigint not null from to node table ident character varying (255) vlanname character varying (255) vlannum character varying (255) address character varying (255) not null netmask character varying (255)
Table B.3: Address
Table 3, Address stores the basic structure of an address element, however
multiple addresses may be associated with a node, therefore it uses the nodeid
as a key.
Item Name Item Type Notes alertdbid bigint from alert ident character varying (255) from alert analyzerid character varying (255) from analyzerid name character varying (255) from classification time character varying (255) from createtime source character varying (255) from source target character varying (255) from target targetport character varying (255) from target
Table B.4: Alert_table Table
Table 4, Alert_table is used to store the summary information of the other
tables, in order to speed later analysis. As this table contains all the relevant
information used in correlation at this time, in practice the other tables are
only used when additional data is needed for informational purposes. In this
case, we assume only one source and target as neither Snort nor Dragon
produces alerts with multiple sources or targets.
185
Item Name Item Type Notes alertdbid bigint not null from alert analyzerid character varying (255) not null key manufacturer character varying (255) model character varying (255) version character varying (255) class character varying (255)
Table B.5: Analyzer Table
Table 5 is the Analyzer table. The Analyzer table is used to store information
about the analyzer which logged the alert.
Item Name Item Type Notes alertdbid bigint not null from alert table origin character varying (255) not null name character varying (255) url character varying (255)
Table B.6: Classification Table
Table 6, Classification is used to store the information of the name and
references of the alert itself. Origin and URL are used to identify where the
alert came from (say the manufacturer themselves) and where to go to find
more information out about this alert.
Item Name Item Type Notes alertdbid bigint not null from alert table ntpstamp character varying (255) not null pcdata character varying (255) not null
Table B.7: CreateTime Table
CreateTime, Table 7, is the table which stores the time of the alert. In IDMEF,
CreateTime and DetectTime can be used to store the creation time of the
alert and the actual time it was detected (could be different), however in the
interests of simplicity, as the Snort IDMEF plugin only uses CreateTime, this
is the only table which is used to store time at this point.
186
Item Name Item Type Notes targetid bigint from target table sourceid bigint from source table analyzerid bigint from analyser table nodeid bigint not null key ident character varying (255) category character varying (255) location character varying (255) name character varying (255)
Table B.8: Node Table
Node, Table 8, is used for storing the information about an address used by
the tables Target, Source and Analyzer. Node is a superclass of an address,
allowing for non-standard addresses to be used, or a node where multiple
addresses are possible (say a multi-homed host). Nodeid is used as the key,
but node contains references to targeted, sourceid and analyzerid which are
filled with the id of the appropriate referring table.
Item Name Item Type Notes alertdbid bigint not null from alert table sourceid bigint not null key ident character varying (255) spoofed character varying (255) interface character varying (255)
Table B.9: Source Table
The Source Table, Table 9, is used to store information about the source of an
attack. It is virtually identical to the Target Table. Note that information on
whether the address is spoofed or not, and the interface that the packet was
detected on are included.
187
Item Name Item Type Notes alertdbid bigint not null from alert table targetid bigint not null key ident character varying (255) spoofed character varying (255) interface character varying (255)
Table B.10: Target Table
The Target Table, Table 10, is used to store information about the source of
an attack. It is virtually identical to the Source Table.
188
189
Appendix C. Full Graphs of Each Scenario
In this appendix, we show the full graphs of each scenarios alerts in full for
reference. The legend below the graph indicates first which colour of the
upper graph glyphs indicate which IDS (the triangle, square and circle
representations are not included in the legend), and then indicates which
colour of the graphs below indicates which alert name, also indicating the
number which corresponds to the type of alert in the upper graph.
A walkthrough of the major aspects of each graph is provided, focusing on
descriptions of significant alerts and patterns, to enable the reader to
understand the information provided by the graphs.
Note the reference ‘IDS1’ in the text corresponds to ‘ids2-snort’ in the logs,
‘IDS2’ in the text corresponds to ‘ids2-dragon’ in the logs, ‘IDS3’ in the text
corresponds to ‘ids3-snort’ in the logs and ‘IDS4’ in the text corresponds to
‘ids3-dragon’ in the logs. In discussion of the graphs following, the log
representations will be used. Also of note is that for each case in the upper
graph the red square indicates an alert for ids2-nids, the blue circle indicates
ids3-nids, the green triangle indicates ids3-snort and the yellow diamond
indicates ids2-snort. The alert types and colours differ in each case, as the
graph generates the colours and alert type numbers for each graph
individually.
190
Figure C.1: Sequential Scenario
191
C.1 Sequential Scenario Graph Walkthrough
In this graph, the first point to note is the first alert, alert number 32,
produced by ids2-nids. This is a heartbeat message (to indicate the sensor is
active) produced when the IDS is started. Notice that an identical alert is
produced by ids3-nids just before the attacks are started.
We can note from the alert types that the attack commences with three alerts,
ICMP PING NMAP, TCP-FLAGS and BAD TRAFFIC udp port 0 traffic. The
TCP-FLAGS and BAD TRAFFIC alerts continue for approximately the next
30 seconds on both ids2-snort and ids3-snort. Shortly after these alerts,
DYNAMIC-TCP messages are observed from ids2-nids and ids3-nids. We note
during this period the alerts are extremely varied in type indicated by the
evenly distributed set of alerts, all of relatively low frequency (all between one
and five, as indicated by the lower graph). We can also note that the two
Snort IDS are producing the most types of alerts, while the two Dragon IDS
produce a relatively discrete group by comparison.
The RESERVICES rlogin root is conspicuous around 3:44:30, and the rest of
the Cuppens attack alerts can be found in a group before it, around 3:44:18.
For example, we can see that there are two lines of alerts on the right of the
graph. We can see in the legend that these alerts come from ids3-snort and ids3-
dragon. We can then look to the legend to see that the alert types indicated
(numbers 2, BAD Traffic loopback traffic and 45, BAD TRAFFIC 0 ttl both
logged by ids2-snort and ids3-snort). We can then look at the colours
corresponding to these (which in the graph are cyan and orange) to see that
both of these alert types had a high volume of alerts during this period, with
BAD Traffic loopback traffic recoding varying levels of alerts below 10 per
second, and BAD TRAFFIC 0 ttl recording hundreds of alerts a second. We
can also note a TCP-SCAN alert during this period from ids2-nids. These alerts
are generated by the DoS Attack.
192
Figure C.2: Sequential with Background Traffic Scenario
193
C.2 Sequential with Background Traffic Scenario Graph Walkthrough
In this graph, we note again the first alert, alert number 1, is a heartbeat
message. Notice that an identical alert is produced by ids3-nids 8 seconds later.
In this graph we can note the same general features as those in C.1, such as
the diffuse alerts during the Stick attack, and the characteristic lines produced
during the DoS attack. The alerts produced are the same, however in this
graph they have different alert type numbers and so occur at different heights
than C.1.
Of interest is the fact that ids3-nids produces a far greater amount of alerts in
this graph than C.1, in DYNAMIC-TCP and DNS:ANY-UDP alerts,
primarily, but also TCP-SCAN alerts. These alerts are actually generated from
the background traffic, as can be seen and will be discussed in more detail in
Figure and Section C.5.
Of particular interest in this graph is the time around 3:50:30, where a group
of alerts can be seen. If the alerts in this group are investigated, the final
Cuppens attack alert can be identified, but is also combined with a great deal
of WEB-ROBOTS alerts, once again from the background traffic. The other
Cuppens attack and the exploit attack alerts can be seen from 3:50:10 to
3:50:20.
194
Figure C.3: Simultaneous Scenario
195
C.3 Simultaneous Scenario Graph Walkthrough
In this graph, we note again the first alert, alert number 2, is a heartbeat
message. Notice that an identical alert is produced by ids3-nids 10 seconds
later.
In this graph we can note the same general features as those in C.1, such as
the diffuse alerts during the Stick attack, and the characteristic lines produced
during the DoS attack, however in this graph, the DoS attack lines are actually
before the Stick diffuse alerts. This is caused by the delay while waiting for the
first phase of the TCP-Scan attack to finish, before running again with Stick
to obfuscate.
Note that in this example, while these two patterns can be seen from
identification relative to the sequential scenario, it is difficult to identify any
other patterns from this graph. Due the combination of the Stick and DoS
attacks make a fairly diffuse graph with no particular patterns. If the alerts are
investigated individually, the Cuppens attack can be identified, but
distinguishing relationships between the exploit attack and first phase of the
TCP-Scan attack are difficult.
196
Figure C.4: Simultaneous with Background Traffic Scenario
197
C.4 Simultaneous with Background Traffic Scenario Graph
Walkthrough
This graph shows the same features as the simultaneous graph, however now
with the addition of background traffic, the patterns easily identified in the
sequential scenario are far more difficult to find.
Once again, the Cuppens attack alerts early in the graph are fairly easy to
identify, as are the alerts for the DoS attack, however these alerts quickly
become merged with the Stick and background traffic, which produce a
diffuse group of alerts, occurring on both types of IDS. As such, purely from
graphing, from this point on other techniques of analysis should be used to
identify related alerts and identify patterns. It could be noted that no normal
network would actually produce this diffuse array of alerts in such a manner,
so graphing can still be considered useful, even simply to identify that
something is abnormal on the network.
198
Figure C.5: Background Traffic
199
C.5 Background Traffic Graph Walkthrough
In this graph we can note that ids2-nids and ids3-nids (red and blue) produce
the most alerts from the background traffic. This is mainly due to the
DNS:ANY-UDP, DYNAMIC-TCP, TCP-SCAN , WEB-ROBOTS and
SSH:HIGHPORT alerts. Many of these are actually normal traffic, as one of
the hosts used for background traffic was a Web Server (producing the WEB-
ROBOTS alerts, whilst the other was an SSH gateway (producing the SSH
alerts) and a firewall (so handled DNS requests and transfers, and was the
protection against TCP Scans). There are a large amount of DYNAMIC-TCP
alerts which appear to be an often used alert from Dragon produced
whenever large amounts of TCP connections are established.
We can note that the often occurring alerts actually produced rates of 3 alerts
per second or above through the 100MB/second stream (shown here), which
contributes to the steady low amounts of these alerts logged when run with
the attacks at 20MB/second. It should also be notes that the steady nature of
the background traffic was advantageous to produce a regular set of unrelated
alerts to ‘muddy the waters’ for the analysis techniques.
It is disappointing that Snort produced so few alerts from the background
traffic, however this allowed for the special case of very diffuse alerts from
both IDS in the case of the simultaneous with background traffic scenario,
which was useful to test how the graphing and clustering engines dealt with
this sort of information.
200
201
Appendix D. Signatures and Experimental Results
This appendix first shows the format of the signature file during operation of
the scenarios, in both forms, the normal version and the modified version in
order that the exploit signatures would fire as discussed in Section 5.5. The
signature logs that the prototype system produced during the scenarios is
detailed for verification of the operation described in the thesis.
Note that in Sections D.2 through D.5 individual signature results are
separa ted by ‘::::::::::::::::::::::::::::’ and the signature result contains sections for
each alert type separated by ‘---’. Each alert type result indicates the name of
the alert (such as ICMP PING NMAP ), the time of the last alert in ‘Zulu’ time
(date‘T’time‘Z’) and then describes each alert of that alert type, in the form:
database id <space> IDS id <space> sensor name <space> alert name <space> alert
time (Zulu) <space> source IP <space> destination IP <space> destination port
Each of the sections is split up based on the exploits and non-exploits
signature priority settings. For example, in section D.2, the first case, D.2.1
concerns the experiment of signatures using normal priority, while D.2.2
concerns the reordered signatures to enable the exploit signatures to fire.
In the sections, the font used is condensed for enhanced readability.
D.1 Signature File
The first version, Example 1, is the version used in most cases throughout the
thesis. The first line indicates the ordering of fields, for each line of the
signature definition. Note that a signature file line in the examples below
actually spans two lines and is terminated by a carriage return.
Example 2 is the version used in the simultaneous scenarios where the
Cuppens, DoS and TCPScan signatures starved the exploit signatures of alerts
and as such has the two exploit signatures rated at a higher priority to avoid
this (though this in turn starves the Cuppens and the DoS signatures of alerts).
This section concerns the exploit-tuned experiment. Note that a single
instance of TCP-Scan can fire, even with signature Exploit 2 running at a
higher priority and requiring the SCAN Proxy (8080) alert. Note that the
Cuppen3Stage does fire in this case due to an RPC portmap listing alert being
propagated to the Cuppens RPC signature (actually due to an occurrence of
this alert in the background traffic at an opportune time), while the
DosAttack signature does not fire in this case either.
::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 1 has fired. It contained the following alerts: --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:50:12Z 226 159 ids3-nids [TCP-SCAN] 2002-10-25T03:50:12Z 131.181.110.4 131.181.97.10 null 227 160 ids3-nids [TCP-SCAN] 2002-10-25T03:50:12Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:49:38Z 2396 2 ids3-snort ICMP PING NMAP 2002-10-25T03:49:38Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:50:12Z 2446 56 ids3-snort SCAN Proxy (8080) attempt 2002-10-25T03:50:12Z 131.181.97.101 131.181.97.10 8080 ::::::::::::::::::::::::::::::::::::::::::: Alert Exploit2 with sigid 5 has fired. It contained the following alerts: --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:50:02Z 417 41 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:50:02Z 131.181.97.101 131.181.97.31 8080 --- Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:50:14Z 419 60 ids2-snort RPC portmap listing 2002-10-25T03:50:14Z 131.181.97.101 131.181.97.31 111 ::::::::::::::::::::::::::::::::::::::::::: Alert Exploitfull with sigid 7 has fired. It contained the following alerts: --- Alerts for Alert Name:[SSH:VERSION-1] Last Event:2002-10-25T03:50:00Z 164 98 ids3-nids [SSH:VERSION -1] 2002-10-25T03:50:00Z 131.181.97.10 131.181.97.31 null --- Alerts for Alert Name:Exploit Step 2 Detect Last Event:2002-10-25T03:50:14Z null null ids2-snort Exploit Step 2 Detect 2002-10-25T03:50:14Z 131.181.97.101 131.181.97.31 111
211
::::::::::::::::::::::::::::::::::::::::::: Alert CuppenFinger with sigid 2 has fired. It contained the following alerts: --- Alerts for Alert Name:[FINGER:ROOT] Last Event:2002-10-25T03:50:17Z 256 189 ids3-nids [FINGER:ROOT] 2002-10-25T03:50:17Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:FINGER root query Last Event:2002-10-25T03:50:17Z 2463 58 ids3-snort FINGER root query 2002-10-25T03:50:17Z 131.181.97.101 131.181.97.10 79 ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenRPC with sigid 4 has fired. It contained the following alerts: --- Alerts for Alert Name:[DYNAMIC-TCP] Last Event:2002-10-25T03:50:17Z 258 191 ids3-nids [DYNAMIC-TCP] 2002-10-25T03:50:17Z 131.181.97.101 131.181.97.10 null 261 194 ids3-nids [DYNAMIC-TCP] 2002-10-25T03:50:17Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:50:17Z 2450 57 ids3-snort RPC portmap listing 2002-10-25T03:50:12Z 131.181.97.101 131.181.97.10 111 2454 59 ids3-snort RPC portmap listing 2002-10-25T03:50:17Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:RPC portmap request mountd Last Event:2002-10-25T03:50:18Z 2452 61 ids3-snort RPC portmap request mountd 2002-10-25T03:50:18Z 131.181.97.101 131.181.97.10 111 ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenRemoteLogin with sigid 6 has fired. It contained the following alerts: --- Alerts for Alert Name:RSERVICES rlogin root Last Event:2002-10-25T03:50:29Z 2451 62 ids3-snort RSERVICES rlogin root 2002-10-25T03:50:29Z 131.181.97.101 131.181.97.10 513 ::::::::::::::::::::::::: :::::::::::::::::: Alert Cuppen3Stage with sigid 8 has fired. It contained the following alerts: --- Alerts for Alert Name:CUPPENS Finger Detect Last Event:2002-10-25T03:50:17Z null null ids3-snort CUPPENS Finger Detect 2002-10-25T03:50:17Z 131.181.97.101 131.181.97.10 79 --- Alerts for Alert Name:CUPPENS RPC Detect Last Event:2002-10-25T03:50:18Z null null ids3-snort CUPPENS RPC Detect 2002-10-25T03:50:18Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:CUPPENS Remote Login Detect Last Event: 2002-10-25T03:50:29Z null null ids3-snort CUPPENS Remote Login Detect 2002-10-25T03:50:29Z 131.181.97.101 131.181.97.10 513
D.4 Simultaneous Results
This section is similar to Section D.2, except that it relates to the experiment
using the simultaneous scenario. The same format and structure are used here
as in D.2.
Again, this scenario required the second item in CuppenRemoteLogin to be
optional.
212
D.4.1 Normal
In this case, virtually all the signatures fire as per the sequential scenario,
except that the order is different as the attacks are run simultaneously. Due to
the simultaneous running, only one TCP-Scan signature firing is logged, as the
TCP-Scan signature propagates (and eventually drops) additional TCP-SCAN
alerts occurring later. The full amount of TCP-Scan signatures can be
determined by examining Appendix C for the simultaneous scenario, or
examining the clusters generated in Appendix E.
::::::::::::::::::::::::::::::::::::::::::: Alert CuppenFinger with sigid 21 has fired. It contained the following alerts: --- Alerts for Alert Name:[FINGER:ROOT] Last Event:2002-10-25T03:52:55Z 46 2 ids3-nids [FINGER:ROOT] 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:FINGER root query Last Event:2002-10-25T03:52:55Z 2179 2 ids3-snort FINGER root query 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 79 ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 22 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:52:59Z 2178 1 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:55Z 127.0.0.1 131.181.97.10 161 2210 33 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:55Z 127.97.76.0 131.181.97.10 29 2368 191 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:56Z 127.9.58.0 131.181.97.10 null 2400 223 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:57Z 127.36.147.0 131.181.97.10 959 2479 306 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:57Z 127.43.246.0 131.181.97.10 57386 2581 406 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:58Z 127.7.84.0 131.181.97.10 null 2595 419 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:58Z 127.82.122.0 131.181.97.10 null 2631 456 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:58Z 127.43.93.0 131.181.97.10 44185 2654 479 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:58Z 127.131.200.0 131.181.97.10 null 98 1 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:59Z 127.0.0.1 131.181.97.31 161 --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:52:58Z 2646 470 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 185.212.91.0 131.181.97.10 null 2647 471 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 254.153.218.0 131.181.97.10 null 2648 472 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 60.64.188.0 131.181.97.10 null 2650 474 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 9.228.98.0 131.181.97.10 null 2651 452 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 250.196.82.0 131.181.97.10 null 2652 477 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 173.147.251.0 131.181.97.10 null 2653 478 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 94.156.141.0 131.181.97.10 null 2657 475 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 252.134.65.0 131.181.97.10 null 2658 476 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 254.202.180.0 131.181.97.10 null 2676 480 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:52:58Z 66.158.73.0 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 30 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:53:02Z 3211 1035 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 10.215.237.0 131.181.97.10 null 3212 1036 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 57.77.240.0 131.181.97.10 null 3213 1037 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 18.189.60.0 131.181.97.10 null 3214 1038 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 202.250.160.0 131.181.97.10 null 3215 1039 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 21.88.217.0 131.181.97.10 null 3216 1040 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 171.79.94.0 131.181.97.10 null
213
3217 1041 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 29.247.200.0 131.181.97.10 null 3218 1042 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 188.176.47.0 131.181.97.10 null 3219 1043 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 228.210.79.0 131.181.97.10 null 3220 1044 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:02Z 155.221.236.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:53:02Z 2696 523 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:59Z 127.12.0.1 131.181.97.10 3264 2814 649 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:00Z 127.154.83.0 131.181.97.10 null 2944 768 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:00Z 127.53.131.0 131.181.97.10 4756 3006 830 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:01Z 127.236.14.0 131.181.97.10 null 3033 858 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:01Z 127.160.51.0 131.181.97.10 45554 3133 956 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:02Z 127.231.117.0 131.181.97.10 5799 3137 963 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:02Z 127.134.18.0 131.181.97.10 5805 3140 966 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:02Z 127.199.89.0 131.181.97.10 5807 3193 1018 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:02Z 127.12.239.0 131.181.97.10 5858 3221 1045 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:02Z 127.159.168.0 131.181.97.10 5913 ::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 20 has fired. It contained the following alerts: --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:53:00Z 99 2 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:53:00Z 131.181.97.101 131.181.97.31 8080 --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:53:06Z 52 8 ids3-nids [TCP-SCAN] 2002-10-25T03:52:56Z 131.181.97.101 131.181.97.10 null 2 3 ids2-nids [TCP-SCAN] 2002-10-25T03:53:06Z 131.181.97.101 131.181.97.31 null --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:53:01Z 3096 919 ids3-snort ICMP PING NMAP 2002-10-25T03:53:01Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 31 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:53:07Z 352 254 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 184.215.216.0 131.181.97.31 null 353 256 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 193.129.57.0 131.181.97.31 null 354 258 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 136.199.131.0 131.181.97.31 null 355 257 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 214.99.118.0 131.181.97.31 null 356 259 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 115.236.192.0 131.181.97.31 null 357 260 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 21.180.150.0 131.181.97.31 null 358 261 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 56.153.167.0 131.181.97.31 null 359 262 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 60.170.111.0 131.181.97.31 null 360 263 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 200.211.142.0 131.181.97.31 null 361 264 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:07Z 61.215.12.0 131.181.97.31 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:53:07Z 3232 1056 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:02Z 127.22.186.0 131.181.97.10 47607 3303 1126 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:03Z 127.32.251.0 131.181.97.10 19521 3449 1273 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:04Z 127.207.211.0 131.181.97.10 null 135 38 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:06Z 127.116.11.0 131.181.97.31 6303 169 73 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:06Z 127.128.41.0 131.181.97.31 17543 282 185 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:06Z 127.13.101.0 131.181.97.31 null 3711 1535 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:06Z 127.10.96.0 131.181.97.10 null 335 238 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:07Z 127.48.126.0 131.181.97.31 null 349 252 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:07Z 127.185.182.0 131.181.97.31 245 362 265 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:07Z 127.6.56.0 131.181.97.31 257 ::::::::::::::::::::::::: :::::::::::::::::: Alert CuppenRPC with sigid 28 has fired. It contained the following alerts: --- Alerts for Alert Name:[DYNAMIC-TCP] Last Event:2002-10-25T03:53:08Z 50 6 ids3-nids [DYNAMIC-TCP] 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 null 57 13 ids3-nids [DYNAMIC -TCP] 2002-10-25T03:53:08Z 131.181.97.101 131.181.97.10 null ---
214
Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:52:58Z 2190 14 ids3-snort RPC portmap listing 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 111 2641 465 ids3-snort RPC portmap listing 2002-10-25T03:52:58Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:RPC portmap request mountd Last Event:2002-10-25T03:52:58Z 2649 473 ids3-snort RPC portmap request mountd 2002-10-25T03:52:58Z 131.181.97. 101 131.181.97.10 111 ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 33 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:53:08Z 4017 1840 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 145.74.108.0 131.181.97.10 null 4018 1841 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 77.182.128.0 131.181.97.10 null 4019 1842 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 208.207.218.0 131.181.97.10 null 4020 1843 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 115.212.29.0 131.181.97.10 null 4021 1844 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 20.235.86.0 131.181.97.10 null 4022 1845 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 187.109.72.0 131.181.97.10 null 4023 1846 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 202.75.9.0 131.181.97.10 null 4025 1848 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 177.135.196.0 131.181.97.10 null 4026 1849 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 198.82.4.0 131.181.97.10 null 4027 1850 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:08Z 128.229.109.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:53:08Z 461 362 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:07Z 127.145.22.0 131.181.97.31 460 489 393 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:07Z 127.194.133.0 131.181.97.31 1828 499 403 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:07Z 127.168.160.0 131.181.97.31 499 3991 1813 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:07Z 127.127.116.0 131.181.97.10 1066 598 501 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:08Z 127.41.29.0 131.181.97.31 null 643 546 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:08Z 127.33.235.0 131.181.97.31 null 712 616 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:08Z 127.103.168.0 131.181.97.31 1949 714 618 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:08Z 127.80.124.0 131.181.97.31 null 4024 1847 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:08Z 127.71.4.0 131.181.97.10 13332 4028 1851 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:08Z 127.205.127.0 131.181.97.10 1450 ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenRemoteLogin with sigid 25 has fired. It contained the following alerts: --- Alerts for Alert Name:RSERVICES rlogin root Last Event:2002-10-25T03:53:08Z 4136 1961 ids3-snort RSERVICES rlogin root 2002-10-25T03:53:08Z 131.181.97.101 131.181.97.10 513 ::::::::::::::::::::::::::::::::::::::::::: Alert Cuppen3Stage with sigid 27 has fired. It contained the following alerts: --- Alerts for Alert Name:CUPPENS Finger Detect Last Event:2002-10-25T03:52:55Z null null ids3-snort CUPPENS Finger Detect 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 79 --- Alerts for Alert Name:CUPPENS RPC Detect Last Event:2002-10-25T03:53:08Z null null ids3-snort CUPPENS RPC Detect 2002-10-25T03:53:08Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:CUPPENS Remote Login Detect Last Event:2002-10-25T03:53:08Z null null ids3-snort CUPPENS Remote Login Detect 2002-10-25T03:53:08Z 131.181.97.101 131.181.97.10 513 ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 35 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:53:11Z 4543 2366 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 11.201.20.0 131.181.97.10 null 4544 2367 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 97.251.14.0 131.181.97.10 null 4545 2368 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 96.110.106.0 131.181.97.10 null 4546 2369 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 15.36.103.0 131.181.97.10 null 4547 2370 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 243.232. 38.0 131.181.97.10 null 4548 2371 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 47.213.166.0 131.181.97.10 null 4549 2372 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 63.155.135.0 131.181.97.10 null
215
4550 2373 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 138.56.197.0 131.181.97.10 null 4551 2374 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 94.233.210.0 131.181.97.10 null 4552 2375 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:11Z 134.45.248.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:53:11Z 837 740 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:09Z 127.69.130.0 131.181.97.31 1470 946 850 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:09Z 127.31.96.0 131.181.97.31 35805 4177 2000 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:09Z 127.139.143.0 131.181.97.10 40735 1004 907 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:10Z 127.51.27.0 131.181.97.31 12645 4324 2148 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:10Z 127.56.86.0 131.181.97.10 null 4339 2162 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:10Z 127.254.177.0 131.181.97.10 10006 1181 1084 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:11Z 127.117.85.0 131.181. 97.31 null 1195 1098 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:11Z 127.77.91.0 131.181.97.31 null 1291 1194 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:11Z 127.131.42.0 131.181.97.31 5358 4553 2376 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:11Z 127.160.103.0 131.181.97.10 3863 ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 38 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:53:14Z 1605 1509 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 58.36.224.0 131.181.97.31 null 1606 1510 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 223.236.229.0 131.181.97.31 null 1607 1512 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 177.195.130.0 131.181.97.31 null 1608 1513 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 18.71.66.0 131.181.97.31 null 1609 1514 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 175.118.207.0 131.181.97.31 null 1611 1517 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 43.9.150.0 131.181.97.31 null 1612 1518 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 200.225.11.0 131.181.97.31 null 1613 1519 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 225.181.101.0 131.181.97.31 null 1614 1520 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 192.205.174.0 131.181.97.31 null 1615 1521 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:53:14Z 79.44.168.0 131.181.97.31 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:53:14Z 4579 2403 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:11Z 127.251.19.0 131.181.97.10 37734 1369 1274 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:12Z 127.73.47.0 131.181.97.31 3256 1396 1300 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:12Z 127.133.234.0 131.181.97.31 null 1414 1317 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:12Z 127.146.38.0 131.181.97.31 54215 4650 2474 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:12Z 127.29.14.0 131.181.97.10 null 1517 1421 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:13Z 127.46.217.0 131.181.97.31 3998 1580 1484 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:13Z 127.45.25.0 131.181.97.31 null 4734 2558 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:13Z 127.164.148.0 131.181.97.10 65510 4766 2577 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:13Z 127.255.136.0 131.181.97.10 null 1616 1522 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:53:14Z 127.78.236.0 131.181.97.31 28503
D.4.2 Exploits
This section concerns the exploit-tuned experiment. Note that a single
instance of TCP-Scan can fire, even with signature Exploit 2 running at a
higher priority and requiring the SCAN Proxy (8080) alert. Note that the
Cuppen3Stage does not fire due to the absence of CuppenRPC and neither
does the DosAttack signature.
::::::::::::::::::::::::::::::::::::::::::: Alert CuppenFinger with sigid 2 has fired. It contained the following alerts: --- Alerts for Alert Name:[FINGER:ROOT] Last Event:2002-10-25T03:52:55Z 46 2 ids3-nids [FINGER:ROOT] 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:FINGER root query
216
Last Event:2002-10-25T03:52:55Z 2179 2 ids3-snort FINGER root query 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 79 ::::::::::::::::::::::::::::::::::::::::::: Alert Exploit2 with sigid 5 has fired. It contained the following alerts: --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:52:55Z 2180 3 ids3-snort SCAN Proxy (8080) attempt 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 8080 --- Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:52:55Z 2190 14 ids3-snort RPC portmap listing 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 111 :::::::::::::::::::::::::::: ::::::::::::::: Alert Exploitfull with sigid 7 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:52:58Z 2654 479 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:52:58Z 127.131.200.0 131.181.97.10 null --- Alerts for Alert Name:Exploit Step 2 Detect Last Event:2002-10-25T03:52:55Z null null ids3-snort Exploit Step 2 Detect 2002-10-25T03:52:55Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:[SSH:VERSION-1] Last Ev ent:2002-10-25T03:52:59Z 53 9 ids3-nids [SSH:VERSION-1] 2002-10-25T03:52:59Z 131.181.97.10 131.181.97.101 null ::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 1 has fired. It contained the following alerts: --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:53:06Z 52 8 ids3-nids [TCP-SCAN] 2002-10-25T03:52:56Z 131.181.97.101 131.181.97.10 null 2 3 ids2-nids [TCP-SCAN] 2002-10-25T03:53:06Z 131.181.97.101 131.181.97.31 null --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:53:00Z 99 2 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:53:00Z 131.181.97.101 131.181.97.31 8080 --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:53:01Z 3096 919 ids3-snort ICMP PING NMAP 2002-10-25T03:53:01Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenRemoteLogin with sigid 6 has fired. It contained the following alerts: --- Alerts for Alert Name:RSERVICES rlogin root Last Event:2002-10-25T03:53:08Z 4136 1961 ids3-snort RSERVICES rlogin root 2002-10-25T03:53:08Z 131.181.97.101 131.181.97.10 513
D.5 Simultaneous with Background Traffic Results
This section is similar to Section D.2, except that it relates to the experiment
using the simultaneous with background traffic scenario. The same format
and structure are used here as in D.2.
Note that in this example, the first item in the CuppenFinger was absent,
therefore it was set to optional. Also, the second DYNAMIC-TCP alert arrived
217
late (due to high levels of background and DoS/Stick traffic), therefore in this
particular case, the Cuppens Signature was altered from a sequence to a group.
D.5.1 Normal
In this case, virtually all the signatures fire as per the sequential scenario,
except that the order is different as the attacks are run simultaneously. Unlike
the simultaneous without background traffic scenario two TCP-Scan
signatures are logged, as a TCP-Scan with later alerts manages to complete
based on a very late SCAN Proxy (8080) alert generated by the background
traffic.
::::::::::::::::::::::::::::::::::::::::::: Alert CuppenFinger with sigid 2 has fired. It contained the following alerts: --- Alerts for Alert Name:[FINGER:ROOT] Last Event:2002-10-25T03:55:02Z 5077 2 ids3-nids [FINGER:ROOT] 2002-10-25T03:55:02Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 3 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:55:06Z 30 1 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:02Z 127.0.0.1 131.181.97.10 161 12 17 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:03Z 127.155.60.0 131.181.97.10 12 74 75 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:03Z 127.115.105.0 131.181.97.10 6718 151 152 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:04Z 127.178.232.0 131.181.97.10 null 252 253 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:05Z 127.137.246.0 131.181.97.10 64950 284 285 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:05Z 127.72.128.0 131.181.97.10 49089 334 335 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:05Z 127.145.243.0 131.181.97.10 1809 3012 1 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:05Z 127.0.0.1 131.181.97.31 161 520 521 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:06Z 127.13.81.0 131.181.97.10 26668 560 561 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:06Z 127.71.9.0 131.181.97.10 3119 --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:55:06Z 550 551 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 9.137.240.0 131.181.97.10 null 551 552 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 148.213.68.0 131.181.97.10 null 552 553 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 22.130.125.0 131.181.97.10 null 553 554 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 156.74.69.0 131.181.97.10 null 554 555 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 66.199.36.0 131.181.97.10 null 555 556 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 230.96.158.0 131.181.97.10 null 556 557 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 151.101.184.0 131.181.97.10 null 557 558 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 136.127.43.0 131.181.97.10 null 558 559 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 115.60.80.0 131.181.97.10 null 559 560 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:06Z 166.251.36.0 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 1 has fired. It contained the following alerts: --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:55:06Z 3013 2 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:55:06Z 131.181.97.101 131.181.97.31 8080 --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:55:03Z 5070 9 ids3-nids [TCP-SCAN] 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 null
218
5071 8 ids3-nids [TCP-SCAN] 2002-10-25T03:55:03Z 131.181.110.4 131.181.97.10 null --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:55:09Z 908 909 ids3-snort ICMP PING NMAP 2002-10-25T03:55:09Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 11 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:55:13Z 1460 1461 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 139.59.70.0 131.181.97.10 null 1461 1462 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 188.82.170.0 131.181.97.10 null 1462 1463 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 40.248.233.0 131.181.97.10 null 1463 1464 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 248.162.42.0 131.181.97.10 null 1464 1465 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 161.13.197.0 131.181.97.10 null 1465 1466 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 105.20.172.0 131.181.97.10 null 1466 1467 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 248.200.174.0 131.181.97.10 null 1467 1468 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 234.58.23.0 131.181.97.10 null 1468 1469 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 118.180.147.0 131.181.97.10 null 1469 1470 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:13Z 115.203.35.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Ev ent:2002-10-25T03:55:13Z 626 627 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:07Z 127.87.94.0 131.181.97.10 3594 645 646 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:07Z 127.133.119.0 131.181.97.10 3724 783 785 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:08Z 127.247.17.0 131.181.97.10 4704 975 976 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:09Z 127.240.79.0 131.181.97.10 null 1035 1036 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:10Z 127.61.2.0 131.181.97.10 null 1066 1067 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:10Z 127.147.105.0 131.181.97.10 6357 1098 1099 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:10Z 127.113.234.0 131.181.97.10 null 1150 1151 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:10Z 127.205.68.0 131.181.97.10 6927 1342 1343 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:12Z 127.17.213.0 131.181.97.10 6970 1470 1471 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:13Z 127.122.144.0 131.181.97.10 8428 ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenRemoteLogin with sigid 6 has fired. It contained the following alerts: --- Alerts for Alert Name:RSERVICES rlogin root Last Event:2002-10-25T03:55:13Z 1533 1535 ids3-snort RSERVICES rlogin root 2002-10-25T03:55:13Z 131.181.97.101 131.181.97.10 513 --- Alerts for Alert Name:[RSH:ROOT] Last Event:2002-10-25T03:55:13Z 5064 15 ids3-nids [RSH:ROOT] 2002-10-25T03:55:13Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenRPC with sigid 9 has fired. It contained the following alerts: --- Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:55:03Z 21 5 ids3-snort RPC portmap listing 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 111 28 2 ids3-snort RPC portmap listing 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:RPC portmap request mountd Last Event:2002-10-25T03:55:03Z 23 26 ids3-snort RPC portmap request mountd 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:[DYNAMIC-TCP] Last Event:2002-10-25T03:55:14Z 5061 18 ids3-nids [DYNAMIC-TCP] 2002-10-25T03:55:13Z 131.181.97.101 131.181.97.10 null 5058 21 ids3-nids [DYNAMIC-TCP] 2002-10-25T03:55:14Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert Cuppen3Stage with sigid 8 has fired. It contained the following alerts: --- Alerts for Alert Name:CUPPENS Finger Detect Last Event:2002-10-25T03:55:02Z null null ids3-nids CUPPENS Finger Detect 2002-10-25T03:55:02Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:CUPPENS Remote Login Detect Last Event:2002-10-25T03:55:13Z
219
null null ids3-nids CUPPENS Remote Login Detect 2002-10-25T03:55:13Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:CUPPENS RPC Detect Last Event:2002-10-25T03:55:14Z null null ids3-nids CUPPENS RPC Detect 2002-10-25T03:55:14Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 13 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:55:15Z 3441 430 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 187.70.47.0 131.181.97.31 null 3442 431 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 45.227.248.0 131.181.97.31 null 3443 432 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 246.211.48.0 131.181.97.31 null 3444 433 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 207.129.216.0 131.181.97.31 null 3445 434 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 197.239.58.0 131.181.97.31 null 3446 435 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 194.108.31.0 131.181.97.31 null 3447 436 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 206.0.46.0 131.181.97.31 null 3448 438 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 180.216.144.0 131.181.97.31 null 3449 439 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 91.3.12.0 131.181.97.31 null 3450 440 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:15Z 223.152.229.0 131.181.97.31 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:55:15Z 1536 1537 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:13Z 127.169.58.0 131.181.97.10 17889 1628 1629 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:14Z 127.220.220.0 131.181.97.10 null 1684 1685 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:14Z 127.211.71.0 131.181.97.10 null 1696 1698 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:14Z 127.210.13.0 131.181.97.10 null 3089 78 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:14Z 127.167.101.0 131.181.97.31 33924 3231 220 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:14Z 127.119.9.0 131.181.97.31 null 1758 1759 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:15Z 127.207.111.0 131.181.97.10 1035 1784 1785 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:15Z 127.181.12.0 131.181.97.10 1060 3436 396 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:15Z 127.167.77.0 131.181.97.31 421 3451 441 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:15Z 127.102.201.0 131.181.97.31 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 18 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:55:17Z 3832 822 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 26.200.90.0 131.181.97.31 null 3833 824 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 247.87.150.0 131.181.97.31 null 3834 825 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55: 17Z 7.192.128.0 131.181.97.31 null 3835 826 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 73.93.3.0 131.181.97.31 null 3836 827 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 181.13.240.0 131.181.97.31 null 3837 828 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 103.132.171.0 131.181.97.31 null 3838 829 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 216.134.136.0 131.181.97.31 null 3839 830 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 60.68.239.0 131.181.97.31 null 3840 831 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 35.124.119.0 131.181.97.31 null 3841 821 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:17Z 193.35.139.0 131.181.97.31 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:55:17Z 1977 1978 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:16Z 127.30.245.0 131.181.97.10 12460 2016 2017 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:16Z 127.183.33.0 131.181.97.10 null 2019 2020 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:16Z 127.103.163.0 131.181.97.10 null 2038 2037 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:16Z 127.242.149.0 131.181.97.10 null 2057 2058 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:17Z 127.231.244.0 131.181.97.10 58457 2173 2174 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:17Z 127.22.198.0 131.181.97.10 35680 3766 756 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:17Z 127.55.56.0 131.181.97.31 1872 3785 768 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:17Z 127.88.218.0 131.181.97.31 12150 3821 812 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:17Z 127.127.212.0 131.181.97.31 1926 3842 832 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:17Z 127.77.92.0 131.181.97.31 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 19 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:55:21Z 4422 1412 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 120.163.74.0 131.181.97.31 null 4423 1417 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 226.232.84.0 131.181.97.31 null
220
4424 1416 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 160.215.99.0 131.181.97.31 null 4425 1413 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 180.41.151.0 131.181.97.31 null 4426 1418 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 255.249.76.0 131.181.97.31 null 4427 1419 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 56.216.202.0 131.181.97.31 null 4428 1420 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 79.39.72.0 131.181.97.31 null 4429 1421 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 178.45.241.0 131.181.97.31 null 4430 1422 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 144.99.191.0 131.181.97.31 null 4431 1425 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:55:21Z 193.81.63.0 131.181.97.31 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:55:21Z 2212 2214 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:18Z 127.239.58.0 131.181.97.10 null 2365 2366 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:19Z 127.125.146.0 131.181.97.10 null 2475 2476 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:19Z 127.235.1.0 131.181.97.10 12008 4095 1084 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:19Z 127.175.119.0 131.181.97.31 null 4193 1182 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:19Z 127.62.14.0 131.181.97.31 3069 2570 2571 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:20Z 127.11.83.0 131.181.97.10 4443 4351 1341 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:20Z 127.112.75.0 131.181.97.31 3638 2625 2627 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:21Z 127.42.47.0 131.181.97.10 null 2660 2661 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:21Z 127.239.110.0 131.181.97.10 null 4432 1424 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:21Z 127.220.65.0 131.181.97.31 null ::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 12 has fired. It contained the following alerts: --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:55:09Z 3015 4 ids2-snort ICMP PING NMAP 2002-10-25T03:55:09Z 131.181.97.101 131.181.97.31 null --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:55:21Z 5119 33 ids3-nids [TCP-SCAN] 2002-10-25T03:55:20Z 131.181.97.101 131.181.97.10 null 5110 34 ids3-nids [TCP-SCAN] 2002-10-25T03:55:21Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:55:30Z 4989 1979 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:55:30Z 131.181.97.101 131.181.97.31 8080
D.5.2 Exploits
This section concerns the exploit-tuned experiment. Note that a single
instance of TCP-Scan can fire, even with signature Exploit 2 running at a
higher priority and requiring the SCAN Proxy (8080) alert. Note that the
CuppensRPC, Cuppens3Stage and DosAttack signatures do not fire in this
case. This is different from the sequential with background traffic case as that
particular experiment was affected by an RPC portmap listing alert occurring
naturally in the background traffic that did not occur due to different timings
(shorter total scenario duration) here.
::::::::::::::::::::::::::::::::::::::::::: Alert CuppenFinger with sigid 2 has fired. It contained the following alerts: --- Alerts for Alert Name:[FINGER:ROOT] Last Event:2002-10-25T03:55:02Z 5077 2 ids3-nids [FINGER:ROOT] 2002-10-25T03:55:02Z 131.181.97.101 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert Exploit2 with sigid 5 has fired. It contained the following alerts:
221
--- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:55:03Z 0 3 ids3-snort SCAN Proxy (8080) attempt 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 8080 --- Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:55:03Z 20 25 ids3-snort RPC portmap listing 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 111 ::::::::::::::::::::::::::::::::::::::::::: Alert Exploitfull with sigid 7 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:55:04Z 151 152 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:55:04Z 127.178.232.0 131.181.97.10 null --- Alerts for Alert Name:Exploit Step 2 Detect Last Event:2002-10-25T03:55:03Z null null ids3-snort Exploit Step 2 Detect 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:[SSH:VERSION-1] Last Event:2002-10-25T03:55:04Z 5068 11 ids3-nids [SSH:VERSION -1] 2002-10-25T03:55:04Z 131.181.97.10 131.181.97.101 null ::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 1 has fired. It contained the following alerts: --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:55:03Z 5070 9 ids3-nids [TCP-SCAN] 2002-10-25T03:55:03Z 131.181.97.101 131.181.97.10 null 5071 8 ids3-nids [TCP-SCAN] 2002-10-25T03:55:03Z 131.181.110.4 131.181.97.10 null --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:55:06Z 3013 2 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:55:06Z 131.181.97.101 131.181.97.31 8080 --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:55:09Z 908 909 ids3-snort ICMP PING NMAP 2002-10-25T03:55:09Z 131.181.97.101 131.181.97.10 null ::::::::::: :::::::::::::::::::::::::::::::: Alert CuppenRemoteLogin with sigid 6 has fired. It contained the following alerts: --- Alerts for Alert Name:RSERVICES rlogin root Last Event:2002-10-25T03:55:13Z 1533 1535 ids3-snort RSERVICES rlogin root 2002-10-25T03:55:13Z 131.181.97.101 131.181.97.10 513 --- Alerts for Alert Name:[RSH:ROOT] Last Event:2002-10-25T03:55:13Z 5064 15 ids3-nids [RSH:ROOT] 2002-10-25T03:55:13Z 131.181.97.101 131.181.97.10 null
222
223
Appendix E. Results of Cluster Analysis
This appendix shows the output of the clustering functions run on each
scenario. These time-based clusters are used in the Chapter 5 clustering
analysis in Section 5.7. The clusters were generated by only allowing groups
of alerts within a threshold of two seconds of each other (i.e. sequential alerts
must be separated by no more than two seconds).
Each log starts with a summary of the Analyzers, Names, Sources, Targets,
Ports, Times and number clusters found, as well as the difference between
alerts (in time) used to determine if alerts are linked.
The log then details the clusters themselves, indicating the cluster number
with a string of asterisks, the number, then another string of asterisks, and
each alert found, indicating the name, number of occurrences, the time of the
first alert and the time of the last alert in ‘Zulu’ notation. The log then finishes
with the total number of alerts, and the different number of ten second
periods of time (with these periods of time comprised evenly distributed ten
second periods over the entire scenario) found with alerts occurring within
them, which is used as an indication of distribution but does not affect the
generation of the clusters themselves.
E.1 Sequential Scenario Clusters
This section details the clusters generated from the sequential scenario. Note
that the clusters can be easily associated with the attacks from Chapter 5
except for cluster 2, which is dominated by random alerts produced by the
tool Stick.
4 Unique Analyzers 73 Unique Names 4817 Unique Sources 4 Unique Targets 102 Unique Ports 64 Unique Times 8 TimeClusters Found using Difference 2 8 clusters
224
**************1******************** --ids2-nids-- [HEARTBEAT],1,2002-10-25T03:43:01Z,2002-10-25T03:43:01Z **************2******************** --ids2-nids-- [DYNAMIC-TCP],19,2002-10-25T03:43:39Z,2002-10-25T03:44:06Z [NOOP:SOLARIS],1,2002-10-25T03:43:45Z,2002-10-25T03:43:45Z [DYNAMIC-UDP],1,2002-10-25T03:43:56Z,2002-10-25T03:43:56Z [ICMP:TFN],1,2002-10-25T03:44:01Z,2002-10-25T03:44:01Z [TCP-FLAGS],25,2002-10-25T03:43:37Z,2002-10-25T03:44:05Z [OVERFLOW:X86],1,2002-10-25T03:43:52Z,2002-10-25T03:43:52Z [TCP-SCAN],2,2002-10-25T03:43:59Z,2002-10-25T03:44:03Z [DYNAMIC-ICMP],3,2002-10-25T03:43:46Z,2002-10-25T03:43:55Z --ids3-nids-- [DYNAMIC-TCP],14,2002-10-25T03:43:47Z,2002-10-25T03:44:06Z [HEARTBEAT],1,2002-10-25T03:43:37Z,2002-10-25T03:43:37Z [ICMP:STACHELDRAHT],1,2002-10-25T03:43:47Z,2002-10-25T03:43:47Z [DYNAMIC-UDP],1,2002-10-25T03:43:49Z,2002-10-25T03:43:49Z [ICMP:TFN],1,2002-10-25T03:43:38Z,2002-10-25T03:43:38Z [TCP-FLAGS],38,2002-10-25T03:43:37Z,2002-10-25T03:44:06Z [DYNAMIC-ICMP],6,2002-10-25T03:43:49Z,2002-10-25T03:44:03Z --ids3-snort-- ICMP Source Quench,1,2002-10-25T03:43:51Z,2002-10-25T03:43:51Z DDOS Stacheldraht client-check,1,2002-10-25T03:43:42Z,2002-10-25T03:43:42Z DOS ath,1,2002-10-25T03:44:02Z,2002-10-25T03:44:02Z ICMP redirect host,1,2002-10-25T03:43:45Z,2002-10-25T03:43:45Z DDOS TFN server response,1,2002-10-25T03:43:38Z,2002-10-25T03:43:38Z Virus - Possible CheckThis Trojan,2,2002-10-25T03:43:43Z,2002-10-25T03:43:49Z BAD TRAFFIC same SRC/DST,2,2002-10-25T03:43:39Z,2002-10-25T03:44:02Z BACKDOOR QAZ Worm Client Login access,1,2002-10-25T03:43:50Z,2002-10-25T03:43:50Z X11 outbound client connection detected,1,2002-10-25T03:44:03Z,2002-10-25T03:44:03Z BACKDOOR BackConstruction 2.1 Connection,2,2002-10-25T03:43:56Z,2002-10-25T03:44:03Z BACKDOOR DeepThroat 3.1 Server Active on Network,1,2002-10-25T03:43:54Z,2002-10-25T03:43:54Z Virus - Possible NAIL Worm,2,2002-10-25T03:43:43Z,2002-10-25T03:43:48Z Virus - Possible MyPics Worm,1,2002-10-25T03:44:04Z,2002-10-25T03:44:04Z BACKDOOR HackAttack 1.20 Connect,1,2002-10-25T03:43:59Z,2002-10-25T03:43:59Z DDOS Stacheldraht server-response,1,2002-10-25T03:43:47Z,2002-10-25T03:43:47Z BACKDOOR Doly 2.0 access,1,2002-10-25T03:43:41Z,2002-10-25T03:43:41Z ICMP PING NMAP,1,2002-10-25T03:43:37Z,2002-10-25T03:43:37Z Virus - Possible Pikachu Pokemon Virus,1,2002-10-25T03:43:43Z,2002-10-25T03:43:43Z DDOS tfn2k icmp possible communication,1,2002-10-25T03:43:43Z,2002-10-25T03:43:43Z DDOS mstream handler to client,1,2002-10-25T03:43:43Z,2002-10-25T03:43:43Z Virus - Possible QAZ Worm Infection,1,2002-10-25T03:44:06Z,2002-10-25T03:44:06Z
225
DDOS - TFN client command LE,2,2002-10-25T03:43:42Z,2002-10-25T03:43:44Z WEB-MISC amazon 1-click cookie theft,1,2002-10-25T03:44:03Z,2002-10-25T03:44:03Z Virus - Possible Worm - txt.vbs file,1,2002-10-25T03:43:55Z,2002-10-25T03:43:55Z ICMP PING speedera,1,2002-10-25T03:43:43Z,2002-10-25T03:43:43Z SCAN nmap TCP,2,2002-10-25T03:43:54Z,2002-10-25T03:43:59Z Virus - Possible Matrix worm,1,2002-10-25T03:43:45Z,2002-10-25T03:43:45Z DDOS Stacheldraht client-spoofworks,1,2002-10-25T03:44:03Z,2002-10-25T03:44:03Z ICMP redirect net,1,2002-10-25T03:43:44Z,2002-10-25T03:43:44Z ICMP Destination Unreachable (Communication with Destination Host is Administratively Prohibited),1,2002-10-25T03:44:02Z,2002-10-25T03:44:02Z Virus - Possible Common Sense Worm,1,2002-10-25T03:43:46Z,2002-10-25T03:43:46Z BAD TRAFFIC udp port 0 traffic,42,2002-10-25T03:43:37Z,2002-10-25T03:44:06Z BACKDOOR DonaldDick 1.53 Traffic,1,2002-10-25T03:43:43Z,2002-10-25T03:43:43Z DDOS mstream agent to handler,1,2002-10-25T03:44:04Z,2002-10-25T03:44:04Z --ids2-snort-- SMTP exchange mime DOS,1,2002-10-25T03:44:04Z,2002-10-25T03:44:04Z Virus - Possible Worm - gif.vbs file,1,2002-10-25T03:43:48Z,2002-10-25T03:43:48Z SCAN Proxy (8080) attempt,4,2002-10-25T03:43:59Z,2002-10-25T03:44:07Z DDOS TFN server response,1,2002-10-25T03:44:02Z,2002-10-25T03:44:02Z BAD TRAFFIC same SRC/DST,1,2002-10-25T03:44:06Z,2002-10-25T03:44:06Z DDOS mstream handler ping to agent,1,2002-10-25T03:43:55Z,2002-10-25T03:43:55Z X11 outbound client connection detected,6,2002-10-25T03:43:59Z,2002-10-25T03:44:07Z BACKDOOR BackConstruction 2.1 Connection,1,2002-10-25T03:43:56Z,2002-10-25T03:43:56Z BACKDOOR GateCrasher,1,2002-10-25T03:44:06Z,2002-10-25T03:44:06Z ICMP Destination Unreachable (Communication Administratively Prohibited),1,2002-10-25T03:43:55Z,2002-10-25T03:43:55Z Virus - Possible NAIL Worm,3,2002-10-25T03:43:47Z,2002-10-25T03:44:03Z DDOS Stacheldraht server-response-gag,1,2002-10-25T03:43:49Z,2002-10-25T03:43:49Z ICMP PING NMAP,1,2002-10-25T03:43:37Z,2002-10-25T03:43:37Z SCAN Squid Proxy attempt,1,2002-10-25T03:44:04Z,2002-10-25T03:44:04Z WEB-MISC http directory traversal,1,2002-10-25T03:43:39Z,2002-10-25T03:43:39Z Virus - Possible Bubbleboy Worm,1,2002-10-25T03:43:57Z,2002-10-25T03:43:57Z BACKDOOR SatansBackdoor.2.0.Beta,1,2002-10-25T03:43:43Z,2002-10-25T03:43:43Z DDOS tfn2k icmp possible communication,1,2002-10-25T03:43:43Z,2002-10-25T03:43:43Z TELNET access,1,2002-10-25T03:43:50Z,2002-10-25T03:43:50Z DDOS mstream handler to client,2,2002-10-25T03:43:44Z,2002-10-25T03:43:55Z
226
TELNET not on console,1,2002-10-25T03:43:41Z,2002-10-25T03:43:41Z BACKDOOR SIGNATURE - Q ICMP,1,2002-10-25T03:43:49Z,2002-10-25T03:43:49Z Virus - Mail .VBS,1,2002-10-25T03:43:56Z,2002-10-25T03:43:56Z Virus - Possible Worm - txt.vbs file,1,2002-10-25T03:43:53Z,2002-10-25T03:43:53Z BACKDOOR NetSphere access,1,2002-10-25T03:43:58Z,2002-10-25T03:43:58Z ICMP PING speedera,1,2002-10-25T03:43:39Z,2002-10-25T03:43:39Z DDOS Stacheldraht client-spoofworks,1,2002-10-25T03:43:44Z,2002-10-25T03:43:44Z Virus - Possible eurocalculator.exe file,1,2002-10-25T03:44:01Z,2002-10-25T03:44:01Z BACKDOOR BackConstruction 2.1 Server FTP Open Reply,1,2002-10-25T03:43:39Z,2002-10-25T03:43:39Z BAD TRAFFIC udp port 0 traffic,31,2002-10-25T03:43:40Z,2002-10-25T03:44:06Z BACKDOOR DonaldDick 1.53 Traffic,1,2002-10-25T03:43:39Z,2002-10-25T03:43:39Z DDOS mstream agent to handler,1,2002-10-25T03:43:50Z,2002-10-25T03:43:50Z SCAN SOCKS Proxy attempt,4,2002-10-25T03:44:03Z,2002-10-25T03:44:05Z **************3******************** --ids3-snort-- RPC portmap listing,1,2002-10-25T03:44:09Z,2002-10-25T03:44:09Z SCAN Proxy (8080) attempt,1,2002-10-25T03:44:09Z,2002-10-25T03:44:09Z BAD TRAFFIC loopback traffic,1,2002-10-25T03:44:09Z,2002-10-25T03:44:09Z **************4******************** --ids3-nids-- [SSH:VERSION-1],1,2002-10-25T03:44:11Z,2002-10-25T03:44:11Z --ids2-snort-- RPC portmap listing,1,2002-10-25T03:44:12Z,2002-10-25T03:44:12Z SCAN Proxy (8080) attempt,1,2002-10-25T03:44:12Z,2002-10-25T03:44:12Z BAD TRAFFIC loopback traffic,1,2002-10-25T03:44:11Z,2002-10-25T03:44:11Z **************5******************** --ids2-nids-- [SSH:VERSION-1],1,2002-10-25T03:44:14Z,2002-10-25T03:44:14Z **************6******************** --ids3-nids-- [FINGER:ROOT],1,2002-10-25T03:44:16Z,2002-10-25T03:44:16Z [DYNAMIC-TCP],5,2002-10-25T03:44:16Z,2002-10-25T03:44:17Z --ids3-snort-- RPC portmap request mountd,2,2002-10-25T03:44:17Z,2002-10-25T03:44:17Z RPC portmap listing,2,2002-10-25T03:44:17Z,2002-10-25T03:44:17Z FINGER root query,1,2002-10-25T03:44:16Z,2002-10-25T03:44:16Z **************7******************** --ids3-nids-- [DYNAMIC-TCP],10,2002-10-25T03:44:28Z,2002-10-25T03:44:30Z [RSH:ROOT],1,2002-10-25T03:44:28Z,2002-10-25T03:44:28Z --ids3-snort-- RSERVICES rlogin root,1,2002-10-25T03:44:28Z,2002-10-25T03:44:28Z **************8******************** --ids2-nids-- [TCP-SCAN],1,2002-10-25T03:44:49Z,2002-10-25T03:44:49Z --ids3-nids--
227
[UDP-SCAN],1,2002-10-25T03:44:39Z,2002-10-25T03:44:39Z [TCP-SCAN],2,2002-10-25T03:44:39Z,2002-10-25T03:44:39Z --ids3-snort-- BAD TRAFFIC 0 ttl,2681,2002-10-25T03:44:39Z,2002-10-25T03:44:59Z BAD TRAFFIC loopback traffic,42,2002-10-25T03:44:39Z,2002-10-25T03:44:59Z --ids2-snort-- BAD TRAFFIC 0 ttl,1948,2002-10-25T03:44:49Z,2002-10-25T03:45:01Z BAD TRAFFIC loopback traffic,25,2002-10-25T03:44:49Z,2002-10-25T03:45:01Z 5005 alerts total 11 different 10 second periods with alerts E.2 Sequential with Background Traffic Scenario Clusters
This section details the clusters generated from the sequential with
background traffic scenario. In this case, the clusters can be related directly to
those in E.1, however the attacks are much harder to distinguish as random
alerts from the background traffic are interspersed in each cluster. Also of
note is there are actually less clusters than the sequential scenario, as
previously separate clusters have been joined together with alerts from the
BAD TRAFFIC loopback traffic,35,2002-10-25T03:52:55Z,2002-10-25T03:53:15Z WEB-MISC PHP strings overflow,1,2002-10-25T03:53:15Z,2002-10-25T03:53:15Z RPC portmap listing,2,2002-10-25T03:52:55Z,2002-10-25T03:52:58Z BACKDOOR SIGNATURE - Q ICMP,1,2002-10-25T03:53:14Z,2002-10-25T03:53:14Z BACKDOOR netbus active,1,2002-10-25T03:53:16Z,2002-10-25T03:53:16Z RPC portmap request mountd,2,2002-10-25T03:52:57Z,2002-10-25T03:52:58Z FINGER root query,1,2002-10-25T03:52:55Z,2002-10-25T03:52:55Z BACKDOOR Infector.1.x,1,2002-10-25T03:53:19Z,2002-10-25T03:53:19Z BACKDOOR NetSphere access,3,2002-10-25T03:53:09Z,2002-10-25T03:53:23Z BAD TRAFFIC 0 ttl,2896,2002-10-25T03:52:55Z,2002-10-25T03:53:15Z DDOS mstream handler to agent,1,2002-10-25T03:53:20Z,2002-10-25T03:53:20Z DDOS Stacheldraht client-spoofworks,2,2002-10-25T03:53:23Z,2002-10-25T03:53:29Z BAD TRAFFIC udp port 0 traffic,21,2002-10-25T03:53:10Z,2002-10-25T03:53:31Z Virus - Possible Common Sense Worm,1,2002-10-25T03:53:30Z,2002-10-25T03:53:30Z --ids2-snort-- ICMP Source Quench,1,2002-10-25T03:53:27Z,2002-10-25T03:53:27Z ICMP redirect host,1,2002-10-25T03:53:22Z,2002-10-25T03:53:22Z DDOS TFN server response,1,2002-10-25T03:53:17Z,2002-10-25T03:53:17Z SCAN Proxy (8080) attempt,2,2002-10-25T03:53:00Z,2002-10-25T03:53:25Z X11 outbound client connection detected,6,2002-10-25T03:53:22Z,2002-10-25T03:53:30Z DDOS TFN client command BE,1,2002-10-25T03:53:17Z,2002-10-25T03:53:17Z BACKDOOR BackConstruction 2.1 Connection,1,2002-10-25T03:53:20Z,2002-10-25T03:53:20Z Virus - Possible NAIL Worm,1,2002-10-25T03:53:20Z,2002-10-25T03:53:20Z ICMP PING NMAP,1,2002-10-25T03:53:01Z,2002-10-25T03:53:01Z SCAN Squid Proxy attempt,4,2002-10-25T03:53:22Z,2002-10-25T03:53:31Z WEB-MISC http directory traversal,1,2002-10-25T03:53:26Z,2002-10-25T03:53:26Z Virus - Possible Bubbleboy Worm,1,2002-10-25T03:53:31Z,2002-10-25T03:53:31Z TELNET access,1,2002-10-25T03:53:28Z,2002-10-25T03:53:28Z DDOS mstream handler to client,1,2002-10-25T03:53:22Z,2002-10-25T03:53:22Z BAD TRAFFIC loopback traffic,32,2002-10-25T03:52:59Z,2002-10-25T03:53:16Z RPC portmap listing,1,2002-10-25T03:53:00Z,2002-10-25T03:53:00Z BACKDOOR netbus active,1,2002-10-25T03:53:17Z,2002-10-25T03:53:17Z BACKDOOR NetSphere access,1,2002-10-25T03:53:21Z,2002-10-25T03:53:21Z BAD TRAFFIC 0 ttl,1999,2002-10-25T03:53:06Z,2002-10-25T03:53:17Z RPC EXPLOIT statdx,1,2002-10-25T03:53:22Z,2002-10-25T03:53:22Z DDOS mstream handler to agent,1,2002-10-25T03:53:27Z,2002-10-25T03:53:27Z BAD TRAFFIC udp port 0 traffic,19,2002-10-25T03:53:03Z,2002-10-25T03:53:29Z
233
SCAN SOCKS Proxy attempt,2,2002-10-25T03:53:24Z,2002-10-25T03:53:24Z 5162 alerts total 6 different 10 second periods with alerts E.4 Simultaneous with Background Traffic Scenario Clusters
This section details the clusters generated from the simultaneous with
background traffic scenario. As in E.3, there are only two clusters – the first
being that of the Heartbeat alert from ids2-nids and the second containing all
of the other alerts. As expected, this makes distinguishing attacks using
clusters almost impossible as no meaningful patterns can be derived. A point
to note is the relationship between total numbers of alerts, unique names,
unique sources and unique ports. In E.3 and E.4, these are both very similar,
even with the introduction of the background traffic, and the background
traffic actually reduces the total numbers of each.