|
|
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.
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)):
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.)
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 |
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:
You can construct a filter so that it only allows packets destined for specified services to pass. All other packets are dropped. This approach is best if you can easily specify which services you want to allow such as HTTP and DNS. You may inadvertently block certain services that people want to use but you can add these later if necessary.
You can construct a filter so that it stops packets destined for specified services from passing. All other packets are allowed to pass. This allows access to all services except those that you specifically block because they may be used to attack your site's systems. This is obviously more risky than restrictive filtering.
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.
``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
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:
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.
``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 |
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 |
This section provides sample filters for restrictive and passive filtering.
# 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.
# 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.
You can use the Packet Filter Manager to define a PPP packet filter that is applied to a WAN network interface.
You can start the Packet Filter Manager in any of these ways:
Packet Filter Manager.
To add a packet filter definition or modify an existing definition for an interface using the Packet Filter Manager:
Interface,
choose the interface to which the filter will be applied or to which it
is currently applied, and click on OK.
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.
See also:
To define an element of a packet filter using the Packet Filter Manager:
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.
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.
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.
To copy a packet filter definition using the Packet Filter Manager:
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.
Copy.
To rename a packet filter definition for an interface using the Packet Filter Manager:
Interface,
choose the interface for which the filter is currently defined, and
click on OK.
Rename.
To delete a packet filter definition for an interface using the Packet Filter Manager:
Interface,
choose the interface for which the filter is currently defined, and
click on OK.
Delete.
Click on OK to confirm.