Controlling who has access to what on your network, both inside and outside, is the task of the firewall. The most fundamental component of security, it is at once both overrated and underused.

  • E-Mail
By  Jon Tullett Published  March 15, 2001

Introduction|~||~||~|In many models, a corporate network resembles an onion, with layers of services and applications. Most of the time, especially as your network opens up to external partners, customers and other third-parties, you want to be able to control who and what can move from one layer to the next, just as you want to control who can access the onion at all.

In essence, any time you can identify a network boundary through which traffic should be controlled, a firewall is the mechanism you use.

Most frequently, that boundary is the point between your corporate network and the Internet, but that certainly is not the only use for firewall functions, although that is an oversight many network managers make.

A terribly common mistake is the "I'm not a target" assumption. To be sure, your particular domain may not be singled out for attack by your enemies, but that is not how crackers (especially the notorious script-kiddie variety) operate.

Many crackers operate by scanning large blocks of IP addresses for specific vulnerabilities (and indeed there are numerous tools to automate such a scan). Once found, those vulnerable networks are attacked, often automatically by the scanning tool.

To the attacker, you are nothing more than an IP address. As such, everyone is a target. And with the proliferation of cracking tools and scanners, it is surely only a matter of time until someone picks a block containing your IP addresses. On the basis of that assumption, that interval is the time you have left to secure your perimeter.

Another basic mistake is to assume that only incoming traffic needs to be filtered. That is not only wrong, it is also dangerously lax, and the cause of many security violations every day.

Distributed denial of service attacks, for example, could be completely prevented by the application of a simple firewall rule on outgoing traffic (of course, a well-configured firewall would have caught the initial communication between the DDoS agent and its co-ordinating server).

Are you prepared to deal with the embarrassment of a third-party detecting port-scans originating from inside your network? What about the impact of bandwidth-hungry applications such as Napster and instant messaging?

A firewall can control these - limiting use to off-peak hours, for example - and reducing network load. A firewall plays a much more important role than just a gatekeeper.

Nor is a firewall's only place at the edge of the network. For example, while the Internet boundary may be secured by a filter or firewall, there are other ways into the network.

Through dial-up on a little-used RAS server, or by physical access at a workstation, or through a WAN gateway to a supply-chain network; there is a myriad of ways. And, of course, the potential of attack from existing "trusted" LAN users.

So, assume the LAN is potentially compromised, and contract the ring of security a little, to surround critical servers. At that second line of defence, another level of security - another firewall - is important.
||**||Users will find a way out|~||~||~|
It's worth remembering that users often show remarkable inventiveness is avoiding network access restrictions, says Gunnar Johansen, consulting systems engineer at Cisco. "Sometimes there is too strict a security policy; this is something we see a lot. Maybe the policy doesn't allow any Internet access, or requires a one-time password to send email, which is in most cases ridiculous.

What do the users do? They buy their own modem, dial into their service provider - it's free of charge [from work] - and they have unrestricted access to the network. Hackers use that the other way around."

A firewall is a simple concept - a service sitting on a flow of traffic, deciding which connections to allow and which to deny. The implementation of that can vary, as can the techniques and the effectiveness.

In its most basic form, a firewall is simply a static filter. According to rules defining source address, target address and port numbers, it allows or denies connections. Not uncommonly, all connections are denied by default, with only specifically listed connections permitted.

That simple filtering can be taken a step further. Because rules can be "chained" so that the outcome of one rule is passed to another, requests for certain services can be redirected, by rewriting any of those four basic fields (source IP, target IP, source port, target port).

By rewriting the target address, all ftp requests can be redirected to a specific server, for example. By altering ("masquerading") the source address, Network Address Translation (NAT) is accomplished. Changing the port allows proxying of services onto non-standard target ports, which can be used to control access through subsequent filters or rules.

Because packet filtering ignores the payload of each packet, it is a very quick process. The downside is that very little intelligence can be built in.

Because the rules are frequently static (i.e.: configured once and then left alone until needing modification), attackers often find a way in without the administrator ever knowing.

Also, it can be complex just to set up the initial rules; services such as DHCP can make matters difficult, and misconfigured firewalls are an attacker's dream come true.

Packet filtering, while a component of a firewall, is not really all that secure. Far too many companies plonk a filter in place and then relax, congratulating themselves on their safety, when in fact there are numerous well-documented techniques to bypass, disable or otherwise dupe a filter into granting malicious packets access to network resources behind it.

For instance, fairly simple address spoofing can fool a filter into believing the packet originated from inside the network rather than from the outside, and therefore allowing it free access to the network.
||**||Getting more sophisticated|~||~||~|
More sophisticated than packet filtering is stateful packet inspection, which examines not only the IP header fields but also the payload, and the state of the connection.

For example, fragmented packets that do not match up, or acknowledgement packets in response to a non-existent request can all be ignored. By examining the entire connection as it flows in both directions is often simpler than a basic filter.

A stateful packet inspection engine requires only one rule to govern the session, whereas a filter needs two sets of rules, one for each of the incoming and outgoing streams. That said, stateful packet inspection rules are in general potentially more complicated than basic filters.

In addition, a stateful firewall can make decisions based on network activity, constructing rules to accommodate new needs. In this way, port scans can be stopped (or better, replied to misleadingly to confuse the attacker), load-balancing can be accomplished among web servers, and so on.

By examining packets for context, application-level decisions can be made, too. Sessions can be rerouted based on the specific content they contain, as well as in the context of traditional filters.
Although more complex, a stateful packet inspection firewall need not add any more overhead to communication than a packet filter would.

More powerful yet is an application proxy, which operates on a store-and-forward basis for all communications. The proxy is completely transparent to both sides, since it is in effect pretending to be the other side of the conversation. Within the proxy, the communication can be taken apart, manipulated and reassembled without anyone being the wiser.

For example, it could intercept an HTTP request, send back a page demanding authentication, and only then permit the session to proceed. This prevents possible misuse of systems by different users sharing a machine, or by a compromised client being used to attack through a firewall.

Integration with a PKI (Public Key Infrastructure) or other user authentication such as biometrics or a central server, is easily accomplished. Another common use is to examine email sessions for viruses or sensitive information.
By offloading these tasks from servers behind the firewall, the chance of newly-discovered vulnerabilities being exploited is minimised.

Unfortunately, this flexibility comes at a price - there is a great deal of performance overhead. Where many network vendors offer filters or stateful firewalls that operate at the wire speed of their routers, application proxies typically are unable to perform that fast. On an Internet connection, where the bandwidth is relatively throttled anyway, that is usually acceptable, but inside a LAN it may be a problem.

One solution, of course, is to put the proxy behind another firewall, which then forwards only certain protocols through the proxy for inspection, and controls the rest itself. Many administrators forget that firewalls can very effectively be chained together for added flexibility and performance.

In a traffic analogy, a packet filter is like a police officer checking a vehicle's registration; a stateful firewall requires the driver to open the trunk for examination; and a proxy demands that the luggage be removed and repacked into a different vehicle.
||**||Management is a complex task|~||~||~|
Although there are a lot of off-the-shelf firewall products, it is important to realise that maintaining a firewall and constructing rule-sets is not a simple task. By far the most common cause of vulnerabilities is a misconfigured firewall.

Above all else, it is vital to realise that a firewall, in whatever form, is not a security solution. It is an important component, and a fundamental starting point, but by itself a firewall cannot keep your network safe, and may lull you into a dangerous sense of security.
New vulnerabilities are discovered all the time, so it is important to keep the rules on the firewall up to date, and the firewall platform patched to the most current version. Behind the firewall, an intrusion detection system is also important; the firewall can only catch intruders as they pass the boundary. Once inside, or if they start off inside and target neighbouring systems, they have the run of their subnet.

Putting a firewall in place is not as simple as many administrators believe. Far more than just putting another service on the gateway server or router, it may imply a certain amount of network redesign and policy drafting. “If you have a big network with no security, and you want to implement a sensible security policy, most times you will have to rearchitect some parts of the network. You want to have certain control points - not single points of failure, because you can have redundant solutions - but you want to have certain layers, like an onion, and be able to say 'what are the rules and criteria to move from one layer to another?',” says Johansen.

A common concern is that introducing a firewall will impact the network performance, but vendors hasten to point out that they are able to deal with most situations. Gunnarsson points out that Cisco's high-end stateful firewall solution can handle a full gigabit of bandwidth, and half a million simultaneous connections. "We don't need that performance, especially here in the Middle East, but we need to be able to tell businessmen that security won't impact their e-business services."||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code