correlation of heterogenous ids alerts for attack detection · intrusion detection, correlation,...
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
(Research)
Information Security Research Centre
Faculty of Information Technology
Queensland University of Technology
March 2004
Keywords
Intrusion Detection, Correlation, Alert Analysis, Attack Signatures
Abstract
With the increasing use of Intrusion Detection Systems (IDS) as a core component of
network security, a vast array of competing products have appeared to fulfil the role of
reliably detecting potential breaches of security in a network. The domain of detecting
intrusions is large. This leads to products which are better at detecting some intrusions
than others, and so to the use of multiple different types of IDS within a network. This
typical usage, combined with the common practice of using IDS at multiple points in the
network, requires sophisticated management of heterogenous alerts from multiple sources.
This management should enable correlation of alerts with the goal of better detecting
attacks, and reducing the monitoring workload on administrators. This thesis presents an
architecture utilising commodity components and the Intrusion Detection Message
Exchange Format (IDMEF) to enable this type of alert management. A signature scheme
for the specification of patterns of alerts that indicate multi-step attacks is given, and a
methodology for analysing alerts using the architecture that was developed. The final
outcomes are a signature system and collection of tools integrated in a GUI management
interface to aid in the detection of attacks, and the results of utilising these tools on a series
of experiments in attack detection.
i
Table of Contents
CHAPTER 1............................................................................................... 1
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
CHAPTER 2............................................................................................. 15
2.1 IDS INTEROPERABILITY....................................................................... 15 2.2 ATTACK SPECIFICATION LANGUAGES................................................... 19 2.3 CORRELATION AND ALERT PATTERN ANALYSIS ................................... 25 2.4 RESEARCH IMPLEMENTATIONS OF CORRELATION SYSTEMS ................. 29 2.4.1 CUPPENS AND MIEGE...........................................................................29 2.4.2 DEBAR AND WESPI...............................................................................32 2.4.3 VALDES AND SKINNER.........................................................................35 2.4.4 KRUGEL AND TOTH..............................................................................36 2.5 COMMERCIAL PRODUCTS..................................................................... 38 2.6 SUMMARY ............................................................................................ 39
CHAPTER 3............................................................................................. 41
3.1 CHALLENGES ....................................................................................... 42 3.2 ALERT ANALYSIS WATERFALL MODEL ................................................ 43 3.2.1 DATA AGGREGATION...........................................................................45 3.2.2 DATA REDUCTION ...............................................................................45 3.2.3 DATA CORRELATION............................................................................46 3.2.4. DATA INDUCTION ...............................................................................46 3.3 ALERT ANALYSIS AND CORRELATION PROTOTYPE MODEL................... 47 3.4 IDMEF ALERT MESSAGES ................................................................... 50 3.5 REAL-TIME VS . OFF-LINE OPERATION .................................................. 52 3.6 ATTACK SIGNATURES........................................................................... 53 3.6.1 SPECIFICATION....................................................................................54 3.6.2 MULTI-STEP SIGNATURE COMPOSITION.................................................57 3.6.3 EXAMPLE............................................................................................58 3.7 ALERT ANALYSIS ................................................................................. 60 3.7.1 SINGLE AND MULTI-FIT SIGNATURE MATCHING .....................................60 3.7.2 CLUSTERING ANALYSIS........................................................................68
ii
3.7.3 GRAPHING ANALYSIS...........................................................................69 3.8 COMBINING ANALYSIS TECHNIQUES TO DETECT ATTACKS ................... 70 3.9 SUMMARY ............................................................................................ 71
CHAPTER 4............................................................................................. 73
4.1 IMPLEMENTATION REQUIREMENTS ...................................................... 73 4.2 COMPONENTS ...................................................................................... 75 4.2.1 ALERT AGENT .....................................................................................76 4.2.2 CONTROL UNIT....................................................................................77 4.2.3 ADMINISTRATIVE CONSOLE..................................................................78 4.3 SIGNATURE ANALYSIS ENGINE............................................................. 80 4.3.1 SIGNATURE INFORMATION....................................................................81 4.3.2 ENGINE COMPONENTS..........................................................................84 4.3.3 SEQUENCE MATCHING, GROUP MATCHING AND TIMEOUTS.....................87 4.3.4 SIGNATURE MATCHING PROCESS ..........................................................88 4.3.5 ALERT PROPAGATION ..........................................................................91 4.4 CLUSTERING ENGINE ........................................................................... 92 4.4.1 CLUSTERING RELATIONSHIPS................................................................93 4.4.2 SQL AND CLUSTERING.........................................................................95 4.5 GRAPHING ENGINE .............................................................................. 98 4.6 PROTOTYPE GRAPHICAL USER INTERFACE USAGE AND OUTPUT ........ 101 4.7 SUMMARY .......................................................................................... 105
CHAPTER 5........................................................................................... 107
5.1 EXPERIMENTAL PROCEDURE AND RATIONALE ................................... 107 5.1.1 NETWORK AND HOST CONFIGURATION................................................108 5.1.2 REPRODUCIBILITY AND TESTING PROCEDURE ......................................110 5.1.3 GATHERING IDS ALERT LOGS ............................................................112 5.1.4 APPENDICES......................................................................................113 5.2 CREATING A BASIC SIGNATURE – CUPPENS ATTACK........................... 113 5.3 ATTACKS USED IN THE EXPERIMENTS ................................................ 117 5.3.1 ATTACK 1: TCP-SCAN .......................................................................118 5.3.2 ATTACK 2: EXPLOITS.........................................................................120 5.3.3 ATTACK 3: CUPPENS ATTACK ............................................................121 5.3.4 ATTACK 4: DOS ATTACK...................................................................124 5.4 TEST RESULTS – INITIAL OBSERVATIONS ........................................... 126 5.4.1 SUMMARY OF SCENARIO INFORMATION...............................................126 5.4.2 GENERAL NOTES ...............................................................................131 5.4.3 DROPPED ALERTS..............................................................................133 5.5 DETAILED DISCUSSION OF ATTACK SIGNATURE MATCHING ............... 135 5.5.1 INTRODUCTION..................................................................................135 5.5.2 TCP-SCAN ........................................................................................135 5.5.3 EXPLOIT ATTACKS.............................................................................136 5.5.4 CUPPENS ATTACK..............................................................................137 5.5.5 DOS ATTACK ....................................................................................139 5.5.6 SIGNATURE MATCHING EFFECTIVENESS ..............................................140
iii
5.6 TESTING SIGNATURE FEATURES ......................................................... 141 5.6.1 MANDATORY/OPTIONAL FEATURES AND WEIGHTING...........................141 5.6.2 REPLICATION FACTOR........................................................................145 5.6.3 SIGNATURE PRIORITY.........................................................................148 5.6.4 IP MATCHING USING NETMASKS ........................................................148 5.7 ATTACK DETECTION USING GRAPHING AND CLUSTERING .................. 149 5.7.1 TCP SCAN.........................................................................................150 5.7.2 EXPLOITS..........................................................................................152 5.7.3 CUPPENS ATTACK..............................................................................153 5.7.4 DOS ATTACK. ...................................................................................155 5.8 ACCOMPLISHMENTS ........................................................................... 156 5.8.1 MULTIPLE MACHINE ATTACK DETECTION...........................................156 5.8.2 SIGNATURE DETECTION OF MULTIPLE ATTACKS ..................................157 5.8.3 DETECTION OF MULTIPLE STAGES OF AN ATTACK ................................157 5.8.4 DISTINCTION OF SINGLE AND MULTI-HOST ATTACKS............................157 5.8.5 TECHNIQUES TO DISCOVER SIGNATURES .............................................157 5.8.6 CORRELATION BETWEEN DIFFERENT ANALYSIS METHODS ...................158 5.8.7 INVESTIGATION OF MATCHING ALGORITHMS........................................158 5.9 SUMMARY .......................................................................................... 158
CHAPTER 6........................................................................................... 159
6.1 EVALUATION OF RESULTS .................................................................. 159 6.1.1 ANALYSIS METHODS..........................................................................159 6.1.2 PROTOTYPE.......................................................................................160 6.1.3 SIGNATURES......................................................................................160 6.1.4 TEST NETWORK.................................................................................163 6.2 FUTURE WORK .................................................................................. 164 6.2.1 ANALYSIS ENGINE.............................................................................164 6.2.2 PROTOTYPE MODIFICATIONS..............................................................165 6.2.3 SIGNATURE SYSTEM ...........................................................................167 6.2.3 ANALYSIS SYSTEM.............................................................................168 6.2.4 TESTING............................................................................................169 6.3 SUMMARY .......................................................................................... 171
BIBLIOGRAPHY................................................................................... 173
APPENDICES........................................................................................ 177
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
vi
vii
List of Tables
Table Page Table 2.1: Research Summary__________________________________________ 39 Table 4.1: Subset table details__________________________________________ 78 Table 4.2: Signature Format ___________________________________________ 81 Table 5.1: IDS Naming ______________________________________________ 110 Table 5.2: Unknown Attack cluster _____________________________________ 114 Table 5.3: Cuppens Alerts____________________________________________ 123 Table 5.4: Alert Summary ____________________________________________ 127 Table 5.5: Attack Detection Summary ___________________________________ 133 Table 5.6: TCP Scan Signature ________________________________________ 135 Table 5.7: Exploit Stage 1 ____________________________________________ 137 Table 5.8: Exploit Stage 2 ____________________________________________ 137 Table 5.9: Cuppens Finger Detect Signature ______________________________ 138 Table 5.10: Cuppens Remote Login Detect Signature ________________________ 138 Table 5.11: Cuppens RPC Detect Signature_______________________________ 138 Table 5.12: Full Cuppens (Cuppens 3 Stage Detect) Signature _________________ 138 Table 5.13: DoS Attack Signature ______________________________________ 139 Table 5.14: Signature Detection Summary ________________________________ 140 Table 5.15: TCP-Scan Alerts__________________________________________ 142 Table 5.16: TCP-Scan mandatory/optional results __________________________ 143 Table 5.17: TCP-Scan threshold results__________________________________ 145 Table 5.18: DoS Attack Alerts _________________________________________ 146 Table 5.19: DoS replication factor results ________________________________ 147 Table 5.20: Cuppens cluster (Host 2)____________________________________ 154 Table 5.21: DoS Attack clusters________________________________________ 156 Table B.1: Alert Table_______________________________________________ 183 Table B.2: AdditionalData____________________________________________ 183 Table B.3: Address _________________________________________________ 184 Table B.4: Alert_table Table __________________________________________ 184 Table B.5: Analyzer Table ____________________________________________ 185 Table B.6: Classification Table ________________________________________ 185 Table B.7: CreateTime Table__________________________________________ 185 Table B.8: Node Table ______________________________________________ 186 Table B.9: Source Table _____________________________________________ 186 Table B.10: Target Table_____________________________________________ 187
viii
ix
Publications
Carey, N. Management of IDS Data, in Proceedings of Australian Unix Users Group
(AUUG) Security Symposium, 2001, Brisbane (AUUG Press)
Carey, N., G. Mohay, and A. Clark. IDS Interoperability and Correlation Using
IDMEF and Commodity Systems in Proceedings of 4th International Conference of
Information and Communications Security (ICICS), 2002, Singapore (Springer-
Verlag).
Carey, N, G. Mohay and A.Clark. Attack Signature Matching and Discovery in
Systems Employing Heterogeneous IDS in Proceedings of 19th Annual Computer Security
Applications Conference (ACSAC), 2003, Las Vegas, Nevada (IEEE) (to be
published)
x
xi
Declaration
The work contained in this thesis has not been previously submitted for a
degree or diploma at any other higher education institution. To the best of
my knowledge and belief, the thesis contains no material previously published
or written by another person except where due reference is made.
Signed: ______________________________________________
Date: ______________________________________________
xii
xiii
Acknowledgments
It seems that the work involved in a Thesis is always greater than you expect.
From humble beginnings, this research has evolved into a significant work,
and something that I am proud to say is my own, though many people have
had a hand in its final content and condition.
I’d first like to thank my principal supervisor, Adjunct Professor George
Mohay, for his tireless constructive criticism of my writing and enthusiasm in
being involved in the project. His direction and insights were invaluable, and I
appreciate how much of a difference his experience and guidance made to
this work.
Dr. Andrew Clark has also been of incredible help in this work, from taking
over the role of supervising when George was unavailable to helping out with
programming and LaTeX issues even before I’d started my Masters. (Andrew
I should have done this in LaTeX!).
Dr. Lauren May was also instrumental in the final product of this thesis. Her
comments were voluminous, exact, and helped to smooth out the wrinkles of
the first real draft of the thesis.
I’d also like to thank Associate Professor Mark Looi and Professor Ed
Dawson for their support in funding for my research, without their help I
would not have been able to afford to do this work, nor received the help and
support of the ISRC after I finished my undergraduate. I owe them a lot for
their decision to take a chance on me.
Gary Gaskell has also been a guiding light in terms of work ethic and early
supervision of my work. Without his recommendation of me for my first IDS
project, I would probably have never started in IDS.
xiv
I’d also like to thank the many other members of the ISRC, both staff and
students who made my stay such an enjoyable and enriching experience. I
hope to continue my relationship with you all in years to come.
Nathan Carey, Wednesday, 3 March 2004.
1
C h a p t e r 1
INTRODUCTION
1.1 Introduction
Intrusion Detection Systems (IDS) have evolved significantly since their
inception in the early eighties [1]. The simple IDS of those early days were
based either upon the use of simple rule-based logic to detect very specific
patterns of intrusive behaviour or relied upon historical activity profiles to
confirm legitimate behaviour. In contrast, we now have IDS which use data
mining and machine learning techniques, and complex protocol-interpreting
stateful signature detectors which allow for more general expressions of what
may constitute intrusive behaviour. Yet other modern IDS use a mixture of
sophisticated statistical and forecasting techniques to predict legitimate
activity in order to diagnose those actions that are suspicious and could be an
attack.
However, in the midst of all this development, perhaps because of the mad
rush of early research, very little work had been done until recently on how to
enable IDS to interoperate effectively, and how to relate the alerts produced
by more than one IDS.
This thesis describes research in the field of IDS alert correlation, specifically
correlation and analysis of alerts from heterogeneous and physically separa ted
IDS in order to detect attacks. IDS alert correlation as a general research area
uses techniques from many different fields, notably network management,
data mining and even virus detection. By combining concepts from multiple
streams of research, we have created a framework for, and implemented a
proof of concept prototype of, attack detection and alert analysis which
enables practical correlation and analysis of alerts from different
2
heterogeneous sources. A prototype has been developed using free or
commodity components allowing for practical benefit to the community.
This chapter presents a discussion of IDS background and principles, the case
for heterogenous IDS alert analysis, the goals of a practical alert analysis
framework and the motivation for the research work described in this thesis.
1.2 What are Intrusion Detection Systems?
Bace and Mell [2] describe Intrusion Detection Systems (IDS) as ‘software
that automates the process of monitoring the events occurring in a computer
system or network and analysing them for signs of intrusions or attempts to
bypass the security mechanism of a computer or network’. IDS are analogous
to a security camera (with attendant security guard) for a network or
computer. They perform analysis on a set of data, normally network traffic or
host audit logs, and produce alerts containing information about possible
intrusion or misuse.
IDS are commonly characterised according to a two-fold taxonomy involving
detection method on the one hand and placement on the other. Classification
by detection method relates to signature detection vs. anomaly detection IDS
while classification by placement relates essentially to host vs. network based
IDS. Virtually all IDS can be described in this way, with the exception of
some new types of ‘hybrid’ IDS, which may use multiple placement types or
detection methods.
1.2.1 Detection Algorithms: Signature vs. Anomaly
In the case of signature based intrusion detection systems, the IDS identifies
known patterns of intrusive behaviour. Such IDS rely on statically or
dynamically compiled libraries of attacks, which are matched, either post-hoc
or in real-time, to a trace of activity in progress. Anomaly-based systems
identify deviations from normal behaviour. They use a model of ‘normal’
behaviour and report any activity which does not conform to the model.
3
Signature based IDS constrain the range of attacks detected in return for an
acceptable error rate in detection, while anomaly based IDS cover the entire
attack space by looking for anomalies within their data source. However, an
anomaly is not necessarily an attack, and this leads to the major failing of
many anomaly-based systems, that is, the problem of a high false positive or
‘false alert’ rate. In addition, it can be difficult to identify exactly why an
activity is anomalous [3].
So in general, signature systems allow for more specific, deterministic results
on detection of intrusions with lower error rates than is possible with anomaly
detection systems. Anomaly detection systems allow for a greater range of
detection at the expense of higher error rates and normally little information
as to the actual attack which may have occurred.
1.2.2 Sensor Placement: NIDS vs. HIDS
IDS may attempt to detect intrusive behaviour at the host level or at the
network level. The former, host based IDS or HIDS, use host logs and event
records to provide a record of current activity which can then be analysed
with either signature based or anomaly based logic. The latter, network based
IDS or NIDS, typically use packet headers and packet level information,
sometimes even packet payload, as their working data. This can then be
processed using either signature or anomaly based logic, typically the former.
HIDS require an IDS to be located on each host to be protected, while NIDS
are generally only needed on ingress, egress and possibly ‘choke’ points of the
network to be protected. Another advantage of NIDS is the capability to
terminate connections of traffic deemed suspicious, which can help to
prevent an attack being successful. Unfortunately, in most cases a HIDS will
only have detected an attack after it has occurred, which means the HIDS
logs themselves are potentially compromised. NIDS are by far the most
common IDS available, due both to the ease of deployment of NIDS and due
to their compatibility with current security infrastructures which focus on
4
network-based systems such as firewalls, proxies and segregated networks.
There is a recent and growing interest in application-based IDS and it is clear
that such IDS can in certain circumstances present some advantages arising
from their application specificity. In the common classification they are
properly regarded as a specialised form of host based IDS.
As alluded to above, with a wide range of IDS and applications, it is inevitable
that individual IDS have their own areas of specialisation and effectiveness [4,
5, 6, 7]. As a result, and with the broad range of systems and networks in use
today, many systems use multiple IDS - which brings with it the associated
challenge of achieving a consistent approach to IDS management and analysis
of IDS alerts. These issues are the focus of this research.
1.2.3 Problems with IDS
IDS are at a critical juncture in their development at the present time. A vast
array of products are commercially available, together with a range of free
tools, and a large number of research prototypes. However these tools, by and
large, have some significant problems which need to be resolved. Problems
with IDS have been described in Allen et al. [6], Coolen and Luiijf [7], Morin
et al. [8] and Bace and Mell [2]. In the context of this work, several specific
problems are relevant and should be discussed in detail. In brief, they are:
1. Large numbers of IDS alerts [8].
2. Large numbers of false positives [8].
3. Inadequate visualisation techniques [6, 9].
4. IDS often produce inaccurate diagnoses resulting from insufficient
information and simplistic analysis [6].
The first problem, that of large numbers of alerts, is that IDS produce a large
number of alerts for even moderately utilised networks and systems. This,
5
combined with high error rates, the large amount of time required to verify an
intrusion, and the cost of managing an IDS can become too high for many
companies to justify. This is especially true due to the cost and scarcity of
adequately qualified IDS monitoring personnel.
The second problem is that of high numbers of false positives from IDS. This
is normally a product of either ‘fuzzy’ algorithms such as machine learning
with an inherent level of error or in signature -based IDS, from inaccurately
specified signatures. A high number of false positives can also occur without
malicious intent in normal network operation due to incorrect IDS
configuration or the incorrect use of signatures (such as signatures for
Windows-based attacks used on a Unix network, for example). A related sub-
problem, generally associated with packet-analysing signature-based NIDS
such as Snort, is the concept of squealing [10] - IDS producing high volumes
of false positive alerts. This is the deliberate production of false positives by
an attacker based on packets crafted specifically to trigger an IDS response.
This aims to overload the processing or analysis systems of the target IDS, in
order to obfuscate attacks within the large number of alerts. This technique is
used in the suite of attacks used to test the prototype system described in
Chapter 5.
The third problem relates to inadequate visualisation techniques. With the
maturity of IDS increasing, many commercial products include sophisticated
methods of visualisation, however there are still improvements to be made
and IDS with properly designed user interfaces are still the exception rather
than the rule. The visualisation of heterogeneous alerts and techniques to
produce meaningful visualisation of attacks directly from alerts or from
network device information is still in its infancy.
The fourth problem, inaccurate diagnosis, stems from IDS concentration on
elementary signatures, generally from a packet-based perspective in NIDS.
These elementary signatures only specify one stage of an attack, and the
6
administrator is left to piece the multiple alerts of a multi-step attack together
themselves. In order to provide analysis of multi-step attacks, a second level
of analysis is required, which is more effective when performed on multiple
hosts and heterogeneous IDS [11].
1.3 Motivation
There has been some significant recent work in the field of alert correlation
and analysis as described in Chapter 2, which has addressed a variety of
signature specification formats, architectures to support attack detection and
correlation, and research on formal methods.
Our goals were to design and implement the following:
1. Specification of a signature matching scheme for attack detection which
matches attack signatures with an alert stream comprising alerts from
heterogeneous IDS and uses off-the-shelf software with minimum specialised
components,
2. an experimental platform to allow experimentation with new signature
matching algorithms and mechanisms,
3. an alert or cluster analysis capability to facilitate the analysis and correlation
of alerts from heterogeneous IDS,
4. a visualization capability to complement and facilitate the above alert
analysis capability,
5. methods to use clustering and graphing to facilitate signature discovery, and
6. a convenient user (administrator) interface to the above features.
7
These features provide us with the potential to see beyond the actual alerts
themselves to determine trends, find patterns and infer relationships between
them, even when they arrive from different sensors of heterogeneous type.
A tool was needed which could leverage multiple IDS logs, yet provide the
functionality of tools such as ACID for Snort, Demarc and SnortReport.
These Snort-based tools provide analysis capabilities by basic graphing and
data exploration facilities for Snort alerts, either real-time to a database or
post-hoc via Snort alert files. One goal of the prototype has been to provide
functionality similar to these free tools as well as providing alert correlation
facilities.
The goal of this research, in summary, has been to design an architecture for
attack detection by alert correlation and analysis, and to produce a prototype
perform these tasks based on standardised communication and alerting
formats using commodity and open source systems. Our approach, we feel,
suits the ‘real world’ concerns of the majority of IDS users.
1.4 Focus and Contributions of the Thesis
As discussed above, the investigation of signature matching and alert
correlation based on alerts from heterogeneous IDS and the applicability of
this to a range of attacks is a relatively new development. There is, at the time
of writing, little extensive research detailing the problems and issues involved
in implementation of these functions. Rather than focusing on redefining
attack signature languages or alert formats, this work focuses on those
techniques and tools which will be of direct practical benefit to the
administrator in the analysis of attacks. Specifically, the focus is on attack
detection by a simple signature scheme, attack detection by alert analysis using
graphing and clustering, and the feedback between analysis using graphing
and clustering to produce signatures for better detection. The last of these is
called ‘Signature Discovery’.
8
The practical outcomes of this work are a simple signature notation and
signature matching algorithm, the use of cluster and graphing tools to
enhance the ability of the administrator to analyse large volumes of alerts
effectively, and methods to discover and create signatures to aid in attack
detection.
In comparison to other works, here only alerts that are generated by IDS are
used, rather than attempting to specify and correlate events, messages or
alarms from other devices on the network. Rather than use synthetically
generated attacks, while testing our implementation we used a small subset of
real-world attacks chosen to be representative of the types of attacks possible
in practice. These attacks were run with and without background traffic. This
enabled the evaluation of the capabilities of our prototype in a variety of
different situations.
In summary, the thesis presents a simple architecture and model of alert
analysis together with practical correlation techniques for networks of
heterogenous IDS with corresponding benefits. As a result of the research,
the following contributions have been identified:
1. signature-based attack detection which is simple and works using only basic alert
components,
2. an experimental platform in Java with separable discrete components, allowing
for experimentation with signature matching algorithms and mechanisms,
3. an alert or cluster analysis capability allowing for facilities to easily relate
complex series of alerts to relevant features within their groups,
4. a visualization capability which uses graphing with three dimensional data
displayed in two tables allowing for easy analysis of the alerts generated by
multiple IDS,
9
5. methods to use clustering and graphing to easily generate new signatures based on
identified anomalous alerts, and
6. a convenient user interface in Java, allowing for platform independent and
efficient access to the above features.
The features above are implemented in a proof-of-concept prototype, which
was tested for effectiveness in a range of scenarios. The end result is a simple,
functional system for the analysis and correlation of IDS alerts for attack
detection.
1.5 Terminology
In the IDS arena the field of alert correlation has been inundated with
conflicting terminologies. In our context, the use of some definitions is
avoided to avert inconsistent use of terminologies from previous and related
work.
Alert: An alert is a warning message generated by an IDS. It may indicate an
attack or suspicious event.
Alert Cluster: An alert cluster is a group of alerts that are related by one or
more common features, such as time, source or destination. This relationship
may be logical, mathematical or based on statistical grouping. We use this
definition of cluster as opposed to some others e.g., in the work of Cuppens
[13], who uses 'cluster' to term grouped alerts corresponding to a single
instance of an attack. Unless otherwise stated, the clusters described here refer
to a time-based signature, where alerts are grouped based on the time period
between subsequent alerts.
Alert Correlation: The discovery and/or establishment of either mutual or
causal relationships between alerts, usually in order to logically group alerts
based on relationship to attacks or actions on a system or network.
10
Alert Feature: A specific field of information contained within an alert
representing an item of interest. Some examples of normal alert features are:
time, source, destination and alert name.
Alert Group: A set of alerts which may be matched to an attack signature in
any order.
Alert Propagation: The act of reassigning repeated alerts matched a signature
that has not yet completed. May be used in different situations in order to
provide better overall attack detection.
Alert Sequence: An alert sequence is a set of alerts whose elements must be
matched to an attack signature in a specific temporal order.
Alert Stream: The flow of alerts from all IDS as well as alerts that may be
generated by the system itself, when a signature is fired. The term ‘alert
stream’ is used to indicate alerts before they have entered into any analytical
processing such as aggregation or correlation. ‘Alert stream’ can also indicate
the alerts gathered from the database in an off-line context.
Attack: We use the definition provided by CERT for the definition of attack:
‘A series of steps taken by an attacker to achieve an unauthorized result; any
attempt to gain knowledge of or penetrate a system; includes scanning,
probing, mapping, etc.’ 1
Attack Signature: An attack signature is the specification of a pattern of
alerts whose occurrence could indicate a complex or multi-step attack. In our
work, signatures consist of a combination of groups and/or sequences of
alerts. For brevity, any reference to ‘signature’ should be deemed ‘attack
signature’ where not explicitly stated otherwise.
1 http://www.cert.org/security-improvement/modules/m06.html
11
Attack Trace: An attack trace is a group of alerts which can be related to a
single instance of an attack.
Component Alert: An alert that satisfies a portion of a signature, and is
associated with a specific instance of a signature match.
Composite Signatures: Signatures comprising one or more of synthetic alerts,
resulting from the firing of a group or sequence signature, and possibly also
including IDS-generated alerts.
Complex Attack: An attack that may comprise multiple steps and generates
multiple alerts. This definition is based on that by Cuppens [13].
Correlation: Coolen and Luiijf [7] term intrusion correlation as ‘The process
of interpreting, combining and analysing the information of all available IDS’.
We use this definition here. However, we specify the term more precisely by
using the term alert correlation to mean the interpretation, combination and
analysis of alerts from multiple IDS.
Event: An event is an action directed at a target which is intended to result in
a change of state (status) of the target. An event may generate no alerts, a
single alert or many alerts.
Monitor Process: A process which monitors the alert stream in order to
detect matches between alerts and signatures.
Sensor/IDS Sensor: Sensors are the basic detection component of an IDS.
Their basic role is to provide either alerts or intrusion-related data directly to a
higher level analysis component within the same IDS. The distinction
between full IDS and sensor is normally defined in terms of information flow.
Any component providing information to an analysis system can be termed a
sensor for that analysis system. In a normal IDS analysis system, any IDS
providing information can be classed as a sensor.
12
Signature Element: An alert item within the sequence or group of a
signature.
Signature File: A file containing the list of signatures to be loaded into the
system.
Signature Firing/Triggering: When all of the items specified in a signature
have been matched and the signature is still valid (timeout has not expired),
the signature is said to ‘fire’ at which time the outcomes of the signature can
be produced, such as generating new synthetic alerts, deleting old alerts or
merging alerts.
Signature Matching: The process by which alerts are matched to elements
within a signature. This consists of checking if all the constraints of a
signature are met and that the alert is within the timeout period of the
signature. In this case the alert is associated with that instance of matching to
the signature, and the signature matching instance is updated with the
information of that alert.
Simple Attack: An attack which can be recognised through a single alert.
Synthetic Attack: An attack generated synthetically, i.e. using packet
generation rather than actually performing the attack itself.
Synthetic Alert: An alert that can be produced by the detection engine itself,
when an attack signature is fired.
1.6 Organisation of the Thesis
Chapter 2 details current works in the field of IDS interoperability, alert
analysis and correlation, with a focus on some recent work of particular
relevance to this research. This chapter also outlines other work in the field,
placing it in the context of this thesis.
13
Chapter 3 continues the theme by developing the fundamental basis for the
design of the architecture for analysis and correlation proposed in Chapter 4.
Details of the IDMEF data format are included as well as the reasoning
behind component selection, the specification of attack signatures, and the
process of alert analysis using clustering and graphing.
Chapter 4 provides a description of how the design has been implemented in
a proof-of-concept prototype. This details the requirements and specifications
of the prototype and continues with details of the implementation of the
signature and alert analysis subsystems. It concludes with information on how
to combine the detection methods to provide a comprehensive analysis
platform for an administrator.
The prototype was designed with practical application in mind. In order to
test this, a series of experiments was performed using a variety of attack tools
run over a test network. Chapter 5 presents the motivation and design of this
network, the basis for selecting the range of attacks used and how the
signature subsystem performs when certain constraints are changed within
signatures.
The final chapter, Chapter 6, presents the results of the evaluation of the
testing procedure, conclusions on the effectiveness of the prototype and
directions for future work.
The Appendices include results and background information of relevance to
the thesis. Appendix A contains information about the IETF Intrusion
Detection Working Group’s Intrusion Detection Message Exchange Format
(IDMEF), consisting of a diagram of the IDMEF model and examples of the
IDMEF messages produced by Snort and Dragon.
14
Appendix B includes tables of the relevant database tables where IDMEF
messages are stored in our prototype, and descriptions of each. Only directly
relevant tables are included in this Section, for brevity.
Appendix C, D and E contain information from the output of the prototype
developed during the thesis including graphs, logs of the prototype signature
matching, and the output of time-based cluster analysis performed during the
experiments in Chapter 5.
Appendix C contains diagrams of graphs produced by the prototype in each
of the different experiments performed. For each each of the five scenarios
tested in Chapter 5, a graph of the alerts produced is provided. Each of these
graphs also provides a brief description of the main features of each graph,
such as identifying how patterns relate to attacks or which features are due to
the background traffic.
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
to represent these clusters by the prototype is also discussed in Appendix E.
15
C h a p t e r 2
ALERT ANALYSIS & CORRELATION: BACKGROUND AND RECENT WORK
The previous chapter discussed IDS in general and the need for correlation
and analysis of the alerts produced by IDS. In this chapter, we discuss the
concepts of IDS interoperability and alert correlation, and how these concepts
play a crucial role in networks deploying multiple IDS. We also describe
recent research work in order to distinguish our approach from the many
other systems which have been proposed and to establish the similarities in
the core concepts of these various approaches. Also discussed are
standardisation efforts and commercial offerings in this area.
2.1 IDS Interoperability
Interoperability is core to the ability of a system to perform alert correlation.
The core issue in IDS interoperability is the ability to allow data sharing
between IDS and data from different, heterogeneous IDS to be pooled. Some
proposals specify the semantics of that communication, while others provide
data formats and protocols.
CIDF or the Common Intrusion Detection Format [4] was the first serious
effort to meet the challenge of IDS interoperability. It achieved this by
specifying the language used by IDS to communicate, and defining the
various roles of the IDS components needing to communicate. The Common
Intrusion Specification Language [14] was specified for the transfer of
intrusion information, but failed to elicit significant use outside of the CIDF
effort itself.
16
The four components specified by CIDF are:
• Event generators
• Event analysers
• Event databases
• Response units
The four components exchange information in messages called Generalised
Intrusion Detection Objects (GIDOs). Each component’s role with respect
to GIDOs is formalised. Event generators produce GIDOs. Event analysers
process this information to classify GIDOs and even produce new GIDOs
based on information received. Event databases store the GIDOs that have
been produced. Response units can be used to implement various levels of
intrusion prevention measures.
This allowed for a standard communication protocol and established methods
for the division of duties in IDS systems. The IETF Intrusion Detection
Working Group (IDWG) emerged as a result of the work done by CIDF, and
attempted to standardise and formalise the work of cooperating IDS. The
IDWG took a slightly different approach to CIDF. Instead of specifying
interfaces, and languages, it specifies protocols and formats.
The development so far has focused on two standards, a data exchange
format and a protocol for communication. The Intrusion Detection Message
Exchange Format (IDMEF) built on the experience of CIDF, but given the
increased deployment of the eXtensible Markup Language (XML) for
specifying protocols across the Internet, used XML for expressing the two
protocol requirements.
17
XML was originally developed out of the Hyper-Text Markup Language
(HTML). It uses tags and fields to specify types of information. Information
can be typecast either within the document itself, or by a Document Type
Definition (DTD).
XML allows for documents organised in a tree structure, where each item
(called an element) can contain multiple sub-elements. Each element has a
defined type and relationship to the elements above it, defined in terms of
mandatory/non-mandatory, and the amount of times it may repeat (once,
only once, or many). Each element also has attributes, which can be used to
store information relevant to that particular element.
An example is shown for the Target element of IDMEF in Figure 2.1.
<!ELEMENT Target ( Node?, User?, Process?, Service?, FileList? )> <!ATTLIST Target ident CDATA '0' decoy %attvals.yesno; 'unknown' interface CDATA #IMPLIED %attlist.global; >
Figure 2.1 Target Element Details
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’.
PostgresDatabase
Signature Analysis Graph Analysis Cluster Analysis
Administrative Console
NewAlerts
FiredSignatures
UnfiredSingatures
AlertGraph
User DefinedClusters
Lists ofalerts
Array of alert informationsubset table
JDBC
Conversion fromResultSet to array
User-Initiated Actions
Figure 4.4: Administration Console Diagram
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.
Cluster 1 --IDS3-- [FINGER:ROOT], 1, 03:44:16, 03:44:16 [DYNAMIC-TCP], 5, 03:44:16, 03:44:17
--IDS4-- RPC portmap request mountd, 2, 03:44:17, 03:44:17 RPC portmap listing, 2, 03:44:17Z, 03:44:17 FINGER root query, 1, 03:44:16Z, 03:44:16
Cluster 2 --IDS3-- [DYNAMIC-TCP], 10, 03:44:28, 03:44:30 [RSH:ROOT], 1, 03:44:28, 03:44:28
--IDS4-- RSERVICES rlogin root, 1, 03:44:28, 03:44:28
Table 5.2: Unknown Attack cluster
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
reference.
123
Snort Dragon Step 1 FINGER root query, 3:44:16 [FINGER:ROOT], 3:44:16
Step 2 RPC portmap request mountd 3:44:17 [DYNAMIC-TCP], 3:44:17
Step 3 RPC portmap listing 3:44:17 [DYNAMIC-TCP], 3:44:17
Step 4 RPC portmap listing 3:44:17 [DYNAMIC-TCP], 3:44:17
Step 5 Not detected Not detected
Step 6 RSERVICES rlogin root, 3:44:28 [RSH:ROOT],3:44:28
[DYNAMIC-TCP], 3:44:30
Table 5.3: Cuppens Alerts
Using our knowledge of the steps of the Cuppens attack, and relating this to
the alerts from each IDS in Table 5.3, we can create mappings for multi-IDS
signatures based on Steps 1 to 6. We note that FINGER root and
FINGER:ROOT are likely equivalent, so we create a signature of the name
CuppenFinger consisting of both of these alerts. We create another signature
with RSH:ROOT and RSERVICES rlogin root called Cuppens Remote Login
Detect. If we combine these in a sequence with the RPC messages from Snort
as well as a single occurrence of DYNAMIC-TCP (to cover the Dragon-Snort
RPC overlap) we create a signature for the combination of these alerts that
allows the checking of detection across heterogenous IDS. Only one instance
of DYNAMIC-TCP is included as this alert, while generated at the same time
as the others, is hard to verify and to justify its inclusion in the signa ture. If
desired, the replication factor in signatures can be used to capture multiple
instances of DYNAMIC-TCP .
The signature itself and the relationship between the components is shown in
Figure 5.4.
124
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 5.4: Cuppens Signature
5.3.4 Attack 4: DoS Attack
This attack uses a DDoS tool to overload a target with erroneous packets.
The Tribe Flood Network DDoS tool (tfn2k) was used in this experiment.
We used the mix flood mode of Tfn2k, which ‘sends UDP, SYN and ICMP
packets interchanged on a 1:1:1 relation, which can specifically be hazardous
to routers and other packet forwarding devices or NIDS and sniffers’ (Tfn2k
Readme). In our case, two phases of this attack were run, with a ten second
gap between them. The first phase was run against Host 1 alone, and in the
second phase then re-run on Host 1 and Host 2.
For the first phase, the tfn command was:
tfn -h localhost -i 131.181.6.91 -c 8
For the second phase, the host included Host 2, and so was:
tfn -h localhost -i [email protected] -c 8
125
The attack is first performed on one host, then on both hosts, in order to test
whether the difference overall can be noted across IDS and to better
differentiate the alerts from both hosts. Note that this imbalance in TFN is
the cause for the different levels of alerts (shown in Section 5.4) between the
two IDS hosts. TFN randomises the source address for the attack, and
random collections of TCP, UDP and ICMP messages are used for the flood.
As such, we would expect a large number of TCP error messages, as well as
the potential for Scan messages (due to a large number of potential
connections to different ports) and a large number of potentially bogus
source IPs.
A signature is needed for the DoS Attack which allows us to recognise both
the core alerts to be used, as well as track potentially large numbers of alerts
to avoid excessive redundancy. This is caused by the very nature of a DoS
attack in that is it a continuum, rather than an attack with specific discrete
steps. In order to support these two goals, the mandatory/optional aspect and
replication features of our signatures are used in order to allow many
duplicate alerts to combine into one single signature. This is due to the fact
that the TCP-SCAN alert may be present during the initial phases of the DoS
attack (likely caused due to the high number of ports that are contacted by
this particular DoS mode from tfn2k), as well as two BAD TRAFFIC type
alerts from Snort, in a ratio approximately 100:1. However, this ratio was not
static mainly due to the unpredictable nature of systems when under full load
(the IDS may not have been logging all the packets that were part of the
attack, the packets may have been dropped by the network interface during
overloading, or there may not have been enough CPU time to be able to
properly process all the packets in the operating systems TCP/IP stack). The
DoS attack is used as a test case for replication factor in Section 5.6.2.
Because of the unpredictable nature of the three alerts, they are combined in
the group format, and because the TCP-SCAN alert does not appear during
most of the attack, it is labelled optional.
126
The basic signature is shown in Figure 5.5:
TCP-SCANBAD TRAFFIC 0
ttlBAD TRAFFICloopback traffic
DosAttack
Figure 5.5: DoS Signature
If an identical alert comes in any one of BAD TRAFFIC 0 ttl, BAD
TRAFFIC loopback traffic or TCP-SCAN alert types, we group them into one
meta-alert (as per Cuppens) by use of the replication factor.
5.4 Test Results – Initial Observations
In this section we describe the results of applying testing to the signatures
mentioned above using the four scenarios: sequential, sequential with
background traffic, simultaneous and simultaneous with background traffic.
In the following sections we include information on the results of the
detection of the attacks, and describe the reasons for any discrepancies.
5.4.1 Summary of Scenario Information
The different scenarios (simultaneous and sequential, with or without
background traffic) produced quite different numbers, distribution and
composition of alerts mainly due to the interaction between the tool Stick, the
DDoS tool, Tfn2k and the background traffic.
127
A summary of alerts generated in the scenarios by each IDS is given in Table
5.4:
Sequential Sequential
w/bckgrnd Simul-taneous
Simul-taneous w/bckgrnd
IDS1 Alerts (Snort – Host 1)
2053 2040 2080 2008
IDS2 Alerts (Dragon – Host 1)
56 68 45 40
IDS3 Alerts (Snort – Host 2)
2813 1513 2984 3012
IDS4 Alerts (Dragon – Host 2)
83 286 53 63
Distinct Types 73 71 54 52 Total Alerts 5005 3907 5162 5123 Total Time * 1 min 24 sec 1 min 28 sec 36 sec 37 sec
Table 5.4: Alert Summary
* Note that this time total is without the first alert in many cases, as this alert was a
heartbeat alert (a simple alert signalling that the sensor is active) generated by Dragon on
startup. The time between startup and the attack run was affected by startup times in the
IDS and by delays in actually starting the attacks. The reasoning behind this can be
observed in the graphs depicting each scenario in Appendix C in which the anomalous first
alert can clearly be seen much earlier than the attacks begin.
Specific features of the table need explanation and are detailed on an IDS by
IDS basis below:
IDS 1 (Snort – Host1)
For this IDS we can note that
a) the sequential with and without background traffic scenarios differed
by 0.6%, and in the simultaneous scenario, by 3%, which indicates
that the background traffic had a noticeable, but generally fairly minor
impact in this case. That the simultaneous scenario is more affected is
due to the fact that the simultaneous scenario relies on the maximum
128
available bandwidth to produce alerts, and that bandwidth is reduced
by the background traffic. The fact that both scenarios produce less
alerts when background traffic is present is due to the two major
producers of alerts, Stick and the DoS Attack, not having as much
available bandwidth or CPU time on the attacker machine to attack
the IDS hosts.
b) The sequential and simultaneous scenarios are within 1.6% of each
other in both the non-background and background cases, with the
simultaneous scenario higher in the non-background case, and the
sequential scenario higher in the background case. This is related to a)
above, in that the simultaneous scenario technically has a longer time
period for the Stick tool to run, because the TCP-Scan takes slightly
longer when run simultaneously. When background traffic is
introduced the influence of Stick (and the DoS tool) is reduced over
the entire time period. In the second case, the sequential scenario is
less affected due to less contention over bandwidth during the attacks.
IDS2 (Dragon – Host 1)
For Dragon, we have different results in each case than Snort. This is
primarily due to the fact that the Stick and DoS tools do not create as many
alerts on Dragon as they do on Snort, due to Dragon’s more mature detection
engine. Dragon generally produces a single alert per time period (the exact
metrics used for this in the Dragon engine is unknown) during the Stick and
DoS Attacks (such as TCP-SCAN or DYNAMIC-TCP) rather than the Snort
method of producing an alert per packet intercepted. However, Dragon is
affected more than Snort by the background traffic, which is sometimes
classified as erroneous and alerted because the traffic is being replayed, and
does not properly conform to sessions and connections in TCP/IP.
However, there are points to note in the results from IDS2. These are:
129
a) In the sequential case, there are more alerts in the background scenario than in
the non-background scenario. Dragon classifies some of the background
traffic as bad traffic and generating alerts over and above those from
the attacks. Note that this impacts more on Dragon’s overall alerts
percentage wise than Snort due to Dragon not producing many alerts
for the Stick and DoS Attacks.
b) Less alerts in the simultaneous scenario with background traffic, contrasting with
a) above. This is due to less background traffic during the shorter time
period of the simultaneous scenarios (only 37 seconds) combined
with less DoS alerts available - due to contention for bandwidth with
the Stick tool. Overall, this leads to less DoS alerts than the non-
background simultaneous scenario, without a corresponding increase
in alerts from the background traffic, therefore net reduction in
overall alerts.
c) Less alerts in the simultaneous scenario that the sequential scenario. This is due
to less DoS alerts due to 20Mb/sec of background traffic leaving only
80Mb/sec available for the DoS. In practice, there is actually much
less, as generally Ethernet and TCP/IP performance degrades
significantly over 70-80% utilisation leaving approximately 50Mb/sec
usable. Dragon produces very few alerts from the Stick tool.
IDS3 (Snort – Host 2)
IDS3 produces more alerts than IDS1 due to the fact that the DoS tool is
used in two phases, one directly against Host 2, then against both Host 1 and
Host 2. This leads to a significantly larger amount of alerts on Host 2 based
IDS - as the DoS attack alerts are the highest occurring alerts of any of the
attacks. Two features of IDS3 need to be discussed in relation to the
description of IDS1 above.
130
a) Why does the total number of alerts decrease so dramatically between the sequential
and sequential with background traffic scenarios? In this particular case, we
note that IDS4 (the Dragon IDS on the same host as IDS3) produces
significantly more alerts than expected (in relation to IDS2) during
this period. This is likely related to the discussion of IDS4 below, as
there are significantly more alerts based on the background traffic on
Host 2 than Host 1 for Dragon. As Dragon actually uses more CPU
time per packet than Snort (due to it’s more complex protocol
analysis), we can deduce that in this particular case, Dragon was using
significant CPU time processing the background traffic, and this
affected resources available for Snort. With less resources available,
Snort dropped a large amount of packets in this scenario, leaving a
significant deficit in the total number of alerts produced.
Unfortunately, the particular phenomenon was not observed in any of
the previous experiments or in any of the other scenarios, but it does
illustrate that the choice to co-host IDS could introduce error in the
experiments.
b) Why does the total number of alerts increase between the non-background and
background traffic scenarios in contrast to the decrease observed on IDS1? It
can be noted that this increase is also apparent on the Dragon IDS
(IDS4) on the same host. This increase is due to the fact that Host 2
was subject to more packets marked as attacks in the background
traffic than Host 1. As such, even though the DoS attack and Stick
alerts decreased, with the increased background traffic alerts there
were more alerts in total. This increase in the Snort case, was less than
1%.
IDS4 (Dragon – Host2)
The major differences in Dragon alerts on Host 2 are based on two features
of Dragon in the experiments (these features have already been discussed in
131
relation to IDS2 and IDS3 above), that of increased alerts from sequential to
the sequential with background traffic scenario, and the fact that there is also
an increase in alerts in the simultaneous with background traffic scenario.
These two increases are related, and explained in the points below:
a) Why does IDS4 produce more alerts than IDS2? Dragon produces more
alerts for the DoS attack than the Stick tool (the other major
producer of alerts), and the additional exposure of Host 2 to the DoS
attack (due to the first phase) leads to significantly more alerts for
IDS4 than IDS2 during the same period.
b) Why does IDS4 produce more alerts in the background traffic scenarios than
those without? The background traffic for Host 2 contains significantly
more traffic causing alerts for Dragon than Host 1. Thus, Dragon
also produces more alerts based on this background traffic, making
the background traffic scenarios produce larger amounts of alerts.
The large number of alerts produced by Dragon on Host 2 from the
background traffic can be observed in the graph of background
traffic alerts in Figure C.5 in Appendix C. This point is also related to
point a) and b) in the discussion of IDS3.
c) Why does IDS4 produce so many alerts in the sequential with background traffic
scenario? This point is identified and explained in point a) in the
discussion of IDS3.
5.4.2 General Notes
Referring to the graphs in Appendix C, and looking at the lower graphs for
numbers of occurrences, we see that the two most often occurring alerts in
any of the scenarios are those attributable to the DoS attack. In each graph,
large numbers (hundreds of alerts per second) of a single alert are noticed
together with another large number of a second alert. This is due to large
numbers of BAD TRAFFIC 0 ttl messages from Snort and BAD TRAFFIC
132
loopback traffic alerts also from Snort. This behaviour is common on those IDS
that use packet analysis.
The other point of interest is the stage in the attacks where the tool Stick is
used producing a large number of alerts with a wide distribution. This even
reaches the point where, due to less Stick alerts being received because of
bandwidth usage, there are less alerts when using background traffic than
without. The background traffic can contribute a maximum of 748 alerts,
though in practice during the duration of the scenarios it contributes between
70 and 130 depending on the scenario, due to the 20MB/s transfer rate
specified above. A graph showing the distribution of the alerts from the
background traffic is shown in Appendix C, Figure C.5. To generate this
graph (as a reference model) the background traffic was replayed in its
entirety at 100 MB/s until completed. This took approximately three minutes.
When replayed in the scenarios, the traffic was replayed at 20MB/s so as not
to unduly interfere with the operation of the DoS attack and the Stick portion
of TCP-Scan. As such this graph should be used as reference only, bearing in
mind that the durations of the attacks were between 30 seconds and one
minute thirty seconds, so only used between 6 – 18 seconds (due to the
slower replay rate) of the alerts in this graph.
The exact effect of Stick is hard to gauge due to the fact that running the
background traffic reduces the ability of the system to run the Stick program
at as fast a speed, therefore it can actually reduce the total number of alerts
while running. When Stick is running, analysis of alerts using the clustering or
graphing technology can yield little specific results, yet can still determine that
a possible spoofing attack occurred. Signature systems can still detect attacks
within this obfuscation yet do not recognise that the spoofing attack has
occurred, as it does not match any defined signature.
The use of signatures allows us to perform quick matching on a variety of
patterns. Signatures for the attacks were created as discussed in Section 5.2, in
133
order to test the validity of the signature scheme. The effects of the signatures
could be varied according to the settings of timeouts, optional/mandatory
settings, and weighting. A summary of detection results using the signatures
for each attack and each scenario are given in Table 5.5, with the full output
logs produced by the prototype included in Appendix D.
Signature Sequential Sequential w/background
Simultaneous Simultaneous w/background
TCP-Scan# Detected Detected Detected Detected Exploit Detected* Detected* Detected* Detected* Cuppens Detected Detected Detected Detected DoS Attack Detected Detected Detected Detected
Table 5.5: Attack Detection Summary
# The TCP-Scan does not detect the portion of the attack due to Stick as this is a
completely random stream of alerts.
* This detection was a special case of not being detected when run in conjunction with the
TCP-Scan and Cuppens signatures. Due to the higher priority signatures of TCP-Scan and
Cuppens, two of the alerts needed by the Exploit signatures were consumed before the exploit
signatures had access (starved as per discussion in Section 3.7.1). The signatures could be
matched, however, if this priority was ranked higher than TCP-Scan and Cuppens. The
logs displaying the results of the two experimental runs can be seen in Appendix D.
5.4.3 Dropped Alerts
As detailed in Chapter 4, when an ASSV is dropped, the alerts within it are
dropped. This has meant that some results in the following sections are not
what is theoretically expected. This is due to the following factors:
• Alerts replicated and dropping out the bottom of signature allocation
(with no match possible), after overfilling all potential states in the
active signatures – as there is only one ASSV per signature state, if
every state of a signature exists and every replication factor of a
specific alert in each state is filled, new alerts arriving will, through
propagation push out the oldest alerts from the signatures with the
134
lowest level of matched alerts, as discussed in Section 4.3.5 Alert
Propagation. Ideally, if attacks occurred in specific time-frames the
signatures could be keyed to these time frames and alerts lost through
alert propagation would only occur through signature starvation.
• Signatures not complete at the end of an attack run
While the dropping of alerts would ideally be zero, the need to eliminate old
signatures and the elimination of their alerts is desirable to save memory and
processing (due to continued redundant searching and checking of old
signatures). In the single-fit algorithm, provision is made for old alerts to be
allocated to new signatures based on overfilled replication factors, however
when a signature itself is timed out, the removal of a old signature assumes
that if there are any valid alerts these would already be in a newer signature, or
that that newer signature has a set of alerts more likely to trigger the signature.
As such, due the design decisions for the engine and single-fit algorithm, there
is always the potential for some alerts to be dropped in favour of triggering at
least one instance of the signature. The algorithm itself is not optimised to
fully utilise every available alert in the best possible manner, for this we need
to use the multiple-fit algorithm in Chapter 3. However, as we see in Section
5.5, the number of errors introduced by this trade-off in algorithm are minor,
and the main goal of consistently producing at least one relevant alert is
achieved.
The capability to not lose any alerts would be possible in the multiple fit
algorithm, as it implements a roll-back mechanism and re -allocation of alerts,
which would make the most efficient use of all alerts to generate signature
matches if possible.
135
5.5 Detailed Discussion of Attack Signature Matching
5.5.1 Introduction
In this section, the results of detection of each one of the attacks is described
and all of the fields used in the signatures in the experiments. This section is
intended to compliment the discussion of each of the attacks in Section 5.3.
In each case we begin with a table showing the features of the signature used
to detect the attack, as well as the results of using this signature against the
alert streams observed during the scenarios. The methods used to generate
these signatures are described in Section 5.2.
5.5.2 TCP-Scan
The process to develop a signature to detect the TCP Scan attack followed
that discussed in Section 5.2. There are three alerts that appear in the scans
which can be used to create a signature. These are the ICMP PING NMAP,
SCAN Proxy(8080) and TCP-SCAN alerts. Due to the randomness of their
appearance during the attack (both IDS trigger these alerts based on a number
of ports accessed within a given time) the three alerts were combined in a
group signature. The distribution and the impact of weighting of these three
alerts on this signature are described in more detail Section 5.6.1.
The signature used to detect the TCP Scan attack is given in Table 5.6.
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘TCPScan’
32 100 0 3
Alert Name Mandatory Weight Timeout Replication ICMP PING NMAP Mandatory 0 10 1 SCAN Proxy (8080)
attempt Mandatory 0 10 1
[TCP-SCAN] Mandatory 0 20 2 Table 5.6: TCP Scan Signature
136
Table 5.6 shows the composition of a signature in tabular format. This table
represents the information for each signature, described in detail in Section
4.3.1. In this example, the signature type is Group, the action to be taken when
the signature is fired is generation of a new alert called TCP-Scan, there is a
netmask of 32 indicating that only a single host is involved, a timeout of 100
seconds, no weighting in use (0 in the table), and a priority of three, of a
possible one to five, with five being the lowest. The three different alerts used
are ICMP PING NMAP, SCAN Proxy (8080) attempt and TCP-SCAN. All of
these alerts are mandatory, but the individual timeouts for the first two alerts
are ten seconds and the replication factor is one, while TCP-SCAN has a
timeout of twenty seconds and a replication factor of two. Both the individual
timeouts in this signature are specified to be much lower than the overall
timeout, and considering that this is a group signature the individual timeouts
drive a maximum theoretical timeout of 60 seconds (Two alerts at 10 seconds,
and replication of two [TCP-SCAN] at 20 seconds each). Thus the overall
timeout is generally not used in this case. The difference between sequence
and group timeouts is described in Section 4.3.3.
This signature does nothing to detect obfuscation of the second portion of
the scan where the tool Stick was used, however detection of the basic attack
(which is attempted to be obfuscated by Stick) still occurs.
5.5.3 Exploit Attacks
The process in 5.2 was used to determine the alerts to be used in detecting
this attack (actually a combination of three tools). Two signatures were used
to capture the Exploit attack comprising the combination of a group and a
sequence, as discussed in Section 5.3.2. The details are given in Tables 5.7 and
5.8 below.
137
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘Exploit Step 2
Detect’
32 30 0 5
Alert Name Mandatory Weight Timeout Replication RPC portmap listing Mandatory 0 10 1 SCAN Proxy (8080)
attempt Mandatory 0 10 1
Table 5.7: Exploit Stage 1
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘Full Exploits Detect’
32 20 0 5
Alert Name Mandatory Weight Timeout Replication BAD TRAFFIC loopback
traffic Optional 0 20 1
Exploit Step 2 Detect Mandatory 0 20 1 [SSH:VERSION-1] Mandatory 0 20 1
Table 5.8: Exploit Stage 2
In this case, we notice that on both Dragon sensors the SSH:VERSION-1
message was generated and on both Snort machines the RPC portmap, BAD
TRAFFIC and SCAN Proxy messages were generated. Due to the conflict
between items of the two exploit parts conflicting with the signatures of
Cuppens and TCP-Scan, if the exploit signatures are at a lower priority than
the TCP-Scan and Cuppens signatures, then during the simultaneous
scenario, the exploit signatures are not detected in order that the TCP-Scan
and Cuppens signatures fire.
5.5.4 Cuppens Attack
The Cuppens attack uses the signature below for detection, derived as per the
process described in Section 5.2, which focuses on the specification of the
Cuppens signature. In all cases the signature detected the attack successfully.
Tables 5.9, 5.10, 5.11 and 5.12 describe the signatures that detect the Cuppens
attack.
138
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘CUPPENS
Finger Detect’
32 5 0 5
Alert Name Mandatory Weight Timeout Replication Finger root query Optional 0 10 1
[FINGER:ROOT] Mandatory 0 20 1 Table 5.9: Cuppens Finger Detect Signature
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘CUPPENS
Remote Login Detect’
32 20 0 5
Alert Name Mandatory Weight Timeout Replication RSERVICES rlogin root Mandatory 0 5 1
[RSH:ROOT] Mandatory 0 5 1 Table 5.10: Cuppens Remote Login Detect Signature
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘CUPPENS RPC
Detect’
32 20 0 5
Alert Name Mandatory Weight Timeout Replication RPC portmap listing Optional 0 5 2
RPC portmap request mountd
Mandatory 0 5 1
[DYNAMIC-TCP] Mandatory 0 5 1 Table 5.11: Cuppens RPC Detect Signature
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘CUPPENS 3 Stage Detect’
32 20 0 5
Alert Name Mandatory Weight Timeout Replication CUPPENS Finger Detect Optional 0 5 1 CUPPENS RPC Detect Mandatory 0 5 1
CUPPENS Remote Login Detect
Mandatory 0 5 1
Table 5.12: Full Cuppens (Cuppens 3 Stage Detect) Signature
139
One point to note is that in earlier versions of the Cuppens Signature (such as
that included in Carey, Mohay and Clark [12]) the RPC alerts were included in
the Cuppens3stage signature, instead of in the Cuppens RPC signature. This
was found to be inadequate as the RPC messages from Snort could occur out
of sequence, which meant that the signature failed to fire. The RPC and
DYNAMIC-TCP alerts were moved to a separate group signature, which
rectified the problem.
5.5.5 DoS Attack
The DoS attack signature was generated using the process in Section 5.2, and
is primarily a test for the replication factor of signatures. This is due to the
fact that the DoS attack occurs over a continuum, rather than being
comprised of discrete steps. As such, the three component alerts can be
combined in many different ratios in order to achieve detection. Due to the
alert propagation feature the alerts contained within the finally fired signature
will always be the newest available. In each case, multiple instances of the
DoS Attack could be found which varied depending on the timeout value of
the signature, the replication factor and whether the TCP-SCAN alert was
considered optional or mandatory. Examples, given in Section 5.6.2, deal with
the replication factor of signatures. The interested reader can view the full
results in Appendix C. The signature for the DoS Attack is given in Table
5.13.
Type Action Netmask Timeout Weighting Threshold
Priority
Group New Alert – ‘DoS Attack’
0 150 0 5
Alert Name Mandatory Weight Timeout Replication [TCP-SCAN] Optional 0 120 0
BAD TRAFFIC 0 ttl Mandatory 0 40 90 BAD TRAFFIC loopback
traffic Mandatory 0 40 1
Table 5.13: DoS Attack Signature
140
5.5.6 Signature Matching Effectiveness
A summary of the number of times each attack was detected using the above
signatures is included as Table 5.14. The DoS attack is labelled with a ‘?’, as
the number of times the signature fires is subjective, as a DoS attack is
continual across a time period. The full logs generated by the prototype
during matching can be found in Appendix D.
TC
P-Sc
an
Expl
oit S
tep
2
Expl
oit F
ull
Cupp
ens
Fing
er
Cupp
ens
Rem
ote
Logi
n
Cupp
ens
RPC
Det
ect
Cupp
ens
3 St
age
Dos
Atta
ck
Number Expected
1 1 1 1 1 1 1 ?
Sequential 1 1 1 1 1 1 1 6
Sequential with Background
1 1 1 1 1 1 1 3
Simultaneous 1 1 1 1 1 1 1 5
Simultaneous with Background
2 1 1 1 1 1 1 5
Table 5.14: Signature Detection Summary
The prototype consistently detects attacks even when run simultaneously with
background traffic in order to confuse or overload the IDS. This is due in
part to the use of mandatory/optional items and weighting which helps to
screen out erroneous alerts from the background traffic and/or spoofed
attacks from the Stick tool. The impact of these additional signature features
is described in more detail in Section 5.6. Of particular interest at this point is
the need for group signatures to specify those items which may occur out of
sequence, even if the group is then added to a sequence as in the case of the
Cuppens and Exploit attacks.
The use of constraints such as timeout, priority, weighting and replication
factor have a huge impact on the effectiveness of signatures as a whole. With
141
timeouts that are too short, signatures can timeout before matching to all the
mandatory options. Without proper priority settings, due to our single fit
approach, signatures can match and consume an alert that would be better
placed in a more important alert, such as the Exploit alert contending with
both TCP-Scan and the Cuppens attack.
5.6 Testing Signature Features
In order to verify the specific operation of components of the signature
system, we demonstrate the different results produced by the prototype using
varying values for the following features:
• mandatory/optional component with weighting,
• replication factor, and
• signature matching.
Also included is a discussion of the effect of IP matching, although this
particular aspect could not be tested on the network due to traffic filtering by
the network switch.
In order to best show the interaction between signatures, the simultaneous
scenario is chosen for the demonstration of the above concepts. The
simultaneous scenario allows for the maximum amount of interaction
between signatures to enable the best testing of the signature features. While
all the attacks can be tested successfully in the simultaneous scenario with
background traffic, the background traffic introduces erroneous alerts which
do not accurately reflect the basic alerts of each attack.
5.6.1 Mandatory/Optional Features and Weighting
The best example of a signature to show the benefit of Mandatory/Optional
features and Weighting is the TCP-Scan signature. The TCP-Scan signature
142
has alerts which only occur during certain portions of the attack, which allows
us to clearly see the difference between mandatory and optional, as well as the
impact of weighting. It also has relatively few alerts thus not overloading the
IDS, unlike the other potential candidate the DoS attack, and this smaller
number of alerts makes interpretation of data easier.
Optional items were originally designed to combat the problems of specifying
alerts that could be contribute to a signature but were not core to the firing of
the signature, and to allow the administrator to mitigate the problems of
certain alerts that could be absent from the alert stream. To use the concept
of optional alerts effectively however, a technique was required to allow for
combinations of alerts to fire a signature if all the items in the signature were
deemed optional or only a certain percentage of optional alerts were required.
This is accomplished via weighting in which a combination of alerts can
contribute a predetermined value towards a threshold value, the achievement
of which would indicate a signature should be fired.
The alerts that are of relevance to us in this example are the three alerts TCP-
SCAN, SCAN Proxy (8080) and ICMP PING NMAP. For the simultaneous
scenario without background traffic, the distribution of these alerts is given in
Table 5.15:
TCP-SCAN
SCAN Proxy (8080)
ICMP PING NMAP
Total
Total Alerts 6 3 2 11
Start Time 3:52:56 3:52:55 3:53:01 3:52:55
End Time 3:53:27 3:53:25 3:53:01 2:53:27 Table 5.15: TCP-Scan Alerts
As there is no definite correlation between the three numbers, the default
signature specifies a single mandatory instance of SCAN Proxy and ICMP
PING, and two of TCP-SCAN, as discussed in Sections 5.3.4 and 5.5.4.
143
For testing purposes for the specific purpose of examining optional and
weighting features we use a 1:1:1 ratio for these alerts, while altering the
mandatory/optional fields of each. By selecting different combinations of
mandatory or optional elements without the use of weighting, we can change
the number of times the signature is detected. The combinations and relative
detection rates are given in Table 5.16.
Case TCP-SCAN
SCAN Proxy (8080)
ICMP PING NMAP
# of expected matches
# of actual matches
1 Mandatory Mandatory Mandatory 2 2
2 Mandatory Mandatory Optional 3 2 – see below
3 Mandatory Optional Mandatory 2 2
4 Mandatory Optional Optional 6 6
5 Optional Mandatory Mandatory 2 2
6 Optional Mandatory Optional 3 3
7 Optional Optional Mandatory 2 2
8 Optional Optional Optional 11 11
Table 5.16: TCP-Scan mandatory/optional results
Note that in these cases weighting is not used for the optional alerts. While
not useful in practice, optional alerts without weighting can be used for
informational purposes if the alerts attributed to each signature tha t is fired
are to be investigated. For most administrators, the fact that the full signature
has fired and the name of the signature is enough (rather than looking at the
individual alerts which have fired), and specifying optional unweighted alerts
is redundant.
The results are what is expected (except for case two):
• When a mandatory item is included, the mandatory item with the
lowest rate of occurrence dictates the firing of the signature.
144
• When all items are optional, the signature fires on any one.
In case two, we note that the timing of TCP-SCAN and Scan Proxy (8080) is
not predictable (i.e. TCP-SCAN and Scan Proxy (8080) do not occur within a
standard time of one another). Unfortunately as can be seen in Appendix C.3,
the Scan Proxy (8080) alert (alert number 38) occurs twice in the first ten
seconds (around 3:52:55 once on both hosts), and once at the last point
3:53:25, which meant that signatures timed out in the middle of this period as
the timeouts of the signatures were limited to 10 seconds from the first alert.
This ten second period was generally initiated by the TCP-SCAN alert (alert
number 8 in C.3) which occurs regularly over the same period. This mismatch
caused the detection of only two matches in Case 2, when the expected
amount would have been three. A longer timeout would solve this problem,
but would not match the generally observed pattern of alerts from the attack
in the other scenarios.
As discussed above, in normal use the case of all optional items necessitates
some other constraint to use to select a certain percentage of the optional
items. In our case we use the threshold weight and weighting of each
individual alert to accomplish this. These two features were also tested on
TCP-Scan signature, though separately from the mandatory/optional features
above. The threshold is an arbitrary integer, chosen by the administrator, as
are the weightings of each alert. When the alert is detected, its weight is added
to the total for the signature. When the total is above the threshold weight the
signature should fire.
The TCP-Scan signature can be specified as a ‘2 out of 3’ example, where if
two of the signature’s alerts are detected, the TCP-scan signature should be
fired. This can be accomplished by setting each item to optional and each
alert’s weighting to be 1, with a threshold of 2. Table 5.17 gives the results of
experiments relating to modifying the threshold value.
145
Case Threshold Weight
TCP-SCAN
SCAN Proxy (8080)
ICMP PING NMAP
# of expected matches
# of actual matches
1 N/A Mandatory Mandatory Mandatory 2 2
2 1 Optional Optional Optional 11 11
3 2 Optional Optional Optional 5 4*
4 3 Optional Optional Optional 2 2*
Table 5.17: TCP-Scan threshold results
* The distribution of the component alerts affects this result from the theoretical 11 and 3
expected from these due to the early end time of ICMP PING NMAP to the other two (as
shown in Table 5.15) and uneven distribution of TCP -SCAN.
5.6.2 Replication Factor
Leveraging the abilities of the alert replication factor in signatures requires
alert types with a large number of occurrences, preferably with different
numbers of replication for each to test against. The best attack to demonstrate
this is the DoS attack. The three alerts in the DoS signature occur at different
levels, for example BAD TRAFFIC 0 ttl occurs approximately one hundred
times per second, while BAD TRAFFIC loopback traffic occurs at
approximately five times per second. TCP-SCAN occurs in most seconds,
though not all. An administrator can use this information to tune the
replication factors to allow for the most suitable number of alerts to be
generated for the alerts received.
146
Table 5.18 shows the alerts relevant to the DoS attack during the
simultaneous scenario.
TCP-SCAN
BAD TRAFFIC 0 ttl
BAD TRAFFIC loopback traffic
Total
Total Alerts 6 4895 67 4968
Start Time 3:52:56 3:52:55 3:52:55 3:52:55
End Time 3:53:27 3:53:17 3:53:16 3:53:27
Table 5.18: DoS Attack Alerts
Note that in the table above, some of the TCP-SCAN alerts are generated by
the TCP-Scan attack. This does not affect the results of this experiment, as it
is not to detect the DoS attack, rather to determine the effects of altering the
replication factor in a signature. A point to note is that the TCP-SCAN alert is
not generated as a direct result of the DoS attack as it is a function of ports
being accessed by the attack observed by the Dragon engine, and only occurs
once in a given time period so this alert is labelled optional (it can be
considered relevant, but not critical to the firing of the signature). The BAD
TRAFFIC 0 ttl alert is tested using multiple levels of replication, while BAD
TRAFFIC loopback traffic is kept as a single alert per signature to enable
comparison (the actual ration varies but is generally 80-100 to 1). With a well-
tuned replication factor, the total number of alerts can be reduced to a
manageable level during the total duration of the attack. Table 5.19 shows the
results of multiple DoS replication experiments.
The different cases were selected to test whether the algorithm was working
properly – some cases were created simply to be very different to determine
the effects. Case 2 for example, used a number of 120 in the TCP-SCAN field
only to see if the optional alert made any difference to the firing of the
signature. The two alerts of interest, BAD TRAFFIC 0 ttl; and BAD
TRAFFIC loopback traffic were varied in order to examine how varying the
numbers affected the final firing. For example, varying the BAD TRAFFIC
147
loopback traffic alert virtually always affected the final number of matches due
to it being the alert with the lower occurrences. The only changed when the
BAD TRAFFIC 0 ttl was above 90 (the average ratio being approximately 80-
100:1). When BAD TRAFFIC loopback traffic was set to 68 in Case 6, the
signature did not fire as there are only 67 alerts of this type available. The
choice of 4800 in Cases 9 and 10 was motivated by the total number of alerts
being 4895 for BAD TRAFFIC 0 ttl.
Case TCP-SCAN (Optional)
BAD TRAFFIC 0 ttl
BAD TRAFFIC loopback traffic
# of expected matches
# of actual matches
1 1 1 1 67 66 2 120 1 1 67 66
3 1 1 2 33 32
4 1 1 3 22 21
5 1 1 67 1 1
6 1 1 68 0 0
7 1 10 1 67 65
8 1 90 1 67 44
9 1 4800 1 1 1
10 1 4800 60 1 1 Table 5.19: DoS replication factor results
What should be noted is that some of the numbers, particularly those where
the BAD Traffic loopback traffic alert is the primary alert (the alert with the most
impact on signature firing, such as when it has a higher replication factor), are
lower than expected such as in Cases 1, 2, 3, 4, 7, and 8. In Cases 1-4, this is
due to both the leftover alerts at the end of a matching process, and a slight
mismatch in the ratios of the two BAD TRAFFIC alerts. In Cases 7 and 8,
this non-linear relationship between the two BAD TRAFFIC alerts is more
obvious where more BAD TRAFFIC 0 ttl alerts are required for each BAD
148
TRAFFIC loopback traffic. This is more obvious in Case 8, where the actual
amount of alerts required is close to the overall ratio between the alerts.
As shown above, the number of signatures matched is dominated by the
lowest occurring mandatory member of the signature. Using the replication
feature, an administrator can tune how many alerts he wants to use to force
different proportions of alerts in the final signature if desired, or to simply
tune down how many times a signature fires that could be matched multiple
times with high occurrences of alerts.
5.6.3 Signature Priority
The concept of signature priority is used in the case of multiple signatures
contending over a single alert. This is exemplified in the case of TCP-Scan
and Exploit2 which both look for the alert SCAN Proxy (8080), and
Cuppens3stage and Exploit2 which use RPC portmap listing. This meant that
when the attacks were run sequentially, both stages of Exploit2 were detected
successfully. However, during the simultaneous attack runs, Exploit2 and
ExploitFull were both denied access to mandatory alert components which
meant that neither fired, however TCP-Scan, Cuppens and the DoS Attack
signature did. When the priority was altered in order that Exploit2 and
Exploitfull had higher priority than TCP-Scan and Cuppens3stage the exploit
signatures were detected correctly. Note that as this is due to the signature
starvation problem (Section 3.7.1) a multiple-fit signature matching engine
would not require such modification.
Details of the differences between the two setups are contained in Appendix
D, where each scenario is shown with and without the priority adjusted for
the exploit signatures.
5.6.4 IP Matching Using Netmasks
The concept of IP matching and netmask has been discussed in Chapters 3
and 4. While explicit testing of the feature could not be performed due to the
149
switched environment (blocking out targets other than the hosts themselves
from the view of the IDS), the results of using these constraints can be
observed in the results of signature matching included in Appendix D. Direct
testing of this feature did show that the ‘exact match’ and ‘any match’ criteria
worked as expected (blocking out irrelevant alerts) and could be used for the
signatures. While most of the attacks are only run on one host at a time aside
from the Stick tool in the TCP-Scan attack, one special case exists in the case
of the DoS Attack. This attack is used across two different hosts at once in
the latter portion of the attack. In later examples of the matches to this
signature which are exemplified in the replication testing logs in Appendix D,
multiple target addresses are found which correspond to a zero netmask (any
host) match to the signature. In every signature other than the DoS and TCP-
Scan signatures, the netmask field is set to thirty-two and only those alerts on
the same host are detected, even in the case of Cuppens where the RPC
messages from the earlier Exploit attack could potentially be associated.
Unfortunately, the opportunity to test the functionality on full netmask-
specified IP ranges was not available from our test network, but could be
tested at a later stage.
5.7 Attack Detection Using Graphing and Clustering
Using the graphing functionality, we can systematically analyse the alerts
present within a certain period of time. The following gives an example of
analysing attack data from the sequential with background traffic scenario.
The graphing and clustering tools are used as an adjunct mechanism to the
signature-based detection. Graphing and clustering do not provide an
administrator with the means to automatically identify all the components of
any of the attacks. However, the administrator is given enough information
by using graphing and clustering (a range of potentially serious alerts linked
either in time or target) to be suspicious of an attack in the case of the TCP-
Scan, Cuppens and DoS attacks.
150
The graphing functionality is generally used to highlight areas in which cluster
analysis could be useful. In many cases the graphing functionality can be used
alone, but in the following examples we use the graphs in conjunction with
clustering functionality to identify attacks.
For these examples, we have selected the sequential with background traffic
scenario in order to present perhaps the most realistic representation of what
the administrator might be likely to see in practice. Both the simultaneous
scenarios due to the operation of Stick are too large, both in number of alerts
and dispersion of alerts, to make meaningful analysis possible during Stick
operation. The sequential scenario is too simplistic, as each of the attacks is
easily identifiable by the breaks in between each. However, the ‘Sequential
with background traffic’ scenario presents a logical sequence of alerts, whilst
also providing a meaningful number of background alerts to make analysis
difficult.
In the examples of clustering and graphing below, please refer to Appendix C,
Figure C.2 for a diagram of the graph shown during the scenario, and
Appendix E.2 for the output produced by the prototype during cluster
analysis.
5.7.1 TCP Scan
In this scenario we can observe clusters of TCP-SCAN alerts. When looking
at the graphs this can be observed as a period of time where multiple TCP-
SCAN, Scan Proxy (8080) and ICMP PING NMAP alerts occur. The fact that
these alerts relate to scanning activity and occur at the same time should cause
these alerts to be associated by the administrator.
There are two separate phases in the TCP-Scan attack: running of the scan
with and without the tool Stick used to obfuscate the scanning type messages.
Unlike the signature case where Stick did not affect detection and could not
be identified, using the graphing and clustering tools the opposite is true –
151
using graphing and clustering a spoofing attack can easily be seen, but the
TCP-SCAN alert is obfuscated.
Using the clustering functionality of the system and a difference in time
between alerts of no more than two seconds, clusters 3 and 4 in Section E.2
also have alerts in this time period. Cluster 3 is relatively small, though
contains 25 DYNAMIC-TCP messages in one second, with four DNS:ANY-
UDP messages in the same second. Cluster 4, which starts four seconds after
Cluster 3 finishes contains large numbers of alerts (many greater than ten) for
items such as DYNAMIC-TCP , TCP-FLAGS, DNS:ANY-UDP, and BAD
TRAFFIC udp port 0 traffic. These alerts are spread across both hosts in Cluster
4, and considering the large numbers associated with alerts above indicating
generic network alerts, a logical conclusion is that some sort of network
anomaly is occurring.
Cluster 4 also contains a great number of alerts types with only one alert,
which is very suspicious. If we observe the graph in Figure C.2, we can see
that the alerts during this time period are extremely varied causing a diffuse
distribution of alerts over the graph, which should not naturally occur on a
network.
Using the information from the graph as well as that from the clusters, we can
see that either a very wide-spread attack is underway or a program is
purposely spoofing attacks on our hosts. Noting that Snort produces a much
wider array of alerts than Dragon on the same hosts, we could assume that a
specific tool against Snort is being used.
However, in this case we can make no reasonable assumptions about the real
attack that the attack spoofer may have attempted, which can conversely still
be detected using signatures. This particular example shows the benefit of
using clustering and graphing to quickly obtain a better picture of the
distribution and relationship of alerts occurring on the network.
152
5.7.2 Exploits
Unfortunately, due to the background traffic expanding clusters 3 and 4 from
Appendix E as shown in the TCP-Scan section above, the Exploit alerts are
very hard to detect using the common time clusters in our experiments.
When we observe this cluster we can note that some alerts are generated that
could correspond to an Nmap scan, such as the SCAN Proxy alert. However,
no other alerts that would indicate a TCP-Scan such as ICMP Ping NMAP
from Snort and TCP-SCAN alerts from Dragon were found in the early part
of the cluster.
We can also note that both of the two Snort IDS produce identical alerts
during this period, and that both of the Dragon sensors log the SSH alert. We
notice alerts for RPC, BAD TRAFFIC and SSH which can be attributed to
Vetescan scanning through services, while the No-op alert from Snort is due to
the Cisco border routing attack.
The difficulty of identifying the exploits amongst the background traffic is
due to two factors:
• The exploits are very similar to the background traffic in that they are
comprised mainly of generic malformed or bad traffic type alerts
(including scanning) without repeated patterns, and that these alerts
overall, are very low priority. Had Vetescan been able to compromise
any of the services run on either machine more alerts may have been
produced, increasing detection probability and it is likely that they
would have been higher priority, making them more conspicuous for
a systems administrator.
• As the exploits occur just after the Stick portion of the TCP-Scan
attack, the background traffic blends the clusters together, and
153
hampers the creation of simple discrete clusters such as in the
sequential without background traffic scenario.
The current problems using the clusters could be alleviated by using a
difference of one second between subsequent alerts (the difference in all
clusters is set to two second difference) or clusters could be grouped by other
time based methods, such as all the alerts in a single 10 second period, for
example. A ‘moving time window’ method could also have allowed the
differentiation of the large clusters. However, as clusters were mainly used to
perform basic analysis on the sequential scenario for signature discovery in
our experiments, performing experiments using all possible permutations of
clustering was out of scope.
Future work to improve clustering detection across difficult distributions of
alerts could involve more complex clustering operations for distributions of
alerts over a particular time period (similar to a ‘moving time window’
method), and potentially clustering by features other than time, such as
priority, which would make identifying alerts of higher importance easier than
the current methods.
5.7.3 Cuppens Attack
Although easily detected via signature matching, the Cuppens attack is very
difficult to detect via visualisation in a background traffic scenario. It consists
of only seven different alerts, none of which occur in abnormally high
numbers. The alerts themselves are not of particular interest, aside from the
remote login alerts, which could be easily missed. This means if using only the
graphing functionality and background alerts are present, the attack could
easily be missed. It is primarily for this reason that signatures are required. If
the alerts that make up the Cuppens attack are known, however, then the
following process can be used after identifying that the Snort and Dragon
finger alerts occur at 3:50:17 and a Snort RSERVICES rlogin root occurs at
3:50:29 (such as may be noticed by a vigilant Systems Administrator).
154
The Cuppens clusters included in Table 5.20 are a subset of the actual clusters
4 and 5 from the sequential scenario with background traffic presented in
Appendix E. The time period of interest is that of 3:50:17 through 3:50:29,
the short period (~10 seconds) that might be investigated after an
administrator has identified the RSERVICES rlogin root alert. Note also that
the RSH:ROOT message we might expect from Dragon is missing,
presumably due to a dropped packet.
IDS3 WEB-MISC netscape servers suite DOS, 1, 03:49:54, 03:49:54 BACKDOOR GateCrasher, 2, 03:49:39, 03:49:54 RPC portmap listing, 2, 03:50:12, 03:50:17 RPC portmap request mountd, 2, 03:50:18, 03:50:18 FINGER root query, 1, 03:50:17, 03:50:17 RSERVICES rlogin root, 1, 03:50:29, 03:50:29 IDS4 [DNS:ANY-UDP], 82, 03:49:39, 03:50:36 [TCP-SCAN], 19, 03:49:39, 03:50:34 [DYNAMIC-TCP], 43, 03:49:50, 03:50:31 [FINGER:ROOT],1,03:50:17, 03:50:17 [WEB:ROBOTS], 3, 03:50:28, 03:50:33
Table 5.20: Cuppens cluster (Host 2)
With the knowledge of the clusters and alerts contained above, we may
observe that the Cuppens attack occurred. The other background alerts do
not obscure the alerts enough to avoid detection. However, the clusters noted
above assume a search for only alerts within the time period surrounding the
finger and root login events. The full cluster generated by the system actually
contains the TCP-Scan and Exploit attacks as well as the Cuppens attack up
to the RSERVICES rlogin root alert (due to background traffic eliminating the
ten second gap between attacks). In this case, both the graphing and
clustering functionality are not sufficiently tuned to allow easy identification
of this attack, and we must rely on two factors to correctly find the Cuppens
attack:
• Identification of the RSERVICES rlogin root alert, and
155
• Looking for possibly related alerts on the same host within that time
period.
In future research the system could be tuned to automatically generate
clusters on a target of a high priority alert, and automatically present this
information to the administrator. This process would eliminate most of the
manual work involved in this sample, though the administrator would still
need to find any particular relevant alerts manually.
5.7.4 DoS Attack.
We see that in the alert totals section of the graph in Figure C.2 an attack has
produced approximately one hundred alerts per second for a period of
approximately twenty seconds near the end of the scenario. Considering the
number of other alerts, this is unusual. Checking the names of the alerts, the
large number is from BAD TRAFFIC 0 ttl, which is repeated for twenty
seconds. In fact, the total number is 3394 alerts over two IDS during the
entire scenario. When clicking on the alert events themselves, we observe
through the alert summary screen that the attack occurs on Host 1 for ten
seconds before changing and appearing on both Host 1 and Host 2 for ten
seconds. An example of the alert summary screen is shown in Figure 5.6.
Figure 5.6: Example of DoS Summary (clicking on graph icon)
We can use cluster analysis to further improve the analysis of this particular
time period, and the results of this are included as Table 5.21. At the same
156
time BAD TRAFFIC loopback traffic, contributes thirty-three alerts (across two
IDS), or approximately one per one hundred alerts of BAD TRAFFIC 0 ttl.
Looking at the clusters generated during this period we can see that we also
logged thirty-two TCP-SCAN alerts, although only one of these was from
Host 1. From this information, the administrator could determine that a DoS
attack could be occurring due to the large number of alerts, the fact that these
are classed as BAD TRAFFIC, and that they occur with very different source
addresses.
IDS1 IDS3 BAD TRAFFIC 0 ttl,1961, 3:50:49 - 3:51:00 BAD TRAFFIC loopback traffic,17, 3:50:50 - 3:51:00
BAD TRAFFIC 0 ttl,1433, 3:50:39 - 3:50:59 DOS Winnuke attack,2, 3:50:40 - 3:50:53 BAD TRAFFIC loopback traffic,15, 3:50:43 - 3:50:59 DNS zone transfer,1, 3:50:53 - 3:50:53
IDS2 IDS4 DYNAMIC-TCP],3, 3:50:39 - 3:50:39 [WEB:ROBOTS],1, 3:50:39 - 3:50:39 [SSH:VERSION-1],1, 3:50:47- 3:50:47 [TCP-SCAN],1, 3:50:50 -3:50:50
[DNS:ZONEXFER],1,3:50:53 – 3:50:53 [DYNAMIC-TCP],3, 3:50:39 - 3:50:39 [WEB:ROBOTS],1, 3:50:39 - 3:50:39 [SSH:HIGHPORT],2, 3:50:44 - 3:50:44 [DNS:ANY-UDP],20, 3:50:38 - 3:50:52 [TCP-SCAN],31,3:50:39 - 3:50:59
Table 5.21: DoS Attack clusters
5.8 Accomplishments
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.
180
CreateTime
DetectTime
AnalyzerTimeCreateTime
Alertident : string
Alertident : string
IDMEF-Message
+version : string = ‘1.0’
IDMEF-Message
+version : string = ‘1.0’
Node
User
Process
Service
Targetident : stringdecoy : {unknown |
yes | no}
interface : string
Targetident : stringdecoy : {unknown |
yes | no}
interface : string
Node
User
Process
Service
FileList
Heartbeat
ident : string
Heartbeat
ident : string
0..1
0..1
0..*
0..*
0..*
1..*
0..1
ToolAlertToolAlert
OverflowAlertOverflowAlert
CorrelationAlertCorrelationAlertname
command0..1
1..* alertident
analyzerid : string
alertident
analyzerid : string
name
1..* alertident
analyzerid : string
alertident
analyzerid : string
program
size0..1
buffer0..1
AnalyzerTime0..1
Analyzeranalyzerid : stringmanufacturer: stringmodel : stringversion : stringclass : stringostype : stringosversion : string
Analyzeranalyzerid : stringmanufacturer: stringmodel : stringversion : stringclass : stringostype : stringosversion : string
Node
Process
0..1
0..1
Analyzeranalyzerid : stringmanufacturer: stringmodel : stringversion : stringclass : stringostype : stringosversion : string
Analyzeranalyzerid : stringmanufacturer: stringmodel : stringversion : stringclass : stringostype : stringosversion : string
Node
Process
0..1
0..1
Classification
origin : string
Classification
origin : stringname
url
Source
ident : stringspoofed : {unknown |
yes | no}interface : string
Source
ident : stringspoofed : {unknown |
yes | no}interface : string
Impact
Action
Confidence
0..1AssessmentAssessment
0..1
0 ..*
AdditionalData
type : stringmeaning : string
AdditionalData
type : stringmeaning : string
0..* AdditionalData
type : stringmeaning : string
AdditionalData
type : stringmeaning : string
Figure A.1: IDMEF Model
Diagram2 (incomplete)
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>
</Node> </Analyzer> <CreateTime ntpstamp="0xc1391bc5.0x2b409000">2002-09-23T04:49:09Z</CreateTime> <Source> <Node> <Address category="ipv4-addr"> <address>131.181.6.94</address>
</Address> </Node>
</Source> <Target> <Node> <Address category="ipv4-addr"> <address>131.181.6.92</address>
</Address> </Node>
</Target> <Classification origin="vendor-specific"> <name>ICMP PING NMAP</name> <url>http://www.whitehats.com/info/IDS162</url>
</Classification> </Alert> </IDMEF-Message>
182
A.2 Example Dragon Message
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).
202
Example 1. Normal Version # Alert Name, Type, FireAction, FireContent, netmask, TimeOut, VoteThreshold, Priority - Alert Stuff - Alert Name # Mandatory # Vote # Timeout # Replication CuppenFinger, group, newalert, CUPPENS Finger Detect, 32, 5, 0, 2, FINGER root query#Mandatory#0#10, [FINGER:ROOT]#Mandatory#1#10 CuppenRemoteLogin, sequence, newalert, CUPPENS Remote Login Detect, 32, 20, 0, 2, RSERVICES rlogin root#Mandatory#0#5, [RSH:ROOT]#Mandatory#0#5 CuppenRPC, group, newalert, CUPPENS RPC Detect, 32, 30, 0, 3, RPC portmap listing#Mandatory#0, RPC portmap request mountd#Mandatory#10#20, [DYNAMIC-TCP]#Mandatory#10#20 Cuppen3Stage, sequence, newalert, CUPPENS 5 Stage Detect, 32, 20, 0, 3, CUPPENS Finger Detect#Mandatory#0, CUPPENS RPC Detect#Mandatory#0, CUPPENS Remote Login Detect#Mandatory#34 TCPScan, group, new alert, TCP-Scan, 0, 100, 0, 3, ICMP PING NMAP#Mandatory#0, SCAN Proxy (8080) attempt#Mandatory#0, [TCP-SCAN]#Mandatory#0#40#2 Exploitfull, group, newalert, FULL Exploits Detect, 0, 40, 0, 5, BAD TRAFFIC loopback traffic#Optional#0, Exploit Step 2 Detect#Mandatory#0, [SSH:VERSION -1]#Mandatory#0 Exploit2, group, newalert, Exploit Step 2 Detect, 32, 60, 0, 5, RPC portmap listing#Mandatory#0, SCAN Proxy (8080) attempt#Mandatory#0 DosAttack, group, newalert, DoS Attack, 0, 150, 0, 3, [TCP-SCAN]#Optional#0#4, BAD TRAFFIC 0 ttl#Mandatory#0#40#2, BAD TRAFFIC loopback traffic#Mandatory#0#40#1
Example 2. Exploits Version # Alert Name, Type, FireAction, FireContent, netmask, TimeOut, VoteThreshold, Priority - Alert Stuff - Alert Name # Mandatory # Vote # Timeout # Replication CuppenFinger, group, newalert, CUPPENS Finger Detect, 32, 5, 0, 2, FINGER root query#Mandatory#0#10,[FINGER:ROOT]#Mandatory#1#10 CuppenRemoteLogin, sequence, newalert, CUPPENS Remote Login Detect, 32, 20, 0, 2, RSERVICES rlogin root#Mandatory#0#5, [RSH:ROOT]#Mandatory#0#5 CuppenRPC, group, newalert, CUPPENS RPC Detect, 32, 30, 0, 3, RPC portmap listing#Mandatory#30#2, RPC portmap request mountd#Mandatory#10#20, [DYNAMIC-TCP]#Mandatory#10#20#2 Cuppen3Stage, sequence, newalert, CUPPENS 5 Stage Detect, 32, 20, 0, 3, CUPPENS Finger Detect#Mandatory#0, CUPPENS RPC Detect#Mandatory#0, CUPPENS Remote Login Detect#Mandatory#34 TCPScan, group, newalert, TCP-Scan, 0, 100, 0, 3, ICMP PING NMAP#Mandatory#0, SCAN Proxy (8080) attempt#Mandatory#0, [TCP-SCAN]#Mandatory#0#40#2 Exploitfull, group, newalert, FULL Exploits Detect, 0, 40, 0, 1, BAD TRAFFIC loopback traffic#Optional#0, Exploit Step 2 Detect#Mandatory#0, [SSH:VERSION -1]#Mandatory#0 Exploit2, group, newalert, Exploit Step 2 Detect, 32, 60, 0, 1, RPC portmap listing#Mandatory#0, SCAN Proxy (8080) attempt#Mandatory#0 DosAttack, group, newalert, DoS Attack, 0, 150, 0, 3, [TCP-SCAN]#Optional#0#4, BAD TRAFFIC 0 ttl#Mandatory#0#40#10, BAD TRAFFIC loopback traffic#Mandatory#0#40#10
D.2 Sequential Results
This section details the logs of the prototype while operating on the sequential
scenario.
D.2.1 Normal
In this case, all the signatures fire as expected except for the two exploit
signatures, which are starved of the RPC portmap listing, SCAN Proxy (8080)
and BAD TRAFFIC 0 ttl alerts from the CuppenRPC, TCP-Scan and
DosAttack signatures. Note that due to the large amount of ports being
203
contacted by the DoS Attack, the TCP-Scan signature fires during the DoS
Attack period.
::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 1 has fired. It contained the following alerts: --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:43:37Z 2090 1 ids3-snort ICMP PING NMAP 2002-10-25T03:43:37Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:SCAN Proxy (8080) attempt Last Event:2002-10-25T03:44:00Z 50 52 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:44:00Z 131.181.97.101 131.181.97.31 8080 --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:44:03Z 4908 43 ids2-nids [TCP-SCAN] 2002-10-25T03:43:59Z 131.181.97.101 131.181.97.31 null 4929 48 ids2-nids [TCP-SCAN] 2002-10-25T03:44:03Z 131.181.97.101 131.181.97.31 null ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenFinger with sigid 2 has fired. It contained the following alerts: --- Alerts for Alert Name:FINGER root query Last Event:2002-10-25T03:44:16Z 2132 85 ids3-snort FINGER root query 2002-10-25T03:44:16Z 131.181.97.101 131.181.97.10 79 --- Alerts for Alert Name:[FINGER:ROOT] Last Event:2002-10-25T03:44:16Z 4991 64 ids3-nids [FINGER:ROOT] 2002-10-25T03:44:16Z 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:[DYNAMIC-TCP] Last Event:2002-10-25T03:44:16Z 4973 61 ids3-nids [DYNAMIC-TCP] 2002-10-25T03:44:06Z 131.181.97.77 131.181.97.10 null 4984 66 ids3-nids [DYNAMIC-TCP] 2002-10-25T03:44:16Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:44:17Z 2131 84 ids3-snort RPC portmap listing 2002-10-25T03:44:09Z 131.181.97.101 131.181.97.10 111 2140 88 ids3-snort RPC portmap listing 2002-10-25T03:44:17Z 131.181.97.101 131.181.97.10 111 --- Alerts for Alert Name:RPC portmap request mountd Last Event:2002-10-25T03:44:17Z 2139 89 ids3-snort RPC portmap request mountd 2002-10-25T03:44:17Z 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:44:28Z 2154 90 ids3-snort RSERVICES rlogin root 2002-10-25T03:44:28Z 131.181.97.101 131.181.97.10 513 --- Alerts for Alert Name:[RSH:ROOT] Last Event:2002-10-25T03:44:28Z 4994 70 ids3-nids [RSH:ROOT] 2002-10-25T03:44:28Z 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:44:16Z null null ids3-nids CUPPENS Finger Detect 2002-10-25T03:44:16Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:CUPPENS RPC Detect Last Event:2002-10-25T03:44:17Z null null ids3-snort CUPPENS RPC Detect 2002-10-25T03:44:17Z 131.181.97.101 131.181.97.10 111 ---
204
Alerts for Alert Name:CUPPENS Remote Login Detect Last Event:2002-10-25T03:44:28Z null null ids3-nids CUPPENS Remote Login Detect 2002-10-25T03:44:28Z 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:44:41Z 2134 82 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:09Z 127.0.0.1 131.181.97.10 161 80 78 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:11Z 127.0.0.1 131.181.97.31 161 2156 102 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:39Z 127.247.227.0 131.181.97.10 null 2160 109 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:39Z 127.53.77.0 131.181.97.10 46397 2179 126 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:39Z 127.247.31.0 131.181.97.10 null 2289 237 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:40Z 127.115.149.0 131.181.97.10 337 2299 248 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:40Z 127.221.78.0 131.181.97.10 383 2318 267 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:40Z 127.128.231.0 131.181.97.10 31706 2346 294 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:40Z 127.136.162.0 131.181.97.10 691 2535 483 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:41Z 127.243.82.0 131.181.97.10 1898 --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:44:41Z 2525 473 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 143.211.33.0 131.181.97.10 null 2526 474 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 216.111.255.0 131.181.97.10 null 2527 475 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 4.133.70.0 131.181.97.10 null 2528 476 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 72.49.232.0 131.181.97.10 null 2529 477 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 50.158.167.0 131.181.97.10 null 2530 478 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 65.192.41.0 131.181.97.10 null 2531 479 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 217.117.243.0 131.181.97.10 null 2532 480 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 157.104.238.0 131.181.97.10 null 2533 481 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 54.210.147.0 131.181.97.10 null 2534 482 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:41Z 165.187.85.0 131.181.97.10 null --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:44:39Z 5001 82 ids3-nids [TCP-SCAN] 2002-10-25T03:44:39Z 131.181. 97.10 131.181.97.101 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 16 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:44:46Z 3247 1195 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 193.177.5.0 131.181.97.10 null 3248 1196 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 244.242.104.0 131.181.97.10 null 3249 1197 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 26.97.22.0 131.181.97.10 null 3250 1198 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 45.189.93.0 131.181.97.10 null 3251 1199 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 171.111.190.0 131.181.97.10 null 3252 1201 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 22.235.96.0 131.181.97.10 null 3253 1200 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 36.252.42.0 131.181.97.10 null 3254 1202 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 166.222.9.0 131.181.97.10 null 3255 1203 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 179.191.127.0 131.181.97.10 null 3256 1204 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:46Z 221.22.12.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:44:46Z 2681 629 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:42Z 127.44.87.0 131.181.97.10 2619 2713 661 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:42Z 127.88.83.0 131.181.97.10 2992 2818 766 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:43Z 127.7.160.0 131.181.97.10 null 2880 825 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:43Z 127.226.107.0 131.181.97.10 3957 2951 899 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:44Z 127.73.186.0 131.181.97.10 null 3008 956 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:44Z 127.182.81.0 131.181.97.10 60061 3114 1062 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:45Z 127.159.205.0 131.181.97.10 null 3174 1121 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:45Z 127.130.44.0 131.181.97.10 34648 3244 1192 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:46Z 127.86.242.0 131.181.97.10 null 3257 1205 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:46Z 127.134.208.0 131.181.97.10 31789 ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 17 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:44:50Z
205
3691 1647 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 241.3.123.0 131.181.97.10 null 3692 1644 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 74.170.56.0 131.181.97.10 null 3693 1643 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 92.33.255.0 131.181.97.10 null 3694 1636 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 193.207.35.0 131.181.97.10 null 3695 1634 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 239.76.41.0 131.181.97.10 null 3696 1631 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 199.47.173.0 131.181.97.10 null 3697 1630 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 238.119.119.0 131.181.97.10 null 3698 1629 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 117.98.147.0 131.181.97.10 null 3699 1642 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 222.29.2.0 131.181.97.10 null 3700 1638 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:50Z 166.122.241.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:44:50Z 3290 1238 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:46Z 127.229.79.0 131.181.97.10 7407 3312 1260 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:47Z 127.176.6.0 131.181.97.10 56765 3352 1290 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:47Z 127.0.107.0 131.181.97.10 38049 3476 1426 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:48Z 127.192.199.0 131.181.97.10 58088 3490 1438 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:48Z 127.26.228.0 131.181.97.10 null 99 103 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:49Z 127.205.144.0 131.181.97.31 23 109 107 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:49Z 127.148.28.0 131.181.97.31 null 3643 1592 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:49Z 127.169.142.0 131.181.97.10 24 3662 1607 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:49Z 127.220. 82.0 131.181.97.10 null 3701 1637 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:50Z 127.252.11.0 131.181.97.10 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:44:53Z 734 735 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 194.47.139.0 131.181.97.31 null 735 736 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 48.27.212.0 131.181.97.31 null 736 737 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 39.134.33.0 131.181.97.31 null 737 738 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 182.242.210.0 131.181.97.31 null 738 739 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 167.159.223.0 131.181.97.31 null 739 740 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 87.222.93.0 131.181.97.31 null 740 741 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 5.61.37.0 131.181.97.31 null 741 742 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 119.77.128.0 131.181.97.31 null 742 743 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 205.25.153.0 131.181.97.31 null 743 744 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:53Z 152.30.94.0 131.181.97.31 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:44:53Z 392 393 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:51Z 127.142.151.0 131.181.97.31 null 432 433 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:51Z 127.69.168.0 131.181.97.31 751 3819 1794 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:51Z 127.68.29.0 131.181.97.10 1214 3857 1813 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:51Z 127.143.124.0 131.181.97.10 null 675 676 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:52Z 127.125.143.0 131.181.97.31 1947 703 704 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:52Z 127.219.119.0 131.181.97.31 36502 722 723 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:52Z 127.170.172.0 131.181.97.31 13942 3924 1865 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:52Z 127.190.253.0 131.181.97.10 null 3975 1927 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:52Z 127.34.26.0 131.181.97.10 null 744 745 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:53Z 127.119.62.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:44:55Z 4328 2280 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 37.49.191.0 131.181.97.10 null 4329 2279 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 196.144.82.0 131.181.97.10 null 4330 2278 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 101.137.199.0 131.181.97.10 null 4331 2281 ids 3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 236.243.102.0 131.181.97.10 null 4332 2273 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 240.156.164.0 131.181.97.10 null 4333 2282 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 155.116.62.0 131.181.97.10 null 4334 2266 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 166.118.209.0 131.181.97.10 null 4335 2289 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 59.50.74.0 131.181.97.10 null 4336 2288 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 18.66.97.0 131.181.97.10 null 4337 2287 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:55Z 18.156.145.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic
206
Last Event:2002-10-25T03:44:55Z 785 787 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:53Z 127.31.122.0 131.181.97.31 5544 890 892 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:53Z 127.34.240.0 131.181.97.31 null 4117 2066 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:53Z 127.100.180.0 131.181.97.10 3625 943 944 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:54Z 127.51.242.0 131.181.97.31 3096 4218 2171 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:54Z 127.197.239.0 131.181.97.10 null 1086 1087 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:55Z 127.78.198.0 131.181.97.31 null 1089 1090 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:55Z 127.184.252.0 131.181.97.31 3788 1151 1152 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:55Z 127.183.235.0 131.181.97.31 4229 4300 2256 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:55Z 127.109.59.0 131.181.97.10 33118 4338 2286 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:55Z 127.54.206.0 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 20 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:44:58Z 4634 2583 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 94.82.158.0 131.181.97.10 null 4635 2584 ids 3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 30.4.15.0 131.181.97.10 null 4636 2585 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 110.87.92.0 131.181.97.10 null 4637 2586 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 98.93.115.0 131.181.97.10 null 4638 2587 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 52.184.83.0 131.181.97.10 null 4639 2589 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 113.209.6.0 131.181.97.10 null 4640 2590 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 198.201.116. 0 131.181.97.10 null 4641 2591 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 231.208.150.0 131.181.97.10 null 4642 2592 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 191.121.13.0 131.181.97.10 null 4643 2588 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:44:58Z 26.172.243.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:44:58Z 4355 2303 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:55Z 127.148.64.0 131.181.97.10 5794 4366 2314 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:55Z 127.155.149.0 131.181.97.10 46951 1244 1245 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:56Z 127.14.175.0 131.181.97.31 65009 1283 1284 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:56Z 127.76.78.0 131.181.97.31 13808 4415 2363 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:56Z 127.143.2.0 131.181.97.10 36570 4500 2449 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:56Z 127.142.90.0 131.181.97.10 17948 1427 1428 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:57Z 127.63.244.0 131.181.97.31 5855 1623 1624 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:58Z 127.219.178.0 131.181.97.31 null 1651 1652 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:58Z 127.124.254.0 131.181.97.31 45304 4645 2594 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:58Z 127.66.235.0 131.181.97.10 35691
D.2.2 Exploits
This section concerns the exploit-tuned experiment with different
prioritisation. 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 (the full Cuppens Signature) and the
DosAttack signatures do not fire in this case.
::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 1 has fired. It contained the following alerts: --- Alerts for Alert Name:ICMP PING NMAP Last Event:2002-10-25T03:43:37Z 2090 1 ids3-snort ICMP PING NMAP 2002-10-25T03:43:37Z 131.181.97.101 131.181.97.10 null --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:44:03Z 4908 43 ids2-nids [TCP-SCAN] 2002-10-25T03:43:59Z 131.181.97.101 131.181.97.31 null 4929 48 ids2-nids [TCP-SCAN] 2002-10-25T03:44:03Z 131.181.97.101 131.181.97.31 null --- Alerts for Alert Name:SCAN Proxy (8080) attempt
207
Last Event:2002-10-25T03:44:09Z 2133 83 ids3-snort SCAN Proxy (8080) attempt 2002-10-25T03:44:09Z 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:44:12Z 77 79 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:44:12Z 131.181.97.101 131.181.97.31 8080 --- Alerts for Alert Name:RPC portmap listing Last Event:2002-10-25T03:44:12Z 79 80 ids2-snort RPC portmap listing 2002-10-25T03:44:12Z 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:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:44:11Z 80 78 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:44:11Z 127.0.0.1 131.181.97.31 161 --- Alerts for Alert Name:[SSH:VERSION-1] Last Event:2002-10-25T03:44:11Z 5004 63 ids3-nids [SSH:VERSION -1] 2002-10-25T03:44:11Z 131.181.97.10 131.181.97.101 null --- Alerts for Alert Name:Exploit Step 2 Detect Last Event:2002-10-25T03:44:12Z null null ids2-snort Exploit Step 2 Detect 2002-10-25T03:44:12Z 131.181.97.101 131.181.97.31 111 ::::::::::::::::::::::::::::::::::::::::::: Alert CuppenFinger with sigid 2 has fired. It contained the following alerts: --- Alerts for Alert Name:FINGER root query Last Event:2002-10-25T03:44:16Z 2132 85 ids3-snort FINGER root query 2002-10-25T03:44:16Z 131.181.97.101 131.181.97.10 79 --- Alerts for Alert Name:[FINGER:ROOT] Last Event:2002-10-25T03:44:16Z 4991 64 ids3-nids [FINGER:ROOT] 2002-10-25T03:44:16Z 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:44:28Z 2154 90 ids3-snort RSERVICES rlogin root 2002-10-25T03:44:28Z 131.181.97.101 131.181.97.10 513 --- Alerts for Alert Name:[RSH:ROOT] Last Event:2002-10-25T03:44:28Z 4994 70 ids3-nids [RSH:ROOT] 2002-10-25T03:44:28Z 131.181.97.101 131.181.97.10 null
D.3 Sequential with Background Traffic Results
This section is similar to Section D.2, except tha t it relates to the experiment
using the sequential with background traffic scenario. The same format and
structure are used here as in D.2.
Note that this scenario required CuppenRemoteLogin to have the second
element optional, rather than mandatory.
D.3.1 Normal
In this case, all the signatures fire as per the sequential scenario.
208
::::::::::::::::::::::::::::::::::::::::::: Alert TCPScan with sigid 1 has fired. It contained the following alerts: --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:50:02Z 165 99 ids3-nids [TCP-SCAN] 2002-10-25T03:50:00Z 131.181.110.4 131.181.97.10 null 29 30 ids2-nids [TCP-SCAN] 2002-10-25T03:50:02Z 131.181.97.101 131.181.97.31 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:02Z 417 41 ids2-snort SCAN Proxy (8080) attempt 2002-10-25T03:50:02Z 131.181.97.101 131.181.97. 31 8080 ::::::::::::::::::::::::::::::::::::::::::: 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 ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 3 has fired. It contained the following alerts: --- Alerts for Alert Name:[TCP-SCAN] Last Event:2002-10-25T03:50:49Z 349 272 ids3-nids [TCP-SCAN] 2002-10-25T03:50:49Z 131.181.110.4 131.181.97.10 null ---
209
Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:50:49Z 423 58 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:14Z 127.0.0.1 131.181.97.31 161 2916 523 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:43Z 127.136.245.0 131.181.97.10 null 2920 527 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:43Z 127.167.12.0 131.181.97.10 null 2956 564 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:44Z 127.125.170.0 131.181.97.10 null 3022 629 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:45Z 127.231.138.0 131.181.97.10 13578 3075 683 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:46Z 127.177.202.0 131.181.97.10 4575 3114 721 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:46Z 127.19.177.0 131.181.97.10 8847 3229 836 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:48Z 127.182.35.0 131.181.97.10 null 3267 874 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:48Z 127.19.244.0 131.181.97.10 40418 3285 892 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:49Z 127.71.28.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:50:49Z 3275 882 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 19.61.173.0 131.181.97.10 null 3276 883 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 135.43.147.0 131.181.97.10 null 3277 884 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 135.159.143.0 131.181.97.10 null 3278 885 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 38.49.209.0 131.181.97.10 null 3279 886 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 86.151.181.0 131.181.97.10 null 3280 887 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 185.121.61.0 131.181.97.10 null 3281 888 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 70.84.184.0 131.181.97.10 null 3282 889 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 53.110.200.0 131.181.97.10 null 3283 890 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 74.52.27.0 131.181.97.10 null 3284 891 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:49Z 82.140.116.0 131.181.97.10 null ::::::::::::::::::::::::::::::::::::::::::: Alert DosAttack with sigid 17 has fired. It contained the following alerts: --- Alerts for Alert Name:BAD TRAFFIC 0 ttl Last Event:2002-10-25T03:50:55Z 3650 1258 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 103.216.208.0 131.181.97.10 null 3651 1259 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 35.13.23.0 131.181.97.10 null 3652 1260 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 2.95.71.0 131.181.97.10 null 3653 1261 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 147.30.94.0 131.181.97.10 null 3654 1262 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 244.199.41.0 131.181.97.10 null 3655 1263 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 221.182.128.0 131.181.97.10 null 3656 1264 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 125.49.64.0 131.181.97.10 null 3657 1265 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 163.135.92.0 131.181.97.10 null 3658 1266 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 78.41.18.0 131.181.97.10 null 3659 1267 ids3-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:55Z 204.16.114.0 131.181.97.10 null --- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:50:55Z 459 107 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:50Z 127.124.106.0 131.181.97.31 7479 602 249 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:50Z 127.47.19.0 131.181.97.31 190 773 420 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:51Z 127.255.117.0 131.181.97.31 null 3419 1027 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:51Z 127.227.63.0 131.181.97.10 1084 963 610 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:52Z 127.178.247.0 131.181.97.31 null 1044 691 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:52Z 127.123.63.0 131.181.97. 31 1156 1097 745 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:53Z 127.197.213.0 131.181.97.31 53390 1236 883 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:53Z 127.153.21.0 131.181.97.31 null 3606 1214 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:54Z 127.78.20.0 131.181.97.10 48443 3660 1268 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:55Z 127.174.197.0 131.181.97.10 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:50:59Z 2117 1765 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 94.18.18.0 131.181.97.31 null 2118 1766 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 202.182.57.0 131.181.97.31 null 2119 1767 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 254.159.120.0 131.181.97.31 null 2120 1768 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 85.46.250.0 131.181.97.31 null 2121 1769 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 239.150.225.0 131.181.97.31 null 2122 1770 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 119.15.96.0 131.181.97.31 null 2123 1771 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 204.64.24.0 131.181.97.31 null 2124 1772 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 13.203.132.0 131.181.97.31 null 2125 1773 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 9.2.149.0 131.181.97.31 null 2126 1774 ids2-snort BAD TRAFFIC 0 ttl 2002-10-25T03:50:59Z 123.154.233.0 131.181.97.31 null
210
--- Alerts for Alert Name:BAD TRAFFIC loopback traffic Last Event:2002-10-25T03:50:59Z 3751 1359 ids3-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:56Z 127.56.121.0 131.181.97.10 53830 1912 1559 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50: 57Z 127.98.139.0 131.181.97.31 35675 1932 1580 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:58Z 127.126.134.0 131.181.97.31 4891 1978 1626 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:58Z 127.7.160.0 131.181.97.31 62291 1990 1638 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:58Z 127.244.193.0 131.181.97.31 26485 2001 1649 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:58Z 127.176.231.0 131.181.97.31 4957 2007 1655 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:58Z 127.27.32.0 131.181.97.31 null 2023 1670 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:58Z 127.192.215.0 131.181.97.31 28404 2097 1745 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:59Z 127.69.225.0 131.181.97.31 6680 2127 1775 ids2-snort BAD TRAFFIC loopback traffic 2002-10-25T03:50:59Z 127.215.213.0 131.181.97.31 49421
D.3.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 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
background traffic.
4 Unique Analyzers 71 Unique Names 3587 Unique Sources 5 Unique Targets 76 Unique Ports 78 Unique Times 6 TimeClusters Found using Difference 2 6 clusters **************1******************** --ids2-nids-- [HEARTBEAT],1,2002-10-25T03:49:27Z,2002-10-25T03:49:27Z **************2******************** --ids3-nids-- [HEARTBEAT],1,2002-10-25T03:49:32Z,2002-10-25T03:49:32Z [DNS:ANY-UDP],1,2002-10-25T03:49:32Z,2002-10-25T03:49:32Z **************3******************** --ids3-nids-- [DYNAMIC-TCP],25,2002-10-25T03:49:35Z,2002-10-25T03:49:35Z [FTP:BAD-LOGIN],1,2002-10-25T03:49:35Z,2002-10-25T03:49:35Z [TCP-SCAN],1,2002-10-25T03:49:35Z,2002-10-25T03:49:35Z [SSH:HIGHPORT],2,2002-10-25T03:49:35Z,2002-10-25T03:49:35Z [DNS:ANY-UDP],4,2002-10-25T03:49:35Z,2002-10-25T03:49:35Z **************4******************** --ids2-nids-- [NOOP:SPARC],1,2002-10-25T03:49:39Z,2002-10-25T03:49:39Z [DYNAMIC-TCP],11,2002-10-25T03:49:42Z,2002-10-25T03:50:19Z [NOOP:SPARC2],1,2002-10-25T03:49:55Z,2002-10-25T03:49:55Z [TCP-FLAGS],16,2002-10-25T03:49:39Z,2002-10-25T03:50:06Z [WEB:ROBOTS],2,2002-10-25T03:49:50Z,2002-10-25T03:50:19Z [SSH:VERSION-1],1,2002-10-25T03:50:15Z,2002-10-25T03:50:15Z
228
[TCP-SCAN],2,2002-10-25T03:50:02Z,2002-10-25T03:50:05Z [DYNAMIC-ICMP],7,2002-10-25T03:49:41Z,2002-10-25T03:50:03Z --ids3-nids-- [DNS:ANY-UDP],67,2002-10-25T03:49:39Z,2002-10-25T03:50:19Z [TCP-FLAGS],19,2002-10-25T03:49:40Z,2002-10-25T03:50:07Z [DYNAMIC-ICMP],2,2002-10-25T03:49:53Z,2002-10-25T03:50:09Z [TCP-SCAN],15,2002-10-25T03:49:39Z,2002-10-25T03:50:18Z [DYNAMIC-UDP],1,2002-10-25T03:49:56Z,2002-10-25T03:49:56Z [SSH:HIGHPORT],15,2002-10-25T03:49:44Z,2002-10-25T03:50:16Z [DYNAMIC-TCP],38,2002-10-25T03:49:50Z,2002-10-25T03:50:17Z [DNS:ZONEXFER],1,2002-10-25T03:49:47Z,2002-10-25T03:49:47Z [DOS-SYNDROP],1,2002-10-25T03:49:38Z,2002-10-25T03:49:38Z [WEB:UNAUTH],1,2002-10-25T03:50:04Z,2002-10-25T03:50:04Z [OVERFLOW:LINUX],2,2002-10-25T03:49:40Z,2002-10-25T03:49:54Z [WEB:ROBOTS],1,2002-10-25T03:49:50Z,2002-10-25T03:49:50Z [SSH:VERSION-1],2,2002-10-25T03:50:00Z,2002-10-25T03:50:00Z [FINGER:ROOT],1,2002-10-25T03:50:17Z,2002-10-25T03:50:17Z --ids3-snort-- WEB-FRONTPAGE /_vti_bin/ access,1,2002-10-25T03:50:00Z,2002-10-25T03:50:00Z SMTP exchange mime DOS,1,2002-10-25T03:49:59Z,2002-10-25T03:49:59Z Virus - SnowWhite Trojan Incoming,1,2002-10-25T03:50:07Z,2002-10-25T03:50:07Z SCAN Proxy (8080) attempt,1,2002-10-25T03:50:12Z,2002-10-25T03:50:12Z BACKDOOR QAZ Worm Client Login access,1,2002-10-25T03:49:38Z,2002-10-25T03:49:38Z WEB-MISC netscape servers suite DOS,1,2002-10-25T03:49:54Z,2002-10-25T03:49:54Z BACKDOOR GateCrasher,2,2002-10-25T03:49:39Z,2002-10-25T03:49:54Z Virus - Possible Worm - jpg.vbs file,1,2002-10-25T03:49:44Z,2002-10-25T03:49:44Z Virus - Possible MyPics Worm,3,2002-10-25T03:49:48Z,2002-10-25T03:49:55Z Virus - Possible Worm - xls.vbs file,2,2002-10-25T03:49:41Z,2002-10-25T03:50:06Z DDOS mstream client to handler,1,2002-10-25T03:49:47Z,2002-10-25T03:49:47Z ICMP PING NMAP,1,2002-10-25T03:49:38Z,2002-10-25T03:49:38Z Virus - Possible Pikachu Pokemon Virus,1,2002-10-25T03:49:46Z,2002-10-25T03:49:46Z WEB-MISC http directory traversal,3,2002-10-25T03:49:39Z,2002-10-25T03:49:54Z BACKDOOR SatansBackdoor.2.0.Beta,1,2002-10-25T03:49:42Z,2002-10-25T03:49:42Z TELNET not on console,1,2002-10-25T03:49:51Z,2002-10-25T03:49:51Z RPC portmap listing,2,2002-10-25T03:50:12Z,2002-10-25T03:50:17Z Virus - Possible BADASS Worm,1,2002-10-25T03:49:46Z,2002-10-25T03:49:46Z Virus - Mail .VBS,1,2002-10-25T03:49:41Z,2002-10-25T03:49:41Z ATTACK RESPONSES id check returned root,2,2002-10-25T03:49:51Z,2002-10-25T03:49:56Z Virus - Possible ExploreZip.B Worm,1,2002-10-25T03:49:43Z,2002-10-25T03:49:43Z RPC portmap request mountd,2,2002-10-25T03:50:18Z,2002-10-25T03:50:18Z FINGER root query,1,2002-10-25T03:50:17Z,2002-10-25T03:50:17Z BACKDOOR Infector.1.x,1,2002-10-25T03:49:56Z,2002-10-25T03:49:56Z Virus - Possible Worm - txt.vbs file,1,2002-10-25T03:49:47Z,2002-10-25T03:49:47Z RPC EXPLOIT statdx,1,2002-10-25T03:49:57Z,2002-10-25T03:49:57Z
229
BAD TRAFFIC udp port 0 traffic,24,2002-10-25T03:49:39Z,2002-10-25T03:50:07Z BACKDOOR PhaseZero Server Active on Network,2,2002-10-25T03:49:41Z,2002-10-25T03:49:52Z --ids2-snort-- WEB-FRONTPAGE /_vti_bin/ access,1,2002-10-25T03:50:00Z,2002-10-25T03:50:00Z SCAN Proxy (8080) attempt,2,2002-10-25T03:50:02Z,2002-10-25T03:50:14Z BAD TRAFFIC same SRC/DST,1,2002-10-25T03:49:54Z,2002-10-25T03:49:54Z WEB-MISC netscape servers suite DOS,1,2002-10-25T03:49:41Z,2002-10-25T03:49:41Z BACKDOOR BackOrifice access,1,2002-10-25T03:49:55Z,2002-10-25T03:49:55Z X11 outbound client connection detected,6,2002-10-25T03:50:00Z,2002-10-25T03:50:09Z DDOS Stacheldraht server-spoof,1,2002-10-25T03:49:49Z,2002-10-25T03:49:49Z DDOS TFN client command BE,1,2002-10-25T03:49:57Z,2002-10-25T03:49:57Z Virus - Possible Worm - jpg.vbs file,1,2002-10-25T03:49:45Z,2002-10-25T03:49:45Z ICMP PING NMAP,1,2002-10-25T03:49:38Z,2002-10-25T03:49:38Z SCAN Squid Proxy attempt,1,2002-10-25T03:50:03Z,2002-10-25T03:50:03Z BACKDOOR Doly 2.0 access,2,2002-10-25T03:49:50Z,2002-10-25T03:50:06Z WEB-MISC http directory traversal,2,2002-10-25T03:49:40Z,2002-10-25T03:49:58Z Virus - Possible Bubbleboy Worm,1,2002-10-25T03:49:55Z,2002-10-25T03:49:55Z BAD TRAFFIC loopback traffic,1,2002-10-25T03:50:14Z,2002-10-25T03:50:14Z RPC portmap listing,1,2002-10-25T03:50:14Z,2002-10-25T03:50:14Z Virus - Mail .VBS,1,2002-10-25T03:50:03Z,2002-10-25T03:50:03Z BACKDOOR DeepThroat 3.1 Keylogger Active on Network,1,2002-10-25T03:50:02Z,2002-10-25T03:50:02Z BACKDOOR NetSphere access,2,2002-10-25T03:49:52Z,2002-10-25T03:50:02Z Virus - Possible Worm - txt.vbs file,1,2002-10-25T03:49:48Z,2002-10-25T03:49:48Z Virus - Possible QAZ Worm,1,2002-10-25T03:49:54Z,2002-10-25T03:49:54Z BACKDOOR Infector 1.6 Client to Server Connection Request,1,2002-10-25T03:50:00Z,2002-10-25T03:50:00Z DDOS mstream handler to agent,1,2002-10-25T03:49:43Z,2002-10-25T03:49:43Z ICMP Destination Unreachable (Communication with Destination Network is Administratively Prohibited),1,2002-10-25T03:49:56Z,2002-10-25T03:49:56Z WEB-IIS cmd.exe access,2,2002-10-25T03:50:10Z,2002-10-25T03:50:10Z BAD TRAFFIC udp port 0 traffic,21,2002-10-25T03:49:39Z,2002-10-25T03:50:08Z Virus - Possible Common Sense Worm,1,2002-10-25T03:49:53Z,2002-10-25T03:49:53Z WEB-MISC ICQ Webfront HTTP DOS,1,2002-10-25T03:49:56Z,2002-10-25T03:49:56Z WEB-IIS ISAPI .ida attempt,1,2002-10-25T03:49:38Z,2002-10-25T03:49:38Z
230
SCAN SOCKS Proxy attempt,1,2002-10-25T03:50:02Z,2002-10-25T03:50:02Z **************5******************** --ids2-nids-- [DYNAMIC-TCP],15,2002-10-25T03:50:28Z,2002-10-25T03:50:33Z [WEB:ROBOTS],5,2002-10-25T03:50:28Z,2002-10-25T03:50:33Z --ids3-nids-- [DYNAMIC-TCP],5,2002-10-25T03:50:28Z,2002-10-25T03:50:31Z [WEB:ROBOTS],3,2002-10-25T03:50:28Z,2002-10-25T03:50:33Z [TCP-SCAN],4,2002-10-25T03:50:27Z,2002-10-25T03:50:34Z [DNS:ANY-UDP],15,2002-10-25T03:50:27Z,2002-10-25T03:50:36Z --ids3-snort-- RSERVICES rlogin root,1,2002-10-25T03:50:29Z,2002-10-25T03:50:29Z --ids2-snort-- WEB-FRONTPAGE _vti_rpc access,1,2002-10-25T03:50:35Z,2002-10-25T03:50:35Z WEB-IIS ISAPI .ida attempt,1,2002-10-25T03:50:31Z,2002-10-25T03:50:31Z **************6******************** --ids2-nids-- [DYNAMIC-TCP],3,2002-10-25T03:50:39Z,2002-10-25T03:50:39Z [WEB:ROBOTS],1,2002-10-25T03:50:39Z,2002-10-25T03:50:39Z [SSH:VERSION-1],1,2002-10-25T03:50:47Z,2002-10-25T03:50:47Z [TCP-SCAN],1,2002-10-25T03:50:50Z,2002-10-25T03:50:50Z --ids3-nids-- [DNS:ZONEXFER],1,2002-10-25T03:50:53Z,2002-10-25T03:50:53Z [DYNAMIC-TCP],3,2002-10-25T03:50:39Z,2002-10-25T03:50:39Z [WEB:ROBOTS],1,2002-10-25T03:50:39Z,2002-10-25T03:50:39Z [SSH:HIGHPORT],2,2002-10-25T03:50:44Z,2002-10-25T03:50:44Z [DNS:ANY-UDP],20,2002-10-25T03:50:38Z,2002-10-25T03:50:52Z [TCP-SCAN],31,2002-10-25T03:50:39Z,2002-10-25T03:50:59Z --ids3-snort-- BAD TRAFFIC 0 ttl,1433,2002-10-25T03:50:39Z,2002-10-25T03:50:59Z DOS Winnuke attack,2,2002-10-25T03:50:40Z,2002-10-25T03:50:53Z BAD TRAFFIC loopback traffic,15,2002-10-25T03:50:43Z,2002-10-25T03:50:59Z DNS zone transfer,1,2002-10-25T03:50:53Z,2002-10-25T03:50:53Z --ids2-snort-- BAD TRAFFIC 0 ttl,1961,2002-10-25T03:50:49Z,2002-10-25T03:51:00Z BAD TRAFFIC loopback traffic,17,2002-10-25T03:50:50Z,2002-10-25T03:51:00Z 3907 alerts total 11 different 10 second periods with alerts E.3 Simultaneous Scenario Clusters
This section details the clusters generated from the simultaneous scenario. In
this case, 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. Note that the larger number of alert
types is generated by Snort rather than Dragon, and that the majority of alerts
are still generated by the DoS attack under the alert name BAD Traffic
Loopback Traffic 0 ttl.
231
4 Unique Analyzers 54 Unique Names 5044 Unique Sources 4 Unique Targets 76 Unique Ports 38 Unique Times 2 TimeClusters Found using Difference 2 2 clusters **************1******************** --ids2-nids-- [HEARTBEAT],1,2002-10-25T03:52:45Z,2002-10-25T03:52:45Z **************2******************** --ids2-nids-- [NETBUS2],1,2002-10-25T03:53:16Z,2002-10-25T03:53:16Z [DYNAMIC-TCP],10,2002-10-25T03:53:15Z,2002-10-25T03:53:29Z [ICMP:TFN],2,2002-10-25T03:53:16Z,2002-10-25T03:53:16Z [DYNAMIC-UDP],1,2002-10-25T03:53:22Z,2002-10-25T03:53:22Z [TCP-FLAGS],19,2002-10-25T03:53:11Z,2002-10-25T03:53:28Z [SSH:VERSION-1],1,2002-10-25T03:53:01Z,2002-10-25T03:53:01Z [TCP-SCAN],3,2002-10-25T03:53:06Z,2002-10-25T03:53:27Z [DYNAMIC-ICMP],7,2002-10-25T03:53:11Z,2002-10-25T03:53:25Z --ids3-nids-- [NOOP:SPARC2],1,2002-10-25T03:53:21Z,2002-10-25T03:53:21Z [HEARTBEAT],1,2002-10-25T03:52:55Z,2002-10-25T03:52:55Z [TCP-FLAGS],19,2002-10-25T03:53:11Z,2002-10-25T03:53:31Z [DYNAMIC-ICMP],2,2002-10-25T03:53:10Z,2002-10-25T03:53:11Z [TCP-SCAN],3,2002-10-25T03:52:56Z,2002-10-25T03:53:12Z [NETBUS],1,2002-10-25T03:53:16Z,2002-10-25T03:53:16Z [DYNAMIC-TCP],18,2002-10-25T03:52:55Z,2002-10-25T03:53:27Z [NOOP:X862],1,2002-10-25T03:53:13Z,2002-10-25T03:53:13Z [NOOP:X86],1,2002-10-25T03:53:13Z,2002-10-25T03:53:13Z [WEB:MULTI-DOT-DOT],1,2002-10-25T03:53:23Z,2002-10-25T03:53:23Z [NOOP:SPARC],1,2002-10-25T03:53:17Z,2002-10-25T03:53:17Z [FINGER:ROOT],1,2002-10-25T03:52:55Z,2002-10-25T03:52:55Z [SSH:VERSION-1],1,2002-10-25T03:52:59Z,2002-10-25T03:52:59Z [RSH:ROOT],1,2002-10-25T03:53:08Z,2002-10-25T03:53:08Z [OVERFLOW:X86],1,2002-10-25T03:53:24Z,2002-10-25T03:53:24Z --ids3-snort-- SMTP exchange mime DOS,1,2002-10-25T03:53:19Z,2002-10-25T03:53:19Z ICMP redirect host,1,2002-10-25T03:53:17Z,2002-10-25T03:53:17Z SCAN Proxy (8080) attempt,1,2002-10-25T03:52:55Z,2002-10-25T03:52:55Z BAD TRAFFIC same SRC/DST,1,2002-10-25T03:53:30Z,2002-10-25T03:53:30Z DDOS TFN client command BE,1,2002-10-25T03:53:05Z,2002-10-25T03:53:05Z RSERVICES rlogin root,1,2002-10-25T03:53:08Z,2002-10-25T03:53:08Z Virus - Possible NAIL Worm,3,2002-10-25T03:53:14Z,2002-10-25T03:53:26Z WEB-MISC Allaire JRUN DOS attempt,1,2002-10-25T03:53:23Z,2002-10-25T03:53:23Z Virus - Possible MyPics Worm,1,2002-10-25T03:53:19Z,2002-10-25T03:53:19Z DDOS mstream client to handler,1,2002-10-25T03:53:19Z,2002-10-25T03:53:19Z ICMP PING NMAP,1,2002-10-25T03:53:01Z,2002-10-25T03:53:01Z WEB-MISC http directory traversal,2,2002-10-25T03:53:08Z,2002-10-25T03:53:09Z DDOS mstream handler to client,1,2002-10-25T03:53:24Z,2002-10-25T03:53:24Z
232
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.
4 Unique Analyzers 52 Unique Names 5009 Unique Sources 4 Unique Targets 65 Unique Ports 39 Unique Times 2 TimeClusters Found using Difference 2 2 clusters **************1******************** --ids2-nids-- [HEARTBEAT],1,2002-10-25T03:54:55Z,2002-10-25T03:54:55Z **************2******************** --ids2-nids-- [NETBUS2],1,2002-10-25T03:55:33Z,2002-10-25T03:55:33Z [DYNAMIC-TCP],11,2002-10-25T03:55:14Z,2002-10-25T03:55:38Z [ICMP:STACHELDRAHT],1,2002-10-25T03:55:28Z,2002-10-25T03:55:28Z [OVERFLOW:LINUX],1,2002-10-25T03:55:35Z,2002-10-25T03:55:35Z [TCP-FLAGS],19,2002-10-25T03:55:10Z,2002-10-25T03:55:38Z [SSH:VERSION-1],1,2002-10-25T03:55:08Z,2002-10-25T03:55:08Z [TCP-SCAN],3,2002-10-25T03:55:13Z,2002-10-25T03:55:36Z [DYNAMIC-ICMP],2,2002-10-25T03:55:28Z,2002-10-25T03:55:30Z --ids3-nids-- [HEARTBEAT],1,2002-10-25T03:55:02Z,2002-10-25T03:55:02Z [TCP-FLAGS],21,2002-10-25T03:55:11Z,2002-10-25T03:55:39Z [DYNAMIC-ICMP],4,2002-10-25T03:55:15Z,2002-10-25T03:55:30Z [TCP-SCAN],4,2002-10-25T03:55:03Z,2002-10-25T03:55:21Z [DYNAMIC-TCP],23,2002-10-25T03:55:02Z,2002-10-25T03:55:39Z [ICMP:STACHELDRAHT],1,2002-10-25T03:55:37Z,2002-10-25T03:55:37Z [UDP-SCAN],1,2002-10-25T03:55:03Z,2002-10-25T03:55:03Z [NOOP:X862],2,2002-10-25T03:55:15Z,2002-10-25T03:55:24Z [NOOP:SOLARIS],1,2002-10-25T03:55:14Z,2002-10-25T03:55:14Z [NOOP:X86],2,2002-10-25T03:55:15Z,2002-10-25T03:55:24Z [RSH:ROOT],1,2002-10-25T03:55:13Z,2002-10-25T03:55:13Z [SSH:VERSION-1],1,2002-10-25T03:55:04Z,2002-10-25T03:55:04Z [FINGER:ROOT],1,2002-10-25T03:55:02Z,2002-10-25T03:55:02Z
234
--ids3-snort-- Virus - SnowWhite Trojan Incoming,1,2002-10-25T03:55:38Z,2002-10-25T03:55:38Z DDOS Stacheldraht client-check,1,2002-10-25T03:55:29Z,2002-10-25T03:55:29Z SCAN Proxy (8080) attempt,1,2002-10-25T03:55:03Z,2002-10-25T03:55:03Z BAD TRAFFIC same SRC/DST,2,2002-10-25T03:55:17Z,2002-10-25T03:55:24Z RSERVICES rlogin root,1,2002-10-25T03:55:13Z,2002-10-25T03:55:13Z Virus - Possible MyPics Worm,1,2002-10-25T03:55:26Z,2002-10-25T03:55:26Z DDOS Stacheldraht server-response,1,2002-10-25T03:55:37Z,2002-10-25T03:55:37Z DDOS mstream client to handler,1,2002-10-25T03:55:28Z,2002-10-25T03:55:28Z ICMP PING NMAP,1,2002-10-25T03:55:09Z,2002-10-25T03:55:09Z BAD TRAFFIC loopback traffic,39,2002-10-25T03:55:02Z,2002-10-25T03:55:23Z Virus - Possible QAZ Worm Infection,1,2002-10-25T03:55:38Z,2002-10-25T03:55:38Z RPC portmap listing,3,2002-10-25T03:55:03Z,2002-10-25T03:55:03Z TELNET login incorrect,1,2002-10-25T03:55:39Z,2002-10-25T03:55:39Z Virus - Possbile Zipped Files Trojan,2,2002-10-25T03:55:16Z,2002-10-25T03:55:29Z RPC portmap request mountd,2,2002-10-25T03:55:03Z,2002-10-25T03:55:03Z BAD TRAFFIC 0 ttl,2921,2002-10-25T03:55:03Z,2002-10-25T03:55:23Z ICMP redirect net,2,2002-10-25T03:55:23Z,2002-10-25T03:55:31Z ICMP Destination Unreachable (Communication with Destination Network is Administratively Prohibited),1,2002-10-25T03:55:34Z,2002-10-25T03:55:34Z ICMP Destination Unreachable (Communication with Destination Host is Administratively Prohibited),2,2002-10-25T03:55:20Z,2002-10-25T03:55:28Z BACKDOOR BackConstruction 2.1 Server FTP Open Reply,1,2002-10-25T03:55:30Z,2002-10-25T03:55:30Z BAD TRAFFIC udp port 0 traffic,22,2002-10-25T03:55:10Z,2002-10-25T03:55:39Z DDOS mstream agent pong to handler,1,2002-10-25T03:55:26Z,2002-10-25T03:55:26Z WEB-MISC ICQ Webfront HTTP DOS,2,2002-10-25T03:55:15Z,2002-10-25T03:55:30Z DDOS mstream agent to handler,2,2002-10-25T03:55:19Z,2002-10-25T03:55:34Z --ids2-snort-- BACKDOOR DeepThroat 3.1 Client Sending Data to Server on Network,1,2002-10-25T03:55:29Z,2002-10-25T03:55:29Z SCAN Proxy (8080) attempt,2,2002-10-25T03:55:06Z,2002-10-25T03:55:30Z BAD TRAFFIC same SRC/DST,1,2002-10-25T03:55:27Z,2002-10-25T03:55:27Z BACKDOOR QAZ Worm Client Login access,1,2002-10-25T03:55:35Z,2002-10-25T03:55:35Z X11 outbound client connection detected,7,2002-10-25T03:55:26Z,2002-10-25T03:55:34Z Virus - Possible MyPics Worm,1,2002-10-25T03:55:37Z,2002-10-25T03:55:37Z BACKDOOR HackAttack 1.20 Connect,1,2002-10-25T03:55:27Z,2002-10-25T03:55:27Z
235
DDOS Stacheldraht server-response,1,2002-10-25T03:55:28Z,2002-10-25T03:55:28Z DDOS mstream client to handler,1,2002-10-25T03:55:34Z,2002-10-25T03:55:34Z ICMP PING NMAP,1,2002-10-25T03:55:09Z,2002-10-25T03:55:09Z SCAN Squid Proxy attempt,1,2002-10-25T03:55:33Z,2002-10-25T03:55:33Z WEB-MISC http directory traversal,1,2002-10-25T03:55:34Z,2002-10-25T03:55:34Z BAD TRAFFIC loopback traffic,15,2002-10-25T03:55:05Z,2002-10-25T03:55:24Z WEB-MISC PHP strings overflow,1,2002-10-25T03:55:39Z,2002-10-25T03:55:39Z RPC portmap listing,1,2002-10-25T03:55:06Z,2002-10-25T03:55:06Z BACKDOOR netbus active,1,2002-10-25T03:55:33Z,2002-10-25T03:55:33Z Virus - Possible Worm - txt.vbs file,2,2002-10-25T03:55:36Z,2002-10-25T03:55:36Z BAD TRAFFIC 0 ttl,1944,2002-10-25T03:55:13Z,2002-10-25T03:55:24Z BACKDOOR Infector 1.6 Client to Server Connection Request,1,2002-10-25T03:55:21Z,2002-10-25T03:55:21Z Virus - Possible Matrix worm,1,2002-10-25T03:55:32Z,2002-10-25T03:55:32Z ICMP redirect net,1,2002-10-25T03:55:28Z,2002-10-25T03:55:28Z Virus - Possible eurocalculator.exe file,1,2002-10-25T03:55:32Z,2002-10-25T03:55:32Z BAD TRAFFIC udp port 0 traffic,20,2002-10-25T03:55:10Z,2002-10-25T03:55:39Z SCAN SOCKS Proxy attempt,1,2002-10-25T03:55:34Z,2002-10-25T03:55:34Z 5123 alerts total 5 different 10 second periods with alerts