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
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.