Section 21.1. Objective 1: Perform Security Administration Tasks
21.1. Objective 1: Perform Security Administration TasksA good security policy includes such things as securing inbound network requests, verifying the authenticity of software packages to assure they are not hostile, and managing local security resources. This Objective details some of the most common of these activities that a system administrator performs. 21.1.1. TCP WrappersAs a Linux system operates in a networked environment, it is constantly "listening" for inbound requests from the network. Many requests come into Linux on the same network interface, but they are differentiated from one another by their port address, a unique numeric designator used by network protocols. Each type of service listens on a different port. Established port numbers and their corresponding services are listed in /etc/services. Here are some lines from that file: ftp 21/tcp ssh 22/tcp telnet 23/tcp smtp 25/tcp mail domain 53/tcp domain 53/udp http 80/tcp www www-http The first column lists the names of various services. The second column lists the port numbers assigned to the services and the protocol (TCP or UDP) used by the service. The optional third column and any other columns list alternative names for this service. For example, http might be referred to as www. Both refer to port 80. 21.1.1.1. On the attackAs the Internet has grown, the frequency of computer break-in attempts has kept pace. To gain entry to an unsuspecting host system, some intruders configure their systems to appear to target servers (that is, your servers) as trusted hosts. This could include a forged IP address or hostname, or the exploitation of aspects of the TCP protocol. Such attacks are carried out against multiple ports, sometimes in a port scan in which multiple ports at a single IP address are attacked in succession. In response to these threats, the TCP wrapper concept was created. The "wrappers" name comes from the idea that the services are "wrapped" in a protective layer. TCP wrappers consist of a single program, tcpd , which is run by inetd in place of actual services like ftpd or telnetd, among others. Tip: While inetd is not used on many modern Linux systems, the functionality of tcpd has been incorporated into many programs through the use of libwrap, the library version of tcpd. tcpd performs the following functions:
If a connection is approved, tcpd steps aside and allows the connection to be received by the true service. You could consider tcpd to be a gatekeeper of sorts, asking for identification at the door, and once satisfied, getting out of the way and allowing entry. By doing so, tcpd does not impact subsequent performance of the network connection. However, this aspect of tcpd prevents its use for services that handle multiple clients at one time, such has NFS and httpd. Instead, services protected by tcpd include single-client programs such as telnet and ftp. 21.1.1.2. Configuring inetd and tcpdChapter 20, "Objective 1: Perform Security Administration Tasks," examines inetd and its configuration file, /etc/inetd.conf. Without tcpd, a typical service configuration looks like this: telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd In this example, /usr/sbin/in.telnetd is the executable program that is called when a Telnet client tries to attach to the system on the Telnet port (23). With this configuration, in.telnetd responds directly and immediately to inbound requests. To enable the use of TCP wrappers for in.telnetd, it is specified that tcpd be called instead. Making this change yields this revised inetd.conf line: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd Now, /usr/sbin/tcpd is called in response to an inbound Telnet connection. tcpd interacts with only the initial network connection. It does not interact with the client process (remote Telnet), the client user (the remote person initiating the Telnet session), or the server process (the local in.telnetd). Since it is autonomous, tcpd has these properties:
21.1.1.3. tcpd access controltcpd provides a method of limiting access from external sources both by name and by address. After receiving a network request, tcpd first does its IP address and hostname checks. If those pass, tcpd then consults two control files, named hosts.allow and hosts.deny, for access control information. These are text files that contain rules (one per line) against which incoming network connections are tested:
If no matches are made in either of the files, then the connection is allowed. This implies that missing hosts.allow and hosts.deny files means that no access control is implemented. The form of the rules in these two files is simple: service_list : foreign_host_list The service list is made up of space-separated program names, such as in.telnetd and in.ftpd. The foreign host list can contain special codes, which can be used on both sides of the colon:
To enable access from systems in domain otherdom.com, except its web server, and to allow access from systems in network 192.168.100.0, you could put the following rules in /etc/hosts.allow: ALL: .otherdom.com EXCEPT www.otherdom.com ALL: 192.168.100. Note that the leading and trailing dots are significant. .otherdom.com matches any system in that domain, such as ftp.otherdom.com and lab1.otherdom.com. The address rule with 192.168.100. matches all of the addresses on that network, including 192.168.100.1, 192.168.100.2, 192.168.100.100, and so on. Tip: DNS is not completely reliable, so relying on it for access control should be avoided if at all possible. Use IP addresses whenever you can. To reject everything else, put the following in /etc/hosts.deny: ALL: ALL This rule denies ALL services from ALL machines anywhere. Remember that matches found in hosts.allow cause the search to stop.
21.1.1.4. tcpd loggingWhen tcpd is enabled, it logs to the authpriv facility in syslogd. (syslog and its configuration are described in Chapter 18, "Objective 3: Configure and Use System Log Files to Meet Administrative and Security Needs.") Check your /etc/syslog.conf file to confirm where this facility will be logged on your system. For example, this /etc/syslog.conf configuration line puts all authpriv messages in /var/log/secure: authpriv.* /var/log/secure Most system service daemons will do some logging on their own. For example, in.telnetd writes the following line to authpriv as the result of a Telnet connection: Feb 8 17:50:04 smp login: LOGIN ON 0 BY jdean FROM 192.168.1.50 When tcpd is listening to the Telnet port in place of in.telnetd, it logs the request first, does its verifications, and then passes the connection on to in.telnetd, which then starts a login process as before. In this case, /var/log/secure looks like this: Feb 8 17:53:03 smp in.telnetd[1400]: connect from 192.168.1.50 Feb 8 17:53:07 smp login: LOGIN ON 0 BY jdean FROM 192.168.1.50 The first line was logged by tcpd. It indicates that a connection was received from 192.168.1.50 bound for the in.telnetd daemon. The smp on these example lines is the name of the host making the log entries. As you can see, the tcpd report precedes the login report. 21.1.2. Finding Executable SUID FilesThe SUID capability of the Linux ext2 filesystem was covered in Chapter 6, "Objective 5: Use File Permissions to Control Access to Files." In that section, the SUID property was described as both a security enhancement and a security risk. It can be considered an enhancement because it allows administrators to grant superuser privileges to specific, trusted programs that may be executed by anyone on the system. The example given is passwd, which needs special access to manipulate the shadow password file (/etc/shadow). Without using the SUID property, everyone on the system would need administrative rights to change his own password, which is clearly undesirable. It is also mentioned that an SUID capability that is granted unwisely can be a security risk, and all applications of SUID must be considered carefully. The reason for this concern is that the potential exists for an attacker to exploit the superuser privilege on an SUID file. For example, if the attacker is able to somehow overwrite the contents of passwd, she could effectively gain superuser access to the system by running a passwd of her own design that changes passwords, adds new accounts, or something else shady. For systems on corporate networks and on the Internet, it is common to minimize the number of SUID files on the system and to regularly monitor the known list of programs for changes. In the event that a new SUID program is found that was not legitimately created or if an attribute of a known file changes, it could be a warning that system security has been compromised. The find command can perform the searches for attributes such as SUID (see the "Applying commands recursively through a directory tree" section in Chapter 5 for details on find). In this example, a find command that searches the entire filesystem for files that have the SUID bit set is constructed; it avoids the /proc filesystem (kernel information) to prevent permission problems. The example generates verbose output similar to ls -l to log detailed information about the SUID files found: # find / \ > -path '/proc' -prune \ > -or \ > -perm -u+s \ > -ls The first line calls the find program and indicates that the search should begin at the root directory /. The second line specifies a -path directive to match /proc utilizing the -prune modifier. This eliminates (or prunes) the /proc directory from the search. The next line joins the -path directive to the -perm (permissions) directive with a logical -or, skipping execution of the -perm directive when -path matches /proc. The -perm directive uses a permission mode of -u+s, which indicates "match SUID." The next line with the -ls prints each match with a format similar to ls -l. The result of this command is a listing of files on your system with the SUID property; the following is just a snippet of what that output would look like: 32773 72 -rwsr-xr-x 1 root root 68508 Feb 24 2003 /bin/mount 32823 28 -rwsr-xr-x 1 root root 28628 Jan 24 2003 /bin/ping 32866 100 -rwsr-xr-x 1 root root 95564 Feb 18 2003 /bin/su 33199 32 -rwsr-xr-x 1 root root 30816 Feb 24 2003 /bin/umount As you can see, the s bit is set on the user of the file, indicating SUID. Keeping this complete list in a file can be useful, because you'll want to check your system periodically for changes. 21.1.3. Verifying PackagesPackage management systems provide a convenient method of managing software on Linux systems. The RPM not only can install package files but also can provide for the verification of package files and software installed on your system. 21.1.3.1. Checking installed packagesIf an intruder were able to penetrate your system, it is likely that he would attempt to modify or replace executable files to grant himself special abilities. To check for such files, the verification option of the package manager can be used to check installed files. With RPM, it is possible to verify the installed files contained in a specific package like this: # rpm -V apache S.5....T c /etc/httpd/conf/httpd.conf .......T c /etc/httpd/conf/srm.conf missing /home/httpd/html/index.html missing /home/httpd/html/poweredby.gif In this example, rpm is reporting that four files do not match the original installed configuration. None is an executable file, and all are easy to explain, so no intruder is suspected here. If an executable file does turn up in the list, you may wish to investigate. For example: # rpm -V XFree86-I128 S.5....T /usr/X11R6/bin/XF86_I128 This shows that the file XF86_I128 is not the same as the one originally installed. Unless you know why the file has changed, corrective action may be necessary to maintain security. In this case, the file in question is an X Server binary that was intentionally upgraded to a newer version than that supplied in the original package. Again, this is an expected result. The output from rpm -V consists of an eight-character string, an optional c (indicating that the file is a configuration file), and the filename. Each column in the result string contains a dot when an attribute has not changed. The output codes listed in Table 21-1 can replace dots to indicate discrepancies.
It can be helpful to monitor all of the packages on your system and track changes to the resulting list on a regular basis. To check all installed packages, use the a verification option as follows: # rpm -Va S.5....T c /etc/exports S.5....T c /etc/hosts.deny S.5....T c /etc/printcap S.5....T c /etc/services .M...... /root S.5....T c /usr/share/applnk/Multimedia/aktion.kdelnk S.5....T c /etc/info-dir ..5....T c /etc/mime.types S.5....T c /etc/httpd/conf/httpd.conf .......T c /etc/httpd/conf/srm.conf missing /home/httpd/html/index.html missing /home/httpd/html/poweredby.gif S.5....T c /etc/named.conf S.5....T c /var/named/named.local .M...... /dev/hdc .M...... /dev/log .M?....T /dev/printer .M...... /dev/pts ......G. /dev/tty0 (... list continues ... ) This list will be large. As your system is configured, upgraded, and modified, you're likely to change many of the files from their original configurations. The important part is being able to explain changes that occur, particularly on executable files. 21.1.3.2. Checking packages prior to installationFrom time to time, you may obtain precompiled software from various sources to add to your system. This may include updated versions of software you already have or new software you don't yet have. It's always best to obtain package files from a trusted source, such as the manufacturer or a well-known distributor. However, as an added safeguard. you may wish to verify that the packages you obtain have not been tampered with or otherwise corrupted. To check an RPM file, use the --checksig option: # rpm --checksig --nopgp fileutils-4.0-1.i386.rpm fileutils-4.0-1.i386.rpm: size md5 OK The size md5 OK status indicates that size and md5 checksum tests passed for the .rpm file. This means that the size of the file and its checksum matched expected values. (A checksum is a calculated value based on the contents of a file (or other piece of information) used as a sort of "fingerprint.") A NOT OK status could indicate a problem. In this example, the --nopgp option is also used to ignore PGP signatures, which may be necessary for you unless you have PGP installed and configured on your system. 21.1.4. SGID WorkgroupsThis Objective requires an understanding of the SGID mode bit and its application to a directory. When SGID is set on a directory, new files created within that directory are assigned the same group ownership as the directory itself. This is explored in detail in Chapter 6, "Objective 5: Use File Permissions to Control Access to Files." If you're currently preparing for Exam 102, be sure to refer back to Part I for a refresher on SGID. 21.1.5. Password ManagementWhen a user calls saying she's forgotten her password, you need to use the superuser account to create a new one for her: # passwd bsmith Changing password for user bsmith New UNIX password:(new password) Retype new UNIX password:(new password again) passwd: all authentication tokens updated successfully Resist the temptation to use an easily guessed password, even if you expect the user to change it immediately. Linux offers you the ability to set expiration dates on passwords. This is done to limit their lifetime, which presumably enhances security by forcing password changes. If a password has been discovered or broken, the password change will eventually correct the security lapse. The chage command configures password aging parameters on a per-user basis when using password aging. The following parameters are defined:
|
EAN: 2147483647
Pages: 257