Chapter 3. Network Access Control

One of your most vital security tasks is to maintain control over incoming network connections. As system administrator, you have many layers of control over these connections. At the lowest level hardware you can unplug network cables, but this is rarely necessary unless your computer has been badly cracked beyond all trust. More practically, you have the following levels of control in software, from general to service-specific:

Network interface

The interface can be brought entirely down and up.

Firewall

By setting firewall rules in the Linux kernel, you control the handling of incoming (and outgoing and forwarded) packets. This topic is covered in Chapter 2.

A superdaemon or Internet services daemon

A superdaemon controls the invocation (or not) of specific network services, based on various criteria. Suppose your system receives an incoming request for a Telnet connection. Your superdaemon could accept or reject it based on the source address, the time of day, the count of other Telnet connections open... or it could simply forbid all Telnet access. Superdaemons typically have a set of configuration files for controlling your many services conveniently in one place.

Individual network services

Any network service, such as sshd or ftpd, may have built-in access control facilities of its own. For example, sshd has its AllowUsers configuration keyword, ftpd has /etc/ftpaccess, and various services require user authentication.

These levels all play a part when a network service request arrives. Suppose remote user joeblow tries to FTP into the smith account on server.example.com, as in Figure 3-1:

If server.example.com is physically connected to the network...

And its network interface is up . . .

And its kernel firewall permits FTP packets from Joe's host . . .

And a superdaemon is running . . .

And the superdaemon is configured to invoke ftpd . . .

And the superdaemon accepts FTP connections from Joe's machine . . .

And ftpd is installed and executable . . .

And the ftpd configuration in /etc/ftpaccess accepts the connection . . .

And joeblow authenticates as smith . . .

then the connection succeeds. (Assuming nothing else blocks it, such as a network outage.)

Figure 3-1. Layers of security for incoming network connections

System administrators must be aware of all these levels of control. In this chapter we'll discuss:

ifconfig

A low-level program for controlling network interfaces, bringing them up and down and setting parameters.

xinetd

A superdaemon that controls the invocation of other daemons. It is operated by configuration files, usually in the directory /etc/xinetd.d, one file per service. For example, /etc/xinetd.d/finger specifies how the finger daemon should be invoked on demand:

/etc/xinetd.d/finger: service finger {     server = /usr/sbin/in.fingerd      path to the executable     user = nobody                      run as user "nobody"     wait = no                          run multithreaded     socket_type = stream               a stream-based service }

Red Hat includes xinetd.

inetd

Another older superdaemon like xinetd. Its configuration is found in /etc/inetd.conf, one service per line. An analogous entry to the previous xinetd example looks like this:

/etc/inetd.conf: finger  stream  tcp  nowait  nobody  /usr/sbin/in.fingerd  in.fingerd

SuSE includes inetd.

TCP-wrappers

A layer that controls incoming access by particular hosts or domains, as well as other criteria. It is specified in /etc/hosts.allow (allowed connections) and /etc/hosts.deny (disallowed connections). For example, to forbid all finger connections:

/etc/hosts.deny: finger : ALL : DENY

or to permit finger connections only from hosts in the friendly.org domain:

/etc/hosts.allow: finger : *.friendly.org finger : ALL : DENY

We won't reproduce the full syntax supported by these files, since it's in the manpage, hosts.allow(5). But be aware that TCP-wrappers can also do IDENT checking, invoke arbitrary external programs, and other important tasks. Both Red Hat and SuSE include TCP-wrappers.

All recipes in this chapter come with a large caveat: they do not actually restrict access by host, but by IP source address. For example, we can specify that only host 121.108.19.42 can access a given service on our system. Source addresses, however, can be spoofed without much difficulty. A machine that falsely claims to be 121.108.19.42 could potentially bypass such restrictions. If you truly need to control access by host rather than source address, then a preferable technique is cryptographic host authentication such as SSH server authentication, hostbased client authentication, or IPSec.