Chapter 24
Host Security
|
|
|
| |
|
 |
| In this chapter: |
| |
|
| |
 |
Enacting a sound security policy and educating users about security issues
|
|
Creating secure passwords and implementing password aging
|
|
Determining file permissions and employing them for greater security
|
|
Employing user groups
|
|
Designing a practical backup strategy
|
|
Constructing file permissions with the SuSEconfig mechanism
|
|
Monitoring your file system with Tripwire
|
|
| |
|
|
| |
Chapter 23 offered a brief introduction to several
security issues. In this chapter we will discuss host
security, which means we will explore the options for optimizing
internal security for a single, isolated machine. We will not cover
network security here. You'll find details on network security in
Chapter 26
.
The purpose of this chapter is to learn how to
|
| |
|
Build a set up that only allows the root user to change system parameters;
|
|
Ensure that all users respect each other's privacy
|
|
Prevent users from posing as another user
|
|
Preventing anyone from gaining root access without proper authentification and authorization
|
|
Restrict special services (such as dialing out) to authorized users
|
|
| |
To achieve these goals, we will cover these points:
|
| |
|
Setting and monitoring file permissions
|
|
Assigning proper passwords for all types of users
|
|
Organizing users into groups according to type of interaction and permission requirements
|
|
Educating users about security issues
|
|
| |
The last point is more of a social issue than a technical concern. It
is very important that all system users are aware of security
policies, appropriate access, and preventive measures. A single weak
point may be enough to allow an intruder to come into the
system. Typical weak points include an easy to guess password, a
binary in a user's home with incorrect permissions, or a network
service that allows the user unauthorized access.
|
| 24.1 | Security Policies |
| |
Crackers often use regular user accounts as the first hop into a
system. Once they have user access, they use so-called
rootkits to gain root access.
If you are responsible for a multi-user site, it is especially
important to design, implement, and clearly communicate a security
policy for your users. Make it mandatory that your users read,
thoroughly understand, and follow it.
These are the minimum points your security policy should cover:
|
| 24.1.1 | Passwords |
| |
Passwords are one of the most important security features used today.
It is important for both you and your users to have secure,
hard to guess passwords. Tools to guess passwords are freely available
and used by crackers in break in attempts. A good password should:
|
| |
|
Contain at least eight characters,
|
|
Not be a valid word or any combination of words in any language,
|
|
Not a name, pet name, or anything similar,
|
|
Have no connection to the owner of the account,
|
|
Contain upper and lower case characters,
|
|
Contain special characters and/or numbers,
|
|
Change frequently.
|
|
| |
|
 |
The most damaging mistake is to use regular words
which can be found in a dictionary, use a friend's name, a nick name,
etc. These kinds of passwords are the easiest to guess. Crackers use
dictionaries to guess passwords. This can be done off-line and
automated.
|
| |
|
 |
Remember that passwords can contain any character, even a
space is allowed. A good way to develop a hard to guess (but easy to
remember) password is to come up with a phrase that's easy to remember
and use the first few characters of every word in the phrase to build
the password. For example, with the phrase ``Zaphod Beeblebrox is
President of the Galaxy'', you could build a password such as
ZBiPotGa. So far, so good. Now substitute some special
characters for letters, and you have a reliable password:
Z8iPo%#Ga.
|
| |
Don't force users to create passwords that are too
cryptic. Often, they'll jot them down out of frustation and fear that
they will forget them. A password has to be easy to remember. Nothing
is worse than walking by a user's desk and finding a 'Post It' on
their monitor with their password written on it as a handy reminder to
them-and the world. Passwords have to be kept secret or they are of no
use.
Show your users how to change their password. It's a simple task
and every user should be able to do it. It's advised that they actually change the
password on a regular schedule. The shadow password system can enforce
this portion of the policy by using password aging.
|
| 24.1.2 | Password Aging |
| |
To enable password aging, you have to edit the file
/etc/shadow. This file contains a line for each user who has a
system account. Each user entry contains nine files, separated by
colons (:):
|
| |
|
Login name
|
|
Encrypted password
|
|
Days since Jan 1, 1970 that password was last changed
|
|
Days before password may be changed
|
|
Days after which password must be changed
|
|
Days before password is to expire that user is warned
|
|
Days after password expires that account is disabled
|
|
Days since Jan 1, 1970 that account is disabled
|
|
A reserved field
|
|
| |
The password aging information can be changed by either editing this
file or with the -x, -n, -w, and -i
options of the passwd command. The -x option is used to
set the maximum number of days a password remains valid. After the
maximum number of days has been reached, the system requires that the
password be changed. The -n option is used to set the minimum
number of days before a password may be changed. The user will not be
permitted to change the password until the minimum number days have
elapsed. The -w option is used to set the number of days that
the system will warn the user before their password expires. The
warning occurs the specified number of days before the expiration,
alerting the user as to how many days until the password is set to
expire. The -i option is used to disable an account after the
password has expired for a number of days. After a user account has
had an expired password for the days specified under inactive, the
user may no longer sign on to the account.
The preferred way is to use passwd for this task. You should call
it every time after you add a user to your system. If you use YaST
to administer your users, you can automate this task. YaST checks to see if a
executable (script or binary) /usr/sbin/useradd.local exists
and executes it after a user has been added, with the user name as
argument.
Unfortunately YaST doesn't unlock the /etc/shadow file
prior to calling the script, so passwd will fail if it's
called within /usr/sbin/useradd.local. Fortunately, we're
on a Linux system, so there's a work around. The shadow
file is locked by creating /etc/shadow.lock. If we
temporarily rename this file to something else, then call
passwd and replace the name, we can get the task
done. It's tricky, but it works. In the following example a small
script is shown which enables password aging for every account created
with YaST:
|
| | #!/bin/sh
#
# /usr/sbin/useradd.local
#
#
# rename /etc/passwd.lock, if it exists
#
if [ -f /etc/shadow.lock ] ; then
mv /etc/shadow.lock /etc/shadow.lck
fi
#
# set max password age to 14 days, give a three day warning
# and a 4 day grace period
#
/usr/bin/passwd -x 14 -w 3 -i 4 $1
#
# rename lockfile back to old value
#
if [ -f /etc/shadow.lck ] ; then
mv /etc/shadow.lck /etc/shadow.lock
fi
|
| |
You can review the account status with passwd -S. The status
information consists of 6 parts. The first part indicates if the user
account is locked (L), has no password (NP), or has a usable
password (P). The second part gives the date of the last password
change. The next four parts are the minimum age, maximum age, warning
period, and inactive period for the password:
|
| | # passwd -S bb
bb P 06/16/99 0 14 3 4
| | | | | | |
| | | | | | +-- 4 day grace period
| | | | | +---- 3 day warning
| | | | +------ change password every two weeks
| | | +--------- minimum age before change
| | +--------------- changed password at June 16 1999
| +-------------------- password id valid
+---------------------- user name
|
| |
|
| 24.1.3 | Permissions |
| |
Every user is responsible for the permissions set for his or her
data. Linux provides the permissions mechanism to protect data from
access by other users. This is your primary tool for maintaining privacy and
security, so we will discuss this in more detail.
Here is a quick run down of Unix-style ownership and permissions policies:
|
| | Ownership |
| |
Sets which user(s) and group(s) retain control of the permission
settings of the node (file or directory) and parent of the node. Each
node has an owner and a group associated with it. Permissions are set
for owner and group separately. A third set of permissions is set for
users which are not an owner of the file and not a member of the group the
file belongs to.
|
| | Permissions |
| |
Bits capable of being set or reset to allow certain types of access to
it. Permissions for directories have a slightly different meaning than the
same set of permissions on files.
Read
|
| |
|
Able to view contents of a file
|
|
Able to read a directory
|
|
| |
Write:
|
| |
|
Can add to or change a file
|
|
Able to delete or move files in a directory
|
|
| |
Execute:
|
| |
|
Can run a binary program or shell script
|
|
Can perform a search in a directory, combined with read permission
|
|
| |
These permissions are set in three levels:
|
| |
|
User - The owner of the file
|
|
Group - The group the user belongs to
|
|
Others - Anyone on the system that is not an owner or a member of a group
|
|
| |
The command to change permissions is chmod(1), which takes either
the octal value of the file permissions or a symbolic mode, and the
file(s) which permissions are to be changed as argument. Here are some
common examples using the symbolic mode string:
|
| | Create example file with default permissions |
| |
|
| | > touch file
> ls -l file
-rw-r--r-- 1 bb users 0 Apr 25 14:16 file
| | |
| | +--- group
| +------- user (owner)
+---------------- permissions
|
| |
|
| | Remove read, write, and execute permissions for group and others |
| |
|
| | > chmod go-rwx file
||||||
|||||+-- execute
||||+--- write
|||+---- read
||+----- remove
|+------ others
+------- group
>ls -l file
-rw------- 1 bb users 0 Apr 25 14:19 file
|
| |
|
| | Give read and write permissions to group |
| |
|
| | > chmod g+rw file
||||
|||+-- write
||+--- read
|+---- give
+----- group
>ls -l file
-rw-rw---- 1 bb users 0 Apr 25 14:36 file
|
| |
You can also change permissions by using the octal representation of
the permissions vector. The advantage of this method is that the
resulting permissions are not dependent on the previous settings and
is preferred by many old-time Unix users. This can also be achieved by
using the equals '=' sign instead of '+' or '-' in the examples shown.
A numeric mode is made from one to four octal digits (0-7), derived by
adding the bits with values of 4, 2, and 1. Any omitted digits are
assumed to be leading zeros. The first digit selects the set user ID
(4) and set group ID (2) and save text image (1) attributes. The
second digit selects permissions for the user who owns the file: read
(4), write (2), and execute (1); the third selects permissions for
other users in the file's group with the same values; and the fourth
for other users not in the file's group with the same values. The
octal code is composed of four digits- one for the owner, one for the
group, one for the 'set-id-bits', and one for those outside these
groups. Each of these digits is the sum of the permissions you want to
give.
For example, to make a file read-write for the owner, read only for
the group, and not accessible for all others, you would use the command
chmod 0640 file:
|
| | > chmod 0640 file
|||
||+-- no permissions for others
|+--- give read permissions for group
+---- give read (4) and write (2) permissions for owner
>ls -l file
-rw-r----- 1 bb users 0 Jun 15 15:10 file
|
| |
Make sure that you don't allow unecessary permissions. Instruct users
to set a private umask in their shell startup script (i.e.,
bashrc for bash so that new files are created with the
necessary set of permissions.
The umask command can be used to determine the default file
creation mode on your system. It is the octal complement of the
desired file mode. If files are created without any regard to their
permissions settings, the user could inadvertently give read or write
permission to someone that should not have this permission. Typically
umask settings include 022, 027, and 077, which
is the most restrictive. SuSE's default mask is 022, which
means that files are created readable for everyone and writeable for
only the owner.
|
| 24.1.4 | Confidentiality |
| |
It sounds obvious, but keep confidential information private and
protected. If your system has a dial-up connection for system users,
do not list the number in public places, or give it away to people who
don't have an account on the machine. Do not divulge your password
anyone, since this is your key to the system's safety. Another
security leak results from sharing accounts. If a friend needs to have
access to the machine, create a new account.
These are a few examples of the security issues you face. You want to
be sure that the system is only accessible to those who own
accounts. Instruct your users to respect these policies and not to
invite anyone else to use your resources.
This doesn't only apply to obvious things like posting the information
somewhere. Be aware that everything you communicate over the Internet
may be read by others. This is especially true of e-mail, which is a
very insecure medium. Unfortunately, telnet, rlogin, and
similar sessions can easily be monitored or hijacked by a third party.
Use PGP to encrypt e-mail, and SSH to encrypt online sessions on remote
machines. Encourage your users to do the same.
|
| 24.1.5 | Privacy |
| |
Encourage your users to respect each other's privacy. No one should
spy on other user's files, e-mail, or passwords. A simple reminder to
'do unto others' should suffice.
|
| 24.1.6 | Awareness |
| |
Be on the look out for changes on the system or in your home directory
which you didn't make. Trace them and inform everyone related to your
system when these things happen.
Crackers are often very careful to not leave a trace. If you find
something that seems strange, don't ignore it-follow up on it
immediately. It may be the first warning that there has been an
intruder on the system.
You can find a much more detailed security policy in
section 2 of RFC2196, the Site Security Handbook. The
Handbook not only covers aspects of user security, but also includes
guidelines and useful information on system administration and
physical accessibility of the actual hardware.
|
| 24.2 | Administrative Tasks to Ensure Host Security |
| |
We've discussed how you can help users maintain a higher level of
security. What can the system administrator do to support users in
this and enforce key aspects of the security policy?
The first - and probably the hardest part is to educate users and to
be helpful with questions they have about security. But you can do
more by setting up useful defaults and provide mechanisms to keep
security up to date.
|
| 24.2.1 | Preparing a Backup Strategy |
| |
While not directly related to security, a good backup strategy becomes
important once you have had an intruder in your system. We won't
discuss terms for developing a real strategy here, but I will list a
few points which are important for recovery after a successful break
in attempt, and may influence your decision on how to backup your
system:
|
| |
|
Total and save recovery of your base system
This means that you should backup your system at the point that
it was first installed and had no user had access to it. It is
important to have this backup to use because the intruder may have changed parts
of the system that may take crucial time to find out about. They may have put a
trojan horse on your machine, which makes it easy for them to come
back even after you close the gap they used to gain access the
first time. The first thing to do after an intrusion is to
ensure that the system itself is safe. Using an installation
backup is a good approach to ensure that everything is
clean.
|
 |
A backup from yesterday, or even one a week or
month old, are often worthless unless you are certain
that you had a clean system at that point. It's better
to be on the safe side and use the earliest backup you own.
|
| |
|
|
Different ages of backups for user data
This is closely related to my first point. At first, you may not
recognize the presence of an intruder. If you find evidence that you
have been attacked, and that it was successful, you will have to
determine how long the intruder was active on your machine. Next you
have to track what he did and recover the affected data from a backup
made prior to his first appearance on the system. In this case, a
preventive measure such as relying on your library of nightly backups
to restore the system may not work. You may be forced to go back to
data a week old or longer.
|
|
Backups must not be accessible from the system
While it's convenient to backup your data on a second hard drive, such as a
Zip disk or a tape that is kept in the drive, these backups
will be worthless after a break-in.
|
|
If your backup is
accessible from the machine that was attacked, the intruder may destroy or
modify your backup as well. Be sure to eject tapes after the backup
is finished. Do not use hard disks for backup purposes, and don't rely
on any type of RAID system for your backup strategy (such as RAID
level 5 or mirroring). These techniques ensure that no data is lost
in the event of hardware failure. This is not the only instance where
you may want to restore data from a backup. In case of a break in,
you have to make sure that the backups you have were not
accessible by the intruder.
|
| |
|
|
Have a clean boot medium
In the event that you have to use your backup tapes to restore your
system, be sure that you boot from a clean medium. Booting the
existing system is not an option. There may be a trojan horse lurking
within that can make all your efforts to reclaim your system
worthless. Have a CD or a boot floppy on hand. Be sure that this
medium is clean and has not been accessed by an intruder.
|
|
| |
There are other steps involved in backup strategies, but if you follow
even these few strategies, you may be able to restore your data and
have your system up again in a relatively short time.
|
| 24.2.2 | Setting the Default umask |
| |
We talked about the umask and how it influences the permissions
of newly created files. The default setting on SuSE systems is
022, which means everyone has read access. This may be
convenient, but it's often more access than you really want. The
default umask is set in /etc/csh.login for the C-shell
family and in /etc/profile for the bourne shell family of
shells. If you change it to 027, only the group the user
belongs to can read newly created files unless the owner sets less
restrictive permissions.
|
| 24.2.3 | Sorting Users into Groups |
| |
You may have users who have to communicate and exchange files with
each other. They will find it rather annoying to deal with restrictive
permissions and change the umask on their own if you don't give
them a good alternative that doesn't violate the reason we have for
using it in the first place.
Remember that if security is not simple and convenient, users will
often violate your strategy by finding more convenient ways to get
their job done with little regard for site security issues. Try to
find a balance and make these issues as transparent and easy to use as
possible.
To avoid having users make everything world writable again, put
them in user groups that reflect their work groups. Each user can be a
member of many groups.
The most common is the default group, called the effective
group. After login, the active group is named the effective group
until another is chosen. When new files are created, they are placed
in this group. The newgrp command can be used to change the
effective group ID:
|
| | >ls -l
total 0
>touch new-file
>ls -l
total 0
-rw-r--r-- 1 bb users 0 May 3 12:46 new-file
>newgrp friends
Password:
> touch new-file.1
> ls -al
total 2
drwxr-xr-x 2 bb users 1024 May 3 12:46 .
drwxr-xr-x 6 bb users 1024 May 3 12:46 ..
-rw-r--r-- 1 bb users 0 May 3 12:46 new-file
-rw-r--r-- 1 bb friends 0 May 3 12:46 new-file.1
|
| |
You see that the file created right after login is owned by the
default group users. The newgrp command has
been used to switch to the group friends. A file created
at this point is owned by this group. The friends group
becomes the effective group.
|
|
Note that the newgrp command
requires an assigned password for this group. Use YaST to assign a
password for the group if you want users to be able to set their
effective group ID to this group.
|
| |
If you are not sure which group(s) you are in, you can use the command
id to get a list of the groups you are a member of:
|
| | > id
uid=501(bb) gid=100(users)
groups=100(users),6(disk),14(uucp),16(dialout),101(friends)
|
| |
The id command displays your numeric user ID (501), your
effective group (users, ID 100), and a list of all groups you
belong to (users, disk, uucp, dialout and
friends).
|
|
Besides the newgrp method, there is an easier way of putting
files into a group without explicitly changing the effective group ID. You can
use the group sticky-bit for directories, to enforce files
created within this directory, and those that belong to the same group as the
directory itself:
|
| | > mkdir FRIEND
> ls -l
total 1
drwxr-xr-x 2 bb users 1024 May 3 13:04 FRIEND
> chgrp friends FRIEND
> chmod g+s FRIEND
> ls -l
total 1
drwxr-sr-x 2 bb friends 1024 May 3 13:04 FRIEND
> cd FRIEND
> touch new-file
> ls -l
total 0
-rw-r--r-- 1 bb friends 0 May 3 13:04 new-file
|
| |
|
| |
This example demonstrates how to create a new directory
FRIEND, change its group to friends and then
set the group sticky-bit. Now if you create a new file in this
directory, it will belong to the group friends without
any further action. If you create a new directory, it will inherit the
group and the sticky-bit. This means once you set your directory
structure like this, you have areas in your filesystem which will take
care of the group structure themselves. This is useful if you have
more than one person working on your web site and you want to make
sure that they can all modify each other's files. Set up your document
tree as shown with a special group for Web administration
(i.e. wwwadmin) and put the users which are in the Web
team into this group.
|
| 24.2.4 | Keeping Track of File Permissions |
| |
I can't say it often enough: file permissions are your best insurance
against nasty surprises. There is one kind of permissions you want to
be especially careful with-- executables with the
set-uid flag set. This flag means that the binary
will run with the permissions of the file ownder for whoever calls
it. You see what the flaw is - anyone can impersonate that user and
have related root permissions.
For some applications this flag is important, since they won't work
without it. It is often used to get temporary root
permissions to perform a special task. An example is when you use the
command passwd to change your password, the new password
has to be written to the file /etc/shadow. However, as a
regular user, you are not allowed to change this file. This is why the
passwd binary is set-uid root. This
particular binary is set to have root permissions, no
matter who is executing it. If you do an ls -l, you see
the set-uid bit in the user area of the permissions field. Instead of
x for executable, it says s for setuid:
|
| | > ls -l /usr/bin/passwd
-rwsr-xr-x 1 root shadow 32916 Jan 19 20:07 /usr/bin/passwd
|
+-- here is the set-uid bit
|
| |
There are only few binaries which really need this flag. We come back
to the battle between security vs. convenience. For some tasks it's
just easier to give away permissions, while doing it the secure way
would take much more effort. A typical situation where this comes up
is dialing out from your machine. One way would be to give the
permissions of the group uucp to all binaries which
handle tty devices. You could set minicom to
be setuid uucp. This would allow everyone on the system
to use minicom to dial out, since the tty devices are
writable for the group uucp. Yet this would also mean
that you lose track of who is allowed to do this. The best solution is
to put the users who are allowed to dial out into the group
uucp. This way you can decide who is going to use the
modem on a per user basis.
The moral of the story? Track and monitor file
permissions. If they change without your involvement, there is a good
chance that somebody broke into your system. Also, be careful with
giving the setuid bit to binaries you are not certain are safe, even
if they perform a useful task. There may be ways to exploit these
binaries and gain root access because their code is not
clean. A common tactic is to provoke a
buffer-overflow and use this to execute applications
with the permissions of the weak binary.
SuSE provides tables where you can specify file permissions. These
tables are used to check and set the permissions every time
SuSEconfig is called. SuSE prepared tables with different
levels of security. You can choose where on the scale between
bulletproof and convenient you want to be.
The name of the default table is /etc/permissions. The
format is simple. One line for each file you want to have the
permissions set and three columns per line to specify the filename,
the ownership and group information and the permission in octal
notation:
|
| | #
# /etc/permissions
#
# Copyright (c) 1996 SuSE GmbH Nuernberg, Germany. All rights reserved.
#
# Author: Burchard Steinbild <bs@suse.de>, 1996
#
# This file is used by SuSEconfig and chkstat to check the permission
# and ownership of different files and directories.
#
# Format:
# <file> <owner>.<group> <permission>
#
#
# directories
#
/ root.root 755
/root root.root 711
/tmp root.root 1777
/tmp/.X11-unix root.root 1777
/usr/postgres/data/base postgres.daemon 700
/usr/postgres/data/files postgres.daemon 755
/usr/lib/ircd irc.root 700
/usr/tmp root.root 1777
/var/X11R6/scores root.root 1777
/var/catman man.root 755
/var/cron root.root 700
/var/cron/tabs root.root 700
/var/lib/xdm/authdir root.root 700
/var/lib/xdm/authdir/authfiles root.root 700
/var/lock root.uucp 775
/var/man2html root.root 1777
/var/run root.uucp 775
/var/run/sudo root.root 700
/var/spool/atjobs at.at 700
[...]
|
| |
SuSEconfig processes this list and checks if the listed files have the
specified owner, group, and permissions. If not, the permissions are
either set or a warning notice is sent to root, depending on the
value of the variable CHECK_PERMISSIONS in
/etc/rc.config. If set to warn the file will
remain unchanged and only a warning message will be sent. If it is
set, then the permissions will be fixed and root will be
informed about the change. You can also (but you shouldn't) set it to
no, in which case the whole mechanism will be disabled.
After the default table has been processed, additional file tables can
be specified that will be incorporated into this mechanism. The tables to
use are listed in the variable PERMISSION_SECURITY in
/etc/rc.config:
|
| | PERMISSION_SECURITY="easy local"
|
| |
This setting will result in using the file tables
/etc/permissions.easy and
/etc/permissions.local after the default table has been
processed. In addition to the easy settings, SuSE
provides /etc/permissions.secure and
/etc/permissions.paranoid, whose titles clearly indicate
their meaning. You can add your own table by listing the extension in
PERMISSION_SECURITY.
To recap, the permission check is only performed when SuSEconfig is
called, which usually when YaST is run. A better way to keep the
permissions up-to-date is to run this check on a regular schedule,
preferrably once a day. In chapter 8, we saw that
cron is the tool to use for regularly scheduled jobs. All
we have to do is to write a script that performs the permission check
(even easier is copying the corresponding lines from
SuSEconfig) and placing it in the directory
/etc/cron.daily. Now permissions are set to be checked
daily.
An example for the script (we named it checkperm) is shown
below. It's nothing more than the section of SuSEconfig wrapped
in an if-statement to ensure that /etc/rc.config is
parsed before the check is performed:
|
| | #!/bin/sh
#
# /etc/cron.daily/checkperm
#
# check file permissions
#
if [ -f /etc/rc.config ] ; then
. /etc/rc.config
if test -n "$CHECK_PERMISSIONS" -a -e /etc/permissions -a \
-x /usr/bin/perl -a -x /usr/bin/chkstat ; then
if test "$CHECK_PERMISSIONS" = "set" ; then
/usr/bin/chkstat -set /etc/permissions
for PERMEXT in $PERMISSION_SECURITY ; do
test -e /etc/permissions."$PERMEXT" &&\
/usr/bin/chkstat -set \
/etc/permissions."$PERMEXT"
done
elif test "$CHECK_PERMISSIONS" = "warn" ; then
/usr/bin/chkstat /etc/permissions
for PERMEXT in $PERMISSION_SECURITY ; do
test -e /etc/permissions."$PERMEXT" &&\
/usr/bin/chkstat \
/etc/permissions."$PERMEXT"
done
fi
fi
fi
|
| |
This is a really simple way to keep track of file permissions. But is
it enough?
|
| 24.2.5 | Monitoring the System |
| |
The sooner you see that you are the target of an attack, the easier it
is to react. The previous section discussed file permissions and how
to monitor and enforce them. But what if someone just replaces the
file and keeps the permissions as they were? By only using the method
above, you wouldn't realize that an intrusion had occurred. What we
would need to check file consistency is a tool that creates checksums
for each file and compares them to previously stored versions. This is
accomplished with tripwire.
|
| 24.3 | Tripwire |
| |
Tripwire is a file integrity checker - a utility that compares a
designated set of files and directories against information stored in
a previously generated database. Added or deleted files are flagged
and reported, as are any files that have changed from their previously
recorded state in the database. When run against system files on a
regular basis, any file changes will be spotted when
tripwire is next run, giving system administrators
information to enact damage control measures immediately.
Using Tripwire, we can conclude with an extremely high degree of
certainty that a given set of files and directories remain untouched
from unauthorized modifications, provided the program and database are
appropriately protected (e.g., stored on read-only media).
|
|
Note that reports of revised files indicate a change from
the time of the last Tripwire database installation or update. For
maximum effect, the files being monitored should be reinstalled from
known secure sources.
|
| |
Tripwire uses message-digest algorithms (one-way
hash functions) to detect changes in a hard-to-spoof manner. This
should be an adequate measure to detect significant changes to critical files,
including those caused by insertion of back-doors or viruses.
Tripwire also monitors changes to file permissions, modification
times, and other significant changes to inodes as selected by the
system administrator on a per-file/directory basis.
Tripwire runs in one of four modes:
|
| |
|
Database Generation,
|
|
Database Update,
|
|
Integrity Checking, or
|
|
Interactive Update mode.
|
|
| |
In Database Generation mode, Tripwire initializes the database based
upon the entries enumerated in the
/var/adm/tripwire/tw.config file. Database Update mode
provides incremental database update functionality on a
per-file/directory basis. This obviates having to regenerate the
entire database every time a file or set of files change. The
Integrity Checking mode generates a report of added, deleted, or
changed files, comparing all the files described by the
tw.config file against the files residing on the
filesystem. Lastly, the Interactive Update mode reports added,
deleted, and changed files and prompts the user on whether those
database entries should be updated. The Interactive Update mode
provides a simple and thorough method for system administrators to
keep Tripwire databases in sync with filesystems that change.
|
| 24.3.1 | Configuration |
| |
The file /var/adm/tripwire/tw.config file contains the
list of files and directories to be scanned by Tripwire. Information
on these files is collected and stored in the tw.db
database file. Stored with each tw.config entry is a
selection-mask that describes what changes Tripwire can safely ignore
without reporting to the user (such as access timestamp).
Each entry in tw.config is a single line in the following form:
|
| | [!|=] entry [select-flags | template] [# comment]
|
| |
An entry is the absolute pathname of a file or a directory. Without
any prefixes, the entry is added to the list of files to be scanned.
|
|
Note that directories listed in the tw.config file are
recursively descended. However, file systems are never crossed. (i.e.,
if /usr and /usr/local are separate file
systems, a /usr in tw.config entry will not
scan files that reside in the /usr/local filesystem.)
|
| |
To prune the entry, you can prefix the entry with a bang
(!) or equal sign(=). The bang indicates
that tripwire should perform an inclusive prune. It
prunes entry from the list of files to be scanned. If
it's a file, the file is removed from the list of files. If it's a
directory, the directory and all of its children are removed from the
list of files. The equal sign means to perform an exclusive
prune. This does not prune entry, but all of its
children. This has no effect if entry is a file. It is
useful for monitoring directories with transient files (e.g.,
/tmp and /var/tmp) because only the
directory itself will be monitored and all the files contained in it
will be ignored.
The select flags tell Tripwire what to look for and what to
ignore. Table 24-2
lists the select flags, but
to ease the configuration, predefined templates can be used, which
will be enough for now:
|
| |
|
R - Read-only
The following attributes are monitored: permission and file mode bits,
inode number, number of links (i.e., inode reference count), user id
of owner, group id of owner, size of file and modification timestamp.
The signature is created using the RSA Data Security, Inc. Message
Digesting Algorithm (MD5) and the Xerox Secure Hash Function (Snefru).
The access timestamp and the inode creation/modification
timestamp are ignored.
This is the default that is used when neither select flags nor a
template are specified.
|
|
L - Log file
Like R, but file size and modification timestamp are ignored,
and no checksum over the file content is created.
|
|
N - Ignore Nothing
This template ensures the highest level of security. In addition to the attributes
included in the R template, N also records the access
timestamp and the inode creation/modification timestamp. Eight
different checksums are created of the files content: The RSA Data
Security, Inc. Message Digesting Algorithms MD5, MD4 and MD2; the
Xerox Secure Hash Function (Snefru); the POSIX 1003.2 compliant 32-bit
Cyclic Redundancy Check (CRC-32); the standard (non-CCITT) 16-bit
Cyclic Redundancy Check (CRC-16); the NIST Secure Hash Algorithm (SHA)
and Haval, a strong 128-bit signature algorithm key.
|
|
E - Ignore Everything
This template is created if you want to exclude certain files from
being monitored in a specified directoy.
|
|
> - monotonically growing file
Like L, but if the size of the file gets smaller, the change will be
reported. This is useful for log files that are expected to grow.
|
|
| |
You can combine the use of templates with select-flag modifiers. We
will come back to this issue later on with a simple example configuration.
Please refer to the manual page tw.config(5) for
a detailed list of the select flags.
What would a tripwire configuration file look like? This
depends on which parts of your system you want to monitor. Obvious
areas of concern are the /etc directory, since it holds all the
important configuration files, and the binary directories /bin,
/usr/bin, /sbin and /usr/sbin, because no one is
supposed to change any of these binaries. You should also keep an eye
on the libraries and modules in /lib and everything contained
in /usr/lib. The kernel image is an important part of your
system, so /boot should be monitored too. Last but not least,
the configuration file of Tripwire itself has to be constant, since what good
does a monitoring tool do if an intruder reconfigures it?
These issues could lead you to construct a configuration like the one shown below:
|
| | #
# /var/adm/tripwire/tw.config
#
/etc R
/bin R
/sbin R
/lib R
/usr/bin R
/usr/sbin R
/usr/lib R
/var/adm/tripwire/tw.config R
# exclude files that are OK to change
!/etc/mtab
!/etc/ntp.drift
!/etc/ld.so.cache
!/etc/snmpd.agentinfo
!/etc/ssh_random_seed
!/etc/mail/sendmail.st
|
| |
|
|
This is a good place to start. You may want to customize it for
your particular needs and include more files and/or directories to the
list. Or you may choose to exclude files that change during normal system operations to
avoid needless warnings. Be careful that you do not exclude too many
files. A good strategy is to start with a restrictive configuration,
and if warnings come up, consider their origin. If
they result from normal operation, exclude the changed attributes (not
the whole file) from monitoring.
|
| |
We'll view an example of a useful extension shortly.
|
| 24.3.2 | Generating the Database |
| |
OK, now that we have finished the configuration, how do we use it? Using
the configuration file we have to create the Tripwire database, which
contains all the stored file attributes and checksums used for
comparison in later runs of Tripwire.
|
|
This has to be done
very carefully. If you have a trojan horse, a modified binary, incorrect
permissions, or anything that is not as it should be on your system at
the moment you create the database, you'll never get accurate reporting.
|
| |
|
|
The recommended method is to install the system from scratch,
not network it and then create the database. As soon as the system is on
the network, there is the chance that an intruder will make modifications
and you'll never catch them if you create your reference database
after an attack. Be certain you're the only one on the
system while you create the database. Running in single-user mode is a
good idea at this point.
|
| |
Creating the database itself is fairly easy. The parameter
-initialize assigns tripwire to create a new database:
|
| | # cd /tmp
# /var/adm/tripwire/bin/tripwire -initialize
### Phase 1: Reading configuration file
### Phase 2: Generating file list
### Phase 3: Creating file information database
###
### Warning: Database file placed in ./databases/tw.db_Maggie.
###
### Make sure to move this file and the configuration
### to secure media!
###
### (Tripwire expects to find it in '/var/adm/tripwire/db'.)
|
| |
The database is stored in a newly created directory
databases of your current working directory. The name is
tw.db_systemname. In the example above, the name
of the system is Maggie, so the database name is
./databases/tw.db_Maggie.
|
|
Once the database is created it should be stored on a secure media,
meaning on read-only media. Remember, this is your reference, the
information you will rely on in the event of an emergency. You want to
be the only person to modify it. A floppy disk with
write protection is a good start. But if you run a big site, the file
size may exceed the 1.44 MB space available on a floppy disk. In this
case, a CD-ROM is a good solution. You want to use CD rewriteables,
since the need for updating the database will arise from time to
time. Don't forget that when you install new software, or change parts
of the configuration, you'll have to update the Tripwire database. If
you use CD rewritables, use a read-only CD-ROM drive to access the
data. Write the CD in a separate machine and access the data with a
regular CD-ROM drive on your server system.
|
| |
|
| 24.3.3 | Using Tripwire to monitor the system |
| |
At this point we've set up Tripwire and created the reference
database. Let's further assume you copied the database to a CD-ROM and
this CD-ROM is accessible via the device /dev/cdrom. Now
how do you use the database after all the effort we've gone through to
create it? There are a couple of ways to use Tripwire. First we can
check the system manually. To do this we mount the CD-ROM and call
tripwire with the database file as argument:
|
| | # mount /dev/cdrom /cdrom -o ro
# /var/adm/tripwire/bin/tripwire -d /cdrom/tw.db_Maggie
### Phase 1: Reading configuration file
### Phase 2: Generating file list
### Phase 3: Creating file information database
### Phase 4: Searching for inconsistencies
###
### Total files scanned: 7429
### Files added: 0
### Files deleted: 0
### Files changed: 7429
###
### After applying rules:
### Changes discarded: 7429
### Changes remaining: 0
###
# umount /cdrom
|
| |
Everything's in working order, with no changes reported. Now we can
advance to automating the monitoring process. We'll write a script
that calls tripwire and is executed (in this example)
once an hour by the cron service. Cron mails
all output of the job to the user the job belongs to. As you can see,
Tripwire is rather chatty, and you certainly don't want to get a mail
every hour telling you everything is OK. If you want to, that's
fine. To avoid the often copious output, you can use the parameter
-q (quiet). This way, Tripwire will report only one line
per changed file, and won't print anything when no changes have been
made.
Now what happens if Tripwire detects that some file has changed? To
illustrate this, let's say we add another user to the system. Run
Tripwire again and to see what it reports with the -q
option:
|
| | # /var/adm/tripwire/bin/tripwire -q -d/cdrom/tw.db_Maggie
changed: drwxr-xr-x root 3072 Jun 16 10:28:21 1999 /etc
changed: -rw-r--r-- root 1898 Jun 16 10:28:21 1999 /etc/passwd
changed: -rw-r----- root 947 Jun 16 10:28:21 1999 /etc/shadow
changed: -rw-r----- root 948 Jun 16 10:28:21 1999 /etc/shadow-
changed: -rw-r----- root 912 Jun 15 17:33:44 1999 /etc/shadow.orig
changed: -rw-r--r-- root 1860 Jun 16 00:00:46 1999 /etc/passwd.orig
|
| |
You see quite a few files are changed when a new user is added to the
system. To see exactly which attributes changed, you'll have to run
Tripwire again without the -q option. This will result in
output like this:
|
| | # /var/adm/tripwire/bin/tripwire -d/cdrom/tw.db_Maggie
### Phase 1: Reading configuration file
### Phase 2: Generating file list
### Phase 3: Creating file information database
### Phase 4: Searching for inconsistencies
###
### Total files scanned: 7429
### Files added: 0
### Files deleted: 0
### Files changed: 7429
###
### After applying rules:
### Changes discarded: 7423
### Changes remaining: 6
###
changed: drwxr-xr-x root 3072 Jun 18 15:23:06 1999 /etc
changed: -rw-r--r-- root 1935 Jun 18 15:23:06 1999 /etc/passwd
changed: -rw-r----- root 982 Jun 18 15:23:06 1999 /etc/shadow
changed: -rw-r----- root 983 Jun 18 15:23:06 1999 /etc/shadow-
changed: -rw-r----- root 947 Jun 16 10:28:21 1999 /etc/shadow.orig
changed: -rw-r--r-- root 1898 Jun 16 10:28:21 1999 /etc/passwd.orig
### Phase 5: Generating observed/expected pairs for changed files
###
### Attr Observed (what it is) Expected (what it should be)
### =========== ============================= =============================
/etc
st_mtime: Fri Jun 18 15:23:06 1999 Thu Jun 17 18:25:18 1999
st_ctime: Fri Jun 18 15:23:06 1999 Thu Jun 17 18:25:18 1999
/etc/passwd
st_size: 1935 1898
st_mtime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 0HfZ6X:oe3HxHSiWjxE0qG 1ffnYV3jXSPmB6WUsrlCGB
snefru (sig2): 0XLeFKc.6PjaJP:vWVmVp4 0zXeGBUsEP8fwMAidyW0J9
/etc/shadow
st_ino: 10633 10632
st_size: 982 947
st_mtime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 0yqRY5uTfyPYw4JwZQSojz 04Nf2YzFvtcysMUG0riXuO
snefru (sig2): 3xqxyI3heEH8UBTkZTDtFi 1WA0wo39rOK3xsNgD.2I2l
/etc/shadow-
st_size: 983 948
st_mtime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 2f112dgUvdYolx3qLH8n2v 10tcO240IKvSQSFxSzH6KZ
snefru (sig2): 298hqVtw5TcCYEpiY3UbKJ 2Vd7sGvpfhAWim9r6KgFVK
/etc/shadow.orig
st_size: 947 912
st_mtime: Wed Jun 16 10:28:21 1999 Tue Jun 15 17:33:44 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 04Nf2YzFvtcysMUG0riXuO 2aIe4dKimRDpmYvXA7FmWA
snefru (sig2): 1WA0wo39rOK3xsNgD.2I2l 0fvl4WGEj:aS348z8hPmw5
/etc/passwd.orig
st_size: 1898 1860
st_mtime: Wed Jun 16 10:28:21 1999 Wed Jun 16 00:00:46 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 1ffnYV3jXSPmB6WUsrlCGB 3iT3ssd:v9TzHmQVifqyMD
snefru (sig2): 0zXeGBUsEP8fwMAidyW0J9 04rUwpzYWKnJXv13ltElWJ
|
| |
This time we get a very detailed report. Tripwire tells us exactly
where it found differences between the files in the system and the
recorded reference in the database. The rows below each file are
explained in table 24-1
. Each monitored attribute of the
file will be listed in the report.
|
| Table 24-1 |
Changes reported by Tripwire |
| |
| Caption |
Meaning |
| st_mode |
States the protection mode-bits that are associated with the file. (i.e., read, write, and execute permission bits). |
| st_ino |
The inode number, which uniquely labels the file within the filesystem. |
| st_nlink |
The number of links to a file which exist. (Adding a hard-link to a file or creates a subdirectory adds one to this number.) |
| st_uid |
The user-id of the file owner. |
| st_gid |
The group-id of the file owner. |
| st_size |
The size (in bytes) of the file. |
| st_atime |
The timestamp of the last file access. |
| st_mtime |
The timestamp of the last file modification. |
| st_ctime |
The timestamp of the last inode update. |
| sig[0..9] |
The 'fingerprint' yielded by each signature routine. |
|
| |
You can get extensive information about the nature of any changes
made. Now we want to automate the system check. The 'be-quiet' option
(-q) is nice, but if something changes, it's better to
have Tripwire deliver a detailed report. To do this, we store the
detailed output of Tripwire in a temporary file and mail it to the
system administrator only in the event that Tripwire finds
differences. The following script gives you an idea how to do this:
|
| | #!/bin/sh
#
# /root/bin/runtripwire
#
sysadmin=root
tmpfile=/tmp/tripwire.out.$$
mount /dev/cdrom /cdrom -o ro
if [ -f /cdrom/tw.db_Maggie ] ; then
/var/adm/tripwire/bin/tripwire -d /cdrom/tw.db_Maggie > ${tmpfile} 2>&1
if [ $? != 0 -a -f ${tmpfile} ] ; then
cat ${tmpfile} | /bin/mail -s "Security Warning!" ${sysadmin}
fi
rm -f ${tmpfile}
else
echo No database file?!
fi
umount /cdrom
|
| |
Now we can add the script to root's crontab and run it (as an example) every
other hour. To do this use crontab -e to add this to the
crontab:
|
| | # run tripwire every other hour
0 */2 * * * /root/bin/runtripwire
|
| |
Once this is set up, you'll be alerted to changes on the system soon after they occur.
|
| 24.3.4 | Maintaining the Database |
| |
The previous example made it clear that when we add a user to the
system, we need to either update the database or revise the
configuration. The same goes for handling groups, password changes,
etc.. Whether you do this or not will depend on the type of machine
you run or whether you want to update the database or change the
configuation.
If it is a server for many users, it may be wiser to change the
configuration. Users change their passwords all the time and you may
change user records frequently, so monitoring the password database
doesn't make much sense. You could end up receiving warning messages
every hour. If the machine is used as a gateway or firewall,
changes are rare and you definitely want to monitor every single
file. If /etc/shadow changes in this scenario, you have to find
out why.
We'll walk through both tasks here. First we'll update the database to
reflect the revised files. To do this, you need to copy the database
back to a writable medium. We'll assume the database is
/tmp/tw.db_Maggie. Now there are two ways to update the
database. You can do it interactively, where Tripwire will prompt you
for each modified file and ask if you want to update the entry shown or
not. Or you can specify the files, directories, or configuration
entries that you want to have updated.
First we'll try the interactive update. To start it, call Tripwire
with the flag -interactive. You will see how it generates
its file list and information database, then you'll be prompted for
each change detected by Tripwire. Here you can choose between several
responses that Tripwire will execute. For each prompted file you can
update the database entry to match the current file (y),
to let database entry stand as is (n), to change this and
all other files in this entry (Y) or leave this and all
other entries as is (N). What does entry mean in this
context? Remember that we had 'entries' when we created the
configuration. Here you can use those entries to update all files
which are covered by this one entry to be updated (or left as they
are) at once.
|
|
Lower case letters specify a single file, and capitalized
letters perform the action on all files which belong to the entry the
current file belongs to.
|
| |
But back to our example. The next listing shows how to set Tripwire to
interactively update the database:
|
| | # /var/adm/tripwire/bin/tripwire -d /tmp/tw.db_Maggie -interactive
### Phase 1: Reading configuration file
### Phase 2: Generating file list
### Phase 3: Creating file information database
### Phase 4: Searching for inconsistencies
###
### Total files scanned: 7429
### Files added: 0
### Files deleted: 0
### Files changed: 7429
###
### After applying rules:
### Changes discarded: 7423
### Changes remaining: 6
###
changed: drwxr-xr-x root 3072 Jun 18 15:23:06 1999 /etc
changed: -rw-r--r-- root 1935 Jun 18 15:23:06 1999 /etc/passwd
changed: -rw-r----- root 982 Jun 18 15:23:06 1999 /etc/shadow
changed: -rw-r----- root 983 Jun 18 15:23:06 1999 /etc/shadow-
changed: -rw-r----- root 947 Jun 16 10:28:21 1999 /etc/shadow.orig
changed: -rw-r--r-- root 1898 Jun 16 10:28:21 1999 /etc/passwd.orig
### Phase 5: Generating observed/expected pairs for changed files
###
### Attr Observed (what it is) Expected (what it should be)
### =========== ============================= =============================
/etc
st_mtime: Fri Jun 18 15:23:06 1999 Thu Jun 17 18:25:18 1999
st_ctime: Fri Jun 18 15:23:06 1999 Thu Jun 17 18:25:18 1999
---> File: '/etc'
---> Update entry? [YN(y)nh?]
|
| |
At this point we could hit Y to update all files within the
entry /etc. Just out of curiosity, let's only update this
directory by hitting y and continuing:
|
| | /etc/passwd
st_size: 1935 1898
st_mtime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 0HfZ6X:oe3HxHSiWjxE0qG 1ffnYV3jXSPmB6WUsrlCGB
snefru (sig2): 0XLeFKc.6PjaJP:vWVmVp4 0zXeGBUsEP8fwMAidyW0J9
---> File: '/etc/passwd'
---> Update entry? [YN(y)nh?]
|
| |
Next you'll see the file from the short list printed at the end of phase
4. Now press Y and see what happens:
|
| | /etc/shadow
st_ino: 10633 10632
st_size: 982 947
st_mtime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 0yqRY5uTfyPYw4JwZQSojz 04Nf2YzFvtcysMUG0riXuO
snefru (sig2): 3xqxyI3heEH8UBTkZTDtFi 1WA0wo39rOK3xsNgD.2I2l
---> Updating '/etc/shadow'
/etc/shadow-
st_size: 983 948
st_mtime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 2f112dgUvdYolx3qLH8n2v 10tcO240IKvSQSFxSzH6KZ
snefru (sig2): 298hqVtw5TcCYEpiY3UbKJ 2Vd7sGvpfhAWim9r6KgFVK
---> Updating '/etc/shadow-'
/etc/shadow.orig
st_size: 947 912
st_mtime: Wed Jun 16 10:28:21 1999 Tue Jun 15 17:33:44 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 04Nf2YzFvtcysMUG0riXuO 2aIe4dKimRDpmYvXA7FmWA
snefru (sig2): 1WA0wo39rOK3xsNgD.2I2l 0fvl4WGEj:aS348z8hPmw5
---> Updating '/etc/shadow.orig'
/etc/passwd.orig
st_size: 1898 1860
st_mtime: Wed Jun 16 10:28:21 1999 Wed Jun 16 00:00:46 1999
st_ctime: Fri Jun 18 15:23:06 1999 Wed Jun 16 10:28:21 1999
md5 (sig1): 1ffnYV3jXSPmB6WUsrlCGB 3iT3ssd:v9TzHmQVifqyMD
snefru (sig2): 0zXeGBUsEP8fwMAidyW0J9 04rUwpzYWKnJXv13ltElWJ
---> Updating '/etc/passwd.orig'
Updating entry: /etc
Updating entry: /etc/passwd
Updating entry: /etc/shadow
Updating entry: /etc/shadow-
Updating entry: /etc/shadow.orig
Updating entry: /etc/passwd.orig
### Updating database...
###
### Phase 1: Reading configuration file
### Phase 2: Generating file list
Updating: update entry: /etc
Updating: update file: /etc/passwd
Updating: update file: /etc/shadow
Updating: update file: /etc/shadow-
Updating: update file: /etc/shadow.orig
Updating: update file: /etc/passwd.orig
### Phase 3: Updating file information database
###
### Old database file will be moved to `tw.db_Maggie.old'
### in ./databases.
###
### Updated database will be stored in './databases/tw.db_Maggie'
### (Tripwire expects it to be moved to '/var/adm/tripwire/db'.)
###
###
### If you changed the tw.config file, remember to run `twdb_check.pl' to
### ensure database consistency.
### See the README file for details.
|
| |
Alright, all files from the entry /etc have been
updated. Because there were no other differences reported, the
database reflects the current status of the system again.
Of course there is a way to do this from the commandline and without
any interaction. The parameter -update puts Tripwire into
the Database Update mode. This mode updates a specified pathname or
entry in the database. If the argument provided is a file, only that
file is updated. If the argument is a directory, that directory and
all of its children are updated. If the argument is an entry in the
tw.config file, the entire entry in the database is
updated. Since we have /etc as entry in the
configuration, we can use this to sync the database with the current
situation:
|
| | # /var/adm/tripwire/bin/tripwire -d /tmp/tw.db_Maggie -update /etc
### Phase 1: Reading configuration file
### Phase 2: Generating file list
Updating: update entry: /etc
### Phase 3: Updating file information database
###
### Old database file will be moved to `tw.db_Maggie.old'
### in ./databases.
###
### Updated database will be stored in './databases/tw.db_Maggie'
### (Tripwire expects it to be moved to '/var/adm/tripwire/db'.)
###
|
| |
|
|
Don't forget to copy the new database into your read-only medium again
so that it is incorporated in the automated monitoring.
|
| |
In the last step on our discussion of Tripwire, we will see how we can
trim the configuration so that files which are changed frequently are
still monitored as much and as often as possible, but don't show up in
warning reports unnecessarily.
In the tripwire configuration you can exclude single files from
directories you want to monitor. In our example, the password and user
database related files change, but their permissions stay constant. We
want to make sure that they actually remain constant. We don't want to
exclude the whole file from monitoring, only certain attributes of
these files.
If you refer to Tripwire's report, you see that we have to exclude the
flags for modification time, inode update, size, and the checksums for
the reported files. You see how it's actually useful to set up a very
restrictive set of rules and then take away only the attributes which
really change due to the task you want to allow.
But how do we exclude these attributes from being checked now? So far
we used only templates for checking files. Earlier I mentioned that we
can combine these templates with so-called
select-flags. Each flag specifies a single file
attribute. Table 24-2
gives a list of the select flags
Tripwire works with.
|
| Table 24-2 |
The Meaning behind Tripwire's Select Flags |
| |
| Flag |
Attribute |
| p |
Permission and file mode bits |
| i |
Inode number |
| n |
Number of links (i.e., inode reference count) |
| u |
User id of owner |
| g |
Group id of owner |
| s |
Size of file |
| a |
Access timestamp |
| m |
Modification timestamp |
| c |
Inode creation/modification timestamp |
| 0-9 |
Checksums (signatures) |
|
| |
You can include attributes with a plus (+) sign and
exclude them with minus (-). All we have to do is prune
the attributes we want to exclude by referencing select flags. The new
configuration then would look like this:
|
| | #
# /var/adm/tripwire/tw.config
#
/etc R
/bin R
/sbin R
/lib R
/usr/bin R
/usr/sbin R
/usr/lib R
/var/adm/tripwire/tw.config R
# exclude attributes changed by user maintenance
!/etc/passwd R-mcs12
!/etc/shadow R-mcs12
!/etc/shadow- R-mcs12
!/etc/shadow.orig R-mcs12
!/etc/passwd.orig R-mcs12
# exclude files that are OK to change
!/etc/mtab
!/etc/ntp.drift
!/etc/ld.so.cache
!/etc/snmpd.agentinfo
!/etc/ssh_random_seed
!/etc/mail/sendmail.st
|
| |
|
|
Unfortunately the script twdb_check.pl, which is used
to sync the database with the new configuration, is malfunctioning on
the SuSE distribution. This means we need to create a new database
from scratch. This also means that the new database could have been
modified by intruders and gone unoticed by the system administrator
between the last check and the database's installation. Even worse,
the modified version would be treated as reference version of these
files. You must disconnect the sytem from all networks, close the
system to users, and run a check which will hopefully report the
expected differences. Then you can modify the configuration, create
and install the new database, and reopen your system for regular use.
|
| |
A drawback is that changes of the directory /etc will still be
reported. This means we will have to extend the script calling
Tripwire by adding a little filter to catch the directory. While no
example is given here, you may find it a useful exercise.
More about Tripwire can be found in the documentation in
/usr/doc/packages/tripwire and in the man
pages tripwire(8) and tw.config(8). There is also a Web
site for Tripwire where you can get newer versions (1.3 is out, while
you'll only find version 1.2 on the SuSE distribution), or the commercially
supported version of Tripwire.
|
|
| Summary: |
| |
In this chapter we learned about aspects of local
security that affect a single host. We examined the need for a security policy that
educates users about security issues and policies. The main
barrier for intruders is the degree of password protection of the accounts on
your system. Choosing secure passwords and enforcing frequent password
changes are the best strategy to keep this barrier strong.
File permissions are used to separate users from system data and from
each other's personal information. Groups can be used to allow easy
exchange of data between users who work together.
We discussed the importance of backups to recover from a cracker
attack and the points which are important in the design of a powerful
backup strategy.
SuSE provides a set of permission lists and a script to sync the
system with these. We saw what these lists look like and how we
can extend this mechanism to enforce frequent updates of these
permissions. We discussed Tripwire, a very good tool used to monitor
changes on your system. An example showed us how to use Tripwire and
how to configure it in a practical way.
|
|
