A Fully Distributed IDS for MANET - Semantic Scholar

Download PDF
6 downloads 731 Views 426KB Size Report
Comment
usually be reinforced by proactive security services, such as intrusion detection. .... created, dispatched and managed through the Mobile. Agent Framework.
A Fully Distributed IDS for MANET Ricardo Puttini University of Brasilia – Brasilia – Brazil [email protected]

Jean-Marc Percher ESEO - Angers – France [email protected]

Ludovic Mé Supélec - Rennes - France [email protected]

Rafael de Sousa University of Brailia - Brasilia - Brazil [email protected]

Abstract In this paper we propose a new distributed intrusion detection system (IDS) designed for mobile ad hoc network (MANET) environments. The complete distribution of the intrusion detection process is the salient feature of our proposition: distribution is not restricted to data collection but also applied to execution of the detection algorithm and alert correlation. Each node in the MANET runs a local IDS (LIDS) that cooperates with others LIDS. A mobile agent framework is used to preserve the autonomy of each LIDS while providing a flexible technique for exploring the natural redundancies in MANET to compensate for the dynamic state of wireless links between high mobility nodes. The proposed solution has been validated by actual implementation, which is described in the paper. Three attacks are presented as illustrative examples of the IDS mechanisms. Attack detection is formally described by specification of data collection, attack signatures associated with such data and alerts generation and correlation. Experiments exhibit fairly good results, the attacks being collaboratively detected in real-time.

1. Introduction Mobile ad hoc networks (Manet) are wireless networks in which the mobile nodes exchange information without the help of any predefined network infrastructure. In such networks, also called spontaneous networks, the nodes collaborate to provide the basic network services. For instance, in the case of routing, the lack of a network infrastructure implies that the service is usually provided in a peer-to-peer fashion and that all the nodes of the network need to act as collaborating routers. Nodes in a MANET may, at any time, disappear from, appear into or move within the network. The resulting dynamic nature of the network topology, along with the unreliability of the wireless links, require for the configuration of MANET services to be highly adaptable.

Moreover, the availability of an individual node cannot be assured and therefore, services cannot rely on a central entity and must be provided in a distributed and adaptive manner. Security services are not an exception to this general rule and many traditional approaches are usually unsuitable for MANET [1]. Moreover, the wireless access links makes the network more vulnerable to many attacks (e.g. passive eavesdropping, active impersonation, denial of service) than wired networks. These features make the provision of security services in MANET particularly challenging. Nevertheless, some solutions for security services in MANET have been presented in recent literature. Most existing solutions consist in some kind of preventive security, usually based in authentication [1,2,3]. These preventive security mechanisms can usually be reinforced by proactive security services, such as intrusion detection. Once more, intrusion detection systems (IDS) have specific requirements in MANET and must not follow a traditional IDS design. In this paper, we are interested in the design of IDS for MANET [4,5]. Our objective is to present a new IDS architecture design, derived from a MANET requirement analysis. In our design, we use the mobility and autonomy associated with mobile agents to provide an efficient and flexible solution to poor connectivity and limited bandwidth in MANET context. Moreover, we allow a complete distribution of the intrusion detection tasks, instead of distributing only the data collection, which is the common approach in most of existing mobile agent based IDS (a brief survey is given in section 7). The definition and description of a distributed and modular IDS architecture using mobile agents is the first contribution of our paper. The second contribution in this paper relates to the implementation of LIDS enforcing our conceptual architecture. The implementation is used to validate the functionalities and suitability of the proposed IDS model, especially in the use of mobile agents. Presently, it

performs misuse detection [6] and uses the management information base (MIB) as its primary data source [7]. Finally, three examples of attack detection are given: detection of two attacks against the MANET routing protocol (routing level) [3] and detection of a stepping stone (session chain) attack (application level) [8]. The attacks describe cooperation in all phases of the intrusion detection process, e.g. data collection, execution of the detection algorithm and alert management.

2. An IDS for MANET with mobile agents Intrusion detection is based in collection and analysis of system and network audit data. Upon detection, intrusions should be reported to security management. Also, an automatic response, aiming to eliminate the causes and/or effects of the intrusion, may be triggered. Given the lack of centralization, the mobility of the nodes and the wireless nature of link connections in the MANET environment, some (if not all) tasks required for the intrusion detection process described above should be executed in a distributed and cooperative manner [4]. In our design, a local IDS (LIDS) is placed on each node of the MANET. The LIDSs communicate using a mechanism that takes into account the restrictions resulting from the MANET context; e.g. limited bandwidth or poor connectivity. Such architecture has already been identified in [4] as a basic requirement to IDS for the MANET environment. To provide flexible and autonomous means of interaction between the LIDS, we have proposed to use mobile agents [5]. If a LIDS fails to cooperate during some period of time (e.g. it has moved away, cracked or is compromised by some intruder), the intrusion detection service must not degrade. Redundancies in the MANET compensate for the nodes that are not cooperating in the detection processes as it is possible for more than one node to track and detect the same attack. Mobiles agents are an alternative to the client-server distribution model [10]. The use of mobile agents, opposed to traditional approaches where data are transported towards the computation location, allows the code to move toward the data. Carefully designed agents can reduce the amount of data exchanged through the network, while providing a flexible way of distribution. Also, a node dispatching an agent doesn’t have to wait for it to return to resume the processing and an agent can be dispatched and even destroyed by other nodes, without having to move back to the originator node. A LIDS cooperate with others by dispatching mobile agents to other nodes and by processing the task embedded in the incoming agents. In our design, cooperation may be done in different stages of intrusion detection. During data collection, nodes exchange

information about events to build the intrusion evidence. In detection algorithm execution, LIDS exchange information about the current state of the structure implementing the detection algorithm. Finally, alert correlation is also possible, when a node uses alerts from others to enforce the evidences of the suspicious activities detected locally. In any case, cooperation is executed by means of a mobile agent that roams from one system to another. Mobile agents can also provide a first element of response to the dynamic nature of MANET topology and membership. Indeed, when a node joins the network, it does so with a running LIDS and a mobile agent platform. It can therefore, immediately take part in the global cooperative intrusion detection process. Keeping the collaboration within a restricted number of nodes relates to bandwidth usage and scalability requirements. The rationale in executing some of the detection tasks only in the local neighborhood is double justified on the very nature of the MANET. A MANET node naturally has to collect and maintain information about its neighbors. Moreover, any information going to or coming from a MANET node should be routed through one of its neighbors, when it may be promiscuously monitored, given the broadcast nature of the wireless links [1]. Thus, neighbors from a node being target by an attack are naturally eligible as primary sources of information about the status of the node suffering the effects of the attack. Neighbor nodes are also eligible as collaborating peers to uncover information related to the intrusion that is lacking locally.

3. LIDS modular architecture In this section we present the proposed modular architecture for the LIDS, which is shown in Figure 1. A Sensor collects data from a data source, an Analyzer processes the collected data for detecting sequence of events that might have security concerns and the Manager stands for the management interface of whole process, besides of doing alert correlation and response initiation. The constraints of the MANET context are considered by addition of the module related with task distribution and of the mobile agents platform.

3.1. Intrusion detection framework Data can be collected from different audit sources, which can be a network packet capture interface (network level), a log system (host level) or a MIB (network, host and/or application levels). The data collected directly from the audit source is hereafter referred as raw data. These data are usually raw and has poor semantics. Also, raw data is available in a format that depends on the data source. Some pre-processing is applied to raw data,

Local IDS Manager

Analyzer

Mobile Agent Framework

IDS Kernel

Mobile Agent

alert Alert Management

query alert

alert

Mobile Agent

detection state

event

Distribution Manager

query

event (Local) Sensor

query, event, alert, detection state

Mobile Agents Place and Security Policy

Event Abstractor IDS Communication (IDMEF module)

raw data query

raw data Mobile Agents Communication (Agent Protocol Module)

Data Collector IDS Protocol

Data Extraction Protocol (local communications only)

Agent Protocol

(Local and External) Communication Support

Figure 1 - Proposed Modular Architecture for LIDS translating it into semantically richer information used by the detection algorithm, which are called events. This transformation on raw data is referred as event abstraction. Event abstraction can use many different techniques, such as pattern matching [6], data-mining [12] or statistical correlation [4]. We have decomposed sensor in two modules: Event Abstractor and Data Collector. These modules separate the data retrieving and the event abstraction features in two different entities. The idea is to enable multiple implementations for the Data Collector module, which may operate simultaneously collecting data from different sources, while enabling the event abstraction process to have abstraction rules that use information originated from multiple sources. Implementations of the Event Abstractor module with different abstraction principles are also possible. The Analyzer processes events according to some defined detection strategy. At least two detection methodologies are currently in discussion: misuse and anomaly detection [11]. It seems to us that these methodologies are complementary. It is our goal to have a hybrid (misuse and anomaly) intrusion detection strategy. In our architecture, each detection algorithm implementation is encapsulated in an IDS Kernel module, and it is possible to have multiples instances of such module, each one with specific detection algorithms. A concise representation of the current status of the detection algorithm is represented in a detection state message. Such information can relate to the state of the

detection of a specific attack, in misuse detection, or to the state of the behavior model, in anomaly detection. The Manager relates to alert management and intrusion response tasks. The Alert Manager module is designed to accomplish with the alert management, performing operations such as alert interpretation, false positive elimination and alert correlation.

3.2. Taking the MANET constrains into account In most distributed IDS architectures, distribution is restricted to data collection. In IDS for ad hoc networks, this is mandatory, as remote collection of important volumes of data is prohibitive due to limited bandwidth. Besides of local data collection, we also want to make a complete distribution of IDS tasks, enabling execution of the detection algorithm and alert management to be equally realized in a distributed manner. In our design, data collection and event abstraction are always kept local. Exchanged data are only concise information (events) resulted from local pre-processing of raw data. Cooperation in execution of the detection algorithm is done by exchange of detection state messages, while alert correlation relates to the exchange of alert messages. We propose that distribution and cooperation are accomplished by means of mobile agents, which are created, dispatched and managed through the Mobile Agent Framework. All high level messages to be

dispatched to or received from other nodes are sent to Distribution Manager. This module decides where the messages should be delivered and processed.

4. Implementation description 4.1. Sensor In the current implementation, intrusion detection is based in data collected from the Management Information Base (MIB), maintained locally in each ad hoc network node by an SNMP agent. The use of this data source is doubled justified. First, MIB has a standard format and SNMP agents are extensively implemented and adopted in a variety of platforms, providing good portability for the IDS. Second, MIB information describes entities of different levels of the system architecture. Thus, we should be able to monitor simultaneously network, host and even application levels. The Data Collector module is simply a software module that executes local SNMP queries to the SNMP agent. The resulting raw data corresponds to the value(s) of the MIB variables at the moment of the query execution.

4.2. Analyzer The IDS Kernel module implements a misuse intrusion detection strategy. Attack signatures are supplied for all attacks that must be detected. Signatures are described as finite state diagrams (FSD) [6]. Each transition in the FSD is executed as a consequence of one event being triggered. Whenever passing from one state to another, an appropriate action can be activated, which may result in generation of one or more messages among: (1) new (more specific) queries, (2) new events, (3) a detection state message containing information about the current state of the FSD or (4) an alert in case of positive attack detection. Events are trigged taking into account both the entity (nodes or service) targeted by an attack (target) and the entity that originates the attack (attacker). The LIDS detecting the attack, which is not necessarily placed in the node targeted in the attack, is always signaled in the event/alert generation. Whenever possible, the target of the attack is also signaled.

4.3. Alert management The current implementation realizes only a simple alert correlation. The idea is to aggregate multiple alerts generated from different nodes detecting the same attack in a group alert. Whenever a node detects an intrusion, it shares the generated alert with all other nodes participating in the detection process or with its neighbors, if the node have detected the intrusion locally. The nodes caches the alerts generated locally and those

received from other cooperating peers. Any node collecting K (a threshold parameter) alerts from different nodes, referring to the same attack can generate a group alert, which is flooded in the network. Alert cache policy is simple timeout, e.g. received/generated alerts are cached during t (a time parameter) seconds. It can be easily shown [14] that such type of group alerts have an improved rate of false positives. Group alerts can be used in attack response (elimination of the node originating the attack from the network).

5. Specifications for the attacks signatures In this section we provide examples of complete signature specification for three types of attacks. The first two attacks (NHOP and N+1HOP) aims to disrupt the OLSR [15] routing protocol (network level). These attacks have basically denial of service (DoS) effects at the target node, and so, they must be detected by some of the target’s neighbors. The last attack (STEPSTONE) is a stepping stone attack [8] (application level). All nodes participating in the session chain participate in the attack detection.

5.1. OLSR backgroung OLSR operates as a table driven and proactive routing protocol, which means that it is based on regular exchange of network topology information, which is used for updating the routing table of participating nodes, by the means of a link-state routing algorithm. Optimization over a pure link state algorithm is obtained by reducing the size of control messages and minimizing flooding of control traffic. Flooding is executed only in some selected nodes, called multipoint relay (MPR). HELLO messages are used by nodes to detect and update the neighbor set. Each node periodically broadcasts HELLO messages, containing information about heard neighbor interfaces and their link status. The link status may either be “symmetric” (link has been verified to be symmetrical), "heard" (link is asymmetrical), "mpr" (a node is selected by the sender as a MPR and the link must be symmetric) or "lost" (indicates that the link with this neighbor interface is now lost). HELLO messages are periodically broadcasted from all nodes to all one-hop neighbors. Routing through a neighbor node is possible only if there is sender have selected the next hop node as “mpr”.

5.2. NHOP attack: detection with collaborative alert correlation In NHOP attack, the attacker generates a spoofed HELLO message, advertising all nodes with 1-hop distance from the target (neighbors) with “lost” link

status. When receiving the faked message, all nodes that were advertised in the faked HELLO message would have the status of the link with the target changed to “heard”. This attack is similar to one of those defined for the OSPF routing protocol by Wang et al. [9]. The NHOP attack can be detected by anomalies in the OLSR scheduling during a HELLO_INTERVAL period. In this interval, one of the following may happen: (1) No information is received in HELLO_MESSAGE (normal), (2) One update is received in HELLO_MESSAGE (normal), or (3) Two or more updates are received in HELLO_MESSAGES, one of them advertising the fake “lost” state (attack). The following events are defined and queried at each HELLO_INTERVAL period: - NHOP_E0: Link type has not been “heard” in the last HELLO_INTERVAL period (no “lost” update, and no attack occurring). - NHOP_E1: Link type was “heard” and “symmetric” or “mpr” in HELLO_INTERVAL period (“lost” update has been received). - NHOP_E2: Link type was “heard” for more than HELLO_INTERVAL (only “lost” update received, no attack occurring). Figure 2 presents the automata for the NHOP signature. Initially (state NHOP_S0), the detecting node hadn’t received any advertisement from the target node with a “lost” type. When receiving one of such advertisement (event NHOP_E1), there is a transition to state NHOP_S1. If “lost” is received in the subsequent HELLO_INTERVAL, NHOP_E2 is generated again and the behavior is considered normal. However if other NHOP_E1 is received, the link type is actually changing twice during one HELLO_INTERVAL. Any occurrence of NHOP_E2 indicates that there is no attack and the symmetry is established, resulting in transitions to the NHOP_S0 state. The attack is detected by each LIDS that is both neighbor from the attacker and the target. As the alerts are sent to all neighbors of the node detecting the attack, neighbors from attacker and target collect the alerts generated and build a group alert. ( NHOP_E2 )

NHOP_S1 NHOP_E0 NHOP_E1 NHOP_S0 NHOP_E3

NHOP_E2

NHOP_E0 ( NHOP_E0 )

NHOP_S2

NHOP_E3 / alert: NHOP_Attack

Figure 2 - NHOP attack signature

5.3. N+1HOP attack: detection with collaborative excution of the detection algorithm In N+1HOP attack, the attacker fabricates a HELLO message advertising the nodes detected to be at 2-hops distance from the target node, along with one additional unavailable address, with “symmetric” link status, causing nearby nodes to select the attacker as MPR, which starts to forward traffic to nodes at 2 or more hops distance through the attacker. Detection starts at former MPR nodes, which detects the change in the target’s MPR set (event N+1HOP_E0). A mobile agent is created in these nodes. These are detection state (N+1HOP_DS0) agent, which the status “change detected in MPR” and a list of nodes being advertised as neighbors of the new MPR (e.g. attacker). This agent is dispatched to all neighbors. The detection proceeds in the nodes receiving the mobile agent. These nodes will compare their own neighbor list with the neighbor list that comes within N+1HOP_DS0. If a node is declared as neighbor but is not actually one, event N+1HOP_E1 and alert N+1HOP_Attack are generated. Figure 3 illustrates the FSD for the N+1HOP signature. N+1HOP_S1 (remote node)

N+1HOP_E0 / N+1HOP_DE0 N+1HOP_E1 / alert: N+1HOP_Attack N+1HOP1_S0 (home node)

N+1HO P_S2 (remote node)

Figure 3 - N+1HOP attack signature

5.3. Stepping stone attack: detection with collaborative data collection The stepping stone attack corresponds to creation of a connection chain (e.g. telnet). This type of attack precedes often some more evasive actions as it represents increased difficulty for tracking the attack source [8]. The root node (attacker) start a telnet connection with other node and, from there to another one and so on, building the chain to the target node. The detection of a telnet chain is divided in two steps. First, whenever one node receives an incoming telnet connection (local event STEPSTONE_E0), this node should query the calling node about its incoming telnet connections. If the calling node has no incoming telnet connection, it will generate an event to the querying node, telling that there it is the root of the telnet chain (remote event STEPSTONE_E1). The node receiving

such event creates a new chain composed by two nodes, the calling node and itself. The chain has the calling node as root. The source address (IP address and port number) of the calling node is stored as the root of the path. Otherwise, the node will generate an event (remote event STEPSTONE_E2) for each active chain it stores, informing the querying node about the chain path. Whenever receiving one of such event, the node creates a new chain formed by the same chain path in the event, adding the source addresses of the incoming connection in the end of the path. Chains are excluded whenever the incoming telnet connection is closed (local event STEPSTONE_E3). Reception of STEPSTONE_E2 event characterizes telnet chain formed by, at least, three nodes, finishing the first step of detection. The second step in the stepping stone attack detection consists in evaluating the existence of relations between telnet connections in the path of each chain (e.g. showing that one telnet connection in the chain path was indeed generated inside the section of the telnet connection in the precedent hop of the telnet chain). For space limitation reasons, we’ll describe the attack signature for the first step only. One possible solution to accomplish the second step of detection would be the use of a statistical correlator based event abstraction such as in [8]. Information collected from the MIB is the table with active TCP connections, expressed by the OID representing “tcpConnTable”, a standard MIB variable [16]. The attack signature is showed in the Figure 4. STEPSTONE_S3 STEPSTONE_E2 / Alert: STEPSTONE_ATTACK STEPSTONE_E3 STEPSTONE_S0

STEPSTONE_E0

STEPSTONE_S1

STEPSTONE_E3 STEPSTONE_E3

STEPSTONE_E1 STEPSTONE_S2

Figure 4 – Stepping stone attack signature

6. Results and analysis We have implemented the LIDS using Java2. The Mobile Agent Framework was implemented using the IBM Aglet platform [17]. A special SNMP agent was needed, implementing an experimental MIB defined for the OLSR protocol. This was implemented as an add-on module to the NetSNMP agent (www.netsnmp.org). The daemon implementing the OLSR was based on the publicly available implementation of the protocol, which conforms to version 3 of the IETF draft. The OLSR daemon was also extended to provide process intercommunication with the SNMP agent.

A MANET with six Pentium IV Linux nodes was used in our experiments, each of them executing the LIDS prototype, the extended SNMP agent and the OLSR daemon. An additional node consisting of a PDA running Linux was used to generate the attacks. Figure 5 illustrates one of the topologies assumed by the network during attack. The three attacks have been played and detected separately. During NHOP, nodes B and C were unreachable by D, E and F, as the attacked node A is the only available path to them). Nodes D, E and F detects the NHOP attack against node A. The detection is always local and cooperation is verified only in the alert correlation. The threshold specifying the number of alerts from different nodes needed to validate a group alert was set to K = 3. As long as nodes D, E and F detects the attack and are neighbors from each other, enough individual alerts were collected for the generation of a group alert. During N+1HOP attack, nodes A, D, E and F changed their MPR to the Attacker node. Node A and B detect the N+1HOP attack by collaboratively executing the detection algorithm. Finally, nodes B and C detects the stepping stone attack using mobile agent to gathering information by querying remote nodes. Both nodes accused the PDA IP address as the attack originator. The detection of these attacks intends to provide a functional and feasibility validation for our design, which is shown to be flexible in detecting attacks in different levels (network and application) and using collaboration in different steps of the detection process. The designed IDS seems also to have good scalability, as the intrusion detection process is not distributed in the entire MANET but rather in a small number of nodes, usually located near each other. The choice of the MIB as a data source is not original [7]. The contribution of our approach for this subject is the use of MIB to enable detection of different kinds of attacks on multiple layers (network, system and application). Moreover, standard MIB information is now largely implemented in the many available SNMP agents making MIB data a particularly standard data source. Finally, the MIB specification can simplify the formal specification for event abstraction and detection rules.

7. Related work The design of IDS for MANET is not a completely new issue. These previous work introduce the basic requirements for such a special type of IDS [4] and discusses some preliminary architecture concepts [5]. In [19], S. Gwalani et al. are proposing an IDS for MANET that is mainly used to reinforce the security of the routing protocol. However, besides of being specifically focused in routing service, the proposed IDS has a centralized architecture, which we claim to be incompatible with the MANET nature.

Figure 5 – Experimentation platform The use of mobile agents in the conception of IDS data analysis and the intrusion inference in a central entity has been a hot topic in the last years. Table 1 summarizes can be found in [24,25]. In all such architectures, the major initiatives in the field. distribution is restricted to the data collection process and W. Jasen [10] from the Mobile Agent Security they are, therefore, not suitable on the MANET context. project at NIST (USA) provides a elusive analysis of The SPARTA (Security Policy Adaptation benefits and possible drawbacks of using mobile agents in Reinforced Through Agents), proposed by C. Krügel et intrusion detection and P. Mell et al. [20] from the same al. [26] (Technical University – Vienna, Austria), team have defined an IDS architecture using mobile developed concurrently with ours, also uses mobile agents agents that is claimed to be resistant to deny of service to carry on events and queries, both of them being attacks. However, such architecture is strongly linked formally specified in a typed language. Each node has an with network infrastructure, which are not observed in autonomous LIDS formed by local sensors and a mobile MANETs. A similar approach can be found in [21]. agent platform. Unfortunately, the SPARTA architecture E. Spafford et al. [22] (Purdue University, USA) have relies on a single central node, named management designed the AAFID (Autonomous Agents For Intrusion console. Although this central entity is not directly Detection) system and M. Asaka et al. [23] (Informationinvolved in the actual detection processes, it has an Technology Promotion Agency – IPA, Japan) have important role in the system architecture, each joining proposed the IDA (Intrusion Detection Agent). Both of node needing to register itself in the management console. them have a hierarchical architecture, organized around a Finally, a complete different approach for the use of central node. The central node is the kernel of the IDS and mobile agents in intrusion detection is proposed by the uses information collected in a distributed manner to independent works from S. Hofmeyr et al. [27] detect intrusions. Similarly, G. Helmer et al. [18] (Iowa (University of New Mexico, USA) and S. Fenet et al.[28] State University, USA) have proposed the MAIDS (Université Claude Bernard Lyon, France). In [27], IDS (Mobile Agent Intrusion Detection System), which architecture emulates the biological immune system by involves an IDS based upon intelligent agent technology. using sets of specialized mobile agents (each pattern of Mobile agents are used to allow various types of intrusion is mapped by a different agent) that roam the specialized agents, referred as low-level agents, which monitored system searching for intrusion traces, while in travel among data collection points and implements [28] the mobile agents mimic the behavior of social simple detection of suspicious activities. At each instance insects. Unfortunately, the mobility pattern is poorly of MAIDS, collaborating static agents (high-level agents), described in both systems. which specialize on a specific category of intrusion and In our design, a LIDS is placed on each node of the collaborate locally with each other, realize intrusion MANET and the LIDSes cooperate both in the data detection inference. The notion of cooperation between collection (sensor), intrusion detection (analyzer) and instances of MAIDS is defined in terms of a centralized alert correlation (manager), in a completely distributed data warehouse system. Other approaches realizing the manner. No central entity is required. Also, collaboration

IDS AAFID [22] IDA [23] MAIDS [18] SPARTA [26]

Data Source System System System/Network System/Network

Table 1 – Survey of mobile agent based IDS Method Data Collection Data Analysis Misuse Mobile Agents Centralized Misuse Mobile Agents Centralized Hybrid Mobile Agents Centralized Misuse Mobile Agents Mobile Agents

Alert Correlation No No Yes No

is done mainly in the neighborhood (e.g. attacks against the routing protocol) or in a restricted number o nodes involved in a multi-phase attack (e.g. stepping stone attack), keeping the communication and processing overhead local or within selected nodes.

8. Conclusions and future work In this paper, we proposed a new distributed and modular architecture for MANET IDSes. The proposed model was validated by implementation and formal description of IDS messages and rules concerning three attacks. The experimental results have demonstrated the feasibility of our IDS. Moreover, our experimentation shows that the proposed architecture is perfectly suited to the MANET context. A complete implementation cycle has been realized and the results obtained are encouraging. We are currently considering performance aspects, which depend mainly on the design of a lightweight mobile agent platform, customized for the needs of the IDS. Further extensions to the implementation include the design of an anomaly based IDS Kernel module and a full-featured implementation of the IDMEF and IDXP, which are still in draft form. Another important issue is the security of the mobile agent platform. In our design, we intend to use a distributed trust and authentication service described in [3].

References [1] L. Zhou and Z. J. Haas - Securing ad hoc networks. IEEE Network, Vol. 13, Nov.-Dec. 1999, pp. 24 –30, 1999. [2] H. Luo, P. Zerfos, J. Kong, S. Lu, and L. Zhang – Selfsecuring Ad Hoc Wireless Networks. Proc. 7th Int. Symposium on Comp. and Communications (ISCC’02), 2002. [3] R. Puttini, L. Me, R. de Sousa, “Certification and Authentication Services for Securing Manet Routing Protocols”, accepted for publication in 5th IEEE Int. Conf. on Mobile and Wireless Communications Networks (MWCN2003), Oct. 2003. [4] Y. Zhang and W. Lee – Intrusion detection in wireless ad hoc networks. Proc. 6th ACM Int. Conf. on Mobile Computing and Networking (MOBICOM 2000), pp. 275-283, 2000. [5] Puttini, R; Percher, JM; Me, L, Camp, O; de Sousa, R. “A Modular Architecture for a Distributed IDS for Mobile Ad Hoc Networks”. Lecture Notes on Computer Science vol. 2669, Springer-Verlag, pp. 91-113, 2003. [6] K. Ilgun, R. A. Kemmerer, and P. A. Porras – State Transition Analysis: A Rule-Based Intrusion Detection Approach. IEEE Trans. on Software Engineering, pp. 181-199, March 1995. [7] J. Cabrera, L. Lewis, R. Prasanth, X. Qin, W. Lee, and R. Mehra – Proactive detection of distributed denial of service attacks using MIB traffic variables – a feasibility study. Proc. 7th IFIP/IEEE Int. Symposium on Integrated Network Management, Seattle, WA, USA, may 2001.

[8] S. Staniford-Chen, and L. Heberlein – Holding Intruders Accountable on the Internet. Proc. 1995 IEEE Symposium on Security and Privacy, 1995. [9] F. Wang, F. Wu – On the vulnerabilities and Protection of OSPF Protocol. Proc. 1998 Int. Conf. on Computer Communications and Networks, 1998. [10] W. Jansen. Intrusion Detection with Mobile Agents. Computer Communications 25(15), Special Issue on Intrusion Detection, Elsevier, pp. 1392-1401, September 2002. [11] H. Debar, M. Dacier and A. Wespi - A revised taxonomy for intrusion-detection systems, IBM Research Report, 1999. [12] W. Lee; S. J. Stolfo; and K. W. Mok - A data mining framework for building intrusion detection models. Proc. 1999 IEEE Symposium on Security and Privacy, 1999. [13] D. Curry, H. Debar, and Merrill Lynch - Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language (XML). IETF Internet draft. June 2002. [14] H. Yang, X. Meng and S. Lu, “Self-Organized Network Layer Security in Mobile Ad Hoc Networks”, Proc. ACM Workshop on Wireless Security – 2002 (WiSe’2002), in conjunction with ACM MOBICOM2002, September, 2002. [15] T. Clausen, P. Jacquet, A. Laouiti, P. Minet, P. Muhlethaler, A. Qayyum, L. Viennot - Optimized Link State Routing Protocol - IETF Internet Draft, MANET working group, version 11, Jul. 2003. [16] K. McCloghrie; and A. Bierman - Entity MIB (Version 2). IETF Request for Comment 2737, December 1999. [17] J. Kiniry and D. Zimmerman - Special Feature: A HandsOn Look at Java Mobile Agents. IEEE Internet Computing, Vol. 1, No. 4, July/August 1997. [18] G. Helmer, J. Wong, V. Honavar, L. Miller, Y. Wang – Lightweight Agents For Intrusion Detection. To be published in The Journal of Systems and Software. [19] S. Gwalani, E. Royer, G. Vigna, R. Kemmerer – AODVSTAT: Intrusion Detection in AODV (work in progress) [20] P. Mell, D. Marks, M. McLarnon – A Denial-of-Service Resistant Intrusion Detection Architecture. Computer Networks, Special Issue on Intrusion Detection, Elsevier Science BV, November 2000. [21] P.C. Chan, V. K. Wei - Preemptive distributed intrusion detection using mobile agents. Proc. 11th IEEE Int. Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 2002), pp. 103-108, 2002. [22] Eugene H. Spafford and Diego Zamboni – Intrusion detection using autonomous agents. Computer Networks, 34(4):547-570, October 2000. [23] M. Asaka – The Implementation of IDA: An Intrusion Detection Agent System. Proc. 11th FIRST Conf. on Computer Security Incident Handling and Response, 1999. [24] M. C. Bernardes, E. Moreira – Implementation of an intrusion detection system based on mobile agents. Proc. of 2000 Int. Symposium on Software Engineering for Parallel and Distributed Systems, pp. 158-164, 2000. [25] J. Barrus, N. Rowe - A Distributed Autonomous-Agent Network-Intrusion Detection and Response System. Proc. Command and Control Research and Tech. Symposium, 1998. [26] Christopher Krügel, Thomas Toth - Flexible, Mobile Agent Based Intrusion Detection for Dynamic Networks. Proc. European Wireless (EW2002), Italy, February 2002.

[27] S. Hofmeyr, S. Forrest – Architecture of an Artificial Immune System. Evolutionary Computation 7(1), MorganKaufmann, San Francisco, CA, pp. 1289-1296 (2000). [28] S. Fenet, S, Hassas – A Distributed Intrusion Detection and response System Based on Mobil Autonomous Agents Using Social Insects Communication Paradigms. Proc. 1st Int. Workshop on Security of Mobile Multiagent Systems, 2001.