Firewall Configura/on Errors Revisited AvishaiWool Internet Security Seminar 2013 Lecturer: Dr. Tom Chothia Presenter: BINBIN HU
Content IntroducAon Preparatory work& Data collecaon Measure method Data analysis Conclusion
IntroducAon The definiaon of the firewall The posiaon of the firewall Basic funcaon modules Design goals for a firewall Some familiar firewalls
1.CorporaAon Firewall the first line of 1.1 What is firewall? the cyber- defense Firewall:A firewall is a combinaaon of hardware and soqware that isolates an organizaaon s internal network from the Internet at large, allowing some packets to pass and blocking others. Firewall = hardware + so2ware + control policy
FIRE DOOR FIREWALL MONITOR IDS REINFORCED ROOM SECURE TRANSMISSION SYSTEM REINFORCEMENT ENCRYPTION VPN DOOR ACCESS CONTROL MONITORING ROOM SECURITY FORCES IDENTITY AUTHENTICATION SECURITY POERATION CENTER SCANNER BUG FINDING & ACCESS CONTROL
The posiaon of the firewall in the network topology hup://net.anquan365.com/equipment/firewall/201110/166360.html
Basic funcaon modules Content Filtering User Authen/ca/on VPN Applica/on Proxy IDS & Warning Packet- filtering& State inspec/on NAT Log
Design goals for a firewall 1. All traffic from inside to outside, and vice versa, must pass through the firewall. 2. Only authorized traffic, as defined by the local security policy, will be allowed to pass. 3. The firewall itself is immune to penetraaon.
1.2 Some familiar firewalls (Hardware firewall) price home users office small enterprise large and medium enterprises campus network hup://www.huaxintong.com/^q_sc.asp
Checkpoint(SoQware firewall) Checkpoint Power- 1
hup://www.jjlink.com/list.php?id=21
Preparatory work& Data collecaon The most important factor of the firewall security Firewall configuraaon test The goal for this work New features of this study Data collecaon
2. The most important factor of the firewall security is how you configure it The protecaon that these firewalls provide is only as good as the policy they are configured to implement. For well- configured firewalls small is (s?ll) beau?ful
2.1Firewall configuraaon test The network auack is the best way to test the firewall configuraaon. Before auacking, an important technology oqen be used scan
Scan the basement of auack. For collecang useful informaaon of target host. scan types TCP SYN (half open) scanning TCP FIN (stealth) scanning TCP Qp proxy (bounce auack) scanning ICMP scanning (ping- sweep)
Internet Worms' most important feature is the ability to scan for more vulnerable machines. Firewall stop worms Monitoring the package in the communication Handling package according to rule-sets
The poor state of firewall configura?on can be observed, indirectly, by the huge prolifera?on of network worms like Blaster and Saphire that could have been easily blocked by a well configured firewall. So this provided a quanataave evaluaaon of the quality of corporate firewall configuraaons. This state of affairs was validated in a 2004 study, the author of this paper claimed that the arguments are s?ll valid.
2.2The goal for this work To test the hypothesis the quality of corporate firewall configuraaons has improved over Ame. To check whether the findings of A quan?ta?ve study of firewall configura?on errors,(2004) are sall valid. 2004 study s main observaaons: (a) firewalls are poorly configured (b) a rule- set s complexity is posiavely correlated with the number of detected configuraaon errors (c)later soqware versions have fewer errors
2.3New features of this study To address some possible criaques, such as: the sample used before was not indicaave; the detected problems were specific only to one vendor. This study has the following features: (1)collected from firewalls running later firewall versions; (2)covered more than twice as many rule- sets as before; (3)included rule- sets from Check Point FireWall- 1 and Cisco PIX (4)consisted 36 vendor- neutral items instead of 12
2.4Data collecaon Data sources: The data for this work includes 54 Check Point FireWall- 1 rule- sets that were collected between 2003 2005.The rule- sets came from a variety of organizaaons, from the telecommunicaaons, financial, energy, media,automoave, and healthcare market segments. The data for this work also includes 30 Cisco PIX rule- sets that were collected between 2003 2005. Objects : Checkpoint Firewall- 1,Cisco PIX AnalyAcal data : 36 configuraaon errors examples: Inbound HTTP to 256+ IPs "To Any allow Any service" rules Outbound SMTP from 256+ IPs
Check Point firewalls Table 1: StaAsAcal properaes of the collected Check Point FireWall- 1 rule- sets. #Rules counts the total number of rules in the rule- set (including NAT rules). #Objects counts the number of network objects (hosts, subnets, and groups of these) defined in the database supporang the rules. #Interfaces counts the number of network interface cards on the firewall. Table 2: DistribuAon of Check Point FireWall- 1 rule- sets by soqware version. For each soqware version we show both the absolute number of rule- sets and their percentage (in parenthesis)
Cisco PIX firewalls Table 3: StaAsAcal properaes of the collected Cisco PIX rule- sets. #Lines counts the total number of lines in the configuraaon file. #Interfaces counts the number of network interface cards on the firewall. Table 4: DistribuAon of Cisco PIX rule- sets by soqware version. For each soqware version we show both the absolute number of rule- sets and their percentage (in parenthesis)
Measure method Previous method RC The analysis of objects The defect of RC The new measure FC The selecaon of configuraaon errors
3 The measure of firewall complexity The research method used previous is RC. RC defined as: RC=#rules+#objects+(#interface/2) #Rules is the raw number of rules in the rule- set, #Objects is the number of network objects, and #Interfaces is the number of interfaces on the firewall The study object for RC is only Checkpoint Firewalls. Now this method is inappropriate in this search, why?
3.1The analysis of objects Objects of study(checkpoint FW1and Cisco PIX) Main differences 1)Type: Emphasize soqware/ hardware 2) Technical principle: Checkpoint s strategy is mainly based on State InspecAon ; Cisco PIX s strategy is primary based on ACL. 3) Management: Checkpoint is based on graphic interface; Cisco PIX based on the command line.
Policy editor of checkpoint
Rule base a simple example
3.2 The defect of RC: For checkpoint, RC didn t give enough weight to the number of interfaces: None of the surveyed Check Point firewalls has more than 18 interfaces (the median number was 4), but Check Point firewalls with hundreds of rules and thousands of objects. #Interfaces is only added to the RC, albeit quadraacally, its contribuaon is oqen dwarfed by the two other terms.
3.3The new measure FC FC is an evoluaon of RC. Goals of improvement: CompaAbility for Cisco SuscepAbility for Checkpoint
Improvement for Cisco For Cisco PIX firewalls, the simplest measure of complexity is the number of lines in the configuraaon file. The raw number of lines to be slightly misleading, especially for very small configuraaons. This is because even the smallest Cisco PIX configuraaon file includes a few tens of boilerplate lines that have liule to do with traffic filtering.
FCp index(for Cisco) Let #Lines denote the number of lines in the ASCII file containing the complete Cisco PIX configuraaon file. Then the firewall complexity of a Cisco PIX firewall is: FCp = #Lines 50.
Improvement for Checkpoint MulAply gives much more weight to the number of interfaces Let #Rules denote the raw number of rules in the Check Point FireWall- 1 rule- set, let #Objects denote the number of network objects, and let #Interfaces denote the number of interfaces on the firewall. Then the firewall complexity of a Check Point FireWall- 1 firewall is: FCc = (#Rules #Interfaces) + #Objects
Through the FC index two kinds of firewall can be put together to compare Firewall complexity distribuaon (log scale) separately for Check Point FireWall- 1 and Cisco PIX. It can be seen from the picture, checkpoint firewall has higher complexity than cisco firewall.
3.4 The selecaon of configuraaon errors The errors in the study: ConsisAng of 36 errors. All the errors are vendor- neutral and create a risk to the network behind the firewall. The angle of the selecaon: Errors are all violaaons of well established pracaces and guidelines.
SelecAon criteria To avoid inflaang the error counts(a single badly wriuen rule may trigger mulaple counted errors), a more specific error was only counted if it was triggered by some rule that does not trigger a more general error. Count each error type once to avoid introducing severity levels, so not all the configuraaon errors in the list are equally severe. Ignore the number of rules contribuang to each error(because the number is less indicaave of the amount of risk), and opted for Boolean indicators for each error.
Error categories inbound traffic(i): Errors cover things such as allowing Any traffic inbound, or allowing services such as RPC, SNMP, and several other known- risky services, also using the noaon of a thresholds to count errors that are related to services such as HTTP, DNS, and FTP. outbound traffic(o): Most of these deal with services that are considered to be risky in all direcaons. And counted errors for indiscriminate outbound e- mail traffic (again using the noaon of a thresholds) and for IRC. internal traffic(d): These all deal with services that are considered to be risky in all direcaons inherently risky rules(r):an error is counted if the rule- set has To Any allow Any service rules
4.Data Analysis DistribuAon of configuraaon errors.
Match order 1 2 3 4 5 6 7 1 2 Any local-net IP Spoofing / IP Op/ons / State Table Security Policy First Rule mail-svr tcp smtp accept Short fw Rule Base Any Any accept Short fw Security Policy Before Last Rule 3 Any Any Last Any Rule In drop Rule Base Long fw Security Policy Last Rule Implicit Drop Policies and rules are matched in order on the Rule Base, one rule at a Ame.
ACL match order IN AcAve Control List(ACL) 1 SIP DIP Sport Dport Accept\Drop 2 SIP DIP Sport Dport Accept\Drop 3 SIP DIP Sport Dport Accept\Drop 4 SIP DIP Sport Dport Accept\Drop. n SIP DIP Sport Dport Accept\Drop Match Order Seq Number OUT
Number of errors as a funcaon of the rule- set s complexity FC (log scale). The central red line represents the least- squares linear regression fit, and the green and purple lines represent one standard deviaaon above and below the least- squares fit.
Errors versus version checkpoint cisco Errors versus version It is clear from both figures that, the effect of the soqware version on the number of configuraaon errors is insignificant: the distribuaon of the number of errors is essenaally independent of the firewall soqware version.
Number of errors as a funcaon of the rule- set s complexity FC (log scale)
conclusion Firewall complexity (FC) measure applies to both firewalls brands and probably to others as well. Firewalls are (sall) poorly configured. The effect of the soqware version on the number of configuraaon errors is insignificant. In general Cisco PIX firewalls seem to exhibit fewer errors than CheckPoint firewalls. A rule- set s complexity is (sall) posiavely correlated with the number of detected configuraaon errors. Thus we can conclude that, for well- configured firewalls, small is (s?ll) beau?ful.
References & useful informaaon Bellovin, S., and Cheswick, W. Network Firewalls. IEEE Communica?ons Magazine, Sep. 1994. Chapman, D. and Zwicky, E. Building Internet Firewalls, Sebastppol, CA: O Reilly, 2000 Wack, J.; Cutler, K.; and Pole, J. Guidelines on Firewalls and Firewall Policy. NIST Special PublicaAon SP 800-41, January 2002 Thank you! Any quesaon?