VERIFICATION OF DISTRIBUTED FIREWALLS CONFIGURATION VS. SECURITY POLICIES USING ℒℐ()

Abstract

Packet filtering firewalls have an important role in providing security in IP networks which control the traversal of packets across the boundaries of a secured network based on a specific security policy. Manual configuring of packet filtering firewalls can be extremely complex and error-prone. Therefore, it can be performed in an improper way which is not in conformance with security policies. So, we need an approach to analyze the configuration of whole packet-filtering firewalls in the network in order to discover all policy violations. In this article, we introduce an approach based on description logics to verify the configuration of all the firewalls in a network universally vs. security policies. Using this approach, system managers can express and analyze security policies with a formal and simple language. This high-level language is extensible and topology-independent. In this approach, we first automatically transform high-level security policies into low-level policies, i.e., filtering rules. Then we develop an algorithm to discover policy violations which takes configuration of the firewalls, network topology, routing information, and low-level security policies as input and determines existing policy violations as output.

Access control policies support security by preventing unauthorized access to resources that can be enforced locally or in a distributed way by coordination of several systems. In the network, packet filtering firewalls work together to enforce service access control policies. Unfortunately, configuring these systems is often a manual, ad hoc, and error-prone process while incorrect or inconsistent configurations can lead to significant vulnerabilities. Particularly, due to the decentralized nature of access control policies in distributed firewalls, the potential of violations increases significantly. Therefore, to ensure that the firewalls in a network have appropriate behavior and compliance with security policies, we should verify configuration of whole firewalls in the network vs. security policies.

Although firewall security has been given strong attention in the research community (e.g., work done on firewall policy transformation techniques (Avishai, 2001; Bartal, Mayer, Nissim, and Wool, 1999; Cuppens, Cuppens-Boulahia, Miege, and Sans, 2004; Mayer, Wool, and Ziskind, 2000; Uribe and Cheung, 2004) or policy conflict analysis (Al-Shaer and Hamed, 2003; Al-Shaer and Hamed, 2004; Al-Shaer and Hamed, 2006; Al-Shaer, Hamed, Boutaba, and Hasan, 2005; Hari, Suri, and Parulkar, 2000; Yuan et al., 2006), few related work (Guttman, 1997; Liu, 2008) attempt to verify the configuration of firewalls. Guttman (1997) proposed an approach to check whether filtering operations at routers are conformance with security policies or not. In this approach, firewall configurations are considered only as a logical description of the filtering to be done at each firewall which makes it impractical to use in widely used firewalls with low-level filtering rules. Also, Liu (2008) introduced an approach for verification of the firewall configuration, but it was restricted to verification of the configuration of one firewall and it does not deal with verification of the configuration of distributed firewalls. Therefore, we need to provide policy management techniques that network administrators can use to analyze, purify, and verify the correctness of the filtering rules of distributed firewall. We consider our work as a significant progress in the area of verification of the configuration of distributed firewalls vs. high-level security policies as it offers a novel and comprehensive framework to automate checking the correctness of the configuration of all the firewalls in the network.

Although formal methods are useful for reasoning about knowledge, they are usually awkward to use by system managers. Therefore, we attempt to use a formal yet simple formalism which is based on description logics (DLs). Description logics are a family of knowledge representation approaches introduced mainly for eliminating the drawbacks and ambiguities of frames and semantic networks. This family of formalisms has formal and logic-based semantics. In addition, a class-based basis of DLs has made them simple to use. ℒℐ() is an expressive yet decidable DL (Baader, McGuinness, Nardi, and Patel-Schneider, 2003) with some tools to support it, such as RACER (Haarslev and Möller, 2001), which is used as our formalism in this research.

In the present article, we introduce an approach for verification and analysis of service access control policies (hereafter called high-level security policies). First, security policies are formalized using a formal yet simple language that is based on ℒℐ(). Afterward, high-level security policies are transformed automatically to a set of low-level policies. Then, the configuration of the firewalls are gathered and formalized automatically. An algorithm gets the network topology, routing information, low-level security policies, and the formal configuration of the firewalls as input and checks whether configurations are in compliance with security policies or not. Capturing the rule order as well as automatic formalizing of the configuration are the main contrasts of our approach with the other ones which make it practical and straightforward to use in concrete systems.

DESCRIPTION LOGICS

Description logics form a family of languages to model an application by means of concepts and roles which denote classes of objects and binary relations between objects, respectively.

Knowledge Base

A DL knowledge base ℬ = 〈, 〉 typically consists of a TBox, , and an ABox, .  contains intentional knowledge in the form of concept and role axioms. The axioms describe general properties of concepts and roles, while  contains assertional knowledge that is specific to the individuals of the domain of interest.

DL Interpretation

In order to define formal semantics of DLs, we consider interpretation I = (Δ ^I , f ^I ) that consists of a nonempty set Δ ^I (the abstract domain of I) and an interpretation function f ^I . Interpretation function maps:

	each concept name C to a subset C I  ⊆ Δ I (the set of instances of C)
	each role name R to a subset R I ⊑Δ I  × Δ I (the set of instances of R)
	each instance name i to an element i I of Δ I .

TBox Axioms

The terminological axioms in  make statements about how concepts or roles are related to each other and consist of concept and role axioms. Basic concept axioms have the form C ≡ D (equivalency) and C⊑D (inclusion or subsumption), where C and D are concepts. An interpretation ℐ satisfies an equivalency axiom C ≡ D iff C ^I  = D ^I , and it satisfies an inclusion axiom C⊑D iff C ^I ⊑D ^I . Equivalency axioms describe sufficient and necessary conditions of individuals to be an instance of C and is equal to C⊑D and D⊑C, while inclusion axioms merely describe necessary conditions. Furthermore, two concepts C and D are disjoint iff C ^I ∩ D ^I  = φ, in other words C⊑ ¬ D.

ABox Assertions

ABox assertions have the forms of C(a) or R(b, c). By the first kind, called concept assertion, one states that instance a belongs to concept C. By the second one, called role assertions, one states that instance c is a filler of the role R for instance b.

Reasoning Services

The standard reasoning tasks provided in DL at the TBox level are subsumption, concept consistency, and knowledge base consistency. A concept C is consistent in , if there is a model for ℬ, in which C has a nonempty interpretation. A knowledge base ℬ is consistent, if there exists a model for ℬ.

An important reasoning service for an ABox is checking ABox consistency, i.e., checking whether an ABox has a model. Another significant reasoning is instance checking to verify whether an instance belongs to a specific concept or not.

ℒℐ()

ℒℐ() supports reasoning on concrete domains. So, let us first define a concrete domain formally.

Definition 1

A concrete domain D consists of a set Δ ^D , the domain of D, and a set pred(D), the predicate names of D. Each predicate name p ∊ pred(D) is associated with an arity n, and an n-ary predicate P ^D  ⊆ (Δ ^D ) ⁿ . For example, the concrete domain N has the set N of all nonnegative integers as its domain, and pred(N) consists of the binary predicate names <, ≤, >, ≥, = as well as the unary predicate names < _n , ≤ _n , > _n , ≥ _n , = _n for n ∊ N which are interpreted by predicates on N (Baader et al., 2003).

In ℒℐ(), the concepts are formed according to the following syntax, where A and S denote an atomic concept and an atomic role, respectively, and C and D are arbitrary concepts. In addition, R is an arbitrary role, n is a positive integer, and u _i , 1 ≤ i ≤ m is a feature. A feature (called attribute or functional role) is a role that associates an instance to only one instance and is mapped to a partial function u: Δ ^I  → Δ ^D  ∪ Δ ^I by interpretation function.

The interpretation function f ^I defined for ℒℐ() is shown in Table 1.

TABLE 1 Interpretation Function of ℒℐ()

Name	Syntax	Semantics
Concept Constructs
Top	T	Δ^I
Bottom	⊥	ϕ
Negation	¬C	Δ^I\C ^I
Intersection	C ⊓ D	C ^I ∩ D ^I
Union	C ⊔ D	C ^I ∪ D ^I
Existential quantification	∃R.C	{O ∊ Δ^I|∃ O′, (O, O′) ∊ R ^I ∧ O′ ∊ C ^I}
Qualified at-least restriction	∃ ^≥n R.C	{O ∊ Δ^I|#{O′|(O, O′) ∊ R ^I ∧ O′ ∊ C ^I} ≥ n}
Universal quantification (value restriction)	∀R.C	{O ∊ Δ^I|∀ O′, (O, O′) ∊ R ^I ⇒ O′ ∊ C ^I}
Role Constructs
Inverse	S	{(O, O′) ∊ Δ^I × Δ^I|(O′, O) ∊ S ^I}
Concrete Domain Constructs
Existential predicate restriction	∃(u 1,…, u n ).P	O ∊ Δ^I|∃ r 1,…, r n  ∊ Δ^D,
Universal predicate restriction	∀(u 1,…, u n ).P	O ∊ Δ^I|∀ r 1,…, r n  ∊ Δ^D,

ℒℐ() has provided role restriction constructs including quantified role restrictions and number restrictions. A quantified role restriction is composed of a quantifier (existential or universal), a role, and a concept expression. Quantified role restrictions allow us to represent the relationships existing between the objects in two concepts. For an example, we can characterize the set of objects whose children are male as ∀ child.Male and the set of objects that have at least one male child as ∃ child.Male. Number restrictions are used to constrain the number of fillers, i.e., the objects that are in a certain relationship with a given object. For example, ∃⁼² child.Male characterizes a set of parents with exactly two male children.

RUNNING CASE STUDY

To be able to present our approach more clearly, our approach is illustrated using a small case study throughout this article. Explaining different phases of the proposed approach using a complex example needs much more space, therefore we restrict ourselves to describe the proposed approach using a simplified case study. Let's consider an imaginary corporation with a network topology shown in Figure 2. There are two firewalls that separate zones. The external firewall guards the corporation's Internet connection. Behind is the DMZ containing the corporation's externally visible servers that provide HTTP and DNS services. Behind the DMZ is the internal firewall, which protects the corporation's intranet. Within the private network zone, there is a distinguished host, Admin, which provides the administration for the servers in the DMZ and firewalls. Furthermore, there is an internal server in this zone to provide ftp and web services for the intranet hosts.

FIGURE 1 ℒℐ() grammar.

FIGURE 2 A typical network topology.

Our policy goals are as follows:

	The administrator must configure servers via secure channels and using insecure channels for updating the servers is not permitted.
	The company owns proprietary information that only intranet users can access.
	External hosts can access DMZ servers including DNS and web servers.
	Telnet service is only permitted for the system administrator.
	Intranet users can access all resources from the internet.
	Other access is not allowed.

Table 2 shows the ruleset of interface Ieth0/0 of the internal firewall. The rulesets of the other interfaces are presented in Appendix A.

TABLE 2 The Ruleset of Ieth0/0

Source address	Destination address	Protocol	Source port	Destination port	Action	Direction
14.2.10.1	∗	TCP	∗	22	Permit	∗
14.2.10.1	14.2.9.2	TCP	∗	443	Permit	Out
14.2.10.1	14.2.9.3	TCP	∗	443	Permit	Out
∗	14.2.10.2	TCP	<1000	80	Deny	∗
14.2.9.∗	∗	TCP	∗	∗	Permit	Out
14.2.10.1	14.2.9.2	TCP	∗	23	Permit	Out
∗	∗	TCP	∗	∗	Deny	Out

TABLE 3 The Statistics of Case Study

Feature	Value
Number of network roles	42
Number of workstation	159
Number of firewalls	7
Average ruleset length	20
Number of high-level security policies	16

OVERALL APPROACH

In this section, we provide a brief overview of the proposed approach which will be elaborated in more detail in subsequent sections. The proposed approach is composed of five phases as follows:

Defining network topology and network roles (Phase 1) , where we describe network roles as well as network topology formally. Definition of network topology includes definition of services, specification of the devices, and the roles that each device has in the network.

Producing formal configuration (Phase 2) , where configuration of whole firewalls in the network are gathered. As the syntax and semantics of the configuration of various firewalls are likely different, we first transform the firewalls configuration into an intermediatory format manually. Afterward, the formal specification of the configuration is produced automatically using the configuration described in the intermediatory format, the formal description of the network topology, and the formalized network services. In this phase, we can detect rule anomalies within a single firewall and between interconnected firewalls in the network.

Formalizing and analyzing policies (Phase 3) , in which we first formalize high-level security policies through a simple language based on DL. Then, using some reasoning services provided by DL like knowledge-base consistency, we investigate security policies to discover any inconsistency. The conflicts among policies can be resolved by assigning priority to them. Furthermore, existing DL systems can extract concepts hierarchy automatically according to the definition of concepts which enables us to find out redundant policies.

Transformation (Phase 4) , which is devoted to transform high-level policies to a set of rules that are described formally. In this article, we refer to these rules as low-level policies. The produced low-level policies are used to verify the configuration of distributed firewalls vs. high-level security policies in phase 5.

Verification (Phase 5) , in which an algorithm gets formal description of the configuration of all firewalls in the network, i.e., formalized rulesets, low-level policies, and routing information as input and checks whether the firewalls' configuration is in compliance with security policies or not.

We implemented a tool named the FPoVer (Firewall Policy Verifier) system to support our approach. FPoVer uses RACER (Haarslev and Möller, 2001) to carry out its reasoning tasks. Main components of FPoVer are shown in Figure 3. The topology manager module is used to define network roles, services, and network topology formally. This component also computes the path between two nodes based on the routing information. The rule engine gets informal configuration of firewalls and produces their formal specification automatically. Furthermore, it can optimize the rulesets and detects anomalies among rules of one firewall or different firewalls. The policy transformer has the responsibility of transforming high-level policies into formal low-level ones. As a finale, the policy engine verifies the configuration of whole firewalls in the network vs. security policies and determines all the violations by denoting relevant filtering rules, services, and policies. Furthermore, this module is able to extract formalized low-level policies that are enforcing by firewalls configuration.

FIGURE 3 FPoVer architecture.

NETWORK TOPOLOGY

We consider network topology as a set of zones connected together via gateways. Each gateway has packet filtering capability, which can be a firewall, router, or switch (we refer to all of them as firewalls). A gateway has at least two interfaces. Interfaces and hosts are defined by their corresponding addresses and zones. A zone is described by its subnet masks. Also, a particular network topology is expressed as a set of assertions in an ABox. Therefore, the knowledge base of a network topology consists of a TBox and an ABox. Figure 4 denotes the formal specification of the core elements of a typical TBox in ℒℐ().

FIGURE 4 The formal specification of the core elements of a network.

Example 1

The formal specification of the zones and the network roles of our case study is partially given in Figure 5. Moreover, Figure 6 partially describes the protected enclave zone by ABOX assertions.

FIGURE 5 The formal specification of the roles and zones (TBOX).

FIGURE 6 ABOX of the protected enclave.

FIREWALLS CONFIGURATION

Configuration of a firewall consists of a sequence of ordered filtering rules. Each filtering rule has a matching part and an action part. The matching part of a rule consists of values for various fields in a packet header including source address and port, destination address and port, protocol and direction (Wool, 2004). When a packet enters the firewall, the firewall goes over the sequence of rules until it finds a rule that matches the header values in the arrived packet. If a match is found, then the packet is either permitted or denied and the rest of the filter will be ignored. Each ruleset has a default policy that determines what to do with a packet in occasions that no matched rule is found. Some firewalls translate addresses and ports and rewrite packet headers before controlling the traffic. Therefore, address fields of rules do not contain real addresses. Address translation tables make the real address to be easily computed. In this research, we suppose real addresses are provided by rulesets.

Figure 7 shows formal definition of the firewall rules in ℒℐ(). In our approach, system managers do not need to formalize configuration. After gathering firewall configuration, FPoVer produces their formal specification automatically by reasoning on the formal definitions of the network topology and the network roles. In the formal specification of the rules, the source and destination addresses are network roles. In cases that the source and destination addresses are identified by IP addresses, we compute the associated roles by reasoning on the knowledge base of network topology. In this way, we may find some unrelated roles. Relevant roles are indicated according to the service of rules and roles definition. For example, if a host had two “web server” and “ftp server” roles, and the rule service is the ftp service, then the “ftp server” role is preferred. The pictorial representation of the rule core concepts is indicated in Figure 8.

FIGURE 7 The formal specification of rules.

FIGURE 8 The pictorial representation of the rule concepts.

Rules order in a ruleset is a significant factor of the correctness of firewalls behavior. One of the main features of our approach, which is excessively an advantage over the other presented approaches, is considering the rule order in formal specification that makes it practical in existing firewalls.

Example 2

Formal specification of the four first rules of Ieth0/0 ruleset is expressed in Figure 9 which was produced automatically by FPoVer.

FIGURE 9 The formal specifications of the first four rules of Ieth0/0.

POLICY DEFINITION

In this section, we first introduce a DL-based framework to express access control policies which are hereafter called permission policies. Permission policies are divided into two categories. A positive permission policy defines the actions that a subject is permitted to perform on an object. A negative permission policy specifies the actions that a subject is forbidden to carry out on an object. Each policy has at least one subject (actor) and one action. Actions must be performed on at least one object. We use the term actor to refer to any user, principal, or automated manager component which has management responsibility. An actor accesses objects by performing actions on them. Objects can be any physical or logical resource such as services, applications, data, printers, etc. Figure 10 shows policy specification with ℒℐ() in which Subject, Action, and Object are primitive concepts. In this specification, Actor and doAction roles are used to define actor and action of the policy, respectively. Each policy definition consists of two parts: the first part defines modality of the policy through a subsumption relationship, while in the second part, actor(s) and action(s) of the policy are specified using an equivalency relationship. The pictorial representation of the core concepts is shown in Figure 11.

FIGURE 10 The policy description in ℒℐ()).

FIGURE 11 The graph model of the core concepts of policy.

An important feature of a policy language is the capability of describing conditions under which the policy is valid such as temporal conditions, network load, etc. Here, the PolicyContext role is used to describe validity conditions of a policy.

Now, let us turn back to the customization of the proposed language for describing service access control policies. A service access control policy specifies rights of a network role on the services and the applications running on a specific server. According to the proposed framework, the objects are the applications and services explained by their names and running ports. This model works well for applications that run on well-known ports.

Access control models define how the permissions are organized through the systems. We use an RBAC model which organizes the subjects based on their roles in an organization. Thus, it allows us to make security policies specification independent of the network topology changes. We distinguish network roles by their zones and services that they offer. For example, suppose that there are two roles “internal web server” and “public web server” in an organization. “web server” is defined as a server which offers web service, while “internal web server” and “public web server” are web servers that are distinct by their zones and we refer to them as basic network roles. A network role is allowed to initiate or accept a service according to policies. So, policy actions are accepting or initiating a service that are dual. Therefore, for the sake of simplicity we just consider AcceptService action. Figure 12 shows formal specification of the services partially in addition to the AcceptService action.

FIGURE 12 The formal specification of the services and AcceptService.

Conflicts can arise in a set of policies that impact on the system behavior. Therefore, it is important to determine and resolve conflicts among policies. One of the most common conflicts is modality conflict. Modality conflicts are inconsistencies in a set of policies that contain policies with opposite modalities (opposite sign) but with the same actors and actions. In order to detect such conflicts between permission policies, we consider the formula (1) which denotes that Authorization ⁺ and Authorization ⁻ are disjoint:

By concentrating on DLs constructors, particularly equivalency relationships, we are able to specify high-level concepts based on the low-level concepts which allows us to specify policies at a more abstract level. In complex and large-scale organizations, we need to provide some facilities to organize policies. Subsumption relationships provided by DLs, allow us to group policies based on either their actors or actions which simplifies their management. In addition, by grouping concepts we are able to reuse action or policy definitions. Due to the fact that security policies are written by different people in an organization, the chance of redundancies between policies is increased as well. Reasoning services provided by DLs, such as concept subsumption and concept disjointness, are strong capabilities that allow us to identify any redundancy or even overlapping among policies.

Due to the class-based basis of DLs, expressing policies with the proposed language is straightforward. Administrators only need to identify the subject, action, and object of each policy while the corresponding formal specification can be produced automatically. However, up until now, FPoVer does not provide this feature yet.

Example 3

Figures 13 and 14 give the formal specification of some actions and policies of our running case study, respectively. With concentration on subsumption capability in DL, a system administrator can express policies at a high level of abstraction without considering technology. For example, consider AcceptSecuredService action, which states that only secure services are acceptable without explaining which channels are secured.

FIGURE 13 The formal specification of the policy actions.

FIGURE 14 The formal specification of security policies.

There are inconsistencies between policies that were detected by FPoVer, e.g., ServerConfigPolicy prohibits the administrator to configure servers insecurely, while the AccessTelnetPolicy policy allows the administrator to use telnet service which is an unsecured service. To make the policies consistent, we remove the TelnetPolicy policy. Also, the DefaultPolicy has conflict with all positive policies. In order to have a consistent policy set, a priority is assigned to DefaultPolicy. The specification of the DefaultPolicy after resolving conflict is shown in Figure 15.

FIGURE 15 The formal specification of DefaultPolicy.

VERIFICATION

In this section, we introduce our approach to verify the configuration of distributed firewalls vs. security policies.

Transformation of Security Policies

The policy statements and the enforcing configurations have a conceptual gap that must be overpassed by suitable techniques. A common approach is transforming the high-level, business-oriented policies into the lower level technology-oriented policies. We take this approach and transform high-level policies into a set of formalized, low-level policies which warrant enforcing the high-level policies correctly. Although, we can detect inconsistencies between policies by considering their context, we must, however, choose suitable policies based on their context to have a consistent low-level policy set. For example, consider two policies; “Host_X in Zone_Y can access ftp service throughout 8–12” and “Zone_Y hosts cannot access ftp service during 14–18.” It is obvious that without capturing the policy context, produced low-level policies will have conflict. Therefore, we use reasoning services provided by DLs systems to choose appropriate policies based on their validity conditions, e.g., in this example, in order to find all the permission policies that are enforceable and valid during 8–12, we must find all concepts subsumed by concept Authorization⁺ ⊓ ∃ PolicyContext.(∀ time. ≥₈ ⊓ ∀ time ≤12).

Despite the fact that rule order has a crucial impact on the behavior of firewalls, in cases where matching parts of the filtering rules are disjoint, the ordering of rules is not important. However, rules are often interrelated and as a consequence the rule order becomes important. In this research, we consider order of the produced low-level policies according to the priority of their corresponding high-level policies. The algorithm shown in Figure 16 transforms policies to a set of formalized rules in which a basic action is defined as an action that does not subsume any action but ⊥.

FIGURE 16 A simple algorithm for transforming high-level policies.

In order to prove that this transformation is complete and sound, we must prove that the role rights according to policies are the same as the rights based on low-level policies. Therefore, first we give some definitions and then prove completeness and soundness of our algorithm.

Definition 2

Semantics of the policy p _j denoted by σ(p _j ) is a set of ordered tuples of the form 〈 _j ,  _j ,  _j , p _j , μ _j 〉, where  _j ⊑NetworkRole,  _j ⊑NetworkRole,  _j ⊑Service, p _j  ∊ N, and μ ∊ {+, −}.

Definition 3

Let policy p _j defined as p _j  ≡ ∀ Actor.ω _j  ⊓ ∀ doAction.α _j  ⊓ ∃hasPriority. = { _{O j} } with basic actions ϕ(α _j ) = {α _{j 1} , α _{j 2} ,…, α _{j m} } defined as formula (2). If p _j ⊑Authorization⁺, the semantics of p _j is defined as formula (3), in the case of p _j ⊑Authorization⁻, the last entry of the tuple j would be replaced by ‘ − ’.

Definition 4

Semantics of the rule I _j  ≡ ∀ hasSrc.α _j  ⊓ ∀ hasDst.β _j  ⊓ ∀ hasService.γ _j  ⊓ ∀ hasOrder.η _j is defined as an ordered tuple σ(I _j ) = 〈α _j , β _j , γ _j , η _j , +〉 if I _j ⊑ permittedRule. For denied rules, the last entry is replaced by ‘ − ’.

Definition 5 (Semantic completeness and soundness)

Let us consider the transformation  applicable to a concept set . Let c denotes a concept belonging to  and {ℓ₁,…, ℓ _m } be the set of corresponding concepts belonging to ().  is a semantic complete transformation if for each c ∊  it holds . Also,  is a semantic sound transformation if for each ℓ _k , it holds σ(ℓ _k ) ∊ σ(c).

Theorem 1 (Semantic soundness)

The PolicyTransformation algorithm (Figure 16) is sound semantically.

Proof

Suppose it is not sound. Therefore, there is a tuple μ = 〈α _j , β _{j t} , γ _{j t} , η _j , ×〉 belonged to σ((p _j )) where μ ∉ σ(p _j ). μ corresponds to the rule ℓ _{j t} = ∀ hasSrc.α _j  ⊓ ∀ hasDst.β _{j t}  ⊓ ∀ hasService.γ _{j t}  ⊓ ∀ hasOrder.η _j . So, there is a policy p _j  ≡ ∀ hasActor.α _j  ⊓ ∀ doAction.δ _j  ⊓ ∃ hasPriority. = η _j where ℓ _{j t} corresponds with one of its basic actions, i.e., ∃ δ _{j t}  ∊ ϕ(δ _j ) ∍ δ _{j t}  = AcceptService ⊓ ∀ onObject.(γ _{j t}  ⊓ ∀ providedBy.β _{j t} ) which ϕ(δ _j ) shows basic actions of δ _j . The corresponding tuple of this action will be μ′ = 〈α _j , β _{j t} , γ _{j t} , η _j , ×〉 and as a result μ′ = μ. Therefore we can deduce μ ∊ σ(p _j ).

Theorem 2

The PolicyTransformation algorithm is complete semantically.

Proof

Suppose it is not complete. Therefore, there is a tuple such as μ = 〈α _j , β _{j t} , γ _{j t} , η _j , ×〉 belonged to σ(p _j ), where . μ corresponds to an action such as δ _{j t}  = AcceptService ⊓ ∀ onObject.(γ _{j t}  ⊓ ∀ providedBy.β _{j t} ), which would be transformed to the positive rule ℓ _{j t} = ∀ hasSrc.α _j  ⊓ ∀ hasDst.β _{j t}  ⊓ ∀ hasService.γ _{j t}  ⊓ ∀ hasOrder.η _j . According to Definition 4, the semantics of ℓ _{j t} would be μ′ = 〈α _j , β _{j t} , γ _{j t} , η _j , ×〉. Therefore, μ′ = μ and as a result .

Example 4

The PolicyTransformation algorithm transforms the security policies of the running case study into the low-level policies shown in Figure 17.

FIGURE 17 The produced low-level policies.

Formal Analysis

Thus far, we have obtained formal specification of the configuration of firewalls and the security policies at the same level of abstraction. Now, we must determine whether the current configuration of firewalls simulates the behavior of the low-level security policies correctly. To this end, we make a comparison between the host's rights on services according to the configuration of firewalls and low-level security policies. First, we introduce a concept called unavailable services, which defines disabled services between a pair of roles in the network. Then, we find unavailable services between each role pair with different zones according to the configuration of whole firewalls along the path of these roles as well as low-level security policies. Afterward, we investigate the equivalency of the unavailable services derived from the configuration and low-level security policies.

A question that comes up is how inactive services by a ruleset are computed. In this research, we simulate a ruleset by only negative rules, while it guarantees that the firewall will behave equivalently. A rule can be triggered if its prior rules do not cover it completely. Therefore, we can compute inactive services between two roles in the network by only taking into account some parts of denied rules that are not covered by prior rules. Figure 18 shows a simplified algorithm for computing inactive services between two roles by a firewall. In a network with multiple firewalls, a service between two hosts is inactive if it is disabled by at least one of the firewalls along their routing path. Thus, inactive services between two hosts, α and β, would be a union of all the disabled services by each firewall along their path, i.e.,

FIGURE 18 Unavailable_services algorithm.

where χ(α, β, I _j , λ) denotes disabled services between α and β by interface I _j in direction λ, and φ(α, β) shows inactive services between α and β.

Let χ _c and χ _p denote inactive services between two roles according to the configuration of the firewalls and the low-level security policies, respectively. χ _c  ≡ χ _p indicates that all inactive services between two roles are identical according to the configurations and security policies. If s _c and s _p are not equivalent and χ _c ⊑χ _p , it means that current configuration allows some services, which according to security policies must be inactive. Finally, if χ _c and χ _p are not equivalent and χ _p ⊑χ _c , there are some inactive services between two roles which security policies say must be active. Other states denote that some inactive services must be active while some active services must be changed into inactive. Using subsumption and disjointness relations between the definition of services, χ _c and χ _p , we can specify all disabled and enabled services between roles.

Lemma 1

Let R _i , γ _i , S _{disabled i} and S _{enabled i} , respectively, denote the ith rule, the service of R _i , disabled and enabled services by preceding rules of R _i in the ruleset of I _k computed by Unavailable_Services. It would hold that S _{enabled i} ⊑ ¬ S _{disabled i} .

Proof

For i = 1, S _enabled1  ≡ ¬ S _disabled1  ≡ ⊥. Now let for t = n, the formula S _{enabled i} ⊑S _{disabled i} holds, so we must prove S _{enabled t+1} ⊑ ¬ S _{disabled t+1} . We prove the lemma for the case R _i ⊑PermittedRule (the proof is the same for negative rules), so

Theorem 3

Service γ between two roles, α and β, is disabled by I _k in direction λ, iff γ⊑χ(α, β, I _k , λ) where χ(α, β, I _k , λ) is computed by Unavailable_Services.

Proof

Let R _j be defined as R _j  ≡ Rule ⊓ ∀ RuleSrc.α ⊓ ∀ RuleDest.β ⊓ ∀ RuleService.γ ⊓ ∀ Ruledir.λ. Furthermore, n denotes the length of the ruleset. For the “if” direction, let service γ be disabled by I _k in direction λ between α and β but the condition γ⊑χ(α, β, I _k , λ), does not hold. Because γ is disabled, the negative rule R _i (line 13) therefore must exist such that R _i ⊑R _j and γ _i ⊑γ. Only some parts of a rule that is not covered with its prior rules is activated. Therefore,

γ is disabled by Rule R _j , so

Formula (8) contradicts our hypothesis.

Now for the “only if” direction, let the condition γ⊑χ(α, β, I _k , λ) hold but the service γ between α and β is allowed by I _k in direction λ. According to formula γ⊑χ(α, β, I _k , λ), the negative rule R _k must exist which γ⊑γ _k and γ⊑S_{disabled i+1} . Since γ is enabled, there is a positive rule such as R _i where R _i ⊑R _j and γ⊑S_{enabled i+1} . So γ⊑S_{enabled i+1}  ⊓ S_{disabled i+1} and as a result S_{enabled i+1} ⊑/ S_{disabled i+1} which is contradictory with Lemma 1.

Example 5

To verify the configuration of firewalls of the running case study, we must compare role rights according to low-level policies shown in Figure 19 and the formalized rulesets of the four interfaces. After applying the proposed approach, a number of violations were found, which due to the lack of space we only point to some of them.

FIGURE 19 χ _c and χ _p from the internal web server to the external network.

Security policies say that external hosts cannot access any services in the intranet, while external firewall and Ieth0/1 allow http requests to the internal web server. Also, Ieth0/1 permits the access with source ports greater than 1000. So, external hosts can access web service with source ports greater than 1000. Figure 19 shows χ _c and χ _p between the external host and the internal web server.

The policy “external hosts can access http service from the public web server” is enforced in the network correctly. The result of verification process is shown in Figure 20.

FIGURE 20 χ _c and χ _p —from the public web server to the external users.

Although Admin must configure servers via secure services such as Https and SSH, Ieth0/0 and Ieth0/1, however, deny Https requests to the DNS server. Figure 21 shows services on the DNS server which are not available for admin.

FIGURE 21 χ_c and χ_p from the DNS Server to Admin.

Complexity Analysis

The complexity order of the Unavailable_Services algorithm (Figure 18) is Ω(L), where L is the length of the ruleset. In order to compute the unavailable services between a role pair, Unavailable_Services is called m times, once for each firewall along the routing path. Therefore, unavailable services between two roles is computed in Ω(mL).

Supposing n is the number of basic network roles, the proposed approach verifies the configuration of the firewalls in O(ln ²), where l is the average length of the rulesets. Checking the equivalency of the unavailable services between a role pair according to the low-level policies and the firewalls, configuration is performed in Ω(mL + l′), where l′ denotes the number of low-level policies. Our approach requires to verify the configuration, where m′ is the maximum number of firewalls on the path. As m′ is usually a small number, we ignore it here. Therefore, the time complexity order of the proposed approach will be O(ln ²), where l is the average length of the rulesets.

EVALUATION

To evaluate the practical value of our approach, we have conducted a real-life case study. In our evaluation study, we applied our approach on an industrial network. The topology of this network is composed of six local networks connected globally to a central site. Each local network is composed of two zones separated by an internal firewall. Thus, the network topology includes 14 zones (12 local zones, the central site, and Internet) separated by seven firewalls. Figure 22 shows the network topology of our case study. In this case study, the operating systems of the clients and servers are Windows XP and Ubuntu Linux, respectively. The central site is a data center including six main servers that are accessed by local networks. Although the zone number of the local networks, the operating systems of the clients, and the operating systems of servers are identical in all local networks, the number of clients/servers and server types, however, vary in various local networks. Moreover, the access rights of hosts in different zones and subsequently the configuration of the firewalls vary. It is worth noting that in this network, only Astaro security gateways are in charge of packet filtering.

FIGURE 22 Network topology.

Verification Results

After applying our approach on the case study, FPoVer revealed a number of violations. For each violation, FPoVer identifies the relevant rules of each firewall and the corresponding security policies that may have a role in the misconfiguration, which subsequently enables the administrator to trace the root of violations. In this experiment, 42 network roles were defined. For 89% of role pairs, the configuration of firewalls applies the security policies correctly, while for 8.5% of role pairs the configuration acts strictly, i.e., the distributed firewalls configuration closes a number of services which according to security policies must be active. Furthermore, configurations allow 2.5% of role pairs to access services, which in terms of security policies must be inactive.

Performance Evaluation

We also performed a number of experiments to measure the performance of FPoVer under different network sizes using our case study. To this aim, we measure the performance of FPoVer with a various number of hosts in the network, a different number of zones (and subsequently the number of defined roles), and varying ruleset lengths. Our experiments were performed on an Intel workstation running Windows XP with Core 2 Duo 2.67 GHz CPU and 2 Gbyte memory.

The attitude behind our approach is based on the comparison of the unavailable services between each role pair according to the distributed firewalls configuration and security policies. Therefore, as previously mentioned, the number of firewalls along the routing path and the rulesets length parameters have significant influence on computing unavailable services between a role pair. We claim that the number of the evaluated rules by Unavailable_Services is the main factor that is determined by two mentioned parameters. Since the maximum number of rulesets in a routing path in our case study is 6, we simulate the effect of increasing the number of rulesets along the path by increasing the rulesets size in our evaluation study.

In order to assess our approach with different ruleset sizes, we use a method to generate a new ruleset with the same behavior but with different lengths. The source (destination) address of a rule can be a network address or an IP address. Therefore, in cases that the source (destination) address of a rule is a network address, we increase the ruleset length by adding multiple rules to the ruleset just before the rule in question. The added rules are obtained by replacing the source (destination) address of the original rule with the IP addresses of the hosts in the source (destination) network. Therefore, we are able to add up to m × nmore rules where m and n denote the number of hosts in the source and destination networks, respectively, where the source and destination addresses of the rule are network addresses. Using this technique, the behavior of the firewall will not change but we will have several redundant rules in the ruleset. Although it was possible to generate rulesets at random, we believe that, however it would be better to have rulesets with identical behavior as we want to verify their behavior vs. a fixed set of security policies.

In our first experiment, we created four instances of the topology each with a different number of interconnected zones: 14 zones, 10 zones, and two instances with 6 zones. The topology instances contain 30(21), 20(15), 10(9), and 42(9) network roles (rulesets), respectively, while having 7, 5, 3, 3 firewalls. Then, we generate four sets of rulesets using the technique previously described for each setting. We used FPoVer to analyze the configuration of the firewalls vs. security policies in each scenario. The total processing time was measured for each topology shown in Figure 23. We noticed that when the analysis is performed on a small number of network roles, the processing time varies from 1 minute to 3.5 minutes. However, as more network roles are involved in the analysis, FPoVer requires increasing processing time ranging from 5 to 103 minutes depending on the number of defined roles. It is worth noting that the number of network roles determines the performance of FPoVer significantly. As a basic role is identified by its zone and the service it offers/receives, the number of basic roles would not be too high, even for cases with a large number of workstations in the network. We believe FPoVer is practical to use in real-world scenarios since it works based on the number of network roles not the number of workstations in the network. As FPoVer checks the configuration of all firewalls, subsequently its processing time is too high. To make FPoVer more interactive, we are providing FPoVer with a feature to check if open/closed services between two workstations conform to security policies. The processing time of this function is reasonable (Figure 24).

FIGURE 23 FPoVer processing time.

FIGURE 24 Processing time of FPoVer in terms of number of hosts.

The memory space used by FPoVer is extremely reasonable approximately 32 Mbytes (less than 35 Mbytes even for the larger networks). As the required memory space of all the experiments was very similar, we do not summarize in this article.

In the second experiment, we study the influence of the number of hosts on FPoVer performance. To do that, we defined a different number of hosts for each role in multiple experiments. As the number of hosts in the network is increased, the ruleset length is raised correspondingly. However, since in the formal specification of the rulesets, the source and destination addresses of a rule are defined in terms of network roles, the number of rules in formal specification does not change. Figure 25 shows the processing time results, where the average length of rulesets is 40. As it is clearly indicated by the results, the difference in the processing times is minor—approximately 400 ms in this experiment. One possible explanation is that the time difference is related to the required time of formalizing the rulesets. Moreover, the used memory space in all cases was about 22 Mbytes.

FIGURE 25 Processing time of FPoVer to compute unavailable services between a role pair.

Furthermore, in our last experiment, we evaluate the performance of FPoVer for computing unavailable services between two roles in cases with two and four rulesets on the routing path. The processing time results are shown in Figure 25. The processing time to compute unavailable services between a role pair ranges between 410 ms to 3472 ms. As it is revealed by the results, the performance of FPoVer in case of two rulesets with average ruleset length 80(40) is approximately the same as the case of four rulesets and an average length of 40(20).

RELATED WORK

A significant amount of work has been reported in the area of policy-based security management. Due to the fact that our main aim in this research is how to verify configuration of firewalls, we focused our study on the related works that intersect with our work in producing and verifying firewall configurations.

Firewall management toolkit Firmato (Bartal et al., 1999) uses an entity-relationship model to specify both the security policies and the network topology and makes use of the concept of roles to define network capabilities (Al-Shaer et al., 2005). Then, based on policy specification, it produces a ruleset and replicates it in all devices without considering the impact of the routing path in rule distribution. In this approach, policies and roles definitions are not separated, while we express policies and roles in distinct ways that increase flexibility and reusability of our proposed language. Another approach close to Bartal et al. (1999) is Cuppens et al. (2004) in which authors present an access control language to specify high-level network access control policies based on XML syntax whose semantics is interpreted by Organization-Based Access Control (Or-BAC). Then they derive concrete rules to configure specific firewalls through an automatic translation process. Other related work in this area (Avishai, 2001; Mayer et al., 2000; Uribe and Cheung, 2004) propose approaches to express firewall policies using a high-level policy language and then map the policies to filtering rules.

Among the alternative approaches for policy verification Guttman (1997) is an important early step that concerns itself with specifying service access policies through a lisp-like language in a logical framework. Policies are described with a low-level, topology-dependent language based on packet information which has made it difficult to use. Authors consider only a logical description of the filtering to be done at each router interface, but they do not specify the configuration files that implement this functional behavior. Also, they do not discuss how to encode a filter configuration file as a logical description of filtering which makes it awkward to use. Security policies and filtering operation of devices are expressed in the same way. An algorithm compares a set of filters with access control policies to determine all policy violations. The proposed algorithm should check a large number of states which makes it difficult and impractical in large networks. In addition, consistency checking of policies is not provided.

In Burns et al. (2001), the authors attempted to design and develop a system for automatic management of security policies in dynamic networks. They express security policies with first-order logic. In this approach, system configuration is produced and distributed dynamically in the network. However, they did not illustrate how security policies are produced, distributed, and verified. In spite of the fact that logic-based languages have proven to be attractive for the specification of security policies, they can, however, be difficult to use and are not always directly translatable efficient implementation (Bandara, Lupu, and Russo, 2003).

Al-Shaer and Hamed (2003)Al-Shaer and Hamed (2004)Al-Shaer and Hamed (2006) and Al-Shaer et al. (2005) presented a set of techniques and algorithms to automatically discover rule anomalies in centralized and distributed firewalls. Also, Bandara, Kakas, Lupu, and Russo (2006) proposed an approach to specify network security requirements based on argumentation for logic programming with priorities (LPP) which analyze rulesets to find out anomalies between rules. Furthermore, in Hari et al. (2000) and Yuan et al. (2006), some algorithms are provided for detecting and resolving conflicts among filtering rules. Uribe and Cheung (2004) have developed a technique for automating the analysis of firewall and network intrusion detection systems that use constraint logic programming to model the networks and policies. However, this technique does not support rule order. However, none of the mentioned research verifies if the filtering rules conform with the high-level security policies.

Mayer, Wool, and Ziskind (2006) presented an approach in which network information and firewall policies are expressed with a high-level language that allows firewall configuration to be performed at an abstract level. They developed some tools to support offline firewall policy analysis and management. However, their approach does not have a formal basis and they do not verify configuration vs. security policies.

Liu (2008) developed a firewall verification tool that takes a firewall ruleset and a property as input, then verifies if the configuration of firewall satisfies the given property. The high-level properties are transformed into the rule properties. Although this work is able to verify configuration of one ruleset vs. a given property (which can be a low-level policy), it is impossible to check the configuration of distributed firewalls.

FUTURE WORKS AND CONCLUSIONS

In this article, we attempted to (1) present a formal high-level language based on DLs that express security policies with a simple language and analyze them for discovering conflicts; (2) automate formalizing firewall configuration; (3) present an algorithm for transforming high-level policies into low-level policies; and (4) propose an approach to verify the high-level security policies which takes low-level policies, routing information, and configurations of whole firewalls in the network as input and using DLs reasoning services to identify all policy violations. To evaluate our approach, we applied our approach on a real-world case study. Moreover, we analyzed the performance of the developed tool under different network sizes. We believe that our approach is an important practical step toward verifying configuration of distributed firewalls vs. security policies formally.

There is much more research to pursue in the area of security policy verification. Our future research will concentrate on considering system vulnerabilities and complex network attacks on enforcement of security policies. The approach proposed in the present research can be generalized to be used for verifying many other types of security policies such as IPSec and QoS. Extending the presented approach for verification of IPSec and QoS policy is an ongoing work. Verification of security policies considering comprehensive configuration of the systems is another future work.

APPENDIX A

TABLE 4 Ruleset of Ieth0/1

Source address	Destination address	Protocol	Source port	Destination port	Action	Direction
14.2.10.1	∗	TCP	∗	25	Permit	∗
∗	14.2.10.2	TCP	>100	80	permit	∗
∗	14.2.10.2	TCP	∗	443	Deny	∗
14.2.10.1	14.2.9.2	TCP	∗	23	Permit	Out
∗	∗	TCP	∗	∗	Deny	∗

TABLE 5 Ruleset of Eeth0/0

Source address	Destination address	Protocol	Source port	Destination port	Action	Direction
∗	14.2.9.2	TCP	∗	80	Permit	∗
∗	14.2.9.3	TCP	∗	53	Permit	∗
∗	14.2.10.2	TCP	∗	80	Permit	∗
14.2.10.∗	∗	TCP	∗	80	Permit	In
∗	∗	TCP	∗	∗	Deny	∗

TABLE 6 Ruleset of Eeth0/1

Source address	Destination address	Protocol	Source port	Destination port	Action	Direction
∗	14.2.9.2	TCP	∗	80	Permit	∗
∗	14.2.9.3	TCP	∗	53	Permit	∗
∗	14.2.10.2	TCP	∗	80	Permit	∗
14.2.10.∗	∗	TCP	∗	80	Permit	In
∗	∗	TCP	∗	∗	Deny	∗