Platform-Independent Firewall Policy Representation

Platform-Indep enden t Firew all P ol icy Represen tatio n V adim Zaliv a, lord@cro co dile.org No v ember 27, 2021 Abstract In this pap er we w ill discuss the design of abstract fi rew all mo del along with platform-independ ent p olicy definition language. W e w ill also dis cuss the mai n design c h allenges and s olutions to these chal lenges, as w ell as examine sever al differences in p olicy seman tics b etw een vendors and how it could b e mapp ed to our platform-indep endent language. W e will also touch up on a pro cessing model, d escribing the mechanism by whic h an abstract p olicy could be compiled into a concrete firewal l p olicy syntax. W e will discuss b riefly some future researc h directions, such as p olicy optimization and va lidation. Keywor ds: firewall , p olicy , NA T, fwbuilder, securit y , rules 1 Con ten ts 1 In tro duction 3 2 Abstract Firew all 4 2.1 Data Mo del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Basic Netw o rking O b jects . . . . . . . . . . . . . . . . . . 4 2.1.2 Hosts, Firewalls, Policies . . . . . . . . . . . . . . . . . . . 5 2.1.3 Utilit y Ob jects . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Synt ax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Pro cess ing Mo del . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Policy V erification and Optimization . . . . . . . . . . . . . . . . 10 2.4.1 V erifica tio n . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Platform-sp ecific c hall enges 11 3.1 Implicit vs . Explicit Interface Sp ecification . . . . . . . . . . . . 11 3.2 Default Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3.3 First vs. Last Policy Rule Matching . . . . . . . . . . . . . . . . 11 3.4 NA T vs Firewall Rules Or der . . . . . . . . . . . . . . . . . . . . 11 3.5 Negation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 Addrress Range E mulation . . . . . . . . . . . . . . . . . . . . . 12 3.7 Dymanic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 Abstract P ol icy Co mpilation T echniques 13 5 Related W ork 14 6 Conclusions 14 App endices 16 A Firew all Builder DTD 16 2 1 In tro duction Presently , firew all administrators are often required to manage m ultiple firewall platforms fr om different vendors. Each of these platfor ms has its own language to describ e fir ewall po licies. Besides syntax differences, firewall polic y mo dels also v ar y from vendor to vendor. If we make a parallel to progra mming lan- guages, a fir ewall administrator is requir ed to lea rn multiple a ssembly languag e s. One pos sible solution is the intro duction of a hig h-level, platform-indep endent firewall po licy description languag e whic h could b e compiled in to representa- tions sp ecific to particular platforms. This a pproach relieves the burden o n firewall administrator o f learning the low-level details of m ultiple firewall plat- forms. Additionally , it helps to eliminate large gr oups of trivial e r rors which a human could make during p olic y configura tion, b y a llowing a user to work with higher level a bstractions without being bur dened b y low-level p olicy syn- tax details. Having a platform-indep endent policy representation will also allow the user to develop a class of cro ss-platform to ols for ma naging, ana lyzing, and v alidating s uch p olicies. W e b elieve that o ur appro ach will allow administrators to increase system security by reducing the c hance o f human erro r. The ideas descr ibe d in this pap er ar e implemen ted in a successful op en source pro ject called Firewall Builder [ 10 ]. It currently supp orts five firewall platforms and is included in ma jor Linux distributions. Firewall Builder al- lows the user to create and edit p olicies of an abstract fir ewall expressed in a platform-indep endent lang uage. The pro ject provides conv e nient GUI for edit- ing firewall p olicies. The abstra ct p olicy us es a set o f provided p olicy c o mpilers to compile into p olicy files for concr e te fir ewall platforms . In this pap er we have fo cused on abstra c t firewall mo dels and p olicy co mpilation. W e r efer readers to related do cuments o n Firewall Builder user interface[ 11 ], API, extensibility[ 14 ], etc. This pap er is orga nized as follows: In section 2 we wil describ e the Abstract Firewall model we ar e using. In section 3 we will discuss some examples of platofrm-sp ecific differences to illustrate the k inds of pro ble ms we are so lv ing. Then, in section 4 , we will dis cuss some pro cessing techniques we ha ve used. Finally , in section 6 we w ill cover so me o f the poss ible directions of future resear ch. 3 2 Abs tract Firew all Firewall B uilder presents a user with a Synthetic Mo del o f a fir ewall, in whic h we can co m bine features suppo rted by v a r ious firewall platforms . W e a ls o made some assumtions ab out the semantics of some rules, which are no rmally also platform dep endent. When working with Firewall Builder, the user only nee ds to know this a b- stract firewall mo de l. The use r defines polic y for this imag ninary abstr act fire- wall, and Firewall Builder’s p olicy compiler tra nslates it to the mode l of the concrete firewall where it will b e actually deplo yed. 2.1 Data Mo del W e use an ob ject model to r epresent v arious netw orking a nd s ecurity co ncepts used in configur ing firewalls. User data is sav e d in files with .fwb using syntax describ ed in section 2.2 . Ob jects a re organized in to Libraries . Ea ch file is a col- lection of such libraries. T ypically there is a t least one library of ob jects created by the use r. Additionally , there is a librar y of standard ob jects provided w ith Firewall Builder which includes definitions of standa rd o b jects (such as a list of standard address rang es for priv ate netw orks per RFC 191 8[ 12 ]) . When used in a business environent , the company ma y supply some libr aries of company-wide ob jects to b e used by all depar tement s. The ob jects could be rougly split into several ca tegories : 2.1.1 Basic Netw orking Ob jects This categor y includes so me basic ob jects repr e senting commo n concepts used in Netw or king. Some of them a re: IPv4 Address Internet Pro to col (IP ) version 4 addr ess IP Service IP service, defined b y pro to col num b er and so me options like loo se source ro te a nd r ecord route UDP Service UDP s e rvice is defined by sour c e and destinatio n po rt ranges. TCP Service TCP s e rvice is defined b y sour ce and de s tination por t ranges and some fla gs. ICMP Se rvice ICMP serv ic e is defined by ICMP type a nd ICMP co de 4 Ph ysi cal Address Da ta link lay er addr ess, such as E thhernet MA C a ddress or F r ame Relay Data Link Connection Identifier (DLCI) . Time Interv al Allows spec ify time p erio d. Time interv als a re commonly used to specify time-based firew all p olicies. It could be expressed either in terms of absolute date a nd time spe c ifications, or in terms of week days (e.g. fr om Monday to F riday ) 2.1.2 Hosts, Fi rew alls, Policies More complex o b jects are Ho s ts . They r epresent netw ork no des (ser vers, work- stations, routers, IP printers, etc.). Hosts can hav e multiple interfaces with static or dynamic IP addresses. A Fire wall is a sp ecial kind o f hos t, which will b e running fir ewall s o ft ware and could b e configur ed using Firewall Builder. The user must sp ecify what OS platform and firewall softw ar e they are using (some pla tforms allow the user to select from s everal fire wall pack ages). F or firewalls, the us e r can define a Firewall Policy and NA T Rules . Firewall Policy consis ts o f a set of fire wall rules . E ach rule ha s a so urce and destination , service , in terfa ce , direction , time a nd an action . Rule-ma tch ing semantics will b e expla ined in Section 2.3 . NA T Rules sp ecify how the fir ewall hos t p erforms net work a ddress transla - tion, changing so urces a nd des tinations of pas sing packets. 2.1.3 Utilit y O b jects Ob jects in these categorie s are v a rious conv enience ob jects, r epresenting higher- level concepts which ar e e asy to use when descr ibing firewall p olicies. Address Range Ra nge of IPv 4 addes ses. Sp ecified by fir s t and last addr ess. Address T able List to IPv4 a ddresses which is sp ecified in an exter nal file that ca n be loaded at p olicy compile time, or at the time of deploymen t o f generated fire wall p olicy , dep ending on the option configur ed in the Ad- dress T able ob ject. Such lists are commonly used to maint ain dynamically upda ted black lists of s pammers or intruders. Groups V ario us ob jects co uld b e combin ed in to named gro ups for the conv e- nience of referencing them as such in p olicy r ules. Users typically group 5 hosts, IP addres ses, serv ices a nd time interv als. Gro ups a re “ typed”. Tha t means that gr oups can contain o nly ob jects of the s ame type. 2.2 Syn tax The p olicy is ex pressed a s an Extens ive Mark up Language (XML[ 6 ]) do cument. The grammar of this document is sp ecified as a Do cumen t Type Definition (DTD) file. The DTD file for the current version is shown in Appendix A . Each ob ject has an unique id attribute. This a ttr ibute is used to establish references b etw een ob jects. Here are some examples, to illustrate the syntax we use. First, so me simple ob jects: Listing 1: Network Ob ject < Network i d=” i d 4 7 5 0 5 C E 8 1 6 4 7 0 ” n am e =” o f f i c e L A N ” a d d r e s s =” 1 0 . 8 6 . 8 1 . 0 ” n e t m a s k=” 2 5 5 . 2 5 5 . 2 5 5 . 0 ” / > Listing 2: UDP Servic e O b ject < UDPService i d =” i d 4 7 5 0 5 D 0 2 1 6 4 7 0 ” n am e =” M y S e r v i e ” d s t r a n g e e n d =” 9 2 ” d s t r a n g e s t a r t = ” 9 0 ” s r c r a n g e e n d =” 7 0 ” s r c r a n g e s t a r t =” 3 0 ” / > Now let us take a lo ok at a firewall with a simple sing le-rule p o lic y 1 , s hown on listing 3 . Listing 3: Fir ewal l Ob ject 1 < F i r e w a l l h o s t O S= ” l i n u x 2 4 ” i d =” i d 4 7 5 0 5 D 0 5 1 6 4 7 0 ” nam e =” M y F i r e w a l l ” p l a t f o r m =” i p t a b l e s ” > 2 < I n t e r f a c e d y n= ” F a l s e ” i d=” i d 4 7 5 0 5 D 0 B 1 6 4 7 0 ” n am e =” i f 0 ” unnum =” F a l s e ” > 3 < I Pv 4 a d d r e s s =” 1 9 2 . 1 6 8 . 1 . 1 ” i d=” i d 4 7 5 0 5 D 0 C 1 6 4 7 0 ” nam e =” M y F i r e w a l l : i f 0 : i p ” n e t m a s k=” 2 5 5 . 2 5 5 . 2 5 5 . 0 ” / > 4 < ph ys A d d r e s s a d d r e s s =” 0 0 : 1 7 : f 2 : e a : e e : 3 5 ” i d =” i d 4 7 5 0 5 D 3 8 1 6 4 7 0 ” n am e =” M y F i r e w a l l : i f 0 : m a c ” / > 5 < / I n t e r f a c e > 6 < I n t e r f a c e d y n= ” T r u e ” i d =” i d 4 7 5 0 5 D 0 D 1 6 4 7 0 ” nam e =” i f 1 ” unnum =” F a l s e ” / > 7 < I n t e r f a c e d y n= ” F a l s e ” i d=” i d 4 7 5 0 5 D 0 F 1 6 4 7 0 ” n am e =” l 0 ” unnum =” F a l s e ” u n p r o t e c t e d =” F a l s e ” > 8 < I Pv 4 a d d r e s s =” 1 2 7 . 0 . 0 . 1 ” i d=” i d 4 7 5 0 5 D 1 0 1 6 4 7 0 ” n am e =” M y F i r e w a l l : l 0 : i p ” n e t m a s k=” 2 5 5 . 2 5 5 . 0 . 0 ” / > 9 < / I n t e r f a c e > 10 < P o l i c y i d =” i d 4 7 5 0 5 D 0 8 1 6 4 7 0 ” > 11 < P o l i c y R u l e a c t i o n =” D e n y ” c o m m e n t =” ” d i r e c t i o n =” B o t h ” d i s a b l e d =” F a l s e ” i d= ” i d 4 7 5 0 5 E C E 1 6 4 7 0 ” p o s i t i o n =” 0 ” > 12 < S r c n e g =” F a l s e ” > 13 < O b j e c t R e f r e f =” s y s i d 0 ” / > 14 < / S r c > 15 < Dst n e g =” F a l s e ” > 16 < O b j e c t R e f r e f =” i d 4 7 5 0 5 C E 8 1 6 4 7 0 ” / > 17 < / D st > 18 < Sr v n e g =” F a l s e ” > 19 < S e r v i c e R e f r e f =” i d 4 7 5 0 5 D 0 2 1 6 4 7 0 ” / > 20 < / S r v > 1 for clarity , some non-essent ial attributes and elemen ts w ere omi tted 6 21 < I t f n e g=” F a l s e ” > 22 < O b j e c t R e f r e f =” s y s i d 0 ” / > 23 < / I t f > 24 < W h e n n e g =” F a l s e ” > 25 < I n t e r v a l R e f r e f =” s y s i d 2 ” / > 26 < / W h e n > 27 < / P o l i c y R u l e > 28 < / P o l i c y > 29 < / F i r e w a l l > As we ca n see, the Fir ewal l element includes the definition for three netw o rk int erfaces and a firewall p o licy . Int erface definitions are expr e s sed as Int erfac e elements. In terface if1 is dynamic and ha s no static IP addr ess asso c ia ted with it. Interfaces if0 and lo0 hav e static IP address es asso cated with them. These IP a ddresses ar e expressed as enclo sing IPv4 elements. One may w onder why interface addr ess was no t sp ecified as a n attribute. The a ns wer is that an interface could hav e more than one IP addres s ass igned to it. The firewall po lic y is ex pressed a s a Policy element, and may contain one or more PolicyRule elements. Because XML spe cification [ 6 ] does not gua rantee element o rder, policy rule or dering is implicitly sp ecified via p osition attrbute which defines PolicyRule absolute orde r within e nclo sing Policy element. Direction and Action rule fields are specified via dir e ction and action a t- tributes of a PolicyR ule . Each PolicyR ule rule element con tains Sr c , Dst , Srv , Itf , When sub-elements to s pec ify Sour c e , Destination , Service , Int erface and Time Interv al rule fields r esp ectively . Each o f these elements co uld contain one or mo re ob ject references s pec ifing their v alue . Each of the field’s matching v alue could optionally b e ma de nega tive by sp ecifying ne g a ttr ibute. F o r example lis ting 4 demonstr a tes a destination which is either an ob ject with id A o r B . Adding negation as s hown on listing 5 changes the meaning so tha t the destination must b e neither A nor B . Listing 4: Negation Example (withou neg ation) < D st n e g=” F a l s e ” > < O b j e c t R e f r e f =”A” / > < O b j e c t R e f r e f =”B” / > < / Ds t > Listing 5: Negatio n E xample (with nega tio n) < D st n e g=” T ru e ” > < O b j e c t R e f r e f =”A” / > < O b j e c t R e f r e f =”B” / > < / Ds t > 7 As we hav e s een, there ar e tw o ma jor wa y s to expres s relationships b etw een ob jects in the Firewall Builder XML. The fir st wa y is embedding - when one ob ject definition is enclos ed in the o ther ob ject definition element. An example is an Interfac e embedded within a Fir ewal l ob ject, or a IPv4 o b ject, embed- ded within a n Interfac e ob ject. The second metho d uses a r eference, via the Obje ctR ef e le men t. In this metho d, in place of the o b ject which w e a r e refer- ing to, we place an Obje ctR ef element, which has its r ef attribute set to the v alue of id o f the o b ject we are reffering to. W e ca n s ee suc h references in Src and Dst elements of a PolicyR ule referencing Network a nd UDPServic e ob jects resp ectively in the ex a mple ab ov e. 2.3 Pro cessing Mo del It is no t sufficien t to define just Data Mo del to b e able to write a firewall po licy . A data model implies c e r tain sema ntics, defined a s a pro cessing mo del . Pro cess ing mo del differ s from one fir ewall platform to a nother. W e w ill define a n abstract pro cessing model to be used when defining p olicies of Abstract Firewall and later on we will map it to pro cess ing mo dels of co ncrete fir e wall pla tforms. F or each pack et pass ing thro ugh a firewall, several pro cessing stages are applied. It is optionally pr o cessed via NA T Rules and then filtered by Fire wall Policy Rules. These stag e s can change the packet headers or even drop o r reject the whole packet . While the sequence of NA T and filtering steps v ar ie s from platform to plat- form in r eal firewalls (see se c tion 3.4 for disuccion), in Fir ewall Builder ’s abs tract firewall mo del, it is fixed and pro ce ssing is a lwa ys done in the following or der: 1. Net work Addr e s s T ra nslation s tep is p erformed 2. Firewall Policy is applied The packet is first matched towards all NA T rules, in the o rder they are defined by the user . A NA T rule “matches” if the r ule orig inal so urce , o r iginal destination a nd original se r vice fields match the current pa ck et and if it happe ns within a n o ptional time interv al sp ecified in the rule. (any matching fields may be sp ecified as Any - a wildca rd which matches any v alue). A matched packet is mo dified by replacing its so urce , destination and service fields with tra nslated source , translated destination and translated ser v ice from the rule. If some o f translated sour ce , tra nslated destinatio n or tr anslated serv ic e is left e mpty by 8 the user, it means that the orig inal v alue of this field should b e preseved. If a pack et has not matched any NA T rule s , it will b e pro cesse d fur ther, unchanged. Next, the pack et is matched towards all Policy r ules in the or der they a re defined by user. F or each pa ck et the following fields ar e matched tow a rds the rules: Source pack et sour ce addr ess (IP or data link level) Destination pack et destinatio n a ddress (IP or data link level) Service pack et ser vice (One of IP , UDP , ICMP service o b jects.) In terface in terface via which this pack et has a rrived Direction direction of the pack et, in resp ect to the firewall ( In b ound or Out - b ound ) An y o f these field could be excluded from matching if Any wildcard is sp ec- ified a s the v alue in the rule. Once a pack et has matched one of the rules, the action sp ecified in the rule is pe rformed. Possible v alues a re: Accept the pack et is p e r mitted to pa ss through Den y/Drop the packet is silent ly dropp ed Reject the pack et is rejected, notyfing the s erver via ICMP message Accoun ting the pack et counter a sso ciated with this r ule is incremented Although actua l fir ewall implementations may v ary in what happe ns once a pack et is ma tched (s e e sectio n 3.3 for examples), in the Firewall B uilder ’s abstract firewall mo del sema ntics are well defined: F or accept , den y and reject actions after the firs t rule is matched, the appro riate action is per formed and no further rule chec ks are per formed. F or acc ounting actio ns, after a count er v a lue increase, the pack et matching is contin ued a gainst any r e maining rule s . After a ll rules have b een pr o cessed and no a ccept , deny or reject action was inv oked, the default p olicy is applied. While the default p olicy could be differ- ent in underlying firewall pla tforms (see se ction 3.2 for discuss ion), in Firewall Builder’s abstra ct firewall mo del, the default p o licy is to p er form a dr op action on every pack et. 9 2.4 P olicy V erification and Optimization Even b efore the p o licy is compiled to c oncrete firewall syntax, there is cer tain pro cessing which co uld be done on the abstract p olicy mo del. The tw o main areas are verific ation a nd optimization . Having w ell-defined pro cessing mo del and a p olicy expressed in a stadartized form, a g e neric high-level p olicy analy sis could b e p erfor med without needing to fo cus on the details o f fir e wall pla tform implemen tation. 2.4.1 V erification While the XML syntax v alida tion towards the DTD ensured that there a re no syntax err ors in the do c umen t, it do e s not catch erro rs in s e ma nt ics. F or example, we found it useful to show users a warning when s o me p olicy rules will never b e used. It is similar to unreachable co de detection in prog r am- ming languages . F or example, let us assume there are tw o identical rules (with drop action), whic h differ only in the des tination addr ess field. The first r ule has destiation address 1.2. 3.4/16 while the second rule ha s 1.2 .3.4/32 . Obviously , all pack ets which could p ossibly match the second r ule, will be matched by the first r ule first. W e call this s ituation “ rule shadowing”, saying that the fir st r ule “shadows” the second one. W e try to detect such situations a nd rep or t them to the user, since they most likely sig nify a n error in the user’s p olicy definition. In a ddition to rule shadowing, in the future we can forsee o ther sema ntic error s which can b e detected and re po rted to the user . This is one o f the areas for the future research. 2.4.2 Optimi zation There is a cost for executing each rule in a firewall. L o ng p olicies tend to affect firewall p er formance. It is very beneficia l to try to optimize firewall polic y by combining and reshuffling r ules to make it s horter and hence more efficient. Common optimization techniques include removing unusued or redundant rules, g rouping multiple rules into a single o ne, and in general to try to ex press the same p olicy with the fewer rules. 10 3 Platform-sp ecific c hallenges Let us examine se le cted examples of pla tform sp ecifics on pf , iptables and ipfilter firewall pla tforms. All these problems ar e nor mally hidden from Firewall Builder users, b ecause the firewall hides a ll these platform-sp ecific differences from the user and gener ates platfor m-sp ecific co de to r esolve these issues. 3.1 Implicit vs. Explicit I n t erface Sp ecification 3.2 Default Policy What should a fir ewall do with a pack et which matc hed none of the p olicy rules? Should it b e allowed to pass thro ug h, o r sho uld it b e discarded? In iptables default p o licy is a user-configur able option. In ipfilter pack ets a r e also passed b y default, unless it is compiled with IPFIL TER DEF AUL T BLOCK option[ 7 ]. In pf packets a re passed by default 3.3 First vs. Last P olicy Rule Matc hing In typical packet filter, a pack et is matched towards a list of rules. It co uld either match or not match each rule. If a rule is matched, it makes a decision to p ermit this pack et ( accept ) or not ( reject o r drop ). Ther e are tw o common matching strategies. In the first stra tegy , matching o ccurs unt il the first matching rule is found. W e w ill ca ll it first match 2 . Another strateg y is to match all rules, then make a decision ba sed on last match. W e will ca ll this strategy las t match 3 . iptables supp or ts o nly the first match strategy . ipfilter and pf b oth suppo rt las t match strategy b y default, unless qu ick rule keyword was sp ecified. This keyw ord intstructs the firewall to s top further matching a nd use results from the current match a s a final decision on whenever pack et should b e per mitted to pass. 3.4 NA T vs Firew all Rules Order Often a firewall w ill per form b oth p acket filtering and network addr ess tr ans la- tion (NA T) functions. The obvious question is: in what or der NA T and filtering rules are applied? Are addresses translated first and then filters ar e chec ked, 2 This strategy is also sometimes reffered to as the “single-tri gger” approac h 3 This strategy is also sometimes reffered to as “mutli-trigger” approac h 11 or vice-versa? This makes a big difference, beca use if NA T is applied first, one should use a lr eady tr anslated (not orig inal) addresses in p olicy rules. iptables destinguish tw o kind of NA T rules : SNA T (so urce NA T) and DNA T (destination NA T). It could b e said tha t DNA T is a pplied first, then pa ck et filtering, and then SNA T. PIX , another po pular firewall platform from CISCO p erforms pack et filter ing first and then NA T. Both ipfilter and pf p erfor m addres s translation fir st and only then p erform filtering functions. 4 3.5 Negation Sometimes it is conv enient to use neg ation in p o lic y rules. F or exa mple, to sp ecify condition like “if sour ce address is not 1.2 .3.4 ”. A more complex form of negation is to a pply it to a group of addresses (“if s ource address is not in { 1.2.3.4 , 10.20 .3 0.40 } ”). iptables supp or t sing le address neg a tion: “Many fla gs, including the ‘-s’ (or ‘–sour c e’ ) and ‘-d’ ( ‘–destinatio n ’ ) flags can hav e their arguments preceded b y ‘!’ (prono unced ‘not’ ) to matc h addre s ses NOT equal to the ones given. F o r exa mple. ‘-s ! lo c alhost’ matc hes any packet not coming from lo c alhost .”[ 13 ]. How ever for addr ess ranges, supp or t for which is facilitated by mo d iprange mo dule, negatio n is no t sup orted. Both ipfilter supp orts nega tion (at least for addr esses). No g roup negation suppo rt is provided. pf suppor ts nega tion (at least fo r addresses). It a lso supports a limited case of gr oup neg ation, when using tables. F o r example, the following fragment allows to pas s all trafic from all addre s ses, ex c ept ones in the bla ck lis t. table {1.2.3.4 , 10.20.30.4 0} pass in quick inet from any to ! keep state 3.6 Addrress Range Em ulation All fir e walls allow the user to sp ecify an individual IP addres s or CIDR blo ck in the rules. How ever, sometimes it is convenien t to sp ecify an address ra nge 4 In case of pf : “The only exception to this rule is when the p ass k eywo rd is used wi thin the nat rule. This will cause the NA T ed pack ets to pass right through the fil tering engine.”[ 2 ] 12 ( fr om - to ). iptables p ermits addr ess rang e s using ipr a nge mo dule. Both ipfilter and pf do not supp or t a ddress rang es. 3.7 Dymanic Interfaces Oftent imes, the IP a ddress as s igned to an interface is no t known at the time o f the po licy definition. This is common with dynamic interface , which obtains its address using DHCP or a similar proto col. Abstract Firewall Policy allows the user to implement such intefaces in p olicy r ules, in place of source or destination addresses. pf p ermits the use of inteface names in the rules, a nd will use curr ent interface IP addresse s at the time the rule is e xecuted. ipfilter is using sp ecial 0/32 notation to refer to cur rently assigned interface IP address. In the cas e o f iptables there is no wa y to r e fer to the current in terface dynamically-a s signed IP addr e s s in policy rules. 4 Abstract P olicy Compilation T ec hniques In this section we will briefly discuss some implementation appro a ches used to compile and deploy Abstrac t Firewall p olicy to a co ncrete firewall platfor m. An abstra c t firewall p olicy needs to b e compiled into p olicy fo r the concr ete firewall. Usually this req uires certain transformatio ns . While o verall rule data structure remains r o ugly the same (sourc e , des tita tio , action, etc.), a target firewall platform puts v ario us limitations to the allowed v alues, and sometimes even implies slightly different semantics. W e found it co n venien t to p erform p olicy transfor mation as a ser ies o f small steps. E ach step could be viewed as a function, whic h takes as input a list of po licy rules and outputs a mo dified list of such rules. Some o f these transfo rma- tions ar e quite simple and could b e reus ed b etw een different fir ewall pla tforms. These transformatio n functions are called Rule Pro cess ors . An example of a rule pro cess o r could b e one which ta kes a sing le rule with address rang es in the rule source a ddress and converts it to a g roup of rules, whic h tog ether p erfor m the same function as the orig inal r ule, but ea ch rule has a single CIDR blo ck in a source address field . 13 5 Related W ork There is a lot of related r esearch in this area (see [ 9 ] for a go o d survey on the sub ject). Many appr oaches ar e concent rated on building an abstract security mo del, and then applying to to the firewall p olicies (either a utomated genetation o r verification). Some mo dels are using UML, so me build up on RBAC mo del. In our opinion, one o f the pro blems with suc h approa ches is the big repre- sentation g ap betw een the mo del a bstractions and the co ncrete firewall device pro cessing and data mo del. Our approach is more pragma tic. Firewall Builder’s abstract firewall mo del is very clo se to the one used in the many mo dern da y firewall devices. This mo del is familiar to the most firewall administrator s and easy to understand. Our mo del could act as intermediate r epresentation b e- t ween high-level mo de ls and formal languag es and concrete fir ewall p olicies. Al-Shaer et. al[ 3 ] pres ent g o o d formalization of firewall rules relationships and clas s ification o f the anomalies which should be detected during po licy ver- ification. 6 Conclusions In this pap er we have presented in an ov er view form Firewall B uilder’s a pproach of corss-platfor m firewall manag ement : the idea of an Abstract Firewall, the data and a pro cessing mo del of such firewall. In a few examples we hav e shown the kind of challenges firewall adminstrator s ar e facing when they are require d to work with multiple firewall platforms. The definition of an abstract fire wall mo del and p olicy definition la ng uage is a first, ena bling step which allows us to develop and apply v arious p olicy anal- ysis and tr ansformation techniques in a platfor m-indep endent manner . Policiy verification and o ptimization techniques, briefly touced upon in the section 2.4 presents many interesting re s earch challenges and o ppo rtunities. Firwall B uilder data files could contain multiple firewalls s haring common utilit y o b jects (hosts, netw orks, etc.). This op ens the opp ortunity for developing more sophisticated p o licy analysis to ols, consider ing not o nly a sing le firewall but a netw ork with several firewalls. Such a comprehensive distributed firewal mo del could b e analyzed for inter-firewall anomalie s as w e ll as intra-firewall anomalies [ 3 ]. In the co urse of the pr o ject, w e s ta rted to work on a formal mo del of p olicy 14 rules relationships. Such a mo del is require d to implement no n-trivial v alida- tion and optimization techniques. O ur initial thinking was alo ng the lines of m ulti-dimensional space , where each r ule field repres e n ts a dimension and a rule represents a figure. Each pack et is repres ent ed as a point in this space. If it matches some rule, this point will b e inside a fig ure represe nted by the rule. References [1] Firewall builder pro ject. ht tp://www.fwbuilder.o r g/. [2] Pf: The op e n bsd pack et filter. http://www.openbsd.org/faq /pf/. [3] E. Al-Shaer and H. Ha med. Discov ery of p olicy anomalies in distributed firewalls. IEEE INFOCOM , 4:26 05–26 16, 2 0 04. [4] M. Bauer. Paranoid p enguin: using firewall builder, Part I. Linux Journal , 2003(1 09), 200 3 . [5] M. Bauer . Parano id Penguin: Using Firewall B uilder , Part II. Linux Journal , 20 0 3(110), 2 003. [6] T. Bray , J. Paoli, C.M. Sper b erg-McQue e n, et al. Ex tens ible Mar kup Lan- guage (XML) 1 .0 . W3C R e c ommendation , 6, 2000. [7] B. Co nob oy a nd E. Fich tner. IP Filter Ba sed Firewalls HOWTO. Sat , 22(26):20 01, 19 1 1. [8] F. C upp ens, N. Cuppens -Boulahia, and J. Garc ıa -Alfaro. Detection and Remov a l of Fire wall Misconfigur ation. Pr o c e e dings of the 2005 IASTED In- ternational Confer enc e on Communic ation, Network and In formation Se- curity (CNIS 2005 ) , 200 5 . [9] A. El-Ata wy . Survey o n the use o f for mal languages/ mo dels for the sp e c - ification, verification, and enfor c ement of netw or k ac c ess-lists. S cho ol of Computer Scienc e, T ele c ommunic ation, and Information Systems, DePaul University, Chic ago, Il linois , 606 04. [10] V. Kurla nd. Firewall Builder. 11th DFN-CER T W orkshop, H amburg , Ger- many , 200 4 . [11] NetCitadel LLC. Firewall Builder User ’s Guide. 20 03. 15 [12] Y. Rekhter, B. Mosko witz, D. Karre n b erg, GJ de Gro ot, and E. Lear. RF C191 8 : Address Allo cation for Pr iv ate Internets. Internet RFC s , 1996 . [13] R. RUSS ELL. Linux 2.4 pa cket filtering howto, 2 0 04. [14] V. Zaliv a. Mana g ing x ml do cument s versions and upgrades with xslt. 2 001. App endices A Firew all Builder DTD 16 17 19 22