AIX安全报告

为您的系统生成审计安全快照将能够使系统管理员实现有效的安全控制，从而确保能够恰当地管理您的 AIX 服务器的安全性。它还展示了当前采用的标准安全策略。在了解每月安全报告和审计报告应当包括哪些内容之前，让我们先来看一下如何呈现它们。虽然这里只讨论了一个安全报告，但是请记住，这种报告将由大量 AIX 服务器生成，因此，务必以准确、中肯的方式呈现信息，并且各个小节都要有明确的标题。您可能决定使用一个机器一个报告 (one box one report) 的方法呈现报告，或者将所有报告整合到一个报告中，您可以自由选择。这两种方法我以前都用过，但我更倾向于生成大型报告的方法。您可以考虑使用 HTML 格式呈现这些信息，信息中包含一些标记，因此您可以单击不同的部分并找到您感兴趣的信息。HTML 可以嵌入到电子邮件中或直接生成到 Web 页面。显然，具体方式取决于您自己的报告标准。

在生成报告时，您可能决定只生关于成生产服务器的报告，而不准备生产关于任何开发、研发或验收测试服务器的报告。我认为显示给管理者的安全报告应当只包括生产服务器，因为其他服务器通常没有生产服务器那么封闭和保守。

在合并为一个报告时，您应当假设服务器已经采用了某些相关的安全工具。其中一些标准工具包括：

SSH

TCP 包装器

AIX Audit 服务

Sudo

报告哪些内容？

我认为报告应当侧重于与用户有关的生产信息、登录属性和有效的 IBM 安全建议。在进一步了解这些之前，让我们先来查看应当包括在通用安全报告的一些内容：

IBM 安全建议

有关密码策略的报告（设置和过期）

有关设置用户 ID/组 ID（UID/GID）文件（非 IBM 生成的文件）的报告

符合应用程序策略的正确的组成员关系

系统流程所有者的锁定帐户，比如 lpd 和 bin

在执行非登录活动的指定天数后锁定帐户

任何新用户或已删除的用户

任何新组或已删除的组

删除或增加了替代用户 (su) 权限的用户

允许的用户组成员

允许访问特权帐户（如 root 用户和应用程序所有者）的 su 访问

登录属性，其中 admin 被设置为 true

状态表示，指出是否对远程登录活动禁用 root 访问

得到许可的用户能够使用 File Transfer Protocol (FTP)、Secure Shell (SSH) 和 Secure Copy Protocol (SCP) 访问 AIX 服务器

报告是否在 /etc/ineted.conf 中禁用 rexec

报告找到的所有 .rhosts 文件

现在，我们将详细了解上面提到的各项内容。

注意

IBM 建议包括 IBM 通过详细的电子邮件发送的安全漏洞说明，告知您在特定操作条件下某个流程或服务存在的潜在缺陷、补丁或解决方案。您需要自己判断这一缺陷是否会影响到您，以及您是否希望解决这个问题。这些电子邮件应当记录在单独的表格或数据库中，这样就可以生成这些建议的历史记录（提供详细信息、出现问题的时间和采取了哪些操作，如果有的话）。关于这些建议的说明应当包含在报告中。

密码策略

拥有良好的密码策略（密码过期和密码规则）非常重要。您在生产环境中使用的密码策略应当是一项严格的标准。例如，对于普通支持用户，他们的密码可能会在一段时间（比如 35 天）后过期。然而，对于应用程序或批处理用户，这会带来一些问题。没人希望半夜运行批处理程序时密码过期，因此可能会将这些密码设置为永不过期。然而，所有用户都应当使用相同的规则来选择密码，比如可重复字符和密码的最小长度。使用 /etc/security 中的默认值时，您应当针对当前采用的标准策略检查默认设置，您会注意到所有不一致的地方。如果这些不一致的地方是已知的异常，那么应当使用一个排除列表，随报告一起提供。如果使用的是网络认证，如 Lightweight Directory Access Protocol (LDAP) 或 Kerberos，那么应当检查这些扩展的属性。

清单 1 演示的方法中，可以对帐户属性的报告进行比较和显示。将包含标准属性策略的模板文件与远程 AIX 服务器上 /etc/security/user 中的默认属性进行比较，就会发现所有不一致的地方。清单 1 还列出了此检查中发现的所有例外用户。

清单 1. 帐户属性

Standard attributes: Current attributes:

admin = admin = false

login = true login = true

su = true su = true

daemon = true daemon = true

rlogin = true rlogin = true

sugroups = sugroups = ALL

admgroups = admgroups =

ttys = ttys = ALL

auth1 = auth1 = SYSTEM

auth2 = auth2 = NONE

umask = 022 umask = 022

expires = expires = 0

SYSTEM = SYSTEM = "compat"

pwdwarntime = 5 pwdwarntime = 5

account_locked = false account_locked = false

loginretries = 3 loginretries = 3

histexpire = 26 histexpire = 26

histsize = 15 histsize = 15

minage = 1 minage = 1

maxage = 5 maxage = 5

maxexpired = -1 maxexpired = -1

minalpha = 1 minalpha = 1

minother = 1 minother = 1

minlen = 8 minlen = 8

mindiff = 2 mindiff = 2

maxrepeats = 2 maxrepeats = 2

Excluded users for this host: ukpen01dd

user1,user2,..

我拥有哪些用户 set-uID

所有非 IBM set-uID 程序都应当进行报告，通过与以前的运行或日志文件比较，您就可以知道是否有新的 set-uID 或修改过的 set-uID 发生了变化。所有显示的 set-uID 程序都应当列出在安全报告中。您可以考虑结合使用 fpm 命令。

组成员关系

拥有正确的组成员关系可以确保非特权用户不会对特权文件进行组访问。应当创建一个用于所有组应用程序成员的模板。如果有任何不应属于这些组的用户，则需要进行报告。

锁定的系统帐户

系统进程帐户的所有者，如 bin 和 lpd 等，应当锁定他们的帐户。即使 login/rlogin 属性为 false，也不应该公开这些帐户，这是无需置疑的。报告应当列出这些未锁定帐户的进程帐户所有者的所有违规行为。

非活动帐户

有必要找出长期未登录 AIX 系统的用户，并检查他们是否需要帐户。经过一段时间后（建议 40 天），应当锁定（而不是删除）这些帐户。当用户导致产生一个事件处理过程票据 (incident process ticket)，且应用程序栈持有者准许时，可以解锁帐户。经过一个比较长的非活动期后，可以删除用户。但是，执行此操作时必须小心谨慎，因为如果用户与应用程序支持有关，那么他们可能通过 GUI 与应用程序相连。因此，AIX 会无法更新该用户的登录属性，在这种情况下，需要采用其他机制进行检查，或者使用用户的排除列表。

用户和组填充

报告有关任何新用户或已删除用户的信息可以展示您管理系统的方式，方法就是始终保持用户群处于最新状态。任何新的用户或组都可以通过一个变更控制请求来创建，并记录这个事件。删除用户很有可能通过发出请求来完成，或者根据不断更新的离职员工列表来删除用户，甚至有可能根据休眠帐户 (dormant account) 来删除用户。维护用户的过程会确保系统不会充满非活动用户。

su和sudo

在 sudoers 文件中查找 su 访问和 sugroup，特权访问能够够确保只有已授权用户才能够转换用户权限。经常发生的情况是会留下临时的 su 访问授权，因此该授权变为永久性的授权。通过对 su 组进行报告，您可以快速确定应当为哪些用户取消 su 访问。您至少应当向以下用户报告 su 访问：root 用户、应用程序所有者、批处理调度程序的所有者。

下面显示了主机 ukpen01dd 上 IBM DB2? 组（db2grp）成员的一个典型条目，无需密码即可将用户权限转换为 DB2 实例用户 db2inst1：

%db2grp ukpen01dd = NOPASSWD:/usr/bin/su – db2inst1

管理员帐户

您应当创建一个报告，其中包含所有在帐户属性中将 admin 设置为 true 的用户的列表。这通常包括系统帐户。其中一些用户为：root 用户、daemon、bin、sys 和 lpd。然而，您可以将这一权限委托给特定用户，因此还应当报告这些用户。

对root用户禁用rlogin

我认为应当对 root 用户禁用所有 rlogin。您应当只能从 su/sudo 进程或通过指定服务器上的直接 SSH 连接进行 root 访问。这种方法可以有效地锁定 root 访问。对 root 执行的惟一的登录访问应当通过系统控制台或 Hardware Management Console (HMC) 来实现。

FTP/SCP访问

需要谨慎考虑是否允许从远程服务器进行 SCP/FTP 访问，因为您不希望限制需要传输文件的用户。整理好用户列表后，您可以使用该列表填充 /etc/ssh/sshd.conf 文件中允许使用的用户条目。另外，不要忘记 ftpaccess.ctl 文件，可以通过该文件了解允许使用 FTP 的用户和 FTP 限制。还可以生成禁用 FTP 访问的用户的列表，这些内容包含在 /etc/ftpusers 中。我认为应当只允许 root 用户进行 SCP 访问，并且只能从指定的（首推）服务器访问。

不安全的命令

还应该进行一项检查，确定 /etc/inetd.conf 中是否没有注释掉 rexec。我不会解释这样做的安全原因，因为所有 Linux?、UNIX? 或 AIX 安全文档对此都有详细的解释。我认为如今仍然使用不安全命令的惟一原因可能是因为 Network Installation Management (NIM) 的推出，并且应当只允许临时使用它们。还应该运行一个查找命令，识别用户的 HOME 目录中的所有 .rhosts 文件。除非有特殊的原因要求在不安全的连接中使用 .rhosts 文件，否者应当报告这些内容，并实现一个流程，将用户移动到 SCP。

检查密码和组文件的有效性

作为每月报告的一部分，您可以使用 grpchk 和 pwdck 命令来确定您的组和密码文件是正确的，不存在任何格式问题或无效的用户或组。

将所有环节衔接起来

从一个中央服务器运行安全报告脚本，或者，将脚本推向每个必要的远程主机，然后运行它。通过这种方式，如果脚本需要进行修改，那么只需要在一台主机上进行修改即可。

在比较只在特定组中才准许使用的用户时，我认为最好创建一个用户模板文件，用它来进行比较。这个模板文件会在运行报告之前从一个中央服务器推出，因为您每个月都要定期更新这个中央文件，指定用户或用户所属的组或子组。该文件的格式可以与 /etc/group 的格式相同。

groupname1: usera,userb,..

groupname2: usera,userb,..

之后的流程就简单了很多，遍历这个文件，将它与 AIX 服务器上现有的组进行比较，然后报告不匹配的用户。