FIREWALL RULE SET OPTIMIZATION

Transcription

1 Authr Name: Mungle Mukupa Supervisr : Mr Barry Irwin Date : 25 th Octber 2010 Security and Netwrks Research Grup Department f Cmputer Science Rhdes University

2 Intrductin Firewalls have been and cntinue t be used t implement lgical security between these netwrks f different trust levels. Netwrk speeds have imprved significantly and calls fr better packet filtering. This research fcused n Netwrk layer firewalling.

3 Prblem Statement Sequential Inspectin: Firewalls inspect packets against a set f rules sequentially until a match is fund. Matching Patterns: Nt all rules are matched each time a packet is inspected thrugh the rule set. Nature f traffic: netwrk traffic is dynamic and ften flws are nt predictable. Netwrk Speed: Increased netwrk speeds are verwhelming firewalls hence the need fr faster filtering decisins by firewalls t avid waste f device and netwrk resurces.

4 Research Objectives T investigate filtering perfrmance imprvement gained thrugh ptimizing a firewall rule set size. Cme up with a tl that can aid netwrk administratrs in rule set ptimizatin.

5 Experiment Design The test was perfrmed in virtual envirnment using VmWare sftware and the firewall hst is running in Bridged mde. IP was cnfigured n the bridge c allw remte access frm Linux fr graphical use.

6 Firewall FreeBSD firewall was used fr tests in this research because f: Flexible rule set lgic First match wins Packet accunting Bridge mde Open surce IPv6 supprt Prted t ther perating systems Mac OS DragnFly Windws

7 Results Capture IPFW-Graph tl was used t capture filtering actins n bth rule sets. Gives graphic utput f packet matching in real-time. Deny rules shwn in red clur. Allw rules shwn in green clur. Cmbines bth in the all view.

8 Traffic Traversal Multi prtcl pcap files were sent thrugh the firewall hst running in bridged mde use tw interfaces in different netwrks (Public and Private t simulate the ideal case). Test specific packets were injected int the firewall especially the nes fr testing illegal traffic handling after ptimizing. # nemesis icmp S D i 0 -c 0 The cmmand abve tests the firewall s deny actin n icmp.

9 Rule Sets Default rule set started with a rule set f 37 rules... Passed traffic frm different pcap thrugh the firewall and cllected matching statistics. Nt all rules matched packets inspected: cunter =0. Sme rules did nt match packets ften.

10 Cunters Lg file

11 Optimizatin Reducing the rule set size was perfrmed based n the cllected statistics. Frm the initial 37 rules, an ptimized set f 13 rules was created. Hw - cntinued revisin f rule set after several tests using pcap files. Mved frequently matched rules frward Remved nn matching rules Intrduced skip t t skip infrequently matched rules that culd match traffic later. Disabled rules fr services nt available Remving vershadwed rules Aviding redundancy Reintrducing rules fr sme denied packets based n their lg cunt and hw necessary they are deemed.

12 Perfrmance Tests Nt standardized firewall tests depend n what aspect is being measured This research cncerned itself with thrughput based n rule set size and picked the fllwing metrics as discussin pints: Cnnectin establishment: measured hw fast the firewall created cnnectins per packets inspected cnsidering the number f rules Frwarding rate : cmpared the bits per secnd transmitted n bth rule sets by measuring hw lng it tk fr a full pcap file t be inspected. Cnnectin teardwn: paired with cnnectin establishment, the faster the tear dwn, the less rules a packet is inspected thrugh t find a match. Legal traffic: checked if ptimizatin denied allwed traffic r stpped certain services allwed frm cmmunicating by lking thugh lg file entries. Illegal traffic: checked if ptimizatin allwed false psitives. Tls were used t inject packets denied by a given rule. These values cmbined, were used t determine a gain in filtering speed : THROUGHPUT

13 Results Tests dne n 1500 bytes pcap file n bth rule sets. Prtcl cmpsitin f pcap file used

14 OptAid: Tl Design

15 OptAid Tl Design Cnsidered ffline prcessing and suggesting ptimizatin actins t the administratr. Design questins still t be answered befre OptAid can be implemented: Statistics aggregatin vs. dynamic nature f traffic. Defining triggering cunter threshlds fr ever changing traffic? Hw ften shuld statistics be sent t the database? D we discard rules cmpletely? Hw much verhead des all this intrduce? Anther cnsideratin was t create a sub-rule-set dynamically. Issues faced and being investigated still are: Prcessing cmplicatins with respect t picking rules fr ncming traffic. Hw t wrk ut and tell what flws t adapt fr. Issues with rule numbering when re-sequencing. Hw t apply the sub-rule set t traffic.

16 Cnclusin Based n the evidence btained frm the tests cnducted in this research, it can be cncluded that: There is a gain in firewall filtering perfrmance by reducing the rule set. Less rules a checked thrugh sequentially and a match is fund faster. The dynamic nature f traffic ffers challenges in adapting rule sets t packet flws. This is why it has generally been described as NP-Hard. Care must be taken nt t pen the netwrk t illegal traffic r denying legitimate traffic by lcking the system ut when ptimizing. Packet filtering is a crucial cmpnent f netwrk security and thus needs better methds t avid wasting f device and netwrk resurces. Better filtering methds and appraches are necessary t make firewalls match up t the imprved transmissin technlgies and netwrk speeds.

17 Future Wrk Investigate mre n rule set ptimizatin technlgy changes every secnd. Implement OptAid tl having understd and demnstrated matching patterns. Investigate further, perfrmance implicatins with regard t dynamic sub rule set creatin frm the larger set. Add dynamic rule set adaptatin t OptAid nce perfrmance issues are addressed.

18 Thank yu fr yur attendance