What You Can Do About It

If you are the system administrator of a Linux system and security is even a minor issue, then you definitely need to read "The Cuckoos Egg" by Cliff Stoll and Internet Security and Firewalls by Cheswick and Bellovin. Although we have covered some of the issues that they confronted and the techniques they used to monitor their intruders, there's nothing like reading it yourself. Plus, if you hear the true stories, they sink in better than hearing just the theory.

"The Cuckoos Egg" reads like a spy novel and is difficult to put down. Even though I knew the outcome before I started reading, it is difficult to put down. I say "is" because I am in the middle of it reading as I write this.

Watching Your System

In the preceding paragraphs, I detailed many of the holes that are used to break into a system. I also addressed the methods that hackers use to gain information about your system to exploit these holes. In this section, I am going to talk about specific methods people have used (including myself) to circumvent normal security.

One aspect of watching your system that can cause the most problems is what to do when you do see that someone is hacking your system. Remember that in many places the mere fact that someone has gained unauthorized access to your system, they have committed a crime. Like any criminal, they will want to cover their tracks. If you let them know you have caught them, they might end up removing all the files on your hard disk (rm -rf /) and then disappear.

Takes a look at the holes we talked about in the previous section. Use those as a guideline for determining what security measure you want to implement on your system.

Accounts

User accounts should be monitored and inactive ones should either be removed or disabled. "Inactive" should be defined by the company's security policy (e.g. three months). Users should be contacted by telephone and told that they need to come in person to get their accounts reactivated. All accounts must have passwords on them. If possible, configure the system to disallow null passwords.

User account areas (home directories, etc) should be monitored regularly to check for possible compromise. This includes removing or monitoring the contents of .rhosts and .forward files. These files need to be owned by the account for which they are in the home directory and permissions set to readable by the owner only (permissions 600).

Require that new user accounts be requested by the persons supervisor or someone else known to the system administrators. You don't want someone calling up and saying that they are new in the Accounting Department and need a new account. The request can be done via email, but confirmation of the request should be done telephonic in cases the supervisors account was compromised. All accounts, as well as changes to groups and permissions must be requested by the supervisors.

The root/administrator account should be the only account on the system that is shared. Only users that have a need should be given access to this account. Since the root password should be different for all machines, is then possible to give root access to only those machines that are necessary.

All guest accounts should be removed from the system. There is no need for a guest account. You should know in advanced that someone will be using the system and you can create an account for them. This limits access to the systems as well as provides a record of activity.

Monitor accounts that are no longer "active", as break-ins are less likely to be noticed. The "Cuckoos Egg" hacker used an account from someone who was on an extended leave. Since Cliff Stoll was aware of this, he knew that whoever was using the account was doing so "improperly". One alternative would be to simply remove the account. When the user returns a new account can be generated. If the person leaves the company then the account should be disabled or removed.

Know who is on vacation and consider disabling their account. Depending on the system, you could set up an at job that turns their account off the last day before they go and turns it back on the day they return. If that is not an option, occasional checks of the system to see if one of these people is logged in might provide clues to a break-in.

Many software products will create their own users. Be careful of these. Make sure you are aware of exactly what their purpose is. If deleting is not possible, make sure that they have limited access to the system. If there are guest accounts on your system and they are not needed, delete them.

Make sure that all accounts have passwords. If the system allows null passwords or simply the enter key, run your password cracker at least once a day to make sure.

Avoid group accounts, other than root/administrator. You can accomplish the same goal by placing everyone in a group and giving access permissions to that group.

Depending on how sensitive your data is, you might consider setting alarms on system an accounts for when they are accessed at "inappropriate" times. What these times are and who can access the system should be specified in your company's security policy (see below).

You can also get users to monitor their own accounts. By using the last command you can show the last time a user was logged in. By having the user check this themselves, you obviously save yourself the trouble, and they know better when they were logged in. Fortunately, this information is provide for you each time you log in. Therefore you can have your users check this and report any inconsistencies.

Passwords

Words that can be found in a dictionary are not good choices for passwords. With just a few lines of code, you could write a simple program that searched through a list of words and tried them all as passwords. However, if activated, Linux will prevent you from choosing any of these as your passwords. It also prevents you from making simple changes to the password like rotating (strawberry becomes awberrystr) or reversing (yrrebwarts).

The passwd program source is relatively easy to modify to add all of the features we discussed. When checking the validity of the password, the program could first check to see if the input was very obvious things like the users name. Next, a dictionary containing common words could be scanned. The input password could also rotated and reversed to see if they match anything on the "no-no" list.

Some systems have added the ability for the system to generate a password. This could be anything from generating random characters, like rY3h%n0& to combining random syllables like bofandi.

If your system doesn't allow you to select passwords for your users, you could regularly run a password cracking program. If you are successful in cracking a password that password must be changed immediately. Simply mail the user saying that it has been determined that the password selected is unacceptable and must be changed. Never include that password in a message.

Password attacks are perhaps the most common way of getting into a system and not bugs in the system itself. Studies have show that unless the system stops "bad" passwords, password guessing will eventually succeed. The hackers in the "Cuckoos Egg" used the same techniques I did to crack passwords and gain access. As Cliff showed, known or assumed accounts names and guesses at passwords succeed amazingly often.

Here are some guidelines when dealing with passwords:

Don'ts

• Don't use your login name in any form (as-is, reversed, capitalized, doubled, etc.).
• Don't use your first or last name in any form.
• Don't use your spouse's or child's name.
• Don't use other information easily obtained about you. This includes license plate numbers, telephone numbers, social security numbers, the brand of your automobile, the name of the street you live on, etc.
• Don't use a password of all digits, all the same letter or keyboard patterns like qwerty. This significantly decreases the search time for a cracker.
• Don't use a word contained in (English or foreign language) dictionaries, spelling lists, or other lists of words.
• Don't use a password shorter than six characters.
• Don't use the same password on multiple machines.
• Don't use a password that has appeared in any published work as being a "good" password.
• Don't ever use your password again, if it is discovered.

Do's

• Do use a password with mixed-case alphabetics.
• Do use a password with non-alphabetic characters, e.g., digits or punctuation.
• Do use a password that is easy to remember, so you don't have to write it down.
• Do use a password that you can type quickly, without having to look at the keyboard. This makes it harder for someone to steal your password by watching over your shoulder.
• Do change your password often.
• Do make remembering the password easier, so you don't have to write it down.
• Do choose a phrase and use the first letters of that phrase. You could also use a line from a song. For example, the first line of "Yellow Submarine" is "In the town, where I was born" would become: Ittwiwb.
• Do use some nonsensical word like slewblue
• Do combine words with some punctuation in the middle: rain;drain, lemon?curry

If you are a system administrator consider running something a password cracking program at regular intervals to see if users are actually using good passwords. Do not allow them to us them by replacing the password program on those machines where possible.

Keep Your Eyes Open

A prefect crime is more than just one where the perpetrator gets away clean. It is one where the crime is not even detected. If an intruder can access a system undetected he is safe. If you do detect an intruder, your company security policy (see below) should detail what to do. If you are monitoring his activity to see what other machines he is trying to break into, don't let him know you are there. If he is clever enough, he might have built in a backdoor, like one of those we discussed earlier.

Certain auditing packages like COPS will monitor and report on changes to key files. Even a shell script that simply compares values is sufficient to catch these kind of changes. Since hackers are aware of these kinds of tools, it is not a good idea to run them automatically from cron jobs. A hacker could look in the cron tabs and see what programs are being executed and either disable them or work around them.

Another thing you can use is SATAN (System Administration Tool for Analyzing Networks). This is an interactive, complex application that checks a wide range of security "issues." Although it didn't find any more security holes than I did by hand (in fact, I found more), it doesn't matter. SATAN is based on HTML and perl. You have all the source code and you can quickly expand it to exploit other holes that you know about. The problem is that as of this writing, certain browsers give it problems. You may have to change the way the browser reacts to the perl scripts. Its available at a lost of places, such as ftp://ftp.win.tue.nl/pub/security.

Know your system. Know what kind of activity is normal for every hour of the day. Imagine it's late Friday night and you know no one is still working. However one computer is busily working on some process. Is it an 'at' job that someone started? Or is it a crack program that's going through a password file? This is how one system administrator was able to detect a person trying to crack passwords.

What processes are normal? If suddenly a new program appears on your system and you are the only one who has access to a compiler or can install software, where did it come from? What processes run with UID of 1? Is someone's shell suddenly starts running with a UID of 1, you know you have a problem.

Excessive processes can result in a denial of service. That is, the system is so busy doing work for the hacking, that it doesn't have time do do other things. Although you can limit the number of processes each user has, if those processes are disk intensive, a hacker could bring the system to a standstill. If the hacker were to keep writing to the file system, you could run out of space or inodes which might cause the system to panic. Even if the system doesn't panic, cleaning up after this will cost a great deal of time and money.

Filesystem Security

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.

The Network

If you provide Internet or any network services you should monitor these as well. Remember that treats do not need to come from outside. Disgruntled employees or someone who has been bribed your competition can compromise security just as much as someone from outside. Good security does not mean pulling the plug on all network connections, but it does mean taking a few simple precautions.

User Comments: