UNIX 计算安全/账户安全
建议主题:shell 环境、密码老化、密码强度、点文件、受限 shell、休眠账户、安全终端和 root 访问。
"仅仅因为你疑神疑鬼,并不意味着他们没有想要算计你。" —匿名。 |
Unix 系统的用户很可能不像系统管理员那样了解其系统的安全方面。因此,使用系统的配置功能来配置这些帐户以使其具有合理的安全性非常重要。此类配置可以应用于默认的用户安全设置、运行程序的环境等等。根据服务器上的访问和数据安全要求,某些帐户可能还需要特殊限制。
帐户投入使用后,系统管理员仍需要保持一定程度的警惕,以确保未滥用访问权限,甚至未被不当人员利用。需要检查密码的强度并定期更新。需要禁用未使用的或不需要的帐户,以防止将其用于不当目的。
首次创建帐户时,通常会为其分配一个单独的主目录。这是一个目录,通常位于/home
或可能是/user
目录树下,用户可以在其中存储其数据文件,以及自定义的启动和配置文件。(这些可能包括.profile
、.login
、.cshrc
等。)
主目录应以这样一种方式进行保护,即用户拥有它,并且目录的组标识符与帐户的默认组匹配。此外,主目录通常被赋予权限,以限制其他用户访问。750
或700
的权限模式很常见。
许多系统管理员提供一组默认的启动文件或“点”文件,这些文件会被复制到新的主目录中。例如,这些文件可以提供有用的别名和特定于站点的操作。但是,这些默认文件需要得到适当的保护,否则它们可能会被篡改,任何新帐户都可能很快被泄露。
在特定用户帐户的主目录不存在的情况下,许多 Unix 系统上的默认操作是在顶级或斜杠(/)目录中启动登录会话。这也是root
(超级用户)帐户的默认目录。因此,这可能会导致启动配置文件的权限问题和其他意外行为。
为了解决此问题,可以将root
帐户的主目录放在其自己的目录树下。(例如,/root
)。通常,此目录应放置在与斜杠相同的文件系统上,以便在系统启动时始终存在该目录。为root
提供一个私有目录还可以为系统管理员可能想要运行的任何工具和脚本提供一个更安全的位置。
实施私有 root 主目录后,系统管理员可以修改斜杠目录下的“点”文件,并使用它们为其用户提供一组默认的启动文件。
请注意,让用户使用斜杠作为主目录登录通常不是一个好主意,并且它通常表明系统存在问题。某些版本的 Unix 提供了一种方法,可以在找不到用户的主目录时禁用用户登录。
许多可用于 Unix 系统的 shell 允许配置环境变量。其中一些变量可能存在安全隐患,而一些变量可以配置为增强系统安全性。
当 Unix 会话无人看管一段时间后,只需要几分钟,不法分子就可以利用这种情况来提高自己的访问权限。例如,假设系统管理员离开办公桌一分钟,然后某人输入了一些命令在 shell 提示符下
root$ touch /tmp/rubbish root$ chmod 4777 /tmp/rubbish root$ exit
这将创建一个可由所有人编辑的文件,该文件可以修改为运行可以授予任何执行它的人 root 权限的命令。该个人现在拥有了系统。正因为存在此类情况,因此对于无人看管的会话而言,要么将其锁定,要么断开连接非常重要。
某些 shell 类型(包括 Korn Shell、Bash 和某些供应商版本的 Bourne Shell)将支持超时变量,即 TMOUT 或 TIMEOUT。设置此变量后,它将给出 shell 过期之前的无活动秒数。(值为零表示没有超时。)此变量可用于在用户或系统管理员离开活动登录会话一段时间后使 shell 过期。通常,此变量将设置为某个值(例如 300 或 5 分钟),这将限制漏洞期。它通常设置在全局 shell 启动文件中,例如/etc/profile
或/etc/csh.login
。
Unix shell 会话使用名为 PATH 的环境变量来确定可从 shell 命令行执行的命令和其他程序的位置。此变量设置为系统上有效目录的冒号分隔列表。当在 shell 提示符下键入命令时,系统将搜索 PATH 中的每个目录,查找名称匹配的程序。找到匹配项后,搜索将停止并执行程序。(出于效率原因,最近执行的命令的目录路径可能会存储在缓存中。)
$ echo $PATH /usr/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:.
在 Unix 中,路径名中的单个句点(.
)或空条目(::
)用于表示当前工作目录。假设某个帐户在其 PATH 变量中恰好包含这样一个句点,并且用户决定执行某个命令。如果在句点之前列出的目录中未找到该命令,则系统将检查用户的当前工作目录以查找匹配的文件。如果找到,则系统将尝试执行该文件。由于用户的当前工作目录可能位于系统上的任何位置,并且帐户在该位置具有访问权限,因此很容易看出为什么这可能构成安全问题。
此潜在漏洞对于 root 帐户尤其如此。假设 root 在其 PATH 变量的开头有一个句点,然后用户打电话报告其主目录中的问题。系统管理员通常会将目录更改为用户的主目录位置,并使用ls
命令执行目录列表。但是,如果用户在其主目录中放置了一个名为ls
的文件,则系统将尝试执行它。此文件很容易成为一个 shell 脚本,它利用 root 帐户的权限授予用户增强的权限,然后简单地复制ls
调用的操作。系统管理员可能根本意识不到不当活动。
因此,重要的是 root 帐户尤其不能在其 PATH 变量中包含句点。请注意,如果 PATH 变量的值以句点开头或结尾,则系统将将其视为句点。因此,此外,root PATH 变量永远不能以冒号开头或结尾,也不能在两个冒号之间没有目录的情况下并排放置两个冒号。无论如何,系统管理员最好键入完整命令路径,而不是依赖于系统。
如果用户需要其 PATH 变量包含句点,则应将其放在 PATH 的最后。这将导致系统在尝试当前工作目录之前检查所有包含可执行文件的标准目录。在 shell 启动脚本(例如/etc/profile
)或某些供应商版本的/etc/PATH
文件中设置 PATH 可以帮助系统管理员管理大多数用户帐户的 PATH 变量的使用。
关于 PATH 变量的另一个问题是 PATH 中的任何目录是否允许用户修改内容。PATH 中目录的权限应全部限制写入权限,并且这些目录中的所有文件都不应允许写入权限。否则,不法用户可以修改一个或多个命令,并期望其他用户甚至 root 执行其修改后的文件。定期检查这些目录和文件的权限对于帮助维护安全系统是必要的。
这些文件通常位于帐户的主目录中,并包含各种启动和配置设置以及过程。这些文件对系统管理员来说很重要,因为在某些情况下,它们会引入 Unix 系统安全性的弱点。
警惕的系统管理员会定期搜索其系统中是否存在这些文件,然后检查权限和内容是否存在潜在的安全问题。除了用户添加的不正确的设置外,入侵者还可以修改这些文件,以便将来重新获取访问权限。
sendmail
程序支持此文件,用于将电子邮件转发到新的地址(例如,用户迁移账户后)。该文件的内容可以包含以逗号分隔的地址列表。然而,在安全方面存在问题,因为地址也可以是系统命令。例如:
[email protected], "|/var/tmp/give_me_access"
当收到电子邮件时,它会被转发到 .forward
文件中的地址。它还会作为标准输入传递给字符串中列出的程序。例如,这可以是用户编写的脚本,用于执行邮件中包含的命令。
禁用用户密码可能是禁用用户帐户的常见做法。但是,如果用户已将其 .forward
文件配置为执行命令,他们仍然可以对系统执行操作。不怀好意的人可能会利用此访问权限进行不当活动。
从 sendmail
程序的第 8 版开始,可以使用 ForwardPath 选项来定义 .forward
文件的备用位置。ForwardPath 选项通过 OJ
行(或“O ForwardPath=
”)在 sendmail
配置中设置。例如:
OJ/var/forward/$u.forward:$z/.forward
这将导致 sendmail
首先检查 /var/forward
目录下是否存在一个文件,该文件的名称为用户帐户名称后跟 .forward
。(因此,bob.forward 将被解释为名为 bob 的用户帐户的 .forward
文件。)如果找不到该文件,则 sendmail
将在用户的主目录中查找 .forward
文件。
每当创建新的用户帐户时,系统管理员就可以在受控目录中创建 account.forward
文件。(这可以作为帐户创建工具的一部分自动完成。)在用户确认他们已经具备足够的 UNIX 知识来正确配置自己的 .forward
文件后,可以删除 account.forward
文件。
用户可能希望使用 ftp
命令来执行例如从远程站点批量下载文件。为了自动化此过程,他们可以配置 .netrc
文件以提供访问权限,而无需输入密码。完成后,可以使用脚本(例如通过计划的批处理任务)来传输文件。不幸的是,.netrc
文件的格式以明文存储密码。任何拥有 .netrc
文件读取权限的人都可以获取用户的登录密码。
ftp
进程有一个内置限制,可以部分缓解此问题。如果除了所有者之外的任何人都可以读取用户的 .netrc
文件,则自动登录过程将失败。这迫使所有者限制此文件的权限。但是,这只是一个部分解决方案。对于大多数目的,更好的方法是改为使用 sftp
命令的主机身份验证方法。
最近,cURL 库允许将 .netrc
文件与所有协议一起使用[1]。
.rhosts
文件可以在运行远程登录命令(通常为 rlogin
)时为用户提供自动登录功能。这绕过了正常的登录过程,并立即将用户连接到系统。正如您所料,此功能可能会给系统带来许多潜在的漏洞。
假设三个系统被设置为 A 与 B 之间存在信任关系,但 A 不一定信任 C。为帐户建立连接 A—B 和 B—C 的 .rhosts
可以为个人从 C 到 A 提供后门。也就是说,设法获得对 C 的不当访问权限的人可以使用 .rhosts
文件获取对 A 的访问权限,即使 A 不信任 C(甚至可能阻止网络访问)。
.rhosts
文件的另一个问题是用于输入允许的帐户访问的方法。该文件可以设置为允许来自任何主机的访问。例如:
+ joebob
将允许 joebob 帐户从任何主机连接,而无需输入密码。不幸的是,该帐户可能属于另一个系统上的完全不同的人,或者它可能是在受损系统上故意建立的,以允许不当访问。
由于其使用固有的安全风险,通常最好在可能的情况下禁用 .rhosts
功能。