24.4.1.1 Changes in file contents

An intruder who gains superuser privileges can change any file on your system. Although you should make a thorough inventory of your computer's entire filesystem, you should look specifically for any changes to the system that affect security. For example, an intruder may have inserted trap doors or logic bombs to do damage at a later point in time.

One way to easily locate changes to system programs is to use the checklists described in Chapter 5, The UNIX Filesystem .

24.4.1.2 Changes in file and directory protections

After a break-in, review the protection of every critical file on your system. Intruders who gain superuser privileges may change the protections of critical files to make it easier for them to regain superuser access in the future. For example, an intruder might have changed the mode of the /bin directory to 777 to make it easier to modify system software in the future, or altered the protections on /dev/kmem so as to be able to modify system calls directly using a symbolic debugger.

24.4.1.3 New SUID and SGID files

Computer crackers who gain superuser access frequently create SUID and SGID files. After a break-in, scan your system to make sure that new SUID files have not been created. See the section Section 5.5, "SUID" for information about how to do this.

24.4.1.4 Changes in .rhosts files

An intruder may have created new .rhosts files in your users' home directories, or may have modified existing .rhosts files. (The .rhosts file allows other users on the network to log into your account without providing a password. For more information, see Chapter 16 .) After a break-in, tell your users to check their .rhosts files to make sure that none of these files have been modified.

Chapter 16 also contains a shell script that you can use to get a list of every .rhosts file on the system. After a break-in, you may wish to delete every .rhosts file rather than take the chance that a file modified by the attacker won't be caught by the account's rightful owner. After all, the .rhosts file is simply a convenience, and your legitimate users can recreate their .rhosts files as necessary.[4]

[4] At some sites, this may be a drastic measure, and might make some of your users very angry, so think it over carefully before taking this step. Alternatively, you could rename each .rhosts file to rhosts.old so that the file will not be used, and so that your users do not need to retype the entire file's contents.

24.4.1.5 Changes to the /etc/hosts.equiv file

An intruder may have added more machines to your /etc/hosts.equiv file, so be sure to check for changes to this file. Also, check your /etc/netgroups and /etc/exports files (or equivalent) if you are running NIS or NFS .

24.4.1.6 Changes to startup files

An intruder may have modified the contents of dot (.) files in your users' home directories. Instruct all of your users to check these files and report anything suspicious. You can force your users to check the files by renaming them to names like login.old , cshrc.old , and profile.old . Be sure to check the versions of those files belonging to the root user, and also check the /etc/profile file.

If you are using sendmail , the attacker may have created or modified the .forward files so that they run programs when mail is received. This aspect is especially critical on nonuser accounts such as ftp and uucp .

If you know the precise time that the intruder was logged in, you can list all of the dot files in users' home directories, sort the list by time of day, and then check them for changes. A simple shell script to use is shown below:

#!/bin/ksh  
# Search for .files in home directories  
for user in $(cat-passwd | /bin/awk -F: "length($6) > 0 {print $6}") 
do  
    for name in $user/.* 
    do
       [[ $name == $user/.. ]] && continue
       [[ -f $name ]] && print "$name"
    done 
done | xargs ls -ltd 

However, using timestamps may not detect all modifications, as discussed at the end of this chapter. The -c and -l options to the ls command should be used to also check for modifications to permission settings, and to determine if the mtime was altered to hide a modification.

Another approach is to sweep the entire filesystem with the find command and observe what files and directories were accessed around the time of the intrusion. This may give you some clues as to what was done. For instance, if your compiler, loader, and libraries all show access times within a few seconds of each other, you can conclude that the intruder compiled something.

If you decide to take this approach, we suggest that you first remount all your filesystems as read-only so that your examinations don't alter the saved filesystem dates and times.

24.4.1.7 Hidden files and directories

The intruder may have created a "hidden directory" on your computer, and be using it as a repository for stolen information or for programs that break security.

On older UNIX systems, one common trick for creating a hidden directory was to unlink (as root ) the ".." directory in a subdirectory and then create a new one. The contents of such a hidden directory are overlooked by programs such as find that search the filesystem for special files. Modern versions of UNIX , however, detect such hidden directories as inconsistencies when you run the /etc/fsck program. For this reason, be sure to run fsck on each filesystem as part of your routine security monitoring.

On some HP-UX systems, intruders have stored their tools and files in a CDF (Context Dependent File) directory. On these systems, be sure to use the -H option to find and ls when you are looking for files that are out of place.

Nowadays, intruders often hide their files in directories with names that are a little difficult to discover or enter on the command line. This way, a novice system administrator who discovers the hidden directory will be unlikely to figure out how to access its contents. Filenames that are difficult to discover or enter include ".." (dot dot space), control characters, backspaces, or other special characters.

You can often discover hidden directories easily because they cause results that differ from those of normal directories. For example:

prose% 
ls -l 

drwxr-xr-x 1 orpheus 1024 Jul 17 11:55 foobar 
prose% 
cd foobar 

foobar: No such file or directory 
prose%

In this case, the real name of the directory is foobar , with a space following the letter r . The easy way of entering filenames like this one is to use the shell's wildcard capability: The wildcard *ob* will match the directory foobar , no matter how many spaces or other characters it has in it, as long the letters o and b are adjacent.

prose% 
ls -l 

drwxr-xr-x 1 orpheus 1024 Jul 17 11:55 foobar 
prose% 
cd *ob* prose%

If you suspect that a filename has embedded control characters, you can use the cat -v command to determine what they are. For example:

% 
ls -l 

total 1 
-rw-r--r-- 1 john 21 Mar 10 23:38 bogus?file 
% 
echo * | cat -v 

bogus^Yfile 
%

In this example, the file bogus?file actually has a CTRL -Y character between the letters " bogus " and the letters "file" . Some versions of the ls command print control characters as question marks (?). To see what the control character actually was, however, you must send the raw filename to the cat command, which is accomplished with the shell echo .

If you are using the 93 version of the Korn shell, you can also list all the files in the local directory in a readable manner. This approach works even when your ls command has been replaced with an altered version:

$ 
printf $'entry: %'' .* * 

entry: . 
entry: .. 
entry: $'..\n' 
entry: $'bogus\031file' 
entry: temp0001 entry: temp0002 $

24.4.1.8 Unowned files

Sometimes attackers leave files in the filesystem that are not owned by any user or group - that is, the files have a UID or GID that does not correspond to any entries in the /etc/passwd and /etc/group files. This can happen if the attacker created an account and some files, and then deleted the account - leaving the files. Alternatively, the attacker might have been modifying the raw inodes on a disk and changed a UID by accident.

You can search for these files with the find command, as shown in the following example:

# find / -nouser -o -nogroup -print

Remember, if you are using NFS , you should instead run the following find command on each server:

# find / \( -local -o -prune \) -nouser -o -nogroup -print

You might also notice unowned files on your system if you delete a user from the /etc/passwd file but leave a few of that user's files on the system. It is a good idea to scan for unowned files on a regular basis, copy them to tape (in case they're ever needed), and then delete them from your system.