Content uploaded by Rida Khatoun
Author content
All content in this area was uploaded by Rida Khatoun on Jul 01, 2020
Content may be subject to copyright.
Decentralized alerts correlation approach for DDoS
intrusion detection
Rida Khatoun, Guillaume Doyen, Dominique Gaïti
Université de Technologie de Troyes
12, rue Marie Curie
10000 - Troyes, France
Email: rida.khatoun, guillaume.doyen, gaiti@utt.fr
Radwane Saad and Ahmed Serhrouchni
TELECOM ParisTech
46, rue Barrault
75013 - Paris, France
Email: ahmed, rsaad@telecom-paristech.fr
Abstract—Availability is one of the main characteristics of
internet security and hence attacks against networks increase
trying to stop services on servers. Distributed denial of service
attacks are very dangerous for computer networks and services
availability. Various defense systems were proposed. Unfortu-
nately, until now, there is no efficient solution. This paper presents
a decentralized architecture for an intrusion detection approach.
The central point of this paper is the alert correlation among
Snort intrusion detection systems (IDS). We believe that this
approach optimizes the detection performance in a completely
distributed fashion by relying on Pastry overlay network as
indexing and routing protocol. We propose novel approach that
will be improved in the future work.
I. INTRODUCTION
Networks security vulnerabilities are growing with the
exponentially increasing number of users using the Internet.
Organizations, companies and even individuals rely on
Internet to communicate with each other. Therefore, security
is becoming more than important for them. The importance
of these Internet services makes their resilience to attacks
and failures critical. The attacks, including Distributed
Denial-of-Service (DDoS) [7] and worms are getting more
sophisticated, more distributed and causing more damages.
Denials of service attacks are as old as the Internet itself,
and they continue to be a significant threat for today’s
Internet as they are growing in number and sophistication.
Recently, in 2007, Estonia were subject to massive and
coordinated cyber attacks on Web sites of the government,
banks, telecommunications companies, Internet service
providers (ISP) and news organizations. The services of
those Web sites were unavailable for hours and days [9].
In fact, they were very strong and fatal attacks. This is a
good example that demonstrates how damaging DDoS attacks
are. Nowadays, the network security is becoming primordial
for organizations and individuals; consequently, intrusion
detection and filtering are necessary for network security
protection. Since prevention does not eliminate the DDoS
threat, improving Internet security is necessary. To counter
DDoS attacks, there are two basic requirements: detection
propriety and traceback property. The first one refers to the
system capability to detect the attack traffic. The second
one is more difficult and refers to the system capability to
determine the attack sources. The problem of the detection is
the way to differentiate the normal traffic from the malicious
one. On the other hand, the problem of traceback is the
spoofed IP address. The distribution of attacks makes the
solution more difficult, and imposes a distributed system for
the solution.
In this paper, we treat the detection propriety by proposing a
decentralized alerts correlation approach for DDoS detection.
This approach relies on the Snort [3] intrusion detection
system in a fully distributed fashion. The basic idea of
our approach is to correlate in a decentralized way the
alerts produced by various intrusion detection systems and
provides a high-level view of attempted intrusions. This
decentralization is obtained using a distributed hash table
(DHT) which can route efficiently resource information about
the victims and share data on the claimed attacks among
peers. This scheme is more flexible and can scale to a very
large number of peers exchanging control messages without
adding an excess overhead to the whole system.
The coming parts of this paper are organized as follows: In
section 2, we describe the Architecture and the functionality
of the proposed approach. Section 3 evaluates the proposed
approach. In section 4, a survey of defense approaches is
presented. Finally, we outline future work and conclude in
Section 5.
II. GLOBAL INTRUSION DETECTION APPROACH
In DDoS context, the first step that should be taken in
consideration is the attack prevention. The first step to prevent
a DDoS attack is to prevent compromise and use of hosts as
agents for DDoS. To achieve this, network IDS have to detect
activities such as scanning. An attacker does not scan port on
a single machine but rather on many ones. A correlation of
alerts can certainly detect the sources of the intrusion. Hence,
the need for cooperation.
We propose a large scale intrusion detection system based
on a P2P architecture. In this new approach, each IDS su-
pervises its sub-network. Each of these IDSs is a peer in a
peer to peer system that forms global collaborative IDS (figure
1). Periodically, each detection system shares with other IDS
978-2-9532443-0-4 © 2008 ESRGroups France 1
Authorized licensed use limited to: Telecom ParisTech. Downloaded on July 01,2020 at 11:14:25 UTC from IEEE Xplore. Restrictions apply.
alerts about suspicious traffic detected on its sub-network.
An IDS such as Snort, with its default configuration files, it
generates a large number of alerts per day (depending on the
network), particularly with the ICMP messages and the packets
reassembly time-out relevant to stream4 Snort preprocessor.
However, some alerts occur frequently for the same event
during a short period of time. In Snort rules files, it is easy to
reduce the number of alerts for the same event, but in this case,
we increase the number of undetected alarms (negative false
alarm). To manage the process of exchanging alerts among
sensors, we propose the use of distributed hash table (DHT).
The DHT allows to the peers involved in this approach to
index and retrieve information about resources which means
a detection information table. The DHT is proposed to avoid
information multicasting.
IDS3
IDS7
IDS5IDS1
IDS4
IDS6
IDS2
IDS8
Alerts : (IPdest2,
IPsrc1, Pdest :
3372, 30)
Alerts : (IPdest1,
IPsrc1,
Pdest :3372, 10)
Alerts : (IPdest3,
IPsrc1,
Pdest :3372,15)
30Pdest : 3372IDS4
15Pdest : 3372IDS6
10Pdest : 3372IDS1
IP Source1
30Pdest : 3372IDS4
15Pdest : 3372IDS6
10Pdest : 3372IDS1
IP Source1
Fig. 1. Decentralized IDS architecture
A. Communication model
Peer to peer (P2P) communication model has certain
advantages such as scalability, robustness and cooperation
on a large scale. This model is a good candidate for the
design of a distributed solution to get an efficient reaction
against attacks which are themselves distributed. Nodes in a
peer to peer network have exactly the same functions and
are perfectly equal in their roles. They are able to form
a distributed and decentralized network with a dynamic
adaptation without affecting the whole functioning of the
network. The distribution of data storage among several nodes
gives the P2P model two main advantages when compared to
a centralized one: reducing the possibility of storage overload
at some points and the absence of a single point of failure.
Many P2P solutions have been proposed that can be
classified into structured and non-structured ones regarding
resource localization methods. Most of structured approaches
are based on hash tables which in their turn can be centralized
or distributed. Distributed Hash Table (DHT) is used in many
applicative routing solutions such as Chord [13] and Pastry
[11] : an important advantage of these solutions is the
robustness since the global functioning of the network is
totally independent of each application node.
In order to design a secured cooperative model, we must
have a secured access to the nodes in order to protect them
against intrusions and attacks. Our communication model is
immune since it relies on a secure distributed hash table DHT.
The immunity is due to a keyed-Hash Message Authentication
Code (HMAC) which is a type of Message Authentication
Code (MAC) calculated using a specific algorithm involving a
cryptographic hash function in combination with a secret key.
This secret key is shared among the IDS and each primitive
used in the DHT core must contain this authentication key.
In fact, we can ensure that for any victim in the network,
one node will store traffic information about this victim. These
information can be certainly replicated on other nodes by
the replication function [2] of the DHT. This is a method
that prevents possible attacks on a node having a victim
information table. Even if any central entity collects all the
data, the nodes can be prone to attack. This is why it is
important to copy all victims information on other nodes of the
ring. If any node on the ring needs to retrieve information kept
by another node, the get function [2] is used after a lookup
for the Id of this particular node.
In addition, the failure of a node appears immediately
in the routing table of its neighbors because each node,
periodically, sends a maintenance messages to all the nodes in
its neighbourhood, indicating that it is still alive. If a node is
not responding for some period, the message towards this node
will be forwarded to another which is numerically closer to the
Id of this node. In Pastry, this event does not normally delay
the routing of a message since the latter can be forwarded to
another node.
B. Detection algorithm
At each monitoring time interval δ, each IDS references
its alerts in the peer to peer system using the source IP
address as a key. We chose the source as key since its IP is
unchanged during the activities. We use an example in Figure
1 to explain our approach. There are eight IDSs participating
in this collaboration. As shown in this figure, after δsecond,
each IDS references its alerts.
•IDS1: IPdest1, Pdest:3372, IPsrc1, 10
•IDS4: IPdest2, Pdest:3372, IPsrc1, 30
•IDS6: IPdest3, Pdest:3372, IPsrc1, 15
IDS1, IDS4 and IDS6 references their alerts on the system
and lookup for the same alerts having the same source IP
in the system. Each of these IDSs will find that two other
IDSs have the same alerts for the same source. At the end
of this correlation, each IDS will be sure that the source
address IPsrc made a malicious activity on some machines
in the network. It can block this activity using the rules of
the detection engine. The correlation can be used to identify
an attack on the Microsoft Distributed Transaction Service on
various networks. As mentioned in [3], this event is generated
when a TCP packet having a large payload was detected.
An attacker needs to generate a packet with a payload in
excess of 1023 bytes and send it to port 3372 of an affected
system, which cause a denial of service attack against a
2
Authorized licensed use limited to: Telecom ParisTech. Downloaded on July 01,2020 at 11:14:25 UTC from IEEE Xplore. Restrictions apply.
host running the Microsoft Distributed Transaction Service
Coordinator (MSDTC). The same activity on various network
will be detected by alert correlation without false positive
possibility. In fact, alerts correlation allows gathering events
from different sources such as IDS and then correlating them.
The correlation gives a better detection efficiently than one
alert generated by only one IDS.
Algorithm 1 Global IDS detection algorithm
1: IPsrc: source IP address
2: IPdest: destination IP address
3: Pdest: destination port
4: β: alerts threshold for a source during δseconds
5: LIPsrc : alerts concerning one IP source
6: δ: time interval in seconds
7: α: number of IDSs which generate the same alerts
8: for each time interval δdo
9: extract a list Lof alerts
10: for each source IP address in Ldo
11: if alertsnumber > β then
12: 1- Hash the source IP to get the key
13: 2- Insert alerts to LIPsrc on the system at the peer
which has the closet identifient to this key
14: 3- At the same peer collect alerts locally and put
them in local alert lists LAi
15: if IDSnumber > α then
16: generate a super intrusion alert to the network
administrator
17: else
18: generate a standard alert
19: end if
20: else
21: generate a standard alert
22: end if
23: end for
24: end for
This algorithm is only useful for the attack’s prevention, but
during the attack another detection algorithm must be used.
Hence, we describe a statistical anomaly detection algorithm
which can exhibit robust performance over various attack
types, without necessarily being complex to be implemented.
In this algorithm, we take an example of detection of ICMP
flooding attack. When an ICMP flooding against a server
starts, there will be a huge number of ICMP packets toward the
server. For that, we propose the following method: during a pe-
riod of observation δ, we monitor the destination IP addresses
according to a prefix (p) in these IPs. In fact, we chose a prefix
because monitoring all destinations, is too costly in terms of
computing time and memory. Then, we calculate for these
destinations their moving averages. Our detection method
relies on the exponentially weighted moving average (EWMA)
which applies weighting factors to data points which are the
number of ICMP during a period of time. The weighting for
each older data point decreases exponentially, giving much
more importance to recent observations without discarding
older observations entirely. The formula for calculating the
EWMA during a period is given by:
¯μd
n(ICMP)=¯μd
n−1(ICMP)×α+(1−α)×Nn
d
ICMP (1)
After these calculations and during the other periods, we
get the mostly frequented destinations in order to analyze their
intentions. Consequently, to detect a flooding attacks against
the server, this condition must be satisfied: Nn
d
ICMP ≥(1 +
β)ׯμd
n(ICMP), thus an alarm is generated. The parameters
of these two formulas are featured as follows:
Detection parameters
αconstant smoothing factor 0<α<1
βconstant detection factor β>0
¯μd
n(ICMP)mean rate estimated in n-1 periods -
III. EXPERIMENTS
To further examine our system performance, we have
implemented our approach over a real network. In this
section, we will explain practically how and why IDS should
cooperate together. In fact, we implemented separately two
experiments. The first one [1] allowed to evaluate the snort
alerts correlation in intrusion detection. The second one has
tried to evaluate the communication model between peers
exchanging some detection parameters such as ratios. The
approach was developed using the core Java programming
libraries and FreePastry [12] which is the open source
implementation of Pastry.
At first, we present the test environment used in our imple-
mentation, and then we describe the implementation part, by
showing some curves. The used infrastructure is illustrated in
figure 2; it is composed of 8 machines where Snort and Pastry
were installed.
Fig. 2. Experiments environment
The links capacity between the machines is 100 Mbps. The
Snort IDS are configured to capture all traffic on the Ethernet
network. They are installed with their default configuration file
as well as the basic rules file.
3
Authorized licensed use limited to: Telecom ParisTech. Downloaded on July 01,2020 at 11:14:25 UTC from IEEE Xplore. Restrictions apply.
In our test, the outbound IP packet size carrying the ICMP
request-reply message was 20 Kbytes. The size of header
fields of the ICMP message is 8 bytes and the IP header
is 20 bytes. To crash the victim in our network, we need
to send approximately 600 ICMP messages per second, such
as each ICMP message has size of 20 Kbytes. We used two
machines to attack a victim using ICMP messages flooding
attack. We used several rates of flooding in this test. As shown
in figure 3, with its default configuration, Snort generates a
large number of alerts during an ICMP flooding period. For
example, when the two attacking machines attacked the victim
by 4000 packets/s with a message size of 10 KBytes, Snort
generated 671 alerts. On another hand, when we increased the
size of the ICMP messages to 15 Kbytes, Snort generated less
alarms. This is due to the fact that the victim was crashed with
6000 messages/s, and that exactly 66% of the messages which
were sent towards the victim were lost, and thus not treated
by Snort.
Snort performance with ICMP attack
0
200
400
600
800
1000
1000 2000 3000 4000 5000
Number of PING
Number of alerts
5k Ping 10k Ping 15k Ping
Fig. 3. Snort alerts generation under ICMP flooding
In the mean time, the log files sizes reported by Snort
grow critically for one attack. For example, when the attack
rate was 5000 messages/s and the size of the message was
10 KBytes, Snort generated an 8 MBytes log file. With this
experimentation Snort alerts correlation demonstrated the
capacity to reduce the alarm number. With a rate of 3000
messages/s, only 8 correlated alerts were generated with
the correlation which drastically decreased the log file size
to only a few Kbytes. On the other hand, 466 alerts were
generated by standard Snort with the same rate.
The second experiment showed the communication model
efficiency between peers exchanging some detection parame-
ters such as ratios. The P2P communication model was devel-
oped using the core Java programming libraries and FreePastry
[12] P2P framework. We present this model experiment in the
context as a communiction layer. In this paper, we present a
single type of attack used during this experiment; the attack
ICMP flooding.
The Figure 4 shows that the ICMP messages arrival rate is
too high during the observation period (δ) compared to the
Time (sec)
ICMP Packets Ratio
Fig. 4. Traffic ratio variation during ICMP flooding
victim bandwidth. The ICMP flow has increased to 75 % of
flow towards victim, which is abnormal. The occurrence of
packets passed through the IDS 10.23.0.225, 10.23.0.226 and
10.23.0.228 towards 10.23.0.27 were referenced in a peer in
the Pastry ring (implicitly in an IDS machine). If an IDS wants
the alerts generated by all the IDS about the traffic towards
10.23.0.227, it just hash the IP address and then its Pastry peer
will find these information at a peer which has an identifier
closed digitally to the key of 10.23.0.27. The ICMP packets
arrival ratio will be exchanged between IDS as an ICMP DDoS
detection metric. The detection time is the sum of period δand
the time for obtaining alerts table. When δincreases a good
knowledge about the destination will be obtained. On the other
hand, the time of detection will increase. Table 1 shows the
min/average/max time for an alerts table query. These values
are taken after the local detection of the ICMP flooding during
δ. Hence, the detection time DT =δ+QT .
QT
Min 5ms
Average 13.08 ms
Max 17 ms
TAB L E I
QUERY TIME (QT) VARIANCES IN OUR Pastry RING
IV. RELATED WORK
In this section, some defense system concept are briefly
presented. Mahajan et al. [6] proposes pushback as a complete
method to deal with DoS. In this scheme, DoS attacks are
treated as a congestion-control problem. A new functionality
is added to each router to detect and preferentially drop
packets that probably belong to an attack. Upstream routers
are also notified to drop such packets (hence the term
pushback) in order that router resources can be used to
route legitimate traffic. The defense system is composed of
two subsystems, LACC (Local Aggregate-based Congestion
Control) and a protocol for routers to exchange information
(pushback messages). LACC is used to detect congestion
in the queue of a router, and it delays packets in order to
4
Authorized licensed use limited to: Telecom ParisTech. Downloaded on July 01,2020 at 11:14:25 UTC from IEEE Xplore. Restrictions apply.
rate-limit the flows that are responsible for the congestion.
The pushback messages are used by a router to request that
upstream routers rate-limit certain flows. This is an interesting
approach but to date only a prototype implementation on
FreeBSD exists. Router vendors did not show interest in
implementing this scheme.
Canonico et al. [10] use the same concept of pushback in
defense "propagation". They propose ASSYST, a distributed
system, in which network routers cooperate in order to
react against DoS attacks in a flexible and dynamic fashion.
ASSYST routers interact through a signaling protocol
named Active Security Protocol (ASP), which provides a
set of messages enabling router communication upon attack
recognition, in order to propagate the characteristics of the
suspicious session as well as the adopted defense strategies.
One of the main advantages of ASSYST is that it does not
require installation on all routers.
DefCOM [4] is a distributed collaborative framework to
defend against flooding DDoS attack. As a global architecture,
it combines the advantages of source-end, victim-end and
core defenses and allows the existing heterogeneous defense
systems to cooperate through an overlay. The overlay
facilitates communication among non-contiguously deployed
nodes. Nodes collaborate by exchanging messages, marking
packets for high or low priority handling, and prioritizing
marked traffic. Its design has an economic model where
networks deploying defense nodes directly benefit from their
operation. However, it was not clearly described how to
authenticate and establish economic cooperative relationship
across different management domains. Moreover, DefCOM
leverages the classifier nodes near the attack sources to
differentiate between legitimate and attack packets. However,
if attack’s packets have no distinct signature, then classifier
nodes will not work; unfortunately, the flooding-style attack
traffic produced by modern attack tools usually has no distinct
characteristics at the attack source end.
To detect DDoS attacks, signal processing techniques are
used [5] [8]. In [5], Kung et al. proposed spectral analysis
approach against DDoS. In [8], Mukkamala et al. proposed
machine learning technique in order to detect DDoS attacks.
The current defense systems are not efficient enough to
detect DDoS attacks. A new defense system must be pro-
posed. Hence, we propose a fully distributed architecture for
a detection based on Snort IDS in a peer to peer environment
for exchanging detection and control messages among peers
which are represented by the IDS.
V. C ONCLUSION
In this work, these results show the capacity of Snort
sensors cooperation for detecting the DDoS attacks in a
fully distributed environment. This work was not limited to
correlate alerts among sensors, but also to define a context
to allow secure communication among them. This work is
deduced from an analysis of various IDS approaches and
models with their pros and cons, the challenge consisted,
preserved the performances and the simplicity of IDS Snort.
It is intuitively well-known that to avoid the DDoS attacks,
a cooperation among various equipment, is necessary. Hence,
the cooperation between Snort IDS does a challenge. The first
implementation and the integration to Snort allowed validating
this approach, nevertheless a testing on large scale is necessary
to deduce the performance concretely.
REFERENCES
[1] T. Bullot, R. Khatoun, L. Hugues, D. Gaïti, and L. Merghem-Boulahia.
A Situatedness Based Knowledge Plane For Autonomic Networking.
ACM International Journal of Network Management, special issue on
NGN, 18(2):171–193, April 2008.
[2] F. Dabek, B. Zhao, P. Druschel, and I. Stoica. Towards a common api
for structured peer-to-peer overlays. In 2nd International Workshop on
Peer-to-Peer Systems (IPTPS’02), February 2003.
[3] C. Green and M. Roesch. Snort users manual 2.8.0 - the snort project.
Technical report, Aout 2007.
[4] J.Mirkovic, M.Robinson, P.Reiher, and G.Oikonomou. Distributed
defense against ddos attacks. Technical report, University of Delaware
CIS Department, 2005.
[5] C.C. Kung and H.T.K Tan. Use of spectral analysis in defense
against dos attacks. In Global Telecommunications Conference, 2002.
GLOBECOM ’02. IEEE, volume 3, pages 2143– 2148, 17-21 Nov. 2002.
[6] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and
S. Shenker. Aggregate congestion control. SIGCOMM Comput.
Commun. Rev., 32(1):69–69, 2002.
[7] J. Mirkovic. D-WARD: source-end defense against distributed denial-
of-service attacks. PhD thesis, University of California, Los Angeles,
August 2003.
[8] S. Mukkamala and A.H Sung. Detecting denial of service attacks
using support vector machines. In FUZZ apos, editor, The 12th IEEE
International Conference on Fuzzy Systems, volume 2, pages 1231 –
1236, May 2003.
[9] P. Finn. Cyber Assaults on Estonia Typify a New Battle Tac-
tic,Washington Post Foreign Service, 19-Mai-2007.
[10] L. Peluso, D. Cotroneo, S. P. Romano, and G. Ventre. Assyst: an active
security system against dos attacks. Technical report, Dept.of Computer
Sciences, University of Napoli, Italy, April 2001.
[11] A. Rowstron and P. Druschel. Pastry: Scalable, decentralized object
location and routing for large-scale peer-to-peer systems. In IFIP/ACM
International Conference on Distributed Systems Platforms (Middle-
ware), pages 329–350, November 2001.
[12] A. Rowstron and P. Druschel. Pastry: Scalable, distributed object
location and routing for large-scale peer-to-peer systems. In IFIP/ACM
Middleware 2001, Heidelberg, Germany, November 2001.
[13] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. Frans Kaashoek,
F. Dabek, and H. Balakrishnan. Chord: a scalable peer-to-peer lookup
protocol for internet applications. IEEE/ACM Trans. Netw., 11(1):17–32,
2003.
5
Authorized licensed use limited to: Telecom ParisTech. Downloaded on July 01,2020 at 11:14:25 UTC from IEEE Xplore. Restrictions apply.
