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.
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, is 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 which is gentler.
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!
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.
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.
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 remove this argument from any modules of 'auth' type for services that allow login. This is usually the login service, 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 |
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.
While password-cracking tools can be by attackers used 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 facorite distribution. John the Ripper can be obtained from 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.
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 Shadow Password HOWTO is outdated, but it might be of some help.