OK, maybe they’re not totally dead, but they’re being demoted. To the mail room.
During the course of my career I’ve always had at least some responsibility for firewall and security devices. In those ~15 years, how these boxes are built and function has shifted. From the perspective of my career, there were IOS ACLs (yes, I know, not a firewall), there was the IOS firewall versions and there were software packages such as gauntlet, checkpoint. There was the Cisco PIX. One installation I worked on in a past life even chose to use IPFW on BSD boxes. Then came was the Sonicwall, a newer take on how to manage a security appliance via a web interface. There was the FWSM. A few things stayed the same. Dedicated hardware.
Being a networking guy by nature, it always irritated me that the inline security devices were 3 years behind networking….at best. Working in a service provider and in research and education has given me a bit of a different take on firewalls and IPS devices as well and has only solidified this belief.
There are a few things that make firewalls and IPS devices an unholy thing in the world that I live in. Since I love bulleted lists, this is an opportunity to use one:
- They get in the way. Of course they to, that is their job. Big data flows, Multicast, jumbo frames, IPv6. There are boxes that can finally do these things, but they are 5-7 years behind and even now are often lacking in support and features.
- They’re expensive. When considering CAPEX, they are often prohibitively expensive compared to something like a passive IDS. Not many budget for a firewall / IPS that can do multi 10G at line rate, IPv6, Multicast and can handle things like GridFTP flows, because until recently they didn’t exist.
- Speeds and Feeds are always first. I worked on 10G and OC192 on the WAN around 2002 with 10G on the LAN around the same time. The first real firewall I saw that could even fall into consideration for that was the FPGA based P10 from Force10 in 2005 (we had an early demo). It was a really innovative device but even it was very clunky since it was an FPGA and caused service interruptions every time you needed to push rules to the FPGAs. The Juniper SRX came much later at 2009, and even it had some issues back then. There exists a handful of options now, the Sonicwall SuperMassive, the Juniper SRX and the Palo Alto come to mind but they’re late. 10G is old hat to some of us. We’re on to 40G and 100G. What now?
So, lets get down to the buzzwords. Cloud. Data Center. Virtualization. SDN. OpenFlow. Ironically enough, being “buzzword compliant” is actually relevant to this commentary. With the advent of virtualization of nearly everything, including the network, vendors are adding things like virtualized firewalls. Juniper has added the JunosV Firefly, Cisco has added the VSG. There are surely others. This movement is just in it’s infancy, but it’s big and I would venture to say that it is game changing. With the huge amounts of cores and memory in virtual machine hosts, it makes sense that the network become part of that for management, total cost of ownership and usability.
The really interesting part of all of this comes not with the virtualization of firewalls, but with the commoditization of network silicon. Chip makers that are spinning ASICS need to make sure their ducks are in a row since, in my personal opinion, there are a lot of options for LAN and data center equipment. Arista is already on top of this. Others vendors will adopt this methodology as merchant silicon adds more abilities. Firewalls will are on their way now. Eventually WAN gear will come around.
What I’m really excited about is the prospect of a merchant silicon based, 40 or 100G OpenFlow based “Firewall”. The foundation is already laid for this. Floodlight already has a dev module for building a firewall with OpenFlow. I’ve not tested this extensively yet. It’s on my short list but wether it works or not isn’t really even relevant. The fact of the matter is that this is the way to a comfortable security perimeter at a reasonable speed for a far more reasonable price tag.
Think of buying an OpenFlow capable device with 40 and 100G interfaces in it as your firewall and IPS device. Port cost is very low. CAPEX is low. OPEX is also fairly low since it is just a normal piece of network hardware. Management is accomplished via an OpenFlow controller.
Rules are pushed manually or programmatically based entirely on site policy. IPS functions can be performed via a passive system like BroIDS or Snort triggering rules in OpenFlow much like is being commonly done with black hole routers now.
This will happen. It’s already happening.
Firewall vendors take notice. Have a strategy for Virtualization. Have a strategy for dealing with OpenFlow and SDN.
It is my belief that once the reporting and management is even half as good as a Palo Alto or Sonicwall, the market will start to change based solely on cost. There is already work being done on this as well.
Am I right? Time will be the judge, but I suspect I am.
I’m now working on the theory that I can flow balance white box Intel servers with a hypervisor. The hypervisor would host a VM that runs a firewall. Current Intel servers can handle up 40 Gbps of raw throughput so I’m expecting 50% in real use. Ten white box servers with rapid upgrades for both hardware and software sounds like a solution to me …..
What everybody seems to forget is that actually simple stateful inspection firewalls are the walking dead. Modern firewalls do a lot of inspection at layer 7 (think Palo Alto Networks). I want to see one of those white box Intel boxes push 20 gigabit of application level firewalled traffic. I highly doubt it.
And I am also curious how you want to put OpenFlow to use here, when basically every flow would need to be forwarded to the Controller and passed on to the “OpenFlow Firewall” for inspection.
In other words: I don’t believe you can get rid of ASICs just yet and you will need hardware firewalls for the forseeable future.
The controller in an OpenFlow architecture is only used for managing the firewalls, defining the policy, pushing the policy, and other overhead operations. The firewalls are left to do their core functions, so the traffic wouldn’t need to be backhauled to the controller.
The controller in an OpenFlow architecture also makes decisions for unknown/undefined flows. Flows that a switch doesn have in it’s forwarding table are being sent to the controller. Now if you think of a firewall, it will naturally have truck loads full of unknown flows, especially if the firewall is placed at the edge/perimeter of a network.
Don’t get me wrong, I would personally welcome our new OpenFlow Firewall overlords 🙂 But I just don’t think that OpenFlow firewall setups would scale and perform anywhere near as good as dedicated, ASIC-based firewalls for a long time to come. I am talking real firewalls here, not simple enhanced ACLs (read: stateful packet inspection).
If you reduce the OpenFlow controller to simply being the management system (policy definition etc.), then why use OpenFlow in the first place? We already have firewalls with separate management software. Nothing new.
Not quite. There are controller architectures that put some controller functions, like packet inspection, into the device. Consider a master controller with the full database of thousands of rules could distribute OpenFlow entries that are relevant to exact device.
Instead of one big firewall process running thousands of rules, I have hundreds of smaller devices running tens of rules. CPU is less important and security is improved since firewall are located where the data is.
Interesting concept, Greg. Although that’s already reality today without OpenFlow. Check Point Provider-1 management platform does exactly that. Junos Space does exactly that.
Of course the nodes are not tiny cheap white boxes but expensive firewall appliances.
Still, to me the question remains whether plain x86 hardware is able to scale when we are talking complex layer7 inspection, IPS, DDoS prevention etc. We’ve already seen Check Point fail miserably with their software-only firewalls when it comes to performance/throughput. There is a reason for Fortinet/Juniper(SRX) being selected over Check Point in large datacenter designs.