Packet Filtering

Introduction

This chapter describes how to manage TCPware packet filtering.

Using Packet Filtering

Packet filtering is used today in almost all (from basic to sophisticated) security firewalls. Packet filtering firewalls apply filtering rules to each packet received to determine whether to accept or discard it. These filtering rules specify the protocol, source and destination IP addresses, and destination ports (for TCP and UDP) for accepted or discarded packets.

You use packet filtering on routers between an internal network and one or more external networks (such as a connection to the Internet). Packet filter rules restrict what may come in over the interface connected to the external network.

Packet filtering can also be useful on hosts. For example, you can restrict the hosts allowed access to services. In particular, these are UDP-based services and services that the TCPware master server does not activate, and thus cannot use incoming access restrictions.

TCPware's packet filtering support is similar to what many routers provide. Once you create a file containing the packet filter rules and load it for an interface, any IP datagrams received on that interface are filtered before being processed or forwarded. (Packets are only forwarded if you enable forwarding; see the NETCU ENABLE FORWARDING command for details.)

Note that when you use packet filtering, each and every datagram received on the interface is filtered. This increases processing overhead depending on the size of the filter list.

Packet filtering can be an effective and useful security mechanism. However, it cannot solve all of your security problems. To be effective, you must construct the filtering rules carefully.

Cautions

Consider the following cautions when setting up packet filtering on an interface:

• Packet filtering does not use state information. Each datagram is filtered without any knowledge of packets that preceded it.

This means that for UDP-based applications, it is not possible to add a rule that says to accept replies to requests. This also affects connection-oriented protocols such as FTP that use two connections, one for commands and the other for data.

• Fragmented datagrams for UDP or TCP are difficult to filter, since only the first fragment has the necessary port information. TCPware solves this problem by applying the filter rules only to the first fragment of UDP and TCP datagrams. The other fragments are accepted and processed or forwarded, but are eventually discarded since they cannot be reassembled without the first fragment. For all other IP protocols, the filter rules apply to each fragment.
• To set up secure packet filtering lists, you need a detailed knowledge of IP, ICMP, TCP, UDP and applications protocols.

Suggested reading includes the protocol RFCs (listed elsewhere in the TCPware documentation) and books such as Cheswick, William R. & Steven M. Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker.

Packet Filter File

Packet filtering uses a filter list to determine whether you can receive a datagram. Filter lists are in packet filter files having the .DAT extension by default. Create one of these files first and then edit it. Format each file entry in the manner described in Table 20-1.

Table 20-1 Fields in a Packet Filter File Entry

Field...	With valid values...	Description
Entry Format: action protocol saddr smask [sport] daddr dmask [dport [doption]]
action	permit drop deny	permit permits the datagram; deny denies the datagram and sends the ICMP; drop denies the datagram without sending an ICMP destination unreachable message to the sender.
protocol	ip ip-number tcp udp icmp	Protocol to check: the values indicated or the numeric IP protocol number. The value ip matches any IP protocol.
saddr	Example: 192.168.123.123	Source IP address to check.
smask	Example: 255.255.255.255	Source address mask to check, in standard bit mask format. To match a single address, use 255.255.255.255. To match any address, use 0.0.0.0
sport	operator operand lt port le eq ge gt ne	Optional source port specification to check (for TCP and UDP entries only). Consists of an operator, space, and port name or number. If port name, must be defined in the TCPWARE:SERVICES. file. If omitted, any source port is valid. Example: gt 1023
daddr	Example: 192.168.123.123	Destination IP address to check.
dmask	Example: 255.255.255.255	Destination address mask to check, in standard bit mask format, as in s-mask above.
dport	operator operand lt port le icmp-msg-type eq ge gt ne	Optional destination port (for TCP and UDP entries) or ICMP message type specification consisting of an operator, space, and operand. If a port name, must be in the TCPWARE:SERVICES. file. If icmp-msg-type, use: 0 Echo Reply3 Destination Unreachable4 Source Quench5 Redirect8 Echo11 Time Exceeded12 Parameter Problem13 Timestamp14 Timestamp Reply15 Information Request16 Information Reply
doption	established	Matches only established connections (TCP segments with ACK or RST bits set).

Each entry specifies a packet filtering condition for a particular protocol type, source or destination address and mask, and destination port and mask specification, with certain additional options. The system looks at each condition in sequence, looks for a match, and takes a permit (accept) or deny (reject) action. The system stops testing conditions after the first match. This means that the order of the entries in the file is important; if the file lists a subsequent condition for an address, the system ignores it.

An implicit deny terminates the list of entries in the packet filter file. This means that if no condition matches, the system rejects the datagram. To use packet filtering:

1	Create address list entries in the packet filter file.
2	Apply the list to interfaces on your system by using packet filtering commands.

To create a packet filter file, edit a file and add address list entries in the format described.

Any number of spaces or tabs can separate each entity. Lines beginning with an exclamation point (!) are comment lines. You can use the dash (–) continuation character at the end of a line that needs to continue onto the next.

To apply the list to a particular network interface or interfaces on your system, use the SET FILTER command, as described in Setting and Showing.

Configuration Recommendations

A packet filtering configuration might look something like Figure 20-1. A packet filter is installed at the ISA-1 interface to prevent unwanted packets from the external networks from entering the internal network. TCPware's packet filters are applied to packets received on a specific interface (no filtering of transmitted packets is done).

Figure 20-1 Tunneling DECnet over IP

Constructing the address filter list requires care in that you only want to let in the packets you need. Here are some recommendations in setting up an address filter list for an interface:

• Add an entry to prevent IP spoofing (that is, having an external host send a datagram as if it came from a local machine). For a router (as in Figure 20-1), this makes sense since no datagram received from an external network should ever have a local source address. Add the following entry to the filter list for the external interface (ISA-1 in Figure 20-1):

  deny ip local-network local-network-mask

• Be careful with services that use "unprotected" port numbers (greater than 1024). Some examples are NFS (port 2049) and X Windows (port 6000 and higher). Explicitly denying these services is a good idea:

  deny udp 0 0 0 0 eq 2049
  deny tcp 0 0 0 0 eq 2049
  deny tcp 0 0 0 0 eq 6000
  deny tcp 0 0 0 0 eq 6001

• Prevent broadcast and loopback packets from entering your network. It is best to restrict the broadcast (the first two of the following entries) to an external interface; apply the loopback restriction (the last entry) to any interface:

  drop ip 0.0.0.0 255.255.255.255
  drop ip 255.255.255.255 255.255.255.255
  drop ip 127.0.0.0 255.0.0.0

• Guard against datagrams from invalid source addresses when connected to the Internet (provided you are not using these network numbers for internal-only traffic purposes). Add the following to the filter list for the external interface (ISA-1 in Figure 20-1):

  drop ip 10.0.0.0 255.0.0.0
  drop ip 172.16.0.0 255.240.0.0
  drop ip 192.168.0.0 255.255.0.0

• You generally need to allow in domain name (DNS) requests using:

  permit udp 0 0 0 0 eq 53

  Whether to allow TCP DNS traffic (usually used for zone transfers) is also something to consider. To disallow TCP DNS traffic, add:

  deny tcp 0 0 0 0 eq 53

• You should not be concerned with what services local users use in the external world. You would want to add:

  permit tcp 0 0 0 0 gt 1023 established

  This allows all TCP datagrams in to ports greater than 1023 that have either the ACK or RST bits set in the TCP flags. Connection establishment requests have just the SYN bit set, so they are not allowed in by this entry.

  You may want to drop the established option if you want to allow incoming connections to unprotected ports. This would allow use of the FTP PASV capability.

• You may offer services to the external world such as a World Wide Web or anonymous FTP server. Add the following entries:

  permit tcp 0 0 (web-server) 255.255.255.255 eq 80
  permit tcp 0 0 (ftp-server) 255.255.255.255 eq 21

  If you have several hosts for each service, add an entry for each. Note that for the FTP Server, the data connections are normally outgoing and thus the earlier permit tcp 0 0 0 0 gt 1023 established configuration works to allow these. However, if users switch to PASV mode, the connections will be incoming (to unprotected port numbers) and therefore the permit tcp 0 0 0 0 gt 1023 configuration (without the established option) may be more effective.

• Allow all ICMPs except ICMP redirects in:

  deny icmp 0 0 0 0 eq 5
  permit icmp

  This is useful for informing hosts about problems. But it can open up denial of service attacks, especially if hosts are not careful about the ICMP redirects that they accept. That is why discarding them is recommended.

• Watch the order of the entries in the table carefully.

  permit tcp 0 0 0 0 gt 1023
  deny tcp 0 0 0 0 eq 2049

  This entry would not work since the permit entry allows the datagram in and processing stops as soon as a match is found. TCPware processes the entries in the order in which you specify them.

• Remember that an implicit "deny everything" is added to the end of the filtering list. This means that to permit a datagram in, you need to have a permit entry in the list.
• Once you applied your filter list, test it first. Get an account on a host on an outside network that you can use to connect to your local hosts. Check that you are not allowing any access you do not want, and that you are allowing access that you do want. If something is not right, modify the filter list, reload it, and retest.

While packet filtering is very useful, it is by no means the only step you should take to secure your network. You must take special care to secure the system to assure that it cannot be compromised. One way to do this is to greatly limit the services it offers.

Setting and Showing

The commands to set and show packet filters are:

SET FILTER	Associates a packet filter list with particular network lines
SET NOFILTER	Removes a previously associated packet filter list from network line(s)
SHOW FILTER	Displays the current packet filter list for network lines

See the NETCU Command Reference manual for details on these commands.

Setting at Startup

When you start TCPware, the STARTNET procedure looks for a TCPWARE:FILTER-line-id.DAT file for each interface it starts. If the file exists, STARTNET issues the following NETCU command to set the filter list for the interface:

SET FILTER line-id TCPWARE:FILTER-line-id.DAT

You can also add the necessary NETCU commands to the TCPWARE:ROUTING.COM file.