Enabling Basic, Required Internet Services

Only one service is truly required: the domain name service (DNS). DNS translates between hostnames and their associated IP addresses. You generally can't locate a remote host without DNS unless the host is defined locally.

Allowing DNS (UDP/TCP Port 53)

DNS uses a communication protocol that relies on both UDP and TCP. Connection modes include regular client-to-server connections, peer-to-peer traffic between forwarding servers and full servers, and primary and secondary name server connections.

Query lookup requests are normally done over UDP, both for client-to-server lookups and for peer-to-peer server lookups. The UDP communication can fail for a lookup if the information being returned is too large to fit in a single UDP DNS packet. The server sets a flag bit in the DNS message header indicating that the data is truncated. In this case, the protocol allows for a retry over TCP. Figure 4.4 shows the relationship between UDP and TCP during a DNS lookup. In practice, TCP isn't normally needed for queries. TCP is conventionally used for administrative zone transfers between primary and secondary name servers.

Figure 4.4. DNS client-to-server lookup.

Zone transfers are the transfer of a name server's complete information about a network, or the piece (zone) of a network, that the server is authoritative for (that is, the official server). The authoritative name server is referred to as the primary name server. Secondary, or backup, name servers can periodically request zone transfers from their primary to keep their DNS caches up-to-date.

For example, one of your ISP's name servers is the primary, authoritative server for the ISP's address space. ISPs often have multiple DNS servers to balance the load, as well as for backup redundancy. The other name servers are secondary name servers, refreshing their information from the master copy on the primary server.

Zone transfers require careful access control between the primary and the secondary servers. A small system isn't likely to be an authoritative name server for a public domain's name space, nor is it likely to be a public backup server for that information. Larger sites could easily host both primary and secondary servers. Care must be taken that zone transfers are allowed only between these hosts. Numerous attacks have been successful because the attacker was able to grab a copy of an entire DNS zone and learn about the network topology in order to direct the attack at the most valuable assets.

Table 4.1 lists the complete DNS protocol the firewall rules account for.

Table 4.1. DNS Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client query	UDP	NAMESERVER	53	Out	IPADDR	1024:65535
Remote server response	UDP	NAMESERVER	53	In	IPADDR	1024:65535
Local client query	TCP	NAMESERVER	53	Out	IPADDR	1024:65535	Any
Remote server response	TCP	NAMESERVER	53	In	IPADDR	1024:65535	ACK
Local server query	UDP	NAMESERVER	53	Out	IPADDR	53
Remote server response	UDP	NAMESERVER	53	In	IPADDR	53
Local zone transfer request	TCP	Primary	53	Out	IPADDR	1024:65535	Any
Remote zone transfer request	TCP	Primary	53	In	IPADDR	1024:65535	ACK
Remote client query	UDP	DNS client	1024:65535	In	IPADDR	53
Local server response	UDP	DNS client	1024:65535	Out	IPADDR	53
Remote client query	TCP	DNS client	1024:65535	In	IPADDR	53	Any
Local server response	UDP	DNS client	53	Out	IPADDR	53
Remote zone transfer request	TCP	Secondary	1024:65535	In	IPADDR	53	Any
Local zone transfer response	TCP	Secondary	1024:65535	Out	IPADDR	53	ACK

ALLOWING DNS LOOKUPS AS A CLIENT

The DNS resolver client isn't a specific program. The client is incorporated into the network library code used by network programs. When a hostname requires a lookup, the resolver requests the lookup from a DNS server. Most computers are configured only as a DNS client. The server runs on a remote machine. For a home user, the name server is usually a machine owned by your ISP.

As a client, the assumption is that your machine is not running a local DNS server; if it is, you should ensure that you need to actually run the name server. There's no need to run extra services! Each client lookup goes through the resolver and is then sent to one of the remote name servers configured in /etc/resolv.conf. In general, it's better to install the client rules even if a local server is used. You'll avoid some confusing problems that could otherwise crop up at some point.

These rules must be installed in the firewall tables before any other rules could successfully specify a remote host by name, rather than by IP address, unless the remote host had an entry in the local /etc/hosts file.

DNS sends a lookup request as a UDP datagram:

 NAMESERVER ="my.name.server"             # (TCP/UDP) DNS if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p udp \              -s $IPADDR --sport $UNPRIVPORTS \              -d $NAMESERVER --dport 53 \              -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p udp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $NAMESERVER --dport 53 -j ACCEPT $IPT -A INPUT  -i $INTERNET -p udp \          -s $NAMESERVER --sport 53 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

If an error occurs because the returned data is too large to fit in a UDP datagram, the DNS client retries using a TCP connection.

The next two rules are included for the rare occasion when the lookup response won't fit in a DNS UDP datagram. They won't be used in normal, day-to-day operations. You could run your system without problems for months on end without the TCP rules. Unfortunately, every so often your DNS lookups hang without these rules. More typically, these rules are used by a secondary name server requesting a zone transfer from its primary name server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              -d $NAMESERVER --dport 53 \              -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $NAMESERVER --dport 53 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $NAMESERVER --sport 53 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

ALLOWING YOUR DNS LOOKUPS AS A FORWARDING SERVER

Configuring a local forwarding name server can be a big performance gain. As shown in Figure 4.5, when BIND is configured as a caching and forwarding name server, it functions both as a local server and as a client to a remote DNS server. The difference between a direct client-to-server exchange and a forwarded server-to-server exchange is in the source and destination ports used. Instead of initiating an exchange from an unprivileged port, BIND initiates the exchange from its own DNS port 53. (The query source port is now configurable. In newer versions of BIND, the local server makes its request from an unprivileged port, by default.) A second difference is that forwarding server lookups of this type are always done over UDP. (If the response is too large to fit in a UDP DNS packet, the local server must revert to standard client/server behavior to initiate the TCP request.)

Figure 4.5. A DNS forwarding server lookup.

DNS BIND PORT USAGE

Historically, DNS servers used UDP port 53 as their source port when talking to other servers. This distinguished client traffic from server-initiated traffic because the client always uses a high, unprivileged port as its source. Later versions of BIND allow the server-to-server source port to be configurable and use the unprivileged ports by default. All examples in this book assume that BIND has been configured to use UDP port 53, rather than an unprivileged port, for server-to-server queries.

Local client requests are sent to the local DNS server. The first time, BIND won't have the lookup information, so it forwards the request to a remote name server. BIND caches the returned information and passes it on to the client. The next time the same information is requested, BIND finds it in its local cache (according to the record's time to live [TTL]) and doesn't do a remote request:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p udp \              -s $IPADDR --sport 53 \              -d $NAMESERVER --dport 53 \              -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p udp \          -s $IPADDR --sport 53 \          -d $NAMESERVER --dport 53 -j ACCEPT $IPT -A INPUT  -i $INTERNET -p udp \          -s $NAMESERVER --sport 53 \          -d $IPADDR --dport 53 -j ACCEPT 

If the lookup fails because of UDP packet size, the server will fall back to a TCP client-mode lookup. If the lookup fails because the remote server doesn't have the information, the local server will query the root cache server. Because of this, the client rules would need to allow DNS traffic to any server, rather than to the specific servers listed in the local configuration.

The alternative BIND configuration is to configure it not only as a forwarding server, but also as a slave to the remote servers specified in the BIND configuration file, named.conf. As a slave, the general client UDP rules aren't required.

Filtering the AUTH User Identification Service (TCP Port 113)

The AUTH, or identd, user identification service is sometimes used when sending mail or posting a Usenet article. Some FTP sites are also configured to require a resolvable AUTH lookup. For logging purposes, the server initiates an AUTH request back to your machine to get the account name of the user who initiated the mail or news connection. Table 4.2 lists the complete client/server connection protocol for the AUTH service. It's becoming much less common for this service to be required though, and therefore I wouldn't recommend running it on your servers.

Table 4.2. identd Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client query	TCP	ANYWHERE	113	Out	IPADDR	1024:65535	Any
Remote server response	TCP	ANYWHERE	113	In	IPADDR	1024:65535	ACK
Remote client query	TCP	ANYWHERE	1024:65535	In	IPADDR	113	Any
Local server response	TCP	ANYWHERE	1024:65535	Out	IPADDR	113	ACK

ALLOWING YOUR OUTGOING AUTH REQUESTS AS A CLIENT

Your machine would act as an AUTH client if you ran a mail or FTP server. Here are rules to allow your server to act as an AUTH client, should you choose to do so:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 113 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 113 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 113 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

FILTERING INCOMING AUTH REQUESTS TO YOUR SERVER

Whether or not you decide to offer the service, you will likely receive incoming requests for the service when you send mail.

If you run the identd server, the following rules enable incoming identd connection requests:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 113 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 113 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 113 \          --dport $UNPRIVPORTS -j ACCEPT 

If you decide not to offer the service, it's a good practice to reject the connection request to avoid waiting for the TCP connection timeout. This is the case only when an incoming packet is rejected rather than dropped, in these examples:

 $IPT -A INPUT -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 113 -j REJECT --reject-with tcp-reset 

Alternatively, you could use the accept rules but not run the identd server. The result would be the same: The TCP layer would return a TCP RST message to the sender.