Back to Access Control

Let's retreat from this huge treacherous swamp called DNS and return to solid ground to continue our discussion of access control.

From the discussions above, it should be clear that I'm not a very great fan of using host names in access control lists. A case can be made for host names if they're local in some way - either listed in some local directory, or part of a DNS domain your local DNS server is authoritative for.

Still, I would recommend that access control lists contain IP addresses and networks only. This may be a nuisance to the administrator of the service, but at least it's effective.

Likewise, if your network service writes a log file that lists every access, you should always include the client's IP address even if a host name is available. Names can be faked if the attacker's timing is right. Spoofing the client IP address is a lot harder, at least for TCP based services (even though it is not entirely impossible, as we've seen above).

XXX: Suggestion - implement @LOCAL keyword that allows connections from local subnets and enable that rule by default. This makes servers more secure in their ``factory´´ configuration.

There is one fairly common type of access control, which is to give clients connecting from the same host the server is on special privilege. For instance, the RPC portmapper implements a registry of RPC services. Querying that information is usually permitted to any host; however adding or removing entries is restricted to clients running on the same host as the portmapper process itself.

There are several ways to verify that a request originated from the local host. One is to check the source address against the IP addresses of all network interfaces. This is clearly a tedious job (and the code to do that is probably not very portable either).

A second option is to require that processes wishing to perform these restricted operations always send them to the address 127.0.0.1. This is a special address on Unix machines which is attached to the so-called loopback device. If a process sends a network packet to 127.0.0.1, it will be delivered to the indicated port on the local machine. In addition, the packet's source address will be set to 127.0.0.1 as well. This means that the server could easily tell whether a request is from a local process by comparing the request's originating address to 127.0.0.1.

Still, this is not perfect. There's nothing that keeps an attacker sitting at a computer in some godforsaken corner of the world from sending a packet to your portmapper, setting the source address to 127.0.0.1. Unless your operating system silently discards this packet (it has all reason to do so, and some Unix operating systems enable this filtering by default!), the packet will be delivered to your portmapper, which thinks it's a legitimate local request.

To make a long story short: the most watertight way of enforcing that certain requests can only be sent by local processes is to use a second socket (often called control socket because it's dedicated to special control tasks), and restrict who can connect to it. With UDP and TCP sockets, you can do this by binding the socket to address 127.0.0.1 and port xyz. Then, a remote attacker can send packets to port xyz on your machine as much as he might - they won't be delivered to your service because the control socket will only accept packets with a destination address of 127.0.0.1.

An alternative solution is to use AF_LOCAL (aka AF_UNIX) sockets. This is a variety of sockets that work only locally, they are not accessible over the network. On several BSD variants and Linux, these sockets will even tell your application which user sent the request, allowing much more fine-grained access control! This class of sockets, and the stuff you can do with them, is covered in detail in chapter .