MIRAGE : an audit tool for the analysis of security policies

J. Garcia-Alfaro^†,‡, F. Cuppens^†, and N. Cuppens-Boulahia^†

^†GET-ENST-Bretagne, 35576 Cesson Sévigné (France)

^‡DEIC-UAB, 08193 Bellaterra, Barcelona (Spain)

Abstract:

The use of different network security components, such as firewalls and network intrusion detection systems (NIDSs), is the dominant method to survey and guarantee the security policy in current corporate networks. On the one hand, firewalls are traditional security components which provide means to filter traffic within corporate networks, as well as to police the incoming and outcoming interaction with the Internet. On the other hand, NIDSs are complementary security components used to enhance the visibility level of the network, pointing to malicious or anomalous traffic. To properly configure both firewalls and NIDSs, it is necessary to use several sets of filtering and alerting rules. Nevertheless, the existence of anomalies between those rules, particularly in distributed multi-component scenarios, is very likely to degrade the network security policy. The discovering and removal of these anomalies is a serious and complex problem to solve. We present in this document a set of analysis and rewriting algorithms for such a management, and the implementation of these algorithms in a first research prototype called MIRAGE (MIsconfiguRAtion manaGEr).

1.  Introduction

Generally, once a security administrator has specified a security policy, he or she aims to enforce it in the information system to be protected. This enforcement consists in distributing the security rules expressed in this policy over different security components of the information system – such as firewalls, intrusion detection systems (IDSs), intrusion prevention systems (IPSs), proxies, etc. – both at application, system, and network level. This implies cohesion of the security functions supplied by these components. In other words, security rules deployed over the different components must be consistent, not redundant and, as far as possible, optimal.

An approach based on a formal security policy refinement mechanism (using for instance abstract machines grounded on set theory and first order logic) ensures cohesion, completeness and optimization as built-in properties. Unfortunately, in most cases, such an approach has not a wide follow and the policy is more often than not empirically deployed based on security administrator expertise and flair. It is then advisable to analyze the security rules deployed to detect and correct some policy anomalies – often referred in the literature as intra- and inter-configuration anomalies [6].

These anomalies might be the origin of security holes and/or heaviness of intrusion prevention and detection processes. Firewalls [9] and network intrusion detection systems (NIDSs) [18] are the most commonly used security components and, in this document, we focus particularly on their security rules. Firewalls are prevention devices ensuring the access control. They manage the traffic between the public network and the private network zones on one hand and between private zones in the local network in the other hand. The undesirable traffic is blocked or deviated by such a component. NIDSs are detection devices ensuring a monitoring role. They are components that supervise the traffic and generate alerts in the case of suspicious traffic. The attributes used to block or to generate alerts are almost the same. The challenge, when these two kinds of components coexist in the security architecture of an information system is then to avoid inter-configuration anomalies.

In [10, 11], we presented an audit process to manage intra-firewall policy anomalies, in order to detect and remove anomalies within the set of rules of a given firewall. This audit process is based on the existence of relationships between the condition attributes of the filtering rules, such as coincidence, disjunction, and inclusion, and proposes a transformation process which derives from an initial set of rules – with potential policy anomalies – to an equivalent one which is completely free of errors. Furthermore, the resulting rules are completely disjoint, i.e., the ordering of rules is no longer relevant.

In [2, 3], we extended our proposal of detecting and removing intra-firewall policy anomalies [10, 11], to a distributed setup where both firewalls and NIDSs are in charge of the network security policy. This way, assuming that the role of both prevention and detection of network attacks is assigned to several components, our objective is to avoid intra- and inter-component anomalies between filtering and alerting rules. The proposed approach is based on the similarity between the parameters of a filtering rule and those of an alerting rule. This way, we can check whether there are errors in those configurations regarding the policy deployment over each component which matches the same traffic.

The advantages of our proposal are threefold. First, as opposite to the related work we show in Section 2, our approach not only considers the analysis of relationships between rules two by two but also a complete analysis of the whole set of rules. This way, those conflicts due to the union of rules that are not detected by other proposals (such as [4, 5, 14]) are properly discovered by our intra- and inter-component algorithms. Second, after applying our intra-component algorithms the resulting rules of each component are totally disjoint, i.e., the ordering of rules is no longer relevant. Hence, one can perform a second rewriting of rules in a close or open manner, generating a configuration that only contains deny (or alert) rules if the component default policy is open, and accept (or pass) rules if the default policy is close (cf. Section 4.3). Third, we also presented in our proposal a network model to determine which components are crossed by a given packet knowing its source and destination, as well as other network properties. Thanks to this model, our approach better defines all the set of anomalies studied in the related work. Furthermore the lack of this model in other approaches, such as [4, 5], may lead to inappropriate decisions.

The remaining of this paper is organized as follows. Section 2 starts with an analysis of some related work. Section 3 introduces a network model that is further used in Section 4 and Section 5 when presenting, respectively, our intra and inter-component anomaly's classifications and algorithms. Section 6 overviews a first implementation of our algorithms in order to validate its performance over real multi-component scenarios. Finally, Section 7 closes the document with some conclusion and future work.

2.  Related Work

Some related proposals to our work, such as [1, 14, 4, 15, 5, 6], provide means to directly manage the discovery of anomalies from the components' configuration. For instance, the authors in [1] consider that, in a configuration set, two rules are in conflict when the first rule in order matches some packets that match the second rule, and the second rule also matches some of the packets that match the first rule. This approach is very limited since it just detects a particular case of ambiguity within a single component configuration. Furthermore, it does not provide detection on multiple-component configurations.

In [14], two cases of anomalies are considered. First, a rule Rj is defined as backward redundant iff there exists another rule Ri with higher priority in order such that all the packets that match rule Rj also match rule Ri. Second, a rule Ri is defined as forward redundant iff there exists another rule Rj with the same decision and less priority in order such that the following conditions hold: (1) all the packets that match Ri also match Rj; (2) for each rule Rk between Ri and Rj , and that matches all the packets that also match rule Ri, Rk has the same decision as Ri. Although this approach seems to head in the right direction, we consider it as incomplete, since it does not detect all the possible cases of intra-component anomalies (as we define in this paper). For instance, given the set of rules shown in Figure 1(a), since R2 comes after R1, rule R2 only applies over the interval [51, 70] – i.e., R2 is not necessary, since, if we remove this rule from the configuration, the filtering policy does not change. The detection proposal, as defined in [14], cannot detect the redundancy of rule R2 within the configuration of such a given firewall. Furthermore, neither [14] nor [15] provide detection on multiple-component configurations.

Figure 1: Example of some firewall configurations.

The approaches presented in [4–6] propose a promising set of algorithms to detect policy anomalies in both single- and multi-firewall configuration setups. Nonetheless, we also consider this approach as incomplete. First, their intra- and inter-component discovery approach is not complete since, given a single- or multiple-component security policy, their detection algorithms are based on the analysis of relationships between rules two by two. This way, errors due to the union of rules are not explicitly considered (as our approach does). The set of rules shown in Figure 1(b), for example, may lead their discovery algorithms to inappropriate decisions. The approach defined in [4] cannot detect that rule R3 will be never applied due to the union of rules R1 and R2. Just a correlation signal – that is obviously a weaker signal than a shadowing one – would be labeled.

Although in [5] the authors pointed out to this problematic, claiming that they break down the initial set of rules into an equivalent set of rules free of overlaps between rules, no specific algorithms have been provided for solving it in [4–6]. From our point of view, the proposal presented in [23] best addresses this limitation, although it also presents some limitations. For instance, giving again the set of rules shown in Figure 1(a), the proposal presented in [23] reports two partial redundancies (respectively, between rules R1,R2; and rules R2,R3), instead of the full redundancy of rule R2.

The inter-component discovery presented in [4–6], moreover, considers as anomalies some situations that, from our point of view, must be suited to avoid inconsistent decisions between components used in the same policy to control or survey to different zones. For instance, given the following scenario:

   their algorithms will inappropriately report a redundancy anomaly between filtering rules FW1{R1} and FW2{R1}. This is because rule FW1{R1} matches every packet that also FW2{R1} does. As a consequence, [4] considers rule FW2{R1} as redundant since packets denied by this rule are already denied by rule FW1{R1}. However, this conclusion is not appropriate because rule FW1{R1} applies to packets from the external zone to the private zone whereas rule FW2{R1} applies to packets from the DMZ zone to the private zone. So, rule FW2{R1} is useful and cannot be removed. Though in [4, 5] the authors claim that their analysis technique marks every rule that is used on a network path, no specific algorithms have been provided for doing so. The main advantage of our proposal over their approach is that it includes a model of the traffic which flows through each component. We consider this is necessary to draw the right conclusion in this case.

Finally, although in both [6] and [23] the authors consider their work as sufficiently general to be used for verifying many other filtering based security policies such as intrusion detection and prevention systems, no specific mechanisms have been provided for doing so.

3.  Network Model and Topology Properties

The purpose of our network model is to determine which components within the network are crossed by a given packet, knowing its source and destination. It is defined as follows. First, and concerning the traffic flowing from two different zones of the distributed policy scenario, we may determine the set of components that are crossed by this flow. Regarding the scenario shown in Figure 2, for example, the set of components crossed by the network traffic flowing from zone external network to zone private3 equals [C1,C2,C4], and the set of components crossed by the network traffic flowing from zone private3 to zone private2 equals [C4,C2,C3].

Let C be a set of components and let Z be a set of zones. We assume that each pair of zones in Z are mutually disjoint, i.e., if zi ∈ Z and zj ∈ Z then zi ∩ zj = ∅. We then define the predicate connected(c1, c2) as a symmetric and anti-reflexive function which becomes true whether there exists, at least, one interface connecting component c1 to component c2. On the other hand, we define the predicate adjacent(c, z) as a relation between components and zones which becomes true whether the zone z is interfaced to component c. Referring to Figure 2, we can verify that predicates connected(C1,C2) and connected(C1,C3), as well as adjacent(C1,DMZ), adjacent(C2, private1), adjacent(C3,DMZ), and so on, become true. We then define the set of paths, P, as follows. If c ∈ C then [c] ∈ P is an atomic path. Similarly, if [p.c1] ∈ P (be "." a concatenation functor) and c2 ∈ C, such that c2 ∉ p and connected(c1, c2), then [p.c1.c2] ∈ P. This way, we can notice that, concerning Figure 2, [C1,C2,C4] ∈ P and [C1,C3] ∈ P.

Figure 2: Simple distributed policy setup.

Let us now define a set of functions related with the order between paths. We first define functions first, last, and the order functor between paths. We first define function first from P in C such that if p is a path, then first(p) corresponds to the first component in the path. Conversely, we define function last from P in C such that if p is a path, then last(p) corresponds to the last component in the path. We then define the order functor between paths as p1 ≤ p2, such that path p1 is shorter than p2, and where all the components within p1 are also within p2. We also define the predicates isFirewall(c) and isNIDS(c) which become true whether the component c is, respectively, a firewall or a NIDS.

Two additional functions are route and minimal route.We first define functtion route from Z to Z in 2^P , such that p ∈ route(z1, z2) iff the path p connects zone z1 to zone z2. Formally, we define that p ∈ route(z1, z2) iff the predicates adjacent(first(p), z1) and adjacent(last(p), z2) become true. Similarly, we define minimal route (or MR for short), such that p ∈ MR(z1, z2) iff the following conditions hold: (1) p ∈ route(z1, z2); (2) there does not exist p' ∈ route(z1, z2) such that p' < p. Regarding Figure 2, we can verify that the minimal route from zone private3 to zone private2 equals [C4,C2,C3], i.e., MR(private3, private2) = {[C4,C2,C3]}.

Let us finally conclude this section by defining the predicate affects(Z,Ac) as a boolean expression which becomes true whether there is, at least, an element z 2 Z such that the configuration of z is vulnerable to the attack category Ac 2 V , where V is a vulnerability set built from a vulnerability database, such as CVE/CAN [17] or OSVDB [19].

4.  Intra-component Classification and Algorithms

In this section we present our set of intra-component audit algorithms, whose main objective is the complete discovering and removal of policy anomalies that could exist in a single component policy, i.e., to discover and warn the security officer about potential anomalies within the configuration rules of a given component.

Let us start by classifying the complete set of anomalies that can occur within a single component configuration. An example for each anomaly will be illustrated through the sample scenario shown in Figure 3.

Figure 3: Example of filtering and alerting policies.

Intra-component Shadowing – A configuration rule Ri is shadowed in a set of configuration rules R whether such a rule never applies because all the packets that Ri may match, are previously matched by another rule, or combination of rules, with higher priority. Regarding Figure 3, rule C1{R6} is shadowed by the overlapping of rules C1{R3} and C1{R5}.

Intra-component Redundancy – A configuration rule Ri is redundant in a set of configuration rules R whether the following conditions hold: (1) Ri is not shadowed by any other rule or set of rules; (2) when removing Ri from R, the security policy does not change. For instance, referring to Figure 3, rule C1{R4} is redundant, since the overlapping between rules C1{R3} and C1{R5} is equivalent to the police of rule C1{R4}.

Intra-component Irrelevance – A configuration rule Ri is irrelevant in a set of configuration rules R if one of the following conditions holds:

(1) Both source and destination address are within the same zone. For instance, rule C1{R1} is irrelevant since the source of this address, external network, as well as its destination, is the same.

(2) The component is not within the minimal route that connects the source zone, concerning the irrelevant rule which causes the anomaly, to the destination zone. Hence, the rule is irrelevant since it matches traffic which does not flow through this component. Rule C1{R2}, for example, is irrelevant since component C1 is not in the path which corresponds to the minimal route between the source zone unix network to the destination zone windows network.

(3) The component is a NIDSs, i.e., the predicate isNIDS(c) (cf. Section 3) becomes true, and, at least, one of the condition attributes in Ri is related with a classification of attack Ac which does not affect the destination zone of such a rule – i.e., the predicate affects(zd,Ac) becomes false. Regarding Figure 3, we can see that rule C2{R2} is irrelevant since the nodes in the destination zone unix network are not affected by vulnerabilities classified as winworm.

4.1  Intra-component Algorithms

Our proposed audit process is a way to alert the security officer in charge of the network about these configuration errors, as well as to remove all the useless rules in the initial firewall configuration. The data to be used for the detection process is the following. A set of rules R as a list of initial size n, where n equals count(R), and where each element is an associative array with the strings condition, decision, shadowing, redundancy, and irrelevance as keys to access each necessary value.

For reasons of clarity, we assume one can access a linked-list through the operator Ri, where i is the relative position regarding the initial list size – count(R). We also assume one can add new values to the list as any other normal variable does (element ← value), as well as to remove elements through the addition of an empty set (element ← ∅). The internal order of elements from the linked-list R keeps with the relative ordering of rules.

Each element Ri[condition] is a boolean expression over p possible attributes. To simplify, we only consider as attributes the following ones: szone (source zone), dzone (destination zone), sport (source port), dport (destination port), protocol, and attack class – or Ac for short – which will be empty whether the component is a firewall. In turn, each element Ri[decision] is a boolean variable whose values are in {true, false}. Each element Ri[type] is a boolean variable whose values are in {filtering, alerting}. Finally, elements Ri[shadowing], Ri[redundancy], and Ri[irrelevance] are boolean variables in {true, false} – which will be initialized to false by default.

We split the whole process in four different algorithms. The first algorithm (cf. Algorithm 1) is an auxiliary function whose input is two rules, A and B. Once executed, this auxiliary function returns a further rule, C, whose set of condition attributes is the exclusion of the set of conditions from A over B. In order to simplify the representation of this algorithm, we use the notation Ai as an abbreviation of the variable A[condition][i], and the notation Bi as an abbreviation of the variable B[condition][i] – where i ∈ [1, p].

The second algorithm (cf. Algorithm 2) is a boolean function in {true, false} which applies the necessary verifications to decide whether a rule r is irrelevant for the configuration of a component c. To properly execute such an algorithm, let us define source(r) as a function in Z such that source(r) = szone, and dest(r) as a function in Z such that dest(r) = dzone.

The third algorithm (cf. Algorithm 3) is a boolean function in {true, false} which, in turn, applies the transformation exclusion (Algorithm 1) over a set of configuration rules to check whether the rule obtained as a parameter is potentially redundant.

The last algorithm (cf. Algorithm 4) performs the whole process of detecting and removing the complete set of intra-component anomalies. This process is split in three different phases. During the first phase, a set of shadowing rules are detected and removed from a top-bottom scope, by iteratively applying Algorithm 1 – when the decision field of the two rules is different. Let us notice that this stage of detecting and removing shadowed rules is applied before the detection and removal of proper redundant and irrelevant rules. The resulting set of rules is then used when applying the second phase, also from a top-bottom scope. This stage is performed to detect and remove proper redundant rules, through an iterative call to Algorithm 3 (i.e., testRedundancy), as well as to detect and remove all the further shadowed rules remaining during the latter process. Finally, during a third phase the whole set of non-empty rules is analyzed in order to detect and remove irrelevance, through an iterative call to Algorithm 2 (i.e., testIrrelevance).

4.2  Complexity of the Intra-component Algorithms

In this section, we discuss the degree of computational complexity of our approach's main algorithm, i.e., Algorithm 1, with respect to the increase of the initial number of rules due to the rewriting process. Indeed, in the worst case (cf. Figure 4), Algorithm 1 may generate a huge number of rules. For instance, if we have two rules with p attributes, the second rule can be replaced by p new rules in the worst case, leading to p + 1 rules.

If we now assume that we have n rules (n > 2) with p attributes, then each rule except the first one can be replaced by p new rules in the first rewriting step of the algorithm. In the second step, the p rules that replace the second rule are combined with the p rules that replace rules 3 to n. Thus, each rule from 3 to n can be replaced by p² new rules. In the third step, the p² rules corresponding to rule 3 are combined with the p² rules corresponding to rules 4 to n. We can show that this may lead to p³ new rules. And so on. Hence, in the worst case, if we have n rules (n > 2) with p attributes, then we can obtain 1 + p + p² + . . . + p^n-1 rules when applying Algorithm 1, that is (p^n-1) ⁄(p – rules)

Figure 4: Best, normal, and worst ruleset examples.

Although this complexity seems very high, in all the experimentations we have done (cf. Section 6), we were always very far from this case. First, because only attributes source and destination may significantly overlap and exert a bad influence on the algorithm complexity. Other attributes, protocols and source and destination port numbers, are generally equal or completely different when combining configuration rules. Second, administrators generally use overlapping rules in their configurations to represent rules that may have exceptions. This situation is closer to the normal case presented in Figure 4 than to the worst case. Third, when shadowing or redundancy situations are discovered by the algorithm, some rules are removed \u2013 which significantly reduces the algorithm complexity.

4.3  Default policies

Each component implements a positive (i.e., close) or negative (i.e., open) policy. If it is positive, the default decision is to alert or to deny a packet when any configuration rule applies. By contrast, the negative policy will accepts or pass a packet when no rule applies.

After rewriting the rules with our intra-component-audit algorithms, we can actually remove every rule whose decision is pass or accept if the policy of this component is negative (else this rule is redundant with the default policy); and similarly we can remove every rule whose decision is deny or alert if its policy is positive. Thus, we can consider that our proposed intra-component audit algorithm generates a configuration that only contains positive rules if the component default policy is negative, and negative rules if the default policy is positive.

5.  Inter-component Classification and Algorithms

The objective of the inter-component audit algorithms is the complete detection of policy anomalies that could exist in a multi-component policy, i.e., to discover and warn the security officer about potential anomalies between policies of different components.

The main hypotheses to deploy our algorithms hold the following:

(1) An upstream traffic flows away from the closest component to the origin of this traffic (i.e., the most-upstream component [5]) towards the closest component to the remote destination (i.e., the most-downstream component [5]);

(2) Every component's policy in the network has been rewritten using the intra-component algorithms defined in Section 4, i.e., it does not contain intra-component anomalies and the rules within such a policy are completely independent between them.

5.1  Inter-component Anomalies Classification

In this section, we classify the complete set of anomalies that can occur within a multi-component policy. Our classification is based on the network model presented in Section 3. An example for each anomaly will be illustrated through the distributed multi-component policy setup shown in Figure 5.

Inter-component Shadowing – A shadowing anomaly occurs between two components whether the following conditions hold: (1) The most-upstream component is a firewall; (2) The downstream component, where the anomaly is detected, does not block or report (completely or partially) traffic that is blocked (explicitly, by means of positive rules; or implicitly, by means of its default policy), by the most-upstream component.

The explicit shadowing as result of the union of rules C6{R7} and C6{R8} to the traffic that the component C3 matches by means of rule C3{R1} is a proper example of full shadowing between a firewall and a NIDS. Similarly, the anomaly between C3{R2} and C6{R8} shows an example of an explicit partial shadowing anomaly between a firewall and a NIDS.

On the other hand, the implicit shadowing between the rule C1{R5} and the default policy of component C2 is a proper example of implicit full shadowing between two firewalls. Finally, the anomaly between the rule C1{R6}, C2{R1}, and the default policy of component C2 shows an example of an implicit partial shadowing anomaly between two firewalls.

Figure 5: An example for a distributed network policy setup.

Inter-component Redundancy – A redundancy anomaly occurs between two components whether the following conditions hold: (1) The most-upstream component is a firewall; (2) The downstream component, where the anomaly is detected, blocks or reports (completely or partially) traffic that is blocked by the most-upstream component.

A proper example of full redundancy between two firewalls is shown by rules C5{R3} and C6{R1}; rules C4{R3} and C6{R5}, on the other hand, show an example of full redundancy between a firewall and a NIDS. Similarly, rules C5{R4} and C6{R2} show a proper example of partial redundancy between two firewalls, whereas rules C4{R4} and C6{R6} show an example of partial redundancy between a firewall and a NIDS.

Sometimes, this kind of redundancy is expressly introduced by network administrators (e.g., to guarantee the forbidden traffic will not reach the destination). Nonetheless, it is important to discover it since, if such a rule is applied, we may conclude that at least one of the redundant components is wrongly working.

Inter-component Misconnection – A misconnection anomaly occurs between two components whether the following conditions hold: (1) The most-upstream component is a firewall; (2) the most-upstream firewall permits (explicitly, by means of negative rules; or implicitly, through its default policy) all the traffic – or just a part of it – that is denied or alerted by a downstream component.

An explicit misconnection anomaly between two firewalls is shown through the rules C5{R1} and C2{R2} (full misconnection); and the rules C5{R2} and C2{R2} (partial misconnection).

An implicit misconnection anomaly between two firewalls is also shown by the rule C1{R5} and the default policy of firewall C2 (full misconnection); and the rules C1{R6} and C2{R1}, together with the default policy of C2 (partial misconnection).

Similarly, the pair of rules C4{R1}-C2{R5} and the pair of rules C4{R2}-C2{R5} show, respectively, an explicit example of full and partial misconnection anomaly between a firewall and a NIDS.

Finally, the rule C4{R5} together with the negative policy of the firewall C2 shows an example of implicit misconnection anomaly between a firewall and a NIDS.

5.2  Inter-component Analysis Algorithms

For reasons of clarity, we split the whole analysis process in four different algorithms. The input for the first algorithm (cf. Algorithm 5) is the set of components C, such that for all c ∈ C, we note c[rules] as the set of configuration rules of component c, and c[policy] ∈ {true, false} as the default policy of such a component c. In turn, each rule r ∈ c[rules] consists of a boolean expression over the attributes szone (source zone), dzone (destination zone), sport (source port), dport (destination port), protocol, and decision (true or false).

Let us recall here the functions source(r) = szone and dest(r) = dzone. Thus, we compute for each component c ∈ C and for each rule r ∈ c[rules], each one of the source zones z1 ∈ Zs and destination zones z2 ∈ Zd – whose intersection with respectively szone and dzone is not empty – which become, together with a reference to each component c and each rule r, the input for the second algorithm (i.e., Algorithm 6).

Once in Algorithm 6, we compute the minimal route of components that connects zone z1 to z2, i.e., [C1,C2, . . . ,Cn] ∈ MR(z1, z2). Then, we decompose the set of components inside each path in downstream path (pathd) and upstream path (pathu). To do so, we use functions head and tail. The first component c_d ∈ pathd, and the last component c_u ∈ pathu are passed, respectively, as argument to the last two algorithms (i.e., Algorithm 7 and Algorithm 8) in order to conclude the set of necessary checks that guarantee the audit process. The operator "∼" within algorithms 7 and 8 denotes that two rules ri and rj are correlated if every attribute in Ri has a non empty intersection with the corresponding attribute in Rj .

Let us conclude by giving in Figure 6 an outlook to the set of warnings send to the security officer after the execution of Algorithm 5 over the scenario of Figure 5.

Figure 6: Execution of Algorithm 5 over the scenario of Figure 5.

6.  Implementation and Performance Evaluation

We implemented the intra and inter-component algorithms presented in this document in a software prototype called MIRAGE (which stands for MIsconfiguRAtion manaGEr). MIRAGE has been developed using PHP, a general-purpose scripting language that is especially suited for web services development and can be embedded into HTML for the construction of client-side GUI based applications [7]. MIRAGE can be locally or remotely executed by using a HTTP server (e.g., Apache server over UNIX or Windows setups) and a web browser.

We evaluated our algorithms through a set of experiments over two different IPv4 real networks. The topology for the first network consisted of a single firewall based on netfilter [22], and a single NIDS based on snort [21] – connected to three different zones with more than 50 hosts. The topology for the second network consisted of six different components \u2013 based on netfilter, ipfilter [20], and snort – protecting six different zones with more than 200 hosts. The whole of these experiments were carried out on an Intel-Pentium M 1.4 GHz processor with 512 MB RAM, running Debian GNU/Linux 2.6.8, and using Apache/1.3 with PHP/4.3 configured.

Figure 7: Memory and processing time evaluation for the intra-component algorithms.

Figure 8: Memory and processing time evaluation for the inter-component algorithms.

During a first phase, we measured the memory space and the processing time needed to perform Algorithm 4 over several sets of IPv4 policies for the first IPv4 network, according to the three following security officer profiles: beginner, intermediate, and expert – where the probability to have overlaps between rules increases from 5% to 90%. The results of these measurements are plotted in Figure 7(a) and Figure 7(b). Though those plots reflect strong memory and process time requirements, we consider they are reasonable for off-line analysis, since it is not part of the critical performance of a single component. In a second phase, we conducted similar experiments to measure the performance and scalability of Algorithm 5 through a progressive increment of auto-generated rules, firewalls and zones for the second network. The results of these measurements are plotted in Figure 8(a) and Figure 8(b). Similarly to the intra-component evaluation, we consider these requirements very reasonable for off-line inter-component analysis.

7.  Conclusions

In this document we presented an audit process to set a distributed security scenario composed of both firewalls and network intrusion detection systems (NIDSs) free of anomalies. Our audit process has been presented in two main blocks. We first presented, in Section 4, a set of algorithms for intra-component analysis, according to the discovering and removal of policy anomalies over single-component environments. We then presented, in Section 5, a set of algorithms for inter-component analysis, in order to detect and warn the security officer about the complete existence of anomalies over a multi-component environment.

Some advantages of our approach are the following. First, our intra-firewall transformation process verifies that the resulting rules are completely independent between them. Otherwise, each rule considered as useless during the process is reported to the security officer, in order to verify the correctness of the whole process. Second, we can perform a second rewriting of rules, generating a configuration that only contains positive rules if the component default policy is negative, and negative rules if the default policy is positive. Third, the network model presented in Section 3 allows us to determine which components are crossed by a given packet knowing its source and destination, as well as other network properties. Thanks to this model, our approach better defines all the set of anomalies studied in the related work, and it reports, moreover, two new anomalies (irrelevance and misconnection) not reported, as defined in this document, in none of the other approaches. Furthermore, and as pointed out in Section 2, the lack of this model in [4–6] leads to inappropriate decisions.

The implementation of our approach in a software prototype demonstrates the practicability of our work. We shortly discussed this implementation, based on a scripting language [7], and presented an evaluation of its performance. Although these experimental results show that our algorithms have strong requirements, we believe that these requirements are reasonable for off-line analysis, since it is not part of the critical performance of the audited component.

As future work, we are currently studying the anomaly problems of security rules in the case where the security architecture includes firewalls, IDS/IPS, and IPSec devices. Though there is a real similarity between the parameters of those devices' rules, more investigation has to be done in order to extend our proposal. In parallel to this work, we are also considering to extend our approach to the analysis of stateful policies.

Acknowledgements

This work was supported by funding from the French ministry of research, under the ACI DESIRS project, the Spanish Government project TIC2003-02041, and the Catalan Government grants 2003FI126 and 2005BE77.

References

[1]    Adiseshu, H., Suri, S., and Parulkar, G. (2000). Detecting and Resolving Packet Filter Conflicts. In 19th Annual Joint Conference of the IEEE Computer and Communications Societies, pages 1203–1212.

[2]    Garcia-Alfaro, J., Cuppens, F., and Cuppens-Boulahia, N. (2006). Analysis of policy anomalies on distributed network security setups. In 11th European Symposium On Research In Computer Security (Esorics2006), volume 4189 of Springer LNCS, pages 496–511, Hambburg, Germany.

[3]    Garcia-Alfaro, J., Cuppens, F., and Cuppens-Boulahia, N. (2006). Towards filtering and alerting rule rewriting on single-component policies. In 25th Conference on Computer Safety, Reliability, and Security (Safecomp 2006), volume 4166 of Springer LNCS, pages 182–194, Gdansk, Poland.

[4]    Al-Shaer, E. S., Hamed, H. H. (2004). Discovery of Policy Anomalies in Distributed Firewalls. In IEEE INFOCOM'04, March.

[5]    Al-Shaer, E. S., Hamed, H. H., and Masum, H. (2005). Conflict Classification and Analysis of Distributed Firewall Policies. In IEEE Journal on Selected Areas in Communications, 23(10).

[6]    Al-Shaer, E. S., Hamed, H. H. (2006). Taxonomy of Conflicts in Network Security Policies. In IEEE Communications Magazine, 44(3), March.

[7]    Castagnetto, J. et al. (1999). Professional PHP Programming. Wrox Press Inc., ISBN 1-86100-296-3.

[8]    Chapman, D. and Fox, A. (2001). Cisco Secure PIX Firewalls. Cisco Press.

[9]    Cheswick, W. R., Bellovin, S. M., Rubin A. D. (2003). Firewalls and Internet security: repelling the willy hacker. Addison-Wesley, second edition.

[10]   Cuppens, F., Cuppens-Boulahia, N., and Garcia-Alfaro, J. (2005). Detection and Removal of Firewall Misconfiguration. In Proceedings of the 2005 IASTED International Conference on Communication, Network and Information Security, pages 154–162.

[11]   Cuppens, F., Cuppens-Boulahia, N., and Garcia-Alfaro, J. (2005). Misconfiguration Management of Network Security Components. In Proceedings of the 7th International Symposium on System and Information Security, Sao Paulo, Brazil.

[12]   Cuppens, F., Cuppens-Boulahia, N., and Garcia-Alfaro, J. (2006). Detection of Network Security Component Misconfiguration by Rewriting and Correlation. In 5th Conference on Security and Network Architectures (SAR 2006).

[13]   Cuppens, F., Cuppens-Boulahia, N., Sans, T. and Miege, A. (2004). A formal approach to specify and deploy a network security policy. In Second Workshop on Formal Aspects in Security and Trust, pages 203–218.

[14]   Gupta, P. (2000). Algorithms for Routing Lookups and Packet Classification. PhD Thesis, Department of Computer Science, Stanford University.

[15]   Gouda, M. G. and Liu, A. X. (2004). Firewall Design: Consistency, Completeness and Compactness. In 24th IEEE International Conference on Distributed Computing Systems (ICDCS-04), pages 320–327.

[16]   Kurland, V. (2003). Firewall Builder. White Paper.

[17]   MITRE Corp. Common Vulnerabilities and Exposures. [Online]. Available from: http://cve.mitre.org/

[18]   Northcutt, S. (2002). Network Intrusion Detection: An analyst's Hand Book. New Riders Publishing, third edition.

[19]   Open Security Foundation. Open Source Vulnerability Database. [Online]. Available from: http://osvdb.org/

[20]   Reed, D. IP Filter. [Online]. Available from: http://www.ja.net/CERT/Software/ipfilter/ip-filter.html

[21]   Roesch, M. (1999), Snort: lightweight intrusion detection for networks. In 13th USENIX Systems Administration Conference, Seattle, WA.

[22]   Welte, H., Kadlecsik, J., Josefsson, M., McHardy, P., and et al. The netfilter project: firewalling, nat and packet mangling for linux 2.4x and 2.6.x. [Online]. Available from: http://www.netfilter.org/

[23]   Yuan, L., Mai, J., Su, Z., Chen, H., Chuah, C., and Mohapatra, P. (2006). FIREMAN: a toolkit for FIREwall Modeling and ANalysis. In IEEE Symposium on Security and Privacy.