Firewall Configuration Errors Revisited-1

Firewall Configura/on Errors Revisited

Lecturer: Dr. Tom Chothia

AvishaiWool �

Presenter: BINBIN HU

Internet Security Seminar 2013

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 the cyber-‐defense

1.1 What is firewall？

•  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

SECURITY FORCES

SCANNER、BUG FINDING

SECURE TRANSMISSION

ENCRYPTION、VPN

DOOR ACCESS CONTROL

IDENTITY AUTHENTICATION

& ACCESS CONTROL

MONITORING ROOM

SECURITY POERATION CENTER

REINFORCED ROOM

SYSTEM REINFORCEMENT

The posiAon of the firewall in the network topology hUp://net.anquan365.com/equipment/firewall/201110/166360.html

Basic funcAon modules

NAT

VPN

Log

IDS & Warning

Content Filtering

User Authen/ca/on

Applica/on Proxy

Packet-‐filtering& State inspec/on

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

hUp://www.huaxintong.com/^q_sc.asp

（Hardware firewall）

home users office small enterprise large and medium enterprises campus network

price

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

•  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.

Improvement for Cisco

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.

3

1 2

4 5 6 7

Security Policy “First” Rule

Security Policy “Before Last” Rule

Security Policy “Last” Rule

Implicit Drop

IP Spoofing / IP Op/ons / State Table

mail-svr smtp accept Short fw tcp

Any Any accept Short fw

3 Any Any Any drop Long fw Last Rule In Rule Base

1

local-net 2

Any Rule Base

Match order

Policies and rules are matched in order on the Rule Base, one rule at a Ame.

ACL match order

1、SIP DIP Sport Dport Accept\Drop




…………………………………………….

n、SIP DIP Sport Dport Accept\Drop

OUT

IN

AcAve Control List （

ACL ）

Match O

rder——Seq N

umber

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？

Firewall Configuration Errors Revisited-1

Documents

Transcript of Firewall Configuration Errors Revisited-1