Knowing what the permissions should be is useful in detecting intruders or other improper activity. If the permissions on files (particularly programs) get changed, you should know why. This is especially important if the files are SUID. If a program is owned by root and changed to be SUID, this could allow someone improper access to the system.
Fortunately, the rpm database has much of the necessary information. Among the information stored is the permissions of the files, owner, group and a checksum. Well go into details on using rpm to check this later on.
You should also check the write permissions on all system directories and files. If an intruder has write permissions on a system directory, he can change log files or add his own version of system programs. While you’re at it check the ownership of system directories as well. It does little good if no one but the owner can write to a file, but the owner is a normal user.
In principle, no one should have write permission to a users home directory other than the user. If some else has write permission, they can overwrite that users .rhosts file. Even if the file is write protected, write permission on the directory means the file can be erased and a new one put in its place. You should also check the existence and content of .rhosts files to ensure that they do not give too much access. Obviously, if .rhosts are not allowed at all, they should be removed.
I also recommend that you be aware of every SUID or SGID program on your system. Know what it is there for and why it should be SUID/SGID. If you know that you won’t need it, consider removing it or changing the permissions. Also, check ownership of all system directories and files. There are some files on the system that need to be writable by everyone. Make sure you know which ones they are so you can see if there have been any changes.
Look for files without an owner. That is, the owner in the inode does not have an entry in /etc/passwd. This could be innocent, when a user has one UID on one machine and another UID on other machine. Using cpio or tar to copy files, the UID of the source is copied to the new machines. This happened to me once, but maybe there is something else behind it. Both -nouser and -nogroup are options to find so it’s easy to hunt for these files.
Check specifically for “wierd” filenames like “…” (three dots) or “..(space)” or “..(backspace)” or anything that might be unusual. It is “possible” that these files were created by accident, but they are common ways of hiding files on a system. Someone could also create filenames with control characters in them. This could help mask them. On most systems, the ls command has an option (e.g. -q) that will print out the directory list with a ? instead of the control characters.
If you system does not have RPM compatible packages, you should create a list of important information, prior to adding any users. Make a complete list of your entire system. Include the owner, group and permissions. For binaries and other non-writable files, get sizes and creation dates. Include the sums, using the sum command or create M5D checksums using one of the tools available on the net. These should never change. Maybe the inode number itself is important, as well. If the inode is different, that means the file was copied.
Once you have your checklist, move it someplace away from that machine. It should NOT be stored on the local machine. If a clever hacker gets into the machine and finds this list, what’s to prevent him from changing it so it matches the modifications he made to your system?
Devices nodes are one group of files that are often overlooked. Check access permissions on device nodes like mem, kmem, hard disks, tape drives. If the intruder has write permission on /dev/kmem or the hard disk, he can change things directly without using the standard tools. In addition, there is rarely a reason why device nodes should exist anywhere other than in /dev. If you find one, find out why it’s there. Check the major and minor to see what kind of device it is.