IDS Active Response Mechanisms: Countermeasure Subsytem for Prelude IDS. Krzysztof Zaraska. July 9, 2002 ...
IDS Active Response Mechanisms: Countermeasure Subsytem for Prelude IDS Krzysztof Zaraska July 9, 2002
1
Introduction
The number of security vulnerabilities in popular software forces system administrators to constantly keep track of new releases of patches from software vendors and exploit code from underground community or security researchers. In ideal case patch is available before exploit; this is however not a rule. Furthermore in real life situations patch not always can be applied on time due to various circumstances (e.g. known problems with the patch, administrator work overload, etc.). IDS signatures for a particular type of attack are usually available soon after the exploit is released; hence a properly maintained IDS can detect if someone tries to exploit a known vulnerability (also, certain IDS may be capable of detecting unknown exploits by means such as polymorphic shellcode detection). The concept of active response mechanisms or countermeasures in IDS is based on the idea of having an IDS capable of automatic reaction once a compromise threat is observed. The goal is to prevent further compromise by blocking the communication between attacker and attacked machine. It must be noted that if such a system is implemented or configured incorrectly it can be fooled into blocking legitimate traffic.
1.1
Techniques
The following techniques can be used to reach our goals: RST emmision is a simple yet commonly used method. It is based on the fact, that a network error message (TCP RST for TCP protocol or ICMP Net/Host/Port unreachable packet for UDP protocol) when received by a TCP/IP stack causes the connection to be dropped. The concept is then to build and inject spoofed TCP RST or ICMP packet when packet sniffer detects an attack. Unfortunately, this technique has a number of limitations, most important of which are the race situation between a packet generated by IDS and packets send by attacker and vulnerability to evasion. The issues related to RST emmision are discussed in detail in [3]. This technique is for example used by Snort with FlexResp extension. firewall update In this technique the IDS modifies the firewall ruleset adding a rule blocking traffic from the attacker. Example solutions: Guardian[4], SnortSam[7]. routing table update is similar to firewall update, the main difference is that a null (blackhole) route to attacking host is added on border 1
routers. signature–based firewall , e.g. Hogwash [6] is a hybrid solution integrating firewall with an IDS. Basically it analyses passing traffic like IDS does and if a packet is considered dangerous, it is dropped or modified.
1.2 1.2.1
Limitations Timing
It is obvious that the application discussed here is time–critical, i.e. an active response mechanism reacting after a long time is not useful. We must note however, that IDS reacts after the dangerous event has taken place (this does not apply to signature–based firewalls). It means that even if latency is minimized, IDS may not be able to prevent actual compromise from happening; e.g. when IDS detects a packet containing shellcode and sends RST packet to tear connection down, the shellcode will still be executed. Therefore blocking communication between target and attacker is rather aimed towards preventing attacker from using obtained shell on remote machine, or isolating a worm–infected machine to prevent it from infecting further hosts. A solution here would be to block attacker at the attack preparation stage, e.g. when a portscan is detected. However since port scans are easy to spoof this would lead to a self–inflicted DoS condition (see below). 1.2.2
Self–inflicted DoS
IDS with active response subsystem using firewall update can be exploited by an attacker in order to cause a DoS condition. For example, if an IDS is configured to automatically block every IP address from which a port scan originates, an attacker can easily spoof a port scan from a hosts she wishes to be blocked. DNS servers are standard example here — spoofing port scan from them will cause them to be blocked at the firewall, and since many applications (both client and server side) actively depend on DNS, a serious service disruption can occur. A standard solution is to incorporate a white list, containing hosts which cannot be blocked, such as DNS servers, Kerberos servers, etc. It must however be noted that attacker may start spoofing hosts non–critical to network infrastructure which are not whitelisted but users depend on — i.e. high– profile Web sites. The countermeasure is to expand the whitelist, to include also these sites. This however still allows the attacker to cause harm, e.g. by spoofing selected clients and causing them to be blocked.
2
Another danger is clogging firewall with inserted rules; since packet has to be matched against a larger number of rules the processing time increases, and thus firewall throughput decreases. A detailed analysis of firewall behavior with increasing numbers of rules can be found in [8]. It should be however noted that according to this study the performance drops significantly when ruleset consists of several hundreds or more rules. Therefore by spoofing large number of hosts, attacker may actually bring firewall to stop. This problem can be prevented by using rules with limited lifetime (i.e. removed from ruleset after a given time) and/or limiting number of rules that can be inserted.
2 2.1
Countermeasures in Prelude IDS About Prelude IDS
Prelude is a hybrid IDS, designed to be modular, fast, and efficient. It is composed of several sensors, each having a different task (host based, network based), and distributed accross the network. A central Manager is responsible for collecting alerts from sensor, and outputting them in an user readable way (file logging, database logging). All modules are based on Prelude Library, libprelude which provides unified support for secure communication (using OpenSSL library), common data types (e.g. alert representation as defined by IDMEF standard) and handling of dynamically loadable plugins. Detailed description of Prelude can be found in [1].
2.2
Design Principles
The design of the countermeasure (CM) subsystem follows the main principle of Prelude architecture, i.e. modularity. Therefore the subsystem was designed and implemented as consististing of many modules performing predefined set of functions and communicating over standarized interfaces. This will allow modules to be easily replaced or added, also by third party vendors, since creating new modules does not require knowledge of large parts of the source tree. Furthermore, elements of subsystem can be placed on different hosts in order to better reflect network topology, facilitate administration, and speed up reaction. This approach also facilitates future enhancing of the subsystem, by replacing existing modules or adding new ones. Following types of modules are introduced: triggering modules which are responsible for analyzing alerts reported by Prelude sensors and making decision if, and what action should be 3
taken for each alert. Subsystem can be equipped with many triggering modules, using various decision making algorithms. For example, a specialized module may be used for triggering immediate reaction to high severity alerts (e.g. detecting of attempted buffer overflow exploit against a known to be vulnerable machine) along with a module performing correlation analysis on alerts stacked in the database and reacting when a possibly dangerous trend is detected; in this example decisions are taken independenty by both modules. Also, introducing manual triggering mechanism requires only adding a new triggering module. communication modules which are responsible for communication between various components of the subsystem. In particular they are responsible for communication from triggering modules and action modules (agents) performing actual action. action modules (agents) which are responsible for performing actual action, i.e. killing attacked process or reconfiguring firewall to block communication between attacker and victim hosts. It is also needed to incorporate protection against self–inflicted Denial– of–Service, so the subsystem cannot be used to cause harm to protected network (or, at least such abuse should be made as difficult as possible for the potential attacker). Next, subsystem should be flexible: configuration should be easily adaptable to the network it is being deployed on to reflect its structure and local security policies.
2.3
Architecture
The main principle of subsystem architecture can be defined as distributed detection, centralized decision and distributed reaction. This principle follows Prelude’s semi–distributed architecture, where sensors located in the various parts of the guarded network send reports to a central manager (or, to a central network of managers if such a configuration is used). With such architecture it’s natural that decisions regarding using available countermeasures should be taken at manager level; therefore the most natural solution is to implement triggering modules as Prelude Manager plugins. Also, sensors communicate with managers and managers communicate with agents; there’s no direct communication between sensors and agents. System behavior under attack is show in figure 1, data flow in this situation is shown in figure 2. 4
Figure 1: Prelude with CM subsystem in action (based on [2]). Numbers in parantheses denote events sequence
5
Figure 2: Data flow within Prelude system during attack shown in fig. 1 It must be noted that such architecture makes impossible using countermeasures such as RST emmision due to timing problems. If RST emmision was to be implemented following above guidelines, a sensor capable of performing RST emmision would have to issue alert to manager and then wait for permission to react. It is highly probable that by the time it received the action request several new packets would have been exchanged between attacker and target host, thus changing currently valid sequence and acknowledge numbers. As a result, delayed RST packet would have been dropped by the host it was sent to. One of possible solutions would be to make such sensor capable of tracking sequence numbers in analyzed connections and using values valid at the time of RST emmision. Another possibility is to make an exception in centralized decision model and allow sensors to emmit RST packets; of course in such a situation Manager must be informed that sensor has taken the action. Although this is technically possible, it may introduce administrative problems related to policy management; with centralized decision making policy has to be imported only into manager(s) while with this approach also sensors must be aware of relevant elements of policy. This may lead to problems at sites with large number of sensors and could require implementing central policy management system. Above problems with RST emmision as well as the drawbacks of this technique (see [3] for details) are main reasons for resignation from implementing 6
such capabilities at the current stage of the project and focusing mainly on performing firewall updates.
3
Implementation
As can be seen from above, changes in Prelude related to implementing the subsystem are limited to modifying Prelude Manager and creating new software packages, that is agents, responsible for performing actual actions. Overall view of subsystem structure is given in fig. 3.
3.1
Abstraction layers
The following abstraction layers are defined for supporting firewall devices (fig. 4): • Communication plugin API: this is the highest abstraction layer, defining a common interface for all communication plugins • Generic agent interface: this is network protocol used by generic firewall agent; a specialized agent can use the same communication protocol and therefore communicate with generic communication plugin in Prelude Manager • Generic agent firewall plugin API: this is the API used for communication between generic firewall agent; this interface is intented for usage with software firewalls (see section 3.3.1 below).
3.2
Prelude Manager
Prelude Manager code has been modified to add following functionality: • support for new plugin types: triggering and communication • support for data types for internal communication between countermeasure plugins • common CM communication layer, providing secure connection and authentication support between agents and communication plugins • support for white– and blacklisting hosts; white list contains the addresses of hosts which cannot be blocked, while black list contains the addresses of hosts communication with is prohibited 7
Figure 3: Overview of CM subsystem structure (from [2]).
8
Figure 4: Abstraction layers (standarized interfaces) in CM subsystem 3.2.1
Communication Plugins
Communication plugins are responsible for communication between Prelude Manager and agents. These plugins interface between internal CM command representation in Prelude Manager and communication protol used by agents. A plugin of given type can communicate with many agents of the same type, i.e. using the same communication protocol. Also, these plugins are responsible for processing status information received from the agent and relaying it to core logic in Manager. A special type of communication plugin is a generic agent, used for communication with generic agents (see below). It is recommended that communication protocol between plugin and agent should be based on the libprelude library if posssible. 3.2.2
Triggering plugins
Triggering plugins implement the design concept of triggering modules (see section 2.2). Every alert received by Manager is passed to all triggering plugins. Each plugin analyzes received alerts and trigger reaction independently.
9
3.3
Agents
Agents are software programs actually performing actions requested by Prelude Manager. Since current implementation focuses on firewall managing agents other types of agents are not discussed here. As stated above (see section 3.2.1), Prelude Manager employs a set of communication plugins for communicating with agents. Since one plugin is capable of communicating with many agents using the same communication protocol it is desirable to use the same agent code for similar applications and use libprelude’s plugins mechanism for managing application–specific code. Such agent is referred to as generic agent. The purpose of firewall agent is to modify the firewall rules to block communication between attacker and victim host. A command received from Prelude Manager contains all the necessary information describing a firewall rule to be inserted, such as: • action type: ACCEPT accept packet DROP drop packet silently REJECT drop packet and send back error message (e.g. TCP RST packet) • layer 4 protocol (TCP, UDP, ICMP) • rule TTL (time–to–live): time after which rule is to be removed from firewall ruleset by the agent • rule rank • rule options • source and target address, netmask and port number It is assumed that this set of information if sufficient for agent to generate a firewall rule working as desired for any firewall type. The subsystem deals with two types of firewalls: hardware and software solutions.
10
3.3.1
Software firewalls and generic firewall agent
A software firewall is a firewall build using a packet filter software running on a general purpose operating system. In particular, we are interested in firewalls build upon a POSIX–compliant free operating systems such as Linux or *BSD. Since we are dealing with time–critical application the communication protocol used between Prelude Manager and firewall agent should not require complex lexical analysis; therefore in the generic firewall agent interface the data is transferred in binary form. Also, for the same reason, an agent managing software firewall (e.g. Linux/Netfiler) should not use system() or similar calls to invoke shell firewall configuration tool (e.g. /sbin/iptables) and pass it the rule; instead it should directly communicate with firewall at low level using the same mechanism that original shell tool does (e.g. a kernel socket). This avoids the overhead related to invoking the utility (and sometimes also shell) along with syntax parsing performed by the utility. It must be noted that this shell–based approach is present in many simpler solution, e.g. Guardian[4] or PortSentry[5]. As stated above, we are particularly interested in Linux and *BSD systems (i.e. systems on which Prelude is currently available). Since there are no major problems with userland code portability between these systems, a generic agent concept can be used here: at each firewall host a generic firewall agent can be deployed, equipped with a plugin dependant on the type of the firewall. The agent can of course have only one plugin at a time, and this plugin is highly dependant on the type of the operating system and the type of the firewall; e.g. a different plugin is needed for Linux 2.2 and 2.4 series kernels. However, since firewall plugin interface is standarized, there is no problem with adding new firewall types. Structure of generic agent is shown on fig. 5. It must also be noted, that theoretically it is possible to use this approach also for abstracting hardware firewall; however we believe that this solution could introduce too much complication and should be avoided in favor of specialized communication plugins. 3.3.2
Hardware firewalls and routers
Within this paper the term hardware firewall refers to a “black box” device used for filtering traffic that is controlled over a dedicated interface (e.g. serial link or Ethernet management port). Such a device can be controlled either by a specialized agent located on a
11
Figure 5: Generic firewall agent structure host near the firewall (i.e. a management host for the firewall connected to the device via a serial link) or a specialized communication plugin in Prelude Manager (e.g. in case when machine running Prelude Manager is located on the same network segment as firewall’s management network interface). Thanks to the concept of abstraction layers the protocol used for communicating with the firewall is not important; the only restriction is that firewall must be able to process rules equivalent to those used by Prelude Manager (see section 3.3 above). Another solution for blocking communication with the attacker is to reconfigure border routers, e.g. by inserting null routes for offending hosts. Note that since the functionality is similar to the one proposed for firewalls, an attempt can be made to handle also routing devices using the same abstraction layers as above. Again, since it is possible to use any communication protocol between agent or communication plugin and the device both dedicated interfaces and routing protocols (e.g. BGP) could be used. 3.3.3
Firewall vendor’s view of abstraction layers
Thanks to the scheme of abstraction layers, firewall vendor (open source project or commercial entity) or contributor wishing to add support for her firewall can provide the most suitable of the following solutions:
12
• plugin for generic firewall agent (this is believed to be the best solution for software firewalls) • specialized firewall agent using generic agent interface • specialized communication plugin for Prelude Manager communicating directly with firewall • specialized communication plugin for Prelude Manager communicating with specialized agent (also provided) The only restriction that is made is the compatibility requirement with one of the three predefined abstraction layers.
4
Project status
4.1
Current implementation
In June 2002, the first implementation known to work in laboratory environment (referred to in this document as “current implementation”) has been done by Vincent Glaume and Baptiste Malguy as an end of studies project ´ ´ at Ecole Nationale Sup´erieure Electonique, Informatique et Radiocommunications (ENSEIRB) in Bordeaux, France. Original documentation (on which this paper is based) is contained in [2]. The implementation is based on the development version of Prelude at the time (this version may be thought of as pre–0.8); the subsystem is scheduled to be merged into main Prelude source tree after the next major release, that is it will most probably be available in version 1.0 of Prelude. Although the current implementation can’t be viewed as complete, it contains following modules: • simple triggering plugin • generic communication plugin • generic agent • Linux Netfilter plugin using libiptc[9] library.
13
4.1.1
Triggering plugin
The plugin is based on the concept of scoring, i.e. assigning each alert a score based on following parameters: 1. attack severity 2. target vulnerability level 3. alert confidence Next, the resulting score is added to a table where information about attackers and targets is kept; that is, an accumulated score is associated with each attacker and target host. When accumulated score exceeds predefined threshold value, reaction is triggered (i.e. attacking host is firewalled). The usage of scoring aims towards preventing trigger overreactivity that could lead to a self–inflicted DoS situation. As for scoring function, it’s value should increase fast with the level of alert severity and target vulnerability, while increasing slower with the growth of alert confidence. To meet these requirements, an exponential function has been chosen in the form of: C(a1 exp(a2 D) + b1 2 exp(b2 S) + k) where: a1 , a2 , b1 , b2 , k — coefficients (see below), C — alert confidence, D — alert severity, S — target vulnerability Note that D and S have non–negative values increasing with attack severity and target vulnerability respectively. At the same time, following requirements are defined: • a low–severity attack against a highly vulnerable machine should be scored higher than a high severity attack against a mildly vulnerable machine • moderately severe attack against a moderately or highly vulnerable machine should have similar score as high-severity attack against a mildly vulnerable machine • minimal value of scoring function should be positive Basing on these, values for a1 , a2 , b1 , b2 , k can be chosen, and accumulated score can be written as: Ni+1 = Ni + C(a1 exp(a2 D) + b1 2 exp(b2 S) + k) 14
where: Ni+1 — new score for given attacker or target, Ni — current score for given attacker or target, C — alert confidence, D — alert severity, S — target vulnerability The values of scoring function for C = 1, D ∈ [0, 2], S ∈ [0, 4] are given in the following table: D\S 0 1 2
4.1.2
0 1 2 4
1 2 3 4 3 6 9 13 4 7 10 14 7 10 13 17
Generic communication plugin
This plugin is responsible for communication between Prelude Manager and generic firewall agent. It uses libprelude–based secure communications to send the agent the rules for firewall update, using the scheme briefly described in section 3.3. 4.1.3
Generic firewall agent
This is the implementation of generic firewall agent concept discussed in section 3.3.1. It’s main part is responsible for communicating with Prelude Manager and decoding received commands. As for now, only one–way communication is implemented, i.e. the plugin does not send status messages to Prelude Manager. Currently only one plugin is implemented, handling Netfilter firewall on Linux using iptc library [9]. Since the agent should not interfere with predefined firewall policy, the agent creates a new rule chain in table filter, responsible for filtering packets. Since rules added by the agent are inserted into the new chain, administrator has full control over the firewall policy simply by defining appropriate position of the chain with respect to the rest of the ruleset. More information on using Netfilter can be found in [10].
4.2
Project future
As seen above, the detection, alerting and logging facilities are not affected by the subsystem. Furtermore, subsystem takes advantage from Prelude library (libprelude) for implementing secure communications between modules (via SSL) and plugins handling. Therefore intergartion with the main source tree as well as deployment in existing installations of Prelude IDS should not be problematic. 15
Following features are planned to be added: • support for more firewalls, both software like IPFilter or IPFW and hardware like Cisco routers • new, more advanced triggering plugins • support for signature–based firewalls, like Hogwash
16
5
Acknowledgements
The subsystem has been brought into existence thanks to hard work of two main programmers: Vincent Glaume Baptiste Malguy Also, following people have greatly contributed by giving their valuable opinions during endless discussions over subsystem design: ark D J Hawkey Jr eberkut Karsten W. Rohrbach Michael Samuel Yoann Vandoorselaere
References [1] Y. Vandoorselaere, L. Oudot “Prelude-IDS, un Syst`eme de D´etection d’Intrusion hybride opensource”, MISC issue 3, July 2002 [2] V. Glaume, B. Malguy “R´eassemblage TCP & Contre–Mesure au sein de l’IDS Prelude”, end of studies project, ENSEIRB Bordeaux 2002 [3] J. Larsen, J. Haile “Understanding IDS Active Response Mechanisms ” http://online.securityfocus.com/infocus/1540 [4] Guardian http://www.snort.org/dl/contrib/guardian-1.6.tar.gz [5] PortSentry http://www.psionic.com/products/portsentry.html [6] Hogwash http://hogwash.sourceforge.net/ [7] SnortSam http://www.snortsam.net/ [8] D. Hartmeier “Design and Performance of the OpenBSD Stateful Packet Filter (pf)” http://www.benzedrine.cx/pf-paper.html [9] L. Balliache “Querying libiptc HOWTO” http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/index.html [10] R. Russell “Linux 2.4 Packet Filtering HOWTO” http://netfilter.samba.org/documentation/HOWTO//packet-filteringHOWTO.html 17
Contents 1 Introduction 1.1 Techniques . . . . . . . . 1.2 Limitations . . . . . . . 1.2.1 Timing . . . . . . 1.2.2 Self–inflicted DoS
. . . .
1 1 2 2 2
2 Countermeasures in Prelude IDS 2.1 About Prelude IDS . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 3 4
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
3 Implementation 3.1 Abstraction layers . . . . . . . . . . . . . . . . . . . 3.2 Prelude Manager . . . . . . . . . . . . . . . . . . . 3.2.1 Communication Plugins . . . . . . . . . . . 3.2.2 Triggering plugins . . . . . . . . . . . . . . . 3.3 Agents . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Software firewalls and generic firewall agent 3.3.2 Hardware firewalls and routers . . . . . . . . 3.3.3 Firewall vendor’s view of abstraction layers . 4 Project status 4.1 Current implementation . . . . . . . 4.1.1 Triggering plugin . . . . . . . 4.1.2 Generic communication plugin 4.1.3 Generic firewall agent . . . . . 4.2 Project future . . . . . . . . . . . . . 5 Acknowledgements
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . . . . . .
. . . . .
. . . .
. . . . . . . .
. . . . .
. . . .
. . . . . . . .
. . . . .
. . . .
. . . . . . . .
. . . . .
. . . .
. . . . . . . .
. . . . .
. . . . . . . .
7 7 7 9 9 10 11 11 12
. . . . .
13 13 14 15 15 15 17
18
