FIREMAN: A Toolkit for FIREwall Modeling and ANalysis Lihua Yuan Jianning Mai Zhendong Su [email protected] [email protected] [email protected] Hao Chen Chen-Nee Chuah Prasant Mohapatra [email protected] [email protected] [email protected] University of California, Davis Abstract configurations. The wide and prolonged spread of worms, such as Blaster and Sapphire, demonstrated that many fire- Security concerns are becoming increasingly critical in walls were misconfigured, because “well-configured fire- networked systems. Firewalls provide important defense for walls could have easily blocked them” [31]. network security. However, misconfigurations in firewalls The following script illustrates how easily firewall mis- are very common and significantly weaken the desired se- configurations can happen: curity. This paper introduces FIREMAN, a static analysis toolkit for firewall modeling and analysis. By treating fire- accept tcp 192.168.0.0/16 any wall configurations as specialized programs, FIREMAN ap- deny tcp 192.168.1.0/24 any 3127 plies static analysis techniques to check misconfigurations, such as policy violations, inconsistencies, and inefficien- The second rule is configured to deny all the outbound traf- MyDoom.A cies, in individual firewalls as well as among distributed fic to a known backdoor TCP port for the worm, firewalls. FIREMAN performs symbolic model checking of and is correct by itself. However, if a firewall examines the firewall configurations for all possible IP packets and each rule sequentially and accepts (or rejects) a packet im- along all possible data paths. It is both sound and complete mediately when the packet is matched to a rule, a preced- shadow because of the finite state nature of firewall configurations. ing rule may subsequent rules matching some com- FIREMAN is implemented by modeling firewall rules using mon packets. The first rule, which accepts all the outbound 192.168.0.0/16 binary decision diagrams (BDDs), which have been used traffic from the local network , shadows the successfully in hardware verification and model checking. second rule and leaves the hole wide open. We have experimented with FIREMAN and used it to un- Correctly configuring firewall rules has never been an cover several real misconfigurations in enterprise networks, easy task. In 1992, Chapman [6] discussed many problems some of which have been subsequently confirmed and cor- that make securely configuring packet filtering a daunting rected by the administrators of these networks. task. Some of them, e.g., omission of port numbers in filtering rules, have been addressed by firewall vendors. However, many others are yet to be addressed successfully. Since firewall rules are written in platform-specific, low- 1. Introduction level languages, it is difficult to analyze whether these rules have implemented a network’s high-level security policies Firewall is a widely deployed mechanism for improving accurately. Particularly, it is difficult to analyze the inter- the security of enterprise networks. However, configuring actions among a large number of rules. Moreover, when a firewall is daunting and error-prone even for an experi- large enterprises deploy firewalls on multiple network com- enced administrator. As a result, misconfigurations in fire- ponents, due to dynamic routing, a packet from the same walls are common and serious. In examining 37 firewalls in source to the same destination may be examined by a dif- production enterprise networks in 2004, Wool found that ferent set of firewalls at different times. It is even more all the firewalls were misconfigured and vulnerable, and difficult to reason whether all these sets of firewalls satisfy that all but one firewall were misconfigured at multiple the end-to-end security policies of the enterprise. places [31]. As another evidence, Firewall Wizards Secu- We propose to use static analysis to discover firewall rity Mailing List [15] has discussed many real firewall mis- misconfigurations. Static analysis has been applied success- fully to discover security and reliability bugs in large pro- 3. We provide an implementation of our algorithm in the grams [7,11], where it examines the control-flow and/or the tool FIREMAN based on binary decision diagrams data-flow to determine if a program satisfies user-specified (BDDs). Using FIREMAN, we have discovered pre- properties without running the program. A firewall config- viously unknown misconfigurations in production fire- uration is a specialized program, so it is natural to apply walls. (Section 5) static analysis to check firewall rules. Compared to test- The rest of this paper is organized as follows. Section 2 ing, static analysis has three major advantages: (1) it can describes the operational model of firewalls, which lays the proactively discover and remove serious vulnerabilities be- foundation for static analysis and error detection. Section 3 fore firewalls are deployed; (2) it can discover all the in- classifies misconfigurations into policy violations, incon- stances of many known types of misconfigurations, because sistencies, and inefficiencies. Section 4 presents our static it can exhaustively examine every path in the firewall effi- analysis algorithm for checking firewall misconfigurations. ciently; (3) when multiple firewalls are deployed in a com- Section 5 describes our implementation and evaluation of plex network topology and are subject to dynamic routing FIREMAN, and the previously unknown misconfigurations configurations, static analysis can discover vulnerabilities that FIREMAN discovered in production firewalls. Sec- resulting from the interaction among these firewalls with- tion 6 reviews related work and Section 7 concludes this out the need to configure these routers. paper. Testing has been proposed to discover firewall miscon- figurations [3, 21, 27, 30], where a tool generates packets and examines whether a firewall processes these packets 2. Modeling Firewalls as intended. However, due to the enormous address space of packets, one cannot test all possible packets practically. 2.1. Models for Individual Firewalls Al-Shaer and Hamed describe common pairwise inconsis- tencies in firewall rules and propose an algorithm to detect Firewalls from different vendors may vary significantly these inconsistencise [1, 2]. Our work is inspired by them, in terms of configuration languages, rule organizations and but our tool can detect a much wider class of misconfig- interaction between lists or chains. However, a firewall gen- urations, such as inconsistencies and inefficiencies among erally consists of a few interfaces and can be configured multiple rules and security policy violations, and miscon- with several access control lists (ACLs). Both the ingress figurations due to the interaction among multiple firewalls. and egress of an interface can be associated with an ACL. To the best of our knowledge, our work is the first to apply If an ACL is associated to the ingress, filtering is performed rigorous static analysis techniques to real firewalls and to when packets arrive at the interface. Similarly, if an ACL is have found real misconfigurations. associated to the egress, filtering will be performed before packets leave the interface. We have implemented our approach in the tool FIRE- Each ACL consists of a list of rules. Individual rules MAN — FIREwall Modeling and ANalysis. FIREMAN can be interpreted in the form hP, actioni, where P is a discovers two classes of misconfigurations: (1) violations predicate describing what packets are matched by this rule of user-specified security policies — For example, allow- and action describing the corresponding action performed ing incoming packets to reach the TCP port 80 on an in- on the matched packets. Packets not matched by the cur- ternal host violates the security policies of most networks; rent rule will be forwarded to the next rule until a match is (2) inconsistencies and inefficiency among firewall rules, found or the end of the ACL is reached. At the end of an which indicate errors or warnings regardless of the security ACL, the default action will be applied. This is similar to policies — For example, a rule intended to reject a packet an “if-elif-else” construct in most programming languages. is shadowed by a preceding rule that accepts the packet. Implicit rules vary on different firewall products. On Cisco FIREMAN can discover problems not only in individual PIX firewall and routers, the implicit rule at the end of an firewalls but also in a distributed set of firewalls that col- ACL denies everything. On Linux Netfilter, the implicit rule lectively violate a security policy. is defined by the policy of the chain. We summarize our major contributions as follows: Note that what we have described is the so-called “first- 1. We give a comprehensive classification of firewall mis- matching” ACLs. Some firewalls e.g. BSD Packet Filter, configurations for both single firewalls and distributed use last-matching ACLs, in which the decision applied to firewalls (Section 3); a packet is determined by the last matched rule. An ACL using last-matching can be converted to first-matching form 2. We present a static analysis algorithm to examine fire- by re-ordering. In this paper, we assume every ACL uses wall rules for policy violations and inconsistencies first-matching. at different levels: intra-firewall, inter-firewall, and Traditional stateless firewalls treat each packet in isola- cross-path (Section 4); tion and check every packet against the ACL, which is com- putation intensive and often the performance bottleneck. 2.1.1 Simple List Model Modern stateful firewalls can monitor TCP 3-way hand- shake and build an entry in the state table. If the firewall Figure 1a depicts the simple list model of an ACL. Since matches a packet to an ESTABLISHED flow, it can accept only “accept” or “deny” actions (first two forms shown in it without checking the ACL, thus significantly reduce the Table 1) are allowed, any packet will traverse the list in or- computation overhead. However, the ACLs still determine der until a decision is made on each packet.