One of the major challenges in the area of Automation & Orchestration in big network environments is to determine on which devices should be executed specific automation tasks. This task could be on the Firewall for example: add Firewall Rule – allow/block src and dst with service XY. This is maybe the simplest use-case for firewall automation.
With one Firewall it is not a problem because you are running automation tasks only on one target. If we have a bigger network infrastructure with more Firewall between source and destination system this could be a huge challenge for automation and enhanced logic is needed to choose the right firewalls/targets for the automation tasks. From the Automation point of view, we must know the exact Firewall target on which we will execute the tasks such as Firewall policy change and that is valid for all Firewalls in the path.
1. Data Format for Firewall representation in the network path
The Firewalls in the network path between source and destination system could be represented with the two dimensional X Y matrix. Optional the diagonal in the matrix could represent the “last resort” Firewall.
In simplest case we have only two firewalls in path e.g.
There could be two main use cases for the connected networks:
1. The Subnet is directly connected to Firewall
Subnet 10.0.2.0/24 – Firewall_B is the last hop Firewall
Subnet 172.21.2.0/24 – Firewall_Y is the last hop Firewall
2. The subnet is routed on the firewall
Subnet 10.0.1.0/24 – Firewall_A is the last hop Firewall, the network is routed
Subnet 172.21.2.0/24 – Firewall_Y is the last hop Firewall, the network is routed
Example Network Diagram for this use-cases is showing networks which are directly connected to Firewalls and networks which are routed behind Firewalls. Routed networks have other Layer 3 active devices present between the network and Firewall
This example table is valid under condition, we have symmetric routing between systems. if we would had asymmetrical routing in the network present, the other half of the matrix must be also defined. The source and destination would have a decisive meaning.
Advantages:
a) Strictly defined relationships between Firewalls and Subnets
Problems to solve:
a) Matrix representation with more than two Firewalls in path
b) Hard to hold the table up-to-date
c) Obtain correct Firewalls in the path
2. Matrix representation with more than two Firewalls in path
The first Problem (a) with more than two Firewalls in the path could be solved by enhancing the table. Definition of the path will be more complicated but again strictly defined
Example:
The table for this use-case looks like:
This could be one form that represents Firewalls in the path between source and destination systems.
3. Matrix keeping up-to-date
There are two most common methods how to built up this matrix. The first method is to build up the matrix based on configuration of the Firewalls such as routing and interface configuration. This method has one major problem – it must not necessary represent the real path in all use-cases.
The table could be static defined if there are not so oft any infrastructure changes regarding Firewalls, Routing and Subnets. In big Network Infrastructures is almost impossible to hold such tables up-to-date by hand, therefore must be updated dynamically. The major problem is to automate the mechanism which will hold this table always up-to-date.
One approach how to determine the real path would be using probes. Beginning with the simplest probes such as trace route – A traceroute provides a map of how data in the network travels from its source to its destination.
Requirements for this mechanism:
- Icmp (type 8) allowed on all Firewall targets for Firewall own Interfaces
- Note: if allowed also on all L3 network devices (e.g. routers) more enhanced and accurate path discovery could be made for the future use-cases
- Machine residing in source network (172.21.10.10)
- Machine residing in destination network (172.21.20.20)
Example Network diagram for this mechanism
Example output of the traceroute probe from source 172.21.10.10 to destination 172.21.20.20 will be looking like:
1 – 172.21.10.1
2 – 10.10.1.1
3 – 10.10.2.1
4 – 10.10.3.1
5 – 10.10.4.1
6 – 10.10.5.1
7 – 10.10.6.1
8 – 172.21.20.20
4. Obtaining the Firewalls in the path
Under assumption we have list of Firewall interfaces from all Firewall targets we can parse the traceroute for the firewall interfaces. The Firewall interface IPs could be obtained either from parsing the configuration or from show interface configuration.
Result after parse will be looking like:
2 – 10.10.1.1 – Firewall A
4 – 10.10.3.1 – Firewall K
6 – 10.10.5.1 – Firewall L
Now we have a list of targets for automation on which the Firewall Rules should be applied for this network connection.
5. Disadvantages / Problems to be solved
This mechanism has another major disadvantages / problems to be solved:
- mostly in bigger environments it is not possible to place machines for probing in every subnet
- Working only with Firewalls in routed mode, not working with Firewalls in transparent mode
- Obtaining Firewalls in the path in environments with dynamic routing protocols