We've seen that SNMPv3 provides authentication, encryption and access control in order to secure network management functions. While this is important (certainly, the network administrator does not want others to gain access to network management functionality), it is only a small part of the network administrator's security concerns. In addition to monitoring and controlling the components of one's network, a network administrator also wants to exclude unwanted traffic (i.e., intruders) from the managed network. This is where firewalls come in. A firewall is a combination of hardware and software that isolates an organization's internal network from the Internet at large, allowing specific connections to pass and blocking others. Organizations employ firewalls for one or more of the following reasons:
A filtering policy can also be based on the combination of addresses and port numbers. For example, the router can forward all Telnet packets (port 23) except those going to and coming from a list of specific IP addresses. This policy permits Telnet connections to and from hosts on the list. It is highly recommended to reject all datagrams that have internal source IP addresses -- i.e., packets that claim to be coming from internal hosts but are actually coming in from the outside. These packets are part of address spoofing attacks, whereby the attacker is pretending to be coming from an internal machine. Unfortunately, basing the policy on external addresses provides no protection from an external host claiming to be a different external host.
Filtering can also be based on whether or not the TCP ACK bit is set. This trick is quite useful if an organization wants to let its internal clients connect to external servers, but wants to prevent external clients from connecting to internal servers. Recall from Section 3.4 that the first segment in every TCP connection has the ACK bit set to 0 whereas all the other segments in the connection have the ACK bit set to 1. Thus, if an organization wants to prevent external clients from initiating connections to internal servers, it simply filters all incoming segments with the ACK bit set to 0. This policy kills all TCP connections originating from the outside, but permits connections originating internally.
Now suppose an organization doesn't want to block all connections originating
from outside; instead it just wants to block only the Telnet connections
originating from outside. How can filtering accomplish this task? To see
how filters handle this, let's look at how the fields are set for Telnet
connections originating internally and Telnet connections originating externally
(Table 8.5.1):
Origination |
|
Address |
IP Address |
Port |
Port |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The p and q in the above table are the port numbers (> 1023) assigned to the client machines (see Section 3.1). From this chart we see that the filter can block Telnet connections originating from outside by blocking inbound packets (external source address and internal destination address) with destination port 23; or by blocking outbound packets (internal source address and external destination address) with source port 23.
In order to have a finer level security, firewalls must combine packet filters with application gateways. Application gateways look beyond the IP/TCP/UDP headers and actually make policy decisions based on application data. An application gateway is an application-specific server through which all application data (inbound and outbound) must pass. Multiple application gateways can run on the same host, but each gateway is a separate server with its own processes.
To get some insight into application gateways, let us design a firewall that allows only a restricted set of internal users to Telnet outside and prevents all external clients from Telneting inside. Such a policy can be accomplished by implementing a combination of a packet filter (in a router) and a Telnet application gateway, as shown in Figure 8.5-1. The filter is configured to block all Telnet connections except those that originate form the IP address of the application gateway. Such a filter configuration forces all outbound Telnet connections to pass through the application gateway. When a internal user wants to Telnet to the the outside world, it first sets up a Telnet session with the gateway. The gateway prompts the user for its user id and password; when the user supplies this information, the gateway checks to see if the user has permission to Telnet to the outside world. If not, the gateway terminates the Telnet session. If the user has permission, then the gateway (1) prompts the user for the hostname of the external host to which the user wants to connect, (2) sets up a Telnet session between the gateway and the external host, (3) relays to the external host all data arriving from the user, and relays to the user all data arriving from the external host. Thus the Telnet application gateway not only performs user authorization but also acts as a Telnet server and a Telnet client. Note that the filter will permit step (2) because the application gateway initiates the Telnet connection.
Internal networks often have multiple application gateways, for example, gateways for Telnet, HTTP, FTP and e-mail. In fact, an organization's mail server (see Section 2.4) and Web cache (see Section 2.9) are application gateways.
Application gateways do not come without their disadvantages. First, you need a different application gateway for each application, which requires installing and configuring a new server for each application. Second, either:
References
Two excellent references are [Chapman 1995][Cheswick 1994]. Readers are also encouraged to read white papers in the Web sites for major manufacturers of firewalls (e.g., [Checkpoint 1999]).
[Cert 1999] CERT, "CERT Summaries,"
http://www.cert.org/summaries/
[Chapman 1995] D.E. Chapman and E.D.
Zwicky, "Building Internet Firewalls," O'Reilly and Associates, Sebastopol,
CA, 1995
[Cheswick 1994] W.R. Cheswick and S.
M. Bellovin, "Firewalls and Internet Security," Addison-Wesley, Reading,
MA, 1994.
[Checkpoint 1999] Checkpoint Software
Technologies Ltd. homepage, http://www.checkpoint.com
[Newman 1998] D. Newman, H. Holzbar,
M. Carter, "Firewalls:
Tough Enough", Data Communications Magazine, April, 1998.
Copyright 1999-2000 . Keith W. Ross and Jim Kurose. All rights
reserved.