Firewalls: The Tool to Prevent Network Exposure
Gilbert Held
Hardly a day goes by without a report of another network break-in at yet another major corporate or government site. If you're a network manager, LAN administrator, or the corporate Webmaster, two questions you likely ask yourself repeatedly are, "Has a hacker gained control of one or more of my internal corporate computers?" and "Can any corporate network be safe?" The answers to both questions are related, as I will shortly note. Although the only hacker-proof computer is probably the one located in a vault and not connected to a network, even a secure facility is not beyond attack. So what can you do? There are two key network devices that should be considered when connecting an internal corporate network to a public network, such as the Internet. One device is a packet filtering router, while the second device, which also performs packet filtering, performs many additional security-related functions and is the primary focus of this article. That device is the firewall, which obtains its name from the barrier used in automobiles, homes, and offices to protect persons from adverse outside elements, typically fires. Although no network can be expected to be totally secure, the use of a firewall can help us sleep better at night by eliminating a large degree of risk to internal private network facilities. An understanding of the functionality and capability of a firewall is best obtained by examining the operation and utilization of packet filtering routers, so I will discuss those. After all, the router, or gateway, provides the basic mechanism for interconnecting networks. By examining basic router packet filtering, I hope to show how this device performs its security-related functions and why total reliance upon packet filtering can result in potential network intrusions. Router Review The primary function of a router is to exchange packets between networks. To accomplish this task, a router must understand one or more network layer protocols, such as IP and IPX, maintain tables that equate known addresses with its interfaces, and perform other routing functions beyond the scope of this article. As the use of routers expanded to interconnect network segments, the connection of private networks to public networks made the private network susceptible to attack from anyone with access to the public network, resulting in a virtually unlimited threat audience. Recognizing the potential adverse effect to corporate data, as well as the good name of a corporation whose data integrity is penetrated, router manufacturers added a packet filtering capability to their products. To illustrate the operation of a packet filtering router, assume an organization has an Ethernet LAN with computers providing telnet, SMTP mail, and a Web server connected to the network. Also assume that we want to connect this Ethernet LAN to the Internet while restricting access to servers from another network operated by this organization, which is also connected to the Internet. For illustrative purpose only, I will designate this organization's telnet, SMTP mail, and Web servers' IP addresses as 123.45.67.8, 123.45.67.9, and 123.45.67.10, respectively. We want to restrict access to the SMTP server from clients on network 192.78.46.*, where * represents all addresses between 0 and 255. Figure 1a illustrates the use of a packet filtering router to control access between the public Internet and the corporate Ethernet network. Both router and firewall packet filtering normally has a default of everything denied unless specifically permitted. Permitting packets to flow through the router requires the creation of one or more access list entries. Each incoming packet is compared against entries in the access list on a sequential basis. Care must be taken in creating an access list as a general permission that prefixes a specific denial of service that would be matched first and allow an unintended operation to occur. The actual construction of an access list and the line item entries varies from router to router. As a minimum, most access lists allow you to specify the packet type, source and destination IP address, source and destination port numbers, and the allowed action. The packet type actually references the protocol, such as TCP, UDP, and ICMP. Most modern router manufacturers support the use of the asterisk (*) in both a dotted decimal position in an IP address and in a port address as a wildcard, allowing all occurrences for the field or field position used. Thus, to permit all inbound TCP packets from any location on network 192.78.46.0 to the SMTP mail server whose IP address is 123.45.67.9, your access list entries might be coded as follows:
IP ADDRESS PORT ADDRESS PACKET SOURCE DESTINATION SOURCE DESTINATION ACTION TCP 192.78.46.* 123.45.67.9 * 25 PERMIT TCP 123.45.67.9 192.78.46.* 25 * PERMIT
Two entries are required in the access list because we presume we want to generate outbound mail as well as receive incoming mail. Even if we didn't, each TCP conversation consists of packets flowing one way followed by acknowledgments that flow in the opposite direction. Thus, an access list must be coded to support a bi-directional data flow capability. To obtain this capability, we must explicitly define what is permitted if the router has a default packet filtering state that specifies all is denied unless permitted. The first entry in the access list permits TCP packets from any computer on the network 192.78.46.* directed to port 25 on the destination mail server whose address is 123.45.67.9, regardless of the port used, to originate the packet. The second entry in the access list permits packets originated by the mail server on port 25 whose IP address is 123.45.67.9 to flow to any destination address on the network 192.78.46.*, regardless of destination port. Although the preceding entries allow bi-directional mail delivery, a better filtering method is to restrict outgoing mail packets to port 25. This would restrict your internal mail server to transmitting mail packets to the well-known SMTP mail port instead of allowing a response to a port of the originator's choosing. Well-known ports represent port numbers less than 1024, which have been standardized for use. Table 1 provides examples of 20 well-known TCP and UDP ports. By enabling or disabling access to those ports, you can control access to the services supported via the use of those ports. Depending upon your organization's computer operations, it is a good idea to examine the services you support and whether or not you should enable outside users to obtain access to such services. Some services may not appear to be dangerous but are. For example, the finger protocol can be used to obtain information about individual computer users or users currently logged onto a system and provides a good starting point for a hacker attack. This is because finger will return the user-ID and name associated with the ID of presently logged-in users and other information that can be used for password guessing or a dictionary attack. Beyond Packet Filtering The key problem associated with packet filtering is that it is limited to examining the contents of predefined fields in the header of a protocol to determine if a source can communicate with a destination. This means the examination process does not focus any attention upon the contents of the packets and provides a potential security hole that unscrupulous persons may attempt to exploit. For example, if you operate an ftp server and permit uploads, an examination of addresses cannot prevent a virus from being uploaded onto your server. Similarly, if a person gains access to a computer on the network from which access is permitted, they then obtain the ability to run a dictionary attack against one or more services behind the firewall (e.g., a mainframe or minicomputer that supports TN3270 or telnet access). Firewall vendors, upon recognizing these limitations, incorporated a variety of features beyond packet filtering into their products. Some of those features include proxy services, address translation, stateful inspection, authentication, and virus checking. The inclusion of one or more of these features requires the firewall to extend its packet examination process to the application layer of the ISO Reference Model and provides a significant additional layer of protection beyond packet filtering. I will provide a few examples of these concepts by discussing the information shown on some configuration screens generated by a firewall. For illustrative purposes, I will use screens generated by the Technologic, Inc. Interceptor firewall, marketed by Technologic of Atlanta, Georgia. Proxy Services A proxy service represents a process whereby the direct connection of a request through a firewall is intercepted by a host. Based upon a predefined set of rules, the packet is either allowed through the firewall or placed in the great bit bucket in the sky, with the requestor usually receiving a "denial" message generated by the firewall. Thus, a proxy service can be viewed as a function that examines packets for the occurrence of predefined operations. Depending upon how a firewall operates, either those operations that are not explicitly permitted are denied, or those operations that are not explicitly denied are permitted. Figure 2 illustrates the Advanced Policy Options configuration screen for the Technologic Interceptor firewall. Here, the term policy is used by the vendor as equivalent to a rule, and the policy displayed is shown with the ftp get command being disabled. Once this policy is saved, each time a new connection arrives at the firewall, all previously established policies are searched in sequence for a policy that applies to the pending connection. If the connection request matches the parameters for a policy, the request is permitted unless the policy bars specific actions. In addition to filtering by commands, the Interceptor firewall is similar to other communications products in that you can apply the policy to an IP address and even the time of day. Address Translation One method commonly employed to protect an internal network from unauthorized access is address translation. Address translation hides your internal IP addresses from outside users by a hiding or mapping process. IP hiding allows only clients behind the firewall to initiate sessions, which may not be desirable. In comparison, one-to-one mapping permits access from in front of the firewall to occur. When using mapping, a proxy server will use a set of Internet Assigned Number Authority (IANA) addresses on the Internet side and your user-defined addressing scheme on the internal network, mapping addresses based upon the direction of the packet flow. Although you might be tempted to use any networking numbers for your internal network, it is not advisable to do so. The assignment of a network number that is in use on the Internet will preclude communications between your internal hosts and those outside hosts. This is because the routing table in the proxy service will direct all packets destined for addresses in use on your network back to your internal network. To alleviate this problem, you should select IP addresses reserved for internal private networks. You can obtain the appropriate IP addresses to hide your internal network addresses from the public through subnetting or through the use of addresses allocated for private internets. Concerning the latter, RFC 1918 specifies three blocks of IP address space that can be used for private internets. Those address blocks are:
10.0.0.0 to 10.255.255.255 172.16.0.0 to 172.31.255.255 192.168.0.0 to 192.168.255.255
Stateful Inspection The term stateful inspection was coined by Checkpoint Systems to reference the examination of packets at higher layers in the ISO Reference Model and analyze their content based upon the content of prior packets. Thus, stateful inspection can be considered similar to tracking a series of telephone calls. One wrong number is probably an error; a series of wrong numbers from the same telephone number and heavy panting on the line probably indicates a disturbed person. Stateful inspection capability should monitor against activities including an excessive number of service attempts, refused connection attempts, and similar activity. Once a predefined condition (e.g., 10 failed connection attempts in a five-minute period) is reached, the firewall should either turn off the service under probable attack or issue an alert to an appropriate employee. Refer to the Add Alert configuration display shown in Figure 3. In examining Figure 3, note that the selection box labeled "Pattern" has its entries pulled down. The Pattern field provides you with an event to search for. Occurrence of that event can be used as a trigger to generate an alert. The actual trigger action can be based upon a frequency and time. For example, the Interception Alert Configuration screen provides you with the ability to specify a frequency that the event must reach before triggering the alert. Note that alerts can be transmitted via electronic mail or via a pager alias entry that defines a script. The script execution in turn initiates a call to a predefined pager telephone number. Authentication Another key feature performed by many firewalls is authentication. There are three basic methods by which computer access authentication is accomplished. Those methods involve the use of static passwords, token generated passwords, and one-time passwords. In actuality, both token generated and one-time passwords can be considered one and the same. Static passwords are very vulnerable to compromise by illegal sniffing. A questionable site on the Internet could enter a very low routing cost to attract traffic like honey attracts flies. Put a sniffer on a router port, and you can watch ftp passwords fly by. Perhaps this is why Windows NT and other operating systems warn about ftp vulnerability when you attempt to set up ftp server service. In any event, static passwords, especially those that are transported in the clear (e.g., ftp passwords) should be avoided. Even when passwords are encrypted, they can provide a false sense of security. This is because a hacker can use the contents of a dictionary to determine a static password after learning a user's ID from the use of the finger protocol or another method. Recognizing this problem, many firewall developers incorporated support for credit card token generators and one-time software generated passwords. A credit card token generator uses a seed burnt into the card to generate a password, typically in the form of 6 or 8 randomly generated alphanumeric digits. The firewall either executes an authentication server process or passes authentication requests to an authentication server. For either method, the process or server prompts users for their PIN and the number presently displayed on the credit card-sized token generator. The client response enables the use of an algorithm to create a randomly generated password by the firewall or separate server, which is then compared to the client's password. Assuming these match, the client session is enabled. Because the token generator's random number changes every minute or so, it can be considered as a one-time password. One-time passwords are commonly generated by software. One popular example is the Bellcore S/KEY system. That system consists of two software programs - one that operates on a server and one that operates on the client. After the client sends a login request, the server issues a challenge in the form of a seed consisting of a number and a string of characters. The user attempting to gain access responds to the challenge number and seed plus a secret user-authentication phrase. This results in the client generating a one-time password that is transmitted to the server for authentication. Similar to token-based authentication, one-time password systems based upon software may be directly supported by a firewall or passed through the firewall to an authentication server. Because firewalls have been the subject of several books and countless articles and white papers produced by many vendors, perhaps the best way to become familiar with their functionality and capability is to both read the literature as well as perform a threat analysis of your private network. In doing so, it may be a good idea to list those services you intend to permit as well as possible threats resulting from allowing such services. For example, if allowing ftp inbound, the threat of a virus is a real concern. By making a list of threats and matching vendor product features against your requirements, you may obtain an appreciation for product capabilities as well as for your own needs. Although no site should ever be considered safe, if carefully evaluated, installed, and configured, a firewall may allow you to sleep better at night.
About the AuthorGilbert Held is an author and lecturer whose recent books include Ethernet Networks 2ed., The Complete Modem Reference 3ed., Data and Image Compression 4ed., and Protecting LAN Resources, all published by John Wiley & Sons. Gil can be reached on the Internet at: 235-8068@mcimail.com.
|