Software Firewalls: Made of Straw? I

July 2, 2005

Software Firewalls: Made of Straw? Part 1 of 2
Israel G. Lugo, Don Parker 2005-06-08

The concept of a firewall still brings to mind the picture of an impenetrable brick wall, the unsurpassable magic protector of all that is good. The bold statements made by today’s security vendors only emphasize this, with claims of complete and automatic security, with a wall able to block all perils dead in their tracks using logic that perhaps didn’t exist two years ago. But what if in reality the wall of the firewall is made of straw?
To answer this question, we need to go over a few basic concepts. First of all, what is a software firewall? At its core, it is nothing more than a filter — one that sits between your normal applications and the networking components of the operating system and decides what it will let through and what it will not. For this, it implants itself in key places of the application/network path, and analyzes what goes through against a rule set, according to specific sets of criteria. Anything that falls under the “allow” rules is allowed to pass on, and conversely anything that does not is silently dropped (with an optional log message, on-screen alert, and so on).

What does this mean from a design point of view? What are the criteria that the information is analyzed against? Well, there are two main areas that a firewall must focus on, resulting in two main components in the design of a software firewall.

The first is at the actual packet level (layers 3 and 4 of the OSI model). The job here is to look for suspicious or malformed packets, detect port scans, and assess whether or not each packet should be allowed into the protocol stack. Packets will be analyzed by networking criteria, for example: formal validity of the packet; direction of the packet (inbound or outbound); source host and port; destination host and port; specific packet flags (is this a connection attempt? Does it belong to an already established connection?).

The other component of the firewall works at a higher level, dealing with individual processes — checking whether process X should be allowed to initiate a connection to a given host on a given port, whether it should be allowed to listen for connections on a given range of ports, and so on. Basically, the firewall will act both as a per-packet and a per-process filter.

How is this done? Exact details vary from product to product of course, but functionally, at the core, is mostly the same. A true software firewall (that is, excluding the rather useless ones that merely hook socket calls) uses two drivers for the actual filtering: one for the packet filtering, another for the per-process filtering. Then there is the front end, the graphical interface, where the user changes settings. The important work is done inside the kernel, using just two drivers.

The packet filter

Concerning the lower level, packet filtering driver, this is typically implemented in one of two ways.

One method involves the use of a NDIS (Network Driver Interface Specification) intermediate driver. Basically, this driver will sit between the Network Interface Card’s driver and the protocol drivers (TCP/IP, etc). It will, in essence, become a virtual adapter, appearing to the protocol drivers as if it were the NIC driver, and vice-versa. As each packet inbound or outbound will go through the intermediate driver, this will permit it to stage a “man-in-the-middle” attack (obviously in a benign way in this case).

The other common method of implementing a packet filter is with tapping into the NDIS itself, hooking a subset of the NDIS library functions used by the protocol drivers. This means the packet filter driver will tap into the NDIS wrapper itself, sitting right between the protocol drivers and anything below. Although this is a totally different implementation, it is functionally similar to the above method.

Now, the job of the packet filter driver seems simple enough. It will analyze every packet it sees, according to the criteria specified in the firewall rules stored in some internal data structure. It will look for things such as source and target hosts and ports, level of fragmentation, protocol type, packet flags, whether or not the packet is part of an already open connection, and so on. For example, if the protocol is TCP and the packet has the SYN flag set (an attempt to open a connection), the filter will look up in its rules whether or not to allow opening the connection, based on the source and target hosts and ports. If the connection is allowed, the filter will add it to an internal list of open connections. This is how the firewall keeps track of open connections, forming the base of stateful packet inspection. If a packet is allowed by the rules, or if it belongs to a connection on the list of open connections, it will be allowed through. The packet filter driver will pass it along to the next layer – either the protocol drivers if the packet was inbound, or the miniport/intermediate drivers if it was outbound. If the packet is blocked by the rules, it will be silently dropped. It will not be passed on to the next layer, which will therefore have no knowledge of it ever existing. Optionally, a waiting thread can also be signalled to show some feedback such as an alert on screen, or write to a log file.

The per-process filter

There is still the other driver to consider in a software firewall, and for good reason. At the levels we’re dealing with in the above filtering (NDIS intermediate or NDIS library wrapper), there is no process information. Everything is just packets that are going in or out, things are happening conceptually from outside the machine from an application point of view. As such, to do the actual per-process filtering, another filtering level is necessary, sitting at a higher place in the chain. Generally, this will be done from kernel space, by wrapping the TDI (Transport Driver Interface) functionality, intercepting the functions that the applications and/or helper DLLs (WinSock) use to communicate data to and from the transport protocol drivers.

Posted in WhitePapers