Enough with “firewalls”
A mythical conversation on firewalls, and some observations
“Let’s put the firewall here, so it can protect the servers in this part of the network.”
“How would you define a firewall?”
“You know, the appliance that, well, protects servers and other machines from outside threats…”
“And how does it do this?”
“By filtering the traffic using some sort of stateful mechanism, and network address translation, and deep packet inspection, and blocking certain ports, and…”
“In other words, it’s a bunch of services on a single device?”
“Yes…”
“Then maybe we should think in terms of services instead of appliances.”
I’ve never actually had this conversation, but I’ve had many similar ones across my times as a network engineer. I’ll admit, in fact, that it took a lot of conversations like this (with me on the receiving end) to grock the difference between a service and an appliance, and to see that my constant thinking in terms of appliances (or even devices) was actually hindering my ability to design networks. Let me give you two specific reasons you should think of security services, instead of security appliances.
First, When you disaggregate the “things a firewall does” into services, you can see that they don’t always make sense as an appliance through which traffic is routed (either by cabling or tunneling, take your pick). For instance, assume the typical firewall as an appliance has the following features—
- network address translation
- VPN tunnel termination
- threat identification through deep packet inspection
- port based filtering
- stateful packet filtering
Now it could be that it makes sense to locate all of these services in place in your network. Or, in fact, it might not. For instance, threat identification through deep packet inspection should ideally be as close to all endpoints as possible—including installed on the endpoints, rather than living as an appliance in the network. Sometimes it might make sense to put simple port level blocking in a different place than stateful packet filtering—particularly if you have a situation where symmetric stateful filtering is hard (or perhaps impossible) to implement. And yes, this might also mean this type of service needs to move to the actual server, rather than being an appliance that lives in the network—or it might mean pushing traffic through a virtualized service, trading network utilization against security and operational costs.
Second, thinking of these services as an “appliance” limits your “out of box” thinking in many ways. Let’s say you end up working on a network in which all traffic must be encrypted all the time. Hmmm… You could always terminate all the traffic into the “firewall appliances,” but do you really want to do this? Perhaps, instead, you could do basic port filtering in the network, and offload other security services into the hosts. Or maybe you want to push traffic through some virtual services so you can centralize key management a little more easily.
What if you run into a situation where deep packet inspection is much more important than port based filtering, such that deep packet inspection consumes a lot more CPU and memory? We can work this problem like a mainframe by buying ever larger appliances to support the single service on the appliance, or… We can take a lesson from the last decade, and disaggregate these services into virtual instances, so they can be scaled out independently on an “as needed” basis.
The firewall, of course, only serves as a proxy for almost everything we do in the network—everything is a service, including calculating the best path, forwarding packets, etc. Packet forwarding, of course, is always best served in hardware on individual network forwarding devices, but everything else should be negotiable, depending on the needs of the specific network.
Enough with firewalls. Talk to me about services.