之前的公司曾经做过几个客户的等保项目，其中包括服务器设置，日志审计的部署，安全系数，某些应用的策略整改等，平台除了自己部署的 ELK，大多数都是从深信服安全资源池配置模块设置来应付等保的。当然现在我也没权限登录之前公司的安全资源池了，只能把以前的等保整改过的内容进行整理。我懒得以后天天百度抄 csdn 了。如果有整改建议的内容我就不写在这里了，抄作业就行了。

对了，我没接触到最核心业务的整改，我负责基本都是边缘业务。

需要额外手段的整改

操作系统仅采用用户名+口令的方式进行身份鉴别，未能提供其他双因子鉴别技术

（1）建议核心设备、操作系统等增加除用户名、口令以外的身份鉴别技术，如基于密码技术的动态口令或令牌等鉴别方式，使用多种鉴别技术进行身份鉴别，增强身份鉴别的安全力度;对于使用堡垒机或统一身份认证机制实现双因素认证的场景，建议通过地址:绑定等技术措施，确保设备只能通过该机制进行身份认证，无旁路现象存在。

这个基本上很多等保都需要整改的内容，意思就是除了普通的账号密码认证外，还要额外添加一个认证方式。这种就像 Steam 的安全令或微信的手机同意才能登录 PC 一样。当然大牌的安全产品都提供证书/指纹/安全令/人脸的方式提供多层认证，但我们用开源或自己做的系统都不会有这种功能。

思路1： 用代理的方式限制？

这种方式就是服务器加白名单，或者系统登录有白名单限制，本质上你挂了代理就是套了一层身份认证方式，代理也需要另外认证才可以使用。我登录了代理，才能访问我的系统，这种也是双因子认证啊！具体做法就是 iptables 咯，最好用 Nginx 的白名单认证比较好，当然业务系统能加一个白名单认证是最好的（非授权 IP 无法登录这个账号），这样又能顺便处理授权 IP 的整改方案。

但是，有些等保机构可能不认这种做法，那还有另外的方式。

思路2： 使用堡垒机系统给业务套一层跳板机

堡垒机迟早都要做的，因此我们可以用堡垒机方案。这边使用 Jumpserver 开源堡垒机。

如果等保机构不认这种方式，我当时就参考了深信服安全资源池的做法，所有客户都要先登录 CSSP 客户侧才能进入安全模块，而客户侧登录界面自带安全码与授权IP认证，等保机构也吃这一套，我们就解释所有安全模块必须经过这个登录界面才可以登录安全模块的管理页面。就算模块没有安全认证功能，我们通过人为的限制使得这个系统必须通过某个平台才能登录。我们也可以抄这种思路去应付。

找一台 Windows 的云主机当 Web 界面的跳板机，当然如果有天融信堡垒机应用发布系统最好（不需要另外弄台跳板机），业务服务器必须限制只有指定某些IP才能访问包括跳板机。然后去堡垒机界面，添加好这台 windows 的云主机资产后，设置好堡垒机的账号和双因子认证后，就可以开始表演了。可以跟等保人员说这个系统必须要用堡垒机才能访问，因此业务系统的双因子全靠堡垒机才能访问！

反正态度强硬点，等保能不能过全靠一张嘴嘻嘻。

审计记录进行定期备份

建议对设备的重要操作、安全事件日志进行妥善保存，避免受到非预期的删除、修改或覆盖等，留存时间不少于六个月，符合法律法规的相关要求。

这个只能靠堡垒机的行为审计才可以，如果业务系统的行为审计的话，只能老实做日志管理了。如果堡垒机不支持命令审计的话，把 HISTFILE 或 .bash_history 文件做个计划任务备份到异地的话也应该没问题。、

系统未按规范开展恢复演练。

（1）建议建立备份恢复机制，定期对重要数据进行备份以及恢复测试，确保在出现数据破坏时，可利用备份数据进行恢复；此外，应对备份文件妥善保存，不要存放互联网网盘、开源代码平台等不可控环境中，避免重要信息泄露；
（2）至少6个月内组织一次恢复演练，测试是否能进行正常的数据恢复，并保留测试记录。
（1）建议设置异地灾备机房，并利用通信网络将重要数据实时备份至备份场地；
（2）异地备份的数据范围（不限于）包括系统的：
■配置数据
■重要业务数据。

这种就是异地备份方案，可以用 rsync 或 git 等等同步工具备份到公司的私有云或私有网盘，这也是弄脚本的事情了。但第二条的话，之前公司就是找一份 Word 文档，写大概的演习记录和签名就行了。大概就是这样写：

演练项目： 对 XXX 系统的数据还原演练
负责人： XXX/XXX/XXX
时间：XXXXX
演练记录：
1. 获取业务系统的备份数据，检验数据的完整性；
2. 停止业务系统（或测试机），备份现系统数据；
3. 将旧数据导入回系统
4. 开启业务服务，验证系统是否正常运作，数据是否恢复成功。
5. 验证成功
6. 自己补充
签名：
上级领导： XXXX 主负责人：XXXX 主监督人：XXXXX

制定安全策略文件，并依据安全策略配置用户的访问控制规则。

这个跟上面一样，也要自己写公司内部制度文档，然后通过下面我所说的三权分立分别设置权限就行了。

能在系统内解决的问题

未部署主机（或网络层）入侵检测软件或系统 与 操作系统未安装防恶意代码软件。

（1）建议系统部署入侵防范设备（可在主机或网络层面），检测对重要系统进行入侵的行为并进行记录；
（2）在发生严重入侵事件时提供报警，应能发现目前主流的各种攻击行为，如木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、口令暴力破解和蠕虫攻击等；
（3）能在发生严重入侵事件时提供有效的（如声音、短信、EMAIL等任一种）报警。

其实就是要装个杀毒软件，Linux 可以考虑 Clamv，Windows 的选择更多了。但是如果要做到三个都要满足，可以考虑使用 EDR 软件，但是大多数 EDR 都是收费应用。如果公司财力雄厚的话，有 IPS 或者找一个开源的 Web 应用防火墙（WAF）比较好，github 就有免费的开源社区 WAF，可以自己找找。

未配置密码复杂度

（1）建议应用系统对用户的账户口令长度、复杂度进行校验，如要求系统账户口令至少8位，由数字、字母或特殊字符中2种方式组成。

业务层面

如果可以改代码的话，可以在登录环节前先做个密码复杂度的判断，代码可以参考 https://blog.csdn.net/REPCHAOCHAO/article/details/119835276 这篇文章。当初我整改 Zabbix 也是在底层代码加了类似这串代码忽悠过去的。

系统层面

抄作业吧，以下内容抄 CSDN 的内容。

在linux下设置密码复杂度办法：

（1）修改/etc/login.defs文件
PASS_MAX_DAYS   90  #密码最长过期天数
PASS_MIN_DAYS   80  #密码最小过期天数
PASS_MIN_LEN    10  #密码最小长度
PASS_WARN_AGE   7   #密码过期警告天数

(2)修改/etc/pam.d/system-auth文件
找到 password requisite pam_cracklib.so这么一行替换成如下：
password  requisite pam_cracklib.so retry=5  difok=3 minlen=10 ucredit=-1 lcredit=-3 dcredit=-3 dictpath=/usr/share/cracklib/pw_dict

参数含义：
尝试次数：5  最少不同字符：3 最小密码长度：10  最少大写字母：1 最少小写字母：3 最少数字：3 密码字典：/usr/share/cracklib/pw_dict

这里要注意一下，有些客户以前就是设置太严格了，连 root 都被锁定了（还赖我们堡垒机有问题hhhh）。这种情况下只能进救援模式，然后进 shell 界面执行以下命令强行解除。

> pam_tally2 -u root -r
#上面这里最好多执行几次
> pam_tally2 -u root
Login           Failures Latest failure     From
root                0 
这里次数为0就是已经解除设置了

三权分立

（1）登录系统的用户存在未相应分配不同的账户，存在使用共用、默认账户的情况；
（2）仅设置一个管理员账户，共用登录。
（1）建立安全策略设置权限表，并根据权限表分配系统登录的用户和权限，严禁仅设置多个管理级别高的管理员账户；
（2）系统为每一需登录系统的自然人，建立独立的用户及权限。

这种就是三权分立，不允许一家独大。这样需要在业务系统或者操作系统添加三种用户，安全管理员（secadmin）、审计管理员（auditor）和系统管理员（sysadmin）。业务系统的管理员不能叫 admin，然后这三种角色最好配置相关权限，只能操作某些界面，这样才能体现三权分立。但大多数等保人员就看看有没有这些账号，有没有权限限制就行了。没有权限限制也得说有。

存储过程安全性或数据完整性

系统配置使用加密算法对重要数据在存储过程中采取完整性保护措施。
应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等。

这个整改在以前等保我都说没办法，因为我是无法理解这句话的含义，直到我找到一篇文章 等保2.0系列安全计算环境之数据完整性、保密性测评 ，我瞬间就懂了。其实这个很简单，只要在业务系统套一层安全协议就可以了。

Web 管理界面，我们加上 HTTPS 就可以了，SSL 就是可靠的校验技术，TCP 协议本身又自带 CRC 检验，都能确保数据的完整和安全性。我们远程系统的操作界面也是通过 RDP 和 SSH 协议，这些本身自带一层加密协议，也是对存储数据过程进行保护。我们可以按照上面超链接的思路，只要我们交互的传输过程有加密协议过一手就可以达成了。再不济也可以通过 VPN 的方式套一层安全。

总结

还有待补全。打算再把我处理的 SSH 的 CVE 漏洞的处理方式写一下，因为之前升级 OPENSSH 过程中有碰壁过，因此晚点我也会写上我的整改方式。

我这边有空也会写一份用来等保的登录界面用来应付各种平台，毕竟 ELK 也非常需要这玩意，国外的开源平台基本是没等保要求的。