Firewalls are a key element in network security. They are in charge of filtering the traffic of the network in compliance with a number of access-control rules that enforce a given security policy. In an always-evolving context, where security policies must often be updated to respond to new security requirements, knowing with precision the policy being enforced by a network system is a critical information. Unfortunately, this is easier said than done. Each firewall vendor uses its own proprietary language to specify the security rules the firewall must enforce and there are usually diferent styles you could use to specify such rules which makes their correct interpretation even more challenging.
To tackle this problem, we propose a model-driven reverse engineering approach able to extract the security policy implemented by a set of firewalls in a working network, easing the understanding, analysis and evolution of network security policies. This work was recently presented at the MoDELS’13 conference (full paper and slides available below).
Let us take a look to an example. Consider we have a De-Militarized Zone (DMZ) network architecture like the one depicted in the following figure. This is a very common architecture used to provide services both to a local network and to the public untrusted network while preventing the local network to be attacked. It is composed by the following elements:
- An intranet composed by a number of private hosts where one of the private hosts acts as an administrator of certain services provided by the network system.
- A DMZ that contains servers providing the following services: DNS, HTTP/HTTPS (web), FTP, SMTP (email) and SSH.
- Two firewalls controlling the traffic towards and from the DMZ. The first firewall controls the traffic between the public hosts (the Internet) and the services provided by the DMZ. The second firewall controls the traffic between the intranet and the DMZ.
The two firewalls in charge of enforcing the security policy of our example network, could be of the same kind. However, following the defense in depth security strategy, it is highly recommended, to use two different firewalls so that a possible vulnerability does not affect the whole network. In our example, the first firewall is a linux iptables packet-filtering firewall whereas the second firewall is a Cisco firewall implementing Cisco PIX filtering .
In the following listing we show an excerpt of the configuration files of both firewalls w.r.t. The HTTP and SMTP services. First firewall controls the traffic from the public hosts to the services provided in the DMZ and uses the netfilter iptables rule language. Note that this configuration file is written using the iptables custom chains feature, which allows the user to define exclusions to rules without using drop or deny rules. The second firewall controls the traffic from the private hosts to the services provided in the DMZ. It uses the Cisco PIX language that does not provide support to a feature like the iptables custom chains.
|First Firewall: Netfilter Iptables||Second Firewall: Cisco PIX|
|iptables -P INPUT DROPiptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -N Out_SMTP
iptables -A FORWARD -s 184.108.40.206 -d 0.0.0.0/0 -p tcp —dport 25 -j Out_SMTP
iptables -A Out_SMTP -d 220.127.116.11/16 -j RETURN
iptables -A Out_SMTP -j ACCEPT
iptables -N In_SMPT
iptables -A FORWARD -s 0.0.0.0/0 -d 18.104.22.168 -p tcp —dport 25 -j In_SMTP
iptables -A In_SMTP -s 22.214.171.124/16 -j RETURN
iptables -A In_SMTP -j ACCEPT
iptables -N NetWeb_HTTP
iptables -A FORWARD -s 0.0.0.0/0 -d 126.96.36.199 -p tcp —dport 80 -j NetWeb_HTTP
iptables -A NetWeb_HTTP -s 188.8.131.52/16 -j RETURN
iptables -A NetWeb_HTTP -j ACCEPT
|access-list eth1 remark Fw2Policy 0 (global)access-list eth1 deny tcp host 184.108.40.206 220.127.116.11 eq 25
access-list eth1 remark Fw2Policy 1 (global)
access-list eth1 deny tcp host 18.104.22.168 22.214.171.124 eq 25
access-list eth1 remark Fw2Policy 2 (global)
access-list eth1 permit tcp 126.96.36.199 255.255.255.0 188.8.131.52 eq 25
access-list eth1 remark Fw2Policy 4 (global)
access-list eth1 deny tcp host 184.108.40.206 220.127.116.11 eq 80
access-list eth1 remark Fw2Policy 5 (global)
access-list eth1 deny tcp host 18.104.22.168 22.214.171.124 eq 80
access-list eth1 remark Fw2Policy 3 (global)
access-list eth1 permit tcp 126.96.36.199 255.255.255.0 188.8.131.52 eq 80
access-group eth1 in interface eth1
Faced with this example, a security expert willing to understand the enforced access control rules will have to directly review the configuration files of the firewalls in the system, which in this case, involves two different rule languages. Not even the topology picture of the network, provided here with the purpose of easing the discussion, can be taken for granted but instead needs to be derived from the configuration files themselves.
Therefore, we can see that the task of extracting the global access control policy enforced by the set of rules in these two firewalls (that are just minimal excerpts of what a full configuration policy would be) requires expert knowledge about Netfilter Iptables and Cisco PIX. Its syntax along with its execution semantics would have to be mastered to interpret the meaning of the configuration files. Moreover, the information from the two configuration files and the default policies would have to be combined as they collaborate to enforce the global policy and can not be regarded in isolation.
In corporate networks potentially composed by up to a thousand firewalls, composed by hundreds of rules and potentially from different vendors using different configuration languages and execution semantics, the task of manually extracting the enforced access control policy would become very complex and expensive, seriously hampering the analysis and evolution tasks the dynamic environment of corporations impose. This is the challenge our approach aims to tackle.
Our (model-based) solution
In short, to solve this problem we have defined XText grammars for both languages that we use to transform the configuration files in PSMs (platform-specific (firewall) models) which are then abstracted into a generic network access-control model and merged to obtain the global security policy of the organization. This process is depicted in this figure:
Once all the access-control information is aggregated in our final platform-independent model, we are able to use the model in several interesting security application scenarios.
Abstraction from topology:
First of all, local information, i.e., access-control rules that only make sense in the context of a concrete firewall, can be identified (so that they can be filtered out when representing the global policy.). Local exceptions are usually added due to the mechanisms used to enforce the global policy. As an example, in the presented configuration excerpts the elements in the network zone 184.108.40.206 are not allowed to send or receive SMTP messages regarding the first firewall. However, elements in 220.127.116.11 are allowed to send them regarding the configuration of the second firewall. This contradiction is due to the enforcing architecture (topology) that imposes the traffic to pass through a certain firewall . This information makes it more difficult to understand the global policy. Our Aggregated PIM model serves as a basis for abstracting from this local information if needed.
Metrics and advanced queries:
Having the access-control information of a network represented as a model, enables the reutilization of a plethora of well-known, off-the-shelf MDE tools. Editor generators, model transformation engines, etc. become automatically available. An immediate application would be the use of the well-known OCL query language to calculate interesting metrics on the model and perform some advanced queries on the rules represented in it. For instance, we could easily query our model for the existence of any connection allowing the administrator host (18.104.22.168) to connect to the server (22.214.171.124) using an OCL expression like: self.connections−>exists ( e | e.source.ipAddr = ’126.96.36.199’ and e.target.IpAddr = ’188.8.131.52 ’)
Visualization of the topology:
Our PIM can also be used to derive the topology of the network, i.e., the arrangement of components and how the information flow through them. For this purpose, a model-driven visualization tool like Portolan can be used. A transformation from our aggregated PIM towards the Portolan Cartography model (Portolan is able to graphically represent any model corresponding to its Cartography metamodel) has been written. This transformation analyzes the global PIM to first, extract the Firewall elements and represent them as nodes. Then, represent the other Network Elements also as nodes and the local containment of Zones. Finally, it extracts the Connections and build the links between each Connection source Network Element to the corresponding Firewall element and from the Firewall element to the target Network Element. In the following figure we show the visualization the tool provided. In the figure, servers (element 184.108.40.206), firewalls, zones and contained elements are easily identifiably as well as the enabled connections between them. If we compare this figure with the figure of the presented example, we can see that the topology is accurately represented.
Network PIM to XACML:
Our proposed network access-control PIM is a specific representation specially tailored to the network domain. We consider that a translation from our PIM towards a more generic access-control representation will complement our approach by enabling reusing tools and results that work on the general access-control model have produced. XACML is an OASIS standard for the specification of access-control policies in XML and is ABAC and RBAC (two of the most successful access- control models) capable. Its flexibility to represent multiple policies for the same system and the fact of counting with a reference implementation, along with the increasing adoption by industry and academy, makes XACML a good choice for a generic access-control representation. Indeed, some works in the model-driven community already chose XACML as a target language.
If you enjoyed this post you may want to read our full paper or view the slides summarizing our full approach: