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. 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.
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.
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.
|
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. As you can
see, the tcpd report precedes
the login report.
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. The final
line redirects output from find
into a new file and puts the command in the background with
&.
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
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 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.
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.
Syntaxchage 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.
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.
|
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. | 
|