Section 13.2 Advanced Preparation

   


13.2 Advanced Preparation

When your system has been broken into, the cracker might have altered any program, file, or even the kernel. This leaves you with a system that you cannot trust until you find and remove any cracker-altered or -added files. Although some "experts" will advise you simply to "restore from backup" or mount your root file system as the second file system of a system that has not been compromised, going directly to these steps throws away valuable information about what the cracker did.

First, you will want to make frequent backups of the system. Besides the value of a backup in case of a disk loss or human error, the files on a GNU tar backup may be easily compared with the versions of those files on disk. Differences will be detected easily and can be analyzed to see whether they contain cracker Trojan horses. If your site uses a different backup scheme than GNU tar, determine whether it allows the easy comparison of the backup tape to the running disk. If not, it might be advantageous to also make a GNU tar backup periodically so that it can be used if a break-in is suspected. GNU tar supports multiple tape backups. Also, there is the dd_multi program discussed in "Protecting the System from User Mistakes" on page 51.

Second, you want secret versions of a few programs that you can trust that allow analysis of the running, possibly Trojan-infested system before you shut it down. You cannot simply keep them on a write-protected floppy and mount that floppy if you suspect a break-in. This is because the mount command could have a Trojan in it. If you put these programs on a write-protected floppy that is left mounted, the cracker will notice this unless you edit /etc/mtab and ensure that /proc is accessible only to root. (The latter is mandatory in any case.)

Because only root normally can mount a file system, you would need to su to root. If the su command has a Trojan, this act would give the root password to the cracker. You cannot even use ssh to connect into the system because the cracker could have added a Trojan to ssh. The best solution that I know is to have a spare ordinary account with an innocent name that a cracker is unlikely to notice. It should have a bin directory or some other equally expected directory with some executables. Some of the programs that are helpful are the following:

 
 ps ls netstat ports grep cmp tar diff md5sum more or less 

You should not simply copy these files from /bin, however, because the cracker could figure out that you are keeping "trusted" copies of programs that he is adding Trojans to. Then, he will replace your trusted copies with versions containing Trojans too. Instead, you should pick unique but ordinary-sounding names for these programs. Look at what locally named programs you have and pick similar names. Keep a printed list of which program is which.

A really clever cracker might try to do a binary compare of your programs to the standard copies in /bin. This should be worked around by adding random data to the end of your copies. This old trick will not affect their correct operation. If your "ordinary" account is called larry, the following might be a good start on building up this list of trusted commands. Do not use /etc/termcap but pick some other method of adding "junk" to the end of your copies of the executables. Note that a printout of the filename mapping and MD5 sum is generated; this could be kept in a safe but obvious place where you will remember to look for it at 3 A.M. in a year's time when you need it.

 
 cd /home/larry mkdir bin chmod 755 bin cp /bin/ls bin/monthly cat /etc/termcap >> bin/monthly (echo ls is monthly;md5sum bin/monthly)|lpr 

       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net