Product SiteDocumentation Site

4.11. 提供安全的用户访问

4.11.1. 用户认证: PAM

PAM (Pluggable Authentication Modules) allows system administrators to choose how applications authenticate users. Note that PAM can do nothing unless an application is compiled with support for PAM. Most of the applications that are shipped with Debian have this support built in (Debian did not have PAM support before 2.2). The current default configuration for any PAM-enabled service is to emulate UNIX authentication (read /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz for more information on how PAM services should work in Debian).
每个带有PAM支持的服务在 /etc/pam.d/ 下都有一个配置文件, 可以通过修改它来完成配置:
  • 认证使用什么样的后端.
  • 会话使用什么样的后端.
  • 如何进行密码检测.
The following description is far from complete, for more information you might want to read the Linux-PAM Guides as a reference. This documentation is available in the system if you install the libpam-doc at /usr/share/doc/libpam-doc/html/.
PAM offers you the possibility to go through several authentication steps at once, without the user's knowledge. You could authenticate against a Berkeley database and against the normal passwd file, and the user only logs in if the authentication succeeds in both. You can restrict a lot with PAM, just as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its second element. Generally it should be set to requisite, which returns a login failure if one module fails.

4.11.2. Password security in PAM

Review the /etc/pam.d/common-password, included by /etc/pam.d/passwd[16] This file is included by other files in /etc/pam.d/ to define the behaviour of password use in subsystems that grant access to services in the machine, like the console login (login), graphical login managers (such as gdm or lightdm), and remote login (such as sshd). This definition is
You have to make sure that the module uses the "sha512" option to use encrypted passwords. This is the default in Debian Squeeze.
The line with the definition of the pam_unix module will look something like:
  password   [success=1 default=ignore] nullok obscure minlen=8 sha512 
This definition:
  • Enforces password encryption when storing passwords, using the SHA-512 hash function (option sha512),
  • Enables password complexity checks (option obscure) as defined in the pam_unix(8) manpage,
  • Imposes a minimum password length (option min) of 8.
You have to ensure that encrypted passwords are used in PAM applications, since this helps protect against dictionary cracks. Using encryption also makes it possible to use passwords longer than 8 characters.
Since this module is also used to define how passwords are changed (it is included by chpasswd) you can strengthen the password security in the system by installing libpam-cracklib and introducing this definition in the /etc/pam.d/common-password configuration file:
  # Be sure to install libpam-cracklib first or you will not be able to log in
  password   required retry=3 minlen=12 difok=3
  password   [success=1 default=ignore] obscure minlen=8 sha512 use_authok
So, what does this incantation do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum size [17] of 12 characters, and difference of at least 3 characters from the old password, and allows 3 retries. Cracklib depends on a wordlist package (such as wenglish, wspanish, wbritish, ...), so make sure you install one that is appropriate for your language or cracklib might not be useful to you at all.
The second line (using the module) is the default configuration in Debian, as described above, save for the use_authok option. The use_authok option is required if is stacked after, and is used to hand over the password from the previous module. Otherwise, the user would be prompted for the password twice.
For more information about setting up Cracklib, read the pam_cracklib(8) manpage and the article Linux Password Security with pam_cracklib by Hal Pomeranz.
By enabling the cracklib PAM module you setup a policy that forces uses to use strong passwords.
Alternatively, you can setup and configure PAM modules to use double factor authentication such as: libpam-barada, libpam-google-authenticator, libpam-oath, libpam-otpw, libpam-poldi, libpam-usb or libpam-yubico. The configuration of these modules would make it possible to access the system using external authentication mechanisms such as smartcards, external USB keys, or One-Time-Passwords generated by external applications running, for example, in the user's mobile phone.
Please note that these restrictions apply to all users but not to the password changes done by the root user. The root user will be able to set up any password (any length or complexity) for personal use or others regardless of the restrictions defined here.

4.11.3. User access control in PAM

可以在 /etc/pam.d/login 中加入一下行, 以确保 root 用户只能从本地终端登录:
  auth     requisite
Then you should modify the list of terminals on which direct root login is allowed in /etc/securetty (as described in 第 4.7 节 “限制控制台登录”). Alternatively, you could enable the pam_access module and modify /etc/security/access.conf which allows for a more general and fine-tuned access control, but (unfortunately) lacks decent log messages (logging within PAM is not standardized and is particularly unrewarding problem to deal with). We'll return to access.conf a little later.

4.11.4. User limits in PAM

The following line should be enabled in /etc/pam.d/login to set up user resource limits.
  session  required
This restricts the system resources that users are allowed (see below in 第 4.11.8 节 “资源的限制使用: limits.conf 文件”). For example, you could restrict the number of concurrent logins (of a given group of users, or system-wide), number of processes, memory size etc.

4.11.5. Control of su in PAM

If you want to protect su, so that only some people can use it to become root on your system, you need to add a new group "wheel" to your system (that is the cleanest way, since no file has such a group permission yet). Add root and the other users that should be able to su to the root user to this group. Then add the following line to /etc/pam.d/su:
  auth        requisite group=wheel debug
以确保只有组 "wheel" 的用户可以使用 su 成为root. 其它用户不能成为 root. 事实上如果他们试图成为 root 将会得到一条拒绝信息.
If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow users 'ref' to log in via ssh. So you put them into /etc/sshusers-allowed and write the following into /etc/pam.d/ssh:
  auth        required item=user sense=allow file=/etc/sshusers-allowed onerr=fail

4.11.6. Temporary directories in PAM

Since there have been a number of so called insecure tempfile vulnerabilities, thttpd is one example (see DSA-883-1), the libpam-tmpdir is a good package to install. All you have to do is add the following to /etc/pam.d/common-session:
 session    optional
There has also been a discussion about adding this by default in Debian configuration, but it s. See for more information.

4.11.7. Configuration for undefined PAM applications

Finally, but not least, create /etc/pam.d/other and enter the following lines:
  auth     required
  auth     required
  auth     required
  auth     required
  account  required
  account  required
  account  required
  password required
  password required
  password required
  session  required
  session  required
  session  required
这些内容为所有的支持 PAM 的应用程序提供了很不错的默认设置(默认访问拒绝).

4.11.8. 资源的限制使用: limits.conf 文件

You should really take a serious look into this file. Here you can define user resource limits. In old releases this configuration file was /etc/limits.conf, but in newer releases (with PAM) the /etc/security/limits.conf configuration file should be used instead.
If you do not restrict resource usage, any user with a valid shell in your system (or even an intruder who compromised the system through a service or a daemon going awry) can use up as much CPU, memory, stack, etc. as the system can provide. This resource exhaustion problem can be fixed by the use of PAM.
There is a way to add resource limits to some shells (for example, bash has ulimit, see bash(1)), but since not all of them provide the same limits and since the user can change shells (see chsh(1)) it is better to place the limits on the PAM modules as they will apply regardless of the shell used and will also apply to PAM modules that are not shell-oriented.
Resource limits are imposed by the kernel, but they need to be configured through the limits.conf and the PAM configuration of the different services need to load the appropriate PAM. You can check which services are enforcing limits by running:
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
Commonly, login, ssh and the graphic session managers (gdm, kdm or xdm) should enforce user limits but you might want to do this in other PAM configuration files, such as cron, to prevent system daemons from taking over all system resources.
The specific limits settings you might want to enforce depend on your system's resources, that's one of the main reasons why no limits are enforced in the default installation.
For example, the configuration example below enforces a 100 process limit for all users (to prevent fork bombs) as well as a limit of 10MB of memory per process and a limit of 10 simultaneous logins. Users in the adm group have higher limits and can produce core files if they want to (there is only a soft limit).
*              soft    core            0
*              hard    core            0
*              hard    rss             1000
*              hard    memlock         1000
*              hard    nproc           100
*              -       maxlogins       1
*              hard    data            102400
*              hard    fsize           2048
@adm           hard    core            100000
@adm           hard    rss             100000
@adm           soft    nproc           2000
@adm           hard    nproc           3000
@adm           hard    fsize           100000
@adm           -       maxlogins       10
These would be the limits a default user (including system daemons) would have:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 2048
max locked memory     (kbytes, -l) 10000
max memory size       (kbytes, -m) 10000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 100
virtual memory        (kbytes, -v) unlimited
And these are the limits for an administrative user:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 100000
max locked memory     (kbytes, -l) 100000
max memory size       (kbytes, -m) 100000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 2000
virtual memory        (kbytes, -v) unlimited

4.11.9. 用户登录: 编辑 /etc/login.defs

The next step is to edit the basic configuration and action upon user login. Note that this file is not part of the PAM configuration, it's a configuration file honored by login and su programs, so it doesn't make sense tuning it for cases where neither of the two programs are at least indirectly called (the getty program which sits on the consoles and offers the initial login prompt does invoke login).
  FAILLOG_ENAB        yes
如果您使用这个变量, 将会记录失败的登录. 这对跟踪尝试暴力攻击者非常重要.
If you set this variable to 'yes' it will record unknown usernames if the login failed. It is best if you use 'no' (the default) since, otherwise, user passwords might be inadvertenly logged here (if a user mistypes and they enter their password as the username). If you set it to 'yes', make sure the logs have the proper permissions (640 for example, with an appropriate group setting such as adm).
  SYSLOG_SU_ENAB      yes
启用这个参数将在 syslog 中记录试图 su 的操作. 对于重要的机器这相当重要, 同时也要注意这可能引起保密性问题.
  SYSLOG_SG_ENAB      yes
The same as SYSLOG_SU_ENAB but applies to the sg program.
As stated above, encrypted passwords greatly reduce the problem of dictionary attacks, since you can use longer passwords. This definition has to be consistent with the value defined in /etc/pam.d/common-password.

4.11.10. User login actions: edit /etc/pam.d/login

You can adjust the login configuration file to implement an stricter policy. For example, you can change the default configuration and increase the delay time between login prompts. The default configuration sets a 3 seconds delay:
auth       optional  delay=3000000
Increasing the delay value to a higher value to make it harder to use the terminal to log in using brute force. If a wrong password is typed in, the possible attacker (or normal user!) has to wait longer seconds to get a new login prompt, which is quite time consuming when you test passwords. For example, if you set delay=10000000, users will have to wait 10 seconds if they type a wrong password.
In this file you can also set the system to present a message to users before a user logs in. The default is disabled, as shown below:
# auth       required issue=/etc/issue
If required by your security policy, this file can be used to show a standard message indicating that access to the system is restricted and user acess is logged. This kind of disclaimer might be required in some environments and jurisdictions. To enable it, just include the relevant information in the /etc/issue[18] file and uncomment the line enabling the module in /etc/pam.d/login. In this file you can also enable additional features which might be relevant to apply local security policies such as:
  • setting rules for which users can access at which times, by enabling the module and configuring /etc/security/time.conf accordingly (disabled by default),
  • setup login sessions to use user limits as defined in /etc/security/limits.conf (enabled by default),
  • present the user with the information of previous login information (enabled by default),
  • print a message (/etc/motd and /run/motd.dynamic) to users after login in (enabled by default),

4.11.11. 限制ftp: 编辑 /etc/ftpusers

文件 /etc/ftpusers 包含不允许使用 ftp 登录主机的用户名单. 如果你真的想允许 ftp 就使用这个文件(通常不推荐使用, 因为它使用明文传送密码). 如果您的守护进程支持 PAM, 您也可用它来定义某些服务对用户的允许和拒绝.
FIXME(BUG): 这是一个缺陷,Debian 中缺省的 ftpusers 不包括所有管理员用户(在 base-passwd 中).
A convenient way to add all system accounts to the /etc/ftpusers is to run
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers

4.11.12. 使用 su

如果您真的需要系统中的用户变为超级用户, 例如, 安装软件包或增加用户, 您可以使用 su 命令来改变身份. 您应该设法避免任何人使用 root 登录系统, 而应当使用su. 实际上, 最好的解决办法是删除 su, 而是使用 sudo, 因为它比 su 有更多特点. 但是, su 在类unix系统上 更具通用性.

4.11.13. 使用 sudo

sudo allows the user to execute defined commands under another user's identity, even as root. If the user is added to /etc/sudoers and authenticates correctly, the commands defined in /etc/sudoers get enabled. Violations, such as incorrect passwords or trying to run a program you don't have permission for, are logged and mailed to root.

4.11.14. 禁止管理员远程访问

您应当修改 /etc/security/access.conf 以禁止管理员远程登录. 这样用户就需要使用 su (或 sudo), 无论本地用户什么时候使用管理员权限, 就都可以进行跟踪了.
您需要在 /etc/security/access.conf 中加入如下行, 缺省的 Debian 配置文件中这一行被注释掉了:
Remember to enable the pam_access module for every service (or default configuration) in /etc/pam.d/ if you want your changes to /etc/security/access.conf honored.

4.11.15. 限制用户访问

有时候您也许认为需要创建本地用户以执行特定的服务(pop3 邮件服务或 ftp). 动手前, 首先记得, Debian GNU/Linux 系统中的 PAM 工具允许使用各种外部地址服务器提供的 libpam 软件包来认证用户(radius, ldap, 等等).
If users need to be created and the system can be accessed remotely take into account that users will be able to log in to the system. You can fix this by giving users a null (/dev/null) shell (it would need to be listed in /etc/shells). If you want to allow users to access the system but limit their movements, you can use the /bin/rbash, equivalent to adding the -r option in bash (RESTRICTED SHELL see bash(1) ). Please note that even with restricted shell, a user that access an interactive program (that might allow execution of a subshell) could be able to bypass the limits of the shell.
Debian currently provides in the unstable release (and might be included in the next stable releases) the pam_chroot module (in the libpam-chroot). An alternative to it is to chroot the service that provides remote logging (ssh, telnet). [19]
如果您要对通过 ssh 访问你的系统的用户有所限制, 可以按照自己的需求来编辑 /etc/security/access.conf .
关于 chroot 用户如何通过 ssh 服务访问系统的内容参见第 B.7 节 “Chroot environment for SSH.

4.11.16. 用户检测

如果您是个偏执狂, 也许希望添加一个系统范围的配置文件来来检测用户在您的系统里所做的操作. 本部分提供一些不同工具使用的小窍门. 输入输出检测脚本

您可以使用本 script 命令来审核用户运行的命令和这些命令的输出. 您不能把 script 配置为一个 shell(即使您把它添加到 /etc/shells 中). 但是您可以配置 shell 的初始化程序运行下边的内容:
umask 077
exec script -q -a "/var/log/sessions/$USER"
当然, 如果您要在系统范围内设置, 那就意味着 shell不嗯个连续的读取个人初始化文件(因为 shell已经被 script 修改). 另一种可用的方法是在用户的初始化文件中完成这一工作(但, 这样的话用户就可能将其删除, 参阅下边的内容)
您还需要在检测目录中(这个例子中是 /var/log/sessions/)配置此文件, 这样用户就可写入内容, 但是不能删除. 例如, 可以通过预先创建用户会话文件, 并用 chattr 设置 append-only 标志来完成这一配置.
另一个对系统管理有用的方案, 其包括日期信息:
umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`" 使用 shell 的历史记录文件

If you want to review what does the user type in the shell (but not what the result of that is) you can setup a system-wide /etc/profile that configures the environment so that all commands are saved into a history file. The system-wide configuration needs to be setup in such a way that users cannot remove audit capabilities from their shell. This is somewhat shell specific so make sure that all users are using a shell that supports this.
For example, for bash, the /etc/profile could be set as follows [20] :
  # Don't let the users enter commands that are ignored
  # in the history file
  readonly HISTFILE
  readonly HISTSIZE
  readonly HISTIGNORE
  readonly HISTCONTROL
For this to work, the user can only append information to .bash_history file. You need also to set the append-only option using chattr program for .bash_history for all users. [21].
Note that you could introduce the configuration above in the user's .profile. But then you would need to setup permissions properly in such a way that prevents the user from modifying this file. This includes: having the user's home directories not belong to the user (since the user would be able to remove the file otherwise) but at the same time allow the user to read the .profile configuration file and write on the .bash_history. It would be good to set the immutable flag (also using chattr) for .profile too if you do it this way. 使用帐号工具完成用户检测

前边的例子是一个配置用户检测的简单方法, 但是对于复杂系统或用户根本就不(或很少)使用 shell 的系统, 用处不大. 如果碰到这种情况, 您需要求助于acct, 这个帐号检测工具. 这个工具会在空闲磁盘上记录用户或系统进程运行的所有命令.
当启用的帐号, 所有的有关进程和用的信息保存在 /var/account/ 目录下, 更确切的是在 pacct 中. 这个帐号软件包包括一些分析这些数据的工具(saac). 其它的用户检测方法 为 .profile 文件设置 inmutable 标志位(同样用到 chattr)是个不错的选择

If you are completely paranoid and want to audit every user's command, you could take bash source code, edit it and have it send all that the user typed into another file. Or have ttysnoop constantly monitor any new ttys [22] and dump the output into a file. Other useful program is snoopy (see also github: which is a user-transparent program that hooks in as a library providing a wrapper around execve() calls, any command executed is logged to syslogd using the authpriv facility (usually stored at /var/log/auth.log).

4.11.17. 检查用户的 profile

如果您要查看用户通常在做些什么, 可以在用户连入时使用包括所有登录信息的 wtmp 数据库. 有几个工具可以处理这个文件, 其中 sac 可以对每个用户产生一个 profile 文件,显示此用户经常登录的时间段.
如果您启用了记账系统, 您还可以用其提供的工具来确定用户的登录时间和执行的命令.

4.11.18. 设置用户的 umask

Depending on your user policy you might want to change how information is shared between users, that is, what the default permissions of new files created by users are.
Debian's default umask setting is 022 this means that files (and directories) can be read and accessed by the user's group and by any other users in the system. This definition is set in the standard configuration file /etc/profile which is used by all shells.
If Debian's default value is too permissive for your system you will have to change the umask setting for all the shells. More restrictive umask settings include 027 (no access is allowed to new files for the other group, i.e. to other users in the system) or 077 (no access is allowed to new files to the members the user's group). Debian (by default[23]) creates one group per user so that only the user is included in its group. Consequently 027 and 077 are equivalent as the user's group contains only the user.
This change is set by defining a proper umask setting for all users. You can change this by introducing an umask call in the shell configuration files: /etc/profile (source by all Bourne-compatible shells), /etc/csh.cshrc, /etc/csh.login, /etc/zshrc and probably some others (depending on the shells you have installed on your system). You can also change the UMASK setting in /etc/login.defs, Of all of these the last one that gets loaded by the shell takes precedence. The order is: the default system configuration for the user's shell (i.e. /etc/profile and other system-wide configuration files) and then the user's shell (his ~/.profile, ~/.bash_profile, etc...). Some shells, however, can be executed with a nologin value which might skip sourcing some of those files. See your shell's manpage for additional information.
For connections that make use of login the UMASK definition in /etc/login.defs is used before any of the others. However, that value does not apply to user executed programs that do not use login such as those run through su, cron or ssh.
Don't forget to review and maybe modify the dotfiles under /etc/skel/ since these will be new user's defaults when created with the adduser command. Debian default dotfiles do not include any umask call but if there is any in the dotfiles newly created users might a different value.
Note, however that users can modify their own umask setting if they want to, making it more permissive or more restricted, by changing their own dotfiles.
The libpam-umask package adjusts the users' default umask using PAM. Add the following, after installing the package, to /etc/pam.d/common-session:
session    optional umask=077
Finally, you should consider changing root's default 022 umask (as defined in /root/.bashrc) to a more strict umask. That will prevent the system administrator from inadvertenly dropping sensitive files when working as root to world-readable directories (such as /tmp) and having them available for your average user.

4.11.19. 限制用户查看/访问的内容

FIXME: Content needed. Describe the consequences of changing packages permissions when upgrading (an admin this paranoid should chroot his users BTW) if not using dpkg-statoverride.
如果您需要授予用户通过 shell 访问系统的权限, 应该仔细考虑清楚. 一个用户, 除非是在非常苛刻的环境下(如 chroot jail) ,可以查看有关您系统的许多信息,包括:
  • some configuration files in /etc. However, Debian's default permissions for some sensitive files (which might, for example, contain passwords), will prevent access to critical information. To see which files are only accessible by the root user for example
    find /etc -type f -a -perm 600 -a -uid 0
    as superuser.
  • 通过查看软件包数据库, 或者查看/usr/share/doc目录, 或通过查看您系统中的二进制文件和库, 来猜测您所安装的软件包.
  • some log files at /var/log. Note also that some log files are only accessible to root and the adm group (try
    find /var/log -type f -a -perm 640
    ) and some are even only available to the root user (try
    find /var/log -type f -a -perm
        600 -a -uid 0
一个用户在您的系统里可以看到什么? 可能许多东西, 试试这个(先做一下深呼吸):
  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null
The output is the list of files that a user can see and the accessable directories. 限制用户对于其他用户信息的访问

如果您允许用户通过 shell 访问, 但是想限制其对于其他用户信息的查看. 用户通过 shell 访问会在其主目录下产生很多文件: 邮箱, 个人文件, X/GNOME/KDE 应用程序的配置文件...
在Debian中每个用户创建是都产生一个附加组, 并且没有两个用户属于同一个组. 这是缺省设置: 当 userX 创建时, 产生一个他所属的名为 userX 组. 这样可以避免因为用户组的概念, 难以对其他用户隐藏信息.
However, users' $HOME directories are created with 0755 permissions (group-readable and world-readable). The group permissions is not an issue since only the user belongs to the group, however the world permissions might (or might not) be an issue depending on your local policy.
You can change this behavior so that user creation provides different $HOME permissions. To change the behavior for new users when they get created, change DIR_MODE in the configuration file /etc/adduser.conf to 0750 (no world-readable access).
Users can still share information, but not directly in their $HOME directories unless they change its permissions.
Note that disabling world-readable home directories will prevent users from creating their personal web pages in the ~/public_html directory, since the web server will not be able to read one component in the path - namely their $HOME directory. If you want to permit users to publish HTML pages in their ~/public_html, then change DIR_MODE to 0751. This will allow the web server to access the final public_html directory (which itself should have a mode of 0755) and provide the content published by users. Of course, we are only talking about a default configuration here; users can generally tune modes of their own files completely to their liking, or you could keep content intended for the web in a separate location which is not a subdirectory of user's $HOME directory.

4.11.20. 生成用户密码

很多情况下, 管理员需要创建多个账号, 并为其设置密码. 当然, 管理员可以简单的将其设为与用户账号相同, 但是这是非常不明智的. 一个比较好的办法是使用密码生成程序. Debian提供了 makepasswd, apgpwgen 软件包(程序名与包名相同). Makepasswd 可以产生注重于安全而不是可读性的真正的随机密码, pwgen 则试图产生无意义但具有可读性的密码. apg 则同时提供了这两种算法 (这个程序还有个C/S版本, 但其并不在 Debian 软件包中提供).
Passwd does not allow non-interactive assignation of passwords (since it uses direct tty access). If you want to change passwords when creating a large number of users you can create them using adduser with the --disabled-login option and then use usermod or chpasswd[24] (both from the passwd package so you already have them installed). If you want to use a file with all the information to make users as a batch process you might be better off using newusers.

4.11.21. 用户密码检查

有时用户密码可能是一个特定系统的安全中最弱的一环. 这归结于一些用户为他们的账户选择了弱密码 (越弱,则被攻击的可能性越大). 既使您创建了使用 cracklib PAM 模块的检测和密码限制,如在 第 4.11.1 节 “用户认证: PAM” 中所述. 用户仍然可以使用弱密码. 因为访问也许包括远程 shell 访问(ssh, 希望是), 一个远程攻击(在他们用其他的方法做过用户枚举之后)无法猜测用户密码是非常重要的, 特别是如果他们不知什么原因收集到了类似用户名甚至 passwdshadow 文件本身等重要信息.
A system administrator must, given a big number of users, check if the passwords they have are consistent with the local security policy. How to check? Try to crack them as an attacker would if having access to the hashed passwords (the /etc/shadow file).
An administrator can use john or crack (both are brute force password crackers) together with an appropriate wordlist to check users' passwords and take appropriate action when a weak password is detected. You can search for Debian GNU packages that contain word lists using apt-cache search wordlist, or visit some Internet wordlist sites.

4.11.22. 注销闲置的用户

闲置用户通常是一个安全隐患, 用户闲置, 可能因为他外出午餐, 或远程连接断掉, 但是没有重新建立. 无论什么原因,闲置用户可能导致系统受到威胁:
  • 因为用户的控制台或许没有锁定,可能被入侵者所利用.
  • because an attacker might be able to re-attach to a closed network connection and send commands to the remote shell (this is fairly easy if the remote shell is not encrypted as in the case of telnet).
强制断开闲置的用户是本地安全策略的一部分. 有以下几种方式:
  • If bash is the user shell, a system administrator can set a default TMOUT value (see bash(1)) which will make the shell automatically log off remote idle users. Note that it must be set with the -o option or users will be able to change (or unset) it.
  • 安装 timeoutd 并根据您的本地安全策略配置 /etc/timeouts. 守护进程将监视闲置用户,在 shell 之外对其记时.
  • 安装 autolog 并配置其删除闲置用户.
使用 timeoutdautolog 守护进程是不错的方法, 因为, 终究, 用户可以修改其缺省 shell,或运行默认 shell 以后,切换到其他的(未受控制的) shell.

[16] In old Debian releases the configuration of the modules was defined directly in /etc/pam.d/passwd.
[17] The minlen option is not entirely straightforward and is not exactly the number of characters in the password. A tradeoff can be defined between complexity and length by adjusting the "credit" parameters of different character classes. For more information read the pam_cracklib(8) manpage.
[18] The default content of this file provides information about the operating system and version run by the system, which you might not want to provide to anonymous users.
[19] libpam-chroot has not been yet thoroughly tested, it does work for login but it might not be easy to set up the environment for other programs
[20] Setting HISTSIZE to a very large number can cause issues under some shells since the history is kept in memory for every user session. You might be safer if you set this to a high-enough value and backup user's history files (if you need all of the user's history for some reason)
[21] Without the append-only flag users would be able to empty the contents of the history file running > .bash_history
[22] Ttys are spawned for local logins and remote logins through ssh and telnet
[23] As defined in /etc/adduser.conf (USERGROUPS=yes). You can change this behaviour if you set this value to no, although it is not recommended
[24] Chpasswd cannot handle MD5 password generation so it needs to be given the password in encrypted form before using it, with the