We all know replacing a firewall is really hard. Even using the same vendor but upgrading to a new platform is risky and time consuming. Switching firewalls that have hundreds or thousands of firewall rules can be an enormous risk and technical challenge where the devil is firmly located in the details. One wrong move and the entire data centre network “gets it in the neck”. If you’ve every owned a CheckPoint firewall, you will know that you want to get replace it as quickly as possible to improve the reliability of your network and reduce costs 1
It’s been while since I climbed onto my “software defined horse” and talked about Use Cases for SDN. Vendors continue to tell me that no one wants OpenFlow and SDN – they say they don’t need it. What vendors lack is imagination, so I’m here to help. This post is describes how SDN could solve the firewall migration challenge.
Of course, it’s change management/ITIL that makes firewall migrations the most miserable project to work on. Endless change meetings and discussions around risk that deliver zero benefit to the business. But, hey, that’s ITIL & ITSM for life defeating experiences.
Firewalls and SDN are about Flows
A firewall doesn’t handle packets, it’s handles flows. That is, the flow between a client & a server from the time the SYN starts until the FIN/ACK tears town the TCP Session. The firewall need to handle all flows in a sessions so that the stateful packet inspection
Lets start the design with a firewall “security locked” between a Router and some Servers in a standard mode for a Internet connection 2.
Lets say that some traffic is coming from the Internet. Each IP session flow would pass through the firewall to the servers and vice versa. And the return session also need to flow through that firewall ? Of course, otherwise the firewall inspection route cannot analyse the flow state of the session and would discard the frame. The yellow arrow shows the traffic flow.
What happens when you want to upgrade that firewall to another model or another vendor. Lets face the fact that you can put up with the CheckPoint FW-1 that causes weekly problems forever. You need to divert traffic flows to your new Juniper or Cisco firewall but the only tools you have is routing. Routing is based on destination addresses only and even using /32 routes can affect multiple firewall rules. Or maybe some policy based routing (which is actually flow based routing).
By far, the most common rule for a firewall is based on SRC IP, DST IP and DST PORT. Although other possibilities exist no one actually uses them much, if at all. Lets say that this “three tuple” is enough to describe 99% of firewall rules.
|SRC IP||DEST IP||DST Port||Action|
For this collection of “firewall rules” you can see that destination address flow redirection is the same. If you are using routing, even /32 routes, then you may need to move a complex set of rules for every /32. For very large firewall complexes, this is certainly true.
Is that too granular to match a single IP/Port ? Consider a “source load split” scenario. What if you move all traffic with a source address of 10.0.0.0/9 through one firewall, and 10.128.0.0/9 through another ? What about 10.0.0.0/12 ? What about a source of 10.0.0.0/12 with a destination of 192.168.0.0/26 ? This approach would allow testing of a new firewall configuration with some smaller fraction of the overall network and reduce the risk to the business.
Here how OpenFlow Helps
Now, you might have heard about OpenFlow. There is a key fact in the name that it’s also identifies traffic flows and also allows a OpenFlow device to manipulate the flows. Here is a sample OpenFlow table showing flow data and a typical set of actions on the data (screenshot from my upcoming book on OpenFlow).
In the context of a secure environment, you can see that OpenFlow has an extended set of criteria for managing network flows. Using OpneFlow on an OpenFlow switch we could selectively identify traffic flows and redirect those flows to a different Ethernet port. Lets add a couple of OpenFlow enabled switches (it could be just one switch, but I’ll show two here for simplicity).
The elements of the solution are:
- OpenFlow capable switches (like PICA8 which are low priced and good quality.).
- OpenFlow Controller to perform the OpenFlow / Switch integration. (BigSwitch for commercial or Floodlight for testing).
- FW Migration App – this is what I’d like someone to deliver.
Here is how I see this working once you have the basic equipment in place
- The FW Migration App reads the configuration from the old firewall.
- App parses the configuration for firewall rules and build a flow table based on the rules.
- App then loads the firewall rules into the new firewall.
The application would need to be able to read the configuration using an API or, more likely, by scraping the CLI. As a one off activity that focusses on the just the firewall rules, this should be less complex than attempting to parse the entire configuration including routing, inspection rules and other random firewall features. Configuration of those “advanced features” could be the second phase (or never phase) of product development.By keeping the configuration extraction simple the product remains simplifed.
The second phase of configuration is to start the cutover on a rule by rule basis. Here is rough outline of the flow:
- FW Migration App GUI has selection button of available rules ready to cutover.
- Select the rules for cutover from the list and select apply.
- OpenFlow rules are sent to the OpenFlow switches.
- Flows are now diverted to an alternate firewall.
This diagram summaries the process.
- Read the configuration of the legacy CheckPoint firewall, parse the standard rule base. Highlight unrecognised rules or actions for user intervention 3
- Push the rules into the new firewall. Engineer performs a manual verification.
- Engineer selects a few rules for migration to the new firewall and OpenFlow rules are dispatched to your OpenFlow switches. All IP Flows matching the flow table are diverted into a different Ethernet port where the new firewall is connected.
Now you have forced the flow over to the alternate firewall while other flows continue to traverse the old firewall.
Once you have migrated all the rules, you can shut down the old CheckPoint and rejoice like these fine people did.
The OpenFlow flow direction is performed in silicon therefore forwarding performance is not consideration. Using policy based routing can be tricky since not all hardware supports line rate forwarding. 4 There are limits in the switch devices on the maximum number of OpenFlow entries in the TCAM that you may have to be careful. Some of todays switching can only hold a few thousand OpenFlow flow entries but is expected to increase in the next year or two as the next merchant silicon chips arrive.
How much is this worth ?
I’ve performed about a half a dozen large scale firewall migrations over the last 10 years. Each of these projects costs millions of $moneys in project time and resources. The real cost is change management, location of service owners and planning meeting which take thousands of man hours. The largest project I’ve worked had a 10 person FTE team for nine months to migrate a firewall cluster (only 2 engineers) plus additional time for executive intervention, management review etc etc etc. I’ve heard stories of a single large institution with 900 obsolete firewalls. These units are costing multi-millions in post-EOL support contracts but that’s cheaper than the cost of upgrading them.
The EtherealMind View
It’s not a billion dollar per annum market so the big vendors won’t be interested in developing this as a product. But I figure a smaller vendor could readily enter the OpenFlow application space and start attaching to high value customers with a low risk product. Because early stage products can rely on the engineer for manual validation, which would happen in a normal project, there is actually very little business risk.
After thinking a bit more, I’ve also realised that you don’t need an application – it would be possible to use the current versions of BigSwitch & Floodlight controllers and manually define flows. Not as simple as using an App but it would get the same result.
That’s my example of an SDN Use Case that is just one of many that SDN/OpenFlow makes possible.
Let me know if you are interested, maybe someone who works for venture capital firm is reading
- The maintenance cost on a CheckPoint firewall makes Cisco looks like a dodgy used car dealer. ↩
- Well, highly simplified anyway. I’ve built arbitrarily complex firewall clusters in my time with three layers of firewalls and dozens of DMZ. The basic premise holds true here. ↩
- Remember that the alternative is to do the whole thing manually anyway so a few manual rules isn’t a show stopper for the product. ↩
- I’ve spent hundreds of hours researching whether a given piece of hardware supports the necessary features. Or determining products that can do this. ↩