The first firewalls that appeared on the market in the early 1990s were simple packet filters – that is, they made their filtering decisions based solely on the sender/recipient IP addresses and the TCP or UDP ports on which the traffic was arriving. Although this was a useful first attempt at keeping intruders out, it didn't get anywhere near full security.

A useful example is a domain name service (DNS) request. Let's assume that a company's DNS lives outside the LAN, which in many cases it does (often it's the company's ISP that runs the DNS service, so you just point your world at their servers). A DNS request comprises a request and a response, and it uses the UDP protocol (which means that, unlike TCP, there isn't a connection in place for the entire process). So the DNS client sends out a request packet from an arbitrary port (say 2345 – in reality it would be anything from 1024 to 65535) to port 53 on the DNS server; the server then replies to port 2345 on the client.

In a packet filtering firewall, you'd have to set up two rules to permit these DNS interactions to happen: you'd permit outgoing connections from ports 1024-65535 to port 53, and incoming connections from port 53 to 1024-65535. The problem is, this could conceivably allow arbitrary connections into the network which look like DNS responses to the firewall but which are attempts to find vulnerabilities in the DNS software. Even if you've specified to the filter that incoming DNS responses are only allowed from a fixed collection of known DNSs, there's still the chance that those machines could be compromised and used as a stepping stone to perpetrate an attack on you (and remember, you can't limit the IP addresses of some external services – video streamers or web servers for example – if they're not the type of service where you can know what machines the users will need to connect to).

Stateful inspection
And so ‘stateful inspection’ was born – the name originally came from the labs of Check Point, the first vendor to use it, although the term has become a generic one these days. The idea is simple: instead of letting the packets through just because they have the right addresses and ports, you put them into the context of what's happening on the network.

It's a simple idea. The firewall sits, waiting for packets, and it sees a DNS request originating from an internal computer and destined for the external DNS. It records this fact in an internal table. When it later receives an incoming DNS response, it checks it against the outgoing ones it's recorded in its table. It permits it through only if the response ties up with a known request. So what it's effectively doing is putting the packets in ‘context’, or monitoring the ‘state’ of each interaction.

As technology has improved, so have the capabilities of stateful inspection firewalls (SIFs) – so these days, a SIF would not just verify that a DNS response corresponded to a request, but would examine the contents of the request and the response and would confirm that the response does indeed conform with what the questioner asked for (DNS packets are a good example here, because a DNS response actually contains a copy of the request, which allows the firewall to marry the two up very accurately).

Deep inspection
Naturally, as firewalls have become more clever, so have attackers. So if an attacker can no longer rely on sending out-of-context packets in the hope that they'll be forwarded to a vulnerable machine, he now has to get devious and do things like hiding SQL code in calls to e-commerce systems in the hope that the server will unwittingly execute that SQL. A new generation of firewalls has evolved to cater for these super-sneaky intrusion attempts, and they're called Deep Inspection Firewalls (DIFs).

In fact, ‘evolved’ is the right word because it's impossible to draw a definite line between stateful inspection and deep inspection – the two merge at the boundary. DIFs are pretty much SIFs on steroids. A typical DIF would not just put the packets in context but would go to the lengths of waiting until (say) a complete request had been received (which could potentially be multiple packets long). Assuming for a moment that it had received a Web request, it would verify that the HTTP request conformed with the appropriate RFCs (specifications). Then it might look at the document being requested to check that the caller wasn’t trying to do something like requesting a document called ‘../../WINNT/SYSTEM32/CMD.EXE?/C+dir+C:\+/S’ – that is, attempting to move outside the Web server directory and execute something on the server that they shouldn't (in this case a complete directory listing of the server's hard disk). Or it might check the URL to see if it recognises anything as an SQL statement which the attacker might be attempting to run in order to grant access to the database server, or to pull out the supplier prices of an e-commerce site's products.

Obviously DIFs require an in-depth knowledge of protocols, server operating software and applications, in order to protect the network from attack in this way. There is a further extremity to which some packages take the concept – notably to customise the DIF to understand home-built applications. So if your in-house development team has constructed a Web site that uses HTTP parameters in its operation (e.g. one called ‘productid’ to specify the product the user is looking at) then if you can tell the DIF that parameter ‘productid’ is always a positive integer between 1 and 1,000,000 it can check its validity before passing the request on to the Web server. Similarly, once you've specified all your parameters, you could tell the DIF to block all other parameters, in case they're from an attacker trying to exploit some little-known parameter-based attack to which the Web server might be susceptible.

Processing power
The evolution of SIFs into DIFs has gone hand-in-hand with the increasing price/performance favourability of server hardware, because these packages are so complex that they can only really be run in software on ‘appliances’ (it would be nigh on impossible to build one in hardware). Software equals ‘slow’ in a networking context, and so in order to keep the systems humming nicely, DIFs require powerful servers, which are only now beginning to exist in an affordable form.

We can be sure that the technology will continue to become more complex as processing power increases – though given that the firewall is understanding more and more about the application's functionality, it's not quite clear for future implementations where the DIF will stop and the application server will start.

SIF vs DIF – in conclusion
In reality, there really isn't a line to be drawn between a DIF and a SIF – it's merely a discussion about generations. Perhaps if we were to attempt to differentiate between the two, it might be to say that a SIF's internal understanding of the applications it's protecting is limited to standards and universally available applications, while a DIF can be made to understand organisation - and site-specific applications as well. In the long run, though, the best way to regard these two types of system is to see the DIF as the high-powered, higher-tech, more processing-intensive descendant of the SIF.