由于篇幅的关系，文章主要介绍一下能力验证需要查看的点，详细的技术知识可能不会写的特别详细，有需要的小伙伴可以关注一下公众号，不定期更新针对于等保2.0测评条款技术细节文章，例如pam模块详解、Linux文件扩展权限ACL等，并可免费获取2022能力验证作业指导书以及Linux虚拟机环境文件，配合文章模拟分析复现食用更佳。

续上篇，这篇主要分析能力验证中 Linux 主机的剩余访问控制条款

四、  入侵防范

a）应遵循最小安装的原则，仅安装需要的组件和应用程序；

这个也没想到，考的是非常细，当时没看，所以也没现场的截图，有的兄弟可以截图发我一下，万分感谢。根据答案的话docker ps -a、docker ps命令查看一下，应该就是没有容器在运行，所以判断为多余。或者通过systemctl list-units --type=service 列出系统上安装的所有服务单元，判断多余。

rlogin估计也是类似，有服务运行着，但没用

查看开机自启服务 systemctl list-unit-files | grep enabled

总得来说这种多余服务个人感觉比较难查，也比较容易失分，可能能力不太够，得看运气。

b）应关闭不需要的系统服务、默认共享和高危端口；

这条的话就不多加赘述了，上文有描述

centos 7 是修改 /usr/lib/systemd/system/telnet.socket 文件 ListenStream 参数

c）应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制；

先看相关安全策略

然后这里我们介绍一下设置远程地址限制的常见方式有哪几种

1.  防火墙

查看当前防火墙是否开启

systemctl status firewalld.service

firewall-cmd --state

开启情况下，查看对应策略

其实我不太明白它是个centos 7.x的系统版本，用的东西好多是6的，正常来说应该用firewalld的。

那么针对iptables，首先先看服务是否正常运行

再查看cat /etc/sysconfig/iptables 文件确认相关配置（此图不为实际环境，为模拟配置环境）

-A：add，添加规则（添加的规则放到最后）

INPUT：进站请求（出站：output）

-p：protocol，指定协议（icmp/tcp/udp）

--dport：指定端口号

-j：指定行为结果，允许（accept）/禁止（reject）

-s：指定源端口号或范围

-m：指定要使用的模块

ACCEPT：代表允许

2.  hosts.allow与hosts.deny文件

hosts.deny中添加设置 sshd : ALL，再次使用ssh连接，会出现：ssh_exchange_identification: read: Connection reset 的错误，但是已经连接上的ssh是不会中断的，说明 hosts.deny时在连接时查询的配置文件。

然后在hosts.allow中添加设置sshd : 192.168.56.1，再次使用ssh可以成功连接。

在设置屏蔽所有ssh后，在单独允许192.168.56.1这个ip地址，ssh是允许的，那么就存在优先级问题。优先级为先检查hosts.deny，再检查hosts.allow。

两个配置文件的格式如下：

服务进程名:主机列表:当规则匹配时可选的命令操作。

为了安全可以在hosts.deny文件中配置拒绝所有的访问ALL:ALL，然后在hosts.allow文件中逐个开放访问许可，增强安全性。

sshd可以换成其他服务进程名，比如httpd、telnetd等等。

3.  sshd_config文件

只允许指定用户进行登录（白名单）：

/etc/ssh/sshd_config配置文件中设置AllowUsers选项：

AllowUsers      test             test1@192.168.1.1

允许test和从192.168.1.1登录的test1账户通过SSH登录系统

只拒绝指定用户进行登录（黑名单）：

/etc/ssh/sshd_config配置文件中设置DenyUsers选项：

DenyUsers  test   test1

拒绝test test1账户通过SSH登录系统

那么这里能力验证采用的就是iptables的方式，查看到ssh入站规则多设置了一个日志审计地址的ip所以不符合，同时未针对telnet服务设置相应的入站规则。

五、  数据完整性

a）应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等;

这条就没啥好分析的，传输过程中一般是通过ssl 来保证完整性的，telnet不具备这个特性，所以不符合

具体的https建立安全连接的过程（SSL原理），可以参考一下这篇文章

https://blog.csdn.net/xiaopang_yan/article/details/78709574

b）应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等。

看下对应的安全策略，发现说了等于没说

这里的当时没注意到另外的账户有对应的计划任务，所以只能进行相应的复现了。

像这类的条款，基本上都是通过计划任务去实现的，由于之前能力验证用的是tripwire 来验证操作系统完整性功能，然后本次我先是看了/etc/crontab和crontab -l，然后用tripwire对应命令，发现没有相关命令，就以为没有完整性检测了，所以这里失分了，正确的方法应该进入到/var/spool/cron目录下去查看有哪些用户的计划任务

上面我们看到有root和securityM01账户执行了计划任务，那么我们就具体看看执行了什么任务，root之前是有看过的，所以我草率的认为没做完整性的计划任务

再看securityM01的对应计划任务（下面图为模拟搭建环境测试截图）

发现此次使用了aide来校验完整性

在/var/lib/aide存储的是完整性校验基准模版。

随意找一个可以看到如下日志结果，发现修改过的为/etc/shadow、/etc/sysconfig/iptables

问题预设点：配置文件中少了对重要文件的完整性检测

配置文件 /etc/aide.conf，猜测配置应该是这样的

! 表示不监控的文件

估计实际配置也是类似情况，未对/etc/group、/etc/pam/.*~、/etc/sudoers等重要文件进行完整性检测。

六、  数据备份与恢复

a）应提供重要数据的本地数据备份与恢复功能；

然后我们找到对应的安全策略

发现并没有明确指出备份单机配置数据的对应安全策略，仅给了日志文件的备份策略，那么这条就按我们正常的测评流程来查看。

首先备份一般是通过计划任务完成，或者第三方软件实现。使用crontab -l 查看到当前root用户的计划任务，发现存在两个计划任务。

log_bak.sh已在安全审计中有对应的解释，这里就不过多赘述。生成文件正常即可

咱们直接看etc_bak.sh中的内容

在每日的凌晨3点，对/etc/整个目录进行备份压缩保存，保存至/root/etcbak/目录下，我们去查看是有对应备份文档生成即可。

没问题所以该条符合。

以上就是2022年能力验证配置核查Linux操作系统的大致情况了，今年的能力验证马上也马上要开始了，争取将mysql数据库也更新出来！