DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Configuring packet filters

Configuring packet filters

In UnixWare 7 Release 7.2, you can use PPP packet filtering to control what types of packets are allowed access to your site's networks and also which packets are allowed to leave your site.

For another method of controlling access to Internet services, see ``Configuring TCP Wrappers''. This mechanism is configurable independently of any underlying filtering that may have been set up.

``A filter applied to a gateway'' shows a filter that has been applied to a gateway machine that connects local networks to the Internet.

A filter applied to a gateway

Connections to the Internet are usually made using a PPP link to an Internet Service Provider (ISP). By configuring filtering on the gateway machine, you can effectively control all network traffic between the local site and the external world. For example, you could allow access from outside to certain services such as FTP and HTTP on the gateway machine but prevent such access to your internal systems. (In practice, it is not recommended that you use a gateway machine to host such services as they might potentially be used to compromise its security. A more common arrangment is to host the services on a separate dedicated machine on the Internet-side of the gateway.) To allow access from hosts on your internal networks to the gateway machine, you need only restrict access to the services for packets that originate from external addresses.

Packet filters for a PPP interface may be constructed by adding their definitions to the appropriate configuration file, or you can use the graphical Packet Filter Manager instead. See ``Designing filters'' for more information on creating filters that are appropriate to your needs.

PPP packet filters


NOTE: In UnixWare 7 Release 7.2, packet filtering is only supported on PPP WAN network interfaces. In previous release, it was also supported for LAN interfaces that used MDI network adapter drivers.

A PPP interface can be configured with four types of packet filter as part of its Internet Protocol Control Protocol (IPCP) characteristics (see ppptalk(1M)):


passin
defines which incoming packets can pass through the interface

passout
defines which outgoing packets can pass through the interface

bringup
defines which packets can bring up a link automatically

keepup
defines which packets can reset the idle timer on a link and so prevent it being brought down
All PPP interfaces share the same filter definition file. The file can contain many filter definitions, each of which must be identified by a unique tag. Each PPP interface can use a different set of filters from the file.


NOTE: Of the four types of PPP packet filters, IP filters can only emulate passout and passout filters. If you require bringup and keepup filters, you must use packet filters to implement these.

To apply a packet filter to a PPP interface, use the PPP Manager. (PPP filters are configured as attributes of the IPCP protocol definition that is associated with a PPP bundle. See ``Configuring a bundle'' and ppptalk(1M) for more information.)

For more about PPP packet filters

To obtain more information about PPP packet filters, see the following manual pages:

Manual page Information provided  
filter(4) Packet filter file syntax
ppptalk(1M) Administrative interface to PPP

Designing filters

The filter mechanism available in UnixWare 7 Release 7.2 allows you to permit or block access to packets based on their source and destination addresses, source and destination ports, direction of travel, and also on protocol-specific information such as TCP flags and ICMP types and codes.

There are two basic methods for designing filters:

As the normal operation of restrictive or permissive filters is to control access to local services from outside, you would usually apply such a filter to incoming packets on the external interface of a gateway.

The simplest type of filter screens packets based on a service defined by the combination of a port number and a protocol type (TCP or UDP). It does not care about the direction in which packets are crossing the interface, or their source or destination addresses.

Fundamentals of protocol operation

``Information used to filter network packets'' summarizes the important information that may be used to TCP/IP network packets.

Information used to filter network packets


Source address
The IP address of the machine from which the packet was sent. This is encoded in the packet's IP header.

Destination address
The IP address of the machine to which the packet is traveling. This is encoded in the packet's IP header.

Source port
A number that is associated with a process on the machine from which the packet was sent. This is encoded in the packet's TCP or UDP header. It is not present in ICMP messages.

Destination port
A number that is associated with a process on the machine to which the packet is traveling. This is encoded in the packet's TCP or UDP header. It is not present in ICMP messages.

Protocol
A number encoded in the packet's IP header that identifies the protocol, such as TCP, UDP or ICMP which will be used to interpret the information carried inside the IP datagram.

If the process on the source or destination machine implements a service (for example, an HTTP server), the source or destination port number is termed ``well-known'' or ``reserved'', and is usually defined in services(4tcp) to be in the range 1 through 1023. These ports are also ``privileged'' in the sense that they can only be assigned to a process with root privileges. There are exceptions to this rule as will be described later.

If the process on the source or destination machine is a client of a service (for example, an HTTP browser), the source or destination port number is temporarily assigned from a pool of available (or ``ephemeral'') port numbers in the range 1024 through 65535. (On UnixWare 7 Release 7.2 systems, ephemeral ports are assigned from the range 32768 through 65535 by default, but other systems may use different ranges taken from 1024 through 65535.) There are also exceptions to this rule as will be described later.

TCP is a connection-oriented protocol. This means that it attempts to maintain reliable delivery of data streamed over an established connection. Part of the mechanism for tracking the state of a TCP connection are several flags within the TCP segment header:

Flag Description
ACK Acknowledge a sequence number
FIN Finished sending data
PSH Push data to an application
RST Reset the connection
SYN Synchronize sequence numbers
URG Data requiring urgent attention

``Flags set during a TCP connection'' illustrates the flags that are usually set in TCP segments during the existence of a TCP connection. The main points to note are:

The most reliable way of testing whether a TCP segment is attempting to open a connection is to look for SYN set and ACK not set. If this is not available, look for ACK not set. This is not as reliable because some TCP/IP implementations may not set ACK in conjunction with RST or FIN.

Flags set during a TCP connection

UDP is a connectionless protocol. This means that it does not attempt to keep track on whether a reply is ever returned in response to a request. ``Illustration of a UDP exchange'' illustrates the much simpler nature of UDP requests and replies. UDP has no flags to record connection state. An application that uses UDP as its transport must perform all such book keeping itself.

Illustration of a UDP exchange

TCP and UDP form the basis of client-server interaction over TCP/IP-based networks including the Internet. Another important protocol is ICMP which encapsulates its messages and responses directly inside IP datagrams without using the TCP or UDP transport protocols. ICMP implements error and control handling on behalf of IP. It is also the basis of useful network administration commands such as ping(1Mtcp) and traceroute(1Mtcp). ICMP has been used in many denial-of-service type attacks so you should take it into consideration when designing filters. Rather than blocking ICMP completely, you may wish to allow access to message types 0 and 11 so that these commands will continue to function.

Restricting services

``Services which you may wish to restrict'' lists some services to which you may want to consider blocking access from outside your organization.

Services which you may wish to restrict

Service Port Protocols Description
systat 11 tcp/udp Display output from ps
netstat 15 tcp/udp Display output from netstat
ftp-data 20 tcp FTP data transfer port
ftp 21 tcp FTP server (in.ftpd) port
telnet 23 tcp telnet server (in.telnetd) port
smtp 25 tcp Mail transport port
domain 53 tcp/udp DNS server (in.named) port
tftp 69 udp TFTP server (in.tftpd) port
finger 79 tcp finger server (in.fingerd) port
http 80 tcp HTTP server port
link 87 tcp ttylink port
pop-3 110 tcp Mail access port
sunrpc 111 tcp/udp RPC bind server (rpcbind) port
uucp 117 tcp UUCP daemon
imap-4 143 tcp Mail access port
snmp 161 udp Network management port
exec 512 tcp Remote execution server (in.rexecd) port
login 513 tcp Remote login server (in.rlogind) port
shell 514 tcp Remote shell server (in.rshd) port
syslog 514 udp System logging
printer 515 tcp Print services port
nfsd 2049 udp NFS server daemon (nfsd) port
xserver0 6000 tcp First X server port

Port considerations

A common practice when constructing filters is to block all incoming TCP connection requests to ports with numbers greater than 1023. This prevents access to servers, such as those for X Windows and NFS, that listen on ports above 1023. Unfortunately, it also blocks data transfers from external FTP servers which try to open a port for data transfer on local FTP clients. In this case, your internal users will need to set their FTP clients to use passive mode for data transfers.

``FTP server opening a data connection to an FTP client'' illustrates what usually happens when an FTP client wishes to transfer data from an FTP server.

FTP server opening a data connection to an FTP client

The FTP client has established a control connection to port 21 (ftp in /etc/services) on the FTP server. When a data transfer is required (to send or receive a file, or simply to list a directory's contents), the client opens an additional port to listen for an incoming connection, and uses either the PORT or the EPRT command to send the number of this port to the server. The server then opens the data connection from its local port 20 (ftp-data in /etc/services) to the specified port on the client. (This assumes that the sendport feature of the FTP client is turned on as recommended.)

``FTP client opening a passive-mode data connection to an FTP server'' illustrates how an FTP client can instead use a passive-mode connection if incoming connections to it from the FTP server are blocked.

FTP client opening a passive-mode data connection to an FTP server

As before, the FTP client has established a control connection to port 21 on the FTP server. When a data transfer is required, the client uses either the PASV or the EPSV command to request that the server open a port to listen for an incoming connection. The server opens an ephemeral port, and sends the number of this port to the client. The client then opens the data connection from a local ephemeral port to the specified port on the server. Port 20 (ftp-data) on the server is not used at all.

See ftp(1tcp), RFC 1579 and RFC 2428 for more information about passive-mode FTP.

If you wish to allow access to an internal FTP server, you will need to open a hole to allow incoming TCP connection requests to ports above 1023 for the server's IP addresses. You should also make sure that no services such as X Windows and NFS are running on the FTP server. An alternative solution is to position the FTP server on the external side of the gateway machine. If necessary, it should be configured with its own set of filters to guard its integrity.

Rather than blocking access to certain services for all external addresses, you may choose to allow access for a specified subset of IP addresses. This is necessary, for example, if you want to restrict access to your internal DNS name servers but you need to be able to answer queries from root domain name servers.

A similar situation occurs with filters that block TCP connections from ports below 1024. This will prevent external access by rcp(1tcp), rlogin(1tcp), and rsh(1tcp), and by FTP servers for data transfers. If some external hosts require access using these commands, you could modify the filter rules to permit access from just their IP addresses. However, you should note that opening such holes permits attacks based on spoofed IP addresses. In any case, it is always worth checking that incoming packets do not come from invalid IP addresses, such as ones belonging to your internal networks.

``Combinations of addresses, ports, and protocols requiring consideration'' summarizes some combinations of addresses, ports and protocol-specific details that you may wish to consider blocking when filtering incoming packets. Note that this list is by no means exhaustive.

Combinations of addresses, ports, and protocols requiring consideration

Source
address
Source
port
Destination
address
Destination
port
Protocol Comments
Local Any Any Any Any Spoofed packets
Any Any Local
broadcast
Any Any ``Smurf'' denial-of-service attacks
Any Any Any Any ICMP Various spoofing denial-of-service attacks; you may wish to allow ICMP types 0 and 11 so that ping and traceroute will work
Any Any Any < 1024 TCP (SYN set, ACK not set),
or UDP
Attempts to access reserved ports; these could be allowed on a case-by-case basis for services such as SMTP, DNS, and HTTP, if directed to a restricted set of addresses
Any Any Any >= 1024 TCP (SYN set, ACK not set),
or UDP
Attempts to access non-reserved (ephemeral) ports; may include ports used by services such as NFS and X Windows
Any < 1024 Any Any TCP (SYN set, ACK not set),
or UDP
Attempts at access made from reserved ports; legitimately used by rcp, rlogin, and rsh for authentication, and by FTP servers for data transfer


NOTE: Source and destination port numbers have no meaning for ICMP.

Sample filters

This section provides sample filters for restrictive and passive filtering.

Restrictive PPP passin packet filter

# Define restrictive passin filter
#
passin_r \
#
# Block anything that pretends to come from your local network.
#
!(src net 202.160.12) and \
#
# Block smurf attacks.
#
!(dst host 202.160.12.0 or 202.160.12.255) and \
#
# Allow access to HTTP, FTP, SMTP and POP-3 on dedicated web servers,
#
((dst port http and host www.mynet.com) or \
(dst port ftp and host ftp.mynet.com) or \
# (note that the next line opens a large hole for passive-mode transfers)
(dst port >= 1024 and host ftp.mynet.com) or \
(dst port smtp and host post.mynet.com) or \
(dst port pop-3 and host mail.mynet.com) or \
#
# allow access to name servers,
#
(dst port domain and (host ns1.mynet.com or host ns2.mynet.com)) or \
#
# and allow incoming TCP packets other than connection requests (ACK set).
#
(tcp[13:1] & 0x10 != 0) or \
#
# For ICMP, only allow in ping and traceroute replies.
#
(icmp[0] == 0) or (icmp[0] == 11))
#
# Everything else incoming is dropped by default.

Permissive PPP passin packet filter

# Define permissive passin filter
#
passin_p \
#
# Block connection attempts from reserved ports,
#
!(tcp[0:2] < 1024 and tcp[13:1] & 0x10 == 0) and \
#
# block access to ports commonly used to attack systems,
#
!(dst port telnet or tftp or finger or link or sunrpc or \
	   exec or login or shell or printer) and \
#
# block access to all ports in the ephemeral port range,
#
!((tcp[2:2] >= 1024) and (tcp[13:1] & 0x10 == 0)) and \
#
# block anything that pretends to come from your local network,
#
!(src net 202.160.12) and \
#
# and block smurf attacks.
#
!(dst host 202.160.12.0 or 202.160.12.255)
#
# Everything else incoming passes by default.

The Packet Filter Manager Interface

You can use the Packet Filter Manager to define a PPP packet filter that is applied to a WAN network interface.


NOTE: You cannot use the Packet Filter Manager to apply a packet filter to a PPP interface. You must instead use the PPP Manager to specify which filters will be applied to a PPP interface when it is next brought up. You can use the Packet Filter Manager to define the filters that a PPP interface can be configured to use.

You can start the Packet Filter Manager in any of these ways:

For more information about using the SCOadmin managers, see ``Administering your system with SCOadmin''.

Configuring a packet filter

To add a packet filter definition or modify an existing definition for an interface using the Packet Filter Manager:

  1. Select Filter -> Interface, choose the interface to which the filter will be applied or to which it is currently applied, and click on OK.

  2. To create a new filter for an interface, select Edit -> Add. Enter the name of the new filter in the dialog box, and click on OK.

    To modify an exiting filter, select its name from the list of filters defined for the interface, and then select Edit -> Modify.

  3. Edit the set of filter elements as described in ``Editing filter elements''.

See also:

Editing filter elements

To define an element of a packet filter using the Packet Filter Manager:

  1. Select one of:

    Match
    Allow packets which match the filter to pass through the interface (passin or passout), to bring up the interface (bringup), or to keep up the interface open (keepup).

    Match except
    Allow packets which do not match the filter to pass through the interface (passin or passout), to bring up the interface (bringup), or to keep the interface open (keepup).

  2. Select the services and ports to which you want the filter element to apply in one of the following ways:

  3. To add a service or port to the list, click on Add. Enter the details of the service or port using the following format:
    port/protocol	[name]
    
    port is the port number of the service, protocol is one of tcp or udp, and the optional name identifies the service. Click on OK to add your entry to the list of ports and services.

    To modify the definition of a service or port, select it, and then click on Modify. Edit the entry and then click on OK.

    To delete one or more services or ports from the list, select them, and then click on Delete.


    NOTE: You cannot modify or delete entries which have been obtained from the services(4tcp) file, or which are used by other filter elements.

  4. Select the direction of packets to which the filter element will be applied:


    NOTE: If you want to specify different origin and destination addresses, you must define a separate filter element (From and To) for each.

  5. Specify the test to be applied to these addresses in one of the following ways:

  6. If you selected Specific or All except in the previous step, click on Add to enter source or destination addresses which are not already listed. Select whether the address is for a host or network, enter an IP address or a resolvable name for a host or network, and then click on OK to add it to the list.


    NOTE: Network IP addresses must be specified without the trailing 0's in what would normally be the host portion of the address. For example, you would specify 200.20.34 rather than 200.20.34.0 (assuming that the network mask is 255.255.255.0).

    To modify an address, select it from the list, and then click on Modify. Edit the entry and then click on OK.

    To remove one or more addresses from the list, select them, and then click on Delete.


    NOTE: You cannot delete an address from the list if it is used by other filter elements.

When you have completed the definition of a filter element, click on Next to edit any additional filter elements.

If you want to edit a previously defined filter element after completing the definition of this filter element, click on Back.

To remove an element from a filter definition, click on Delete.

To stop editing filter elements and save the complete filter, click on Finish. The filter will not become active until you apply it to an interface by selecting Filter -> Load.

Copying a packet filter

To copy a packet filter definition using the Packet Filter Manager:

  1. Select Filter -> Interface, choose the interface for which the source filter is currently defined, and click on OK.

    Alternatively, to choose from a list of example filters, select Filter -> Interface, then select Template filters, and click on OK.

  2. Select the filter to be copied from those listed, and then select Edit -> Copy.

  3. Select the interface to which the filter is to be copied, enter a new name for the filter if desired, and click on OK to confirm.

Renaming a packet filter

To rename a packet filter definition for an interface using the Packet Filter Manager:

  1. Select Filter -> Interface, choose the interface for which the filter is currently defined, and click on OK.

  2. Select the filter to be renamed from those listed for the interface, and then select Edit -> Rename.

  3. Enter the new name for the filter, and click on OK.

Deleting a packet filter

To delete a packet filter definition for an interface using the Packet Filter Manager:

  1. Select Filter -> Interface, choose the interface for which the filter is currently defined, and click on OK.

  2. If the filter is already applied to the interface, unload it using the PPP Manager or ppptalk(1M).

  3. Select the filter to be deleted from those listed, and select Edit -> Delete. Click on OK to confirm.

© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004