TrustWave 在扫描 CentOS 方面做得更好了——我现在至少可以在提出争议时选择“我有反向移植的软件”。但他们仍然通过要求用户每月在其网站上花费数小时的辛苦点击来提供出色的工作保障。
现在回到我的问题。CVE-2016-10009 还没有被 RHEL 人员修补，而且没有直接可用的修复对于 CentOS。在 TrustWave 对我的初始争议的回复中有这样一段话：
由于此发现影响 PCI DSS 合规性，因此需要确认已以某种方式解决。扫描报告中列出的要求是升级系统或利用提到的补偿控制（例如，永远不要从受信任白名单之外的路径加载 PKCS#11 模块（运行时可配置））。
最新的 OpenSSH 补丁已将修复程序反向移植到 OpenSSH 7.3，我不清楚是否会解决这个特定的漏洞。提到的“补偿控制” - 仅允许列入白名单的模块 - 正是 7.4 中的修复程序，因此这没有帮助，并且扫描报告未列出任何内容。
因此，我正在寻找能够满足扫描仪要求的配置更改，但我找不到。 这是一个不错的解释这个问题。我能做些什么吗？完全禁用 PKCS#11？
答案1
这是一个恶意 ssh 的漏洞服务器可以攻击客户如果客户端已通过 ssh-agent 转发进行连接，和以某种方式在客户端的文件系统中安装了恶意文件。
我还认为 TrustWave 大大高估了这个问题的重要性。
也就是说，显而易见的解决方法是禁用代理转发/etc/ssh/sshd_config。
AllowAgentForwarding no
请记住，如果服务器被攻陷，攻击者只需删除它，然后等待倒霉的管理员连接他们的代理即可。所以这是一种荒谬的解决方法。
答案2
我认为这个问题没有实际意义。
据我了解，Trustwave 审查了该漏洞并调整了其 CVSS/严重性排名，因此该发现不再是 PCI 故障。
（值得重复的是AllowAgentForwarding no是一个愚蠢的转移注意力的花招。那是服务器端配置，而这是客户端漏洞。）
答案3
我认为，正如@pilcrow 所建议的那样，这是一个客户端漏洞，因此解决方法是在客户端将标志放在ForwardAgent no文件 ssh_config 中。