The stateless UDP protocol is inherently less secure than the connection-based TCP protocol. Because of this, many security-conscious sites completely disable, or else limit as much as possible, all access to UDP services. Obviously, UDP-based DNS exchanges are necessary, but the remote name servers can be explicitly specified in the firewall rules. As such, this section provides rules for only three services:
traceroute (UDP Port 33434)On Unix and Linux systems, TRaceroute is a UDP service that causes intermediate systems to generate ICMP Time Exceeded messages to gather hop count information, and that causes the target system to return a Destination Unreachable message, indicating the endpoint of the route to the host. By the default deny policy, the firewall being developed in this chapter blocks incoming UDP TRaceroute packets because traceroute default ports are not explicitly enabled. As a result, outgoing ICMP responses to incoming traceroute requests won't be sent. Table 4.13 lists the complete client/server connection protocol for the traceroute service.
TRaceroute can be configured to use any port or port range. As such, it's difficult to block all incoming TRaceroute packets by listing specific ports. However, it often uses source ports in the range from 32,769 to 65,535 and destination ports in the range from 33,434 to 33,523. Because traceroute can be configured to use any source and destination port, the most effective way to block incoming traceroute is to block the outgoing ICMP messages generated in response. Symbolic constants are defined for TRaceroute's default source and destination ports: TRACEROUTE_SRC_PORTS="32769:65535" TRACEROUTE_DEST_PORTS="33434:33523" ENABLING OUTGOING traceroute REQUESTSIf you intend to use TRaceroute yourself, you must enable the UDP client ports. Note that you must allow incoming ICMP Time Exceeded and Destination Unreachable messages from anywhere for outgoing traceroute to work: $IPT -A OUTPUT -o $INTERNET -p udp \ -s $IPADDR --sport $TRACEROUTE_SRC_PORTS \ --dport $TRACEROUTE_DEST_PORTS -j ACCEPT Because traceroute is a less secure UDP service and can be used to identify your edge router, map your LAN, or attack other UDP services, allowing incoming TRaceroute isn't recommended. Accessing Your ISP's DHCP Server (UDP Ports 67, 68)DHCP exchanges, if any, between your site and your ISP's server will necessarily be local client-to-remote server exchanges. Most often, DHCP clients receive temporary, or semipermanent, dynamically allocated IP addresses from a central server that manages the ISP's customer IP address space. The server also typically provides your local host with other configuration information, such as the network subnet mask; the network MTU; the default, first-hop router addresses; the domain name; and the default TTL. If you have a dynamically allocated IP address from your ISP, you need to run a DHCP client daemon on your machine. It's not uncommon for bogus DHCP server messages to fly around your ISP's local subnet if someone runs the server by accident. For this reason, it's especially important to filter DHCP messages to limit traffic between your client and your specific ISP DHCP server as much as possible. Table 4.14 lists the DHCP message type descriptions, as quoted from RFC 2131, "Dynamic Host Configuration Protocol."
In essence, when the DHCP client initializes, it broadcasts a DHCPDISCOVER query to discover whether any DHCP servers are available. Any servers receiving the query may respond with a DHCPOFFER message indicating their willingness to function as server to this client; they include the configuration parameters that they have to offer. The client broadcasts a DHCPREQUEST message to accept one of the servers and to inform any remaining servers that it has chosen to decline their offers. The chosen server responds with a broadcast DHCPACK message, indicating confirmation of the parameters that it originally offered. Address assignment is complete at this point. Periodically, the client sends the server a DHCPREQUEST message requesting a renewal on the IP address lease. If the lease is renewed, the server responds with a unicast DHCPACK message. Otherwise, the client falls back to the initialization process. Table 4.15 lists the complete client/server exchange protocol for the DHCP service.
The DHCP protocol is far more complicated than this brief summary, but the summary describes the essentials of the typical client and server exchange. For more information, refer to the section "Choke as a Local DHCP Server (UDP Ports 67 and 68)," in Chapter 6. The following firewall rules allow communication between your DHCP client and a remote server: DHCP_SERVER="my.dhcp.server" # if you use one # Initialization or rebinding: No lease or Lease time expired. $IPT -A OUTPUT -o $INTERNET -p udp \ -s $BROADCAST_SRC --sport 68 \ -d $BROADCAST_DEST --dport 67 -j ACCEPT # Incoming DHCPOFFER from available DHCP servers $IPT -A INPUT -i $INTERNET -p udp \ -s $BROADCAST_SRC --sport 67 \ -d $BROADCAST_DEST --dport 68 -j ACCEPT # Fall back to initialization # The client knows its server, but has either lost its lease, # or else needs to reconfirm the IP address after rebooting. $IPT -A OUTPUT -o $INTERNET -p udp \ -s $BROADCAST_SRC --sport 68 \ -d $DHCP_SERVER --dport 67 -j ACCEPT $IPT -A INPUT -i $INTERNET -p udp \ -s $DHCP_SERVER --sport 67 \ -d $BROADCAST_DEST --dport 68 -j ACCEPT # As a result of the above, we're supposed to change our IP # address with this message, which is addressed to our new # address before the dhcp client has received the update. # Depending on the server implementation, the destination address # can be the new IP address, the subnet address, or the limited # broadcast address. # If the network subnet address is used as the destination, # the next rule must allow incoming packets destined to the # subnet address, and the rule must precede any general rules # that block such incoming broadcast packets. $IPT -A INPUT -i $INTERNET -p udp \ -s $DHCP_SERVER --sport 67 \ --dport 68 -j ACCEPT # Lease renewal $IPT -A OUTPUT -o $INTERNET -p udp \ -s $IPADDR --sport 68 \ -d $DHCP_SERVER --dport 67 -j ACCEPT $IPT -A INPUT -i $INTERNET -p udp \ -s $DHCP_SERVER --sport 67 \ -d $IPADDR --dport 68 -j ACCEPT Notice that DHCP traffic cannot be completely limited to your DHCP server. During initialization sequences, when your client doesn't yet have an assigned IP address or even the server's IP address, packets are broadcast rather than sent point-to-point. At the Layer 2 level, the packets may be addressed to your network card's hardware address. Accessing Remote Network Time Servers (UDP Port 123)Network time services such as NTP allow access to one or more public Internet time providers. This is useful to maintain an accurate system clock, particularly if your internal clock tends to drift, and to establish the correct time and date at bootup or after a power loss. A small-system user should use the service only as an Internet client. Few small sites have a satellite link to Greenwich, England; a radio link to an atomic clock; or an atomic clock of their own lying around. ntpd is the server daemon. In addition to providing time service to clients, ntpd uses a peer-to-peer relationship among servers. Few small sites require the extra precision ntpd provides. ntpdate is the client program and uses a client-to-server relationship. The client program is all that a small site will need. Table 4.16 lists only the client/server exchange protocol for the NTP service. There is rarely, if ever, a reason to run ntpd itself because that's the server component. If you must run the NTP server (as opposed to the client), do so in a chroot environment.
The ntpd startup script that is run at boot time uses ntpdate to query a series of public time service providers. The ntpd daemon is started after the server's reply. These hosts would be individually specified in a series of firewall rules: TIME_SERVER="my.time.server" # external time server, if any if [ "$CONNECTION_TRACKING" = "1" ]; then $IPT -A OUTPUT -o $INTERNET -p udp \ -s $IPADDR --sport $UNPRIVPORTS \ -d $TIME_SERVER --dport 123 \ -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p udp \ -s $IPADDR --sport $UNPRIVPORTS \ -d $TIME_SERVER --dport 123 -j ACCEPT $IPT -A INPUT -i $INTERNET -p udp \ -s $TIME_SERVER --sport 123 \ -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT Note that the previous rules are written for a standard client/server UDP communication. Depending on your particular client and server software, it's possible that one or both of them will use the NTP server-to-server communication model, with both the client and the server using UDP port 123. |