Protecting Services on Assigned Unprivileged Ports

Services intended for local or private use, in particular, often run on unprivileged ports. For TCP-based services, a connection attempt to one of these services can be distinguished from an ongoing connection with a client using one of these unprivileged ports through the state of the SYN and ACK bits. Blocking connection requests is sufficient. UDP-based services must simply be blocked unless the state module is used.

You should block incoming connection attempts to these ports for your own security protection. You want to block outgoing connection attempts to protect yourself and others from mistakes on your end and to log potential internal security problems. It's safer to block these ports across the board and route related traffic on an exceptional, case-by-case basis.

OFFICIAL SERVICE PORT NUMBER ASSIGNMENTS

Port numbers are assigned and registered by the IANA. The information was originally maintained as RFC 1700, "Assigned Numbers." That RFC is now obsolete. The official information is dynamically maintained by the IANA at http://www.iana.org/assignments/port-numbers.

What kinds of mistakes might you need protection from? The worst mistake is offering dangerous services to the world, whether inadvertently or intentionally. A common mistake is running local network services that leak out to the Internet and bother other people. Another is allowing questionable outgoing traffic, such as port scans, whether this traffic is generated by accident or intentionally is sent out by someone on your machine. A deny-everything-by-default firewall policy protects you from many mistakes of these types.

THE PROBLEM WITH PORT SCANS

Port scans are not harmful in themselves. They're generated by network-analysis tools. The problem with port scans today is that they are usually generated by people with less-than-honorable intentions. They are "analyzing" your network, not their own. Unfortunately, this leaves the merely curious looking guilty as well.

A deny-everything-by-default firewall policy enables you to run many private services behind the firewall without undue risk. These services must explicitly be allowed through the firewall to be accessible to remote hosts. This generalization is only an approximation of reality, however. Although TCP services on privileged ports are reasonably safe from all but a skilled and determined hacker, UDP services are inherently less secure, and some services are assigned to run on unprivileged ports. RPC services, usually run over UDP, are even more problematic. RPC-based services are bound to some port, often an unprivileged port. The portmap daemon maps between the RPC service number and the actual port number. A port scan can show where these RPC-based services are bound without going through the portmap daemon. Luckily, the use of portmap is becoming less and less common, so this isn't as much of a concern as it was a number of years ago.

Common Local TCP Services Assigned to Unprivileged Ports

Some services, usually LAN services, are offered through an officially registered, well-known unprivileged port. Additionally, some services, such as FTP and IRC, use more complex communication protocols that don't lend themselves well to packet filtering. The rules described in the following sections disallow local or remote client programs from initiating a connection to one of these ports.

FTP is a good example of how the deny-by-default policy isn't always enough to cover all the possible cases. The FTP protocol is covered later in this chapter. For now, the important idea is that FTP allows connections between two unprivileged ports. Because some services listen on registered unprivileged ports, and because the incoming connection request to these services is originating from an unprivileged client port, the rules allowing FTP can inadvertently allow incoming connections to these other local services as well. This situation is also an example of how firewall rules are logically hierarchical and order-dependent. The rules explicitly protecting a private, local service running on an unprivileged port must precede the FTP rules allowing access to the entire unprivileged port range.

As a result, some of these rules appear to be redundant and will be redundant for some people. For other people running other services, the following rules are necessary to protect private services running on local unprivileged ports.

DISALLOWING CONNECTIONS TO COMMON TCP UNPRIVILEGED SERVER PORTS

Connections to remote X Window servers should be made over SSH, which automatically supports X Window connections. By specifying the --syn flag, indicating the SYN bit, only connection establishment to the server port is blocked. Other connections initiated using the port as a client port are not affected.

X Window port assignment begins at port 6000 with the first running server. If additional servers are run, each is assigned to the next incremental port. As a small site, you'll probably run a single X server, so your server will listen only on port 6000. Port 6063 is typically the highest assigned port, allowing 64 separate X Window managers running on a single machine, although ranges up to 6255 and 6999 are also seen sometimes:

 XWINDOW_PORTS="6000:6063"                # (TCP) X Window 

The first rule ensures that no outgoing connection attempts to remote X Window managers are made from your machine:

 # X Window connection establishment $IPT -A OUTPUT -o $INTERNET -p tcp --syn \          --destination-port $XWINDOW_PORTS -j REJECT 

The next rule blocks incoming connection attempts to your X Window manager. Local connections are not affected because local connections are made over the loopback interface:

 # X Window: incoming connection attempt $IPT -A INPUT -i $INTERNET -p tcp --syn \          --destination-port $XWINDOW_PORTS -j DROP 

The remaining TCP-based services can be blocked with a single rule by use of the multiport match extension. Blocking incoming connections isn't necessary if the machine isn't running the service, but it's safer in the long run, in case you later decide to run the service locally.

NFS usually binds to UDP port 2049 but can use TCP. You shouldn't be running NFS on a firewall machine, but if you are, external access is denied.

Connections to Open Window managers should not be allowed. Linux is not distributed with the Open Window manager. Incoming connections to port 2000 don't need to be blocked. (This will not be the case later, when the firewall's FORWARD rules are protecting other local hosts.)

Attempts to connect to remote SOCKS servers are fairly common and often involve intrusion exploits. SOCKS uses port 1080.

squid is a web cache and proxy server. squid uses port 3128 by default but can be configured to use a different port.

The following rule blocks local clients from initiating a connection request to a remote NFS server, Open Window manager, SOCKS proxy server, or squid web cache server:

 NFS_PORT="2049"                        # (TCP) NFS SOCKS_PORT="1080"                      # (TCP) socks OPENWINDOWS_PORT="2000"                # (TCP) OpenWindows SQUID_PORT="3128"                      # (TCP) squid # Establishing a connection over TCP to NFS, OpenWindows, SOCKS or squid $IPT -A OUTPUT -o $INTERNET -p tcp \          -m multiport --destination-port \          $NFS_PORT,$OPENWINDWS_PORT,$SOCKS_PORT,$SQUID_PORT \          --syn -j REJECT $IPT -A INPUT -i $INTERNET -p tcp \          -m multiport --destination-port \          $NFS_PORT,$OPENWINDWS_PORT,$SOCKS_PORT,$SQUID_PORT \          --syn -j DROP 

Common Local UDP Services Assigned to Unprivileged Ports

TCP protocol rules can be handled more precisely than UDP protocol rules because of TCP's connection establishment protocol. As a datagram service, UDP doesn't have a connection state associated with it. Unless the state module is used, access to UDP services should simply be blocked. Explicit exceptions are made to accommodate DNS and any of the few other UDP-based Internet services you might use. Fortunately, the common UDP Internet services are often the type used between a client and a specific server. The filtering rules can often allow exchanges with one specific remote host.

NFS is the main UNIX UDP service to be concerned with and also is one of the most frequently exploited. NFS runs on unprivileged port 2049. Unlike the previous TCP-based services, NFS is primarily a UDP-based service. It can be configured to run as a TCP-based service, but usually it isn't.

Associated with NFS is the RPC lock daemon, lockd, for NFS. lockd runs on UDP port 4045:

 NFS_PORT="2049"                           # NFS LOCKD_PORT="4045"                         # RPC lockd for NFS # NFS and lockd if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p udp \              -m multiport --destination-port $NFS_PORT,$LOCKD_PORT \              -m state --state NEW -j REJECT     $IPT -A INPUT -i $INTERNET -p udp \              -m multiport --destination-port $NFS_PORT,$LOCKD_PORT \              -m state --state NEW -j DROP else     $IPT -A OUTPUT -o $INTERNET -p udp \              -m multiport --destination-port $NFS_PORT,$LOCKD_PORT \              -j REJECT     $IPT -A INPUT -i $INTERNET -p udp \              -m multiport --destination-port $NFS_PORT,$LOCKD_PORT \              -j DROP fi 

THE TCP AND UDP SERVICE PROTOCOL TABLES

The remainder of this chapter is devoted to defining rules to allow access to specific services. Client/server communication, for both TCP- and UDP-based services, involves some kind of two-way communication using a protocol specific to the service. As such, access rules are always represented as an I/O pair. The client program makes a query, and the server sends a response. Rules for a given service are categorized as client rules or server rules. The client category represents the communication required for your local clients to access remote servers. The server category represents the communication required for remote clients to access the services hosted from your machines.

The application messages are encapsulated in either TCP or UDP transport protocol messages. Because each service uses an application protocol specific to itself, the particular characteristics of the TCP or UDP exchange are, to some extent, unique to the given service.

The exchange between client and server is explicitly described by the firewall rules. Part of the purpose of firewall rules is to ensure protocol integrity at the packet level. Firewall rules, expressed in iptables syntax, are not especially human-readable, however. In each of the following sections, the service protocol at the packet-filtering level is presented as a table of state information, followed by the iptables rules expressing those states.

Each row in the table lists a packet type involved in the service exchange. A firewall rule is defined for each individual packet type. The table is divided into columns:

• Description contains a brief description of whether the packet is originating from the client or the server, and the packet's purpose.

• Protocol is the transport protocol in use, TCP or UDP, or the IP protocol's control messages, ICMP.

• Remote Address is the legal address, or range of addresses, that the packet can contain in the remote address field.

• Remote Port is the legal port, or range of ports, that the packet can contain in the remote port field.

• In/Out describes the packet's directionthat is, whether it is coming into the system from a remote location or whether it is going out from the system to a remote location.

• Local Address is the legal address, or range of addresses, that the packet can contain in the local address field.

• Local Port is the legal port, or range of ports, that the packet can contain in the local port field.

• TCP protocol packets contain a final column, TCP Flag, defining the legal SYN-ACK states that the packet may have.

The table describes packets as either incoming or outgoing. Addresses and ports are described as either remote or local, relative to your machine's network interface. Notice that, for incoming packets, Remote Address and Port refer to the source fields in the IP packet header; Local Address and Port refer to the destination fields in the IP packet header. For outgoing packets, Remote Address and Port refer to the destination fields in the IP packet header; Local Address and Port refer to the source fields in the IP packet header.

Finally, in the few instances when the service protocol involves ICMP messages, notice that the IP Network-layer ICMP packets are not associated with the concept of a source or destination port, as is the case for Transport-layer TCP or UDP packets. Instead, ICMP packets use the concept of a control or status message type. ICMP messages are not sent to programs bound to particular service ports. Instead, ICMP messages are sent from one computer to another. (The ICMP packet contains a copy of at least some of the original packet that resulted in the error message. The receiving host identifies the process that the error refers to by examining the packet carried in the ICMP packet's data area.) Consequently, the few ICMP packet entries presented in the tables use the source port column to contain the message type. For incoming ICMP packets, the source port column is the Remote Port column. For outgoing ICMP packets, the source port column is the Local Port column.