Firewall Configura/on Errors Revisited

(1)

Firewall Conﬁgura/on Errors Revisited

Lecturer: Dr. Tom Chothia

AvishaiWool

Presenter: BINBIN HU

(2)

Content

•

IntroducAon

•

Preparatory work& Data collecAon

•

Measure method

•

Data analysis

(3)

IntroducAon

•

The deﬁniAon of the ﬁrewall

•

The posiAon of the ﬁrewall

•

Basic funcAon modules

•

Design goals for a ﬁrewall

(4)

1.CorporaAon Firewall——the ﬁrst line of

the cyber-‐defense

1.1 What is ﬁrewall？

•  Firewall：A ﬁrewall 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.

(5)

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

(6)

The posiAon of the ﬁrewall in the network topology

(7)

Basic funcAon modules

NAT VPN Log IDS & Warning Content Filtering User Authen/ca/on Applica/on Proxy

(8)

Design goals for a ﬁrewall

•  1. All traﬃc from inside to outside, and vice versa,

must pass through the ﬁrewall.

•  2. Only authorized traﬃc, as deﬁned by the local

security policy, will be allowed to pass.

(9)

1.2 Some familiar ﬁrewalls

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

（Hardware ﬁrewall）

home users oﬃce small enterprise large and medium enterprises campus network

pr

ic

(10)

Checkpoint(SoQware ﬁrewall)

(11)

(12)

Preparatory work& Data collecAon

•

The most important factor of the ﬁrewall

security

•

Firewall conﬁguraAon test

•

The goal for this work

•

New features of this study

(13)

2. The most important factor of the

ﬁrewall security is

how you conﬁgure it

•

The protecAon that these ﬁrewalls provide is

only as good as the policy they are conﬁgured

to implement.

•

For well-‐conﬁgured ﬁrewalls

(14)

2.1Firewall conﬁguraAon test

•

The network aUack is the best way to test the

ﬁrewall conﬁguraAon.

•

Before aUacking, an important technology

(15)

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

(16)

•

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

(17)

•

The poor state of ﬁrewall conﬁgura?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

conﬁgured ﬁrewall.

——So this provided a quanAtaAve evaluaAon of

the quality of corporate ﬁrewall conﬁguraAons.

This state of aﬀairs was validated in a 2004 study, the author of this paper claimed that the arguments are s?ll valid.

(18)

2.2The goal for this work

•

To test the hypothesis—— the quality of

corporate ﬁrewall conﬁguraAons has improved

over Ame.

•

To check whether the ﬁndings of

“A quan?ta?ve

study of ﬁrewall conﬁgura?on errors,(2004) “

are sAll

valid.

2004 study’s main observaAons: (a) ﬁrewalls are poorly conﬁgured

(b) a rule-‐set’s complexity is posiAvely correlated with the number of detected conﬁguraAon errors

(19)

2.3New features of this study

•  To address some possible criAques, such as: the sample used

before was not indicaAve; the detected problems were speciﬁc only to one vendor.

•  This study has the following features:

(1)collected from ﬁrewalls running later ﬁrewall 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

(20)

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, ﬁnancial, 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 conﬁguraAon errors

examples： Inbound HTTP to 256+ IPs "To Any allow Any service" rules Outbound SMTP from 256+ IPs

(21)

Check Point ﬁrewalls

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) deﬁned in the database supporAng the rules. #Interfaces counts the number of network interface cards on the ﬁrewall.

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)

(22)

Cisco PIX ﬁrewalls

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)

(23)

Measure method

•

Previous method—— RC

•

The analysis of objects

•

The defect of RC

•

The new measure ——FC

(24)

3

The measure of ﬁrewall complexity

The research method used previous is RC.

•  RC deﬁned 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 ﬁrewall

•  The study object for RC is only Checkpoint Firewalls.

Now this method is inappropriate in this search,

(25)

3.1The analysis of objects

•  Objects of study（Checkpoint FW1and Cisco PIX）

•  Main diﬀerences

•  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

(26)

(27)

(28)

(29)

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 ﬁrewalls has

more than 18 interfaces (the median number was

4), but Check Point ﬁrewalls 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.

(30)

3.3The new measure ——FC

•

FC is an evoluAon of RC.

•

Goals of improvement

：

CompaAbility —— for Cisco

(31)

•  For Cisco PIX ﬁrewalls, the simplest measure of

complexity is the number of lines in the conﬁguraAon ﬁle.

•  The raw number of lines to be slightly misleading,

especially for very small conﬁguraAons. This is

because even the smallest Cisco PIX conﬁguraAon ﬁle includes a few tens of “boilerplate” lines that have

liUle to do with traﬃc ﬁltering.

(32)

FCp index

（

For Cisco

）

•

Let #Lines denote the number of lines in the

ASCII ﬁle containing the complete Cisco PIX

configuraAon file. Then the firewall complexity

of a Cisco PIX ﬁrewall is:

(33)

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 ﬁrewall. Then the ﬁrewall complexity of a Check Point

FireWall-‐1 ﬁrewall is:

(34)

Through the FC index two kinds of ﬁrewall 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 ﬁrewall has higher complexity

(35)

3.4 The selecAon of conﬁguraAon 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 ﬁrewall.

•  The angle of the selecAon: Errors are all violaAons of

(36)

SelecAon criteria

•  To avoid inﬂaAng the error counts(a single badly

wriUen rule may trigger mulAple counted errors), a more speciﬁc 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 conﬁguraAon 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.

(37)

Error categories

•  inbound traﬃc(i): Errors cover things such as allowing Any

traﬃc 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 traﬃc(o): Most of these deal with services that

are considered to be risky in all direcAons. And counted errors for indiscriminate outbound e-‐mail traﬃc (again using the noAon of a thresholds) and for IRC.

•  internal traﬃc(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

(38)

4.Data Analysis

(39)

3

1

2

4

5

6

7

Security Policy “First” Rule

Security Policy “Before Last” Rule

Security Policy “Last” Rule

Implicit Drop

IP Spooﬁng / IP Op/ons / State Table

mail-svr tcp smtp accept Short fw

Any Any accept Short fw

3 Any Any Last Rule In Rule BaseAny drop Long fw

1 local-net 2 Any Rule Base

Match order

(40)

ACL match order

1、_{SIP DIP Sport Dport Accept\Drop}

……….

n、_{SIP DIP Sport Dport Accept\Drop}

OUT IN Ac Av e C on tr ol Lis t_（ AC L_） Ma tch O rd er— — Se q N umbe r

(41)

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 ﬁt, and the green and purple lines represent one standard deviaAon above and below the least-‐squares ﬁt.

(42)

•

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.

(43)

(44)

conclusion

•  Firewall complexity (FC) measure applies to both

ﬁrewalls brands and probably to others as well.

•  Firewalls are (sAll) poorly conﬁgured.

•  The eﬀect of the soQware version on the number of

conﬁguraAon errors is insigniﬁcant.

•  In general Cisco PIX ﬁrewalls seem to exhibit fewer

errors than CheckPoint ﬁrewalls.

•  A rule-‐set’s complexity is (sAll) posiAvely correlated

with the number of detected conﬁguraAon errors.

Thus we can conclude that, for well-‐conﬁgured ﬁrewalls, “small is (s?ll) beau?ful”.

(45)

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

！