[Top] [Prev] [Next] [Bottom]

Creating a Network Security Firewall


This document shows how to create a network security firewall to meet specific network protection goals. It contains actual examples for configuring a series of IP filters that together allow only specific user activity, while blocking all other activity.

This chapter contains the following section:

Firewall Scenario

Goals of the Firewall

Creating the Firewall Profile

Allowing Access to the Web Server

Allowing Internal Client Access to External Services

Preventing Spoofing of Source Addresses

Summary

Note: This chapter does not cover all connectivity issues. See Profile and Filter Examples for examples of additional filters that you may need.

Firewall Scenario

Figure 1 shows a typical example of a corporate network connected to the Internet using GTSecure.

Figure 1 Typical Data Flow Between a Corporate Network and the Internet

The following information is important about this configuration:

Goals of the Firewall

Using Figure 1, this chapter shows how to create a profile that meets the following six goals:

1. Allow any computer to establish data flows with the corporate Web server (HTTP) running on Server-C.

2. Allow personal computers inside the corporate network to run HTTP, FTP, Telnet, DNS, and other client programs with servers outside the corporate network.

3. Prevent external access to other applications on Server-C.

4. Prevent external access to any application on internal personal computers.

5. Prevent internal users from offering illegal servers to the Internet.

6. Prevent internal data flows from being disrupted by attack.

Creating the Firewall Profile

1. Create a profile to hold the set of filters that implement the firewall.

IP Filters Config>add profile firewall

2. Associate this profile with the WAN interface, which is interface 1.

IP Filters Config>set interface 1 profile=firewall

Note: A new profile has no filters. In the absence of any filters, the profile blocks all traffic.

Current Status

Figure 2 No Filters Defined, No Communication

Allowing Access to the Web Server

1. Create a filter that does both of the following:

2. Assuming the IP address of Server-C is 162.2.2.1, enter the following:

IP Filters Config>add filter firewall.webaccess direction=both destination=162.2.2.1 dport=http

Note the following information about this filter:

Current Status

The following filter now exists:

IP Filters Config>list filter firewall.webaccess
Listing Filters

Name Dir Address Port Protocol Idle
Action
---------------------------------------------------------------------------
webaccess both ida=162.2.2.1 idp=HTTP(80) TCP Pass Off

Note: Because the direction of the webaccess filter is both, the destination address and destination port have an "i" next to them, which means that the information shown applies to inbound packets.

As Figure 3 shows, outside users can send HTTP packets to Server-C, but they cannot send FTP packets or other packets to Server-C.

Figure 3 Filter Defined, Outside Users Can Send HTTP Packets To and Receive HTTP Packets From the Web Server

It takes only one filter to meet four of the six Goals of the Firewall. That is because three of these goals are to block packets. Blocking packets is easier than allowing some packets through without unintentionally allowing attack.

Allowing Internal Client Access to External Services

Most IP applications work as follows:

1. The client allocates a TCP socket with a system assigned port number. Such ports are called transient ports and fall into a specific range of numbers.

2. The client sends a Syn packet from its assigned port number to the server's well-known port number (usually but not always a low number).

3. The server responds with a Syn+Ack packet. The response has the same port numbers but in reverse order.

4. The client sends an Ack packet. The connection is now established.

5. The client and server may exchange data packets and acknowledgments for some amount of time. The port numbers do not change.

6. Either side may gracefully close the connection by sending a Fin packet. The other side sends Fin+Ack. A final Ack is sent and the connection is closed.

This is a standard single-connection interaction. HTTP (Web), Telnet, SMTP (e-mail), and many other applications interact in this way.

Notable exceptions include

See Handling FTP and Handling TFTP.

Scoping the Command Line

The scope command reduces the amount of data entry. Since the next steps involve the firewall profile, enter the scope command to reduce data entry.

IP Filters Config>scope firewall
IP Filters Config firewall>

Notice that the prompt changed to include firewall. All commands you enter at the IP Filters Config firewall> prompt apply to the firewall profile.

Allowing Internal Access to External Servers

Client programs generally use transient port numbers. Therefore, a simple scheme to allow internal access to external servers is to create an opening in both directions for transient port numbers inside the firewall. Add the following filter:

IP Filters Config firewall>add filter client dir=both protocol=tcp dport=transient

This filter also works for FTP, which has an incoming connection back from external servers, because that connection is to a transient port on the internal client.

However, this simple scheme neither prevents internal users from offering illegal servers to the outside world by configuring them on transient ports, nor does it protect internal clients from a form of attack called port fishing. In this attack, an external hacker tries to send data to all transient port numbers hoping to disrupt established data flows.

Improving Security on Internal Client Connections

This section shows how to modify the profile to prevent the port fishing and illegal server problems.

1. Delete the previous filter.

IP Filters Config firewall>delete filter client

2. Add a filter allowing outbound data from transient ports.

IP Filters Config firewall>add filter icout dir=out protocol=tcp sport=transient

3. Add a child filter that opens a hole in the inbound direction for the specific pair of addresses and ports found in the outbound packet.

IP Filters Config firewall>add filter icout.response dir=in destination=source source=destination sport=dport dport=sport idle=300

Figure 4 shows how the parent and child filters that you just created work.

Figure 4 How the Parent and Child Filters Work

Handling FTP

The filter icout does not work for FTP client applications unless they operate in PASV mode, which uses only one TCP connection. If the application does not run in PASV mode, when an internal client connects to an external FTP server, the initial channel is for commands only. Actual file transfers take place over additional connections that the FTP server establishes. That is, the internal client receives an incoming connection from an FTP port to a transient port.

The following steps show how to create a parent filter and a series of child filters to handle FTP applications that do not operate in PASV mode.

1. Create a filter to detect traffic from an internal transient port to an external FTP server and place the filter in front of the existing filter icout.

IP Filters Config firewall>add filter ftpclient dir=out dport=ftp_control sport=transient before=icout

2. Add a child that is identical to the icout.response filter you added above. This filter opens a hole for the specific pair of addresses and ports found in the outbound packet.

IP Filters Config firewall>add filter ftpclient.response dir=in dest=source source=dest sport=dport dport=sport idle=300

3. Define a second child that watches for an incoming connection to a transient port from the same external FTP server. This is a temporary filter with a wide hole. It has an idle time limit of 30 seconds.

IP Filters Config firewall>add filter ftpclient.inwide dir=in dest=source source=dest dport=transient sport=ftp_data ptype=syn delete=on idle=30

4. Add a child filter to ftpclient.inwide.

As soon as GTSecure recognizes a packet from the FTP server to the client, it uses the specific destination port to install this child filter, inwide.narrower. The filter ftpclient.inwide uninstalls itself.

The idle time on the final filter is five minutes, which should be enough to allow a file transfer to pause and recover.

IP Filters Config firewall>add filter ftpclient.inwide.narrower dir=both dest=dest source=source dport=dport sport=sport idle=300

Allowing Generic UDP Traffic

The previous filters allowed TCP traffic through the firewall. To allow clients inside the firewall to run UDP applications, such as accessing Domain Name Servers (DNS) outside the firewall, follow these steps.

1. Add a filter that allows UDP packet requests out from the firewall.

IP Filters Config firewall>add filter udp dir=out protocol=udp sport=transient

2. Add a child filter that allows UDP packet replies back in through the firewall.

IP Filters Config firewall>add filter udp.reply da=sa sa=da dp=sp sp=dp idle=30

Handling TFTP

The Trivial File Transfer Protocol (TFTP) is a connectionless transfer protocol based on UDP. The client's initial message is to a well-known port, but the response comes from a transient port. Subsequent messages from the client are sent to the same transient port from which the first server packet came.

The following steps show how to create parent and child filters to handle TFTP traffic from an internal client to an external TFTP server.

1. Create a filter to allow internal clients to access external TFTP servers.

IP Filters Config firewall>add filter tftpc dir=out protocol=udp sport=transient dport=tftp

2. Add a child filter to tftpc.

When the tftpc filter recognizes that an internal client accessed an external TFTP server, it installs the child filter. This filter opens a hole to allow packets from the server on any transient port back to the client.

IP Filters Config firewall>add filter tftpc.response dir=in dest=source source=dest sport=transient dport=sport delete=on idle=30

3. Add a child filter to tftpc.response.

When tftpc.response recognizes the response from the server, it deletes itself in favor of tftpc.response.narrower, which has the specific pairs of port numbers.

IP Filters Config firewall>add filter tftpc.response.narrower dir=both dest=dest source=source dport=dport sport=sport idle=600

Because the direction of this filter is both, it also adds a new hole to pass the client's outbound packets back to the server. These packets are now going to a different port than the first packet.

Preventing Spoofing of Source Addresses

There is a form of attack which, while unlikely, is desirable to prevent. Suppose that a client on the inside of a firewall is accessing the company Web server. Suppose further that this Web server is also servicing clients outside the firewall. It is possible, though difficult, for a hacker outside the firewall to address packets to the Web server that claim (via spoofing) to be coming from the internal client. This hacker would be unable to get any data to come back out through the firewall, but might be able to disrupt the internal client's session.

To prevent this, add a filter that blocks any packets coming from the Internet that claim to have a source address that matches any network on the inside of the firewall. Such a packet is clearly a spoof and is some sort of attack.

In the example in Figure 1, the internal network number is 162.2.2.0. The following filter suffices:

IP Filter Config firewall>add filter nospoof before=* dir=in source=162.2.2.0&255.255.255.0 action=block

Summary

At this point, you have met all of the goals for the firewall with a total of 13 filters. Table 1 shows the filters that you added to satisfy each goal. Note that only webaccess and nospoof filters had site-specific information.

Table 1 Summary

Goal Filters Added to Satisfy
1. Allow data flows with the corporate Web server (HTTP) running on Server-C.

webaccess

2. Allow corporate (internal) personal computers to run Netscape, FTP, Telnet, DNS, and other client programs with servers outside the corporate network.

icout (2 filters)
ftpclient (4 filters)
tftpc (3 filters)
udp (2 filters)

3. Prevent external access to other applications on Server-C.

None needed

4. Prevent external access to any application on personal computers.

None needed

5. Prevent internal users from offering illegal servers to the Internet.

None needed

6. Prevent internal data flows from being disrupted by attack.

nospoof



[Top] [Prev] [Next] [Bottom]

Copyright © 2001, Nx Networks, Inc. All rights reserved.