Firewall architectures - a look at some critical system platform issues
Imagine a LAN as a building with its size in proportion to the computer network size and capacity. The building has its offices - workstations, store rooms and archive rooms - servers, corridors that connect various building segments - routers, the guard hut - the DeMilitarized Zone (DMZ). When implementing a defensive system for building security, the designer must plan the positioning of firewalls in advance so that they will be able to block a fire and protect as much of the building structure as possible. It's obvious, that all walls of the building might be made of a firewall technology, but the costs involved would become magnified out of all proportion. Striking a happy medium is necessary. Therefore, when considering firewall deployment, the designer must well address the following question: "From where would a threat to my system most likely originate and for what reasons?" Once the places of potential origin of the fire have been determined, the designer can attempt to make a layout of firewalls. The similarities end there however. The designer of a building is allowed to be free from the fear that a disgruntled employee might set off a fire in the office using the furniture, whilst on the other hand the firewall designer will have to take into consideration such events.
Many users inside the protection of a firewall may believe that their systems are safe, since the firewall sits between the LAN and the public network. This is risky thinking; because firewalls are perimeter security only (even those being equipped with "true" firewall features) and once bypassed provide little or no security. A firewall based on a "better than nothing" philosophy runs the considerable risk that may provide a false sense of security. If you are considering implementing a "true" firewall, remember that a consistent security policy must be outlined in advance - and this is not a concern of the elaboration methodology but of its essence. The security policy must determine how basic communication will take place at the firewall, where the firewall must sit and how to configure it. The security policy should also define if more than one firewall is required (or maybe, that a firewall would be of no use) and what should the connectivity scheme be. Once installed, a firewall system is an ongoing process that requires constant vigilance, maintenance, log reviewing and response to events. The inability to keep these requirements satisfied, and sometimes made worse by an inadequate or poor administration that would weaken any protection provided by even the best firewall, would result in it becoming nothing but a murmuring and flashing electronic box, yet adding the danger of providing the illusion of security that can further erode the private network itself.
Firewalls are typically implemented using two approaches. The firewall literature is full of theories that categorize firewalls as hardware-based and software-based ones but there is nothing in such a classification that reasonably suggests a hierarchical point of view. I think instead, that a less debatable and apt classification will be that of using the notions of a dedicated and non-dedicated firewall hardware and system platform. Such an implementation approach may become an important factor in choosing a firewall solution, although the very decision must be taken directly by an experienced and knowledgeable system administrator or person installing the firewall. A must-have for any non-dedicated firewall application system is a proper installation of the operating system on which the firewall will be placed. A "proper installation" means that the operating system must be suitably "hardened" (i.e. configured for security) and especially for this reason, no service going beyond the necessary minimum may be run on the operating system. With dedicated firewall hardware and software platforms, it is very likely, that they are sold with their minimum protection (without useless overheads) built in by the manufacturer and ready to power on and configure. This does not imply however, that turnkey solutions are always better than non-dedicated own applications, since commercial products might not be free of manufacturer's errors, and as such, more difficult to be debugged in respect to non-dedicated tools. So in this case, firewall management is also a critical issue because the firewall administrator must not only know how to manage a firewall, but also how to maintain and upgrade it for security. Another important consideration in implementing a firewall is a reduced capacity of key network nodes. Once in place, i.e. in a private network, a firewall would appear to be a source of constant problems and concerns regarding its proper functioning. And it would be indeed, if a firewall has been purchased and implemented for the wrong reasons, without an understanding of its role in the infrastructure of a private network. An important caveat to remember: you can't use just any firewall.
Benefits and risks
A firewall is primarily used to protect the boundary of an organization's internal network whilst it is connected to other networks (e.g. to the Internet). A typical misconception is, as I already mentioned, to use perimeter routers for performing this role. At the very least, perimeter routers can be employed in two ways: either without packet filtering rules involved or by using an IP filtering router solution (most likely together with a dynamic NAT) selectively passing or blocking data packets based on port information or addresses acceptable by the security policy. Of course, a firewall must always be situated next to the router. Some practical solutions to this are illustrated in Figures 1 and 2 below.
In these examples, a perimeter router controls traffic at the IP level. I think this device should be considered the first (but not only) line of defense protecting a private network. In implementing the packet filtering mechanism, it is a good idea to run this service on perimeter routers placed inside private networks (that separate two networks) primarily to block unwanted packets accessing other LANs. The criteria used in filtering rules for determining the disposition of packets (accept or reject) should be consistent with the specific security policy, not established at the discretion of the system administrator. In each of the figures there is an isolated area called DMZ that stands for DeMilitarized Zone. A DMZ in the IT sense is an interface that enables the network designer to setup different rules of access for both networks separated by a DMZ for better security. Secondly, the implication of a DMZ is clear; an acceptable tradeoff involved here, is that it would be preferable to have a machine that is a more "attractive" target hacked into, for example, the Web server, that may be re-assembled in a few minutes, than it is to have the workstations or local servers that often contain a company's strategic information hacked into. There is a catch however, that with such a solution, because it presents an essential flaw, namely that of a lack of separation between servers and workstations across a private network, insider attacks are more likely to occur or, an intruder may use an internal workstation as a jumping off point for an attack, for example, by email. To avoid this, internal servers should be isolated by extra internal zones protected by a firewall (or more firewalls if so required).
Such solutions however, are seldom used due to a poor cost-to-benefit ratio. For the servers in private networks to operate effectively, they must be appropriately protected, whilst a consistent security policy should make it impossible to get into protected areas by unauthorized users. In addition, any attempts to break into a private network could be simply detected and restrained using administrative and legal measures. The approach described above seems to be a reasonable means of providing segregation and protective isolation between various internal departments of a large organization, for example to "isolate" a research center in order to protect the research results from being captured by competitors or in large private networks such as academic and corporate networks. Here, the approach is based on physical separation of network boundaries. Figure 4 below illustrates an example of this type of network.
The R1 and R2 are perimeter routers of a private network. I consider that the objective here should be to distribute tasks between different devices (following the philosophy: "less components, less prone to damage"), let's say, the initial packet filter can (or even should) be made only on the perimeter router, regardless of whether other protective provisions have already been implemented. Also, a dynamic NAT may be deemed necessary to sit on this device (although not always feasible). F1 - a firewall, that establishes the DMZ access rules where public servers sit. F3 and F4 are provided for dual purposes. First of all, they define a set of rules that control traffic between a private network and a public network moving in either direction. These firewalls provide VPN support for interdepartmental connections. Physically it may be a pair of copper wires, leased from an ISP, a wireless connection or any other means. Also, physical boundaries between private networks are defined by these firewalls. F2 and F5 firewalls perform similar functions within the local networks that they have been installed - they establish rules of internal server access to be followed by private subnets. Additionally, the F2 is to eliminate unuseful traffic between the subnets 1 and 2. These examples do not pretend to be models to follow in building a private network. They are merely some criteria for weighing the choice of firewall application. The reality is that this is a security policy decision first, and a firewall implementation (if at all) issue second. The above solutions still do not define what types of firewalls are to be installed across a network. Selection of firewall type and locations should also be consistent with a comprehensive security policy. Finally, the benefit of any firewall depends upon a critical issue that is common for all applications, and which may compromise the reliability of the network as a whole. Typically these solutions are enough but not always perfect: if a public network or a specially protected subnet ceases to be reachable even for a little while, the firewall application fails. In order to avoid this, redundant systems are used by configuring these systems so that, either all of them control both the incoming and outgoing traffic simultaneously or so that they resume operation after receiving a message signaling a failure of the primary system.
Unconventional solutions - how to setup a simple firewall trap
Another specialized application of firewalls exists, that is often presented in the media but with little practical guidelines given on this issue. Many approaches are possible, therefore the drawing below is a merely a preliminary outline of an idea of such a system. It involves constructing a firewalled trap-network. The theory is that a firewall, to be efficient, must very carefully monitor any incoming and outgoing traffic and reconfigure access policy rules in real-time.
Suppose a user attempts to get into the company's Web site. Because no malicious intentions are detected, a connection is established. If an intruder were to attempt to access a similar connection, he might begin with scanning the address space of the company. A firewall that is in place detects the hacker's attempt and redirects attacking packets to a trap-network, that may be constructed, for example, by isolating a separate (private) address class on a free firewall interface, so that the dangerous traffic would be transferred onto another network interface. Thus, the intruder enters a server that acts on behalf of the company's Web server. If the intruder neglects to mount a destructive attack for a while, he would probably resume an attack after a certain time, trying to gain access to the "true" server; any hacking action would result in redirecting it to the mimic server, but the consequences (many intruder's footprints) of his attack would be only visible to him and the system administrator. The firewall trap system's ability to replay stored attacks would be used for post-mortem and forensic analysis. Naturally, this was an example of a very simple trap. In the figure, there is a device indicated as an IDS (that stands for Intrusion Detection System), which under certain circumstances may operate in a standalone manner and re-configure a firewall with which it operates in conjunction. And what happens if an intruder immediately begins his attack with no scan attempts but directly, by using an exploit technique (most pseudo-hackers use it, in fact)? Of course, such attack would pass through the network gateway, since over here the traffic is not examined at the application layer. With lower-layer based firewalls, only an IDS tool can provide an effective solution that will be able to automatically re-configure the network gateway, thereby redirecting the traffic to the trap network.
Some tips - reacting to events is a vital concern
No event response - no sense in having a firewall installation. The last topic I'd like to touch on is an adequate countermeasure against any suspicious events. I think this issue directly implies the need for knowledgeable and experienced IT system administrators. When your security system identifies an attack, a little common sense and no panic is recommended. An attacker, once scared away, is likely to penetrate your assets next time. If an intruder's actions do not pose a direct threat (e.g. network scanning), do not block them but carefully try to gather information about the attacker and the attack (for further purposes). A more experienced individual may prepare an isolated network segment to setup a trap for forensic analysis and for the undertaking legal steps against the intruder. I think that many administrators react too quickly to incidents, while others instead, ignore them with perhaps even worse consequences.
Summary - what is the recommended type of a firewall?
When it comes to buying a firewall, there are many choices available on the market that offer their firewall products as those that ensure as high as 100% network security and as being able to solve any security problem that it's potential users may encounter. This is a staple of typical "cheesy" marketing where strengths are accentuated whilst weaknesses are made irrelevant. When examining the firewall solution to purchase, consider if and how the firewall supports any security services that you may need. The security policy document will answer these questions; therefore consideration of security policy issues is of key importance. Also, the security policy's role is to indicate whether your network needs a firewall and what would be the expected cost/benefit ratio when buying a firewall and/or when installing it. Once you select either a turnkey solution or a non-dedicated hardware and software platform-based firewall, plan to spend some time figuring out who will appropriately configure and harden your system for security. When looking at firewalls, a key factor to consider is the administrator's experience with these security tools. A firewall is designed to be the single point of traffic into and out of the network that it protects, and as such becomes a single point of failure. So, perhaps it would be more secure to select a firewall that represents your intuitive idea of a configuration, although with less adaptability, but also with less of a risk of having flaws exposed in your firewall resulting from inadequate experience in this field. A good practice is to fully configure your product before you buy it - using even a piece of paper - and analyze all possible scenarios. If you do all of your homework and ask the right questions beforehand, your firewall implementation will run much more securely and reliably.
1. Chris Hare, Karanjit Sijan, Internet Firewalls and Network Security, New Riders Publishing, Indianapolis 1996.
2. Micki Krause, Harold F. Tipton, Handbook of Information Security Management, CRC Press LLC, (electronic edition) 1997.
3. Dominik Miklaszewski, Zapory ogniowe - praca dyplomowa, Szczecin 1998. (In Polish only)
4. Matthew Strebe, Charles Perkins, Firewalls sciany ogniowe, Mikom, Warszawa 2000. (In Polish only)
5. Merike Kaeo, Tworzenie bezpiecznych sieci, Mikom, Warszawa 2000. (In Polish only)
6. Vademecum Teleinformatyka, praca zbiorowa, red. zespo Networld Magazine, IDG Poland S.A., Warszawa 1999. (In Polish only)
7. D. Brent Chapman, Elizabeth D. Zwicky, Building Internet Firewalls, O'Reilly Press (electronic edition) 1995.