You are on page 1of 13


Abnormal Event Detection for Network Flooding Attacks


Department of Communications Engineering

Department of Information Engineering
Feng Chia University
Taichung, 407 Taiwan

Due to the high demand for network service availability and reliability, the IDS (Intrusion Detecting System) has become an essential element for IP networks. Currently,
most IDSs use a pattern-matching mechanism to detect network flooding attacks. However, while running, such a mechanism needs to take into considerable the computing
time/resource of an IDS or an IDS-embedded router. This can easily cause the IDS or
router to become overloaded or to crash. In this paper, an abnormal event detection
mechanism based on the abrupt variation analysis of network traffic is proposed. This
detection mechanism works cooperatively with the pattern-matching mechanic to perform effective attack detection in a situation where overloading of an IDS or an
IDS-embedded device should be avoided. In addition, a monitoring system using abnormal event detection is designed and implemented to demonstrate its detection performance. By using the developed system, network managers can not only determine the
occurrence and the behavior of an attack, but also take some timely actions to present or
stop the attack on crucial network resources.
Keywords: abnormal traffic event detection, statistical reference window, network
flooding attacks, event correlation, network security management

Due to the rapid growth of the use of the Internet and its related technologies, the
demand for high quality and reliable Internet service has increased. However, the occurrences of malevolence network attacks and viruses seriously threaten the Internet [1, 2].
These disaster events, either network attacks or viruses, cause not only system crashes or
performance degradation, but also damages IT enterprises. Therefore, an effective system
for detecting network attacks is needed. Current methods used for intrusion detection are
described in the following:
The pattern-matching method is widely used by most of the current IDSs. Normally,
an IDS uses predefined pattern rules describing network attacks to check and analyze
each incoming pattern of packets. The major problems with pattern-matching for network attack detection are the low processing capacity and the inability to detect novel
attacks. To improve packet processing performance, Fisk [3] and Coit [4] proposed sevReceived March 30, 2004; accepted June 30, 2004.
Communicated by Chu-Sing Yang.




eral methods to speed up pattern comparing tasks. In addition, Snort 2.0 [5] also used a
rule optimizer and rule classifier to quicken attack detection.
 Abnormal Behavior Detection
Abnormal behavior detection finds abnormal behavior in network traffic, which
triggers more detailed checks of network attacks. This is because abnormal traffic behavior is normally treated as a symptom of an underlying problem in the managed network. This method is widely used in network management for fault detection or prediction. In 1990, Maxion et al. [6] monitored the campus network traffic of Carnegie Mellon
University for about seven months and used the acquired data to construct a traffic model
for predicting the traffic amount in the next time slot. Then they set an appropriate
threshold for the next time slot to check if traffic changed abnormally. Hood and Ji [7]
collected all the MIB logs from network backbone routers for network fault verification.
Moreover, they used a Bayesian network to calculate the probability of fault occurrence
in each time slot. Thotton et al. [8] used a first order auto-regressive model to calculate
white noise series. The generalized likelihood ratio was used to determine the degree of
the value change of a parameter. In their work, spatial correlation was also utilized to
combine all measured parameters to reduce the number of fault occurrences. Nevertheless, abnormal behavior detection has difficulty verifying whether the detected abnormal behavior is a real problematic event or not; this means that network managers need
to further check related network logs and data to make a more precise determination.
Hiraishi et al. [9] used a Hyperbolic Tree to visualize the system log data of users.
Managers can understand all the actions and related information of each system user by
observing the corresponding Hyperbolic Tree and can easily discover invalid user actions when the branches connected to the Danger group grow explosively. Erbacher et
al. [10] used two basic components to construct a connection graph of a managed host.
The first component is an arrow used to show the direction of a connection of the monitored host, while the second component is a circle with which arrows connect. Several
different kinds of arrows are designated for different network services, such as telnet,
FTP, NFS, port scanning, and so on. All the connections from and to a host can be observed by monitoring the connection graph of that host. If there is an attack on that host,
it can be easily discovered by monitoring the width change of the attack connection arrow in the connection graph.
In summary, current IDSs use pattern-matching as the major network attack detection mechanism. However, the pattern-matching mechanism may cause equipped routers
or IDSs to become overloaded when flooding attacks occur; this will make the router or
IDS the first victim in a network attack event. To solve this problem, we combine pattern-matching and traffic change detection to detect network flooding attacks based on
the reduced average CPU computing load of the IDS. In addition, we also implement a
visual monitoring system. After observing the behavior of network flooding attacks via
the monitoring system, network managers can take actions to prevent, stop, or even control the expansion of the attacks in advance. The rest of this paper is organized as follows.



Section 2 describes the behavior of network flooding attacks and our management architecture. The time series analyses used in our abnormal traffic change detection are also
presented. Section 3 describes the major traffic change detection methods with different
change detection mechanisms and time series analyses. In addition, the performance of
these methods is evaluated and compared. Section 4 presents our system implementation,
and section 5 concludes this paper.


A system for detecting network flooding attacks must be able to not only determine
the occurrence of an attack in time, but also visualize the attack in order to alert or protect network users. This means that the management system should provide timely information about the occurrence of an attack as well as the overall attack behavior or its
paths. To do this, the system must determine the behavior of network flooding attacks
first. During an attack, abnormal events reflecting abrupt traffic changes occur in the
network area affected by the attack [1]. The attack traffic floods the related network elements (devices) and causes some specific packet measures to grow explosively. On the
basis of these observations, we can use some standard management protocols (e.g.,
SNMP) to easily obtain these measures from the managed network and then determine if
there are abnormal traffic changes. Once an abnormal traffic change is found, the type of
the attack can be determined by examining the type of the attack packets associated with
the abrupt traffic change, and the IDS will trigger pattern-matching only using
the matching rules of that attack from the entire attack-pattern knowledge base.
To track attack paths, the management system should observe the incoming and
outgoing traffic of each transmission interface of the managed network elements. Based
on information regarding the attack traffic direction, the next victims of the attack can be
estimated and warmed in advance. For example, as shown in Fig. 1, the attack traffic
passes through link(1 3) and link(2 3) in time t1, and runs across element3 to element4 in time t2. Thus, we can deduce that the downstream of element4 link(4 5)
will be the next victim as the attack traffic floods the network.





May be affected in
next time slot t3

Fig. 1. Flooding by attack traffic.

Considering the system implementation, it is possible that the manager or the management system will be unable to correctly collect related management information from
its managed network (or devices), due to the network congestion caused by the attack



traffic. To avoid this situation, an out-of-band management architecture, as shown in Fig.

2, can be used. Every managed element (router in Fig. 2) directly transmits needed management information to the corresponding manager via the out-of-band management information network (such as via a SMS network). This can assure that the management
traffic will not be affected or infected by the attack traffic.

Manager Domain
Real-World Network

Fig. 2. Management architecture.

For traffic change detection, to accurately detect abrupt changes in flooding attacks,
several change detection methods with two different time series analyses can be used
(performance comparisons will be given in section 3). Here, we will first discuss two
different kinds of time series analysis normally used in traffic change detection [11] as a
basis for setting traffic thresholds, and we will later discuss the major methods used in
our traffic change detection scheme.
Time series analyses normally divides the data over time into two major portions,
the reference window portion and the test window portion, before further engineering traffic. The traffic data in the reference window are used as thresholds to make a
comparison with the (current) traffic in the test window. Two mechanisms are usually
used to determine the size of the reference window for the time series data: the fixed and
variance mechanisms. In the fixed reference window size mechanism, the size of the reference window is fixed in every comparison at each regular time interval, and the size of
the reference window is the same as that of the test window. The window size can be
determined and adjusted by users themselves. In our experiments, we examined the detection accuracy achieved with different fixed window sizes. In the variance reference
window size mechanism, the size of the reference window varies. The time series data in
the test window is compared with the traffic data in the reference window, which is the
same size or two or more times the size of the test window. In our work, the variance
reference window size is determined as follows (as shown in Fig. 3):
1. Initially, the sizes of the reference window and the test window are the same. As
shown in Fig. 3 (a), we assume  that the starting point of the reference window is at
time T,  that the ending point of the reference window and the starting point of the
test window are time T + t and  that the ending point of the test window is time T +



Initially, choose two windows of the same size

In Time T

Partition point

If no change occurs, extend the reference window

In Time T + t

In Time T + 3t






Partition point

If no change occurs, continue to extend the reference window

Partition point

If a change occurs, choose a new reference window

In Time T + 4t


Change point

Partition point

Fig. 3. Various window sizes.

2t. Then, T + t can be viewed as a partition point between the reference window and
the test window.
2. When we compare the traffic data in the reference window with that in the test window, if the degree of variation does not exceed the threshold, then the partition point
will shift to the end of the test window. The next time, the data in the text window will
be compared with the traffic data within a reference window that is twice as large. This
step will be repeated until the degree of variation of the traffic exceeds the specified
threshold (as shown in Fig. 3 (b)).
3. When the degree of variation exceeds the threshold, a change point will be set at the
partition point of the last traffic comparison (as shown in Fig. 3 (c)). This means that
an abrupt change will be detected in the text window, and that the detection procedure
will be restarted from the current change point.
For abrupt traffic change detection based on a comparison of the two traffic windows, the log likelihood ratio test with first order Auto-Regressive model, which was
proposed by Hood et al. [12], is used in our work. By modeling the two adjacent traffic
windows of the time series data using AR(1), we can generate two white noise series.
Then, the joint probability of a change between these two traffic windows can be esti2
mated as l = ( 1 ) N R ( 1 ) NT exp( NR2 R )exp( NT2 T ), and the joint probability
2 R
2 T
2 R2
2 T2
of no change happening can be calculated as l 0 = ( 1 ) N R + NT exp( ( NR + N2 T ) P ),
2 P
2 P2
where  NR and NT are the values of the white noise series random variables of the reference window and the test window, respectively;  P2 is the pooled variance. Next, the
log likelihood ratio used to estimate the degree of change can be obtained by using =
(NR + NT)logP NRlogR NTlogT.



In our study, two other traffic detection methods, the standard derivation comparison method and the average comparison method, were employed to make a performance
comparison for traffic change detection, where the degree of change in the standard derivation comparison method and the average comparison method was defined as
( )higher
Average higher
and =
, respectively.
( )lower


To compare the performance of the traffic change detection methods mentioned in
section 2, an experimental network was built, which included three PC-based routers,
four PCs, two Ethernet switches, and one hub (as shown in Fig. 4). In addition, the whole
experimental networking environment was equipped as shown in Table 1:
Table 1. Experimental environment.
PC Hardware
Routing Daemon
Routing Protocol
Flow Calculator
Background Traffic
Window Size
Change Degree Threshold

Pentium 200MHz + 64MB Memory

Redhat linux 7.3
NeTraMet (with Flow Meter MIB) [13]
200, 400, 600, 800, 1000 pkts/sec
40, 80, 120, 160, 200 users
1000, 2000 pkts/sec
5, 10, 15, 20, 30 samples
2, 3, 5, 10 (AR(1))

Background Traffic :
simulate normal traffic
Attack Traffic

Fig. 4. Experimental environment.



In our experiments, in each trail, flooding attacks are started by two PCs running
1000 DDoS attacking processes simultaneously. Three traffic change detection methods
mentioned in section 2 were used to detect abrupt traffic changes caused by these attacks.
Bi-direction background traffic was generated separately by two different traffic models
across the experimental network to simulate typical user network traffic. The first one
was the Poisson traffic model, in which the inter-arrival time is defined as t =
log(1 p )

, where is the average arrival rate of the traffic packets. Fig. 5 shows the

artificial Poisson traffic collected in our experimental network. As one can see, the traffic
seems to be too stable and unlike real Internet traffic. Therefore, the second background
traffic model used was the WWW model. In our work, we used freeware written by S.
Deng [14], which uses the Weibull and Pareto distributions, to generate WWW traffic
and inject it into our experimental network (as shown in Fig. 6).

Fig. 5. Poisson traffic.

Fig. 6. WWW traffic.

For each detection method with different time series analyses, after performing
about 1000 attack experiments, we selected the parameter combination that achieved the
best degree of accuracy on average. Figs. 7 and 8 show the performance of each method.
In Fig. 7, m2-30-5 means that if a user uses method 2 to perform attack detection, the
best parameter combination will be 30 samples per window, where the change degree
threshold is 5. In other words, a window size of 30 and a threshold degree of 5 will be
the best settings for method 2 to detect abrupt traffic changes. Methods 1~6 are described
as follows:
 m1: the log likelihood ratio test with AR(1) and a fixed reference window size;
 m2: the log likelihood ratio test with AR(1) and a variable reference window size;
 m3: the average value (or mean) comparison with a fixed reference window size;
 m4: the average value (or mean) comparison with a variable reference window size;
 m5: the standard derivation comparison with a fixed reference window size;
 m6: the standard derivation comparison with a variable reference window size.










1000 1000-2

Background Traffic

Fig. 7. Detection performance with Poisson traffic.


















Fig. 8. Detection performance with WWW traffic.

Fig. 7 shows the best parameter combination for each attack detection method with
the background traffic of a Poisson distribution. As shown in Fig. 7, the attack traffic was
set to 2000 pkts/sec, and we found that most of the detection methods had good performance. This is because there was quite a large difference between the amounts of attack traffic and background traffic. Hence, later, we reduced the amount of attack traffic
to 1000 pkts/sec and again used background traffic of 1000 pkts/sec to evaluate performance. The corresponding evaluation results are shown in Fig. 7, which are depicted by
1000-2. We can find that methods 2 and method 5 with a window size of 30 and a
change degree threshold of 5 achieved better performance than the others. However, it
should be pointed out that the performance evaluation is made in a stable intra-networking environment. Most networks with rising and falling traffic (for example,
the out-bound trunk of a campus network), require many modifications.



Fig. 8 shows the best parameter combination of each detection method in the WWW
background traffic test. From Fig. 8, we find that methods using the log likelihood ratio
test could not achieve good detection of abrupt traffic changes in this case. However,
methods 3 and 4 with 30 samples per test window and method 5 with 15 samples per test
window achieved extremely high accuracy in detection. In our system implementation,
according to the results shown in Figs. 7 and 8, method 4 was employed as the major
method for network flooding attack detection.
With traditional IDSs, pattern-matching is widely used to perform attack detection,
where the content of each incoming packet is examined in detail using each rule in the
IDSs knowledge base (Fig. 9 (a)). In the worst case, the total number of pattern-matches

needed is T = N

a , where N is total number of incoming packets during a detection


i =1

time interval, R is the number of rules in the knowledge base, and ai is the number of
comparison items in rule i, respectively. In order to reduce the total number of pattern-matches, an improved pattern-matching method was developed. It classifies all incoming packets before matching patterns; that is, each incoming packet needs to only be
examined based on the corresponding portion of rules (as shown in Fig. 9 (b)). For example, incoming TCP packets only need to be compared (or examined) with the
TCP-related rules in the knowledge base. In the worst case, the total number of patternx

matches can be reduced to T = N +



a , where N is the total number of incomk

i =1

j =1 k =1

ing packets during the detection time interval, ak is the comparison number of items in
rule k, Ri is the number of rules in category i, ni is the number of incoming packets in
category i, and x is the number of categories. It should be noted that no matter whether it
is being attacked or not, the IDS would check all the incoming packets.



















Fig. 9. (a) Traditional and (b) improved pattern-matching.

However, according our observations, it is not usual for a network service (or a network server) to be attacked all the time. Of course, if an attack occurs, a serious and
costly damage to the enterprise will occur if there is no protection of the IDS. In our
work, as mentioned in section 2, an IDS inside an edge router, along with the improved
pattern-matching method combined with effective traffic change detection, was installed
in our laboratory network. When no attack occurred, the average CPU computing load on
the IDS could be reduced dramatically since pattern-matching would not be enabled.
When attacks occurred, the CPU computing load on our IDS increased by only around
4-6% on average.



In our system implementation, the IDS has two subsystems: one is the centralized
Visual Monitor built into the Manager host, and the other is the Detector embedded in
our PC-based routers (Fig. 4). To observe the behavior of network flooding attacks, the
topology of the managed network is that shown in the Visual Monitor (Fig. 10). A manager can use a simple specification language to describe the managed network for the
purpose of later visualized translation of the corresponding topology [15]. Users can use
the Visual Monitor to obtain more detailed information regarding each interface of the
managed backbone devices (Fig. 11). In addition, they can determine the behavior of
flooding attacks by observing the occurrence sequence of abnormal events (alarms) in
the Visual Monitor, which collects detected abnormal traffic events in all of its managed
IDC-embedded routers (Fig. 10 (b)). Please note that, in Fig. 10 (b), the symbols R and
symbol S in a routers interface stand for the in-bound and out-bound abnormal traffic
events detected at that interface, respectively.
As mentioned in section 2, an effective network flooding attack detection system
can not only provide information about attacks but also support timely actions taken to
reduce or prevent damage. To do this, in our system, the manager can utilize the graphic
window of the Interface View (in Fig. 11) by clicking on the designated interface of the
managed devices in the Visual Monitor. Each flow shown in this view is checked by our
abnormal traffic detection system. If a flow is detected as an attack, the State column of
that flow will be valued Abnormal. In this case, the network manager can click on the
Drop button to trigger the corresponding IDS-embedded router, which has the interface
control of the abnormal flow for dropping its incoming packets. With this function, a
network manager can prevent, stop, or even control network flooding attacks through
timely dropping of the attacking packets in the proper network elements interfaces.


Fig. 10. Topology views.



Fig. 11. Device interface information.

To evaluate the detection performance of our system implementation, 1000 network

flooding attacks with a variety of background traffic types were automatically performed
between 2003/9/1 and 2003/10/31 in our experimental networking environment. These
attack trails included three major kinds of attacking packets: ICMP, UDP, and TCP. Our
system achieved good performance with more then 91% accurrancy in the detection of
these network flooding attacks during the test period. Currently, we are trying to deploy
our system in networks in which traffic varies hour to hour (much like the traffic in our
campus network).

In this study, we combined pattern-matching and traffic change detection to cooperatively detect network flooding attacks. The computation-intensive pattern-matching
mechanism is enabled only when network flooding attacks are detected, so the average
CPU load on the IDS is not always high. A monitoring system based on the above combination has been implemented to show how network managers can use it to take actions
to prevent, stop, or even control the spread of attacks. In addition, to effectively detect
the network flooding attacks, an abnormal traffic change detection mechanism with corresponding time series analysis has also been incorporated into our system implementation.
Nevertheless, according to the system performance evaluation, our detection method
does not work well with highly utilized network links. This is because abrupt changes
within heavy network traffic become quite unclear. Thus, in the future, we will try to
develop a more precise and comprehensive method for network flooding attacks to solve
this problem. Moreover, our system will be applied to a wireless networking environment to develop more detection applications.



1. A. Chakrabarti and G. Manimaran, Internet infrastructure security: a taxonomy,
IEEE Network, Vol. 16, 2002, pp. 13-21.
2. J. McHugh, A. Christie, and J. Allen, Defending yourself: the role of intrusion detection systems, IEEE Software, 2000, pp. 42-46.
3. M. Fisk and G. Varghese, Fast content-based packet handling for intrusion detection, UCSD Technical Report CS2001-0670, 2001.
4. C. J. Coit, S. Staniford, and J. McAlerney, Towards faster string matching for intrusion detection or exceeding the speed of snort, in Proceedings of DARPA Information Survivability Conference and Exposition, Vol. 1, 2001, pp. 124-130.
5. Snort 2.0, Open Source Network Intrusion Detection System,
6. R. A. Maxion and F. E. Feather, A case study of Ethernet anomalies in a distributed
computing environment, IEEE Transactions on Reliability, Vol. 39, 1990, pp.
7. C. S. Hood and C. Ji, Proactive network fault detection, in Proceedings of INFOCOM 97, Vol. 3, 1997, pp. 1147-1155.
8. M. Thottan and C. Ji, Adaptive thresholding for proactive network problem detection, in Proceedings of the 3rd IEEE International Workshops on Systems Management, 1998, pp. 108-116.
9. H. Hiraishi and F. Mizoguchi, Design of a visual browser for network intrusion detection, in Proceedings of the 10th IEEE International Workshops on Enabling
Technologies: Infrastructure for Collaborative Enterprises, 2001, pp. 132-137.
10. R. F. Erbacher, K. L. Walker, and D. A. Frincke, Intrusion and misuse detection in
large-scale systems, IEEE Computer Graphics and Applications, Vol. 22, 2002, pp.
11. J. B. D. Cabrera et al., Proactive detection of distributed denial of service attacks
using MIB traffic variables a feasibility study, in Proceedings of 2001 IEEE/ IFIP
Integrated Network Management, 2001, pp. 609-622.
12. C. S. Hood and C. Ji, Beyond thresholds: an alternative method for extracting information from network measurements, in Proceedings of 1997 IEEE Global Telecommunications Conference, Vol. 1, 1997, pp. 487-491.
13. N. Brownlee, Using NeTraMet for production traffic measurement, in Proceedings
of 2001 IEEE/IFIP Integrated Network Management, 2001, pp. 213-226.
14. S. Deng, Empirical model of www document arrival at access link, in Proceedings
of 1996 IEEE International Conference on Communications, Vol. 3, 1996, pp.
15. C. S. Chao, Y. S. Chen, and A. C. Liu, Statistical detection for network flooding
attacks, in Proceedings of the 2003 National Computer Symposium, 2003, pp.
16. L. Deri, R. Carbone, and S. Suin, Monitoring networks using ntop, in Proceedings
of 2001 IEEE/IFIP Integrated Network Management, 2001, pp. 199-212.
17. J. Cao et al., Internet traffic tends to poisson and independent as the load increases,
Bell Labs Technical Report, 2001.



Chi-Shih Chao () received his M.S. and Ph.D. degrees in Information Engineering from Feng Chia University in
1996 and 2001, respectively. From 2002 to 2004, he was the director of the Computer Resource Center, OIT, Feng Chia University. Currently, he is an Assistant Professor in the Communications Engineering Department of Feng Chia University. His research interests include VoIP performance/fault measurement,
wireless LAN management, and multimedia networks/communications. In addition, he is a member of IEEE, ACM, and Phi-TauPhi.

Yu-Xin Chen () received his B.E. and M.S. degrees

in Information Engineering from Feng Chia University in 2001
and 2004, respectively. Currently, he is a software engineer at the
Tellus Group Corp. in Hsinchu, Taiwan. His research interests
include network management and embedded systems.

An-Chi Liu () received his B.S.E.E. and M.S. degrees from National Chiao Tung University in Taiwan, and his
Ph.D. degree from the University of Illinois at Chicago, in 1973,
1977, and 1981, respectively. He is a Professor at Feng Chia
University, Taiwan, which he joined in 1989. From 1989 to 1994,
he was the Chair of the Department of Information Engineering.
From 1994 to 1998, he was the Dean of Engineering and, since
1998, he has been the President of Feng Chia University. Previously, he was a faculty member at the Illinois Institute of Technology and at North Dakota State University. His research interests include distributed processing, network management, and
software engineering.