A Cloud-based Architecture for Network Attack Signature Learning Omessaad HAMDI
Maïssa MBAYE
Francine KRIEF
University of Carthage, SUPCOM, Tunisia
[email protected]
Gaston Berger University, LANI, Sénégal
[email protected]
University of Bordeaux, LaBRI, France
[email protected]
Abstract— Intrusion Detection System (IDS) is an essential component of the network security infrastructure. It detects malicious activities by monitoring network traffic. There are two main classes of IDS: the anomaly-based IDS and signature-based IDS. An important challenge, for signaturebased IDS, is automating attack signature writing from traffic logs, which can be very hard to be established for human administrator. In this paper, we propose a solution addressing this challenge. We propose cloud-based signature learning service using Inductive Logic Programming (ILP). Learning service generates rule describing properties shared by packets labelled as malicious and that do not cover normal packets. The system uses a background knowledge composed of predicates used to describe network attack signature. The cloud architecture of our IDS enables it to have specialized nodes. Preliminary experimentations show that the proposed system is able to reproduce automatically SNORT signature. Keywords: cloud computing, Inductive Logic Programming, Intrusion Detection System, attack signature.
I.
INTRODUCTION
Network administrators implement Intrusion Detection Systems (IDSs) to avoid intrusion attacks and to enforce network security strategy. An IDS monitors traffic and sends intrusion alerts to administrator’s console when a suspicious activity is detected. There are three main categories of IDS: signature-based IDS, anomaly-based IDS and hybrid systems. Anomalybased IDS builds a model of normal activity after a training phase and any activity that deviates from this normality is classified as an intrusion (abnormal). This type of IDS may generate many false positives because all unknown traffic is considered as suspicious. However, it can detect unknown attack and then it may have less false negatives. Signaturebased IDS uses signatures that describe each attack properties using a specific rule grammar. Each packet/traffic is analyzed by IDS to detect if it matches one of signatures stored inside a database. This category can be very fast in intrusion detection process. However, it cannot handle unknown vulnerabilities (Zero-Day Attack) since it only handles attacks for which signatures are already defined in signature database. This database must be continuously provisioned by administrator with new attack signatures. Despite of all these drawbacks, signature-based IDSs are very efficient: They generate few false positives. Intrusion detection process can be done very quickly with
sophisticated pattern matching. In signature-based IDS context, when a network attack occurs, a challenging task for administrator is to write accurate signature that describes this attack. The problem comes to the fact that, administrator can have a lot of traffic concerned with the attack and a too general signature may generate undesirable false positives. In this paper, we try to address this challenge using a cloud-based architecture to learn signatures with inductive logic programming. Our main proposition is to design a cloud architecture that gives as main service attack signature learning. The structure of the paper is as follows. Section 2 presents related work. In Section 3, we introduce the signature learning system and the cloud-based architecture for signature learning in Section 4. Section 5 describes the proof of concept. We finish by a conclusion and future work. II.
RELATED WORK
Intrusion Detection System (IDS) was introduced by Anderson in [1]. It is used to report malicious activities to the administrator and to enable him to monitor network and be aware of attacks that occur in it. Few researches have exploited the Inductive Logic Programming (ILP) to automate signature-based intrusion detection systems. In [2], authors proposed a voting system between the ILP, the GP (Genetic Programming) and a statistical model for diagnosing intrusions. Their approach is purely theoretical and is not experimentally proven. In [3], a browser has been proposed to facilitate analysis of traffic. It uses the ILP to provide each user with a profile for anomalybased IDS. In [4], authors used the ILP only to ensure the resource access rights. In [5], authors develop an approach called “Signature A priori” based on data mining. This approach facilitates the generation of attack signatures. It assists administrators in signature discovery in network IDS. In this approach, authors consider that they are able to generate a signature for a new attack that is related to an existing attack. In [6], authors try to improve the approach proposed in [5]. They consider that Signature A priori algorithm is slow. They propose a more efficient way than the Signature A Priori by applying a method called “scan-Reduction” to reduce scanning times of database and so to accelerate signature generation.
978-1-4799-8784-9/15/$31.00 ©2015 IEEE
Many intrusion detection cloud architectures were proposed in the literature. In [7], authors propose a customizable cloud-based service to provide cloud consumers the ability to detect attacks on many virtual machines residing in multiple cloud regions. IDS as a Service protects cloud consumers against attacks initiated from any source external to cloud or inside the cloud. It offers security for them by deploying IDS in public clouds. In [8], authors present a cloud intrusion detection data and virtual host based communications. They propose cloud intrusion datasets to monitor traffic that access the host (this host is called virtual Host Intrusion Detection). In [9], authors propose a scheme that uses a blacklist to help filter network packets based on the IP domains. The blacklist is updated using the method of static-based blacklist generation. Evaluation demonstrates the effectiveness of the approach. However, it reflects some limitations: rules are not optimal and the scheme cannot resist to some attacks. In this context, we use ILP to learn IDS signatures. Our approach is fast and able to generate a signature by analyzing few suspicious attacks. This approach is adopted for cloud-based architecture. We propose signature learning as specialized IDSs in cloud to ameliorate signature learning. The novelty of our proposition is twofold: 1) we propose a signature learning as a cloud service. The learned signatures are in Prolog grammar then it is used as proxy-grammar that can be translated to specific IDS. 2) Our ILP learning process aims to use general background knowledge to learn specific attack. The main outcomes of our paper are to design a cloud architecture that gives as main service attack signature learning using specialized IDSs by taxonomy. We are based on [10] to specialize IDS nodes. III.
ATTACK SIGNATURE LEARNING
A. Clausal property of attack signatures Attack signatures grammar is very similar to logic programming’s one. Semantic of logic programs is ‘if body then head’ and it is the same as for signature based intrusion detection, which is ‘if conditions then action’. Proposition: Any attack signature can be written as a logic program. Let P be a packet or a traffic (set of packets) and P1…Pn its properties, C be a condition on packet/traffic properties (fields) and a function match(C,Pi), which returns TRUE if Pi verify the conditions C and FALSE otherwise. An attack signature is just a set of conditions on packets and traffics properties. An intrusion occurs when properties of P match to C.
݅݊ ݊݅ݏݑݎݐ ሥ ݄݉ܽܿݐሺܥǡ ܲ ሻ ൌ ܴܷܶܧ ୀଵ
Where P1… Pn are properties of P. This equivalence means that all properties should match to C to have an intrusion. Actually signature-based intrusion detection systems have a database of signatures and each packet of traffic is matched to all of them.
݊݅ݏݑݎݐ݊ܫ ሧ ൭ሥ ݄݉ܽܿݐሺܥ ǡ ܲ ሻ൱ ൌ ܴܷܶܧ ୀଵ
ୀଵ
This formula can be rewritten as follows (which are clausal forms where all rules have the same head): ൝
݅݊݊݅ݏݑݎݐሺܲሻǣ െ݄݉ܽܿݐሺܥଵ ǡ ܲଵ ሻǡ ǥ ǡ ݄݉ܽܿݐሺܥଵ ǡ ܲ ሻ ǥ ݅݊݊݅ݏݑݎݐሺܲሻǣ െ݄݉ܽܿݐሺܥ ǡ ܲଵ ሻǡ ǥ ǡ ݄݉ܽܿݐሺܥ ǡ ܲ ሻ
This property of signature is very interesting for us since our main idea is then to design a service that learns signatures as logic programs. B. Signature Learning with Inductive Logic Programming Inductive Logic Programming (ILP) can be defined as the intersection between automated learning and the logic programming [11]. It is the main technique for learning logic programs. A logic program is a set of rules and facts. The ILP solver has three main parameters: Positive Examples, Negative Examples and Background Knowledge (BK). BK ܤis a set of vocabulary, rules and predicates that can be used to describe a learned concept. The set of Positive Examples ܧା is the one that should be described or characterized using B. The set of Negative Examples ି ܧare the one that should be excluded from the description learned. With these parameters the ILP solver is able to find a set of properties ܪexpressed with vocabulary in ܤso that the largest subset of ܧା verifies H and the largest subset of ܧേ does not verify [ ܪ18]. More formally, given ܤ, ܧା and ି ܧ, ILP learns a theory H so that: • ܪ ڂ ܤ٧ ܧା , H that together with BK logically implies (covers) all positive examples (Completeness) • ܪ ڂ ܤ٬ ି ܧCovers none of the negative examples The most famous logic programming language is Prolog [12], which will be used in our experimentation. There are many approaches for PLI [6]: P-Progol, CProlog, FOIL, IndLog etc. In our proposition, the idea of using ILP is to consider malicious packets as positive examples, normal packets as negative examples and properties as BK to be used to describe attacks. In this way, learning signature consists in finding general rule that describes properties common to all positive examples and that are not shared with negative examples. This general rule then describes common properties of the set of malicious packets (ࡱା ) so that this rule does not cover normal traffic (ࡱି ). Table 1 describes correspondences between attack signatures and ILP semantics. Signature Grammar ܪ ܧା ିܧ ܭܤ
ILP Parameter Attack signatures Predicates describing malicious packets/ traffic properties Predicate describing normal packets/traffic properties Signature vocabulary used to describe malicious packets
Table 1: ILP and Signatures correspondences C. SNORT signature logic grammar and learning In our testbeds we consider SNORT signature as a reference to validate the learned rule. SNORT uses a simple
grammar to specify attack signature. This grammar is composed of a header and a signature body. The signature header: contains information about protocol, source and destination IP addresses and ports; The signature body: includes alert messages and information about packets, which are inspected to determine whether the action of the rule should be accepted. In our simulation, we use SNORT to save traffic to be analyzed then. IP_SRC/NET_SRC:PORT > NET_DST/IP_DST:PORT (
contain ILP modules. As input, they have malicious and normal traffic in standard format (e.g. PCAP). The system returns a prolog rule (signature) that can be translated to any specific target grammar (Fig. 1).
rule_body)
Interesting fields are in the body part where properties of packets that correspond to an attack are described. When our signature learning service receives raw packets in PCAP format, it transforms packets to prolog facts with the predicate p(_,_,_,_,_,..,). The following is a possible representation of an IP packet into Prolog fact (with some adaptations to be clearer): p(id=1421661907.86, ip_ver=4, ip_ihl=5, tos=0, ip_len=65535, ip_id=1, ip_flags=0, ttl=64ip_proto=1, ip_src=192.168.0.116, ip_dst=192.168.0.1, icmp_type=8icmp_code=0, icmp_id=0,icmp_seq=0 )
After that these packets are classified with respect of their label (normal/negative, malicious/positive) to construct positive and negative examples. Negative examples are not mandatory but can help to optimize learned signature. Concerning the background knowledge it can contain any predicate used to describe the packet/traffic properties. The following is an example (proto) of a predicate that can be used as BK. proto([p(_,X,_,_,_)|[]],tcp):- X is 6. proto([p(_,X,_,_,_)|Q],tcp):- X is 6, proto(Q,tcp). proto([p(_,X,_,_,_)|[]],icmp):- X is 1. proto([p(_,X,_,_,_)|Q],icmp):- X is 1, proto(Q,icmp). proto([p(_,X,_,_,_)|[]],udp):- X is 17. proto([p(_,X,_,_,_)|Q],udp):- X is 17, proto(Q,udp). proto([p(_,X,_,_,_)|[]],tcp):- X is 6. proto([p(_,X,_,_,_)|Q],tcp):- X is 6, proto(Q,tcp).
Here, for instance proto indicates the protocol transported by IP protocol (protocol field of IP header). Value 6 means that the transport protocol is TCP. IV.
CLOUD-BASED ARCHITECTURE FOR SIGNATURE LEARNING
In this section, we present the cloud architecture that gives as main service network attack signature learning. To the best of our knowledge this is the first work that shows a cloud-based architecture for network attack signature learning. A. Basic Service Architecture The basic aim of our proposition is to provide attack signature as a service. It works inside a cloud with client/server architecture. Clients access to the service through a secure virtual private network. The signature learning service is provided by learning nodes (LN) that
Figure 1 Signature Learning Service architecture Inside a learning node, we have an ILP engine, a BK logic database and a Grammar Translator Proxy. The grammar translator proxy is a data mediation component between ILP engine and client. It translates input data from client to ILP predicate parameters: malicious traffic to Positive Examples ( ܧା ) and normal traffic to Negative Examples () ି ܧ. Inductive Logical Programming engine learns general rule corresponding to signatures. This engine needs a logic database composed of background knowledge and examples that correspond to input traffic data classified as malicious. After that ILP Engine learns rules, Grammar Translator Proxy transforms these rules from Prolog grammar to specific IDS grammar.
Figure 2 Leaning Node’s Architecture Currently only SNORT rule grammar is supported. Let learned signature C٧:- P1… Pn where C is the clause head and P1… Pn are predicates of BK. The transformations to SNORT signature rule is done in two steps: Step 1: Build the rules head from Prolog signature by extracting the source and destination IP, the transport layer port in the learned signature. The BK predicates in the rule body are Pi=ip_src(packet), Pj=ip_dst(packet), Pk=src_port(packet),dst_port(packet),
Pl=proto(X,tcp).
If the parameter of the predicate is a literal then it will be transformed literally. If the parameter is a variable then it will be translated to any. Prolog Signature ip_src(192.168.0.1), ip_dst(10.0.0.1),proto(P,tcp), dst_port(X),src_port(Y) Ip_src(X),dst_ip(10.0.0.1), proto(P,icmp)
Snort Rule body alert tcp 192.168.0.1:ANY > 10.0.0.1:ANY alert icmp ANY > 10.0.0.1
Step 2: Build the rules body. In the SNORT body, C is transformed into (msg: some_text_id). The body predicates P1… Pn are transformed to the nearest SNORT filter F1,F2,F3,… For instance syn_tcp_actif(packet) could be translated into the SNORT filter flow: (…,flow :established,…). The final SNORT rule body is: (F1,F2,…). Finally the signature is sent to client to feed his signature database. The main outcome of this solution is that the complex task of writing signature from network logs can now be done by cloud service. B. Specialization for distributed IDS service The BK in ILP setting is generally domain specific. More specifically two signatures can use different background knowledge. For instance, an attack targeting operating system may not use the same set of predicates than one targeting network protocol. Background knowledge should be as specific as possible to avoid noise. In our Cloud based service for signature learning, learning nodes are specialized [14] according to attack taxonomy. In this taxonomy we have four main classes of learning modules: Operation system targeted; Application (Client/Server); Network Protocols. Specialization of nodes by categories of attack signature they can learn is very relevant to have more optimized signatures. Each client network can subscribe to any kind of specialized IDS service according to the target of the attack. The outcome of this criterion is to optimize service response delay and to minimize noise in the rule. Predicates in background knowledge may change from one attack to other. Specialized set of learning nodes inside our cloud service according to taxonomy helps to have optimized background knowledge. The underlying hypothesis is that attacks in the same category may be described with the main set of properties.
classical methods. The main benefits of this approach are (1) a significant time saving, thanks to automatic design of attack signatures from packets traces, (2) the availability of this service thanks to the cloud. V.
A. Environment of implementation We use Aleph 1 as ILP Engine, which is an implementation based on Prolog. To validate our approach, we simulate the required number of positive and negative examples to generate a logical rule equivalent to a SNORT signature. The first stage of our work consists to determine the characteristics of a network packet. These characteristics are then implemented as Prolog predicates in the background knowledge. The second step consists to simulate a network formed by a server computer and a set of virtual machines with an attacking machine. Machines send packets to the server. These packets will be analyzed and classified into positive examples and negative examples. We simulate several attacks to learn their signatures using PLI. Our simulations consider the percentage of predicates expresses the number of predicates appeared in the rule. We present thereafter, our simulation results for two types of attacks. B. SYN flood attack In a client/server TCP connection, the client sends a SYN request, the server then responds with a SYN / ACK packet and then the client validates the connection with a packet ACK. A TCP connection can be established when these three steps have been taken. A SYN flood is an attack that sends a series of "SYN" messages to a computer, but does not send back any ACK messages. Therefore, the server ends up waiting for multiple responses and it may not be able to respond to legitimate requests. The generated logical rule using the developed background knowledge, positives examples (SYN flood attacked packets) and negative examples (other traffic) is: attacked_packet(A): - syn_tcp_actif (A), packet_number (A). The obtained rule means that the machine has received a big number of packets with SYN flag set. Note that in the simulation, we consider that packets come from the same machine (same IP address) and that we are using TCP protocol. e+ number 2 2 1 2 0 1
Figure 3: Cloud-based architecture for specialized signature learning nodes However, the risk of having some noise remains. We will focus on this problem in our future work. Another risk is data modification between client and signature learning service. System can verify input data integrity, with
PROOF OF CONCEPT
e- number 3 2 3 1 1 0
Percentage 100% 0% or 50% 0% 50% 0% 0%
Table 2: SYN flag attack 1
A Learning Engine for Proposing Hypotheses
Table 2 shows the required number of positive examples and negative examples to generate a logical rule describing SYN flood attack with: • e+ number : represents the number of used positive examples; • e- number : represents the number of used negative examples; • Percentage: represents the percentage of used predicates forming the generated logic rule. If we have 50 %, this means that we obtained a large number of packets from the same machine or many active SYN flag packets, which does not mean a SYN flood attack. Note that in order to generate a logical rule similar to the rule defined by the SNORT community, we need only 2 positive examples and 3 negative examples. The SNORT rule for Syn Flood attack is [13]: alert tcp any any -> any any (msg : " SYN Flood " ; flow: stateless ; flags : S, 12; threshold: the type threshold , track by_sr ( ip , protoPass; tcp flags , flag ip , port) c , count 3 seconds 1; classtype : attempted- recon ; sid : 10002 ; rev1 ;),
C. Ping of death attack This attack consists of sending an ICMP echo request packet that is larger than the maximum IP packet size (65535). Since the received packet is larger than the normal IP packet size, it is fragmented. The target cannot reassemble the packets, so it crashes [17]. e+ number 2 2 2 3 3 2 1
e- number 4 3 2 2 1 1 2
Percentage 100% 100% 33% or 66% 33% or 66% 33% 33% 0%
Table 3: Ping of death attack Table 3 shows the required number of positive and negative examples to generate a logical rule blocking a ping of death attack. The obtained rule is: attacked_packet (A):- dsizesuperieur(A,65535), icode(A,netunreachable), itype(A,echo). which means that the attacked machine receives a packet size greater than 65535 with message type 8 (Echo), code 0 (net unreachable). The percentage equal to 33 % means that we got only one predicate from three predicates in the learned rule and 66 % means that we got only two predicates. Note that in the both cases, the learned rule does not describe the ping of death attack. We simulated other attacks. Obtained results show that with very few suspicious packets, our approach generates a rule equivalent to a SNORT signature. VI.
CONCLUSION AND FUTURE WORK
In this paper, we studied signature-based IDS in order to assist administrators to describe a signature attack by learning method using Inductive Logic Programming (ILP).
This learning system is developed for cloud based architecture. It uses specialized IDS nodes, according to attack taxonomy, in the cloud to reduce intrusion detection work. Preliminary experimentations show that by using ILP, we can reproduce automatically SNORT rules. These experimentations are done for specifics attacks. We are currently working on implementing generic background knowledge in order to be used for all attacks. The proposed approach assists administrator to update IDS based signature. We aim to automate the task of separating examples. We also plan to explore how to efficiently share examples between clients in a secure privacy-preserving way. Acknowledgment This work is supported by the African-ExcellenceCenter (CEA-MITIC) at Gaston Berger University/Sénégal. References [1]
[2]
[3]
[4] [5]
[6]
[7]
[8]
[9]
[10] [11] [12]
[13]
[14]
Anderson, J. P.. Computer security threat monitoring and surveillance. Technical report, James P. Anderson Company, Fort Washington, Pennsylvania, April 1980. Wei L.. A novel framework for network intrusion detection using learning techniques, Communications, Computers and signal Processing, 2005. PACRIM. Mizoguchi, F. Anomaly detection using visualization and machine learning, Enabling Technologies : Infrastructure for Collaborative Enterprises, WET ICE, 2000.. Ko, C. Logic induction of valid behavior specifications for intrusion detection, IEEE Symposium on Security and Privacy,. S & P 2000. Han, H., LU, X., and Ren, L.-Y.. Using data mining to discover signatures in network-based intrusion detection. In : Machine Learning and Cybernetics, IEEE, 2002. p. 13-17. Zhengbing, H., Zhitang, L., et Junqi, W.. A novel Network Intrusion Detection System (NIDS) based on signatures search of data mining. In : Knowledge Discovery and Data Mining,. IEEE, 2008. p. 10-16. Alharkan, T. et Martin, P.. IDSaaS: Intrusion detection system as a service in public clouds. 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (ccgrid 2012). IEEE, 2012. p. 686-687. Moorthy, M. and Rajeswari, M. Virtual Host based Intrusion Detection System for Cloud. International Journal of Engineering & Technology (0975-4024), 2013, vol. 5, no 6. Meng, Y. et Kwok, L.. Adaptive context-aware packet filter scheme using statistic-based blacklist generation in network intrusion detection. In : Information Assurance and Security (IAS).IEEE, 2011. p. 74-79. Hansman, S. and Hunt, Ray. A taxonomy of network and computer attacks. Computers & Security, 2005, vol. 24, no 1, p. 31-43. Lavrac and S.Dzeroski. Inductive logic programming : Techniques and applications. Ellis Horwood, New York, 1994. 120 Clocksin, William F. ; Mellish, Christopher S. (2003). Programming in Prolog. Berlin ; New York : Springer-Verlag. ISBN 978-3-54000678-7. Mbaye, M. and Ba C., "A distributed IDS Cloud service: an architecture based on Pub-Sub paradigm" Pages 225 – 235. 12th African Conference on Research in Computer Science and Applied Mathematics (CARI 2014), Saint-Louis ,Sénégal ,October 2014 ., pp.376, 2014 S. Muggleton, Luc, and D. Raedt. Inductive logic programming: Theory and methods. Journal of Logic Programming, 19:629–679, 1994.
