by Bob Rudis and Phil Kostenbader
Hardware and software firewalls promise to protect your system and your network from the dangers of the Internet, but how well do they really fare against cutting-edge attacks? This article presents some of the major differences between hardware and software firewalls and illustrates the real challenges faced by software firewall vendors.
Hardware versus software
Firewalls come in many different flavors to meet varying needs of users. There are dedicated hardware firewall appliances, like the Cisco PIX, complete with cool flashing lights, that provide security for whole networks. There are also dedicated software firewalls, such as CheckPoint/ipchains/iptables/ipf/pf, running on robust operating systems used as gateways that also provide complete network security. Finally, there is a new generation of "personal" firewalls that are designed to run on and protect workstations and servers directly.
Dedicated hardware or software firewalls usually provide at least one-dimensional coverage -- port/IP blocking -- for your network. Some even provide two-dimensional coverage by adding active intrusion detection (IDS) or intrusion prevention (IPS) to their basic functions. Personal firewalls can even go one step further and provide three-dimensional coverage with the addition of active application blocking.
Most organizations will end up deploying a combination of dedicated and personal firewalls to provide comprehensive asset protection both on and off their internal networks.
Perils of personal firewalls (and other dedicated firewall software)
While dedicated and personal firewalls are usually managed in a similar fashion, personal firewalls are more challenging for IT departments to deploy and control. Local users with administrative privileges -- not an unlikely scenario in most shops running Microsoft Windows -- will be able to start and stop the firewall process at will. Similarly, users with sufficient privileges or malicious programs that exploit a vulnerability on a system will be able to install software that "climbs over the top" of the firewall. In situations where the user is notified of potentially dangerous activity (usually via a pop-up window), too often they will typically select "allow", fearing the loss of the ability to operate on the network. This is the most typical mode of operation for viruses or worms spread by e-mail or spyware installed through a web browser.
Since most large organizations worry about support costs, they are unlikely to even have a personal firewall configured in this highly restricted mode. Generally, the firewall will be deployed with the most basic policy possible to protect the system with no potential to interfere with core business functions. Even if more restricted blocking is in place, web, e-mail and other types of standard Internet traffic will usually be allowed from "standard" components and thus provide an equally accessible conduit for malicious programs.
Once something comes in "over the top" it is, unfortunately, all too easy for it to dig its way out underneath or even go straight through the firewall.
Most personal firewalls operate like a bouncer at a nightclub: they are a part of the system and look closely at folks coming in and are aware of who's going out. But how closely can they really watch everything? Will a bouncer catch a patron stealing something they could be hidden in their pocket? Will a bouncer profile who they are going to watch and miss those that do not fit the definition?
In much the same way, personal firewalls operate as either an application or as a combined application/kernel component that sits and watches what it is fed by the network component of the kernel. Like a bartender, the operating system doesn't really even concern itself with what it's processing (remember, it's the bouncer's job to restrict access). If one could devise a way to consistently stay out sight of the bouncer and get direct access to the bartender, the drinks would never stop flowing. The practical question then remains: is it possible to have network traffic flow through a system and never be seen -- or at least cared about -- by any active personal or dedicated software firewall? The answer, unfortunately, is yes.
Wormhole-tunneling with PCAP
PCAP is a library designed to provide applications with the ability to access network interfaces using a standard API and capture packets directly. Perhaps the most common example of this is the Ethereal program. Ethereal is an open source, multi-platform packet sniffer and protocol analyzer. With it, one can get a raw view of what's coming in and going out of the PC. The following scenario uses just Ethereal to demonstrate how trivial it is to bypass these software firewalls.
Now, if the firewall is blocking all inbound TCP/UDP packets, how is it possible to see the traffic? Obviously, Ethereal is seeing the packets before they reach the firewall. Do a full nmap (http://www.insecure.org/nmap/) port scan with OS detection (which should fail) against the system. If the firewall is running any type of active protection mechanism, it would detect and block this scan even if the inbound policy was not set to block all traffic. However, the point to note is that Ethereal still sees the traffic.
Based solely on this simple scenario, it is clear that libpcap can be used to listen for inbound traffic that is supposed to be blocked. This provides an unfiltered incoming channel for malicious programs. If it were possible to send packets out via this same "wormhole-tunnel" then a malicious program would have a full, two-way communications channel to operate on.
For sending packets, once again we see that the libpcap library provides comprehensive support for this see Sending Packets with libpcap. The outbound traffic goes completely underneath the firewall.
Unprotected on the road
While the scope of this paper is focused on software firewalls, the next scenario adds VPN into the mix since most "road warriors" run a combination of firewall and VPN in order to use resources on their home network while protecting the mobile asset. Let's look at this scenario.
In a VPN configuration, most personal firewalls are configured to drop their shields (because all traffic is heading to and from a trusted source), so the VPN client is, in fact, a liability because there is no need to use a libpcap outbound wormhole-tunnel communications channel. The firewall will happily ignore whatever packets a malicious program might need and they go unfiltered through the "secure" VPN connection.
Creating and using a wormhole-tunnel communications channel is not limited to malicious use by malware, spyware, viruses or worms. The following scenario illustrates how one can legitimately (and more robustly) bypass the firewall without the use of libpcap.
With the firewall blocking, run an nmap scan against both the PC's IP address and the emulated environment's IP address. The firewall will block the PC scan, but the emulated environment will gladly respond back to the probe attempt, as shown below in Figure 1.
The emulated environment is using similar techniques to "bypass" the firewall and use low-level network kernel access to perform its functions. In the example screen capture, the VMWare machine has an address of 192.168.0.7 and the host PC has an address of 192.168.0.4. The scan was performed from 192.168.0.2. The firewall -- running on 192.168.0.4 -- shows the blocked scan attempts.
Below, Figure 2 shows the results of the nmap scan of the VMWare client.
If both scenarios two and three are combined, the setup will have a workstation with a VPN connection (with spilt-tunnelling disabled) and also a running VMWare client. While the VPN is engaged, the VMWare session will have complete access to the local network. With some configuration tweaking and some minor scripting, the VMWare client could act as a "bridge" between the local network and the VPN target network -- something that should be disabled when split-tunnelling is disabled.
Protecting systems/networks with (and from) PCAP
There are legitimate uses of the libpcap library, beyond traditional packet sniffers, that even go so far as to help protect networks from attack. Scenario 4 shows an example of this.
Despite any potential good that libpcap-based programs might offer, there are some steps that can be taken to defend against malicious use of this wormhole-tunnel channel:
As attacks become more sophisticated, the traditional multi-layered approach to security will become more and more crucial to ensure the integrity of systems and networks. These wormhole-tunnels have the potential to increase the number of "zombie" PCs on the Internet even further -- estimated at one million already -- since they can bypass unmonitored protection mechanisms. It is important that users be educated regularly on all of the threats they face when connected and that all systems are deployed with a defense in depth strategy. Using the approaches in this article will help you secure your network from these threats.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.