Account Auditing

The first step in securing a server is to determine what level of presence it must have. A server sitting on a network can be accessed in a variety of ways. Some methods require a username and password, and others do not require any form of authentication.

You can run network services that use a simple query-response scenario that does not require authentication. In this type of environment, a query is sent to a server, the server interprets the information, and when required, it passes information back to the client. Examples include DNS, DHCP, web server traffic, and PING. This type of access is controlled through managing services in the different run levels (see Chapter 3, "Booting and Shutting Down the Server"), the local account the service is run under, and firewall management (see Chapter 11, "Network Security Concepts").

Most services that are of interest to the end user require authentication. Examples are file sharing, remote logins, and access to secured websites. Numerous methods can be used to authenticate users. In this chapter, we concentrate on the authentication processes available on the local server.

Local access to a system is governed by the use of a username and password typically stored in /etc/passwd. Chapter 4, "User and Group Administration," introduced the concept of the /etc/passwd file as the repository of all user accounts that have access to a system. Listing 5.1 contains a copy of the /etc/passwd file from the DNS server installed in Chapter 2, "Updating the Server." If you recall, the DHCP-DNS software components were installed on top of a minimum SLES install. Referring to Listing 5.1, you may observe an interesting fact: A number of accounts created during the install are not required for the proper functioning of DHCP.

Listing 5.1. /etc/passwd File from the DHCP Server Pollux

 root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash daemon:x:2:2:Daemon:/sbin:/bin/bash lp:x:4:7:Printing daemon:/var/spool/lpd:/bin/bash mail:x:8:12:Mailer daemon:/var/spool/clientmqueue:/bin/false news:x:9:13:News system:/etc/news:/bin/bash uucp:x:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash games:x:12:100:Games account:/var/games:/bin/bash man:x:13:62:Manual pages viewer:/var/cache/man:/bin/bash at:x:25:25:Batch jobs daemon:/var/spool/atjobs:/bin/bash wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false ftp:x:40:49:FTP account:/srv/ftp:/bin/bash postfix:x:51:51:Postfix Daemon:/var/spool/postfix:/bin/false sshd:x:71:65:SSH daemon:/var/lib/sshd:/bin/false nobody:x:65534:65533:nobody:/var/lib/nobody:/bin/bash hart:x:1000:100:Hart:/home/hart:/bin/bash named:x:44:44:Name server daemon:/var/lib/named:/bin/false dhcpd:x:100:65534:DHCP server daemon:/var/lib/dhcp:/bin/false 

Echoing the policy that a system should contain only the minimum set of applications for its tasking, a proper account policy should dictate that unused accounts not be permitted on any system. There is no need for accounts such as games on a production server unless they are explicitly required. Such accounts, especially those with a UID in the reserved system space, should be removed. Though unlikely, they could provide access to the system if they are compromised. Because they are "standard" account names, modification to the default setup for these accounts could go undetected, allowing inappropriate access to the system. If the accounts are not present, the opportunity for exploit is not present either.

On a typical system, there are three types of accounts: local accounts with elevated access, local accounts used to run the various services, and unprivileged user accounts. In the remainder of this chapter, we examine how to further refine the access given to accounts.