19. 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.
|
Field... |
With valid values... |
Description |
|
Entry Format: action protocol saddr smask [sport] daddr dmask [dport [doption]] |
||
|
action |
permit |
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 |
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 |
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 |
|
dport |
operator operand lt port |
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 Reply |
|
doption |
established |
Matches only established connections (TCP segments with ACK or RST bits set). |
|
start time |
|
Absolute of delta VMS-format date/time. If specified, the filter takes effect starting at the time specified. By default, a filter takes effect when loaded by MultiNet if the start time is not defined. |
|
end time |
|
Absolute or delta VMS-format date/time. If specified, the filter is ignored after the time specified is reached if an absolute time is specified, or after the time calculated by adding the end time to the start time if a delta time is specified. If no start time was specified, the delta time is added to the current time. If the end time for a non-repeating filter has already passed when the filter definition is parsed, the filter is not loaded and the user is informed of that fact. |
|
repeat |
|
If Y and start/end times are specified, this filter repeats until it is removed. Both a start and end time must be specified in order to specify a repeating filter. |
|
log |
|
Logs events from this filter. |
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.
Filtering by Time
Filters may be set to be activated only during a specified time period. These filters may be specified as a one-time filter or as a filter that repeats. For example, a filter may be set up to filter all traffic from a specific address during the hours of 5am to 5pm each day, or a filter may be specified that filters traffic starting from the time the filter is loaded and for the next 3 hours.
Time-based filtering is done by specifying a start time, an end time, or both start and end times for a filter in the filter definition file. For repeating filters, both start and end times must be specified. Note that all time values for start and end times must be specified in VMS absolute or delta time format. For example, the following are all valid:
|
29-DEC-2014 |
would be interpreted as "29-DEC-2014 <current time> |
|
29-DEC-2014 18:03 |
would be interpreted as "29-DEC-2014 18:03:00.00" |
|
18:03:00 |
would be interpreted as "<current date> 18:03:00.00" |
|
1 15:00 |
would be interpreted as a delta time of 1 day, 15 hours |
Note that if an absolute time is specified that contains both a date and time (example 2 above), it MUST be enclosed by double quotes. For example:
deny icmp 0 0 0 0 eq 5 start 17:00:00 end "29-Sep-2014 6:00:00"
Given the following filter file (the dashes at the end of some
lines are for readability only, and are not valid):
deny tcp 15.1.94.2 15.1.94.255
2.22.2.5 255.255.255.255 start 15:20 end 18:30 repeat
deny tcp 1.1.94.2 1.1.94.255 207.225.29.51 255.255.255.255 end
"1-JAN-2014 18:30" deny tcp 195.101.94.209 195.101.94.255
207.225.29.51 255.255.255.255 start
18:00 end "1 00:30" repeat
deny tcp 195.101.94.209 195.101.94.255 207.225.29.51 255.255.255.255
deny tcp 195.101.94.209 195.101.94.255 207.225.29.51 255.255.255.255 start
17:00 end 18:30
deny tcp 15.1.94.2 15.1.94.255 2.22.2.5 255.255.255.255 start "2
00:00" end 3 00:00"
Line 1 will filter from 15:20 to 18:30 each day.
Line 2 will filter from the time the filter is loaded through 18:30 on January
1, 2014
with no logging. After that time, if the filters are reloaded, this filter will
not be loaded.
Line 3 will filter from 18:00 to 19:30 each day.
Line 4 has no time limits on it.
Line 5 will log from 17:00 through 18:30 today.
Line 6 will filter starting 2 days from the time the filter is loaded, through
3 days after that.
Filter Logging
Filter "hits" may be logged, either to OPCOM or to a file defined by the user. Logging is enabled on a filter-by-filter basis, by using the "log" keyword on the end of a filter definition line. For example:
deny tcp 192.10.9.209 192.10.9.255 207.225.29.51 255.255.255.255 log
Logging for the interface is controlled via the NETCU SET FILTER command. The actual logging is performed by the TCPware_FLOG process, which is started the first time a NETCU SET FILTER <interface><filter_file>/LOG command is issued (a single TCPware_FLOG process handles logging for all interfaces defined on the system).
The NETCU SET FILTER command switches used to support logging are
|
Qualifier |
Values |
Default |
Description |
|
/[NO]LOG |
OPCOM or a valid filename |
None |
Used to turn logging on or off. Filter events may be logged to OPCOM or to a specified file. Only those events with the LOG qualifier in their definition are affected by this qualifier. |
|
/FORMAT |
COMMA or NORMAL |
NORMAL |
If NORMAL, then the normal formatting as seen by |
|
/INTERVAL |
Number of seconds, between 5 and 2^31 |
5 seconds |
Reporting interval. The minimum reporting interval is 5 seconds, so that a flood of filter events doesnt drag the system down. When reporting events, a count of missed events will be included for each event where the event couldnt be reported before the next event occurred. |
When filter logging is enabled, the TCPware_FLOG process will be started. This process checks each interface at the interval defined by the /INTERVAL qualifier for the NETCU SET FILTER command. As unlogged filter hits are found, it will log them to OPCOM or to a file, according on the parameters set by the /LOG and /FORMAT qualifiers for the NETCU SET FILTER command.
When logging to OPCOM, only NORMAL formatting is allowed. An OPCOM message, formatted as the filter output from NETCU SHOW FILTER, will be displayed for each filter with unlogged hits on it.
When logging to a file, the output will be identical to that of
the filter displays from NETCU SHOW FILTER command, if /FORMAT=NORMAL is
specified. If
/FORMAT=COMMA is specified, the data will be recorded as comma-delimited
fields, one line per filter, to the file. The first line of this file will
contain the field names (comma-delimited) to aid in interpreting the contents
of the file.
Examples:
NETCU SET FILTER EWA-0 FILTERS.DAT /LOG=OPCOM/INTERVAL=10
enables logging to OPCOM, with a reporting interval of 10 seconds.
NETCU SET FILTER EWA-0 FILTERS.DAT/LOG=FOO.DAT/FORMAT=COMMA
enables logging to the file FOO.DAT in comma-delimited format, and a reporting interval of 5 seconds (the default).
NETCU SET FILTER EWA-0 /NOLOG
This disables all logging for the interface, closing all open log files.
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).
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 Tunneling DECnet over IP), 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 Tunneling DECnet over IP):
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 Tunneling DECnet over IP):
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.