773 lines
36 KiB
Plaintext
773 lines
36 KiB
Plaintext
User Authentication HOWTO
|
||
|
||
Peter Hernberg
|
||
|
||
Floris Lambrechts - Language changes, various small fixes (v0.8).
|
||
|
||
2000-05-02
|
||
Revision History
|
||
Revision 0.8 2003-02-20 Revised by: fl
|
||
language changes, various small fixes
|
||
Revision 0.5 2000-05-15 Revised by: ph
|
||
added section on securing pam, added resources section
|
||
Revision 0.1 2000-05-02 Revised by: ph
|
||
initial version
|
||
|
||
|
||
Explains how user and group information is stored and how users are
|
||
authenticated on a Linux system (PAM), and how to secure you system's user
|
||
authentication.
|
||
|
||
-----------------------------------------------------------------------------
|
||
Table of Contents
|
||
1. Introduction
|
||
1.1. How this document came to be
|
||
1.2. New versions
|
||
1.3. Feedback
|
||
1.4. Copyrights and Trademarks
|
||
1.5. Acknowledgements and Thanks
|
||
1.6. Assumptions about the reader
|
||
|
||
|
||
2. How User Information is Stored on Your System
|
||
2.1. /etc/passwd
|
||
2.2. Shadow passwords
|
||
2.3. /etc/group and /etc/gshadow
|
||
2.4. MD5 encrypted passwords
|
||
2.5. Sifting through the mess
|
||
|
||
|
||
3. PAM (Pluggable Authentication Modules)
|
||
3.1. Why
|
||
3.2. What
|
||
3.3. How
|
||
3.4. Getting more information
|
||
|
||
|
||
4. Securing User Authentication
|
||
4.1. A strong /etc/pam.d/other
|
||
4.2. Disabling logins for user with null passwords
|
||
4.3. Disable unused services
|
||
4.4. Password-cracking tools
|
||
4.5. Shadow and MD5 passwords
|
||
|
||
|
||
5. Tying it all together
|
||
5.1. Apache + mod_auth_pam
|
||
5.2. Our example
|
||
5.3. Installing mod_auth_pam
|
||
5.4. Configuring PAM
|
||
5.5. Configuring Apache
|
||
5.6. Testing our setup
|
||
|
||
|
||
6. Resources
|
||
6.1. PAM
|
||
6.2. General Security
|
||
6.3. Offline Documentation
|
||
|
||
|
||
7. Conclusion
|
||
|
||
1. Introduction
|
||
|
||
1.1. How this document came to be
|
||
|
||
When trying to add a number of (mostly unnecessary :) network services to my
|
||
existing home network, I kept running into the problem of authentication, so
|
||
I decided to figure out how authentication works on linux systems, write a
|
||
HOWTO, and call it my senior project. I hope this document helps you
|
||
understand this often-forgotten, but very important, aspect of system
|
||
administration.
|
||
-----------------------------------------------------------------------------
|
||
|
||
1.2. New versions
|
||
|
||
Unitl I get my domain up and running properly, the newest version of this
|
||
document will be available from http://www.linuxdoc.org/.
|
||
-----------------------------------------------------------------------------
|
||
|
||
1.3. Feedback
|
||
|
||
Comments, corrections, suggestions, flames, and flying saucer sightings can
|
||
be sent to petehern@yahoo.com.
|
||
-----------------------------------------------------------------------------
|
||
|
||
1.4. Copyrights and Trademarks
|
||
|
||
(c) 2000 Peter Hernberg
|
||
|
||
This manual may be reproduced in whole or in part, without fee, subject to
|
||
the following restrictions:
|
||
|
||
<EFBFBD><EFBFBD>*<2A>The copyright notice above and this permission notice must be preserved
|
||
complete on all complete or partial copies
|
||
|
||
<EFBFBD><EFBFBD>*<2A>Any translation or derived work must be approved by the author in writing
|
||
before distribution.
|
||
|
||
<EFBFBD><EFBFBD>*<2A>If you distribute this work in part, instructions for obtaining the
|
||
complete version of this manual must be included, and a means for
|
||
obtaining a complete version provided.
|
||
|
||
<EFBFBD><EFBFBD>*<2A>Small portions may be reproduced as illustrations for reviews or quotes
|
||
in other works without this permission notice if proper citation is
|
||
given. Exceptions to these rules may be granted for academic purposes:
|
||
Write to the author and ask. These restrictions are here to protect us as
|
||
authors, not to restrict you as learners and educators. Any source code
|
||
(aside from the SGML this document was written in) in this document is
|
||
placed under the GNU General Public License, available via anonymous FTP
|
||
from the GNU archive.
|
||
|
||
|
||
-----------------------------------------------------------------------------
|
||
1.5. Acknowledgements and Thanks
|
||
|
||
Thanks to my family for putting up with me for 18 years. Thanks to the Debian
|
||
folks for making such a sweet distro for me to play with. Thanks to [http://
|
||
www.cgr.org/] CGR for paying me to be a geek. Thanks to Sandy Harris for his
|
||
helpful suggestions. Finally, I'd like thank the makers of ramen noodles,
|
||
because I don't know how I'd live without them.
|
||
-----------------------------------------------------------------------------
|
||
|
||
1.6. Assumptions about the reader
|
||
|
||
For the purpose of this document, it is assumed that the reader is
|
||
comfortably with executing commands at the command line and editing text
|
||
configuration files.
|
||
-----------------------------------------------------------------------------
|
||
|
||
2. How User Information is Stored on Your System
|
||
|
||
2.1. /etc/passwd
|
||
|
||
On almost all linux distributions (and commercial *nixes as well), user
|
||
information is stored in /etc/passwd, a text file which contains the user's
|
||
login, their encrypted password, a unique numerical user id (called the uid),
|
||
a numerical group id (called the gid), an optional comment field (usually
|
||
containing such items as their real name, phone number, etc.), their home
|
||
directory, and their preferred shell. A typical entry in /etc/passwd looks
|
||
something like this:
|
||
pete:K3xcO1Qnx8LFN:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
|
||
|
||
|
||
As you can see, it's pretty straight-forward. Each entry contains the six
|
||
fields I described above, with each field separated by a colon. If this were
|
||
as complex as user authentication got, there would be no need for this HOWTO.
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.2. Shadow passwords
|
||
|
||
Looking at your /etc/passwd, it's likely that you actually saw something like
|
||
this:
|
||
pete:x:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
|
||
|
||
|
||
Where did the encrypted password go? Before I tell you where it went, a bit
|
||
explanation is required.
|
||
|
||
The /etc/passwd file, which contains information about all users, including
|
||
their encrypted password, is readable by all users, making it possible for
|
||
any user to get the encrypted password of everyone on the system. Though the
|
||
passwords are encrypted, password-cracking programs are widely available. To
|
||
combat this growing security threat, shadow passwords were developed.
|
||
|
||
When a system has shadow passwords enabled, the password field in /etc/passwd
|
||
is replaced by an "x" and the user's real encrypted password is stored in /
|
||
etc/shadow. Because /etc/shadow is only readable by the root user, malicious
|
||
users cannot crack their fellow users' passwords. Each entry in /etc/shadow
|
||
contains the user's login, their encrypted password, and a number of fields
|
||
relating to password expiration. A typical entry looks like this:
|
||
pete:/3GJllg1o4152:11009:0:99999:7:::
|
||
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.3. /etc/group and /etc/gshadow
|
||
|
||
Group information is stored in /etc/group. The format is similar to that of /
|
||
etc/passwd, with the entries containing fields for the group name, password,
|
||
numerical id (gid), and a comma-separated list of group members. An entry in
|
||
/etc/group looks like this:
|
||
pasta:x:103:spagetti,fettucini,linguine,vermicelli
|
||
|
||
|
||
As you can see from the "x" in the password field, group passwords can be
|
||
shadowed as well. Although groups almost never have their own passwords, it
|
||
is worth noting that shadowed group password information is stored in /etc/
|
||
gshadow.
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.4. MD5 encrypted passwords
|
||
|
||
Traditionally, unix passwords were encrypted with the standard crypt()
|
||
function. (For more information on the crypt() function, see the crypt(3)
|
||
manpage.) As computers grew faster, passwords encrypted with this function
|
||
became easier to crack. As the internet emerged, tools for distributing the
|
||
task of password-cracking across multiple hosts became available. Many
|
||
'newer' distributions ship with the option of encrypting passwords with the
|
||
stronger MD5 hash algorithm. (For more information on the MD5 hash algorithm,
|
||
consult RFC 1321.) While MD5 passwords will not eliminate the threat of
|
||
password cracking, they will make cracking your passwords much more
|
||
difficult.
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.5. Sifting through the mess
|
||
|
||
As you can see, there are a number of different ways user authentication
|
||
information can be stored on your system (shadow passwords without MD5
|
||
encryption, /etc/passwd passwords with MD5 encryption, etc.). How do programs
|
||
like login and su know how to verify your password? Worse yet, what if you
|
||
wanted to change the way passwords are stored on your system? How will
|
||
programs that need your password know that passwords are stored differently?
|
||
PAM is the answer.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3. PAM (Pluggable Authentication Modules)
|
||
|
||
Pluggable authentication modules are at the core of user authentication in
|
||
any modern linux distribution.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.1. Why
|
||
|
||
Back in the good old days of linux, if a program, such as su, passwd, login,
|
||
or xlock, needed to authenticate a user, it would simply read the necessary
|
||
information from /etc/passwd. If it needed to change the users' password, it
|
||
would simply edit /etc/passwd. This simple but clumsy method presented
|
||
numerous problems for system administrators and application developers. As
|
||
MD5 and shadow passwords became increasingly popular, each program requiring
|
||
user authentication had to know how to get the proper information when
|
||
dealing with a number of different schemes. If you wanted to change your user
|
||
authentication scheme, all these programs had to be recompiled. PAM
|
||
eliminates this mess by enabling programs to transparently authenticate
|
||
users, regardless of how user information is stored.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.2. What
|
||
|
||
Quoting from the [http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
|
||
pam.html] Linux-PAM System Administrator's Guide: "It is the purpose of the
|
||
Linux-PAM project to separate the development of privilege granting software
|
||
from the development of secure and appropriate authentication schemes. This
|
||
is accomplished by providing a library of functions that an application may
|
||
use to request that a user be authenticated." With PAM, it doesn't matter
|
||
whether your password is stored in /etc/passwd or on a server in Hong Kong.
|
||
When a program needs to authenticate a user, PAM provides a library
|
||
containing the functions for the proper authentication scheme. Because this
|
||
library is loaded dynamically, changing authentication schemes can be done by
|
||
simply editing a configuration file.
|
||
|
||
Flexibility is one of PAM's greatest strengths. PAM can be configured to deny
|
||
certain programs the right to authenticate users, to only allow certain users
|
||
to be authenticated, to warn when certain programs attempt to authenticate,
|
||
or even to deprive all users of login privileges. PAM's modular design gives
|
||
you complete control over how users are authenticated.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.2.1. Distributions that support pam.
|
||
|
||
Nearly all popular distributions have supported PAM for some time. Here's an
|
||
incomplete list of distributions that support PAM:
|
||
|
||
<EFBFBD><EFBFBD>*<2A>Redhat since version 5.0
|
||
|
||
<EFBFBD><EFBFBD>*<2A>Mandrake since 5.2
|
||
|
||
<EFBFBD><EFBFBD>*<2A>Debian since version 2.1 (partial support in 2.1 -- complete support in
|
||
2.2)
|
||
|
||
<EFBFBD><EFBFBD>*<2A>Caldera since version 1.3
|
||
|
||
<EFBFBD><EFBFBD>*<2A>Turbolinux since version 3.6
|
||
|
||
<EFBFBD><EFBFBD>*<2A>SuSE since version 6.2
|
||
|
||
|
||
This list is certainly incomplete and possibly inaccurate. I'd appreciate it
|
||
if you sent any corrections or additions to this list to <petehern@yahoo.com
|
||
>.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.2.2. Installing PAM
|
||
|
||
Installing PAM from scratch is long process, beyond the scope of this HOWTO.
|
||
If PAM isn't installed on your system, you're probably running such an old
|
||
version of your distribution that there are many other reasons to upgrade. If
|
||
you really want to do it yourself, then you're certainly not the sort of
|
||
person who needs any help from me. For all these reasons, I'm going to assume
|
||
that you already have PAM installed.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.3. How
|
||
|
||
Enough talk, let's dig in.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.3.1. PAM configuration files
|
||
|
||
PAM configuration files are stored in the /etc/pam.d/ directory. (If you
|
||
don't have /etc/pam.d/ directory, don't worry, I'll cover that in the next
|
||
section) Let's go over there and take a look.
|
||
~$ cd /etc/pam.d
|
||
/etc/pam.d/$ ls
|
||
chfn chsh login other passwd su xlock
|
||
/etc/pam.d/$
|
||
|
||
|
||
Your system may have a few more or a few less files in this directory,
|
||
depending on what's installed on your system. Whatever the details, you
|
||
probably saw a file for each of the programs on your system that authenticate
|
||
users. As you probably already guessed, each file contains the PAM
|
||
authentication configuration for the program it's named after (except for the
|
||
other file, which we'll talk about in a little bit). Let's take a look the
|
||
PAM configuration file for login (I've condensed the file for the sake of
|
||
simplicity):
|
||
/etc/pam.d/$ cat login
|
||
# PAM configuration for login
|
||
auth requisite pam_securetty.so
|
||
auth required pam_nologin.so
|
||
auth required pam_env.so
|
||
auth required pam_unix.so nullok
|
||
account required pam_unix.so
|
||
session required pam_unix.so
|
||
session optional pam_lastlog.so
|
||
password required pam_unix.so nullok obscure min=4 max=8
|
||
|
||
|
||
Before I dig into this file, I must mention a little something.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.3.2. A little something
|
||
|
||
A small percentage of the readers are probably thinking, "Oh no! I don't have
|
||
a /etc/pam.d directory! Your list of distributions says that my distribution
|
||
includes PAM, but I can't find that directory. Without PAM, my life is empty
|
||
and meaningless! What can I do?" Don't worry, all is not lost. If you know
|
||
that your distribution includes PAM, but you have no /etc/pam.d/ directory,
|
||
then your PAM configuration is stored in /etc/pam.conf. Rather than being
|
||
spread across several files, all your PAM configuration is stored in a single
|
||
file. This adds a little twist to PAM configuration, but the proper
|
||
adjustments are pointed out in section 3.3.4.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.3.3. Configuration syntax
|
||
|
||
PAM configuration files have the following syntax:
|
||
type control module-path module-arguments
|
||
|
||
|
||
Using the login configuration file (see above) as an example let's take a
|
||
look a the syntax for PAM configuration files:
|
||
|
||
PAM configuration tokens
|
||
|
||
type
|
||
The type token tells PAM what type of authentication is to be used for
|
||
this module. Modules of the same type can be "stacked", requiring a user
|
||
to meet multiple requirements to be authenticated. PAM recognizes four
|
||
types:
|
||
|
||
account
|
||
Determines whether the user is allowed to access the service, whether
|
||
their passwords has expired, etc.
|
||
|
||
auth
|
||
Determines whether the user is who they claim to be, usually by a
|
||
password, but perhaps by a more sophistcated means, such as
|
||
biometrics.
|
||
|
||
password
|
||
Provides a mechanism for the user to change their authentication.
|
||
Again, this usually their password.
|
||
|
||
session
|
||
Things that should be done before and/or after the user is
|
||
authenticed. This might included things such as mounting/unmounting
|
||
the user home directory, logging their login/logout, and restricting/
|
||
unrestricting the services available to the user.
|
||
|
||
|
||
In the login config file, we see at least one entry for each type. Since
|
||
this the program that allows user to login (hence the name :), it's
|
||
understandable that it needs to access all of the different types of
|
||
authentication.
|
||
|
||
control
|
||
The control token tells PAM what should be done in if authentication by
|
||
this module fails. PAM recognizes four control types:
|
||
|
||
requisite
|
||
Failure to authenticate via this module results in immediate denial
|
||
of authentication.
|
||
|
||
required
|
||
Failure also results in denial of authentication, although PAM will
|
||
still call all the other modules listed for this service before
|
||
denying authentication.
|
||
|
||
sufficient
|
||
If authentication by this module is successful, PAM will grant
|
||
authentication, even if a previous required module failed.
|
||
|
||
optional
|
||
Whether this module succeeds or fails is only significant if it is
|
||
the only module of its type for this service.
|
||
|
||
|
||
In the configuration file for login, we see nearly all of the different
|
||
control types. Most of the required modules are pam_unix.so (the main
|
||
authentication module), the single requisite module is pam_securetty.so
|
||
(which makes sure the user is logging in on a secure console), and the
|
||
only optional module is pam_lastlog.so (the module that retrieves
|
||
information on the user's most recent login).
|
||
|
||
module-path
|
||
The module-path tells PAM which module to use and (optionally) where to
|
||
find it. Most configurations only contain the module's name, as is the
|
||
case in our login configuration file. When this is the case, PAM looks
|
||
for the modules in the default PAM module directory, normally /usr/lib/
|
||
security. However, if your linux distribution conforms to the Filesystem
|
||
Hierarchy Standard (FHS), PAM modules can be found in /lib/security.
|
||
|
||
module-arguments
|
||
The module-arguments are arguments to be passed to the module. Each
|
||
module has its own arguments. For example, in our login configuration,
|
||
the "nulok" ("null ok", argument being passed to pam_unix.so module,
|
||
indicating the a blank ("null") password is acceptable ("ok").
|
||
|
||
|
||
-----------------------------------------------------------------------------
|
||
3.3.4. pam.conf configuration
|
||
|
||
If your PAM configuration is stored in /etc/pam.conf rather than /etc/pam.d/,
|
||
PAM configuration lines are a bit different. Rather than each service having
|
||
its own configuration file, all configurations are stored in /etc/pam.conf
|
||
with the service name as the first token in a configuration line. For
|
||
example, the following line in /etc/pam.d/login:
|
||
auth required pam_unix.so nulok
|
||
|
||
|
||
would become the following line in /etc/pam.conf:
|
||
login auth required pam_unix.so nulok
|
||
|
||
|
||
Except for this minor difference, all the rest of the configuration PAM
|
||
syntax applies.
|
||
-----------------------------------------------------------------------------
|
||
|
||
3.4. Getting more information
|
||
|
||
For more information on configuring PAM and complete PAM module reference,
|
||
consult the [http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
|
||
pam.html] Linux-PAM System Administrator's Guide. This guide serves as a
|
||
thorough and up-to-date reference on PAM configuration.
|
||
-----------------------------------------------------------------------------
|
||
|
||
4. Securing User Authentication
|
||
|
||
Many linux distributions ship with user authentication that is not adequately
|
||
secure. This section discusses some of the ways you make user authentication
|
||
secure on your system. While doing these things will make your system more
|
||
secure, do not be so naive as to think they make you invulnerable.
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.1. A strong /etc/pam.d/other
|
||
|
||
All of the files in /etc/pam.d/ contain the configuration for a particular
|
||
service. The notable exception to this rule is the /etc/pam.d/other file.
|
||
This file contains the configuration for any services which do not have their
|
||
own configuration file. For example, if the (imaginary) xyz service attempted
|
||
authentication, PAM would look for a /etc/pam.d/xyz file. Not finding one,
|
||
authentication for xyz would be determined by the /etc/pam.d/other file.
|
||
Since /etc/pam.d/other is the configuration to which PAM services fallback,
|
||
it is important that it is secure. We will discuss two secure configurations
|
||
of /etc/pam.d/other, one which is quite nearly paranoid and one which is
|
||
gentler.
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.1.1. A paranoid configuration
|
||
|
||
A paranoid configuration of /etc/pam.d/other is as follows:
|
||
auth required pam_deny.so
|
||
auth required pam_warn.so
|
||
account required pam_deny.so
|
||
account required pam_warn.so
|
||
password required pam_deny.so
|
||
password required pam_warn.so
|
||
session required pam_deny.so
|
||
session required pam_warn.so
|
||
|
||
|
||
With this configuration, whenever an unknown service attempts to access any
|
||
of the four configuration types, PAM denies authentication (via the
|
||
pam_deny.so module) and then logs a syslog warning (via the pam_warn.so
|
||
module). Short of a bug in PAM, this configuration is brutally secure. The
|
||
only problem with that brutality is it may cause problems if your
|
||
accidentally delete the configuration of another service. If your /etc/pam.d/
|
||
login was mistakenly deleted, no one would be able to login!
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.1.2. A kinder configuration
|
||
|
||
Here's configuration that isn't quite so mean:
|
||
auth required pam_unix.so
|
||
auth required pam_warn.so
|
||
account required pam_unix.so
|
||
account required pam_warn.so
|
||
password required pam_deny.so
|
||
password required pam_warn.so
|
||
session required pam_unix.so
|
||
session required pam_warn.so
|
||
|
||
|
||
This configuration will allow an unknown service to authenticate (via the
|
||
pam_unix.so module), although it will not allow it to change the user's
|
||
password. Although it allows authentication by unknown services, it logs a
|
||
syslog warning whenever such a service attempts authentication.
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.1.3. Choosing a /etc/pam.d/other
|
||
|
||
I would strongly reccomend that you implement the first /etc/pam.d/other
|
||
configuration unless you have a very good reason not to. It always a good
|
||
idea to be 'secure by default'. If you ever do need to grant a new service
|
||
authentication privileges, you can simply create a PAM configuration file for
|
||
that service.
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.2. Disabling logins for user with null passwords
|
||
|
||
On most linux systems, there a number of "dummy" user accounts, used to
|
||
assign privileges to certain system services like ftp, webservers, and mail
|
||
gateways. Having these accounts allows your system to be more secure, because
|
||
if these services are compromised, an attacker will only gain the limited
|
||
privileges available to the dummy account, rather than the full privileges of
|
||
a service running as root. However, allowing these dummy account login
|
||
privileges is a security risk, as they usually have blank (null) passwords.
|
||
The configuration option that enables null passwords is the "nullok"
|
||
module-argument. You'll want to remove this argument from any modules of
|
||
'auth' type for services that allow login. This is usually the login service,
|
||
but it may also include services like rlogin and ssh. Hence, the following
|
||
line in /etc/pam.d/login:
|
||
auth required pam_unix.so nullok
|
||
|
||
|
||
should be changed to:
|
||
auth required pam_unix.so
|
||
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.3. Disable unused services
|
||
|
||
Looking at the files in /etc/pam.d/, you'll probably see configuration files
|
||
for a number of programs you don't use and maybe even a few you've never
|
||
heard of. Although allowing authentication to these services probably won't
|
||
open any huge security holes, you're better off denying them authentication.
|
||
The best way to disable PAM authentication for these programs is to rename
|
||
these files. Not finding the file named after the service requesting
|
||
authentication, PAM will fallback to the (hopefully) very secure /etc/pam.d/
|
||
other. If you later find that you need one of these programs, you can simply
|
||
rename the file to its original name and everything will work as it was
|
||
intended.
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.4. Password-cracking tools
|
||
|
||
While password-cracking tools can be used by attackers to compromise a
|
||
system, they can also be used by system administrators as proactive tool to
|
||
ensure the strength of passwords on their system. The two most commonly used
|
||
password-cracking tools are "crack" and "John the Ripper". Crack is probably
|
||
included in your favorite distribution. John the Ripper can be obtained from
|
||
[http://www.false.com/security/john/index.html] http://www.false.com/security
|
||
/john/index.html. Run the tools against your password database and you'll
|
||
probably be surprised with what they come up with.
|
||
|
||
Additionally, there is a PAM module which utilizes the crack library to check
|
||
the strength of a users password whenever it changed. When this module is
|
||
installed, the user can only change their password to one which meets the
|
||
minimum password strength.
|
||
-----------------------------------------------------------------------------
|
||
|
||
4.5. Shadow and MD5 passwords
|
||
|
||
As was discussed in the first section of this document, Shadow and MD5
|
||
passwords can make your system more secure. During the installation
|
||
procedure, most modern distributions will ask whether you want to install MD5
|
||
and/or Shadow passwords. Unless you have a good reason not to, you should
|
||
enable these. The process of converting from non-shadowed/non-MD5 passwords
|
||
is a complicated process, and is beyond the scope of this document. The
|
||
[http://www.linuxdoc.org/HOWTO/Shadow-Password-HOWTO.html] Shadow Password
|
||
HOWTO is outdated, but it might be of some help.
|
||
-----------------------------------------------------------------------------
|
||
|
||
5. Tying it all together
|
||
|
||
In this section, I'll give a simple example which ought to help tie together
|
||
what's in the previous section.
|
||
-----------------------------------------------------------------------------
|
||
|
||
5.1. Apache + mod_auth_pam
|
||
|
||
As our example, we'll install and configure mod_auth_pam, an Apache module
|
||
that allows you to authenticate users of your webserver using PAM. For the
|
||
purpose of this example, I'll assume you have apache installed. If it's not
|
||
installed already you should be able find installation packages from your
|
||
distributor.
|
||
-----------------------------------------------------------------------------
|
||
|
||
5.2. Our example
|
||
|
||
Our goal will be to configure a restricted area of our webserver, a family/
|
||
directory, to authenticate users via PAM. This directory contains private
|
||
family information, and should only be accessible to members of the user
|
||
group family.
|
||
-----------------------------------------------------------------------------
|
||
|
||
5.3. Installing mod_auth_pam
|
||
|
||
First, you'll want to download mod_auth_pam from [http://blank.pages.de/pam/
|
||
mod_auth_pam/] http://blank.pages.de/pam/mod_auth_pam/. The following
|
||
commands will compile mod_auth_pam (you must be logged in as root):
|
||
~# tar xzf mod_auth_pam.tar.gz
|
||
~# cd mod_auth_pam-1.0a
|
||
~/mod_auth_pam-1.0a# make
|
||
~/mod_auth_pam-1.0a# make install
|
||
|
||
|
||
If you have any trouble installing the mod_auth_pam module, make sure you've
|
||
installed your distribution's apache-dev package. After you've installed
|
||
mod_auth_pam, you'll need to restart apache. Apache can usually by restarted
|
||
by typing the following command (again, you must be root):
|
||
~# /etc/init.d/apache restart
|
||
|
||
-----------------------------------------------------------------------------
|
||
|
||
5.4. Configuring PAM
|
||
|
||
The PAM configuration for Apache is stored in /etc/pam.d/httpd. The default
|
||
configuration (which was installed when you installed mod_auth_pam) is
|
||
secure, but it uses a module (pam_pwdb.so) which may not be available on many
|
||
systems. (Besides, configuring it from scratch will be fun!) So delete the /
|
||
etc/pam.d/httpd file, and start with a fresh one.
|
||
-----------------------------------------------------------------------------
|
||
|
||
5.4.1. Deciding how to configure PAM
|
||
|
||
If we're going to configure how PAM deals with Apache's authentication
|
||
requests, we need to figure out exactly what we need PAM to check for. First,
|
||
we want PAM to make sure the user's password matches their password in the
|
||
standard unix password database. This sounds like the 'auth' type and the
|
||
pam_unix.so module. We'll want the module's control type to be set to
|
||
'required', so authentication will fail without a correct password. Here's
|
||
what the first line of our /etc/pam.d/httpd looks like:
|
||
auth required pam_unix.so
|
||
|
||
|
||
Secondly, we must make sure that the users account is valid (i.e. their
|
||
password has not expired or any such nastiness). This is the 'account' type
|
||
and is also provided by the pam_unix.so module. Again, we'll set this
|
||
module's control type to 'required'. After adding this line, our /etc/pam.d/
|
||
httpd configuration looks like this:
|
||
auth required pam_unix.so
|
||
account required pam_unix.so
|
||
|
||
|
||
It's not terribly sophisticated, but it does the job. It ought to be a good
|
||
start for learning how to configure PAM services.
|
||
-----------------------------------------------------------------------------
|
||
|
||
5.5. Configuring Apache
|
||
|
||
Now that PAM is configured to authenticate apache's requests, we'll configure
|
||
apache to properly utilize PAM authentication to restrict access to the
|
||
family/ directory. To do so, add the following lines to your httpd.conf
|
||
(usually stored in /etc/apache/ or /etc/httpd):
|
||
<Directory /var/www/family>
|
||
AuthPAM_Enabled on
|
||
AllowOverride None
|
||
AuthName "Family Secrets"
|
||
AuthType "basic"
|
||
require group family
|
||
</Directory>
|
||
|
||
|
||
You may need to replace /var/www/ with the default location of web documents,
|
||
which is often /home/httpd/. Wherever that is, you'll need to create the
|
||
family directory.
|
||
|
||
Before we test our setup, I'll take a moment to explain the Apache
|
||
configuration you just entered. The <Directory> directive is used to
|
||
encapsulate configuration data for this directory. Inside this directive,
|
||
we've enabled PAM authentication ("AuthPAM_enabled on"), turned off any
|
||
overriding of this configuration ("AllowOverride none"), named this
|
||
authentication zone "Family Secrets" ("AuthName "Family Secrets""), set the
|
||
http authentication (not the PAM authentication) type to the default
|
||
("AuthType "basic""), and required the user group family ("require group
|
||
family").
|
||
-----------------------------------------------------------------------------
|
||
|
||
5.6. Testing our setup
|
||
|
||
Now that we've got everything setup up properly, it's time to revel in our
|
||
success. Fire up your favorite web browser and head over to http://
|
||
your-domain/family/ (replacing your-domain with, well, your domain). You are
|
||
now an uber-authenticator!
|
||
-----------------------------------------------------------------------------
|
||
|
||
6. Resources
|
||
|
||
There are a number of resources, both online and offline, where you can more
|
||
information about user authentication. If you know of any resources that
|
||
ought to be added to this list, drop me a line at <petehern@yahoo.com>
|
||
-----------------------------------------------------------------------------
|
||
|
||
6.1. PAM
|
||
|
||
<EFBFBD><EFBFBD>*<2A>[http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html]
|
||
Linux-PAM System Administrator's Guide
|
||
|
||
<EFBFBD><EFBFBD>*<2A>[http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
|
||
pam_modules.html] Linux-PAM Module Writer's Manual
|
||
|
||
<EFBFBD><EFBFBD>*<2A>[http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
|
||
pam_modules.html] Linux-PAM Application Developer's Manual
|
||
|
||
|
||
-----------------------------------------------------------------------------
|
||
6.2. General Security
|
||
|
||
<EFBFBD><EFBFBD>*<2A>[http://www.linuxsecurity.com/] linuxsecurity.com
|
||
|
||
<EFBFBD><EFBFBD>*<2A>[http://www.securitywatch.com] securitywatch.com
|
||
|
||
<EFBFBD><EFBFBD>*<2A>[http://www.linuxdoc.org/HOWTO/Security-HOWTO.html] Security HOWTO
|
||
|
||
<EFBFBD><EFBFBD>*<2A>[http://packetstorm.securify.com] Packetstorm
|
||
|
||
|
||
-----------------------------------------------------------------------------
|
||
6.3. Offline Documentation
|
||
|
||
A lot of information can be gathered from your system's manual pages. The
|
||
following are some manpages relating to user authentication. The number in
|
||
parentheses refers to the manpage section. To view the passwd(5) manpage, you
|
||
would enter man 5 passwd.
|
||
|
||
<EFBFBD><EFBFBD>*<2A>passwd(5)
|
||
|
||
<EFBFBD><EFBFBD>*<2A>crypt(3)
|
||
|
||
<EFBFBD><EFBFBD>*<2A>pam.d(5)
|
||
|
||
<EFBFBD><EFBFBD>*<2A>group(5)
|
||
|
||
<EFBFBD><EFBFBD>*<2A>shadow(5)
|
||
|
||
|
||
-----------------------------------------------------------------------------
|
||
7. Conclusion
|
||
|
||
I hope you found this HOWTO helpful. If you have any questions, comments, or
|
||
suggestions, I'd love to hear from you. You can email me at <
|
||
petehern@yahoo.com>.
|