Enabling Common UDP Services


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

  • Dynamic Host Configuration Protocol (DHCP)

  • Network Time Protocol (NTP)

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.

Table 4.13. traceroute Protocol

DESCRIPTION

PROTOCOL

REMOTE ADDRESS

REMOTE PORT / ICMP TYPE

IN/OUT

LOCAL ADDRESS

LOCAL PORT / ICMP TYPE

Outgoing TRaceroute probe

UDP

ANYWHERE

33434:33523

Out

IPADDR

32769:66535

Time exceeded (intermediate hop)

ICMP

ANYWHERE

11

In

IPADDR

Port not found (termination)

UDP

ANYWHERE

3

In

IPADDR

Incoming traceroute probe

UDP

ISP

32769:65535

In

IPADDR

33434:33523

Time exceeded (intermediate hop)

ICMP

ISP

Out

IPADDR

11

Port not found (termination)

ICMP

ISP

Out

IPADDR

3


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 REQUESTS

If 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."

Table 4.14. DHCP Message Types

DHCP MESSAGE

DESCRIPTION

DHCPDISCOVER

Client broadcast to locate available servers

DHCPOFFER

Server to client in response to DHCPDISCOVER with offer of configuration parameters

DHCPREQUEST

Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others; (b) confirming correctness of previously allocated address after, for example, system reboot; or (c) extending the lease on a particular network address

DHCPACK

Server to client with configuration parameters, including committed network address

DHCPNAK

Server to client indicating that client's notion of network address is incorrect (for example, client has moved to new subnet) or client's lease has expired

DHCPDECLINE

Client to server indicating that network address is already in use

DHCPRELEASE

Client to server relinquishing network address and canceling remaining lease

DHCPINFORM

Client to server, asking only for local configuration parameters; client already has externally configured address


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.

Table 4.15. DHCP Protocol

DESCRIPTION

PROTOCOL

REMOTE ADDRESS

REMOTE PORT

IN/OUT

LOCAL ADDRESS

LOCAL PORT

DHCPDISCOVER; DHCPREQUEST

UDP

255.255.255.255

67

Out

0.0.0.0

68

DHCPOFFER

UDP

0.0.0.0

67

In

255.255.255.255

68

DHCPOFFER

UDP

DHCP SERVER

67

In

255.255.255.255

68

DHCPREQUEST; DHCPDECLINE

UDP

DHCP SERVER

67

Out

0.0.0.0

68

DHCPACK; DHCPNACK

UDP

DHCP SERVER

67

In

ISP/NETMASK

68

DHCPACK

UDP

DHCP SERVER

67

In

IPADDR

68

DHCPREQUEST; DHCPRELEASE

UDP

DHCP SERVER

67

Out

IPADDR

68


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.

Table 4.16. NTP Protocol

DESCRIPTION

PROTOCOL

REMOTE ADDRESS

REMOTE PORT

IN/OUT

LOCALADDRESS

LOCAL PORT

Local client query

UDP

TIMESERVER

123

Out

IPADDR

1024:65535

Remote server response

UDP

TIMESERVER

123

In

IPADDR

1024:65535


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.




Linux Firewalls
Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort
ISBN: 1593271417
EAN: 2147483647
Year: 2005
Pages: 163
Authors: Michael Rash

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net