Reasoning About Firewall Policies Through Refinement and Composition

Abstract

An algebra is proposed for constructing and reasoning about anomaly-free firewall policies. Based on the notion of refinement as safe replacement, the algebra provides operators for sequential composition, union and intersection of policies. The algebra is used to specify and reason about iptables firewall policy configurations. A prototype policy management toolkit has been implemented.

1 Introduction

Firewall configuration management is complex and error-prone, and a misconfigured policy may permit accesses that were intended to be denied or vice-versa. We regard the specification of a firewall policy as a process that evolves. Threats to, and access requirements for, resources behind a firewall do not usually remain static, and over time, a policy or distributed policy configuration may be updated on an ad-hoc basis, possibly by multiple specifiers/administrators. This can be problematic and may introduce anomalies; whereby the intended semantics of the specified access controls become ambiguous.

In this paper, we present a firewall policy algebra $\mathcal{FW}_1$ for constructing and reasoning over anomaly-free policies. The algebra allows policies to be composed in such a way that the result upholds the access requirements of each policy involved; and permits one to reason as to whether some policy is a safe (secure) replacement for another policy in the sense of [11, 14]. The proposed algebra is used to reason about iptables firewall policy configurations. A partial mapping for the iptables filter table is given in the algebra. iptables is a command line utility used to define policies for the Linux kernel firewall Netfilter [1]. We focus on stateful firewall policies that are defined in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes.

The primary contribution of this paper is an algebra $\mathcal{FW}_1$, that can be used to reason about firewall policies using refinement and composition operators. The effectiveness of the algebra is demonstrated by its application to anomaly detection, and standards compliance.

The paper is organised as follows. Section 2 introduces the notion of adjacency, which is at the heart of reasoning about/composing firewall rules that involve IP/port ranges. In Sect. 3 we define datatypes for firewall rule attributes, such as IP/port ranges. Section 4 defines the firewall policy algebra $\mathcal{FW}_1$. In Sect. 5, we use $\mathcal{FW}_1$ to reason about firewall policies in practice. Section 6 describes a prototype policy management toolkit for iptables and presents some preliminary results. Related work is outlined in Sects. 7 and 8 concludes the paper. The Z notation [19] is used to present the algebra and has been syntax- and type-checked using the uzz tool.

2 A Theory of Adjacency

A firewall policy is conventionally defined as a sequence of order-dependent rules. A rule is composed of filter conditions and a target action. Filter conditions usually consist of fields/attributes from IP, TCP/UDP headers; with the most commonly used attributes being source/destination IP/port, and network protocol. Target actions are usually allow or deny [3, 8].

Range-based filter condition attributes (IPs/ports) have logical mappings to intervals of ${\mathbb {N}}$. For example, the port range that includes all ports from SSH up and including HTTP can be written as the interval $[22 {..}80]$. Consider as part of a running example, a system that is capable of enforcing firewall rules where the filter condition attribute for the rules is destination port range. Then if we had a rule that allowed all ports from SSH to HTTP, it may look like: (i, $[22 {..}80]$, allow), where i is the index of the rule in the policy, $[22 {..}80]$ is the required port range, and allow means that network traffic matching this pattern be permitted traversal of the firewall. Suppose we had a second rule, that specifies allow everything from Quote Of The Day (QOTD) up to and including FTP Control. Then (j, $[17 {..}21]$, allow), specifies that for the rule at index j; the required port range $[17 {..}21]$ is allowed. Intuitively, we can see that the port ranges for the rules at index i and index j are adjacent, and we may want to join rules i and j into a single rule that looks like (k, $[17 {..}80]$, allow). This notion of adjacency becomes more complex when we consider comparing/composing firewall rules comprising $2 {..}n$ filter condition attributes.

2.1 The Adjacency Specification

In this section we define the filter condition attribute relationships of adjacency, disjointness and subsumption. These relationships are at the heart of adjacency, and ultimately the $\mathcal{FW}_1$ algebra.

Let $\mathcal {IV}[min, max]$ be the set of all intervals on the natural numbers, from min up to and including max. Intervals are defined by their corresponding sets.

For example, $\mathcal {IV}[1,3]$ gives $\{[1 {..}1],[1 {..}2],[1 {..}3],[2 {..}2],[2 {..}3],[3 {..}3]\}$. For ease of exposition and when no ambiguity arises, we may write an interval as a pair [$\bot {..}\top$], rather than by the set it defines. Let $IPv4$ define the set of all possible IPv4 address ranges, and similarly, let $Port$ define the set of all possible network port ranges, where $IPv4== \mathcal {IV}[0, 2^{32}-1] \wedge Port== \mathcal {IV}[0, 2^{16}-1]$.

Adjacency. Two intervals are adjacent if their union defines a single interval. We generalize this to any attribute of type X, whereby for $a, b \in X$, if $a \wr _{\tiny X} b$, then a and b are adjacent in the set X.

For example, interval $[1 {..}2]$ is adjacent to interval $[3 {..}3]$, thus $[1 {..}2]$ $\wr _{\tiny \mathcal {IV}[1,3]}$ $[3 {..}3]$. It follows for $a, b \in {\mathbb {N}}$ that $a\wr _{\tiny {\mathbb {N}}} b \iff (a=b \vee a+1=b\vee b+1=a)$, and given $S, T \in {\mathbb {P}}X$ then $S \wr _{\tiny {\mathbb {P}}X} T \iff true$.

Disjointness. Two intervals are disjoint if they don’t intersect. Given $a, b \in X$, $a \mid _{\tiny X} b$ denotes a and b are disjoint in X.

For example, $[1 {..}2]$ and $[3 {..}3]$ are disjoint, thus $[1 {..}2] \mid _{\tiny \mathcal {IV}[1,3]} [3 {..}3]$. It follows for $a,b \in {\mathbb {N}}$ that $a \mid _{\tiny {\mathbb {N}}} b \iff a \ne b$, and given $S, T \in {\mathbb {P}}X$ then $S \mid _{\tiny {\mathbb {P}}~X} T \iff S \cap T = \emptyset$.

Subsumption. An interval I subsumes (covers) an interval J, if $J \subseteq I$. For $a, b \in X$, if $a \mathop {\leftarrow }\limits ^{\tiny X} b$ then b covers a in X. The properties of reflexivity, transitivity and antisymmetry define $\mathop {\leftarrow }\limits ^{\tiny X}$ as a non-strict partial order over X [5].

For example, $[1 {..}3]$ covers $[3 {..}3]$, thus $[3 {..}3] \mathop {\leftarrow }\limits ^{\tiny \mathcal {IV}[1,3]} [1 {..}3]$. It follows for $a,b \in {\mathbb {N}}$ that $a\mathop {\leftarrow }\limits ^{\tiny {\mathbb {N}}} b \iff a=b$, and given $S, T \in {\mathbb {P}}X$, then $S\mathop {\leftarrow }\limits ^{\tiny {\mathbb {P}}X} T \iff S\subseteq T$.

For a set X and $S\in {\mathbb {P}}X$, the flattening function $\lceil S \rceil$ gives the cover-set for the elements of $S$.

For example, $\lceil \mathcal {IV}[1,3] \rceil = \{[1 {..}3]\}$. We define a difference operator for $S, T\in {\mathbb {P}}X$, where $S\setminus _{\tiny {\mathbb {P}}X} T$ gives the relative compliment of $T$ in $S$.

For example, $\lceil \mathcal {IV}[1,3] \rceil \setminus _{\tiny \mathcal {IV}[1,3]} \{[1 {..}1],[3 {..}3]\} = \{[2 {..}2]\}$.

3 Filter Condition Attribute Datatypes

In this section we define the datatypes used to construct the filter condition attributes for the $\mathcal{FW}_1$ policy model.

3.1 The Adjacency Datatype

For a set X, the Adjacency datatype $\alpha [X]$, is the set of all closed subsets of X partitioned by adjacency.

For example $\alpha [\mathcal {IV}[1,3]]$ gives {{$[1 {..}1]$}, {$[1 {..}2]$}, {$[1 {..}3]$}, {$[2 {..}2]$}, {$[2 {..}3]$}, {$[3 {..}3]$}, {$[1 {..}1]$,$[3 {..}3]$}}, and $\alpha [IPv4]$ defines the set of all closed subsets for the intervals of the IPv4 address range partitioned by adjacency.

Adjacency Ordering. An ordering can be placed over Adjacency-sets, and is defined as follows.

The elements $\bot , \top \in \alpha [X]$ define the least and greatest bounds, respectively, on $\alpha [X]$, where for any $S\in \alpha [X]$, then $\bot \le S\le \top$. Adjacency negation defines a valid complement operator in $\alpha [X]$, where $(S\oplus {\mathbf{not}~S}) = \top$ and $(S\otimes {\mathbf{not}~S}) = \bot$.

Adjacency Intersection. Under this ordering, the meet, or intersection $S\otimes T$ of $S, T\in \alpha [X]$ is defined using subsumption, as the cover-set for the generalized union of all Adjacency-sets, where each element of ($S\otimes T$) is covered by an element in both $S$ and $T$. Intuitively, this means that the values of the meet are all non-empty intersections of each value in $S$ with each value in $T$. Under the ordering relation $\le$, $\otimes$ provides a greatest lower bound (glb) operator, and $S\otimes T$ is covered by both $S$ and $T$, that is $(S\otimes T) \le S$ and $(S\otimes T) \le T$.

Adjacency Union. The join of $S, T\in \alpha [X]$ is defined using subsumption, as the generalized intersection of all Adjacency-sets, where each element of ($S\oplus T$) covers an element in either $S$ or $T$. Intuitively, this means that the values of the join are exactly a union of the elements from both $S$ and $T$. Given the definition of ordering using subsumption, it follows that the Adjacency join provides a lowest upper bound (lub) operator. Since $\oplus$ provides a lub operator we have $S\le (S\oplus T)$ and $T\le (S\oplus T)$.

Proposition. The poset $(\alpha [X], \le )$ forms a distributive lattice with compliment operator $\mathbf{not}$. This follows from the definition of $\le$ as a subsumption ordering/an antisymmetric preorder, the properties of $\mathbf{not}$, the intuitive definition of the meet of $S, T\in \alpha [X]$ as all non-empty intersections of each value in $S$ with each value in $T$, and the intuitive definition of the join operation as an exact union of the elements from both $S$ and $T$ [18].

Given the adjacency, disjointness and subsumption relations; then for $S, T\in \alpha [X]$, we define $S\wr _{\tiny \alpha [X]} T\iff true$ $\wedge$ $S\mid _{\tiny \alpha [X]} T\iff S\otimes T= \bot$ $\wedge$ $S\mathop {\leftarrow }\limits ^{\tiny \alpha [X]} T\iff S\le T$.

3.2 The Duplet Datatype

A duplet is an ordered pair, where the set of all duplets for types X, Y, is defined as $\delta [X,Y]$, where $\delta [X, Y] == X {\times }Y$. For example, $\delta [\mathcal {IV}[1,1], \mathcal {IV}[1,2]]$ gives {($[1 {..}1]$,$[1 {..}1]$), ($[1 {..}1]$,$[1 {..}2]$), ($[1 {..}1]$, $[2 {..}2]$)}, and $\delta [\alpha [IPv4], \alpha [Port]]$ gives the set of all duplets for adjacency-free IP/port-ranges.

Recall the earlier example of the firewall system that supports only destination port range filter conditions. Suppose we want to extend the expressiveness of the policy rules for this system to include a definition for destination IP range. Then $\alpha [\delta [\alpha [IPv4], \alpha [Port]]]$, is the set of all closed subsets of adjacency-free IP/port-range duplets, partitioned by adjacency. Consider two policy requirements, where network traffic is to be allowed to the IP range $[1 {..}3]$ on ports $[1 {..}3]$, and to the IP range $[2 {..}4]$ on ports $[2 {..}4]$. Then modelling this using sets of adjacency-free duplets, we have $S, T \in \alpha [\delta [\alpha [IPv4], \alpha [Port]]]$, where $S ==$ {({$[1 {..}3]$}, {$[1 {..}3]$})} and $T ==$ {({$[2 {..}4]$}, {$[2 {..}4]$})}.

Duplet Disjointness. A pair of duplets are disjoint if the attributes in the first coordinate are disjoint, or the attributes in the second coordinate are disjoint. For $(a_{1}, b_{1}), (a_{2}, b_{2}) \in \delta [X, Y]$, then:

$$\begin{aligned} (a_{1}, b_{1})\mid _{\tiny \delta [X, Y]}(a_{2}, b_{2}) \iff (a_{1}\mid _{\tiny X} a_{2}\vee b_{1}\mid _{\tiny Y} b_{2}) \end{aligned}$$

For example, $\lnot (S \mid _{\tiny \alpha [\delta [\alpha [IPv4], \alpha [Port]]]} T)$.

Duplet Adjacency. A pair of duplets are adjacent if the attributes in the first coordinate are adjacent, and the attributes in the second coordinate are not disjoint. Thus, we have:

$$\begin{aligned} (a_{1}, b_{1})\wr _{\tiny \delta [X, Y]}(a_{2}, b_{2}) \iff (a_{1}\wr _{\tiny X} a_{2}\wedge \lnot ~(b_{1}\mid _{\tiny Y} b_{2}) ) \end{aligned}$$

For example, $S \wr _{\tiny \alpha [\delta [\alpha [IPv4], \alpha [Port]]]} T$.

Duplet Subsumption. A duplet is distinguished from a standard ordered pair, whereby we explicitly define orderings separately in each coordinate. For example, suppose we wanted to join adjacent policies S and T, then under a ‘standard’ Cartesian product ordering we have $S \oplus T =$ {({$[1 {..}4]$}, {$[1 {..}4]$})}. This obviously results in an overly permissive policy, conversely; an overly restrictive policy if we were composing deny rules. A duplet $(a_{1}, b_{1})$ covers a duplet $(a_{2}, b_{2})$ in $\delta [X,Y]$, if $a_{1}$ covers $a_{2}$ in X, and $b_{2}$ covers $b_{1}$ in Y. Thus:

$$\begin{aligned} (a_{2}, b_{2})\mathop {\leftarrow }\limits ^{\tiny \delta [X, Y]}(a_{1}, b_{1}) \iff (a_{2}\mathop {\leftarrow }\limits ^{\tiny X} a_{1}\wedge b_{1}\mathop {\leftarrow }\limits ^{\tiny Y} b_{2}) \end{aligned}$$

Then we have $S \oplus T =$ {({$[1 {..}4]$}, {$[2 {..}3]$}), ({$[1 {..}3]$}, {$[1 {..}1]$}), ({$[2 {..}4]$}, {$[4 {..}4]$})}. Thus, the join, or union $(S \oplus T)$ of S and T, defines the adjacency-free coalescence of all duplets from S and T. For reasons of space, we do not give the implementation definition for this operation.

3.3 The Stateful/Protocol Datatype

In this section, we define the network protocols of interest for the model and encode a notion of state. The iptables command line utility allows the end-user to specify one (or all) of seven different protocols in a rule [1]. For reasons of space, we focus only on the TCP, UDP and ICMP protocols.

Let $Flags$ be the set of TCP flags, where $Flags~{:}{:=} \, \mathsf{syn} \, | \, \mathsf{ack} \, | \, \mathsf{fin} \, | \, \mathsf{psh} \, | \, \mathsf{rst} \, | \, \mathsf{urg}$. The TCP protocol is defined as the set of all sets of pairs of sets of $Flags$, whereby for each pair; the first set contains the flags that are to be examined in a packet-header, and the second set contains the flags that must be set (in a packet-header). In [1], these are referred to as the comp and mask values for a packet, respectively. Let $TCP$ be the set of all sets of comp/mask pairs, where $TCP== {\mathbb {P}}({\mathbb {P}}\, Flags{\times }{\mathbb {P}}\, Flags)$. Let $[TypesCodes]$ be the set of all valid ICMP Type/Code pairs. For simplicity and reasons of space, we do not consider how the values of $TypesCodes$ may be constructed, other than to assume that the usual human-readable notation can be used, such as (8,0) and (17,0) $\in TypesCodes$. The iptables conntrack modules’ statelist [1] may be defined as follows. Let $State$ be the set of connection tracking states for a packet/connection, where $State~{:}{:=} \, \mathsf{new}\, | \, \mathsf{established}\, | \, \mathsf{related}\, | \, \mathsf{invalid}\, | \, \mathsf{untracked}$.

Let $Protocol$ define the set of all protocols, given as the set of all duplets over $TCP,$ UDP ($[0 {..}1]$), ICMP (${\mathbb {P}}\, TypesCodes$) and the set of all sets of connection tracking states (${\mathbb {P}}\, State$).

$$\begin{aligned} Protocol== \delta [TCP, \delta [\{0,1\}, \delta [{\mathbb {P}}\, TypesCodes, {\mathbb {P}}\, State]]] \end{aligned}$$

Proposition. The $Protocol$ datatype forms a product-lattice structure. This follows from the definition of $Protocol$ as the product of powerset/binary lattices [5].

4 The $\mathcal{FW}_1$ Policy Algebra

In this section we define an algebra $\mathcal{FW}_1$, for constructing and reasoning about anomaly-free firewall policies. We focus on stateful firewall policies that are defined in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols.

A filter condition is a five-tuple (s, sprt, d, dprt, p), representing network traffic originating from source IP range s, with source port range sprt, destined for destination IP range d, with destination port range dprt, using stateful-protocols p. Let $FC$ define the set of all filter conditions, where:

$$\begin{aligned} FC== \delta [\alpha [IPv4], \delta [\alpha [Port], \delta [\alpha [IPv4], \delta [\alpha [Port], Protocol]]]] \end{aligned}$$

A firewall policy defines the filter conditions that may be allowed or denied by a firewall. Let $Policy$ define the set of all firewall policies, whereby:

A firewall policy $(A,D)\in Policy$ defines that a filter condition $f \in A$ should be allowed by the firewall, while a filter condition $f \in D$ should be denied. Given $(A,D)\in Policy$ then A and D are disjoint: this avoids any contradiction in deciding whether a filter condition should be allowed or denied. Given that A and D are also both adjacency-free; then $Policy$ defines the set of anomaly-free firewall policies in the sense that they contain no redundancy, shadowing, or other anomalies [4].

Note that $(A,D)\in Policy$ need not partition $\lceil FC \rceil$: the allow and deny sets define the filter conditions to which the policy explicitly applies, and an implicit default decision is applied for those filter conditions in $\lceil FC \rceil \setminus _{\tiny \alpha [FC]}(A \oplus D)$. For the purposes of modelling iptables firewalls it is sufficient to assume default deny, though we observe that $\mathcal{FW}_1$ can also be used to reason about default allow firewall policies. The policy destructor functions $allow$ and $deny$ are analogous to functions first and second for ordered pairs:

Policy Refinement. An ordering can be defined over firewall policies, whereby given $P,Q\in Policy$ then $P \sqsubseteq Q$ means that P is no less restrictive than Q, that is, any filter condition that is denied by Q is denied by P. Intuitively, policy P is considered to be a safe replacement for policy Q, in the sense of [11, 14] and any firewall that enforces policy Q can be reconfigured to enforce policy P without any loss of security. The set $Policy$ forms a lattice under the safe replacement ordering and is defined as follows.

Formally, $P \sqsubseteq Q$ iff every filter condition allowed by P is allowed by Q and that any filter conditions explicitly denied by Q are also explicitly denied by P. Note that in this definition we distinguish between filter conditions explicitly denied in the policy versus those implicitly denied by default. This means that, everything else being equal, a policy that explicitly denies a filter condition is considered more restrictive than a policy that relies on the implicit default-deny for the same network traffic pattern. Safe replacement is defined as the Cartesian product of Adjacency orderings over allow and deny sets and it therefore follows that $(Policy, \sqsubseteq )$ is a poset.

$\bot$ and $\top$ define the most restrictive and least restrictive policies, that is, for any $P\in Policy$ we have $\bot \sqsubseteq P \sqsubseteq \top$. Thus, for example, any firewall enforcing a policy P can be safely reconfigured to enforce the (not very useful) firewall policy $\bot$.

Policy Intersection. Under this ordering, the meet $P \sqcap Q$, of two firewall policies P and Q is defined as the policy that denies any filter condition that is explicitly denied by either P or Q, but allows filter conditions that are allowed by both P and Q. Intuitively, this means that if a firewall is required to enforce both policies P and Q, it can be configured to enforce the policy $(P \sqcap Q)$ since $P \sqcap Q$ is a safe replacement for both P and Q, that is; $(P \sqcap Q) \sqsubseteq P$ and $(P \sqcap Q) \sqsubseteq Q$. Given the definition of safe replacement as a product of two Adjacency lattices, it follows that the policy meet provides the glb operator. Thus, $P \sqcap Q$ provides the ‘best’/least restrictive safe replacement (under $\sqsubseteq$) for both P and Q.

Policy Union. The join of two firewall policies P and Q is defined as the policy that allows any filter condition allowed by either P or Q, but denies filter conditions that are explicitly denied by both P and Q. Intuitively, this means that a firewall that is required to enforce either policy P or Q can be safely configured to enforce the policy $(P \sqcup Q)$. Since $\sqcup$ provides a lub operator we have $P \sqsubseteq (P \sqcup Q)$ and $Q \sqsubseteq (P \sqcup Q)$.

Proposition. The set of all policies $Policy$ forms a lattice under safe replacement. This follows from the definition of $\sqsubseteq$ as a Cartesian product of two Adjacency lattice orderings.

4.1 Constructing Firewall Policies

The lattice of policies $\mathcal{FW}_1$ provides us with an algebra for constructing and interpreting firewall polices. The following constructor functions are used to build primitive policies. Given a set of adjacency-free filter conditions A, then $(\mathsf{Allow}~A)$ is a policy that allows filter conditions in A, and $(\mathsf{Deny}~D)$ is a policy that explicitly denies filter conditions in D.

This provides what we refer to as a weak interpretation of allow and deny. Network traffic patterns that are not explicitly mentioned in parameter S are default-deny and therefore are not specified in the deny set of the policy. The following provides us with a strong interpretation for these constructors:

In this case $(\mathsf{Allow^{+}}~A)$ allows filter conditions specified in A, while explicitly denying all other filter conditions, and $(\mathsf{Deny^{+}}~D)$ denies filter conditions specified in D while allowing all other filter conditions.

Proposition. A firewall policy $P \in Policy$ can be decomposed into it’s corresponding allow and deny sets, and re-constructed using the algebra; for any $(A,D)\in Policy$, since A and D are disjoint then:

$$\begin{aligned} (\mathsf{Allow^{+}}~A) \sqcup (\mathsf{Deny}~D)= & {} (A, \lceil FC \rceil \setminus _{\tiny \alpha [FC]} A) \sqcup (\emptyset , D)\\= & {} (A,D) \\= & {} (\mathsf{Allow}~A) \sqcap ( \mathsf{Deny^{+}}~D) \end{aligned}$$

5 Reasoning About Policies in Practice

Sequential Composition. A firewall policy is conventionally constructed as a sequence of rules, whereby for a given network packet, the decision to allow or deny that packet is checked against each policy rule, starting from the first, in sequence, and the first rule that matches gives the result that is returned. The algebra $\mathcal{FW}_1$ can be extended to include a similar form of sequential composition of policies. The policy constructions above can be regarded as representing the individual rules of a conventional firewall policy.

Let denote a sequential composition of an allow rule $(\mathsf{Allow}~A)$ with policy Q with the interpretation that a given network packet matched in A is allowed; if it does not match in A then policy Q is enforced. The resulting policy either: allows filter conditions in A (and denies all other filter conditions), or allows/denies filter conditions in accordance with policy Q. We define:

which is as expected. A similar definition can be provided for the sequential composition , whereby a given network packet that is matched in D is denied; if it does not match in D then policy Q is enforced. We define:

While in practice its usual to write a firewall policy in terms of many constructions of allow and deny rules, in principle, any firewall policy $P \in Policy$ can be defined in terms of one allow policy $(\mathsf{Allow}~allow(P))$ and one deny policy $(\mathsf{Deny}~deny(P))$ and since the allow and deny sets of P are disjoint we have . We define this as:

Let $Rule$ define the set of all firewall rules, where . We define a rule interpretation function as:

A firewall policy is defined as a sequence of rules $\langle r_{1}, r_{2}, {..},r_{n}\rangle$, for $r_{i}\in Rule$, and is encoded in the policy algebra as .

Policy Negation. The policy negation of $P \in Policy$ allows filter conditions explicitly denied by P and explicitly denies filter conditions allowed by P. We define:

From this definition it follows that $(\mathbf{not}~P)$ is simply $(deny~(P),allow~(P))$ and thus $\mathbf{not}~(\mathsf{Deny}~D) = (\mathsf{Allow}~D)$ and $\mathbf{not}~(\mathsf{Allow}~A)=(\mathsf{Deny}~A)$. Note however, that in general policy negation does not define a complement operator in the algebra $\mathcal{FW}_1$, that is, it not necessarily the case that $(P \sqcup {\mathbf{not}~P}) = \top$ and $(P \sqcap {\mathbf{not}~P}) = \bot$.

5.1 Anomaly Analysis

A firewall policy is conventionally constructed as a sequence of order-dependent rules, and when a network packet matches with two or more policy rules, the policy is anomalous [3, 4, 8]. By definition, the adjacency-free allow and deny sets of some $P \in Policy$ are disjoint, therefore P is anomaly-free by construction. We can however define anomalies using the algebra; by considering how a policy changes when composed with other policies.

Redundancy. A policy P is redundant given policy Q if their composition results in no difference between the resulting policy and Q, in particular, if .

Shadowing. Some part of policy Q is shadowed by the entire policy P in the composition if the filter condition constraints that are specified by P contradict the constraints that are specified by Q, in particular, if . This is a very general definition for shadowing. Perhaps a more familiar interpretation of this definition is one where the policy P is a specific allow/deny rule that shadows a part or all of the policy with which it is composed. Recall that $(\mathbf{not}(\mathsf{Allow}~A)) = (\mathsf{Deny}~A)$ and, for example, in all or part of policy Q is shadowed by the rule/primitive policy $(\mathsf{Allow}~A)$ if Q denies the filter conditions specified in A, that is, . Similarly, in part or all of policy Q is shadowed by the rule/primitive policy $(\mathsf{Deny}~D)$ if . Further definitions for shadowing may be constructed using the algebra. For example, an initial interpretation of the generalisation anomaly [3] in the composition ; is where Q is generalised by P if all of P shadows (specifically) part of Q. We are currently investigating how this and other anomalies can be reasoned about within the algebra.

Inter-policy Anomalies. Anomalies can also occur between the different policies of distributed firewall configurations [4]. In the following, assume that P is a policy on an upstream firewall and Q is a policy on a downstream firewall.

An inter-redundancy anomaly exists between policies P and Q if some part of Q is redundant to some part of P, whereby the target action of the redundant filter conditions is deny. Given some set of filter conditions A denied by P, and some set of filter conditions B denied by Q, if then there exists an inter-redundancy between P and Q.

An inter-shadowing anomaly exists between policies P and Q if some part of Q’s allows are shadowed by some part of P’s denies. Given some set of filter conditions A denied by P, and some set of filter conditions B allowed by Q, if , then there is an inter-shadowing anomaly between P and Q.

An inter-spuriousness anomaly exists between policies P and Q if some part of Q’s denies are shadowed by some part of P’s allows. Again, given some set of filter conditions A allowed by P, and some set of filter conditions B denied by Q, if , then there exists an inter-spuriousness anomaly between P and Q.

5.2 Standards Compliance

RFC 5735 [7], details fifteen IPv4 address blocks/ranges that have been assigned by the Internet Assigned Numbers Authority (IANA) for specialized/global purposes. Some of these address spaces may appear on the Internet, and may be used legitimately outside a single administrative domain, however, while the assigned values of the ranges do not directly raise security issues; unexpected use may indicate an attack [7]. For example, packets with a source IP address from the private address space 172.16.0.0/12, arriving on the Wide Area Network interface of a network router, may be considered spoofed, and may be part of a Denial of Service (DoS), or Distributed DoS attack.

RFC 5735 Compliance. An IP spoof-mitigation compliance policy $\textsf {RFC5735}$ is defined. Best practice recommendations are implemented for each of the fifteen specialized IP ranges in [7], resulting in one hundred and twenty iptables deny rules. In [10], we defined this deny ruleset for a firewall management tool, we do not give the definition here for reasons of space. The compliance policy terminates with a final iptables rule that specifies all other traffic be permitted. To model these iptables rules in the algebra, we define some additional filter condition attributes and provide a more formal definition of $\textsf {RFC5735}$.

An Extended Firewall Policy. An attribute for the iptables filter table chains may be defined as $Chain~{:}{:=} \,\mathsf{input}\, | \, \mathsf{output}\, | \, \mathsf{forward}$. Direction-based filtering may be given as $Dir~{:}{:=} \,\mathsf{ingress}\, | \, \mathsf{egress}$, and the set of all sets of interfaces on a machine may be given as ${\mathbb {P}}\, Iface$, where for simplicity, we assume elements of $Iface$ resemble eth0, wlan0, tun0, etc. Let $AdditionalFC$ be the set of all duplets for additional filter condition attributes of interest for this paper, whereby:

$$\begin{aligned} AdditionalFC== \delta [{\mathbb {P}}\, Chain, \delta [{\mathbb {P}}\, Dir, {\mathbb {P}}\, Iface]] \end{aligned}$$

A revised definition for the set of all filter conditions $FC_{\mathcal {I}}$ is given as:

$$\begin{aligned} FC_{\mathcal {I}}== \delta [\alpha [IPv4], \delta [\alpha [Port], \delta [\alpha [IPv4], \delta [\alpha [Port], \delta [Protocol, AdditionalFC]]]]] \end{aligned}$$

A revised definition for the set of all policies $Policy_{\mathcal {I}}$ is given as:

The compliance policy $\textsf {RFC5735}\in Policy_{\mathcal {I}}$, defines the minimum requirement for what it means for some perimeter network firewall policy to mitigate the threat of IP spoofing for all traffic, in accordance with RFC 5735. Thus, we have for all $P \in Policy_{\mathcal {I}}$, if $P \sqsubseteq \textsf {RFC5735}$, then P complies with the best practice recommendations outlined in [7] for IP spoof-mitigation.

6 Encoding and Evaluating Iptables Policies

A prototype policy management toolkit has been implemented in Python for iptables. We reason over $Policy_{\mathcal {I}}$ policies using (); time-based performance-analysis tests were conducted. The test-bed for the experiments was a 64-Bit Ubuntu 14.04 LTS OS, running on a Dell Latitude E6430, with a quad-core Intel i5-3320M processor and 4 GB of RAM. Every experiment was conducted three times; the median result chosen for inclusion in this paper. Overall, the results are promising.

Evaluating Sequential Policy Composition. Two datasets were generated for experimentation. Each dataset consists of iptables policies of size $2^{4}{..}2^{11}$. One dataset contains policies where no rule is adjacent to any other rule (other than itself), and the other dataset consists of policies where every new rule is adjacent to the previous rule; to ensure the maximum number of possible rules are generated as a result of composition. The rules all have a target action of allow. The implementation parses the system’s currently enforced iptables ruleset $\langle r_{1}, r_{2}{..}r_{n}\rangle$ by chain, and then normalizes each rule to a primitive/singleton policy $\langle \mathcal {I}(r_{1}), \mathcal {I}(r_{2}) {..}\mathcal {I}(r_{n}) \rangle$. The overall policy for the chain is evaluated as . For reasons of space, we give the results for the sequential composition experiments as lists of tuples ($\mathcal {P}$,$\mathcal {T}(\mathcal {P})$), where $\mathcal {P}$ is the policy named by the number of iptables rules it was constructed from for the experiment, and $\mathcal {T}(\mathcal {P})$ is the time taken in seconds for the evaluation of the sequential composition of the rules in $\mathcal {P}$. For the adjacent dataset we have [($2^{4}$, 0.80), ($2^{5}$, 2.02), ($2^{6}$, 5.13), ($2^{7}$, 15.32), ($2^{8}$, 51.18), ($2^{9}$, 183.42), ($2^{10}$, 707.15), ($2^{11}$, 2792.81)]. We observe that the evaluation time for the sequential composition of $2^{9}$ rules is around three minutes, and $\mathcal {T}(2^{11})$ is approximately forty six minutes. For the non-adjacent dataset, we have [($2^{4}$, 0.07), ($2^{5}$, 0.13), ($2^{6}$, 0.29), ($2^{7}$, 0.67), ($2^{8}$, 1.73), ($2^{9}$, 4.98), ($2^{10}$, 16.09), ($2^{11}$, 57.81)], and we see that for the largest ruleset, $2^{11}$, $\mathcal {T}(2^{11})$ is approximately one minute.

Evaluating Policy Union. Experiments were conducted to test policy lub, whereby each policy in the adjacent dataset was split into two policies, where the first policy contains the odd (index) rules from the original policy, and the second policy contains the even (index) rules from the original policy. Then for each $P, Q \in Policy_{\mathcal {I}}$ in this split dataset, the time taken for the operation $P \sqcup Q$ is encoded in the matrix in Table 1. The times taken for composition of policies of equal size are approximately the same as (slightly less than) those for the results given in the adjacent sequential composition dataset. This is highlighted through the diagonal in the matrix, and is as expected; given that we used all allow rules.

Table 1. Time taken to compute $P \sqcup Q$ (in seconds)

Evaluating Policy Compliance. A further dataset consisting of iptables policies of size $2^{4}{..}2^{11}$ was generated to test policy compliance. Each policy in this dataset was RFC 5735 compliant by construction. Results are again given as a list of tuples ($\mathcal {P}$,$\mathcal {T}(\mathcal {P})$), where $\mathcal {P}$ is the policy named by the number of iptables rules it was constructed from for the experiment, and $\mathcal {T}(\mathcal {P})$ is the time taken in seconds for the evaluation of $\mathcal {P}\sqsubseteq \textsf {RFC5735}$. We have [($2^{4}$, 1.07 $\times 10^{-3}$), ($2^{5}$, 1.62 $\times 10^{-3}$), ($2^{6}$, 2.23 $\times 10^{-3}$), ($2^{7}$, 3.50 $\times 10^{-3}$), ($2^{8}$, 5.24 $\times 10^{-3}$), ($2^{9}$, 1.03 $\times 10^{-2}$), ($2^{10}$, 2.76 $\times 10^{-2}$), ($2^{11}$, 4.95 $\times 10^{-2}$)], and we see that for each $\mathcal {P}\in Policy_{\mathcal {I}}$ in this compliance-dataset $\mathcal {T}(\mathcal {P})$ is negligible.

7 Related Work

In [3], a firewall policy is modelled as a single rooted tree, relations between rules are defined on a pairwise basis, and definitions for firewall configuration anomalies are provided. In [4], the work is extended to distributed firewall policies. In [8], a firewall policy is modelled as a linked-list, and in [13] rule relations within a policy are modelled in a directed graph. In [20] Binary Decision Diagrams are used to model firewall rulesets. We model a firewall policy as an ordered pair of disjoint adjacency-free sets, where the set of policies $Policy$ forms a lattice under $\sqsubseteq$, and each $P \in Policy$ is anomaly-free by construction. In [3, 4, 8, 13, 20] an algorithmic approach is taken to detect/resolve anomalies. We follow an algebraic (as opposed to algorithmic) approach towards modelling anomalies in a single policy, and across a distributed policy configuration through policy composition. In earlier work [12], we developed the algebra $\mathcal{FW}_0$, and used it to reason over host-based and network access controls in OpenStack. In the $\mathcal{FW}_0$ algebra, we focused on stateless firewall policies that are defined in terms of constraints on individual IPs, ports and protocols. In this paper, the algebra $\mathcal{FW}_1$ is defined over stateful firewall policies constructed in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes. We argue that $\mathcal{FW}_1$ gives a more expressive means for reasoning over OpenStack security group and perimeter firewall configurations. In [16], cloud calculus is used to capture the topology of cloud computing systems and the global firewall policy for a given configuration. This paper could extend the work in [16], given that $\mathcal{FW}_1$ may be used in conjunction with cloud calculus to guarantee anomaly-free dynamic firewall policy reconfiguration, where the ordering relation $\sqsubseteq$ may give a viable alternative for the given equivalence relation defined over ‘cloud’ terms for the formal verification of firewall policy preservation after a live migration. In [21], a firewall policy algebra is proposed. However, the authors note that an anomaly-free composition is not guaranteed as a result of using their algebraic operators. Our work differs, in that policy composition under the $\sqcap , \sqcup$ and operators defined in this paper all result in anomaly-free policies. In [2], an abstract model for Netfilter is proposed, and a language to specify firewall configurations is introduced that is similar to the XML-based access control language supported by Or-BAC presented in [9]. In [17], a formal model of Netfilter is defined, and the properties of reachability and cyclicity within firewall policy configurations are investigated. In [6], a theorem-proving approach is used to reason about firewall policies. The proposed algebra $\mathcal{FW}_1$ is used to reason about and compose anomaly-free policies and therefore we do not have to worry about dealing with conflicts that may arise. Anomaly conflicts are dealt with in composition by computing anomaly-free policies, rather than using techniques such as [15] to resolve conflicts in policy decisions. Encoding a definition for Network Address Translation in $\mathcal{FW}_1$ is a topic for future research.

8 Conclusion

A policy algebra $\mathcal{FW}_1$ is defined in which firewall policies can be specified and reasoned about. At the heart of this algebra is the notion of safe replacement, that is, whether it is secure to replace one firewall policy by another. The set of policies form a lattice under safe replacement and this enables consistent operators for safe composition to be defined. Policies in this lattice are anomaly-free by construction, and thus, composition under glb and lub operators preserves anomaly-freedom. A policy sequential composition operator is also proposed that can be used to interpret firewall policies defined more conventionally as sequences of rules. The algebra can be used to characterize anomalies, such as shadowing and redundancy, that arise from sequential composition. Best practice policy compliance may be defined using $\sqsubseteq$. The algebra $\mathcal{FW}_1$ provides a formal interpretation of the network access controls for a partial mapping to the iptables filter table. $\mathcal{FW}_1$ is a generic algebra and can also be used to model other firewall systems. The results in this paper are described in terms of the algebra $\mathcal{FW}_1$, for stateful firewall policies that are defined in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes.