16.3.账户安全
在 FreeBSD 中，维护安全账户对于数据机密性、系统完整性和权限隔离至关重要，因为它可防止未经授权的访问、恶意软件和数据泄露，同时确保合规性并保护组织的声誉。
16.3.1. 防止登录
在保护系统时，良好的起点是审计账户。禁用不需要登录访问的账户。
技巧
确保
root已设置强密码，并且该密码不可共享。
有两种方法可拒绝账户的登录访问。
第一种方法是锁定账户，以下示例演示了如何锁定 imani 账户：
# pw lock imani第二种方法是通过将 shell 改为 /usr/sbin/nologin 来防止登录访问。nologin(8) shell 防止系统在用户尝试登录时为其分配 shell。
只有超级用户可为其他用户更改 shell：
# chsh -s /usr/sbin/nologin imani16.3.2. 密码哈希
密码是技术领域中不可避免的弊端。当必须使用密码时，应确保其复杂性，并使用强大的哈希机制对存储在密码数据库中的版本加密。FreeBSD 支持多种算法，包括其 crypt() 库中的 SHA256、SHA512 和 Blowfish 哈希算法，详细信息请参见 crypt(3)。
默认的 SHA512 不应更改为不安全的哈希算法，但可更改为更安全的 Blowfish 算法。
注意
Blowfish 并非 AES 的一部分，也不视为符合任何联邦信息处理标准（FIPS）。在某些环境中，可能不能使用它。
要确定使用哪种哈希算法加密用户的密码，超级用户可查看 FreeBSD 密码数据库中该用户的哈希。每个哈希都以符号开头，表示用于加密密码的哈希机制类型。
如果使用的是 DES，则没有开始符号。对于 MD5，符号为 $。对于 SHA256 和 SHA512，符号为 $6$。对于 Blowfish，符号为 $2a$。在这个示例中，imani 的密码使用默认的 SHA512 算法哈希，因为哈希以 $6$ 开头。请注意，存储在密码数据库中的是加密哈希，而不是密码本身：
输出应类似于以下内容：
哈希机制是在用户的登录分级中设置的。
可运行以下命令检查当前使用的哈希机制：
输出应类似于以下内容：
例如，要将算法更改为 Blowfish，可将该行修改为：
然后，必须执行 cap_mkdb(1) 来升级 login.conf 数据库：
请注意，这一更改不会影响任何现有的密码哈希。这意味着所有密码都应通过要求用户运行 passwd 来重新哈希，以便更改其密码。
16.3.3. 密码策略强制执行
强制实施本地账户的强密码策略是系统安全的基本方面。在 FreeBSD 中，可使用内置的可插拔身份验证模块（PAM）来实现密码长度、密码强度和密码复杂性的要求。
本节演示了如何使用 pam_passwdqc(8) 模块配置最小和最大密码长度以及强制执行混合字符。此模块在用户更改密码时生效。
要配置此模块，请切换到超级用户并取消注释 /etc/pam.d/passwd 中包含 pam_passwdqc.so 的行。
然后，编辑该行以匹配密码策略：
有关参数的解释，可参见 pam_passwdqc(8)。
保存此文件后，当用户更改密码时，将看到类似如下的消息：
输出应类似于以下内容：
如果输入的密码不符合策略，将拒绝，并出现警告，用户将有机会再次尝试，直到达到配置的重试次数。
如果组织的策略要求密码过期，FreeBSD 支持在用户的登录分级中设置 passwordtime，该配置位于 /etc/login.conf 中。
default 登录分级包含示例：
因此，要将此登录分级的过期时间设置为 90 天，请删除注释符号 (#)，保存编辑，然后执行以下命令：
要为个别用户设置过期时间，可向 pw 命令传递过期日期或过期天数，以及用户名：
如上所示，过期日期的设置格式为 日、月、年。有关更多信息，请参见 pw(8)。
16.3.4. 使用 sudo 进行共享管理
系统管理员通常需要能授予用户增强的权限，以便他们能执行特权任务。让团队成员访问 FreeBSD 系统以执行其特定任务，这为每个管理员带来了独特的挑战。这些团队成员只需要超出普通用户级别的一部分访问权限；然而，他们几乎总是告诉管理层，他们无法在没有超级用户访问权限的情况下执行任务。幸运的是，提供此类访问权限给最终用户是没有必要的，因为已有工具可管理这一具体需求。
技巧
即使是管理员，也应在不需要时限制自身权限。
到目前为止，本章已讨论了如何让授权用户能访问以及如何尽量防止未经授权的访问。当已授权用户有权访问系统资源时，另一个问题就会出现。在许多情况下，一些用户可能需要访问应用程序启动脚本，或者一组管理员需要维护系统。传统上，标准的用户和组、文件权限，甚至是 su(1) 命令用于管理这种访问。而随着应用程序需要更多的访问权限，更多用户需要使用系统资源，更好的解决方案应运而生。目前使用最广泛的应用程序是 Sudo。
Sudo 能让管理员对系统命令配置更严格的访问控制，并提供一些高级日志记录功能。作为工具，它可从 Ports Collection 获取，路径为 security/sudo，或使用 pkg(8) 工具。
执行以下命令来安装它：
安装完成后，安装的 visudo 将使用文本编辑器打开配置文件。强烈建议使用 visudo，因为它内置了语法检查器，可在文件保存前验证没有错误。
配置文件由多个小节组成，能广泛配置。在以下示例中，Web 应用程序维护者用户 user1 需要启动、停止和重启名为 webservice 的 Web 应用程序。为了授予该用户执行这些任务的权限，在 /usr/local/etc/sudoers 文件的末尾添加以下行：
现在，用户可使用以下命令启动 webservice：
虽然这个配置让单个用户能访问 webservice 服务；然而，在大多数组织中，通常由 Web 团队负责管理该服务。单行配置同样可为整个组提供访问权限。以下步骤将创建 Web 组，将用户添加到该组，并让该组所有成员能管理该服务：
使用相同的 pw(8) 命令，将用户添加到 webteam 组：
最后，在 /usr/local/etc/sudoers 文件中添加这一行，让 webteam 组的任何成员能管理 webservice：
技巧
大多数组织正在转向或已采用双因素认证模式。在这种情况下，用户可能没有密码可供输入。
sudo(8) 可通过
NOPASSWD变量配置为支持双因素认证模式。将其添加到上述配置中，将让所有 webteam 组成员能管理该服务，而无需密码：
16.3.5. 使用 Doas 进行共享管理
使用 doas，用户可执行具有提升权限的命令，通常以 root 用户身份，同时保持简化且注重安全的方法。与 sudo(8) 不同，doas 强调简洁性和极简主义，专注于精简的权限委派，而不会出现大量令人不知所措的配置选项。
执行以下命令来安装它：
安装后，必须配置 /usr/local/etc/doas.conf 文件，以便为用户授予特定命令或角色的访问权限。
最简单的配置条目可能如下所示，它让 local_user 在执行 doas 命令时能以 root 身份运行命令，并且不要求输入密码：
安装和配置好 doas 工具后，现在可使用提升的权限执行命令，例如：
更多配置示例，请参阅 doas.conf(5)。
最后更新于