20 道防火墙、加密与合规练习题及答案

1. 1. 在 Linux 主机上，iptables、nftables、firewalld 和 ufw 都被称为防火墙工具。下面哪一项正确描述了它们之间的关系？

   • A.这四者各自在用户空间自带一个数据包过滤引擎，因此同时启用其中两个只是让两套独立的过滤器依次生效。
   • B.firewalld 自己检查数据包，只把允许的流量交给 netfilter，由 netfilter 为每个被接受的连接做路由决策。
   • C.过滤发生在内核 netfilter 框架；nftables 是当前用户空间接口，firewalld 和 ufw 是生成规则的前端。✓ 答案
   • D.在 Debian 系内核中 ufw 已取代 netfilter，而 nftables 只是 RHEL 系系统上用来检查规则语法的工具。

   netfilter 是真正检查数据包的内核挂钩框架。iptables 命令族及其后继 nft 都是把规则装入 netfilter 的用户空间工具；firewalld（RHEL 系）和 ufw（Debian 系）则是更上层的前端，把区域或服务请求翻译成同样的内核规则。它们都不在用户空间过滤数据包。

   编号 QB-PWQNRH依据： Linux kernel networking documentation (netfilter framework) and the nft(8), firewall-cmd(1) and ufw(8) manual pages报告此题的问题

2. 2. 一台 RHEL 系主机使用 iptables 命令做过滤。INPUT 链末尾已有一条丢弃其余所有流量的规则。管理员执行 `iptables -A INPUT -p tcp --dport 443 -j ACCEPT`，但 HTTPS 仍然无法访问。原因是什么？

   • A.链内规则自上而下依次匹配、首次命中即生效，靠前的丢弃规则已经处理了该数据包；需要用 `-I` 把放行规则插到它前面。✓ 答案
   • B.ACCEPT 目标只在 nat 表中有效，因此这条规则必须改用 `-t nat -A INPUT` 重新添加，否则它无法放行任何入站 HTTPS 连接。
   • C.使用 `-A` 追加时规则默认进入 FORWARD 链，因此发往本机自身的流量根本不会与这条新规则做比较。
   • D.除非规则同时带上 `-m conntrack --ctstate NEW`，`--dport` 匹配会被忽略，内核会跳过它并落到丢弃规则上。

   在一条链内，netfilter 按顺序遍历规则，在第一条条件匹配的规则处停止并执行其目标。由于兜底的丢弃规则位于追加规则之前，数据包在到达 ACCEPT 之前就被丢弃了。`-A` 追加到链尾，而 `-I` 插入到链首或指定的行号位置，这才能把放行规则放到丢弃规则前面。

   编号 QB-7EWTBJ依据： iptables(8) manual page, rule specification and the -A and -I options报告此题的问题

3. 3. 一次评审询问：为什么一条 iptables 规则以 `-j DROP` 结尾，而另一条以 `-j REJECT` 结尾？这两个目标在实际效果上有什么区别？

   • A.DROP 会回送 ICMP 端口不可达消息，而 REJECT 只是静默丢弃数据包，所以在内部网络中 DROP 能提供更多信息。
   • B.DROP 丢弃数据包且不做任何回应，发送方只能等到超时；REJECT 丢弃后回送 ICMP 错误，发送方会立即失败。✓ 答案
   • C.DROP 丢弃数据包并把它记入内核环形缓冲区，而 REJECT 丢弃时不做任何记录，因此审计场景更倾向使用 DROP。
   • D.两者丢弃数据包的方式完全相同；REJECT 只是为兼容旧版 iptables 保留的别名，对线路上的响应没有任何影响。

   DROP 把数据包交给内核的丢弃路径，不回送任何内容，客户端的连接尝试只能挂到超时，这同时也让主机在随意探测下显得不存在。REJECT 同样丢弃数据包，但会产生一个 ICMP 错误（默认是端口不可达，也可用 `--reject-with` 选择其他类型），客户端会立即失败。两者都阻止了流量，区别在于发送方能得知什么以及多快得知。

   编号 QB-QW3ZWJ依据： iptables-extensions(8) manual page, REJECT target and its --reject-with option报告此题的问题

4. 4. 某团队要在两种设计之间选择：INPUT 默认策略为 DROP 并配一份显式放行清单，或 INPUT 默认策略为 ACCEPT 并配一份显式拒绝清单。为什么说前一种设计是“失效即关闭”？

   • A.DROP 策略只对管理状态为 up 的接口生效，因此只要还有接口在初始化，主机就会一直处于不可达状态。
   • B.DROP 策略会让内核在任何规则被删除时重新载入已保存的规则集，在流量通过之前恢复到上一个已知良好的配置。
   • C.DROP 策略会让连接跟踪把每个数据包都当作 NEW 处理，半开连接因此被清理，攻击者也无法复用已有的状态条目。
   • D.DROP 策略丢弃无放行规则匹配的流量，编辑时漏掉一条规则的代价是可用性下降，而非悄悄暴露主机。✓ 答案

   在默认拒绝下，放行清单就是被允许流量的完整表述，任何都不匹配的数据包会落到链的默认策略上被丢弃。因此配置出错表现为服务不可用，这是可见的、会被立刻修复的。而在默认允许下，拒绝清单必须穷举所有不想要的情况，凡是作者没想到的，或者之后才开始监听的服务，都是可达的，而且不会有任何报错提示。

   编号 QB-8E96HK依据： iptables(8) manual page, chain policy (-P); CompTIA Linux+ security content domain, firewall policy design报告此题的问题

5. 5. INPUT 默认策略为 DROP，已放行入站 SSH，另有一条规则为 `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`。此后从该主机浏览网页是正常的，尽管没有任何规则提到回程流量。原因是什么？

   • A.本机自己产生的流量不受 INPUT 过滤，因此对主机主动发起的请求的回应会完全绕过该链，不需要单独的规则。
   • B.RELATED 状态会在会话期间打开 1024 以上的所有端口，远端 Web 服务器的回程流量正是这样到达客户端进程的。
   • C.连接跟踪记录了出向流，回程数据包因此匹配 ESTABLISHED 而被放行，无需任何规则指明服务器或其端口。✓ 答案
   • D.链的默认策略只有在所有 ACCEPT 规则两次匹配失败后才被查询，这让回程数据包获得按源端口匹配的第二次机会。

   有状态防火墙为它见过的每一条流保存一个 conntrack 条目。主机发起出向连接时该条目被建立，服务器的回程数据包被识别为属于该连接并归类为 ESTABLISHED，因此那一条 ESTABLISHED,RELATED 规则就放行了它们。RELATED 覆盖的是相关但独立的流，例如针对该连接的 ICMP 错误。若没有连接跟踪，就必须写无状态规则去匹配每一种可能的回程流量。

   编号 QB-RWEB4M依据： iptables-extensions(8) conntrack match; Linux kernel networking documentation on connection tracking报告此题的问题

6. 6. 在一台 RHEL 系服务器上，管理员执行了 `firewall-cmd --permanent --add-service=https`，随后立即从另一台机器测试该服务，连接仍被拒绝。这是什么情况？

   • A.带 --permanent 的改动只写入保存的配置，须 `firewall-cmd --reload` 才生效。✓ 答案
   • B.该改动其实已经生效，但必须先把 https 服务写入 /etc/services，firewalld 才能把这个名字解析成端口号。
   • C.该命令只改变了正在运行的规则集，所以现在有效，但除非再执行 `--runtime-to-permanent`，下次重启就会丢失。
   • D.永久改动只会应用到默认区域，因此测试失败是因为承载测试流量的那个接口被绑定在另外一个完全不同的区域上，规则并未生效。

   firewall-cmd 维护两套彼此独立的配置。不加 --permanent 的改动直接进入正在运行的规则集，重新载入或重启后丢失；加了 --permanent 则写入 firewalld 保存的配置，而正在运行的规则集不变。`firewall-cmd --reload` 读取永久配置并将其装入内核，这一步才让新服务可达。`--runtime-to-permanent` 的作用正好相反，是把已验证可用的运行时规则集保存下来。

   编号 QB-9EMGPM依据： firewall-cmd(1) manual page, --permanent, --reload and --runtime-to-permanent options报告此题的问题

7. 7. 管理员通过 SSH 在一台由 firewalld 管理的主机上操作，把 ssh 服务从活动区域中移除（仅作为运行时改动），随后无法再建立新会话，但当前会话仍然可用。哪一个操作能用已保存的配置恢复 SSH 访问？

   • A.执行 `firewall-cmd --runtime-to-permanent`，它用运行中的规则集重写保存的配置，恢复上一个状态。
   • B.执行 `firewall-cmd --reload`，它会丢弃运行时的规则集并装入磁盘上的永久配置，而在那份永久配置里 ssh 服务仍然是放行的。✓ 答案
   • C.执行 `firewall-cmd --complete-reload`，它会清空连接跟踪，被阻断的 SSH 握手会在下一次尝试时重试并成功。
   • D.执行 `firewall-cmd --panic-on`，它会暂停全部包过滤，直到管理员再次关闭该模式，从而让新的 SSH 会话通过。

   `--reload` 会丢弃运行时规则集并从磁盘重新载入永久配置，因此一个尚未保存的运行时错误正好被它撤销。这也正是有风险的防火墙改动要先在运行时做、确认可用后再用 `--runtime-to-permanent` 提升的原因；在本例中执行该命令反而会把坏掉的规则集保存下来，而 `--panic-on` 是阻断全部流量而非恢复访问。

   编号 QB-SWSN9N依据： firewall-cmd(1) manual page, --reload versus --runtime-to-permanent and --panic-on报告此题的问题

8. 8. 一台有两个网络接口的 Linux 路由器需要：(a) 让内网子网通过它唯一的动态公网地址访问互联网；(b) 把内网的一台 Web 服务器发布到该公网地址上。用 iptables 实现时，哪一种搭配是正确的？

   • A.出向用 nat 表 PREROUTING 链中的 DNAT，入向用 nat 表 POSTROUTING 链中的 MASQUERADE 做重定向。
   • B.出向用 nat 表 POSTROUTING 链中的 MASQUERADE，入向用 nat 表 PREROUTING 链中的 DNAT 做重定向。✓ 答案
   • C.出向用 filter 表 INPUT 链中的 SNAT，入向用 filter 表 OUTPUT 链中的 REDIRECT 做重定向。
   • D.出向用 mangle 表 OUTPUT 链中的 MASQUERADE，入向用 mangle 表 FORWARD 链中的 DNAT 做重定向。

   源地址转换必须发生在路由决策之后，因此位于 POSTROUTING；MASQUERADE 这个变体会取出口接口当前持有的地址作为源地址，正好满足动态公网地址的需要。目的地址转换必须发生在路由决策之前，这样数据包才会被继续路由到内网服务器，所以端口转发用 PREROUTING 中的 DNAT。两者都属于 nat 表；此外还必须持久地启用 IP 转发，否则流量根本不会在两个接口之间转发。

   编号 QB-AEYTUN依据： iptables(8) and iptables-extensions(8) manual pages, nat table chains with the SNAT, MASQUERADE and DNAT targets报告此题的问题

9. 9. 一台 Debian 系服务器需要一个最简防火墙：拒绝未经请求的入站流量，但保持 SSH 可达，并用 ufw 配置。哪一个操作序列是正确的，ufw 又是如何处理这些规则的？

   • A.先 `ufw default drop all`，再 `ufw permit ssh`，最后 `ufw start`；ufw 以独立守护进程运行，在内核 netfilter 钩子看到数据包之前先行检查。
   • B.只需 `ufw allow OpenSSH` 即可，因为只要引用了 /etc/ufw/applications.d 下的任一应用配置，ufw 就会立刻拒绝入站流量。
   • C.先 `ufw enable`，再 `ufw allow 22`，最后 `ufw reload`；ufw 把规则存在自己的数据库里，每条放行规则都要 reload 后才生效。
   • D.先 `ufw default deny incoming`，再 `ufw allow OpenSSH`，最后 `ufw enable`；ufw 把规则翻译成 netfilter 规则，并在每次启动时重新应用。✓ 答案

   ufw 是 Debian 系提供的简化前端。`ufw default deny incoming` 设定兜底方向，`ufw allow OpenSSH` 使用指明端口的应用配置，`ufw enable` 既立即启用策略，也安排在启动时恢复它，所以与裸 iptables 命令不同，规则集是持久的。在底层，ufw 生成的是 netfilter 规则，它本身并不过滤数据包。

   编号 QB-TW5ZEP依据： ufw(8) manual page, default policy, application profiles and the enable subcommand报告此题的问题

10. 10. 管理员需要用 Linux 上的 GnuPG 把一个大归档文件发给外部合作方，且只有该合作方能读取。应采用哪种做法，其中各把密钥分别起什么作用？

    • A.用 `gpg -c` 配共享口令加密，因为对称模式才能让一个完全没有密钥对的接收方解开收到的文件。
    • B.用 `gpg --detach-sign` 对归档签名，因为分离签名会让没有签名者公钥的人无法读取文件内容。
    • C.用 `gpg --encrypt --recipient` 指定管理员自己的公钥加密，因为发送方的密钥对才是确立该文件来源的东西。
    • D.用 `gpg --encrypt --recipient` 指定已导入的合作方公钥加密，因为只有合作方持有的对应私钥才能解密。✓ 答案

    公钥加密是有方向的：用某个公钥加密的数据只能由对应的私钥解密。因此要让某个指定接收方获得机密性，就要用该接收方的公钥加密，而这把公钥必须先用 `gpg --import` 导入本地钥匙环，并最好核对其指纹。`gpg -c` 是对称加密，需要另行带外共享口令；而分离签名提供的是真实性与完整性，完全不提供机密性。

    编号 QB-PRX7BR依据： gpg(1) manual page, --encrypt with --recipient, --symmetric and --detach-sign报告此题的问题

11. 11. 一个备用分区刚刚用 `cryptsetup luksFormat /dev/sdb1` 初始化，并用 `cryptsetup open /dev/sdb1 secure` 打开。正确的下一步是什么，为什么？

    • A.执行 `mkfs.ext4 /dev/sdb1`，因为文件系统必须建在分区本身上，这样 LUKS 头部才能随后追加到它后面。
    • B.对 /dev/mapper/secure 再执行一次 `cryptsetup luksFormat`，因为映射设备需要自己的头部才能创建文件系统。
    • C.执行 `mkfs.ext4 /dev/mapper/secure`，因为映射设备是该分区解密后的视图，经由它写入的一切都会以加密形式落盘。✓ 答案
    • D.执行 `mount /dev/mapper/secure /mnt`，因为 luksFormat 在写入 LUKS 头部时已经在容器内建好了文件系统。

    `cryptsetup open` 会创建一个 device-mapper 节点 /dev/mapper/secure，它呈现容器解密后的内容；文件系统必须建在这个节点上，因为经由它写入的数据会先用卷的主密钥加密再落到 /dev/sdb1。若改为格式化裸分区，会覆盖 LUKS 头部并使容器无法访问；由于主密钥就存放在该头部中，备份头部才是保护数据的手段，而销毁头部会让数据无法恢复。

    编号 QB-69S2RQ依据： cryptsetup(8) manual page, luksFormat and open with the device-mapper node under /dev/mapper报告此题的问题

12. 12. 针对同一个文件比较三种机制：SHA-256 摘要、用 SHA-256 和共享密钥计算的 HMAC，以及一个 GnuPG 签名。下面哪一项说明了它们各自能证明什么？

    • A.摘要只能发现改动；HMAC 还能说明发送方知道共享密钥；签名把文件绑定到某一把私钥的持有者。✓ 答案
    • B.三者证明来源的能力完全相同，只是输出长度不同，所以选择哪一个取决于存储该值需要多少空间。
    • C.摘要和 HMAC 都能证明来源，因为二者都依赖某个秘密；而签名只能说明文件在传输中没有被改动。
    • D.摘要能证明来源，因为只有发布者才能算出它；HMAC 没有增加任何东西；签名只是把摘要压缩后便于传输。

    普通摘要只根据数据本身计算，任何人都能重新算出来：它能发现改动，但完全说明不了文件由谁产生。HMAC 把共享密钥混入计算，因此正确的值说明产生者持有该密钥，不过持有该密钥的任一方都可能产生它。签名用私钥生成、用对应公钥校验，因此把文件绑定到某一个特定的密钥持有者，既提供完整性也提供真实性。

    编号 QB-NRKV5Q依据： gpg(1) --verify and openssl-dgst(1) -hmac; CompTIA Linux+ security content domain, hashing and message authentication报告此题的问题

13. 13. 从社区镜像站下载了一个 tar 归档，其 `sha256sum` 输出与项目下载页面上给出的摘要一致。这实际上证明了什么？

    • A.证明文件真实且来自该项目，因为除了项目本身，没有任何人能算出与所下载字节完全一致的摘要值。
    • B.证明归档中不含恶意代码，因为对被改动过的归档计算出的摘要绝不可能与项目公布的那个值相同。
    • C.证明字节与公布摘要一致；但控制镜像与摘要页的攻击者也能通过，故仍需 `gpg --verify`。✓ 答案
    • D.证明下载过程受到端到端保护，因为摘要只有在客户端校验过证书的 TLS 连接上才可能完好无损地传输过来。

    校验和比对只能说明你手上的字节就是当初计算摘要时用的那些字节，这是针对传输损坏以及针对无法同时改动公布值的篡改者的完整性检查。如果同一方同时控制文件和列出其摘要的页面，两者会一起被改动，检查依然会通过。真实性需要攻击者无法伪造的东西，这正是项目会为校验和文件发布分离签名的原因。

    编号 QB-59EQJP依据： sha256sum(1) and gpg(1) --verify; CompTIA Linux+ security content domain, file integrity and signed package verification报告此题的问题

14. 14. 为一台公网 Web 服务器，管理员先执行 `openssl genpkey`，再执行 `openssl req -new -key server.key -out server.csr`。生成的请求里包含什么，CA 又贡献了什么？

    • A.它携带公钥以及身份信息，CA 对其整体签名，于是任何信任该 CA 的客户端都会接受其中声明的身份。✓ 答案
    • B.它携带一份自签名证书，CA 会为该证书重新签发有效期，使客户端在剩余有效期内接受原有签名。
    • C.它携带私钥以便 CA 校验，CA 会把同一把密钥包在证书里连同自己根密钥的副本一起返回。
    • D.它携带打算使用的加密算法清单，CA 会代管理员选定密钥对，然后签发对应的证书。

    证书签名请求由密钥对生成，但只包含其中的公钥部分，加上主体名称和所请求的扩展项，并用自身私钥签名以证明确实持有该私钥；私钥始终不离开服务器。CA 的贡献是它的签名，用来证明所声明的身份已按其公开标准核验过；客户端接受该证书是因为它们本来就信任该 CA 的根证书，而不是因为请求本身有什么特别之处。

    编号 QB-RRNVNT依据： openssl-req(1) manual page, certificate request generation; X.509 certificate path validation报告此题的问题

15. 15. 一台内部 Linux Web 服务器提供的是用 `openssl req -x509` 生成的证书。主机名匹配、有效期正常、私钥也正确，但浏览器仍提示连接不是私密连接。原因是什么？

    • A.因为用 `-x509` 生成的证书并不包含公钥，客户端无法完成密钥交换，于是把结果报告为不受信任。
    • B.因为自签名证书的有效期被限制得很短，而浏览器会拒绝任何有效期低于其最低要求的证书。
    • C.因为 `-x509` 输出的是签名请求而不是证书，服务器提供的文件客户端根本无法解析成证书。
    • D.因为该证书由自己的密钥签名，而非客户端信任库中的任何证书，证书链止于无法验证的签发者。✓ 答案

    客户端校验会沿证书链一路上溯，直到遇到本地信任库中已有的证书。自签名证书的签发者就是它自己，因此证书链终止于一个客户端从未被告知要信任的锚点，无论主机名和日期多么正确，警告都会出现。解决办法是改用根证书已被信任的 CA 签发的证书，或者有意把内部 CA 的根证书安装进客户端信任库；`openssl req -x509` 确实生成的是真正的证书，只是不受信任而已。

    编号 QB-89GQ3T依据： openssl-req(1) manual page, -x509 self-signed output; X.509 certificate path validation and local trust anchors报告此题的问题

16. 16. 一个已稳定运行一年的 HTTPS 服务在某个周一早晨突然对所有客户端失败，而周末并没有做过任何部署。应该先做哪一项检查，为什么证书过期是一种长期存在的运维风险？

    • A.重启 Web 服务并查看其日志，因为过期证书会在服务下次启动时被自动重新加载并续期。
    • B.用 `openssl x509 -enddate -noout -in server.crt` 读取有效期。✓ 答案
    • C.把证书指纹与 CA 根证书比对，因为 CA 把根证书轮换成更长的密钥后，原有证书链就会失效。
    • D.检查私钥是否仍与证书匹配，因为随着文件系统长期不断写入，密钥文件会逐渐与证书失去对应关系，从而握手失败。

    证书带有固定的 notBefore 与 notAfter 时间戳，因此时钟一过 notAfter 就校验失败，即使没有任何文件被改动、没有任何配置被修改也是如此——这正是一个原本正常、未被改动的服务会自行崩掉的原因。`openssl x509 -enddate` 从文件中读出该日期，`openssl s_client -connect host:443` 则显示服务器实际提供的是什么，因此续期必须被跟踪并自动化，而不能靠人记。

    编号 QB-QRAJGS依据： openssl-x509(1) manual page, -dates and -enddate; openssl-s_client(1) for the served chain报告此题的问题

17. 17. 某团队在一台新装好的 RHEL 系服务器上安装 AIDE，编辑了 /etc/aide.conf，运行 `aide --init`，随后运行 `aide --check`，却报告找不到数据库。缺了哪一步，又是什么让基线可信？

    • A.AIDE 每次检查都必须加上 `--config /etc/aide.conf`，而基线之所以可信，是因为 AIDE 每次检查都会重新计算整个数据库。
    • B.AIDE 在首次检查前必须用 `aide --update` 注册数据库，而基线之所以可信，是因为它随安装包一起提供。
    • C.AIDE 会把新数据库写成 aide.db.new.gz，必须改名为配置中指定的名字；而基线只有在干净主机上建立并离机保存时才可信。✓ 答案
    • D.AIDE 要求先把保存的数据库解压缩，而基线之所以可信，是因为它的摘要由包管理器重新算出。

    `aide --init` 故意写入一个新文件，以免意外覆盖已有基线；必须把它移动或改名为 /etc/aide.conf 中设定的数据库路径，`aide --check` 才有可供比对的对象。该机制只能回答“与基线相比是否发生了变化”，因此基线必须在确认干净的系统上建立，并保存在入侵者无法改写的地方，否则攻击者只需把自己的改动重新做成基线即可。

    编号 QB-795DWR依据： aide(1) and aide.conf(5) manual pages, --init and --check with the database_out setting报告此题的问题

18. 18. 一台 RHEL 系主机可能已被篡改。管理员需要：(a) 确认下载到的软件包文件确实来自厂商；(b) 查明磁盘上已有的文件是否与软件包交付的内容不同。哪一种搭配是正确的？

    • A.下载的包用导入了厂商密钥的 `rpm --checksig pkg.rpm` 校验；已安装文件用 `rpm -Va`，它会把文件与 RPM 数据库记录比对。✓ 答案
    • B.下载的包用 `rpm -Va` 校验，因为它能验证任意包文件的签名；磁盘上已安装的文件则用 `rpm --checksig pkg.rpm`。
    • C.下载的包用 `sha256sum pkg.rpm` 校验，因为仅凭摘要即可确立厂商身份；已安装文件用 `rpm -qa`，它会列出每个包交付的内容。
    • D.下载的包用 `rpm --import` 处理，因为导入该文件就把它登记为可信；已安装文件用 `rpm -qi`，它会打印期望的摘要值。

    这是两件不同的事。`rpm --checksig`（等价于 `rpm -K`）用先前通过 `rpm --import` 导入的密钥校验包文件中内嵌的签名，这才能确立该文件来自厂商且未被改动。`rpm -V` 和 `rpm -Va` 完全不做签名校验：它们把已安装文件与 RPM 数据库中记录的大小、权限位、摘要、属主、属组和时间戳比对，每一项未通过的测试打印一个标志，未被改动的文件则没有任何输出；配置文件会标记为 `c`，本来就预期会不同。

    编号 QB-TRCJZV依据： rpm(8) manual page, --checksig and -K, and the -V verify options with their result flags报告此题的问题

19. 19. 在一台 Debian 系服务器上有四项安全任务：查出实际在监听的网络服务、把主机配置与已公布的加固基准做对比、了解自某个已知良好时间点以来是否有被监控文件发生变化、以及查找已知 rootkit 的痕迹。哪一种工具与任务的对应关系是正确的？

    • A.端口扫描器检查配置基准，OpenSCAP 找出正在监听的服务，rkhunter 发现被改动的文件，AIDE 在磁盘上寻找 rootkit 痕迹。
    • B.OpenSCAP 找出正在监听的服务，AIDE 检查配置基准，端口扫描器发现被改动的文件，rkhunter 汇报加固基准的符合情况。
    • C.AIDE 找出正在监听的服务，rkhunter 检查配置基准，OpenSCAP 发现被改动的文件，端口扫描器寻找 rootkit 痕迹。
    • D.端口扫描器找出正在监听的服务，OpenSCAP 检查配置基准，AIDE 发现被改动的文件，rkhunter 寻找 rootkit 痕迹。✓ 答案

    这几种工具回答的是不同的问题，不能互相替代。端口扫描器从网络侧探测可达端口，显示哪些服务被暴露；在本机上，`ss -tulpn` 能显示同样的监听项以及各自所属的进程。OpenSCAP 依据可机读的 SCAP 内容（例如已公布的加固基准配置文件）评估运行中的配置，并逐条规则报告通过或失败。AIDE 把文件系统与保存的摘要和属性基线比对，因此它发现的是变化，而不是暴露面。rkhunter 则搜索已知 rootkit 的特征迹象。

    编号 QB-A97DEV依据： oscap(8), aide(1), rkhunter(8) and ss(8) manual pages; CompTIA Linux+ security content domain, vulnerability scanning and file integrity报告此题的问题

20. 20. 在一台 RHEL 系主机上，依据 SCAP Security Guide 内容执行了 `oscap xccdf eval --profile <profile_id> --results results.xml --report report.html`，若干规则未通过。对这个结果的正确解读和下一步分别是什么？

    • A.扫描在评估过程中已经自行修正了未通过的规则，因此该报告记录的是一台已经完全符合所选基准配置文件的主机。
    • B.报告记录的是该时刻主机的状态；修复是单独的一步，之后重新扫描才是发现项已关闭的证据。✓ 答案
    • C.规则未通过说明该配置文件不适用于这台主机，正确做法是换用别的配置文件，直到扫描不再出现任何失败项。
    • D.报告就是审计人员需要的交付物，一旦归档，发现项即可视为关闭，只需安排下一次例行扫描。

    XCCDF 评估把运行中的配置与所选配置文件中的规则逐条比对，写出结果文件和一份便于人阅读的报告；除非显式请求修复（使用修复选项，或根据结果生成修复脚本/剧本并执行），它不会改变任何东西。因此报告是某一时刻状态的证据，而不是结果本身：只有在配置被改动、并且重新扫描显示该规则通过之后，发现项才算关闭。对数据流执行 `oscap info` 可以列出可用于 `--profile` 的配置文件标识。

    编号 QB-STXCUU依据： oscap(8) manual page, xccdf eval with --profile, --results, --report and the remediation option报告此题的问题

练习题依据 CompTIA 公布的 Linux+ 考试大纲及 Linux 系统管理的通行实践编写。CompTIA 和 Linux+ 是 CompTIA 的商标，Linux 是 Linus Torvalds 的注册商标；本网站与 CompTIA 无关联，也未获其认可。真实考试除选择题外还包含实操题（performance-based questions），要求在模拟环境中实际完成任务——四选一的题型无法复现这一部分，因此本题库覆盖的是知识部分，请同时在真实系统上动手练习。CompTIA 会定期修订大纲并为每个版本编号：报考前请向 CompTIA 确认现行大纲、考试代码与报考要求。 关于 CompTIA Linux+ 认证 →