The technology that is the primary security mechanism has just had its 12th birthday, and while the internet, networks, attacks and systems have all changed, the firewall is still the firewall.
Prayer might be said to be the last refuge of a scoundrel, but firewalls are often the only refuge for a computer network. Still, at many conferences, I advocate taking firewalls by their network cables and throwing them in the river (to my amazement, many in the audiences have agreed). As they were being developed, firewalls were a technology meant to protect devices and applications, and they were never intended to provide security. Now, operating systems and applications (and soon IPv6) will all have been developed from the start with security playing a central role.
It used to be precaution enough to block Telnet to a UNIX-based firewall, but attack sophistication was changed forever when, in 1996, Aleph One released "Smashing the stack for fun and profit." This paper enabled the hacker community to stand on the shoulders of giants. Now, attackers didn't need to know the level of operating system architecture - everything was simplified.
In today's environment, the port blocking by most firewalls mostly provides a sense of false security. The first major change hit when encryption became almost a de facto standard for many common applications. Firewalls can't see into the encrypted activity to determine what the traffic actually holds. For the non-encryption problem, the actual solution is to turn off all non-business critical ports on the target device itself, instead of depending on a device blocking the connection attempt one step closer to the internet.
As attacks have evolved, the arguments for firewalls have evolved as well. If a port needs to be open for business reasons, the port needs to be left open through the firewall. If a port is non-business critical, the port should be turned off. In fact, I would say that firewalls solve the wrong problem. We need ports to be open, we need to connect to the internet, and turning off the business is counterproductive. The real problem with network traffic is not the destination, but rather who sent the traffic in the first place. Authentication is the key, not paranoid blocking and passing all encrypted traffic.
You may have already guessed that this month we tested firewalls - both application- and network-based firewalls. Previously, we tested network access control (NAC), and - from concept through implementation - that seemed like a better solution than firewalls. But if we at the SC Lab have learned one thing, it is to test before forming an opinion.
In this month's review, we decided to focus on the improvements to the firewall over the last 12 years. In short, we were looking for what used to be the non-firewall that now is part of the firewall. And the results were surprising. The devices we tested were more like some sort of mutant security device than the firewall of 12 years ago. These devices read into the data portion of packets to determine the attack from legitimate requests. There were other firewalls that terminated encrypted tunnels in order to first judge the contents of the request. There were even devices that could hardly be called firewalls anymore.
We saw these firewalls with new eyes, because they could actually block attack traffic on business critical ports - in other words, they could function more like an IDS, than an IDS could 10 years ago. These firewalls didn't just check the incoming traffic, but protected against data leakage as well. What really changed our minds about firewalls is when the devices asked for authentication before allowing traffic to pass. These firewalls were very close to using 802.1x for the authentication protocol. Imagine: The firewall is now talking to the RADIUS server to authenticate the user before granting traffic. It is tough now to call these devices firewalls, since they have changed as much, if not more than, the electronic frontier.