Automatic Verification of Firewall Configuration with
Respect to Security Policy Requirements
Soutaro Matsumoto1 and Adel Bouhoula2
1
Graduate School of System and Information Engineering
University of Tsukuba – Japan
[email protected]
2
Higher School of Communication of Tunis (Sup'Com)
University of November 7th at Carthage – Tunisia
[email protected]
Abstract. Firewalls are key security components in computer networks. They filter network
traffics based on an ordered list of filtering rules. Firewall configurations must be correct and
complete with respect to security policies. Security policy is a set of predicates, which is a high
level description of traffic controls. In this paper, we propose an automatic method to verify the
correctness of firewall configuration. We have defined a boolean formula representation of
security policy. With the boolean formula representations of security policy and firewall configuration, we can formulate the condition that ensures correctness of firewall configuration.
We use SAT solver to check the validity of the condition. If the configuration is not correct, our
method produces an example of packet to help users to correct the configuration. We have
implemented a prototype verifier and had some experimental results. The first results were very
promising.
Keywords: Firewall Configuration, Security Policy, Automatic Verification, SAT Solver.
1 Introduction
Firewalls are key security components in computer networks. They filter packets to
control network traffics based on an ordered list of filtering rules. Filtering rules describe which packet should be accepted or rejected. Filtering rules consist of a pattern
of packet and an action. Firewalls reject / accept packets if the first rule which
matches the packet in their configurations rejects / accepts the packet. Security policies are high-level description of traffic controls. They define which connection is
allowed. They are sets of predicates. Security policies reject / accept connections if
the most specific predicate which matches the connection rejects / accepts the connection. Firewalls should be configured correctly with respect to security policies. Correct configurations reject / accept connections if and only if security policies reject /
accept the connections. However, the correctness of firewall configurations is not
obvious.
Consider for example the following security policy.
1. All users in LAN can access Internet
2. All users in LAN1 cannot access youtube.com
3. All users in LAN2 can access youtube.com
E. Corchado et al. (Eds.): CISIS 2008, ASC 53, pp. 123–130, 2009.
© Springer-Verlag Berlin Heidelberg 2009
springerlink.com
124
S. Matsumoto and A. Bouhoula
Fig. 1. Structure of the Network
There are three predicates. Assume that we have a network LAN, two sub networks LAN1 and LAN2, and there is a website youtube.com in the Internet. The
structure of the networks is shown in figure 1. The first predicate is the most general
one that allows all users in LAN to access any web site in the Internet. The Second
predicate is more specific than the first predicate which prohibits users in LAN1 to
access youtube.com. Third predicate allows users in LAN2 to access youtube.com. Under this security policy, users in LAN1 cannot access youtube.com. Since the second predicate is the most specific for a connection from
LAN1 to youtube.com, the connection will be rejected.
Consider for example the following firewall configuration in Cisco’s format.
access-list 101 permit tcp 192.168.0.0
any
access-list 102 reject tcp 192.168.1.0
233.114.23.1
access-list 103 permit tcp 192.168.2.0
233.114.23.1
0.0.255.255
eq 80
0.0.0.255
0.0.0.0
0.0.0.255
0.0.0.0
eq 80
eq 80
There are three rules named 101, 102, and 103. Rule 101 permits connections from
192.168.*.* to any host. * is wildcard. Rule 102 rejects packets from 192.168.1.* to
233.114.23.1. Rule 103 permits packets from 192.168.2.* to 233.114.23.1. Assume
that the network LAN has address 192.168.*.*, LAN1 and LAN2 have 192.168.1.*
and 192.168.2.* respectively, and youtube.com has address 233.114.23.1. This
configuration can read as a straightforward translation of the security policy. Unfortunately, this configuration is incorrect. Since the first rule that matches given connection will be applied, a connection from LAN1 matches the first rule and it will be
accepted even if the destination is youtube.com.
We propose a method to verify the correctness of firewall configurations with respect to security policies. Security policy P and firewall configuration F are translated
into boolean formulae QP and QF. The correctness of firewall configuration is reduced
to the equivalence of the two formulae. The equivalence of the two formulae is
checked by satisfiability of QP ⇎ QF. If the formula is satisfiable, QP and QF are not
equivalent and F is not correct. A counterexample of packet will be produced such
that P and F will give different answers for the packet. The counterexample will help
users to find and correct mistakes in their configurations.
1.1 Related Work
There are a lot of works about development of formal languages for security policy
description [1, 2]. Our formalization of security policy is very abstract, but essentially
Automatic Verification of Firewall Configuration
125
equivalent to them. The works are so technical that we simplified the definition of
security policy.
There are some works for efficient testing of firewalls based on security policies
[3, 4]. Their approaches generate test cases from security policy and then test networks with the test cases. Our method only verifies the correctness of the configuration of firewall. The simplification makes our method very simple and fast. The
essence of our method is the definition of boolean formula representation. Other steps
are applications of well-known logical operations. The fact that our method is performed on our computers makes verifications much faster and easier than testing with
sending packet to real networks. This also makes possible to use SAT solvers to prove
the correctness.
Detecting anomalies in firewall configurations is also important issue [5]. Detection of anomalies helps to find mistakes in configuration, but it does not find mistakes
by itself.
Hazelhurst has presented a boolean formula representation of firewall configuration, which can be used to express filtering rule [6]. The boolean formula representation can be simplified with Binary Decision Diagram to improve the performance of
filtering. In this paper, we use the boolean formula representations of firewall configuration and packets.
2 Security Policy and Firewall Configuration
We present a formal definition of security policy and firewall configuration. The
definitions are very abstract. We clarify the assumptions of our formalization about
security policy.
2.1 Security Policy
Security policy is a set of policy predicates. Policy predicates consist of action, source
address, and destination address. Actions are accept or deny.
The syntax of security policy is given in figure 2. policy is a set of predicate. A
predicate consists of action K, source address, and destination address. Action K is
accept A or deny D. A predicate A(s, d) reads Connection from s to d is accepted. A
predicate D(s, d) reads Connection from s to d is denied. Network address is a set.
Packets are pairs of source address and destination address. Packet p from source
address s to destination address d will match with predicate K(s’, d’) if and only if s
⊆ s' ⋀ d ⊆ d' holds.
We have a partial order relation ⊒ on policy predicates.
K(s, d) ⊒ K’(s’, d’) ⇔ s ⊇ s’ ⋀ d ⊇ d’
If q ⊒ q’ holds, q is more general than q' or q' is more specific than q.
Packet p is accepted by Security Policy P if the action of the most specific policy
predicate that matches with p is A, and p is rejected by P if the action of the most
specific policy predicate which matches with p is D.
126
S. Matsumoto and A. Bouhoula
policy
predicate
address
K
::=
::=
::=
::=
|
{ predicate, …, predicate }
K(address, address)
Network Address
A
D
Accept
Deny
Fig. 2. Syntax of Security Policy
configuration
rule
address
K
::=
::=
::=
::=
|
rule :: configuration | φ
K(address, address)
Network Address
A
D
Accept
Deny
Fig. 3. Syntax of firewall configuration
Example. The security policy we have shown in section 1 can be represented as
P = { q1, q2, q3 } where q1, q2 and q3 are defined as follows:
1. q1 = A(LAN, Internet)
2. q2 = D(LAN1, youtube.com)
3. q3 = A(LAN2, youtube.com)
We have ordering of policy predicates q1 ⊒ q2 and q1 ⊒ q3.
Assumptions. To ensure the consistency of security policy, we assume that we can
find the most specific policy predicate for any packet. We assume that the following
formula holds for any two different predicates K(s, d) and K’(s’, d’).
s × d ⊇ s’ × d’
⋁
s × d ⊆ s’ × d’
⋁ s × d ∩ s’ × d’ = φ
Tree View of Security Policy. We can see security policies as trees, such that the
root is the most general predicate and children of each node is set of more specific
predicates. We define an auxiliary function CP(q) which maps predicate q in security
policy P to the set of its children.
CP(q) = { q’ | q’ ∈ P ⋀ q ⊒ q’ ⋀ ¬(∃q’’ ∈ P . q ⊒ q’’ ⋀ q’’ ⊒ q) }
For instance, CP(q) = { q2, q3 } and CP(q2) = CP(q3) = φ for the previous example.
2.2 Firewall Configuration
The syntax of firewall configuration is given in figure 3. Configurations of firewalls
are ordered lists of rules. Rules consist of action, source address, and destination address. Actions are accept A or deny D.
Automatic Verification of Firewall Configuration
127
A packet is accepted by a firewall configuration if and only if the action of the first
rule in the configuration that matches with source and destination address of packet is
A. The main difference between security policies and firewall configurations is that
rules in firewalls form ordered list but predicates in security policies form trees.
3 Boolean Formula Representation
We present a boolean formula representation of security policy and firewall configuration in this section. This section includes also a boolean formula representation of
network address and packet. In the previous section, we did not define concrete representation of network addresses and packets.1
The boolean formula representations of network address and firewall configuration
are proposed by Hazelhurst [6].
3.1 Boolean Formula Representation of Network Addresses and Packets
Network addresses are IPv4 addresses. Since IPv4 addresses are 32 bit unsigned
integers, we need 32 logical variables to represent each address. IP addresses are
represented as conjunction of 32 variables or their negations, so that each variable
represents a bit in IP address. If the ith bit of the address is 1 then variable ai should
evaluate true. For example an IP address 192.168.0.1 is represented as the following.
a32 ⋀ a31 ⋀ ¬a30 ⋀ ¬a29 ⋀ ¬a28 ⋀ ¬a27 ⋀ ¬a26 ⋀ ¬a25 ⋀
a24 ⋀ ¬a23 ⋀ a22 ⋀ ¬a21 ⋀ a20 ⋀ ¬a19 ⋀ ¬a18 ⋀ ¬a17 ⋀
¬a16 ⋀ ¬a15 ⋀ ¬a14 ⋀ ¬a13 ⋀ ¬a12 ⋀ ¬a11 ⋀ ¬a10 ⋀ ¬a9 ⋀
¬a8 ⋀ ¬a7 ⋀ ¬a6 ⋀ ¬a5 ⋀ ¬a4 ⋀ ¬a3 ⋀ ¬a2 ⋀ a1
Here, a1 is the variable for the lowest bit and a32 is for the highest bit.
«p» is an environment, which represents packet p. Packets consist of source address
and destination address. We have two sets of boolean variables, s = { s1, …, s32} and d
= { d1, …, d32 }. They represent source address and destination address of a packet
respectively. If packet p is from address 192.168.0.1, «p»|s is the following.
{ s32 ↦ T, s31 ↦ T, s30 ↦ F, s29 ↦ F, s28 ↦ F,
s24 ↦ T, s23 ↦ F, s22 ↦ T, s21 ↦ F, s20 ↦ T,
s16 ↦ F, s15 ↦ F, s14 ↦ F, s13 ↦ F, s12 ↦ F,
s8 ↦ F, s7 ↦ F, s6 ↦ F, s5 ↦ F, s4 ↦ F,
s27 ↦ F, s26 ↦ F, s25 ↦ F,
s19 ↦ F, s18 ↦ F, s17 ↦ F,
s11 ↦ F, s10 ↦ F, s9 ↦ F,
s3 ↦ F, s2 ↦ F, s1 ↦ T,
}
«p» also includes assignments of d for destination address of p.
‹a, b› is a boolean formula such that «p» ⊢ ‹a, b› holds if and only if packet p is
from a to b. ‹192.168.0.1, b› is like the following boolean formula.
s32 ⋀ s31 ⋀¬ s30 ⋀ ¬s29 ⋀ ¬s28 ⋀ ¬s27 ⋀ ¬s26 ⋀ ¬s25 ⋀ …
1
Without loss of generality, we have a simplified representation of network addresses. We can
easily extend this representation to support net-masks, range of ports, or other features as proposed by Hazelhurst.
128
S. Matsumoto and A. Bouhoula
This is the only eight components of the formula. They are the same as the highest
eight components of boolean formula representation of IP address 192.168.0.1.
3.2 Boolean Formula Representation of Security Policy
Security Policy P can be represented as boolean formula QP, such that ∀p : Packet . P
accept p ⇔ «p» ⊢ QP holds. We define a translation BP(q, β) which maps a policy
predicate q in security policy P to its boolean formula representation.
BP(A(a, b), T)
=
BP(A(a, b), F)
=
BP(D(a, b), T)
=
BP(D(a, b), F)
=
¬‹a, b› ⋁ (T ⋀ q∈C BP(q, T))
‹a, b› ⋀ (⋀ q∈C BP(q, T))
¬‹a, b› ⋁ (⋁q∈C BP(q, F))
‹a, b› ⋀ (T ⋁ q∈C BP(q, F))
where C = CP(q)
We can obtain the boolean formula representation of security policy P as BP(q, F)
where q is the most general predicate in P.
Example. The following is an example of transformation from security policy P in
section 2 to its boolean formula representation. The boolean formula representation of
P is obtained by BP(q1, F) since q1 is the most general predicate.
BP(A(LAN, Internet), F) = ‹LAN.Internet› ⋀ BP(q2, T) ⋀ BP(q3,T)
BP(D(LAN1, youtube.com), T) = ¬‹LAN1.youtube.com›
BP(A(LAN2, youtube.com), T) = ‹LAN2.youtube.com› ⋁ T
Finally we have the following formula after some simplifications.
‹LAN.Internet› ⋀ ¬‹LAN1.youtube.com›
Consider a packet from LAN1 to youtube.com, the first component in the formula
evaluates true, but the second component evaluates false. Whole expression evaluates
false, so the packet is rejected.
3.3 Boolean Formula Representation of Firewall Configuration
Firewall configuration F can be represented as boolean formula QF, such that ∀p:
Packet . F accept p ⇔ «p» ⊢ QF holds. B(F) is a mapping from F to QF.
B(φ)
B(A(a, b) :: rules)
=
=
B(D(a, b) :: rules)
‹a, b› ⋁ B(rules)
=
¬‹a, b› ⋀ B(rules)
F
4 Experimental Results
We have implemented a prototype of verifier. The verifier reads a security policy and
a firewall configuration, and verifies the correctness of the configuration. It supposes
Automatic Verification of Firewall Configuration
129
that we have IPv4 addresses with net-masks and port numbers of 16 bit unsigned
integer with range support. The verifier uses MiniSAT to solve SAT [7].
In our verifier packets consist of two network addresses and protocol. Network addresses are pair of a 32 bit unsigned integer which represents an IPv4 address and a
16 bit unsigned integer which represents a port number. The protocols are TCP, UDP,
or ICMP. Thus, a formula for one packet includes up to 99 variables – two 32+16
variables for source and destination addresses and three variables for protocol.
We have verified some firewall configurations. Our experiments were performed
on an Intel Core Duo 2.16 GHz processor with 2 Gbytes of RAM. Table 1 summarizes our results. The first two columns show the size of inputs. It is the numbers of
predicates in security policy and the numbers of filtering rules in firewall configuration. The third column shows the size of the input for SAT solver. The last column
shows the running times of our verifier. It includes all processing time from reading
the inputs to printing the results. All of the inputs were correct because it is the most
time consuming case. These results show that our method verifies fast enough with
not so big inputs.
If configurations are not correct, then the verifier produces a counterexample packet. The following is an output of our verifier that shows a counterexample.
% verifyconfig verify ../samples/policy.txt ../samples/rules.txt
Loading policy ... ok
Loading configuration ... ok
Translating to CNF ... ok
MiniSAT running ... ok
Incorrect: for example [tcp - 192.168.0.0:0 - 111.123.185.1:80]
The counterexample tells that the security policy and firewall configuration will give
different answers for a packet from 192.168.0.0 of port 0 to 111.123.185.1
of port 80. Testing the firewall with the counterexample will help users to correct the
configuration.
Table 1. Experimental Results
# of predicates
3
13
26
# of rules
3
11
21
size of SAT
9183
21513
112327
running time (s)
0.04
0.08
0.37
5 Conclusion
In this paper, we have defined a boolean formula representation of security policy,
which can be used in a lot of applications. We have also proposed an automatic
method to verify the correctness of firewall configurations with respect to security
policies. The method translates both of the two inputs into boolean formulae and then
verifies the equivalence by checking satisfiability. We have had experimental results
with some small examples using our prototype implementation.
Our method can verify the configuration of centralized firewall. We are working
for generalization of our method for distributed firewalls.
130
S. Matsumoto and A. Bouhoula
References
1. Hamdi, H., Bouhoula, A., Mosbah, M.: A declarative approach for easy specification and
automated enforcement of security policy. International Journal of Computer Science and
Network Security 8(2), 60–71 (2008)
2. Abou El Kalam, A., Baida, R.E., Balbiani, P., Benferhat, S., Cuppens, F., Deswarte, Y.,
Miége, A., Saurel, C., Trouessin, G.: Organization Based Access Control. In: 4th IEEE International Workshop on Policies for Distributed Systems and Networks (Policy 2003)
(June 2003)
3. Senn, D., Basin, D.A., Caronni, G.: Firewall conformance testing. In: Khendek, F., Dssouli,
R. (eds.) TestCom 2005. LNCS, vol. 3502, pp. 226–241. Springer, Heidelberg (2005)
4. Darmaillacq, V., Fernandez, J.C., Groz, R., Mounier, L., Richier, J.L.: Test generation for
network security rules. In: Uyar, M.Ü., Duale, A.Y., Fecko, M.A. (eds.) TestCom 2006.
LNCS, vol. 3964, pp. 341–356. Springer, Heidelberg (2006)
5. Abbes, T., Bouhoula, A., Rusinowitch, M.: Inference System for Detecting Firewall Filtering Rules Anomalies. In: Proceedings of the 23rd Annual ACM Symposium on Applied
Computing, Fortaleza, Ceara, Brazil, pp. 2122–2128 (March 2008)
6. Hazelhurst, S.: Algorithms for analysing firewall and router access lists. CoRR
cs.NI/0008006 (2000)
7. Eén, N., Sörensson, N.: An extensible sat-solver. In: Giunchiglia, E., Tacchella, A. (eds.)
SAT 2003. LNCS, vol. 2919, pp. 502–518. Springer, Heidelberg (2003)