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.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved. The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use
and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look
here