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