Policy configuration

As mentioned in Chapter 7, a firewall policy is a physical manifesta- tion of a business need. Particular types of network or application protocols may be deemed counterproductive to business objectives. As such, the firewall is the place where business objectives become practical reality.

8.2.1

Interface

A firewall has two avenues of approach: LAN and WAN. Traffic requests may originate from either side, and as such, policies must be developed that correspond to each side. For example, HTTP traffic may be permitted from the WAN side, but not from the LAN. Denying LAN HTTP traffic would, effectively, prevent an employee from setting up a web server and running a competing business from his desktop. This happens mostly in large offices where supervision is loose and firewall access controls are never configured. A common question that arises with respect to “closing ports” has to do with the way in which a server and a client negotiate a connection. Most people, initially, think that port 80 on the server talks to port 80 on the client. This is not the case. Below are three sample packet head- ers from a secondary HTTP packet:

1.

TCP - Transmission Control Protocol Source Port: 80 (http)

Destination Port: 4889 Sequence Number: 0x00d85110 Ack Number: 0x80c3aef7 Offset: 5 (20 bytes)

2.

TCP - Transmission Control Protocol Source Port: 80 (http)

Destination Port: 4882 Sequence Number: 0xf334bc6b

Ack Number: 0x80b372d6 Offset: 5 (20 bytes)

3.

TCP - Transmission Control Protocol Source Port: 80 (http)

Destination Port: 4890 Sequence Number: 0x00d92fee Ack Number: 0x80c434a6 Offset: 5 (20 bytes)

Clearly, the port on the client (Destination) computer is port 3762. This is a random number between ports 1024 and 65535 selected by the requesting agent. Closing port 80 on the LAN side to all HTTP traffic will, therefore, not block internal users from establishing port 80 connections to external servers. RFC 2616, the standard for HTTP 1.1, is interesting reading and contains more information about the behavior of the protocol. RFC 793, for example, details TCP/IP. Many of the Request for Comments (RFC) document series contain useful information. They are the ultimate authority on the manner of behavior for many aspects of the Internet Protocol.

8.2.2

Source

Additional control over the source IP address may be required. Simply put, this allows highly localized control over “trouble spots.” Oftentimes, this can be applied to a particular problem spot where a computer may be engaging in some inexplicable, yet harmless, pro- tocol transmissions. A policy that targets a particular IP address can be useful in balancing load usage or simply preventing undesirable activity. Don’t micromanage your firewall, though! Care should always be taken to address as many issues at the macroscopic level as possible.

8.2.3

Destination

In the context of a policy configuration, a destination will be either the LAN or the WAN. For example, the source for Point-to-Point

8.2 Policy configuration 151

Tunneling Protocol (PPTP) may be set to Anyand the destination set to the WAN IP address of the machine. Simultaneously, on the LAN side, a policy may be configured for the purpose of preventing inter- nal machines from acting as mail servers—a common tactic of viruses. Such a policy would have a LAN destination, with a source ofAny.Actual restriction of the port and protocol would be config- ured under Services.

8.2.4

Services

There are many services, such as FTP, HTTP, PPTP, etc., that are preconfigured for convenience on firewalls. These services are well known, and may or may not be cause for concern. Much depends on established business policies. However, there may be a case where, through the use of a sniffer, an unusual level of activity is noticed to be traversing between particular ports. An administrator of a highly secure network may want to immediately disable this traffic. If the service is already defined, then the configuration of a custom policy will imme- diately put an end to the trouble. If it is not, then there are several pieces of information that must be obtained from the packet header:

■ Protocol ■ Source port ■ Destination port

Most firewalls present protection from the perspective of defend- ing against the external world. Yet, a custom policy may be applied to either an external or an internal traffic pattern. What this means is that the configuration of a custom policy is done from either the frame of reference of an inbound packet or an outbound packet.If the packet being examined is an inbound packet, the source and des- tination will be one way, and if it is an outboundpacket, then the source and destination reverse themselves.

Some firewalls may not explicitly define the context of inboundor

outbound and primary or secondary. Figure 8.1 demonstrates that typically the world of connections is viewed from the point of view of the firewall. However, this may not always be the case, as some man- ufacturers, in a misguided effort to oversimplify administration, have

been known to regard all traffic that is heading toward the LAN as

inbound. In these cases, trying to decipher which way is which from the firewall perspective is a matter for simple experimentation. If the illicit packets are still flowing after the rule has been created, delete the policy and recreate it with the numbers transposed. It’s usually a good idea to restart a firewall after a policy has been deleted. Oftentimes these configurations are made to text-based configuration files that are only examined on startup.