9. Security Preparation (before you go
on-line)
Ok, so you have checked over your system, and determined it's as secure as
feasible, and you're ready to put it online. There are a few things you should
now do in order to prepare for an intrusion, so you can quickly disable the
intruder, and get back up and running.
9.1. Make a Full Backup of Your Machine
Discussion of backup methods and storage is beyond the scope of this
document, but here are a few words relating to backups and security:
If you have less than 650mb of data to store on a partition, a CD-R copy of
your data is a good way to go (as it's hard to tamper with later, and if stored
properly can last a long time), you will of course need at least 650MB of space
to make the image. Tapes and other re-writable media should be write-protected
as soon as your backup is complete, and then verified to prevent tampering. Make
sure you store your backups in a secure off-line area. A good backup will ensure
that you have a known good point to restore your system from.
9.2. Choosing a Good Backup Schedule
A six-tape cycle is easy to maintain. This includes four tapes for during the
week, one tape for even Fridays, and one tape for odd Fridays. Perform an
incremental backup every day, and a full backup on the appropriate Friday tape.
If you make some particularly important changes or add some important data to
your system, a full backup might well be in order.
9.3. Testing your backups
You should do periodic tests of your backups to make sure they are working as
you might expect them to. Restores of files and checking against the real data,
sizes and listings of backups, and reading old backups should be done on a
regular basis.
9.4. Backup Your RPM or Debian File
Database
In the event of an intrusion, you can use your RPM database like you would
use tripwire, but only if you can be sure it too hasn't
been modified. You should copy the RPM database to a floppy, and keep this copy
off-line at all times. The Debian distribution likely has something similar.
The files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most likely won't fit on a single
floppy. But if compressed, each should fit on a seperate floppy.
Now, when your system is compromised, you can use the command:
to verify each file on the system. See
the
rpm man page, as there are a few other options that
can be included to make it less verbose. Keep in mind you must also be sure your
RPM binary has not been compromised.
This means that every time a new RPM is added to the system, the RPM database
will need to be rearchived. You will have to decide the advantages versus
drawbacks.
9.5. Keep Track of Your System Accounting
Data
It is very important that the information that comes from syslog not be compromised. Making the files in /var/log readable and writable by only a limited number of
users is a good start.
Be sure to keep an eye on what gets written there, especially under the auth facility. Multiple login failures, for example, can
indicate an attempted break-in.
Where to look for your log file will depend on your distribution. In a Linux
system that conforms to the "Linux Filesystem Standard", such as Red Hat, you
will want to look in /var/log and check messages, mail.log, and others.
You can find out where your distribution is logging to by looking at your /etc/syslog.conf file. This is the file that tells syslogd (the system logging daemon) where to log various
messages.
You might also want to configure your log-rotating script or daemon to keep
logs around longer so you have time to examine them. Take a look at the logrotate package on recent Red Hat distributions. Other
distributions likely have a similar process.
If your log files have been tampered with, see if you can determine when the
tampering started, and what sort of things appeared to be tampered with. Are
there large periods of time that cannot be accounted for? Checking backup tapes
(if you have any) for untampered log files is a good idea.
Intruders typically modify log files in order to cover their tracks, but they
should still be checked for strange happenings. You may notice the intruder
attempting to gain entrance, or exploit a program in order to obtain the root
account. You might see log entries before the intruder has time to modify them.
You should also be sure to separate the auth facility
from other log data, including attempts to switch users using su, login attempts, and other user accounting information.
If possible, configure syslog to send a copy of the
most important data to a secure system. This will prevent an intruder from
covering his tracks by deleting his login/su/ftp/etc attempts. See the syslog.conf man page, and refer to the @ option.
There are several more advanced syslogd programs out
there. Take a look at https://www.core-sdi.com/ssyslog/ for Secure Syslog. Secure
Syslog allows you to encrypt your syslog entries and make sure no one has
tampered with them.
Another syslogd with more features is syslog-ng.
It allows you a lot more flexibility in your logging and also can has your
remote syslog streams to prevent tampering.
Finally, log files are much less useful when no one is reading them. Take
some time out every once in a while to look over your log files, and get a
feeling for what they look like on a normal day. Knowing this can help make
unusual things stand out.
9.6. Apply All New System Updates.
Most Linux users install from a CD-ROM. Due to the fast-paced nature of
security fixes, new (fixed) programs are always being released. Before you
connect your machine to the network, it's a good idea to check with your
distribution's ftp site and get all the updated packages since you received your
distribution CD-ROM. Many times these packages contain important security fixes,
so it's a good idea to get them installed.
