Protecting a company's data is a Red Hat Linux administrator's mission, a mission made tougher by Trojan horses and backup mistakes. In this tip, Mark Sobell explains how to corral Trojan horses and describes some handy tools for backups. He is the author of
the new edition of "A Practical Guide to Red Hat Linux," which debuted at LinuxWorld in San Francisco on Aug. 3. In part one of this interview, he covered user administration. The third and final episode will offer pointers for avoiding common Red Hat Linux administration mistakes.
Why are Trojan horses that take advantage of misspellings so dangerous?
Sobell: Trojans that take advantage of misspellings are dangerous because everyone makes a typo now and then. For example, it is very easy to type sl instead of ls and, if the mistyped command displays the correct output, you may not notice that it installed a key logger or other mischievous program in the background. Using TAB-completion when you give commands can help by notifying you that there are multiple commands that start with the same letters.
What's a good way to stop that type of Trojan horse?
Sobell: Check your PATH variable and make sure that there are no directories in PATH that a user other than Superuser can write to. (If an attacker can already write to the disk as Superuser, the system is probably already compromised.) With PATH set up properly, the only way this kind of Trojan can work is if you specify a pathname of a user-writable directory when you give a command, which you are not likely to do.
When you use su to gain Superuser privileges, make sure to use su – (follow the su command with a hyphen). The hyphen causes su to provide the same environment as if you had logged in as root, including root's PATH. Without the hyphen, you are given Superuser privileges, but retain your old environment, which may contain a PATH with user-writable directories.
In what corporate IT settings would the backup utilities tar, Amanda, and cpio be most useful?
Sobell: Really, any setting. The most important parts of a backup strategy are the frequency of the backup, the media the backup is stored on, and the location of the copies, rather than the software used to construct them.
It is never a good idea to rely too heavily on incremental backups, because they require all of the backup media to work when you recover. For example, if you store a snapshot on tape A, and diffs on tapes B and C, you need tapes A, B, and C to work to be able to restore the latest version of a file.
In a commercial setting, individual workstations should be installed from a disk image, and no important information should be stored on them. Work files should be stored on a server's RAID array. (RAID reduces risk from hardware failure). This RAID array should be rsync'd with an off-site system periodically to reduce risk from physical damage or theft. Snapshots (backups) should be stored offline and offsite to allow deleted files to be recovered.
For critical data, use a filesystem such as XFS that supports filesystem snapshots. With a snapshot, you mount an existing filesystem as a snapshot. The snapshot volume then stores copies of the original of any files that are changed after the snapshot is taken and presents itself as a static, read-only filesystem. Backing up from the snapshot eliminates some issues that arise from the fact that during the time you are backing up a filesystem it can change. Check out this how-to for more information.
You can write scripts using tar, dump, and cpio. With tar and cpio you can reduce the size of a backup by compressing files using bzip2. Using scripts is good because it is not very hard and it allows you to customize backups to meet your requirements. It is important to remember to take dumps of databases properly. For example, by dumping an SQL file or instructing the database to sync to disk before running the backup. These tasks are quite easy with a custom backup script.
Amanda is good for heterogeneous networks and can work with most backup utilities.
It is also a good idea to use CVS or something similar, and commit to disk all work files every day. This strategy allows you to roll back to an earlier version without having to hunt through backup tapes.
Other products to look at for enterprise backup include IBM's Tivoli Storage Manager and Veritas NetBackup. For all environments check out Tapeware, from Yosemite Technologies. It supports many tapes including SDLT, LTO2, and DLTIV, can create temporary disk archives, and is not too expensive.
This was first published in August 2004