Mignis: A semantic based tool for firewall configuration

P. Adao˜ C. Bozzato, G. Dei Rossi, R. Focardi and F.L. Luccio SQIG–IT, IST, ULisboa, Portugal DAIS, Universita` Ca’ Foscari Venezia, Italy Email: [email protected] Email: {cbozzato,deirossi,focardi,luccio}@dsi.unive.it

Abstract—The management and specification of access control implemented as a series of chains, tables and rules that are rules that enforce a given policy is a non-trivial, complex, and executed in a precise given order. In this paper we propose a time consuming task. In this paper we aim at simplifying this model of Netfilter in which we abstract the concept of chains, task both at specification and verification levels. For that, we rules and packets, and introduce the notion of state that records propose a formal model of Netfilter, a firewall system integrated the information about exchanged packets. We give a semantics in the kernel. We define an abstraction of the concepts for this abstraction, close to the real one, that specifies how of chains, rules, and packets existent in Netfilter configurations, and give a semantics that mimics packet filtering and address packets are dealt by the firewall in a specific state. translation. We then introduce a simple but powerful language The novel features of our model allow us to introduce a new that permits to specify firewall configurations that are unaffected simple declarative language that specifies firewall policies by by the relative ordering of rules, and that does not depend on the abstracting both the order in which rules are applied, and the underlying Netfilter chains. We give a semantics for this language different chains that Netfilter provides. The main advantage and show that it can be translated into our Netfilter abstraction. We then present Mignis, a publicly available tool that translates of this language is that transitions are defined in a single- abstract firewall specifications into real Netfilter configurations. step fashion, contrary to the multi-step semantics associated Mignis is currently used to configure the whole firewall of the with the evaluation of the different tables of Netfilter. We then DAIS Department of Ca’ Foscari University. show how this language can be translated into our Netfilter abstraction, and we provide sufficient conditions under which I.INTRODUCTION a specification given in this language and its translation into Netfilter abstraction have the same effect on packets, both in Protecting networks from external and internal attacks is terms of filtering and network address translation. a crucial task. System administrators rely on the usage of firewalls that examine the network traffic and enforce poli- It is important to stress that, in our high level setting, any cies based on specified rules. However, implementing correct order of rules is acceptable and irrelevant for the semantics, policies is a non-trivial task: if a policy is too weak the system whereas in Netfilter the order in which rules are written is may be attacked by exploiting its weaknesses, while if it is too fundamental and in general not interchangeable. Indeed, a restrictive legitimate traffic may be filtered out. well-known difficulty that reduces significantly the usability of Netfilter is that adding/deleting/modifying rules is context- Manually proving that implementations comply with a dependent and might potentially break the whole firewall firewall policy is a too much time-consuming practice given policy. This makes it painful for system administrators to that firewall rules are usually written in low-level, platform- modify complex Netfilter configurations. Our firewall lan- specific languages, thus automatic tools for testing them have guage, instead, makes it very easy to modify a configuration been developed [22], [34]. These tools however do not pre- as the relative order of rules never affects the behavior of vent users from introducing new flaws when modifying such the generated Netfilter rules. This language, in spite of its policies. Some flaws may derive from the wrong order of simplicity, is expressive and powerful enough to specify the firewall rules (consistency problems), and some others from most commonly used network security policies. the lack of matching rules for every packet that crosses the firewall (completeness problems). Another approach is to In order to demonstrate the feasibility and illustrate the use a firewall design process that passes through different simplicity and advantages of this approach we also present verification stages [26], but this is also time and resource MIGNIS, a novel publicly available tool that translates, ac- consuming. Policy visualization tools have also been developed cording to the aforementioned results, abstract firewall spec- [23], [28], [29], [33], but they are not sufficiently helpful in ifications into real Netfilter configurations. We then show an dynamically changing networks where new services are added example of how MIGNIS can be used in a realistic, large scale, over time, as these typically impose very articulated firewalls and non-trivial setting: MIGNIS is currently used to configure composed of hundreds or even thousands of interacting rules. the firewall of the DAIS Department of the Ca’ Foscari It is in fact very difficult to keep the number of rules small University of Venice. Using the overlap-detecting capabilities also because of redundancies (compactness problem). of MIGNIS and its simple syntax we were able to tackle the compactness problem by capturing many redundancies in the In our opinion, there is an increasing need for formal and initial Netfilter configurations, and we could thus drastically general tools to reason about the security of firewalls. Existing reduce the number of configuration lines. Moreover, we have tools are however still far from the intended goal and we run some experiments by querying the MIGNIS specification propose in this paper one further step in that direction. and we were able to extract information such as the rules that Our contribution: Netfilter is a firewall system inte- affect packets from a certain host or whether a certain rule is grated in the Linux kernel [32]. A firewall in Netfilter is already included or not in the specification.

1 Related work: Formal approaches to firewall policy is Uncomplicated (UFW) [12], the default firewall configurations have been studied in the literature. Gouda et al. tool for Ubuntu. However, in this tool the order of the rules propose in [24] a method, called Structured Firewall Design, is relevant, in contrast to our solution. [14] is a which allows the design of a firewall with non-conflicting quite mature and flexible tool that similarly to MIGNIS tries and compact rules. The technique is very interesting but it to express firewall policies at a higher level of abstraction limited to stateless firewalls in which a decision is taken only avoiding complex control-flow. The idea is that each zone has depending on the received packet, while our solution instead a policy and rules are exceptions to these policies. However, is more general given that it applies also to stateful firewalls, Shorewall is not as declarative as MIGNIS since rules are in which the fate of some packet also depends on the history still evaluated one after the other. Moreover, configurations of previously received packets. are spread into different files which makes it harder than in In [25] a formal model of firewall policy, based on Netfilter, MIGNIS to have a general view of what the policy is. Pyroman is introduced and two properties of firewall policy configura- [6] is a tool developed to configure the firewall of the Center tions, namely reachability and cyclicity are investigated. An for Digital Technology and Management in Munich. However, NP-completeness proof of the problem of analyzing a firewall given that its language is very close to the Netfilter configura- configuration with respect to those properties is also provided. tion language, it is not easy to manage. Graphical tools, such as kmyfirewall [3], firestarter [2] or the more complete Firewall As we have previously pointed out, an accurate semantics builder [8], suffer from the same shortcoming of language- of a high level language allows the security administrator to based tools in either not being expressive enough for the sake avoid firewall misconfigurations. The work that is closer to of simplicity or exposing low-level characteristics of Netfilter, our proposal is [21], where the authors provide an access such as the evaluation order of chains. control language based on the XML syntax that is supported by the access control model Or-BAC. The authors also present There are proposals for representing access control policies an example of the mapping of the abstract policy into some as XML documents [7], [10]. These approaches are interesting Netfilter firewall rules. In spite of the proposed language being but too complex given that they are meant to be applicable in more generic than ours, it lacks some important elements more general security policies and applications. of Netfilter configurations such as the specification of the Systems for the management of large scale infrastructures network address translation (NAT). Moreover, and contrary such as Chef [13], LCFG [15] and Puppet [17], usually to our solution, no formal proof of the correctness of the offer facilities to automatically deploy host-based firewalls on translation process between the abstract language and the low machines, providing configuration templates or allowing for level Netfilter language is presented. the specification of basic rules. In both cases, there is no formal Recently, some network programming languages, that cre- semantics for the specification nor any attempt to transform or ate an abstraction of network programs over some hardware- verify the provided rules. oriented APIs, have been proposed. An example is the lan- Bottom-up approaches that extract the model of the access guage proposed in the Frenetic project [9], which works at control policy from the configuration files of the firewalls two distinct levels and is able to capture dynamic policies. The and allow one to reason about their application have been language has evolved during the years but still it is not clear proposed [20], [27], [30], [31]. We instead take a top-down which primitives are essential, and how new added constructs approach that allows one to write simple, easy to modify should interact with the existing ones. Moreover, it does not firewall rules that are translated into a concrete Netfilter address interesting questions such as network reachability or firewall configuration. cyclicity. These features and others, such as reachability, traffic Finally, there are other interesting low level open-source isolation, and compiler correctness, have been captured by firewalls such as ipfilter [4], Packet Filter (PF) [11], and NetKAT a new network programming language equipped with pfSense [16]. They were developed for like systems, a sound and complete equational theory [18]. However, this OpenBSD and FreeBSD respectively, and language is not specifically targeted at firewalls, and thus does provide stateful firewalls and network address translation not consider some issues such as NAT, and does not provide (NAT). They have low-level -like rules, thus are not a translation mechanism to real-world packet filters. very easy to manage. In our opinion a mapping from the For what concerns firewall configuration tools, there are MIGNIS to all these firewalls is possible given their stateful many, but, as far as we know, for none of them a semantics of nature and their handling of NATs. This translation is an on- their specification language has been provided. Some of those going work. languages may be compiled to several low level languages, This paper is organized as follows: in Section II we provide and admit any order of rules, and thus are more general than background on Netfilter, and in Section III we give a formal the specification language that we propose. However, due to model of Netfilter chains, rules and packets. In Section IV we their generality, their complexity is close to the one of the introduce a simple firewall language that abstracts Netfilter low level specification, thus making their adoption harder. chains and the order in which rules are applied, and in Moreover, they usually also have a lack of expressiveness Section V we provide a translation of this language into in other fields: Firmato [19] only permits the use of allow Netfilter model. In Section VI we illustrate MIGNIS, a publicly rules, FLIP [35] does not support the overlap between rule available tool that translates firewall specifications into real selectors, and NeTSPoC [5] does not allow to specify custom Netfilter configurations, and we briefly illustrate and discuss filters over the generated rules. Other languages are simpler the DAIS Department firewall configuration. We conclude in but not expressive enough, e.g., HLFL [1] does not support Section VII. port ranges in its syntax. A widely adopted user-friendly tool

2 II.BACKGROUNDON Network

Netfilter is a standard framework for packet filtering in mangle Linux kernels [32]. It provides iptables, a tool that en- PREROUTING nat ables configuring Netfilter for packet filtering, network address PREROUTING translation (NAT) and packet mangling. The extreme flexibility mangle Routing of iptables makes it very powerful but also non-trivial to INPUT decision nat use. In fact, Netfilter configurations are inspected following a INPUT

flow that allows for jumping into subsets of rules, going back filter INPUT mangle to the ‘callee’, similarly to what happens in function calls, FORWARD exiting when a decision on the packet is taken, and applying a Local process filter FORWARD default policy when no matching rule is found. In this section mangle we present the basic notions behind packet filtering and NAT OUTPUT nat with iptables. Readers familiar with it can safely skip this OUTPUT section. filter OUTPUT mangle Chains and tables: Netfilter is based on tables, each POSTROUTING containing lists of rules called chains. We focus on the three nat most commonly used tables: mangle for packet alteration, POSTROUTING nat for NATs, and filter for packet filtering. There are Network five predefined chains that are inspected in specific moments of a packet life cycle: Fig. 1. Chain and table traversal. (i) PreRouting, as soon as the packet reaches the host; (ii) Forward, when the packet is routed through the host; options -t table and -L. Here we inspect table filter: (iii) PostRouting, when the packet is about to leave the # iptables -t filter -L host; Chain INPUT (policy ACCEPT) target prot opt source destination (iv) Input, when packets are routed to the host; (v) Ouput Chain FORWARD (policy ACCEPT) , when packets are generated by the host. target prot opt source destination

We have four possible execution flows: (i) → (ii) → (iii), Chain OUTPUT (policy ACCEPT) for packets passing through the host; (i) −→ (iv), for packets target prot opt source destination routed to the host; (v) −→ (iii) for packets generated by the host and (v) −→ (iii) −→ (i) −→ (iv) for packets that are both All chains are empty as rules would appear under the fields generated by the host and routed to the host. target, prot, etc. Moreover, the default policy is ACCEPT. -P Tables do not necessarily contain all of the above prede- To change the default policy we can use option as follows -t filter filter fined chains: table mangle contains all of them; nat contains (we omit option as is the default table): only PreRouting, Input (since kernel version 2.6.34), # iptables -P INPUT DROP # iptables -L Ouput, and PostRouting, whereas filter contains only Chain INPUT (policy DROP) Input, Forward and Ouput. Tables are inspected in the fol- ... lowing order: mangle, nat, filter. Figure 1 summarizes the resulting execution flow. After mangle-PreRouting In the example above the default policy for the Input chain and nat-PreRouting there is a branching and a packet is in table filter has been changed to DROP. When we ping either processed through the mangle-Input and filter- localhost we find that all packets are lost since the Input Input chains if it is addressed to the local host, or through chain is inspected when packets are routed to the local host: the mangle-Forward and filter-Forward chains if it # ping -v localhost is addressed to another host. Packets forwarded to other hosts PING localhost (127.0.0.1) 56(84) bytes of data. ˆC are then inspected by mangle-PostRouting and nat- --- localhost ping statistics --- PostRouting. The same happens to packets originated by 31 packets transmitted,0 received,100% packet loss ... the local host which are first processed through mangle- Ouput, nat-Ouput and filter-Ouput. Example 2 (Simple accept rule). By setting the default policy Rules: Chains are lists of rules that are inspected one for the Input chain in table filter to DROP we forbid any after the other. Rules specify criteria to match a packet and a external connection to the host. To enable ssh connections it target. If the packet does not match the criteria, the next rule is enough to add (-A chain option) an ACCEPT rule in the in the chain is examined; if it does match, then the packet is same chain and table specifying 22 as the destination port: processed as specified in the target. Here we only consider a # iptables -A INPUT -p tcp --dport 22 -j ACCEPT ACCEPT DROP # iptables -L subset of targets: , for accepting the packet, , for Chain INPUT (policy DROP) dropping it, DNAT, for destination NAT, and SNAT for source target prot opt source destination NAT. Chains may also have a default policy that is triggered ACCEPT tcp -- anywhere anywhere tcp dpt:ssh if none of the rules in the chain matches the packet. ... Example 1 (Default drop policy). By default Netfilter does We can see that we now have a rule that accepts any tcp packet not filter packets. We can list chains of a specific table using with destination port 22, i.e., ssh and in fact it is now possible

3 to connect to the host via ssh. It is worth mentioning that very close to the real implementation of conntrack. A state adding now another similar rule but with target DROP to the s is a set of tuples (src, dst, id, src0, dst0, id0) where src, dst end of this chain would still allow the ssh connections as rules are the source and destination of the initial packet, src0, dst0 are inspected in the order in which they appear in the chain. are the source and destination of the expected answer, and id, id0 model protocol-specific information that is used to track Example 3 (NATs). Address translation is useful in various established connections (e.g., the unique identifier of ICMP situations. For example, when accessing the Internet from an echo requests and replies). By recording this information in internal LAN, the source private address is translated into a the state, the conntrack module is able to perform all the public IP and all packets received back are translated and PreRouting and PostRouting translations. For example, forwarded to the originating address (source NAT). Another if host a starts a new tcp connection to an host b through example is a router that redirects external requests to a certain a source NAT with address c, then the state is enriched with port of a web server located in the internal LAN (destination the tuple (a, b, , b, c, ) as the expected answer should be a NAT). Destination NATs are defined in the nat table and in packet from b to c. When the answer arrives, we have enough the PreRouting chain as follows: information to transparently forward it to a. iptables -t nat -A PREROUTING -p tcp -i eth0 -d 192.168.0.1 --dport 80 -j DNAT --to-destination 192.168.0.100:80 We do not abstract packets since, as we will see below, our model allows for any constraint that is expressible in In this example, all connections from interface eth0 directed iptables syntax. Given a concrete packet p, we write sa(p), to 192.168.0.1 on port 80 are translated into 192.168.0.100 da(p), id(p) to denote respectively the source and destination on the same port. So any web connection to the first host will addresses and identifier (if applicable) of p. When receiving p be redirected to the second. Interestingly, answers from host one may check whether or not it belongs to an already 100 will be translated as coming from host 1 so that they will established connection by searching for tuples with matching transparently reach the browser that initiated the connection. src, dst, id or src0, dst0, id0. Moreover, if p belongs to an In fact, NAT rules are inspected only when initiating new established connection, one may also determine the source and connections. The translations are then stored and suitably destination of its expected answer. applied to all packets belonging to the same connection. We Definition 1 (Established connections). A packet p belongs to illustrate this below. an established connection in s, denoted p `s src, dst if one of the following holds: Conntrack: Netfilter uses the conntrack module to keep track of the established connections. The module stores i)(sa(p), da(p), id(p), src, dst, id) ∈ s the source and destination address of the packet that initiated ii)(src, dst, id, sa(p), da(p), id(p)) ∈ s the connection plus the source and destination address of the expected answer. This allows for correctly dealing with NATs. where src, dst are the source and destination addresses of the expected answer to p. Example 4 (Tracking destination NATs). For the destination NAT of Example 3, conntrack records the following infor- In the following we will write p `s to denote p `s src, dst mation: for some src and dst and we will write p 0s to denote that # conntrack -L p `s does not hold. ... tcp 6 431994 ESTABLISHED Modelling chains, tables and rules: A firewall is imple- src= 10.0.0.1 dst=192.168.0.1 sport=49303 dport=80 mented as a series of chains, tables and rules that are executed src=192.168.0.100 dst=10.0.0.1 sport=80 dport=49303 in a given order. Let us first consider rules that do not perform address translation. For the sake of simplicity we only consider We can see that the packet originated by 10.0.0.1 and ad- targets ACCEPT and DROP. dressed to 192.168.0.1 on port 80 expects an answer from 192.168.0.100 addressed to 10.0.0.1. This information is Rules are defined in terms of address ranges n. An address enough to apply the suitable translation to all subsequent range n is a pair consisting of a set of IP addresses and a set of packets of this connection: for packets originated by 10.0.0.1 ports, denoted IP(n):port(n). Given an address addr we write Netfilter translates (again) the destination into 192.168.0.100; addr ∈ n to denote port(addr) ∈ port(n), if port(addr) is for packets coming from 192.168.0.100 and addressed to defined, and IP(addr) ∈ IP(n). Notice that if addr does not 10.0.0.1 Netfilter translates the source address to 192.168.0.1, specify a port (for example in ICMP packets) we only check behaving this time as a source NAT. This latter translation will if the IP address is in the range. We will use the wildcard ∗ be done automatically in PostRouting as an effect of the to denote any possible address or port. established destination NAT. Definition 2 (Basic rule). A basic rule r is a tuple (n1, n2, φ, t) where n1 and n2 are respectively the ranges of source and III.A FORMALMODELOF NETFILTER destination addresses, φ is a formula over a packet and a We now give a formal model for a significant subset of state, and t ∈ {ACCEPT, DROP} is the target of the rule. Netfilter covering all of the predefined chains: PreRouting, Forward, PostRouting, Input and Ouput. More specifically, a formula φ is any option expressible in iptables that is checkable over a packet and possibly a Modelling conntrack: As explained in Section II, the state, excluding options that: conntrack module keeps track of the active connections re- lating the source/destination IP of a packet with the source/des- • alter the packets, except for address translation that we tination of the expected response. Our abstraction of a state s is support explicitly in special translation rules defined

4 below; other packet alterations are not supported at the p s p, s6|=T nat p `s src, dst 0 δ moment; [DEstll ] [DNewll ] (s, p) δ p[da 7→ src] (s, p) δ p • alter the connection state which, to the best of our ll ll p s p, s|=T nat t dst ∈ t knowledge, is not possible in core iptables modules; 0 δ [DNATll ] δ • alter the chains, as we want to have full control on chain (s, p) ll p[da 7→ dst] definition. For example option -F would flush the chain p s p,˜ s6|= nat removing all the existing rules and altering the semantics p `s src, dst 0 Tσ [SEstll ] [SNewll ] (s, p, p˜) σ p˜[sa 7→ dst] (s, p, p˜) σ p˜ of the firewall. ll ll

p s p,˜ s|= nat t src ∈ t Example 5. The iptables rule of Example 2: 0 Tσ σ [SNATll ] # iptables -A INPUT -p tcp --dport 22 -j ACCEPT (s, p, p˜) ll p˜[sa 7→ src]

PRE sa(p) 6∈ L da(˜p) 6∈ L p, s|=Lman ACCEPT (s, p) ll p˜ ∗ ∗ ∗ 22 ACCEPT PRE is modelled as ( : , : , -p tcp, ). We notice that p,˜ s|=Lman ACCEPT p,˜ s|= fil ACCEPT FOR L FOR --dport 22 in the only constraint on addesses and is POST 0 p,˜ s|=Lman ACCEPT (s, p, p˜) ll p POST  included in the second component ∗:22. Formula φ is ‘-p tcp’. [Forwardll ] 0 p,p 0 s −→ll s ] (p, p ) We extend this to consider rules that perform address PRE sa(p) 6∈ L da(˜p) ∈ L p, s|=Lman ACCEPT (s, p) ll p˜ translation. We still formalize rules as quadruples but in this PRE  INP 0 0 p,˜ s|=Lman ACCEPT (s, p, p˜) ll p p , s|= fil ACCEPT INP  L case, instead of a target, we specify the address range on which INP [Inputll ] 0 we perform the translation. This uniform notation for rules will p,p 0 make semantics concise. s −→ll s ] (p, p ) OUT sa(p) ∈ L da(˜p) 6∈ L p, s|=Lman ACCEPT (s, p) ll p˜ Definition 3 (Translation rule). A translation rule r is a tuple OUT  POST 0 p,˜ s|= fil ACCEPT p,˜ s|=Lman ACCEPT (s, p, p˜) ll p L POST  (n1, n2, φ, t) where n1 and n2 are respectively the ranges of OUT [Outputll ] 0 source and destination addresses, φ is a formula over a packet p,p 0 and a state, and t is the range to which the addresses are s −→ll s ] (p, p ) OUT translated. We abusively call this range of addresses t the sa(p) ∈ L da(˜p) ∈ L p, s|=Lman ACCEPT (s, p) ll p˜ OUT  POST 0 target of the rule. p,˜ s|= fil ACCEPT p,˜ s|=Lman ACCEPT (s, p, p˜) ll p L POST  OUT 0 0 0 p , s|=Lman ACCEPT p , s|=Lman ACCEPT p , s|= fil ACCEPT PRE INP L Example 6. The iptables rule of Example 3: INP [Localll ] iptables -t nat -A PREROUTING -p tcp -i eth0 -d 192.168.0.1 p,p0 s −→ s ] (p, p0) --dport 80 -j DNAT --to-destination 192.168.0.100:80 ll is modelled as (∗:∗, 192.168.0.1:80, -p tcp, 192.168.0.100:80) TABLE I. NETFILTER FIREWALL SEMANTICS. assuming that eth0 is connected to the Internet, i.e., all source addresses are possible. Definition 6 (Netfilter Firewall). A Netfilter firewall F is A packet p matches a rule r in a state s whenever its composed of twelve lists of rules Lman, T nat , Lman, T nat, source and destination addresses are in the specified ranges PRE PRE INP INP Lfil , Lman , T nat , Lfil , Lman , Lfil , Lman , T nat , where the and φ holds. INP OUT OUT OUT FOR FOR POST POST subscript represents the chain name and the superscript the Definition 4 (Rule match). Given a rule ri = (n1, n2, φ, t) we table name. L lists are composed of basic rules while T lists say that p matches ri in state s, denoted p, s|=r ri, if sa(p) ∈ are composed of translation rules. n1, da(p) ∈ n2 and φ(p, s). Netfilter firewall semantics: We can now define how We can now define how a packet is processed given a list a packet p is dealt by a Netfilter firewall F in a state s. of rules. As in real implementations of Netfilter we inspect The semantics is presented in Table I. To distinguish this rules one after the other until we find a matching one, which semantics from the abstract and intermediate ones introduced establishes the destiny (target) of the packet. in the following sections, we index rule names and transitions Definition 5 (Rule list match). Given a rule list R = with ll (meaning low-level). Semantics is given in terms of three different transition relations. [r1, . . . , rn], we say that p matches R in state s with target t, denoted p, s|= t, if δ R The first relation is (s, p) ll p˜, meaning that p is accepted as p˜ by chain δ in state s. This is where destination NAT ∃i ≤ n . ri = (n1, n2, φ, t) ∧ p, s|=r ri ∧ ∀j < i . p, s6|=rrj. happens and δ can be either PRE or OUT. Rule DEstll is We also write p, s6|=R if p does not match any of the rules in applied to packets that are already defined in the state. These nat R, formally ∀ri ∈ R . p, s6|=rri. do not go through the Tδ table as their destination address is already recorded in the state; we translate the destination We can now define a Netfilter firewall as a set of lists of address of these packets into the source address of their rules, each corresponding to a chain in a certain table. For the expected answer, since this is how they should be delivered. nat table we have lists of translation rules that we denote Rule DNewll states that new packets for which there is no nat by T . Albeit standard descriptions of Netfilter do not include rule in Tδ are not translated; rule DNATll on the contrary Input chain in nat table this is part of Netfilter since kernel states that for new packets for which there is a translation nat version 2.6.34, and we have decided to include it in the model. rule in Tδ , the destination address is translated to some dst

5 belonging to the range of destinations t. and PostRouting: when the packet comes in, the chains PreRouting Input nat Relation (s, p, p˜) σ p0, means that p, previously translated and of table are not inspected. ll Rule Local correctly mimics this behaviour. into p˜ in chains PRE or OUT, is now accepted as p0 by chain σ ll in state s. This models source NAT and in this case σ is either Example 7. Consider the destination NAT rule from Exam- POST or INP. This relation is defined by rules SEstll , SNewll ple 6 in chain PreRouting of table nat and let and SNATll that are dual of the previous ones. nat TPRE = [(∗:∗, 192.168.0.1:80, -p tcp, 192.168.0.100:80)] p,p0 Finally, relation s −→ s0 represents the state transition ll We assume that all other translation lists T are empty, and that from s to s0 where packet p is accepted and translated into p0. all basic lists L are [(∗, ∗, >, ACCEPT)], that is, they accept The relation is defined through four rules corresponding to the any packet. Moreover, let L = {127.0.0.1:∗, 192.168.0.1:∗} four possible execution flows discussed in Section II: Forward ll be the set of addresses of our firewall. is for packets that pass through the host; Inputll for the ones that are routed to the host; Outputll for packets generated by Consider now an empty state s and a packet p coming the host; and Localll for the ones both generated by and routed from sa(p) = 1.2.3.4:5678 on the Internet and directed to to the host. da(p) = 192.168.0.1:80. Let us for readability write such packet as p = (1.2.3.4:5678 192.168.0.1:80). Since sa(p) 6∈ We denote by L the set of addresses corresponding to L we can only apply either Forward or Input . Since state the host, typically 127.0.0.1 and all the IPs of the various ll ll s is empty, thus p , and given the rule above, we have interfaces with no port restriction. Given a packet p and its 0s p, s|= nat 192.168.0.100:80 which by application of DNATll , TPRE translation p˜ after destination NAT, we select one of the four PRE rules depending on whether or not p and p˜ belong to L. For gives (s, p) ll p˜ for p˜ = p[da 7→ 192.168.0.100:80] = example, rule Forward is applied whenever sa(p) 6∈ L and (1.2.3.4:5678 192.168.0.100:80). Intuitively, p˜ is packet p ll after destination NAT. da(˜p) 6∈ L, while rule Outputll is applied whenever sa(p) ∈ L and da(˜p) 6∈ L. Since da(˜p) 6∈ L we apply rule Forwardll and this packet 192.168.0.100 T nat DROP will be forwarded to the web server . As POST Our semantics assumes a default policy, i.e., a packet POST 0 0 is dropped if not explicitly accepted by some basic rule in each is empty, rule SNewll gives (s, p, p˜)ll p with p =p ˜. man man man fil of the traversed chains. Address translation is instead optional: Moreover, LPRE,LFOR,LPOST,LFOR accept any packet and so 0 p,p 0 if there is no matching translation rule the packet is delivered we have s −→ll s with unchanged. Rule Forwardll states that a packet p is accepted 0 as p0 if it is: s = { (1.2.3.4:5678, 192.168.0.1:80, , 192.168.0.100:80, 1.2.3.4:5678, ) } (1) accepted by mangle-PreRouting list Lman; PRE Consider now answer p = (192.168.0.100:80 1.2.3.4:5678) (2) possibly transformed into p˜ by nat-PreRouting list a nat from the server. Notice that these addresses match the second TPRE, or by the fact that it belongs to an established PRE part of the tuple in s meaning that pa is established and giving connection subject to NAT (relation (s, p) ll p˜); pa `s 1.2.3.4:5678, 192.168.0.1:80. By rules DEstll we obtain (3) accepted as p˜ by mangle-Forward, filter- PRE man (s, pa) ll pa[da 7→ 1.2.3.4:5678] = pa, and by rule SEstll Forward and mangle-PostRouting lists L , POST 0 0 FOR (s, pa, pa) ll pa with pa = pa[sa 7→ 192.168.0.1:80] = fil man 0 LFOR and LPOST; and 0 pa,pa 0 0 nat (192.168.0.1:80 1.2.3.4:5678) which gives s −→ll s . (4) possibly translated from p˜ into p by list TPOST, or when POST 0 0 on an established connection (relation (s, p, p˜) ll p ). Intuitively, the established connection in s applies a source 0 NAT to the answer packets so that they go out with the State update is achieved through the partial function s](p, p ) source address that was initially contacted by 1.2.3.4, i.e., that yields: 192.168.0.1:80. The state s0 is unchanged because the answer belongs to an established connection. • s if p `s • s ∪ {(sa(p), da(p), id(p), sa(pans), da(pans), id(pans))} if p 0s and pans 0s where pans is the expected answer to p, IV. FIREWALL SPECIFICATION LANGUAGE i.e., p = p0[sa 7→ da(p0), da 7→ sa(p0)] ans In order to simplify the specification of firewall policies we Intuitively, when p belongs to an established connection the propose a simple firewall specification language that abstracts state is not modified and s0 = s. When instead p does not the many different chains existing in Netfilter and the order belong to any established connection we extend the state with in which rules are applied. We later provide a translation a new tuple in which the source and destination addresses of p0 of this simple language into a Netfilter firewall and show are swapped, as we want to store the source and destination that, under reasonable assumptions, this translation preserves addresses of the expected answer pans to p. The check pans 0s the semantics, that is, firewall configurations written in this avoids that the new tuple overlaps with existing connections. language can be translated into equivalent configurations for This models the fact that in real scenarios it is not possible (our model of) Netfilter. to connect from/to a busy port or to reuse an already taken Syntax: The firewall language has the following syntax: connection identifier. r ::= n / n | φ (DROP) The other three rules model the corresponding three exe- 1 2 | n1 > n2 | φ (ACCEPT) cution paths similarly to Forwardll . Notice that local commu- | n1 > [n2] nt | φ (DNAT) nication only performs address translation in chains Ouput | n1 [nt] > n2 | φ (SNAT)

6 p, s|=C ACCEPT p, s6|=C DROP configuration. Differently from the low-level semantics of [ACCEPThl ] (s, p) ↓hl p Section III, this relation is derived in one step from single or pairs (in the case of DSNAT) of firewall language rules. In p, s|= DNAT(n ) dst ∈ n p[da 7→ dst], s6|= DROP, SNAT C t t C particular, rule ACCEPThl applies when p matches an ACCEPT [DNAThl ] hl (s, p) ↓ p[da 7→ dst] firewall rule of the form n1 > n2 | φ and it is not dropped. The packet is accepted with no translation. Rule DNAThl applies p, s|=C SNAT(nt) src ∈ nt p, s6|=C DROP, DNAT [SNAThl ] to n > [n ] n | φ and checks that the translated packet is hl 1 2 t (s, p) ↓ p[sa 7→ src] not dropped neither has an applicable SNAT rule (otherwise

p, s|=C DNAT(nt) dst ∈ nt p˜ = p[da 7→ dst] rule DSNAThl should be used). In this case the packet is 0 0 p,˜ s6|=C DROP p,˜ s|=C SNAT(nt) src ∈ nt accepted as p[da 7→ dst] where dst ∈ nt. Rule SNAThl applies [DSNAThl ] (s, p) ↓hl p˜[sa 7→ src] to n1 [nt] > n2 | φ and it is the dual of DNAThl . Notice that in this case we check that the original p (before source NAT) hl 0 p 0s (s, p) ↓ p is not dropped: as we explained before, DROP forbids packets [NEWhl ] 0 p,p 0 s −→hl s ] (p, p ) between the communication endpoints and so we check it after destination NAT and before source NAT. Rule DSNAThl simply p `s src, dst p[da 7→ src], s6|=C DROP combines the two rules above and is applied when there are p0 = p[da 7→ src, sa 7→ dst] [ESThl ] matching DNAT and SNAT rules. This is useful when we want p,p0 s −→hl s to have both source and destination NAT on the same packet. 0 p,p 0 TABLE II. FIREWALLLANGUAGESEMANTICS. Relation s −→hl s denotes the state transition and is given by two rules. Rule NEWhl applies to any packet p that establishes a new connection and is accepted as p0 by one of the previous rules. The state is updated so to include the new Intuitively, the DROP rule n / n | φ forbids packets p that 1 2 connection, using the same ] operator of Table I. Rule ESThl satisfy φ(p, s) to flow from n1 to n2, even through NATs, and simply inspects the state for established connections and has priority over any other rule. It applies to any packet p performs the corresponding translation as long as there is no either in a new or in an established connection with n1 and explicit rule dropping this packet (again, after destination NAT n2 as communication endpoints i,e, after destination NAT and is applied). before source NAT are applied; the ACCEPT rule n1 > n2 | φ enables new connections from n1 to n2, as long as φ holds. Example 8. Consider the destination NAT rule from Exam- We write n1 > [n2] nt | φ to indicate that nt is behind a ples 6 and 7. In the firewall language it is specified as destination NAT (DNAT) and n1 may start new connections with it by sending a packet satisfying φ to an address in n2; we use n1 [nt] > n2 | φ to indicate that n1 may start new source C = {∗:∗ > [192.168.0.1:80] 192.168.0.100:80 | -p tcp} NAT (SNAT) connections with n2 sending packets satisfying φ and with source address nt. Established connections are always allowed in both directions, unless they are explicitly dropped Differently from Example 7 here we do not have to specify by DROP. A set of these firewall rules is called a configuration. anything else: the firewall will only allow packets through this destination NAT and all the established answers to them. The firewall language allows administrators to specify firewalls in a purely declarative style. There is no control flow: Consider an empty state s and the same packet new packets that match at least one of ACCEPT,DNAT,SNAT p = (1.2.3.4:5678 192.168.0.1:80) as in Example 7. and established packets go through if they are not explicitly We have p, s|=C DNAT(192.168.0.100:80) and clearly 0 0 dropped by DROP. Notice that, in most of the cases, DROP p , s6|=C DROP, SNAT with p = p[da 7→ 192.168.0.100:80] = is not necessary since the same effect could be obtained by (1.2.3.4:5678 192.168.0.100:80) since there are no DROP hl 0 restricting the scope of the other rules in order to accept less nor SNAT rules in C. By DNAThl we obtain (s, p) ↓ p 0 p,p 0 0 packets. However, DROP is very useful in practice as it makes and thus s −→hl s with s as in Example 7. The answer it possible, for example, to forbid all packets from/to specific pa = (192.168.0.100:80 1.2.3.4:5678) from the server hosts or ports independently of the many different ACCEPT, is established, i.e., pa `s 1.2.3.4:5678, 192.168.0.1:80. 0 DNAT or SNAT rules these hosts and ports might match. This 0 pa,pa 0 By rule ESThl we directly have s −→hl s with is the reason why we give higher priority to the DROP rule. 0 pa = pa[sa 7→ 192.168.0.1:80, da 7→1.2.3.4:5678] = Semantics: We extend the notation of Section III to (192.168.0.1:80 1.2.3.4:5678). C the firewall specification language. Let be a configuration. Notice that for this specific packets the configuration C p, s|= ROP, CCEPT, NAT( ), NAT( ) We write C D A D nt S nt to re- behaves like the one of Example 7. However the two firewalls C / | φ spectively denote that there exists in rule n1 n2 are not the same: here the destination NAT is the only way to > | φ > [ ] | φ or rule n1 n2 or rule n1 n2 nt or rule send a packet to the server and any other packet is rejected, [ ] > | φ sa(p) ∈ , da(p) ∈ n1 nt n2 , such that n1 n2, and apart from established ones. In Example 7 we configured all φ(p, s) . When no such matching rules exist we respectively chains so accept any packets, making the firewall completely p, s6|= ROP, CCEPT, NAT, NAT write C D A D S . open. To implement a configuration that behaves like the single Firewall language semantics is presented in Table II. Se- DNATrule in the firewall language we would need to add 3 mantics is given in terms of two relations. Relation (s, p) ↓hl p0 more rules in the Netfilter chains as discussed in the next states that p is accepted as p0 in state s by the firewall section.

7 n1 > n2 | φ n1 / n2 | φ il p s p, s6|=S p `s src, dst 0 DNAT (n1, n2, φ, ACCEPT) ∈ SA (n1, n2, φ, DROP) ∈ SD [DEstil ] [DNewil ] (s, p) DNAT p[da 7→ src] (s, p) DNAT p il il n1 > [n2] nt | φ il (n1, nt, φ, DROP) ∈ SD1 (n1, n2, φ, nt) ∈ SDNAT p 0s p, s|=SDNAT t dst ∈ t ? (n1, nt, φ , ACCEPT) ∈ SA DNAT [DNATil ] (s, p) il p[da 7→ dst] n1 [nt] > n2 | φ p p,˜ s6|=il p `s src, dst 0s SSNAT (n1, n2, φ, ACCEPT) ∈ SA (n1, n2, φ, nt) ∈ SSNAT [SEst ] [SNew ] SNAT il SNAT il (s, p, p˜) il p˜[sa 7→ dst] (s, p, p˜) il p˜ TABLE IV. TRANSLATION FROM FIREWALL LANGUAGE TO p p,˜ s|=il t src ∈ 0s SSNAT t INTERMEDIATE LEVEL LANGUAGE. [SNAT ] SNAT il (s, p, p˜) il p˜[sa 7→ src]

sa(p) 6∈ L ∨ da(˜p) 6∈ L DNAT il DNAT The first relation is (s, p) il p˜, meaning that p is p `s ∨ p, s6|=S (s, p) il p˜ D1  il il SNAT 0 accepted in state s as p˜ after performing a destination NAT p,˜ s6|= p `s ∨ p,˜ s|= (s, p, p˜) p SD SA il δ [Extil ] translation. It is equal to relation (s, p) ll p˜ of Table I 0  p,p 0 nat s −→il s ] (p, p ) using SDNAT as the translation rules instead of Tδ . The second SNAT 0 relation is (s, p, p˜) il p and it means that p, previously sa(p) ∈ L ∧ da(˜p) ∈ L il DNAT translated into p˜ by some destination NAT, is now accepted in p `s ∨ p, s6|=S (s, p) il p˜ D1  0 il il SNAT 0 state s as p after performing a source NAT translation. It is p,˜ s6|= p `s ∨ p,˜ s|= (s, p, p˜) p SD SA il σ 0 0 il 0 il 0 il equal to relation (s, p, p˜) ll p of Table I using SSNAT as the p `s ∨ p , s6|=S p , s6|=S p `s ∨ p , s|=S 0 D1 D A nat p,p 0 [Localil ] 0 translation rules instead of Tσ . Finally, relation s −→il s p,p 0 0 s −→il s ] (p, p ) represents the state transition from s to s where packet p is accepted and translated into p0, and is defined through rules TABLE III. SEMANTICS OF THE INTERMEDIATE LEVEL FIREWALL. Extil and Localil .

Rule Extil reflects the flow of non-local packets. Rules in SD are all of type DROP and will be responsible for dropping V. FROM THE FIREWALL LANGUAGE TO NETFILTER 1 packets that try to circumvent destination NATs. A packet to In this section we show that the firewall specification be accepted has then either to belong to an already established language presented in Section IV can be translated into our connection or to match none of these rules; if p passes this Netfilter model of Section III, and that under reasonable test it will be translated into p˜ by some destination NAT. The conditions the accepted packets are the same. Since there resulting packet p˜ should not match any DROP rule in SD, are significant differences between the two approaches, e.g., and is required to either match an ACCEPT rule in SA, as Netfilter assumes ordering among the rules while the firewall the default policy is DROP, or the original packet to be in an language does not, we propose an intermediate step where established connection. If p˜ passes all these tests the source the language is close to the one presented in Section III NAT translation produces the final p0. but where the ordering is still irrelevant. We then map the Rule Local applies to local packets and is equal to rule firewall language to this intermediate language, and finally this il Ext except that the packet p0 is then sent back to the local intermediate language to the Netfilter model. il machine and has to pass the initial verifications. Notice that in Definition 7 (Intermediate Firewall). An intermediate firewall this case we do not apply again destination nor source NATs

FI is composed of five sets of rules SD1 ,SDNAT,SD,SA,SSNAT as this is the behavior in Netfilter. respectively to drop packets before destination NAT, to perform We stress three ideas from this intermediate semantics. The destination NAT, to drop and accept connections, and finally first is that packets belonging to established connections are to perform source NAT. Rules in SD ,SD and SA are basic 1 always accepted unless explicitly dropped by a rule in SD; rules while rules in SDNAT,SSNAT are translation rules (cf. Def- the second is that we have all DROP rules (S ,S ) checked initions 2 and 3). Moreover, rules in S and S have target D1 D D1 D before the ACCEPT rules (S ) and so acceptance implies the DROP ACCEPT A while rules in SA have target . non-match of any of the DROP rules; and finally that we allow ourselves to consult the state of the original packet p even The following definition is similar to Definition 5. after performing a destination or a source NAT translation. Definition 8 (Rule set match). Given a set of rules S = This might look counter-intuitive but is in fact what happens in {s1, . . . , sn}, we say that p matches S in state s with target t, real iptables semantics. This will become clearer once we il denoted p, s|=S t, if define later in this Section the translation between these levels.

∃si ∈ S . si = (n1, n2, φ, t) ∧ p, s|=r si. il We also write p, s6|=S if p does not match any of the rules in A. From the firewall language into the intermediate level S, formally ∀s ∈ S . p, s6|= s . i r i We will now show that our abstract firewall language can Intermediate firewall semantics: Intermediate level fire- be encoded into this intermediate level firewall. Translation is given by the least sets S ,S ,S ,S and S satisfying wall semantics is presented in Table III and similarly to the D1 D A DNAT SNAT semantics presented in Table I for Netfilter is also given in the rules of Table IV. terms of three different transition relations (indexed by il). All translations in Table IV are intuitive except the DNAT

8 one, where the rules added to SA and SD1 might need some the second introduces non-determinism in the specification. To explanation. For the first, one can easily see that if a packet p disallow these we require that for every packet p, and state s matches a DNAT rule n1 > [n2] nt | φ, the formula φ that is p, s|=C ACCEPT iff p, s6|=C SNAT and p, s6|=C DNAT. We call matched by p before the translation should not be the same as such configurations nat-consistent. the φ? that is matched by p˜ after the translation. As an example This condition enforces that an ACCEPT rule is matched φ = (da(p) = IP(n )) consider 2 . This formula is true before iff there is no matching NAT rule, and can be syntactically p the translation, as is addressed to n2, but is no longer true enforced (although more restrictively) by checking that if r = p˜ after the translation, where is now addressed to nt. Since we n > n | φ and r0 = n0 [n0 ] > n0 | φ0 or r0 = n0 > [n0 ] n0 | φ0 φ 1 2 1 t 2 1 2 t do not want to introduce any structure in , the most that we are in C then n ∩ n0 = ∅ or n ∩ n0 = ∅. can require for this to be well-defined is φ? to be such that for 1 1 2 2 any packet p, state s, n1 > [n2] nt | φ ∈ C and dst ∈ nt, we We say that a SNAT rule r is local if r = n1 [nt] > n2 | φ ? have φ(p, s) iff φ (p[da 7→ dst], s). This way we ensure that and n1 ∩ L= 6 ∅ and n2 ∩ L= 6 ∅. φ is somehow preserved by the destination NAT translation. Theorem 2. Let C be an abstract firewall configuration A trivial way to enforce this condition is to require that the φ ? and FI the intermediate firewall obtained by the translation used in DNAT rules cannot refer da(p) and define φ = φ. presented in Table IV. Then for any states s, s0 and packets 0 For the rule in SD1 the rationale is that the ACCEPT p, p we have that: rule added to SA would make it possible to send packets 0 0 p,p 0 p,p 0 directly from n1 to nt, that is more than what we want when (i) if s −→il s then s −→hl s ; defining the DNAT rule n1 > [n2] nt | φ. To prevent this, we (ii) if C is well-formed, nat-consistent, has no local SNAT 0 0 have to drop those packets before destination NAT is applied. p,p 0 p,p 0 rules, and s −→hl s then s −→il s . However, and as a side effect, these rules in SD1 will also disable legitimate communications of rules n1 > nt | φ and 0 0 B. Relating intermediate and Netfilter firewalls n1 > [nt] n2 | φ and n1 [n2] > nt | φ which poses a problem when we think about completeness. We now relate intermediate firewalls FI introduced earlier in this section with the Netfilter firewalls F of Section III. While the soundness of our translation is always guaran- 0 0 0 0 0 p orig(p ) p p,p 0 p,p 0 Given a packet we will denote by the packet teed, i.e., if s −→il s then s −→hl s , its completeness needs δ before performing any NAT translation, that is, (i) if (s, p) ll some extra conditions. In particular, one needs to exclude the 0 0 δ σ 0 p then orig(p ) = p, (ii) if (s, p) ll p˜ and (s, p, p˜) ll p then S 0 same behaviors that are excluded by D1 . orig(p ) = p; and (iii) if no NAT translation is performed then We say that a configuration is well-formed if for every orig(p0) = p0. packet p, state s, and n1 > [n2] nt | φ in C, if p, s|=C ACCEPT Definition 9. Let FI = hSD1 ,SDNAT,SD,SA,SSNATi be an or p, s|=C DNAT(nt) or p, s|=C SNAT(nt) then sa(p) ∈/ n1 ∨ intermediate firewall. The translation into a Netfilter firewall da(p) ∈/ nt ∨ ¬φ(p, s). Intuitively we are saying that if there F = hLman, T nat , Lman, T nat, Lfil , Lman , T nat , Lfil , Lman , is a DNAT with end-points n and n , then there can be no PRE PRE INP INP INP OUT OUT OUT FOR 1 t Lfil , Lman , T nat i is defined as follows: other (non-drop) rule that allows direct access from n1 to nt. FOR POST POST (i) Let Sest = {(n , n , φ ∧ orig(p) , t) | (n , n , φ, t) ∈ The above condition can be syntactically enforced (al- D1 1 2 0s 1 2 0 0 S }. Let list Lman be any possible ordering of the set though more restrictively) requiring n1 ∩n1 = ∅ or nt ∩n2 = ∅ D1 PRE 0 0 0 0 0 0 0 Sest ; add rule (∗, ∗, >, ACCEPT) to the end of this list; whenever ri = n1 > n2 | φ , or ri = n1 > [n2] nt | φ , or D1 0 0 0 0 nat ri = n1 [nt] > n2 | φ . Notice that in the particular case that (ii) Let list TPRE be any possible ordering of the set SDNAT; ri = n1 > [n2] nt | φ the definition above enforces n2 and nt man (iii) Let list LINP be the concatenation of any possible ordering to be disjoint. of the set SD with any possible ordering of the set SA ∪ {(∗, ∗, orig(p) ` , ACCEPT)}; add rule (∗, ∗, >, DROP) Lemma 1. Let C be an abstract firewall configuration and FI s the intermediate firewall obtained by the translation presented to the end of this list; nat in Table IV. Then for any state s and packet p we have that: (iv) Let list TINP be any possible ordering of the set SSNAT; man (v) Let LOUT be defined as (i); nat (i) p, s|=il iff p, s|= NAT( ) (vi) Let T be defined as (ii); SDNAT nt C D nt OUT fil (ii) p, s|=il iff p, s|= NAT( ) (vii) Let L be defined as (iii); SSNAT nt C S nt OUT fil (iii) p, s6|=il iff p, s6|= DROP. (viii) Let L be defined as (iii); SD C FOR nat (ix) Let TPOST be defined as (iv); The proofs of the propositions can be found in Appendix A. fil man man (x) Let list LINP = LFOR = LPOST = {(∗, ∗, >, ACCEPT)}. In order to achieve completeness, we need to require an extra condition. We can see that if rules n1 > n2 | φ and Several remarks should be made concerning the translation n1 [nt] > n2 | φ are both present in a configuration C, above. First, notice that the formula orig(p) 0s used in then any packet from a source in n to a destination in n , the rules of Sest , item (i), is not in iptables language. 1 2 D1 satisfying φ, can follow directly to n2 or through the SNAT. However, this is only for convenience of the exposition as this Similarly, if n1 > n2 | φ and n1 > [n2] nt | φ are both present formula can be written as the option -m state --state in configuration C, one cannot know if the packet will be NEW. Moreover, the module state always inspects the state forwarded to n2, or to an address in nt. The first case poten- of the packet before any address translation and so it will tially allows one to expose private IPs to the outside, whereas always return the same result regardless of being applied

9 to the original p, to the p˜ obtained after destination NAT This notion of deterministic configurations can be extended translation, or to the p0 obtained after source NAT translation. to intermediate firewalls. We say that an intermediate firewall man 0 Similarly, the formula orig(p) `s used in LINP , item (iii), FI is deterministic if for any packet p, state s, and rules r, r ∈ 0 0 0 0 0 is also not written in iptables language. This is again SDNAT with r = (n1, n2, φ, t), r = (n1, n2, φ , t ), if p, s|=r 0 0 0 for convenience of the exposition as, for the same reason as and p, s|=r then t = t ; analogous for r, r ∈ SSNAT. above, this formula can be written as the option -m state Proposition 4. Let C be a configuration and F the interme- --state ESTABLISHED. I diate firewall obtained by the translation presented in Table IV. Notice also that since all rules in S and S have target D1 D Then C is deterministic iff F is deterministic. DROP the order in which they are implemented (among them) I man man man in LPRE and LINP is irrelevant; similarly for SA (LINP ) where Lemma 5. Let FI be an intermediate firewall and F the the target is always ACCEPT. For SDNAT and SSNAT it is Netfilter firewall obtained by the translation presented in trickier as the firewall semantics presented in Table II is non- Definition 9. Then for any state s and packets p, p,˜ p0 we have deterministic in the presence of overlapping NATs. We will that: address this problem later in this Section. δ DNAT (i) for δ = PRE, OUT, if (s, p) ll p˜ then (s, p) il p˜; Finally, we would like to make a simple remark in terms of (ii) for σ = POST, INP, if (s, p, p˜) σ p0 then (s, p, p˜) SNAT p0 efficiency of the generated rules. It is clear from the translation ll il Moreover, if F is deterministic we also have that: that we are overpopulating the lists of F. As an example, notice I man (iii) for δ = PRE, OUT, if (s, p) DNAT p˜ then (s, p) δ p˜; that we place all the rules of SA in LINP , but only packets il ll SNAT 0 σ 0 with destination dst ∈ L will ever flow through the Input (iv) for σ = POST, INP, if (s, p, p˜) il p then (s, p, p˜) ll p man chain. So, one could effectively “restrict” the rules in LINP to those which the destination has a non-empty intersection with We can now state our Theorem. L and obtain the same behavior, as the removed rules would Theorem 6. Let FI be an intermediate firewall and F the never be triggered. Similarly for the other lists. We adopted Netfilter firewall obtained by the translation presented in to overpopulate the lists and do this “pruning” afterwards as Definition 9. Then for any states s, s0 and packets p, p0 we it would simplify both the translation and the proofs. We can have that: however state the following proposition. 0 0 p,p 0 p,p 0 Proposition 3. Let F be a Netfilter firewall and Ltab and T tab (i) if s −→ll s then s −→il s ; ch ch 0 0 respectively a basic rule list and a translation rule list of chain p,p 0 p,p 0 (ii) if FI is deterministic and s −→il s then s −→ll s . ch and table tab. Define Notice that the translation given in Definition 9 (ll ⇒ il) (i) Ltab = {r | r = (n , n , φ, t) ∈ Ltab ∧ n ∩ L 6= ∅}; INP 1 2 INP 2 is always sound like the one presented in Table IV (il ⇒ hl). tab tab (ii) LOUT = {r | r = (n1, n2, φ, t) ∈ LOUT ∧ n1 ∩ L 6= ∅}; This implies that all the real Netfilter behaviors are captured tab tab by the semantics of Table II. (iii) LFOR = {r | r = (n1, n2, φ, t) ∈ LFOR ∧(n1∪n2)∩L = ∅} (iv) Similarly for T nat and T nat . INP OUT VI.THE MIGNISTOOL

Then for ch = INP, OUT one has that p, s|=T tab t iff p, s|= tab t. ch Tch MIGNIS, “murus ignis” (“wall of fire” in latin) is a publicly For ch = INP, OUT, FOR one has that p, s|=Ltab t iff p, s|= tab t. available Python program of about 1500 lines of code, under ch Lch active development.1 The aim of MIGNIS is to take a set The presence of two NATs with different targets, for exam- of rules written in the firewall specification language and to 0 ple, n1 [nt] > n2 | φ and n1 [nt] > n2 | φ, or n1 > [n2] nt | φ translate them into real iptables rules. In the previous 0 and n1 > [n2] nt | φ, is a source of non-determinism as in sections we have shown how to translate the firewall language the first case we do not know which source address to exhibit, into the Netfilter model in a way that preserves the semantics. and in the second we do not know which destination to send It is thus enough to map the rules in the Netfilter model into the packet to. the actual iptables syntax. Fortunately in real Netfilter policies the behavior is deter- Recall that we have two kinds of rules that are translated ministic, as the order in which the system administrator writes differently depending on the list of rules they belong to: the rules reflects the option he is willing to take. With this in mind we can force our configurations also to be deterministic Basic rules tab (keeping the overlapping part only in the option that we want (IP1:p1, IP2:p2, φ, t) ∈ Lchain is translated into to enforce). A configuration is said deterministic if for every iptables -t tab -A chain -s IP1 --sport p1 -d IP2 0 --dport p2 φ -j t packet p, state s, if p, s|=C DNAT(nt) and p, s|=C DNAT(nt) then n = n0 . Similarly for SNAT. t t Translation rules These conditions require that whenever there are two (IP1:p1, IP2:p2, φ, nt) ∈ T nat is translated into matching NAT rules of the same type, they have the same δ target. Similarly to enforcing well-formedness, this can be syn- iptables -t nat -A δ -s IP1 --sport p1 -d IP2 --dport p2 φ -j DNAT --to-destination nt tactically enforced (although more restrictively) by checking 0 0 0 nat that either n1 ∩ n1 = ∅ or n2 ∩ n2 = ∅ or nt = nt, whenever (IP1:p1, IP2:p2, φ, nt) ∈ T is translated into 0 0 0 0 σ rules n1 > [n2] nt | φ and n1 > [n2] nt | φ are in C (analogous 0 0 0 0 1 for rules n1 [nt] > n2 | φ and rn1 [nt] > n2 | φ ). Available for download at the address https://github.com/secgroup/Mignis

10 INTERFACES nets mapping. It has 3 columns: interface alias (used lan eth0 10.0.0.0/24 ext eth1 0.0.0.0/0 in the rules), real interface name, and subnet in the XXX.XXX.XXX.XXX/N form; ALIASES mypc 10.0.0.2 ALIASES: generic aliases used to avoid repeating IP ad- router_ext_ip 1.2.3.4 dresses; malicious_host 5.6.7.8 FIREWALL: rules written in the firewall language; FIREWALL lan [.] > ext The configuration presented in Table V is common amongst lan / malicious_host home users: ext > [router_ext_ip:8888] mypc:8888 tcp * > local:22 tcp lan [.] > ext specifies that from the lan it is allowed TABLE V. EXAMPLE OF A FIREWALL CONFIGURATION. to access the Internet, using a SNAT with dynamic address (masquerade); lan / malicious_host forbids any pc in the lan to iptables -t nat -A σ -s IP1 --sport p1 -d IP2 --dport p2 communicate with the malicious host; φ -j SNAT --to-source nt ext > [router_ext_ip:8888] mypc:8888 tcp allows incoming tcp connections on port 8888 that are There are a few special cases that we discuss below: forwarded to mypc, i.e., 10.0.0.2; (1) We allow for protocol specification out of φ as this is * > local:22 tcp allows for ssh connections to the more readable and handy when specifying real policies. local host. For example lan [proxy] > ∗ : 443 tcp specifies that The execution of MIGNIS consists of several steps: (i) Netfilter 443 lan can connect to any other host on https port via is reset; (ii) default policies and some default rules are applied: tcp protocol. This is also useful to more precisely detect these allow the router to initiate external connections, receive possible overlaps of rules as it allows MIGNIS to discrim- pings, and broadcast traffic which is usually considered safe inate on the filtered protocols. Protocol specifications are (but can be switched-off if needed); (iii) firewall language -p protocol translated as and are placed before any rules are translated into iptables rules; (iv) rules that --sport --dport occurring filter on ports ( or ). This guarantee that each IP address will originate only from its iptables is required in syntax since filters on ports are assigned interface are added. This makes equivalent, from protocol-specific; a security perspective, to specify interfaces or addresses as (2) iptables does not allow to specify arbitrary sets of sources and destinations; (v) log rules are added. addresses. In MIGNIS we have added the possiblity of defining lists of addresses and protocols that are pre- MIGNIS reports that two overlapping rules have been de- compiled into sets of MIGNIS rules which, in turns, are fined: lan / malicious_host and lan [.] > ext. translated into iptables, as specified above. We have In fact the former aims at blacklisting malicious_host also developed a ‘smart’ translation of set exclusion which which is part of ext. Overlapping information is quite useful is not treated in the formal model yet but might be with big configurations to point out possible redundancies and accounted for in future work. For example it is possible mistakes. For lack of space, the output of MIGNIS is reported to specify lan \ h1 to match all hosts in lan except h1. in Table VII of the Appendix. (3) the usage of orig(p) 0s and orig(p) `s respec- man fil A. Real case-study tively in LPRE and LFOR was just for convenience in the exposition as these could be written respec- In this section we describe how our theory and tool have tively as -m state --state NEW and -m state been applied to a real system, i.e., the --state ESTABLISHED. If one of the address com- of the department of Enviromental Sciences, Informatics and ponents is a wildcard ∗ (e.g., no source port is specified) Statistics of the Ca’ Foscari University, Venice. Sensitive the corresponding option is removed; informations were abstracted out or otherwise anonymised. (4) In SNAT, when there is no translation address we use the The network is part of a larger university network and is, in target MASQUERADE that dynamically picks the address turn, composed of 3 subnetworks, each of them with different for the interface through which the packets are going out. purposes and configurations. We identify the following entities: Rule (IP1:p1, IP2:p2, φ, ) ∈ T nat is translated into σ • The whole university network, denoted by U, which is not iptables -t nat -A σ -s IP1 --sport p1 -d IP2 --dport p2 under our direct control. φ -j MASQUERADE • The main departmental network, denoted by D. (5)M IGNIS additionally allows users to specify interfaces • The laboratory network, denoted by L instead of addresses. In this case the translation is done • A recently-allocated network which will be used mostly -i -o using options (input interface) and (output inter- by personal clients, denoted by C. face), as it is shown later on, rather than -s and -d. • The firewall F, which acts as a router between D,L, C Firewall configuration: In Table V we present a simple and U, and is also connected to the Internet through other example of a configuration file. It is composed of different routers. sections. We describe the most relevant ones: The are about 350 active hosts on D,L and C, plus a varying INTERFACES: the list of the router interfaces and sub- number of temporary or guest’s hosts.

11 # Transparent proxy for lab hosts. As it is common for real systems, these networks are labs > [ext:80] proxy:8080 tcp not strictly compartmentalised according to the purpose and labs [F] > proxy tcp to the security requirements of the hosts, due to historical, # https requests should appear from the same source labs [proxy] > *:443 tcp economical and technical constraints. In particular, D is a mixed network, in which servers and faculty members’ clients, # acting as a DHCP server which are not yet moved to C, coexists. Network L is also (D,L,C):68 <> local:67 udp partially mixed, because it contains both lab clients and servers # acting as a multicast router (using xorp) which are used mainly by students. All the aforementioned (*,local) <> multicast all * > local (igmp,pim,udp) | -d multicast networks support multicast transmissions, and are integrated in local > * (igmp,pim,udp) | -s multicast a broader multicast system, used mainly for audio and video # as a policy, we want to notify rejection transmissions, which is managed by the university. This setting # for unallowed outgoing tcp connections leads to a quite complex firewall configuration, which is rich POLICIES of exceptions for single hosts or classes of those. (D,L,C) // ext tcp The original firewall configuration, as a sequence of hand- TABLE VI. SNIPPETS OF CONFIGURATION FROM THE CASE STUDY. crafted iptables commands, was 610 lines long (counting only the commands themselves), with 5 custom chains. After a careful translation, we produced a 210 lines long MIGNIS this is not relevant, which makes specifying and maintaining configuration which was able to match the behaviour of the a firewall much simpler. We gave a formal semantics for previous firewall, and which was subsequently used as our this language, and showed that under reasonable conditions, actual firewall configuration. In a second phase, using both firewall policies expressed in our language can be translated the overlap-detecting capabilities of MIGNIS, analysing the into the proposed Netfilter model in a way that preserves more readable configuration, and using the information given packet filtering and address translation. by the annotated logs, we were able to further reduce the The theoretical results of this work were implemented in configuration to 141 MIGNIS lines, which were translated into 472 iptables commands. Some overlapping warning MIGNIS a novel, publicly available tool which translates a were ignored in order to increase the readability and the high-end firewall specification expressed in our declarative maintainability of the configuration, thus the configurations language into real iptables rules. We also described some could be further reduced in size by approximately 30 lines, real-world applications of this tool, including a case study without changing its semantics. To this day, the department given by the actual firewall configuration of a University firewall runs on this latter configuration. department, and we showed how the static analysis capabilities of the can help to spot errors in firewall policies and In Table VI we give some snippets of the actual configu- to reduce the complexity of their specifications, e.g., detecting ration, in which some non-trivial rules are shown. Notice the overlaps. straightforward way of expressing transparent proxy and https- passthrough rules, which translate in at least 7 iptables While we were not the first ones presenting a language that rules. In fact, since labs is defined as an alias for a list simplifies firewall specification, to the best of our knowledge of aliases of 5 disjoint IP ranges, this would have required our model is the first that provides correctness guarantees about 35 lines. The rules for the DHCP server are bidirectional, the generated configuration. in order to allow for all the steps of protocol handshaking. We believe this work may have impact in several com- Another interesting example is given by the rules to allow munities. From a practical perspective we allow practitioners the firewall to act as a multicast router, in which packets to specify firewall configurations in a simple understandable not going to or coming from a local address are still seen language with single-step semantics, and to generate the list in the INPUT and OUTPUT chain, respectively. Notice that of rules that implements that configuration in Netfilter. For this requires some extra options to be passed to iptables. theoreticians we propose a formalization of the behavior of a The last example shows the specification of a REJECT policy firewall that is amenable to verification of the intended security for some network. The intended behaviour is to immediately properties. notify applications running in networks behind the firewall that With respect to future work, we are considering further the desired connection is not allowed, thus sparing the need to possible optimizations of the specification language and of wait for a timeout. its translation. Since in our specification language the rule order is not relevant, it is possible to automatically rearrange VII.CONCLUSIONS the underlying Netfilter rules according to the statistics on In this paper we addressed the problem of simplifying the packet matching provided by Netfilter itself. This could lead to specification, management and analysis phases of a firewall performance improvements for firewalls managing very intense system. In order to do so, we first proposed an abstract model traffic. Experiments on this topic are ongoing, using the system for Netfilter, that is rich enough to capture the concepts of described in the case study. Another future work regards the chains, rules, and packets. We then provided a multi-step extension of MIGNIS to allow for the translation into rules for semantics for this model that emulates real Netfilter executions. firewall systems different from Netfilter but having a similar semantics, exploiting an opportunely modified abstract model. We introduced a simple, yet expressive, declarative lan- guage to specify firewall configurations. Contrary to concrete Acknowledgements:: The authors would like to thank implementations, where the order in which rules are written is David Aspinall and James Cheney for their valuable com- crucial to determine the behavior of the system, in our language ments on earlier versions of this work. This work was par-

12 tially supported by FCT projects ComFormCrypt PTDC/EIA- [29] S. Morrissey, G. Grinstein, and B. Keyes. Developing multidimensional CCO/113033/2009 and PEst- OE/EEI/LA0008/2011. firewall configuration visualizations. In Proc. of the 2010 International Conference on Information Security and Privacy. ISRT, 2010. [30] S. Pozo, R. Ceballos, and R. M. Gasca. Afpl, an abstract language REFERENCES model for firewall acls. In Proc. of the international conference on Computational Science and Its Applications, Part II, ICCSA ’08, pages [1] High level firewall language. http://www.hlfl.org, 2003. 468–483. Springer-Verlag, 2008. [2] . http://www.fs-security.com/, 2007. [31] R. M. Marmorstein. Formal Analysis of Firewall Policies. PhD thesis, [3] Kmyfirewall. http://www.kmyfirewall.org/, 2008. College of William and Mary, Williamsburg, VA, May 2008. [4] Ipfilter. http://coombs.anu.edu.au/∼avalon/, 2009. [32] R. Russell. Linux 2.4 packet filtering howto. http://www.netfilter.org/ documentation/HOWTO/packet-filtering-HOWTO.html, 2002. [5] Netspoc: A network security policy compiler. http://netspoc.berlios.de, 2011. [33] T. Tran, E. Al-Shaer, and R. Boutaba. Policyvis: Firewall security policy visualization and inspection. In Proc. of the 21st Large Installation [6] Pyroman. http://pyroman.alioth.debian.org/, 2011. System Administration Conference (LISA ’07), pages 1–16. Usenix [7] Rule markup language. http://www.ruleml.org/, 2011. association, 2007. [8] Firewall builder. http://www.fwbuilder.org/, 2012. [34] J. Walsh. Icsa labs firewall testing: An in depth anal- [9] Frenetic, a family of network programming languages. http://www. ysis. http://bandwidthco.com/whitepapers/netforensics/penetration/ frenetic-lang.org/, 2013. Firewall%20Testing.pdf, 2004. [35] B. Zhang, E. Al-Shaer, R. Jagadeesan, J. Riely, and C. Pitcher. Specifi- [10] Oasis extensible access control markup language. http://xacmlinfo.org/ cations of a high-level conflict-free firewall policy language for multi- category/xacml-3-0/, 2013. domain networks. In Proc. of ACM Symposium on Access Control [11] Packet filtering. http://www.openbsd.org/faq/pf/filter.html, 2013. Models and Technologies (SACMAT 2007). ACM, 2007. [12] Uncomplicated firewall. https://help.ubuntu.com/community/UFW, 2013. APPENDIX [13] Chef. http://www.getchef.com/chef/, 2014. [14] Iptables made easy, shorewall. http://www.shorewall.net/, 2014. Throughout this Appendix we will use p, s|=ri instead of [15] LCFG large scale unix configuration system. http://www.lcfg.org/, 2014. |=C whenever we need to make explicit which rule ri ∈ C [16] pfSense, a proven open source firewall. http://www.pfsense.org/, 2014. is satisfied. It is defined in the same way as |=C , that is, p, s|=r iff sa(p) ∈ n , da(p) ∈ n , and φ(p, s) whenever [17] With puppet enterprise, you pull the strings. http://puppetlabs.com/, i 1 2 2014. ri = n1 / n2 | φ or ri = n1 > n2 | φ or ri = n1 > [n2] nt | φ [18] C. J. Anderson, N. Foster, A. Guha, J.-B. Jeannin, D. Kozen, or ri = n1 [nt] > n2 | φ. C. Schlesinger, and D. Walke. Netkat: Semantic foundations for networks. In Proc. of the 41st ACM SIGPLAN-SIGACT Symposium Restatement of Lemma 1. Let C be an abstract firewall on Principles of Programming Languages (POPL 2014), to appear. configuration and FI the intermediate firewall obtained by ACM, 2014. the translation presented in Table IV. Then for any state s and [19] Y. Bartal, A. Mayer, Nissim, and A. Wool: Firmato. A Novel Fire- packet p we have that: wall Management Toolkit. ACM Transactions on Computer Systems, 22(4):1237–1251, 2002. (i) p, s|=il iff p, s|= NAT( ) SDNAT nt C D nt [20] F. Cuppens, N. Cuppens-Boulahia, J. Garca-Alfaro, T. Moataz, and (ii) p, s|=il n iff p, s|= SNAT(n ) X. Rimasson. Handling stateful firewall anomalies. In SEC, volume SSNAT t C t 376 of IFIP Advances in Information and Communication Technology, il (iii) p, s6|=S iff p, s6|=C DROP. pages 174–186. Springer, 2012. D [21] F. Cuppens, N. Cuppens-Boulahia, T. Sans, and A. Miege.` A formal Proof: We will analyze all possible cases. approach to specify and deploy a network security policy. In Formal Aspects in Security and Trust (FAST’04), pages 203–218, 2004. p, s|=il n SDNAT t [22] A. El-Atawy, T. Samak, Z. Wali, E. Al-Shaer, F. Lin, C. Pham, and S. Li. il iff ∃(n1, n2, φ, nt) ∈ SDNAT . p, s|= (n1, n2, φ, nt) An automated framework for validating firewall policy enforcement. SDNAT In Proc. of the Eighth IEEE International Workshop on Policies for iff ∃(n1, n2, φ, nt) ∈ SDNAT . sa(p) ∈ n1 ∧ da(p) ∈ n2 ∧ φ(p, s) Distributed Systems and Networks (POLICY’07), pages 151–160. IEEE, iff ∃n1 > [n2] nt | φ ∈ C . sa(p) ∈ n1 ∧ da(p) ∈ n2 ∧ φ(p, s) 2007. iff p, s|=C DNAT(nt) [23] T. Gobel¨ F. Mansmann and W. Cheswick. Visual analysis of complex firewall configurations. In Proc. of the Ninth International Symposium All steps follow from the definitions except from the third to on Visualization for Cyber Security, VizSec’12, pages 1–8. ACM, 2012. the forth step. For this step: (⇒) follows because the set of [24] M.G. Gouda and A.X. Liu. Structured firewall design. Comput. Netw., rules SDNAT is the least satisfying the rules of Table IV and 51(4):1106–1120, March 2007. DNAT rules are the only rules translated to SDNAT; and (⇐) [25] A. Jeffrey and T. Samak. Model checking firewall policy configurations. follows as all DNAT rules in C are translated to a rule in In Proc. of the 2009 IEEE International Symposium on Policies for SDNAT. Distributed Systems and Networks (POLICY ’09), pages 60–67. IEEE Computer Society, 2009. p, s|=il n SSNAT t [26] A.X. Liu and M.G. Gouda. Diverse Firewall Design. IEEE Transactions il iff ∃(n1, n2, φ, nt) ∈ SSNAT . p, s|= (n1, n2, φ, nt) on Parallel and Distributed Systems, 19(9):1237–1251, 2008. SSNAT iff ∃(n1, n2, φ, nt) ∈ SSNAT . sa(p) ∈ n1 ∧ da(p) ∈ n2 ∧ φ(p, s) [27] S. Mart´ınez, J. Cabot, J. Garcia-Alfaro, F. Cuppens, and N. Cuppens- Boulahia. A model-driven approach for the extraction of network iff ∃n1 [nt] > n2 | φ ∈ C . sa(p) ∈ n1 ∧ da(p) ∈ n2 ∧ φ(p, s) access-control policies. In Proc. of the Workshop on Model-Driven iff p, s|=C DNAT(nt) Security, MDsec ’12, pages 5:1–5:6. ACM, 2012. [28] S. Morrissey and G. Grinstein. Visualizing firewall configurations using The justification is the same as in the previous case noticing created voids. In Proc. of the Int. Workshop on Visualization for Cyber now that (⇒) the set of rules SSNAT is the least satisfying the Security. ACM, 2009. rules of Table IV and SNAT rules are the only rules translated

13 # Default policies iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP iptables -t mangle -P PREROUTING DROP

# Mandatory rules iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Default rules # - Loopback iptables -A INPUT -i lo -j ACCEPT # - Invalid packets iptables -t mangle -A PREROUTING -m state --state INVALID,UNTRACKED -j DROP # - Broadcast traffic iptables -A INPUT -d 255.255.255.255 -j ACCEPT iptables -t mangle -A PREROUTING -d 255.255.255.255 -j ACCEPT # - Multicast traffic iptables -A INPUT -d 224.0.0.0/4 -j ACCEPT iptables -t mangle -A PREROUTING -d 224.0.0.0/4 -j ACCEPT

## Rules # lan / malicious_host iptables -A FORWARD -i eth0 -d 5.6.7.8 -j DROP # * > local:22 tcp iptables -A INPUT -p tcp --dport 22 -j ACCEPT # ext > [router_ext_ip:8888] mypc:8888 tcp iptables -t mangle -A PREROUTING -p tcp -i eth1 -d 10.0.0.2 --dport 8888 -m state --state NEW -j DROP iptables -A FORWARD -p tcp -i eth1 -d 10.0.0.2 --dport 8888 -j ACCEPT iptables -t nat -A PREROUTING -p tcp -i eth1 -d 1.2.3.4 --dport 8888 -j DNAT --to-destination 10.0.0.2:8888 # lan [.] > ext iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth1 -j MASQUERADE

# IP/IF bind iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.0/24 -j ACCEPT iptables -t mangle -A PREROUTING -i lo -j ACCEPT iptables -t mangle -A PREROUTING -i eth1 -s 10.0.0.0/24 -j DROP iptables -t mangle -A PREROUTING -i eth1 -s 127.0.0.0/8 -j DROP iptables -t mangle -A PREROUTING -i eth1 -j ACCEPT

# Log iptables -t mangle -N mangle_drop iptables -t mangle -N mangle_drop_icmp iptables -t mangle -A mangle_drop_icmp -j LOG --log-prefix "MANGLE-DROP-ICMP " ...

TABLE VII. TRANSLATION OF THE CONFIGURATION OF TABLE V.

to SSNAT; and (⇐) follows as all SNAT rules in C are translated Proof: to a rule in SSNAT. 0 p,p 0 0 (il ⇒ hl) Suppose that s −→il s for some states s, s and p, s6|=il 0 SD packets p, p . We will analyze all possible cases and verify that il 0 iff ∀(n1, n2, φ, ·) ∈ SD . p, s6|=S (n1, n2, φ, ·) p,p 0 D we also have s −→hl s . iff ∀(n1, n2, φ, ·) ∈ SD . sa(p) ∈/ n1 ∨ da(p) ∈/ n2 ∨ ¬φ(p, s) iff ∀n1 / n2 | φ ∈ C . sa(p) ∈/ n1 ∨ da(p) ∈/ n2 ∨ ¬φ(p, s) We analyze first the cases where one applied the rule iff ∀n1 / n2 | φ ∈ C . p, s6|=n1 / n2 | φ [Extil ], that is, sa(p) 6∈ L or da(˜p) 6∈ L, and identify the iff p, s6|=C DROP differences to the case [Localil ] afterwards.

Again, except from the third to the forth step, all other steps [Case p `s]: Suppose that (A1) p `s src, dst for some follow from the definitions. For this step: (⇒) follows as all src, dst. In this case s0 = s.2 negative rules in C are translated to a rule in SD; (⇐) follows DNAT By [Extil ] one has (B1)(s, p) il p˜, for some p˜, because the set SD is the least satisfying the rules of Table IV (C )p, ˜ s6|=il , and (D )(s, p, p˜) SNAT p0. 1 SD 1 il and n1 / n2 | φ are the only rules translated to SD. (A1) together with (B1) and (D1) imply that the rules DNAT SNAT Restatement of Theorem 2. Let C be an abstract firewall used in il and il were necessarily [DEstil ] and [SEstil ], 0 configuration and FI the intermediate firewall obtained by the and so p˜ = p[da 7→ src] and p =p ˜[sa 7→ dst] = p[da 7→ translation presented in Table IV. Then for any states s, s0 and src, sa 7→ dst]. packets p, p0 we have that: By (C1) and Lemma 1 it follows that p,˜ s6|=C DROP and so 0 0 0 p,p p,p 0 p,p 0 [ ST ] s −→ s (i) if s −→il s then s −→hl s ; one gets by E hl that hl .

(ii) if C is well-formed, nat-consistent, has no local SNAT 2 0 0 When analyzing each case i within a proof we will use consistently the p,p 0 p,p 0 rules, and s −→hl s then s −→il s . notation (Ai), (Bi),... to denote its hypothesis.

14 0 0 0 0 • For the case [Localil ] the proof is exactly the same as there is a rule rs = (n1, n2, φ , t ) ∈ SSNAT such that p,˜ s|=r rs. 0 0 0 0 we have the same hypothesis (A1)–(D1). By definition of translation there is a rule n1 [t ] > n2 | φ in 0 0 0 0 C and from p,˜ s|=r rs it follows that p,˜ s|=n1 [t ] > n2 | φ . [Case p ]: Suppose now that (A ) p . In this case s0 = 0s 2 0s The result follows using [DSNAThl ] recalling that by (E2) s ] (p, p0). We will show that in all possible cases (s, p) ↓hl p0 hl 0 we have p,˜ s6|=C DROP. We have then that (s, p) ↓ p˜[sa 7→ p,p 0 and conclude s −→hl s using [NEWhl ]. addrs] = p[da 7→ addrd, sa 7→ addrs]. il 0 It follows from (A2) and [Extil ] that (B2) p, s6|=S , —For p 6=p ˜ = p the proof is a combination of the D1 0 (s, p) DNAT p˜, (C )p, ˜ s6|=il , (D )p, ˜ s|=il , previous two cases. First notice that as in case p 6=p ˜ 6= p one il 2 SD 2 SA SNAT 0 necessarily used [DNATil ] and consequently there is a rule in and (s, p, p˜) il p . C such that p, s|=n1 > [n2] t | φ and p˜ = p[da 7→ addrd] for Before analyzing all possible cases we observe that from addrd ∈ t. (C2) and Lemma 1 we get (E2)p, ˜ s6|=C DROP. SNAT 0 0 For (s, p, p˜) il p , as in the case p =p ˜ = p , we can Moreover, and since by (A2) we have that p 0s, we use either [SNewil ] or [SNATil ]. If [SNewil ] was applied, then (s, p) DNAT p˜ = p (F ) p, s6|=il hl claim that if il then 2 SDNAT and p,˜ s6|=C SNAT and (s, p) ↓ p˜ by [DNAThl ] as by (E2) we have one necessarily applied rule [DNewil ]. If not, suppose that p,˜ s6|=C DROP. If [SNATil ] was applied, then there is a rule in one applied rule [DNAT ], that is, p, s|=il t for some rule 0 0 0 0 0 il SDNAT C such that p,˜ s|=n1 [t ] > n2 | φ and p =p ˜[sa 7→ addrs] 0 hl 0 (n1, n2, φ, t) ∈ SDNAT and da(˜p) = da(p) = addrd ∈ t. It for addrs ∈ t . In this case (s, p) ↓ p by [DSNAThl ] as by follows by definition of correct translation (Table IV) that there (E2) we have p,˜ s6|=C DROP. is also a rule (n1, t, φ, DROP) ∈ SD1 . But this contradicts our 0 il —For p =p ˜ 6= p the proof is the same as in the branch hypothesis as from (B2) one has that p, s6|=S and in our case 0 D1 [SNATil ] of the case p =p ˜ = p . we have sa(p) ∈ n1, da(p) = da(˜p) ∈ n2 ∩ t, and φ(p, s). 0 il • For the case [Localil ] the proof is exactly the same as —Consider first p =p ˜ = p . By (F2) we have p, s6|= SDNAT we have the same hypothesis (A2)–(D2). which implies by Lemma 1 that p, s6|=C DNAT. Recall that since p˜ = p we also have by (E2) that p, s6|=C DROP. We have two SNAT 0 (hl + ⇒ il) Suppose that C is a well-formed configuration subcases: either (s, p, p) il p by [SNewil ] or by [SNATil ]. p,p0 il 0 If [SNewil ] was applied, then p, s6|= and one has by with no matching SNAT rules for local packets, and s −→hl s SSNAT 0 0 SNAT DNAT for some states s, s and packets p, p . We will analyze all Lemma 1 that p, s6|=C . Since we also have p, s6|=C 0 p,p 0 it follows that p, s6|=C nat. possible cases and verify that we also have s −→il s . Now, from (D ) and p =p ˜ it follows that p, s|=il r for 2 SA a We analyze again the cases where sa(p) 6∈ L or da(˜p) 6∈ L, some rule ra = (n1, n2, φ, ACCEPT) ∈ SA. By definition and identify the differences to the case where sa(p) ∈ L and of the translation this rule was obtained either by (i) the da(˜p) ∈ L afterwards. translation of n1 > n2 | φ, and in this case p, s|=n1 > n2 | φ 0 0 hl [ESThl ]: In this case s = s and p = p[da 7→ src, sa 7→ and (s, p) ↓ p follows by [ACCEPThl ]; or by (ii) the dst] for some src, dst. We have as hypothesis that p `s translation of n1 [nx] > n2 | φ for some nx, but this case src, dst and p[da 7→ src], s6|=C DROP. is not possible as we have just seen that p, s6|=C SNAT; or by + + (iii) the translation of n1 > [nx] n2 | φ for some nx and φ From p `s src, dst it follows immediately that p `s (φ+)? = φ ∨ p, s6|=il and p ` ∨ p,˜ s|=il ; and by [DEst ] and [SEst ] such that . In this case we also have that there is SD s SA il il a rule r = (n , n , φ+, DROP) ∈ S . But by definition of 1 DNAT m 1 2 D1 it follows respectively that (s, p) il p˜ = p[da 7→ src], and φ?, and since n > [n ] n | φ+ ∈ C and da(p) ∈ n , we have SNAT 0 1 x 2 2 (s, p, p˜) il p =p ˜[sa 7→ dst] = p[da 7→ src, sa 7→ dst]. that φ+(p, s) iff (φ+)?(p[da 7→ da(p)], s) that is equivalent il il By Lemma 1, p[da 7→ src], s6|=C DROP, and p˜ = p[da 7→ to φ(p, s). Hence p, s|= ra iff p, s|= rm and so this third SA SD1 il src] it follows that p,˜ s6|=S . case is also not possible as it contradicts (B2). D p,p0 [SNAT ] p, s|=il t0, addr ∈ 0 Putting all these together we obtain by [Ext ] that s −→ If il was applied, then SSNAT s t and il il 0 0 0 0 there is a rule rs = (n1, n2, φ , t ) ∈ SSNAT such that p, s|=r rs. s. 0 0 By definition of correct translation there is a rule n1 [t ] > 0 0 0 0 0 0 • For the case where both sa(p), da(˜p) ∈ L the proof is n2 | φ ∈ C and consequently p, s|=n1 [t ] > n2 | φ . In this hl equal to the previous one but in order to apply the [Localil ] rule case (s, p) ↓ p[sa 7→ addrs] follows by [SNAThl ]. we still have to show that (i) p ` ∨ p0, s6|=il , (ii) p0, s6|=il , s SD SD 0 1 —Consider now p 6=p ˜ 6= p . Since by (A2) p s, this and (iii) p ` ∨ p0, s|=il hold for p0. The first and last 0 s SA implies that one used rules [DNATil ] and [SNATil ] that is disjunctions follow by hypothesis p `s. As for (ii) notice that p, s|=il t addr ∈ p˜ = p[da 7→ addr ] SDNAT , d t, and d , and by hypothesis there is no SNAT rules matching local packets, p,˜ s|=il t0 addr ∈ 0 p0 =p ˜[sa 7→ addr ] SSNAT , s t , and s . We will hence we use [SNewil ] instead of [SEstil ], and obtain that show that this case is an instance of [DSNAT ]. p0 =p ˜. Since p,˜ s6|=il was proved earlier, the results follows hl SD p, s|=il t addr ∈ r = by [Localil ]. Since SDNAT and d t, there is a rule d (n1, n2, φ, t) ∈ SDNAT such that p, s|=r rd. By definition of 0 correct translation there is a rule n1 > [n2] t | φ ∈ C and p,p 0 [NEWhl ]: Consider now that s −→hl s](p, p ) by [NEWhl ]. from p, s|=r rd it follows that p, s|=n1 > [n2] t | φ. hl 0 We have as hypothesis that (a) p 0s and (b)(s, p) ↓ p . We p,˜ s|=il t0 addr ∈ 0 Similarly for SNAT. Since SSNAT and s t , will analyse all possible cases and verify that we also have

15 0 p,p 0 (ii) p0, s6|=il , and (iii) p ` ∨ p0, s|=il hold for p0. The last s −→il s ] (p, p ). SD s SA two follow as p0 =p ˜ and they were already checked for p˜. We start by claiming that if C is well-formed and p, s|=ri The first follows as we have seen above that p,˜ s|=il , hence il SA for some rule ri ∈ C then (c) p, s6|=S . Suppose the il 0 D1 by (c) one has that p,˜ s6|= . Since p =p ˜ we conclude the il SD1 contrary, that is, p, s|=S . In this case there is a rule D1 proof by [Localil ]. (n1, nt, φ, DROP) ∈ SD1 such that sa(p) ∈ n1, da(p) ∈ nt, 0 and φ(p, s), and by definition of correct translation there is a [SNAThl ]: In this case we have p = p[sa 7→ addrs] rule n1 > [n2] nt | φ in C for some n2. This contradicts the for some addrs ∈ nt and, by hypothesis, well-formedness of C. (a3) p, s|=n1 [nt] > n2 | φ, (b3) p, s6|=C DNAT, and Let us then analyze all possible cases for ↓hl . (c3) p, s6|=C DROP. Since by (a3) p, s|=n1 [nt] > n2 | φ, we have by (c) that 0 il [ACCEPThl ]: In this case p = p and we have by p, s6|= . SD1 hypothesis (a1) p, s|=n1 > n2 | φ, (b1) p, s6|=C nat, and Notice that by (b3) there is no matching DNAT rule for (c1) p, s6|=C DROP. il p, s and so by Lemma 1 it follows that p, s6|=S that together DNAT DNAT Since by (a1) p, s|=n1 > n2 | φ, we have by (c) that with (a) and [DNewil ] implies (s, p) p˜ = p. il il p, s6|=S . D1 Also, by Lemma 1, (c ), and p˜ = p it follows that p,˜ s6|=il . 3 SD By Lemma 1, (c ) and (b ) it follows respectively 1 1 Since by (a ) n [n ] > n | φ ∈ C we get by the trans- that p, s6|=il , p, s6|=il , and p, s6|=il , and so together 3 1 t 2 SD SDNAT SSNAT lation that (n , n , φ, ACCEPT) ∈ S and by (a ) and p˜ = p with (a) one can apply [DNew ] and [SNew ] to obtain 1 2 A 3 il il that p,˜ s|=il . DNAT SNAT 0 SA (s, p) il p˜ = p and (s, p, p) il p = p. il Finally by Lemma 1 and (a3) it follows that p, s|= nt, Since by (a1) n1 > n2 | φ ∈ C we get by the translation SSNAT and so together with (a) one can apply [SNATil ] to obtain that (n1, n2, φ, ACCEPT) ∈ SA and together with (a1) that SNAT 0 p, s|=il . (s, p, p) il p = p[sa 7→ addrs] with addrs ∈ nt. SA 0 0 p,p p,p Putting all these together we obtain by [Extil ] that s −→il Putting all these together we obtain by [Extil ] that s −→il 0 s ] (p, p0). s ] (p, p ). • For the case where both sa(p), da(˜p) ∈ L notice that • For the case where both sa(p), da(˜p) ∈ L notice that 0 0 0 il we also have p =p ˜ as by hypothesis there is no SNAT p =p ˜ = p and the extra conditions (i) p `s ∨ p , s6|= , SD1 0 il 0 il rule matching local packets (hence we use [SNewil ] instead (ii) p , s6|= , and (iii) p `s ∨ p , s|= were already proved 0 SD SA of [SEstil ]). Then, p =p ˜ = p and the justification is the same for p and p˜. The proof follows by [Local ]. il as in the case [ACCEPThl ].

0 0 [DNAThl ]: In this case we have p = p[da 7→ addrd] [DSNAThl ]: In this case p = p[da 7→ addrd, sa 7→ 0 for some addrd ∈ nt and we have by hypothe- addrs] for addrd ∈ nt and addrs ∈ nt and we have by 0 sis (a2) p, s|=n1 > [n2] nt | φ, (b2) p , s6|=C DROP, and hypothesis (a4) p, s|=n1 > [n2] nt | φ, p˜ = p[da 7→ addrd], 0 0 0 0 (c2) p , s6|=C SNAT. (b4)p, ˜ s6|=C DROP, and (c4)p, ˜ s|=n1 [nt] > n2 | φ.

Since by (a2) p, s|=n1 > [n2] nt | φ, we have by (c) that Since by (a4) p, s|=n1 > [n2] nt | φ, we have by (c) that p, s6|=il . p, s6|=il . SD1 SD1 (a ) p, s|=il n (a ) p, s|=il n By Lemma 1 and 2 it follows that SDNAT t, and By Lemma 1 and 4 it follows that SDNAT t, and so so together with (a) one can apply [DNATil ] which gives together with (a) one can apply [DNATil ] in order to obtain DNAT 0 DNAT (s, p) il p˜ = p[da 7→ addrd] = p with addrd ∈ nt. (s, p) il p˜ = p[da 7→ addrd] with addrd ∈ nt. 0 il Also, by Lemma 1, (b2), and p˜ = p it follows that Also, by Lemma 1 and (b4) it follows that p,˜ s6|=S . il D p,˜ s6|=S . D Since by (a4) n1 > [n2] nt | φ ∈ C we get by the trans- ? Since by (a2) n1 > [n2] nt | φ ∈ C we get by the trans- lation that (n1, nt, φ , ACCEPT) ∈ SA. Since by (a4) we also ? lation that (n1, nt, φ , ACCEPT) ∈ SA. Since by (a2) we also have that sa(˜p) = sa(p) ∈ n1, da(p) ∈ n2, and φ(p, s), and have that sa(˜p) = sa(p) ∈ n1, da(p) ∈ n2, and φ(p, s), and by construction da(˜p) = addrd ∈ nt, we have by definition of by construction da(˜p) = addr ∈ n , we have by definition of φ? that φ?(˜p, s) and consequently that p,˜ s|=il . d t SA φ? that φ?(˜p, s) and consequently that p,˜ s|=il . SA il 0 Finally by Lemma 1 and (c4) it follows that p,˜ s|= n , 0 SSNAT t Finally notice that by (c2) and p˜ = p there are no and so together with (a) one can apply [SNATil ] to obtain matching SNAT rules matching p,˜ s and so by Lemma 1 it SNAT 0 0 (s, p, p˜) il p =p ˜[sa 7→ addrs] with addrs ∈ nt. p,˜ s6|=il (a) [SNew ] follows SSNAT that together with and il implies 0 SNAT 0 p,p (s, p, p˜) il p˜ = p . Putting all these together we obtain by [Extil ] that s −→il 0 p,p0 s ] (p, p ). Putting all these together we obtain by [Ext ] that s −→ il il • sa(p), da(˜p) ∈ L s ] (p, p0). For the case where both notice that we also have that p0 =p ˜ as by hypothesis there is no SNAT • For the case where both sa(p), da(˜p) ∈ L it is left to rule matching local packets (hence we use [SNewil ] instead 0 il 0 show that the remaining conditions (i) p `s ∨ p , s6|= , of [SEst ]). Then, either p =p ˜ = p and the justification is SD1 il

16 0 il the same as in the case [ACCEPThl ], or p 6=p ˜ = p and the p, s|= t ⇒ p, s|= nat t. SDNAT TPRE justification is the same as in the case [DNAThl ] nat (iv) [SNAT]il : the reasoning is the same using TPOST and S Restatement of Proposition 3. Let F be a Netfilter firewall SNAT instead. and Ltab and T tab respectively a basic rule list and a transla- ch ch Restatement of Theorem 6. Let F be an intermediate tion rule list of chain ch and table tab. Define I firewall and F the Netfilter firewall obtained by the translation presented in Definition 9. Then for any states s, s0 and packets (i) Ltab = {r | r = (n , n , φ, t) ∈ Ltab ∧ n ∩ L 6= ∅}; INP 1 2 INP 2 p, p0 we have that: tab tab (ii) L UT = {r | r = (n1, n2, φ, t) ∈ L UT ∧ n1 ∩ L 6= ∅}; O O 0 0 tab tab p,p 0 p,p 0 (iii) LFOR = {r | r = (n1, n2, φ, t) ∈ LFOR ∧(n1∪n2)∩L = ∅} (i) if s −→ll s then s −→il s ; nat nat 0 0 (iv) Similarly for T and T . p,p 0 p,p 0 INP OUT (ii) if FI is deterministic and s −→il s then s −→ll s .

Then for ch = INP, OUT one has that p, s|=T tab t iff p, s|= tab t. ch Tch Proof: For ch = NP, UT, OR one has that p, s|= tab t iff p, s|= t. I O F L Ltab ch ch We do this proof analyzing rules [Forwardll ], [Inputll ], [Output ], and [Local ]. For DNAT and SNAT we rely on Proof: ll ll The proof is immediate verifying that the flows Lemma 5. in which each of these lists is applied satisfy exactly the tab tab We analyze first the case where one applied the rule conditions demanded in the transformations Lch and Tch . [Forwardll ], that is, sa(p) 6∈ L and da(˜p) 6∈ L, and identify Restatement of Proposition 4. Let C be a configuration the differences to the other cases afterwards. 0 and FI the intermediate firewall obtained by the translation p,p 0 (ll ⇒ il) Suppose that s −→ll s ] (p, p ) by presented in Table IV. PRE [Forward ], that is, (A) p, s|= man ACCEPT, (B)(s, p) ll LPRE ll Then C is deterministic iff FI is deterministic. p˜, (C)p, ˜ s|=Lman ACCEPT, (D)p, ˜ s|= fil ACCEPT, FOR LFOR POST 0 (E)p, ˜ s|= man ACCEPT, and (F )(s, p, p˜) p by LPOST ll Proof: The proof is immediate just noticing that r = hypothesis, and (G) orig(p) = orig(˜p) = orig(p0) = p by (n1, n2, φ, t) ∈ SDNAT iff rC = n1 > [n2] t | φ ∈ C, and construction. that p, s|=r iff p, s|=rC . Similarly for SSNAT. est Since all rules in SD have target DROP, if (A) is satisfied 1 man Restatement of Lemma 5. Let FI be an intermediate then the only matching rule in LPRE is (∗, ∗, >, ACCEPT) that is the last rule of the list and the only one not in Sest . Conse- firewall and F the Netfilter firewall obtained by the translation D1 est presented in Definition 9. Then for any state s and packets quently, for every rule (n1, n2, φ(p, s) ∧ orig(p) 0s, t) ∈ SD , 0 1 p, p,˜ p we have that: either sa(p) ∈/ n1 or da(p) ∈/ n2 or ¬φ(p, s) or orig(p) `s. But recall that by construction (n1, n2, φ(p, s) ∧ orig(p) s, t) ∈ DNAT 0 (i) for δ = PRE, OUT, if (s, p) δ p˜ then (s, p) p˜; Sest iff (n , n , φ(p, s), t) ∈ S , hence the above condition is ll il D1 1 2 D1 σ 0 SNAT 0 il (ii) for σ = POST, INP, if (s, p, p˜) ll p then (s, p, p˜) il p equivalent to p, s6|= ∨ orig(p) `s, that by (G) is equivalent SD1 Moreover, if F is deterministic we also have that: il I to p, s6|=S ∨ p `s. DNAT δ D1 (iii) for δ = PRE, OUT, if (s, p) il p˜ then (s, p) ll p˜; DNAT SNAT 0 σ 0 From Lemma 5 and (B) it follows that (s, p) il p˜. (iv) for σ = POST, INP, if (s, p, p˜) il p then (s, p, p˜) ll p Let us now look carefully at (D)p, ˜ s|= fil ACCEPT. By LFOR Proof: T nat = T nat T nat = T nat fil Since PRE OUT and POST INP, we will do construction, L is obtained by concatenation of any possible the proof just for cases T nat and T nat . FOR PRE POST ordering of the set SD with any possible ordering of the nat set S ∪ {(∗, ∗, orig(p) ` , ACCEPT)}, followed by a last We start by noticing that since TPRE is a particular ordering A s nat rule (∗, ∗, >, DROP). By (D), one has that (˜p, s) matches a of SDNAT, and TPOST a particular ordering of SSNAT, rules [DNew] and [SNew] behave the same way both in the IL rule si = (n1, n2, φ, ACCEPT) ∈ SA ∪ {(∗, ∗, orig(p) `s fil and LL semantics; also, since by construction p `s src, dst , ACCEPT)} as all other rules in LFOR have target DROP. Now, is deterministic the two semantics also behave the same way if s ∈ S it follows immediately that p,˜ s|=il ; if instead i A SA for [DEst] and [SEst]. We are then left to show the result for si = (∗, ∗, orig(p) `s, ACCEPT), then we have orig(˜p) `s, that rules [DNAT] and [SNAT]. by (G) is equivalent to p `s. Putting the two cases together il we get what we want p,˜ s|= ∨ p `s. (i) [DNAT]ll : if p, s|= nat t then it is immediate that SA TPRE p, s|=il t T nat S fil SDNAT as PRE is a particular ordering of the set DNAT Notice also that by the ordering of the rules in L , nat FOR and matching in the list TPRE implies necessarily matching p,˜ s|= fil ACCEPT implies that (˜p, s) did not match any of LFOR some rule of the set SDNAT. the rules in S and consequently p,˜ s6|=il . D SD nat (ii) [SNAT]ll : the reasoning is the same using TPOST and SNAT 0 Finally, from Lemma 5 and (F ) one has (s, p, p˜) il p . SSNAT instead. 0 p,p 0 We may conclude using [Extil] that s −→ll s ] (p, p ). (iii) [DNAT]il : notice that determinism enforces that when- ever there are two matching rules in SDNAT their target is the • For the case sa(p) 6∈ L and da(˜p) ∈ L, rule [Inputll ], man INP fil same. This ensures that the result is the same regardless of the proof is the same using LINP and ll instead of LFOR POST the order in which the rules are checked and so we have that and ll , as by construction these are the same. We conclude

17 p,p0 0 p,˜ s|= man ACCEPT. using [Extil ] that s −→ll s ] (p, p ). LPOST

• For the case sa(p) ∈ L and da(˜p) 6∈ L, rule [Outputll ], Finally, from Lemma 5, determinism, and (e) one has man OUT fil POST 0 the proof is also the same using L , ,L instead of (s, p, p˜) ll p . We may conclude using [Forwardll ] that OUT ll OUT 0 man PRE fil p,p 0 LPRE, ll ,LFOR, as by construction these are the same. We s −→ll s ] (p, p ). 0 p,p 0 conclude using again [Extil ] that s −→ll s ] (p, p ). • For the case sa(p) 6∈ L and da(˜p) ∈ L, the proof is the man INP fil POST • For the case where both sa(p), da(˜p) ∈ L, rule [Local ], same using LINP and ll instead of LFOR and ll . Notice ll fil the proof is the same as in the case [Outputll ] but in order to that in this case LINP = {(∗, ∗, >, ACCEPT)} and we trivially 0 il 0 apply [Localil ] we still have to show that (i) p `s ∨ p , s6|= , verify p , s|=Lfil ACCEPT. We conclude using [Inputll ] that SD1 INP 0 il 0 il 0 p,p0 (ii) p , s6|= , and (iii) p `s ∨ p , s|= hold for p . 0 SD SA s −→ll s ] (p, p ). We can do this using the extra hypothesis pro- • sa(p) ∈ L da(˜p) 6∈ L 0 For the case and , the proof is also vided by rule [Local ], that is, (iv) p , s|= man ACCEPT, man OUT fil man PRE ll LPRE 0 0 the same using LOUT, ll and LOUT instead of LPRE, ll and (v) p , s|=Lman ACCEPT, and (vi) p , s|= fil ACCEPT. p,p0 INP LINP fil 0 L . We conclude using [Outputll ] that s −→ll s ] (p, p ). In fact (iv) implies (i) by the same reason that FOR il • sa(p), da(˜p) ∈ L (A) p, s|= man ACCEPT implied p, s6|= ∨ p ` in the case For the case where both , the proof LPRE SD s 0 1 is the same as in case [Outputll ] but in order to apply of rule [Forwardll ]. Just use p instead of p and recall that 0 0 [Localll ] we still have to show that (i) p , s|=Lman ACCEPT, orig(p ) = orig(p) = p by (G). 0 0 PRE 0 (ii) p , s|= man ACCEPT, and (iii) p , s|= fil ACCEPT hold for p . LINP L Similarly (v) implies (iii) and (ii) by the same reason that INP il il We can do this using the extra hypothesis provided by rule (D)p, ˜ s|= fil ACCEPT implied p,˜ s|=S ∨ p `s and p,˜ s6|=S LFOR A D 0 il 0 il 0 [Localil ], that is, (iv) p `s ∨ p , s6|=S , (v) p , s6|=S , and in the case of rule [Forward ]. Just use p instead of p˜ and D1 D ll 0 il man fil 0 (vi) p ` ∨ p , s|= . s SA recall that LINP = LFOR and orig(p ) = orig(˜p) = p by (G). In fact (iv) implies (i) by the same reason that (a) p `s + il ∨ p, s6|= implied p, s|= man ACCEPT in the first case (il ⇒ ll) Let us now prove the converse. Suppose that SD LPRE 0 1 0 p,p 0 (sa(p) 6∈ L and da(˜p) 6∈ L). Just use p instead of p and FI is deterministic and that s −→il s ] (p, p ) by [Extil ] with 0 il recall that orig(p ) = orig(p) = p by (f). sa(p) 6∈ L and da(˜p) 6∈ L. That is, (a) p `s ∨ p, s6|= , SD1 (b)(s, p) DNAT p˜, (c)p, ˜ s6|=il , (d) p ` ∨ p,˜ s|=il , and Similarly (v) and (vi) implies (ii) by the same rea- il SD s SA SNAT 0 il il (e)(s, p, p˜) p . We also have by construction that son that (c)p, ˜ s6|=S , and (d) p `s ∨ p,˜ s|=S implied il D A 0 (f) orig(p) = orig(˜p) = orig(p0) = p. p,˜ s|= fil ACCEPT in that same first case. Just use p instead LFOR man fil 0 Suppose that p `s in (a). In this case there is no matching of p˜ and recall that LINP = LFOR and orig(p ) = orig(˜p) = p rule for (p, s) in Sest as by construction all formulas in the by (f). D1 rules of Sest are of the form φ(p, s)∧orig(p) and orig(p) = D1 0s p by (f). If instead we have by (a) that p, s6|=il then there SD1 is no matching rule in SD1 and consequently no matching rule in Sest , as all the rules in Sest are equal to the ones in D1 D1 SD1 but with a stronger condition. This implies that in both man cases the only rule in LPRE that matches (p, s) is the last one (∗, ∗, >, ACCEPT) and consequently p, s|= man ACCEPT. LPRE From Lemma 5, determinism, and (b) it follows that PRE (s, p) ll p˜. man Since LFOR = {(∗.∗.>, ACCEPT)}, it trivially follows that p,˜ s|= man ACCEPT. LFOR From (c) it follows that there is no matching rule for (˜p, s) in SD and so there is no matching DROP rule in the initial part fil of LFOR that is composed by all the rules in SD. Let us now look carefully at (d) p ` ∨ p,˜ s|=il . If s SA p,˜ s|=il then (˜p, s) matches a rule (n , n , φ, ACCEPT) in SA 1 2 fil SA (and LFOR) as all rules in SA have target ACCEPT. If instead p `s, and since orig(˜p) = p by (f), this implies that orig(˜p) `s and consequently (˜p, s) matches the rule fil (∗, ∗, orig(p) `s, ACCEPT) in LFOR. Putting the two cases together it follows that p,˜ s|= fil ACCEPT as we never reach LFOR fil the last rule of LFOR that is the only remaining DROP rule of fil LFOR. man Since the only rule in LPOST is (∗, ∗, >, ACCEPT) one has

18