Book: LPI Linux Certification in a Nutshell Section: Chapter 21. Security (Topic 1.14)
### 21.1 Objective 1: Perform Security Administration Tasks A 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 Wrappers As 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:
    # /etc/services:
    #
    ftp        21/tcp
    ssh        22/tcp
    ssh        22/udp
    telnet     23/tcp
    smtp       25/tcp
    www        80/tcp
    www        80/udp
The left column lists various services that could be provided by the system.[1] The right column lists the port numbers assigned to the services and the protocol (TCP or UDP) used by the service. For example, the telnet service uses port 23, and web servers use port 80. When a browser wishes to contact the web server on a specific IP address, it attempts to attach to port 80 at that address. Likewise, Telnet clients attach to port 23. If the appropriate service is listening, it responds and a new communications session is established. Linux networking software consults this table to determine port numbers. [1] Just being listed doesn't imply that a service is really active. ##### 21.1.1.1 On the attack As 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 where 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 called in place of actual services like ftpd or telnetd, among others. tcpd performs the following functions: Responds to network requests and does security tests on the information provided in the connection message Consults local configuration files ( /etc/host.allow and /etc/host.deny) to restrict access Provides detailed logging via the `authpriv` facility of syslog for connection requests 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 tcpd Section 20.1 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: Application independence The same small tcpd program can be used on many different network services. This simplicity makes tcpd easy to install, configure, and upgrade. Invisible from outside Anyone trying to gain access has no direct evidence that tcpd is in use.[2] [2] However, it is customary for tcpd to be in use by default on modern Linux installations. ##### 21.1.1.3 tcpd access control tcpd 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: /etc/hosts.allow tcpd consults this file first. When an incoming network request matches one of these rules, tcpd immediately grants access by passing the network connection over to the server daemon. If none of the rules are matched, the next file is consulted. /etc/hosts.deny This file is consulted second. If a network request matches one of these rules, tcpd denies access to the service. 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: ALL This is the universal wildcard, which always matches all requests. When used on the left side of a rule, `ALL` indicates every service protected by tcpd. On the right side, it means all possible hosts. EXCEPT In the context of:
    list1 EXCEPT list2
this operator matches anything that matches `list1` unless it also matches `list2`. LOCAL This wildcard matches machines on the local network -- any host whose name does not contain a dot character. KNOWN This matches with a successful DNS lookup. Dependent on DNS servers. PARANOID This wildcard matches when a hostname lookup returns a different address than the inbound network connection is offering. tcpd must be compiled with the -DPARANOID option to enable this capability. By default, connections in this category are dropped prior to testing against the rules in the control files. UNKNOWN Opposite of `KNOWN`. When a DNS lookup for a host fails, this wildcard matches. This could happen for valid reasons, such as a DNS server failure, so use this one with caution. To create a system closed to all remote systems except those on the local network, the following line is placed in /etc/hosts.allow :
    ALL: LOCAL
This rule allows connections to `ALL` services from `LOCAL` machines. If `LOCAL` does not match, this single line in /etc/hosts.deny is tested:
    ALL : ALL
This rule denies `ALL` services from `ALL` machines anywhere. Remember that matches found in hosts.allow cause the search to stop, so that `LOCAL` machines are not tested against the rules in hosts.deny. 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 change the /etc/hosts.allow file from the previous example to:
    ALL: LOCAL
    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.
## On the Exam Remember that hosts.allow is evaluated prior to hosts.deny. This means that if a match occurs in hosts.allow, the connection succeeds and any potential matches from hosts.deny are ignored. Also remember that, in the absence of control, file access is permitted. Keep in mind that services that are not in use may have control settings. A configuration in /etc/hosts.allow or /etc/hosts.deny does not imply that listed services are actually running on the system. Evaluate the complete setup of inetd.conf, hosts.allow, and hosts.deny when answering questions about tcpd.
##### 21.1.1.4 tcpd logging When tcpd is enabled, it logs to the authpriv facility in syslog (syslog and its configuration are described in Section 7.3.) 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.[3] As you can see, the tcpd report precedes the login report. [3] The `smp` on these example lines is the name of the host making the log entries. #### 21.1.2 Finding Executable SUID Files The set user ID (SUID) capability of the Linux ext2 filesystem was covered in Section 4.5. 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 lpr, which needs special access to manipulate the print spools. Without using the SUID property, everyone on the system would need administrative rights to use lpr, 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 lpr, he could effectively gain superuser access to the system by running an lpr of his own design that changes passwords, adds new accounts, or something else shady and unrelated to printing. 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 Section 3.1 for details on find). In this example, a find command is constructed that searches the entire filesystem for files that have the SUID bit set; it avoids the /proc filesystem (kernel information) to prevent permission problems. The example generates verbose output using ls to log detailed information about the SUID files found:
    # find /  \
          -path '/proc' -prune  \
          -or  \
          -perm -u+s  \
          -exec ls -l {} \;  \
          >  /usr/local/etc/suid_list &
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 -`exec` directive indicates what find is to do for each SUID file found. Here, the ls -l command is invoked and fed the response from find to verbosely list the SUID file's attributes. The curly braces (`{}`) are replaced with the matched text once for each match.[4] The final line redirects output from find into a new file and puts the command in the background with `&`. [4] Note that a backslash in front of the semicolon is required with -exec. Admittedly, find can get a bit long in the tooth but is nevertheless powerful. 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:
    -rwsr-xr-x 1 root root  33120 Mar 21  1999 /usr/bin/at
    -rwsr-xr-x 1 root root  30560 Apr 15  1999 /usr/bin/chage
    -rwsr-xr-x 1 root root  29492 Apr 15  1999 /usr/bin/gpasswd
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 Packages Package management systems provide a convenient method of managing software on Linux systems. The Red Hat Package Manager (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 packages If an intruder were able to penetrate your system, it is likely that she would attempt to modify or replace executable files in order to grant herself 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.

##### Table 21-1. RPM Verification Codes

Dot Code | Description
--- | ---
    5
| The MD5 checksum, a sort of "fingerprint" for the file, is different.
    S
| The file size has changed.
    L
| Symlink attributes have changed.
    T
| The file's modification time (or mtime) has changed.
    D
| Device file has changed.
    U
| The file's user/owner has changed.
    G
| The file's group has changed.
    M
| The file's mode (permissions and file type) has changed.
    ?
| Unknown or unexpected result.
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 installation From 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[5] matched expected values. 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. [5] A checksum is a calculated value based on the contents of a file (or other piece of information) used as a sort of "fingerprint." #### 21.1.4 SGID Workgroups This Objective requires an understanding of the SGID (set group ID) 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 Section 3.5. 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 Management When a user calls saying he's forgotten his password, you need to use the superuser account to create a new one for him:
    # 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: Minimum password age The minimum number of days between password changes. Maximum password age The maximum number of days between password changes. The user is forced to change his password before using the account after the number of days has elapsed without a password change. Last password change The date on which the password was last changed. Password expiration warning The number of days' warning that are issued in advance of a password expiration. Password inactive The number of days of inactivity the system allows before locking a password. This is an automated way of avoiding stale but valid user accounts. Account expiration date The date on which an account expires.
chage |
#### Syntax
    chage user
    chage [options] user
#### Description In the first form without options, chage is interactive. In the second form, chage may be used with parameters specified via options on the command-line. #### Options -d lastday lastday is the number of days between the last password change and January 1, 1970. As an administrator, you may need to modify this value. lastday may also be specified as a date in /MM/DD/YY format. -E expiredate expiredate is a date on which an account will no longer be accessible. Like lastday, it is stored as the number of days since January 1, 1970, and may be specified as a date in /MM/DD/YY format. -I inactive inactive is the number of days of inactivity allowed after a password expires before an account is locked. A value of disables the inactive feature. -m mindays mindays is the minimum number of days between password changes. This prevents a user from making multiple password changes at one time. -M maxdays maxdays is the maximum number of days that a password remains valid. This forces users to change their passwords periodically. -W warndays warndays is the number of days before a password expires that the user is warned of the upcoming expiration. #### Examples User bsmith is to be provided with a password that cannot be changed more than once every 2 days, that must be changed at least every six months (180 days), that retains its default 7-day warning interval, that is set to lock after three weeks' of inactivity, and that expires altogether at the end of 2002. The following interactive session with chage makes these settings:
    # chage bsmith
    Changing the aging information for bsmith
    Enter the new value, or press return for the default

            Minimum Password Age [0]: 2
            Maximum Password Age [99999]: 180
            Last Password Change (MM/DD/YY) [02/10/00]:<return>
            Password Expiration Warning [7]: <return>
            Password Inactive [0]: 21
            Account Expiration Date (MM/DD/YY)
                 [12/31/69]: 12/31/2002
This creates the same settings using the command line:
    # chage -m 2 -M 180 -I 21 -E 12/31/2002 bsmith
If you wish to set these parameters for groups of users or everyone on the system, you could create a simple shell script to loop over all users in /etc/passwd and run the chage command with options. The information on password aging is stored in either the /etc/passwd file, or if shadow passwords are enabled, in the /etc/shadow file. #### 21.1.6 The Secure Shell Among the security issues surrounding networked computer systems is the problem of plain text communications. Much of the information traveling between systems is simply sent as text, including passwords at login time. If someone were able to capture the network packets of your communications without your knowledge, your passwords and other information could be compromised. While this may seem like a remote possibility, such activity has become much easier than it was just a few years ago, because low-cost hardware can be used to make a network analyzer for just this purpose. In 1995, a researcher developed an application intended to replace some of the plain text communications programs such as telnet, rlogin, and rsh. The new application was titled Secure Shell, or SSH. This application may also be used to secure other communications such as the X Window System, though such use is beyond the requirements for the LPIC Level 1 exams. The following tutorial explains how to acquire, compile, install, and configure ssh for Linux, so that you can use it in place of Telnet.[6] [6] Licensing restrictions apply to the commercial use of SSH. Verify your intended use and license type. While you may find a precompiled package, it is a simple matter to compile and install ssh if you have a C compiler. SSH is available at http://www.ssh.org/ and at many mirror (copy) sites around the world. Using your browser or FTP client, download the latest version to your system and extract the tarball with the following command:
    # tar zxvf ssh-2.0.13.tar.gz
The z option to tar instructs it to invoke gzip to decompress the archive before reading it. You now have a directory hierarchy called ssh-2.0.13 (your version may be different). You should cd into the new directory and examine the documents you find there, then configure, compile, and install the software:
    # cd ssh-2.0.13
    # ./configure
    # make
    # make install
If you have a recent compiler such as gcc, you shouldn't have any difficulty with these steps. Configuration and compilation present typical output, so you won't see any surprises there if you've compiled software from source before. The installation, however, generates keys for the software to use in its encrypted communications. This process may take a few extra minutes. Once SSH is installed, you may need to add /usr/local/bin and /usr/local/sbin to your `PATH` or use full pathnames. To enable login from remote systems using SSH, you must start sshd, which may be done simply by issuing the following command:
    # sshd
Note that you do not need to put this command in the background, as it handles this detail itself. Once the sshd daemon is running, you may connect from another SSH-equipped system:
    # ssh mysecurehost
The default configuration should be adequate for basic use of SSH. One common problem you may encounter is that a system may not be specifically listed by a DNS server. In this case, comment out (that is, put `#` in front of it using a text editor) the following line from /etc/ssh/sshd2_config:
    RequireReverseMapping           yes
This eliminates the DNS lookup and allow your configuration to function. If your systems are configured with a proper DNS server, this step should not be necessary. If you have difficulty with SSH, examine the log for syslog facility auth, which is most likely /var/log/messages, for information.
## On the Exam The Secure Shell (SSH) is an involved and highly configurable piece of software, and detailed knowledge of its setup is not required. However, SSH is an important part of the security landscape. Be aware that all communications using SSH are encrypted using public/private key encryption, which means that plain text passwords are unlikely to be compromised.