FireWell implementation

FireWell is a tool to validate, detect and prevent conflicts on firewall policies in SDN.

FireWell is an independent application and can run remotely to the controller. It serves and consumes information with the controller. FireWell is configured to run in parallel with Alloy version 4 and the UNSAT solver of Kodkod^c. This section shows the FireWell

cThis work uses the same methodology presented in chapter 3.

architecture and details its implementation that translates firewall policies, from SDN controller, for validating and detecting conflicts.

FireWell Architecture

As shown in figure 4.2 FireWell is an external application that serves and consumes information to/from the controller. FireWell has two interfaces: the first one is the RESTlet which establishes connection with the controller to get and install rules into the SDN firewall application; the second one is the interface with Alloy which parses rules on files that later are processed by the solver and its outputs are received through the same interface. FireWell also has two modules to process structures taken from the controller:

the network topology parser and the firewall rule transformer. It comprises a module to parse structure into Alloy language, a module that abstracts the topology, a module that handles firewall rules, a module that creates trees of data–fields, and I/O interfaces with the RESTlet service and the interpreter.

The process through FireWell is as follows:

1) FireWell gets controller information, such as network topology, and the set of rules from the SDN firewall application.

2) FireWell builds its own representation of firewall rules.

i) The module of topology creates the FireWell representation of nodes and links.

This data structure is inspired in the formalization done in § 3.1.1.

ii) Firewall rules are transformed into a set of fields trees to reduce the number of variables. This tree–data transformation allows to create sets of symbols that later are defined into predicate logic.

iii) FireWell uses its Parser module to translate its rules into well-formed expressions.

3) Once rules are in logic expressions, FireWell writes an .als file which later will be load into Alloy. After that, the .als file is processed with the Alloy solver.

4) After the SAT solver with unsatisfiability procedure is executed, the list of counter examples, if they exist, are interpreted to identify firewall rule conflict or nodes which violate the security policy by counterexamples. Recall that a counterexample is an abstraction of conflicting rule or a policy violation.

5) Conflicts are reported to the network administrator. This report includes the firewall rule, its number, and the counterexample explanation, the set of contradicting rules or the policy circumvention.

FireWell

Network Applications

Topology

REST API

Topology Firewall

RESTlet Rules Fields Tree Interpreter

Floodlight controller OpenFlow protocol

Alloy Counter Examples

Parser

SAT Solver

KodKod UnSATcore

Virtual Switch Circuit Pusher

Forwarding

Alloy Language

Figure 4.2: FireWell architecture. It gets topology information from Floodlight, creates the model and exchanges formulation with Alloy.

RESTlet interface and Model Parser

FireWell, at first instance, has a RESTlet that gets information from the Floodlight controller. This information includes topology nodes and links, and the set of rules in the firewall application. Then, FireWell resolves nodes, links, and firewall rules, and builds its own representation on JAVA–data structures. Network topology is also represented on its structure and creates forwarding tables for each device with information available through the Floodlight controller.

Parsing the model has three steps. First, fundamental elements such as nodes, protocols, addresses, ports and actions are created as sets. The parser module writes rules, topology, paths, and flows into sets and relational logic expressions. In the second phase the parser writes trees for addresses, a sequence which defines priority, and rule instantiation as show in figure 4.3. Firewall rules are inspected. Fields from all rules are analyzed; FireWell parser identifies relations over fields and builds data–trees. This procedure maps variables and rule definitions into sets to reduce the amount of variables. Additionally, following the same model presented in § 4.3.1, FireWell creates the functions to classify filter–field relations, and rule conflicts. The identifier of each rule is represented as a sequence of

a ⁰ a

a

a

a

a

(*.*.*.*)

(140.192.37.*)

(140.192.37.20) (140.192.37.30)

(161.120.33.40) (140.192.35.*)

Figure 4.3: Tree of addresses created from the example of table 4.1.

elements used to illustrate priority. At the third phase, parser establishes the scope to run the model, and write the unsatisfiable cases. This output is recorded to a .als file which can also be run from the Alloy interface. Figure B.1 shows an example of the result the firewall model translated into Alloy language.

Floodlight [Big12] is a NOS and controller system used by FireWell because it supports upper applications and protocols, and translates their instructions to forwarding devices. At the lower level, OpenFlow [McK+08b] is the communication protocol that binds Floodlight in a centralized controller to forwarding devices, establishes standard interfaces, and executes applications, algorithms and protocols on the switches.

Tree optimization

An attribute of FireWell is the ability to reduce the amount of variables that later will be evaluated in Alloy. A naive way to create sets and identify relations between their elements by creating all possible elements in a set, and then, calculate their relations. For example, a firewall rule can have IP ranges or subnets in the form 192.168.10.0/24 and then FireWell identifies field relations (=, ⊂, ⊃, ) with another field, e.g. 192.168.10.0/25 and creates a tree of field relationships.

In this manner, FireWell creates a tree of relations between fields. In the case of IP addresses, the root of the tree is the wildcard (∗. ∗ . ∗ .∗) equivalent, because all addresses are subsets of the root. Then, FireWell analyses other policy fields, establishes relations and creates a tree. Additionally, each node in the tree has a reference to the policy.

Thus, analyzing different walks over the tree, dependencies between rules can be found.

Figure 4.3 shows the address tree created by FireWell from the example of table 4.1.

Interpreter

FireWell uses the Alloy–Java–API interface to process the model, and receives the solver output. An unsatisfiable result is an abstraction of a conflict. The solver, in this case the UNSAT, executes verification clauses, denoted by check-assert into Alloy model. Results from the SAT solver are interpreted by FireWell to identify counter examples found by the solver. The interpreter decodes the output and identifies the set of fields, rules, and nodes that are received in the counter example and identifies the conflict.

FireWell interprets the result from the SAT solver and shows if the set of firewall policies contains conflicts. Once the solver reports a counter example is found, the interpreter executes a routine to identify the set of policies that generates the conflict. Finally, rules in conflict are shown to the console. FireWell is able to identify conflict fields and this information could give more tools to the administrator to identify the inconsistent rule.