• No results found

Verification of Security Policies

4.1 From Middlebox to Network Application

The management of security in network infrastructure is a complex duty. Network security involves applications, services and access control which mainly relies on firewall configuration and operation. Recall that 50% to 80% of infrastructure failure is caused by misconfiguration [AWY08; KD12]. Specifically, configuring network security policies such as firewall rules is an error prone task. Automatic tools for management aim to reduce the time required to configure network devices and the problems caused by configuration errors.

Configuration of firewalls is a well-known problem [Woo10]. Traditional firewall middlebox suffers from several drawbacks such as 1) contradictory rules that define different actions for the same packet (and must be arranged or prioritized to apply one over the rest); 2) inconsistent rules affecting the same traffic but defined on different firewalls (and must be redefined according to a global policy); 3) pointless and impractical rules could be included increasing complexity but do not add functionality, on the contrary, they increase the processing time and the complexity of detecting configuration errors; and 4) policies in several middle–boxes lack of consistency, it means, all firewalls must process the same packet with the same policy.

4.1.1 Firewall functionality

Firewall is a middlebox that controls and monitors the network against unauthorized traffic. It is widely used not only to restrict external and private traffic, but also to grant access to applications and control user behavior. A firewall filters packets according to a security policy which is represented as a list of rules to decide which actions apply to a packet. A rule has the structure hpredicatei → hactioni that means if predicate is valid, then the action takes place. A predicate is a logical expression evaluated over a set of packet fields such as protocols, source and destination addresses and ports. The action is a

forwarding decision, commonly accept or deny. A packet matches a rule if its header satisfies the predicate. Rules are sorted, therefore if a packet header matches a rule predicate, the corresponding action is executed, and the following rules are discarded. To find conflicts on firewall configuration, it is necessary to analyze the previous (i − 1) rules and evaluate them against the it h rule.

Here in SDN environment, the firewall is an application running on the controller server.

Now firewall operation is also distributed across the switches. The interesting issue, in this scenario, is how to validate if firewall rules conflict. In order to solve this problem, we first introduce how to identify conflicts in the SDN firewall application.

4.1.2 Firewall and Security rules in SDN

Recall that SDN separates control and data planes § 2.1. This functional separation gives major flexibility, permits network administrators to create software routines, and allows dynamic configurations. Now, applications operate and control the network. As with many other network functionalities, firewall is adopted as an application for SDN controller.

SDN introduces a different scenario for firewall functionality. The firewall application is able to modify the forwarding table of a device. This flexibility increases the risk of firewall–rule conflicts unlike the pre–SDN scenarios. Detecting and preventing conflicts in firewall rules for SDN is different than firewall-middlebox because, as any other SDN application, the output of the control plane is a set of forwarding rules for datapaths.

Firewall functionality and other rules are distributed in multiple datapaths. The verification of those forwarding rules must guarantee the inter–operation of multiple devices and network applications, not only the firewall rules. The main goal is ensuring that all involved network devices satisfy the high–level policies.

4.1.3 FireWell Proposal

We propose to verify firewall rules and forwarding rules from datapaths as product of this SDN application. The verification engine is based on Alloy and finds examples (or counterexamples) of networks that exhibit a topology and support a set of constraints of firewall rules. Alloyais a first order relational language to model and explore solutions for a formulation based on predicates. In our proposal, the network topology, traffic flows and policies are written as predicates and then are evaluated. Alloy has demonstrated being suitable to solve that kind of satisfaction problems.

ahttp://alloy.mit.edu/alloy/

Network security is a field that uses logic verification in extensible way [APS14]. For instance, access control mechanisms, such as RBAC, were verified to find inconsistencies and contradictions using Alloy [PSS11]. We propose to use Alloy, as a formal language, to define and analyze models based on relational first–order logic. It has been used to analyze inconsistencies in rules and policies in multiple domains [PSS11]. Using Alloy, we can translate specifications in PPL into a relational model and determine if the set of network policies can be implemented in a concrete network topology without conflicts.

The Path-Based Policy Language (PPL) is a well-known language for Policy-based network management. Using PPL, network administrators can specify the set of rules about how the network must deal with specific types of traffic, and then use a compiler to transform these rules into technology-level instructions. Existing PPL compilers [SLX01][Guv03]

perform validations on policies to detect conflicts such as contradicting rules for the same network segment. However, these compilers only support a subset of the language, and cannot detect conflicts related to traffic priority, neither user–groups administration.

In contrast to configuration verifiers, Policy–Based Management is a tool to simplify network administration and support the creation of error-free configurations. The essential concept is that managers write a set of well–formed policies (at business-level) in an unambiguous language, that are later translated into operational parameters (at technological-level) for each entity in the corresponding network [Str03].

The network community has been struggling for years about how to manage networks, supporting business demands and preventing configuration errors. Some approaches are focused on configuring and monitoring each network device using centralized applications and management protocols such as SNMP. Other approaches, such as VeriFlow [Khu+13], are aimed at checking the configuration of each network device and detecting conflicts, inconsistencies and bugs. In contrast, Policy-based Network Management focuses on the specification of the intended behavior of a network and the automatic configuration of each one of its elements [Ste+99]. It simplifies the administration and supports the creation of error–free configurations. In Policy-based Management, the essential concept is the well–form policy. This policy is written by managers in an unambiguous language, and later translated into operational parameters (configuration scripts) for each entity in the corresponding network [Str03].

Alloy is a first-order formal language used to model and explore solutions for a formulation based on predicates. It has been used to analyze inconsistencies in rules and policies in multiple domains. For instance, access control mechanisms such as RBAC were verified to find inconsistency and contradictions using Alloy [PSS11]. Recently, it was used to model general network behavior to find security violations [MLCD14]. Using

Alloy, we can translate firewall rules into a relational model and determine if the set of firewall policies are valid over a given network topology. Moreover, it finds examples (or counterexamples) of traffic flows that satisfy (or violate) the policy.

The administration of network demands automated tools to simplify the network configuration. Managers call for mechanisms to check and validate network configurations that guarantee the achievement of its goals. Moreover, a forecast engine would be helpful to test configurations before being applied. Policy-based Management could be an important method to achieve this goal.