Post-Installation Security Procedures

Some other networking programs do not run through inetd. These are mostly daemons that run through the rc files at system startup. When not needed, these daemons can be disabled by editing the system startup files. The mount daemon, for example, is the daemon that enables people to mount file systems from our Linux machine. If we want to disable the mount daemon completely, we should edit the rc files so the daemon will not run after the system reboots. If we want to let selected clients in our network work with parts of our file systems, we can run mountd with a restricted set of rules that will enforce our policy on the client. This will give the client a limited access to our system.

To configure the mountd restrictions, we should edit the /etc/exports file. The /etc/exports file is the file the mount daemon consults before it gives permissions to the client to mount our local file system. Not only can we limit the clients that can mount our local file systems, but we can also enforce options such as read-only, nosuid and more on the authorized clients.

Another often used program that listens for connections on the network is the lpd. The line-printer daemon opens port 515 to listen for connections. We can edit the /etc/hosts.equiv or the /etc/hosts.lpd files to disable and enable the service for some clients. With the port# argument, we can tell lpd to listen on a different port than 515; this is a good trick as long as it is not the only step we are taking to secure the service.

The X Window System is a network-based window system that enables other clients to send their application's display to our server. These applications can be dangerous since they can read our keystrokes and view the display of other applications on our X server. If we don't need the X networking support, we can run the X server with the option -nolisten tcp set. This option causes the X server to not listen to port 6000, and thus not accept connections from any client. To use this option, simply add it to the clientargs variable in the /usr/X11/bin/startx script.

If we need to display output from other machines on our X server, we can use the xhosts and xauth commands to limit the machines and users that can run applications on our X server. The xhost command is very simple: xhost + hostname or xhost - hostname.

The + sign indicates the client has permission to run applications on our X server, using the -display server:0.0 option from the command line on the client machine. The - sign indicates the client does not have permission to run applications on our server, and if a user on the client machine tries to run an X application on our server, he will get an error message indicating he is not authorized to do so.

DNS servers must be secured. There is a huge amount of information people can get easily, just by transferring our zone file to their systems. Sometimes our zone files contain the inner network addresses of our systems, router addresses and more.

BIND-8 has many neat security features. The latest version of BIND 8 is 8.2.1, and I recommend upgrading name servers to this version. It contains support of access lists (ACL) for zone query and zone transfers. In the BIND configuration file we can limit the machines that can transfer to each and every zone. One more thing we can do is to put our local network zone, if any, in a secure mode, so that named will only answer queries of names belonging to that zone to clients in our local network. There are built-in ACL names such as any and none which we can use in the named configuration file. One big advantage of the new bind versions is the logging. With version 8 we can tweak the logs to show anything we would like to see. And when it comes to security, the log is a very important issue. Listing 1 is an example of a configuration file allowing only local hosts from network 192.168.1/24 to query all zones; it also allows queries from anywhere on the network to query the outside zones only. One more thing to look at in this named configuration file is that zone transfers are only allowed to two other machines on the network and only for the outside zone.

Listing 2

We can play with these new features of named and disable “dns relaying” by allowing the world to query only zones for which our name server is authoritative, and enabling other queries only from our local networks. This kind of setting will disable the possibility that someone from the Internet will send recursive requests to our server.

Another nice feature in the BIND 8 is that the named can run in a chrooted environment; this means that if a hacker exploits the named, it will not have access to all of the file system, but to a very small part of it. To make named run in a chrooted environment, we can use the -t option from the command line.

The last thing about the DNS is we can make the name daemon run as a non-root user. This is a very good thing to do as in many other programs as in addition to named. By running a process as root, we actually give the process the permission to do anything in our system; we can accept that as long as the process does only what it was programmed to do in the first place. However, if someone can make this process run arbitrary code, for example, then this arbitrary code will run as root. This means any bug or buffer overflow found in this process can give the hacker a root privilege. Since we don't want to make the hacker's life easier, we can have the named run as a different user.

To accomplish this task, we first add the appropriate user and group to the system. Than we use the -u and -g options from the command line, to specify userid and groupid to the named process. [More discussion of “Securing Name Servers on UNIX” can be found in the article of that name in this issue.]