昨天看到了一个银行的审计报告，这个审计报告也是基于科技风险的相关要求去检查，在报告中，审计小组指出，“在该银行中，主机设备上的普通用户已经按照相关策略执行了配置，并且定期会修改密码，但是root用户已经近两年没有修改密码了。”就root这个事情引起了我的思考，与审计小组人员沟通后，他们表示导致这种情况大致包括以下两种情况：

1.root密码是这类操作系统的重要管理员密码，在未实施堡垒机之前（正在进行堡垒机项目），root账户属于部门或者运维团队内共享账户（多个成员使用一个特权账户去完成管理工作），所以改密码要通知这些人，或者通知一些使用root调用的程序。

2.操作系统的策略对于root而言是不生效的，只能针对于普通用户。

我相信这也是很多企业面临的问题，解决的办法也可以分为两种，

1.纳入运维平台管理，并且在运维平台的用户端必须做到帐号的独立，然后在运维平台上根据职能做权限的分配，或在操作系统上使用权力委派的形式进行多种职能角色的划分。

2.利用基线工具或者是手工检查的方法定期对操作系统的安全情况进行抽检。

之所以能够关注这块，是因为这个审计小组做的比较细致，给我们提供了一些好的思路。下面我就给大家说一下经常容易忽略的root密码修改问题的具体检查方法。

其实在Linux 操作系统中，做像修改密码这样的操作是肯定会产生日志的，如果你们的企业已经将日志发送到SOC平台，或者是其他日志管理平台，那么你可以在平台上检索关键字，就拿Linux 操作系统来讲，修改密码会产生 如下的一条日志，该日志表示station001这个设备的test1账户在12月26 14:01:04进行了修改。

“Dec 26 14:01:04 station001 passwd: pam_unix(passwd:chauthtok): password changed for test1”

如果日志没有集中备份的话，完全可以提取shadow文件中第三个字段进行计算：

下面给一个例子出来：这是我在RHEL6平台下查看的test密码，第三个字段数值为16034，这个数据表示自 1/1/1970 起，密码被修改的天数，如果嫌计算麻烦，那么可以在新建一个测试账户，目的在于用当前新创建账户的数值减去16034，就可以得到改密码的修改时间。如果设备特别多，那么可以通过脚本的方式进行shadow文件的提取

test:$6$cLdOnWPa$wq6zn2MkRdrG7XkSrJ8rg0iOVIKgF7nFgabWpebQNyZ7BT18/GoQNUlC2Zk.ZBOVk.e6th0HaqENQEmsDbW5a.:16034:0:99999:7:::