Firewalls

team lib

When your network is connected to a public network, it is exposed to spies, thieves , hackers, thrill seekers, and various other threats. As the public Internet has come to play a critical role in most everyone's networking strategy, protection from undesirable Internet inhabitants is a necessity. One of the key elements of safe networking is a properly designed and configured firewall system.

There are three basic designs for firewall operation. The first, and simplest, is the packet filter. Most routers can be configured to filter packets based on straightforward comparison of packet contents with filter specifications. For instance, particular IP addresses or subnets, particular TCP or UDP port numbers , or combinations of these properties can always be denied passage.

In most modern routers, adding a security-based filter step to the packet forwarding process will add little or no overhead, so packet-filtering firewalls can have very high performance. Unfortunately, would-be intruders have a number of options for defeating simple filtering. For instance, they can spoof packets to appear as if they come from an acceptable source.

The second basic firewall design enhances packet filtering so that it can't be circumvented by these measures. This process, developed and patented by Check Point Software Technologies (www.checkpoint.com), is known as stateful inspection. Stateful inspection extends the packet-by-packet filtering process to include multipacket flows. A connection table tracks individual flows, enabling policy checks that extend across series of packets. For example, TCP ACK packets not preceded by a TCP SYN packet with a correct sequence number can be blocked.

With the correct configuration, a stateful inspection firewall can offset many of the shortcomings of plain packet filtering without serious performance penalties. Like vanilla packet filtering, stateful packet inspection works for all applications because its basic functioning is at the Network and Transport layers . No special client configuration or new client software is required.

The third firewall design is the application proxy. With a pure application proxy, no traffic at all goes through the firewall. Instead, the application proxy behaves like a server to clients on the trusted network and like a client to servers outside the trusted network.

Thus, a Web browser attempting to connect to eBay will speak HTTP and pass the eBay destination URL-and the other information that browsers provide Web servers-to the application proxy firewall. The firewall will then apply its policy rules to the request. If the request is permitted, it will send the request off to eBay. The source IP address on the HTTP packets to eBay will be that of the firewall, not that of the original client.

By operating at the Application layer, application proxy firewalls permit as much granularity as anyone could desire when it comes to rules. For example, lists of specific URLs can be blocked from certain subnets, or FTP clients can be restricted from Puts, but permitted to execute Gets. Added advantages of Application-layer operation include the ability to require strong authentication before connecting and the ability to create detailed logs of security events.

Because the action is at the Application layer, proxies must be provided for each application. A number of traditional Internet applications-including FTP, e-mail, and news-are bundled into common browsers, so they can all be handled by configuring the browser to talk to the firewall. However, custom applications and network applications not bundled into a browser will have to be configured at the firewall individually, assuming they can be adapted to proxy execution at all.

While application proxy firewalls can provide the highest level of security and the finest-grain control, they can also be the most complex to configure. Also, because they act as relay agents for all the clients on the network, their performance can be problematic .

A variant of the application proxy model is the circuit-level gateway. On this model, the firewall relays TCP (and in the most recent implementations, UDP) connections between the trusted and untrusted networks after authenticating the end points. Circuit-level gateways don't access Application-layer information as application proxy firewalls do, so it's not necessary to supply separate proxy processes for each application. The best-known implementations of circuit-level gateways employ an IETF standard protocol called SOCKS. Version 5 of SOCKS includes authentication and UDP flows.

SOCKS 5 (and circuit-level gateways in general) require modifications to either applications or to client TCP/IP stacks. Most common browsers on the most widespread platforms have built-in SOCKS support, and modified protocol stacks are also available for various flavors of Unix, various flavors of Windows, and Macintosh. Nevertheless, a significant administrative effort is needed to implement a circuit-level gateway for a sizable enterprise.

Application proxy firewalls and circuit-level gateways transparently perform Network Address Translation (NAT). The network interface that connects to the untrusted network is all that the untrusted network sees, so the addresses and the structure of the trusted network are shielded from view. In themselves , packet filters and stateful inspection firewalls don't translate IP addresses and port numbers, though there's no reason that NAT can't be implemented separately.

Some makers of NAT devices (mostly those aimed at home networks) describe them as firewalls, but that claim is misleading. NAT does shield internal addresses and their structures from outside view, but it doesn't provide control over outbound traffic, perform authentication, or prevent spoofed inbound packets.

Hybrid Devices

In practice, commercial firewalls often make use of multiple protective techniques. Check Point's Firewall-1 has NAT options. Network Associates' Gauntlet, an application proxy firewall, incorporates so-called adaptive proxy technology that essentially hands off packet flows to a stateful inspection engine if the first few packets are passed by the application proxy.

Furthermore, the position of the firewall at the boundary between the trusted network and the untrusted network makes it tempting to build in other services. For example, it may make the most sense to terminate a VPN at the firewall, rather than decrypting the contents of each packet for a security check and then re-encrypting everything that passes the check.

A security check that involves identifying particular traffic flows will have done much of the work required for bandwidth management. It's a small step from providing application proxy services to providing a local cache for common requests , as Novell has done with its BorderManager product.

Firewalls are fundamentally software processes, though they aren't all marketed as software. A firewall can't be any more secure than the operating system underlying it. Most firewalls are deployed on Unix or Windows NT/2000, though there are vulnerabilities with all the variants of these OSs.

Some firewall producers customize an OS-usually Unix-and install their firewall software on that OS in a sealed box. These systems are marketed as firewall appliances, and some would argue that hiding the particulars of the OS contributes an additional layer of security. More importantly, the " hardened " kernels of these customized OSs are stripped down and adapted for firewall functionality instead of general-purpose application execution.

When the trade press began writing about firewalls in the mid-'90s, it was common for tests to be designed around performance, as though these devices were routers or drag racers. Unfortunately, the throughput of a firewall is completely orthogonal to the security it provides. In fact, overly fast performance may once have been an indicator that security was lacking.

Testing for security is inherently difficult-it's impossible to prove that every vulnerability has been eliminated. Security scanner tools that have gathered together all known exploits can be run against firewalls, but that isn't the same as proving invulnerability.

Beyond Technology

While understanding firewall architectures and technical vulnerabilities is essential to protecting the enterprise network, developing an appropriate security policy is perhaps even more important. Establishing policy requires understanding the value of data, of undisrupted business processes, of various forms of legal and fiduciary liability, and other nontechnical organizational matters.

IT and security people can help ask the right questions, but they aren't the last word on such issues. Once enterprise management determines the fundamental policy guidelines, technical people can implement practices and procedures to carry out those guidelines.

An additional technical matter arises at this point. In some ways, a misconfigured firewall can be more dangerous than none at all. Traditional firewalls were configured with scripts and command-line interfaces. It takes a lot of training and aptitude to mentally convert a list of "deny" and "permit" statements with IP addresses and port numbers into a clear image of the network's protection. Purists may disagree , but I'm convinced that modern GUI-based software, with wizards and graphical representations of procedures, enhances the security of a firewall implementation, in addition to easing the pain.

A related issue is firewall management. Large enterprises will have numerous firewalls to deploy, and will likely want to implement similar policies in many locations. Some enterprises use internal firewalls to protect against potential internal threats, and the configuration of these will perhaps differ substantially from that of the firewalls that protect against threats coming in from the public network. Consistency and flexibility of configuration management will be important for these internal firewalls too.

Firewall logs are critical for anticipating threats, for postmortems after attacks, and for understanding future requirements. Application proxy firewalls, which have the most detailed information about traffic, can provide the most detailed logs. Logs often serve to trigger alarms-you can be paged in the middle of the night when that dreaded Distributed Denial of Service (DDoS) attack finally hits your e-commerce site. Logs provide valuable evidence after successful or unsuccessful firewall activities, and they can certainly play an important role in tracing intruders, in convicting them once they're caught, and in proving that your site took pains to prevent intrusions.

Firewalls can't be expected to do the impossible. If there are back doors into your network, such as desktop or laptop machines with dial-up Internet accounts, or home cable-modem users with access to your network, the firewall can't defend those pathways . Successful firewall operations are dependent on the device being a single point of contact between the untrusted network and the trusted network.

Furthermore, firewalls installed to protect the internal network from outside intruders are no help against insiders. Firewalls don't replace access controls on servers, file systems, databases, or applications. Nor can they protect the network from viruses, unless that capacity is specifically added on.

With well-thought-out configuration and management systems, however, modern firewalls can keep even dedicated attackers from wreaking havoc on your network.

Resources

Network Associates' Gauntlet Firewall Is Part Of The Company's Pretty Good Privacy (PGP) Division. There Are White Papers On Adaptive Proxies And Other Topics At www.nai.com/asp_set/buy_try/try/whitepapers.asp#PGP SECURITIES/.

Check Point Software Technologies' account of stateful packet inspection, along with numerous other technical documents, is available at www.checkpoint.com/products/downloads/fw1-4.0tech.pdf/. Registration is required if you haven't previously registered.

Information Security Policies Made Easy , by Charles Cresson Wood (Baseline Software, Sausalito, CA, 1997, ISBN 1881585042), is a comprehensive starting point for defining organizational security policies.

This tutorial, number 143, by Steve Steinke, was originally published in the June 2000 issue of Network Magazine.

 
team lib


Network Tutorial
Lan Tutorial With Glossary of Terms: A Complete Introduction to Local Area Networks (Lan Networking Library)
ISBN: 0879303794
EAN: 2147483647
Year: 2003
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net