لطفا منتظر باشید ...
Controlling
Accounts and Passwords
If a server exists, it's a potential door
into your computer. There are several different ways to lock this door. One is
to use firewall tools like iptables (discussed in
which works only with some servers, is to pay careful attention to user
accounts and passwords on the computer. Servers that use these features can
become vulnerable if the computer hosts unused accounts or if passwords fall
into the wrong hands. This method of control requires a partnership between you
as a system administrator and all of your users, so it's important that you
communicate the risks of poor password choice, password use over unencrypted
connections, and so on to your users.
Account Creation Procedures and Policies
The first step in protecting your system
through account security is to develop and follow appropriate procedures and
policies for the creation of accounts. To use the analogy of servers as doors,
every account is a key that can open a door (often several doors). By
minimizing the number of accounts on the computer, you reduce the risk that a
key to enter your system will be abused. Of course, many servers need user accounts. Without user accounts, a
file-sharing server is of limited utility, an FTP server can be used only for
anonymous access, and so on. The trick is to determine when you really need to
create a particular user account.On some servers, the answer is simple: You don't create user accountsat least, not for anybody
but a handful of administrators (perhaps just one). Earlier chapters in this
book have described the circumstances in which a server requires user accounts.
Many servers, such as font, DHCP, and time servers, don't need user accounts,
and so such computers can easily do without user accounts. Other server
systems, such as Web and FTP servers, may or may not need user accounts,
depending upon precisely how they're to be used. Remote login servers are
usually run on computers that host many user accounts, so these systems always
require user accounts.Assuming a computer needs ordinary user
accounts, you should have a clearly defined policy regarding use of that
computer that you can use to guide when to create an account. For instance, a
computer in a university's physics department might exist for use by faculty,
staff, and students associated with that department, so you should have a
policy to create accounts only for those individuals. Formalizing these
policies can help avoid an expansion that might be undesirable from a security
point of view. You can change these policies if they become too constricting,
but it's easy for a system to acquire unused or unnecessary accounts if your
account-creation policies are too lax or informal. This formalization is
particularly important if the computer has many users.You may also want to develop scripts or a
checklist to follow when creating user accounts. One particularly important
detail in this process is how you set the password. The upcoming section,
"
default permissions system for your computer. For instance, you might want to
create separate project groups and assign users to specific groups, and assign
permissions on home directories to restrict who may access whose files. Appropriate
policies vary greatly from one environment to another, so you'll have to
develop your settings with your particular needs in mind. In an open
environment, loose home directory permissions such as 0755 or even 0775 may be
in order, with a matching umask value for file creation; but in an environment
in which intra-system security is more important, you may need to set tight
0700 home directory permissions with restrictive umasks.
Monitoring Account Usage
Once you've created accounts for your users,
you may want to monitor those accounts to see that they aren't abused. There
are two key aspects to this monitoring: Checking for inactive accounts and
checking for abuses of active accounts.
Handling Inactive Accounts
User accounts are seldom permanent. Students
graduate and employees move on to other jobs, for instance. Whenever an
account falls into disuse, it should be disabled or removed to minimize the
risk of its being abused. If you receive a notice that the user has left your
organization or should no longer have an account for some other reason, you can
manually disable or delete the account. You might not always receive such a
notification, though. One way to help automate the process is to create
accounts that automatically expire, or that have passwords that expire. You can
use the usermod command to set
an expiration date on an account, thus: # usermod -e 2003-07-04 george
This command tells the system that the george account will become inactive on
July 4, 2003. (You can use the -e
parameter to useradd to create
an account with an expiration date initially, as well.) This approach is most
useful when you know that a given user will no longer need an account after a
certain date, such as with student accounts and those for temporary employees.A less drastic approach is to set up an expiring password.
These require the user to change the password on a regular basis, such as once
a month. You can do this with the chage
command, thus: # chage -M 30 -W 5 george
This command tells the system that george must change his password every 30 days, and to warn george of an impending deadline 5 days
before the fact. If george
doesn't change his password, the account will be disabled and require
administrative intervention to be used again.These automated processes can help reduce problems, but they
aren't appropriate for all situations. For instance, if the account exists for
some nonlogin process, such as file sharing via a Samba server or mail delivery
only, users may not see password expiration messages, at least not unless you
create custom cron jobs to check for impending account expirations and notify users,
say by sending them e-mail about the upcoming password expirations. There are
some active steps you can take to monitor account usage. For instance, the last command returns information on the
last few logins, and many distributions maintain a log file called /var/log/auth in which information on
authentication is stored. If you want to be very diligent, you might even set
up a cron job to monitor system log files, note when users log in, and notify
you if an account goes unused for more than some given period of time. You can
use these tools to monitor account usage, and if an account falls into disuse,
investigate further to determine if it should be deleted.You might need to take active administrative steps to alter
account availability. For instance, once an account has automatically expired,
you might want to delete it if you know it won't be used again. You might want
to write a script that checks for expired accounts and reports back to you if
it finds any. (These accounts can be identified because the third
colon-delimited field in /etc/shadow
contains a smaller value than the eighth field.)
Checking
for Account Abuse
A nightmare for any system administrator is a local account that's
being abused. Perhaps one of your users is untrustworthy, and is using the
computer to attack other systems, or even the local system itself. Another
possibility is that an outsider might have hijacked a user's account in order
to abuse it.One way to check for abuse is to look for suspicious activity
in your system log files, such as /var/log/messages
and /var/log/secure . (Precisely
what log files exist, and what information they contain, varies from one
distribution to another.) System log files mostly monitor the activity of
servers, though, not of clients. Therefore, you might not see any evidence of a
local user abusing, say, a Telnet client to attack another system. Such
evidence might turn up in a firewall's log files, though, depending on your
network's configuration. You might also see suspicious activity if your system
comes under attack from outside.Unfortunately, checking for such abuses by scanning log files
is tedious at best. Automated tools like the Simple Watcher (SWATCH,
files for key strings that might indicate trouble, but such tools aren't
foolproof.One potentially important step you can take in tracking, if
not preventing, abuse of your system is to run the auth server (also known as identd ).
When a client on your system contacts an external server, that server might try contacting yours to find the identity of
the user who makes the outgoing connection. If your user causes trouble on the
remote system, that system's administrator can contact you and tell you who was
causing problems, because the username will be recorded in the remote system's
logs. This process only works, of course, if identd
is installed and running on your system, and if it's not been compromised
itself. (Most distributions ship with this server, which is very basic and so
requires only minimal configuration. It's normally run from a super server.) Ultimately, your ability to track and prevent abuse of your
local systems is limited. You can be alert to suspicious local activity, such
as processes that should not be running, but closely monitoring all the
activity on even a single computer is far more work than a single system
administrator can undertake.
Setting
Good Passwords
In order to use passwords, computers must store them on disk.
Typically, computers encrypt passwords, generally using a hash, or one-way encryption algorithm. In Linux,
password files are usually stored in /etc/shadow
(old Linux systems often used /etc/passwd ).
This practice makes a password file useless even if a cracker obtains itor so
it would be in a perfect world. Increasing CPU power and disk space have made
it possible for crackers to encrypt entire dictionaries that span multiple
languages and include many proper names and variant spellings, letter order
reversals, and so on. If a cracker obtains an encrypted password file, the
cracker can compare the file's entries to the encrypted results from the
dictionary file. If a match results, the cracker has learned the password.For this reason, the best passwords are random collections of
letters, numbers, and any other characters the computer allows for a password.
Such random strings are unlikely to appear in a cracker's password-cracking
dictionary. Unfortunately, random passwords are hard to remember, so most
people pick easy-to-rememberand therefore easy-to-breakpasswords. A
reasonable compromise is to build something that won't appear in a dictionary
but that has personally memorable characteristics. This process is two-step:
First, build a base, and then modify that base.To build a base, take a pair of unrelated words and merge them
together, such as bunpen; or use an acronym
that has meaning only to you, such as yiwttd
(for yesterday I went to the dentist ). This
base is easy for you to remember and should not appear in a dictionary. It's
best if the base is as long as possible. (I used six-character bases as
examples because eight is the limit on some systems, and subsequent
modifications will increase the length.) Nonetheless, a cracker might stumble
upon your base by combining words from a dictionary. Therefore, further
modifications are necessary.Possible modifications include: Mix case If your system's passwords are case-sensitive, mix up the case
randomly, as in BUnPeN or YiWTtd. Many systems use case-insensitive passwords,
though, so this step may not help security in all situations. For instance,
Windows uses case-insensitive passwords for its SMB/CIFS file sharing. Add digits or
punctuation Add two or three randomly selected
digits or punctuation, creating something like BU3nP&eN
or Y+iWTtd2. Reverse a word If you used two words as your base, reverse the letter order of
one of them. This might produce BU3nNe&P,
for instance.Further modifications are, of course,
possible. The key is that, despite the random appearance of these end results,
the person who produced them can regenerate the password with relative ease. Such
passwords therefore need not be written down or stored unencrypted on a
computer. These two practices both greatly degrade security, because the paper
or computer file might fall into the wrong hands.If you want to check that your users'
passwords are good, you can use a password cracking program on them, such as
Crack ( http://www.users.dircon.co.uk/~crypto/ ). If the program delivers a password to you, you can help the user
create a better password.WARNING
align=left border=0> If you run a password-cracking program, do
it on a computer that's not connected to any
network to eliminate the risk that a cracker will stumble across your
efforts. Also, as with port scanning, password cracking is grounds for
dismissal from many employers, so if you want to do this to improve local
security, be sure to obtain permission first!
In addition to creating good passwords, users
should take pains to keep passwords secure. This means that users should never
write down passwords or give them to other people (even friends, family
members, or co-workers). You should explicitly tell your users that you will
never need to know their passwords; there have been scams in the past where
crackers have claimed to be system administrators and asked for passwords, and
users have fallen for the ruse.Even if users create good passwords and don't
give them away, they can be discovered through various means. One is shoulder surfing, in which a cracker observes a user
in a public area typing in the password. This is a real risk in public computer
centers such as those common on university campuses, and to a lesser extent in
the cubicle farms common in many companies. Another risk, which has been
described elsewhere in this book, is password sniffing,
in which a computer on a network is programmed to recover passwords sent
between other computers on the network. This is a risk both on local networks
and on the Internet at large. You can minimize the risk on local Ethernet
networks by using switches rather than hubs; switches don't echo data to all
connected devices, so the sniffer would have to be on the client or server
computer itself to acquire a password. A still better approach is to use
protocols that encrypt the password, rendering an intercepted password useless.
