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.
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.
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.
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.
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:
root# rpm -Va
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.
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 http://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.
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.
