我需要在 AWS 实例上部署一些文件完整性监控和入侵检测软件。
我真的很想使用 OSSEC，但是它在服务器可以根据负载自动部署和关闭的环境中效果不佳，因为它需要生成服务器管理的密钥。因此，在 AMI 中包含代理将不允许在它出现时立即进行监控。
有很多选择，并且在本网站的其他帖子中列出了一些选项，但是到目前为止我所看到的没有一个解决 AWS 或基于云的部署中固有的独特问题。
谁能告诉我一些产品，最好是开源的，我们可能会用它们来涵盖需要该软件的 PCI DSS 部分？
有没有其他人在 AWS 上实现过这个？
PCI DSS 合规规则规定，如果我们使用任何计算机通过基于 Web 的虚拟终端进行卡支付，那么这些 PC 必须与 IT 网络的其余部分隔离（否则整个 IT 网络都属于 PCI 合规范围） .
我们需要呼叫中心的多人才能使用虚拟终端通过电话进行客户卡付款。问题是这些人还需要访问 IT 网络的其余部分才能完成他们的其余工作职能。
有什么实用的方法来实现这一点吗？我所能想到的要么是将 PCI 合规性的范围扩展到整个网络（我想避免这种情况），要么为每个人提供两台 PC——一台用于他们工作的主要部分，另一台仅用于卡通过虚拟终端支付。
有没有人有任何实施这个的实际经验？
这适用于 Ubuntu 14.04 和 Centos 7。
我需要限制以 root 身份主动运行的用户数量。即在 CLI 上以 root 身份登录。
基本上，我一次只希望一个用户能够以 root 身份运行命令。这里的目的是审计。
我研究了在 /etc/security/limits.conf 中设置限制，但 pam_limits.so 模块似乎只影响登录。或者登录shell。没有把握。但无论具体情况如何，它确实会阻止用户多次通过 SSH 连接到一个盒子，但不会阻止多个用户通过“sudo su”成为 root 用户。因此，设置limits.conf 仍然可以允许多个用户同时以root 身份登录。
这是我尝试过的limits.conf行来限制这个：
root hard maxlogins 1
接下来我尝试限制@admins 组中的用户。我认为这些用户是唯一允许 sudo su 到 root 的用户（基于我们现有的自定义 sudo 规则）。
@admins hard maxlogins 1
这似乎做我想做的事，但似乎笨拙/错误。称之为直觉——我不太清楚我认为这个错误的地方。
最后，“为什么？”。为什么我有这个要求？
我们正在尝试实施控制以满足 PCI-DSS 3.1 要求 8.5“不要使用组、共享或通用 ID、密码或其他身份验证方法”——强调“共享”。在 Windows 环境中，您只需授予用户执行任何操作的权限，并且没有人共享主管理员帐户。Linux 环境的设计使得在某些情况下，您确实希望以 root 身份登录。在 Linux 环境中必须有一种符合 PCI 标准的方法来解决这个问题。
我熟悉配置 Linux 服务器以符合PCI-DSS 3.2 的一些更常见的方法，至少符合SAQ A的要求。一个常见的问题是要求 8.5，它要求：
通用用户 ID 和帐户被禁用或删除
这包括 root 用户，显然不能被禁用，因此需要“补偿控制”（在 PCI-DSS 的术语中）。一个常见的配方是以下的一些变体：
ssh才能使用 SSH 密钥；sudo获取root；pam_loginuid一旦用户有root，安装记录登录用户ID；和auditd以记录 root 操作和登录用户 ID。但是，如果我今天要处理，它不是我要保护的单一机器：它是一个小型集群（目前有 10 台机器），并且能够在机器之间ssh（和scp文件）进行（和文件）真的非常有用。作为非 root 用户必须这样做将是一个真正的痛苦：几乎总是你需要的文件只能被 root 读取，并且需要放在一些只有 root 可以写入的地方。
我想要做的是允许ssh在机器之间作为 root，使用服务器上存在的 SSH 密钥。这在块中使用命令很容易。我不太担心允许破坏一台机器的人控制整个集群的安全隐患：这些机器非常相似，如果他们设法破坏一台机器，他们可能可以使用相同的过程来访问其余的./etc/ssh/sshd_configPermitRootLoginMatch Address
但是，如果我这样做，我将失去跟踪谁在运行什么命令的能力，因为当我ssh到另一台机器时，没有登录 UID 不再附加到进程。PCI-DSS 中的补偿控制需要“满足原始 PCI DSS 要求的意图和严格性”，并且要求 8.5 的意图被声明为使“跟踪系统访问和活动到个人”成为可能。在不保留登录 UID 的情况下，我们不再为允许 root 用户存在提供补偿控制。 …
TrustWave 在扫描 CentOS 方面变得更好了——我现在至少可以在提交争议时选择“我有向后移植的软件”。但是他们每个月都需要花费数小时的辛勤指向和点击他们的网站，从而提供出色的工作保障。
现在我的问题。CVE-2016-10009 尚未由 RHEL 人员修补，并且没有可用于 CentOS 的直接修复程序。在 TrustWave 对我最初争议的回应中，有以下说明：
由于这一发现会影响 PCI DSS 合规性，因此确实需要确认它已以某种方式得到解决。扫描报告中列出的要求是升级系统或利用提到的补偿控制（例如永远不要从受信任的白名单（运行时可配置）之外的路径加载 PKCS#11 模块）。
最新的 OpenSSH 补丁已修复向后移植到 OpenSSH 7.3，我不清楚是否会解决此特定漏洞。提到的“补偿控制”——只允许列入白名单的模块——正是 7.4 中的修复，所以这没有帮助，并且扫描报告没有列出任何内容。
因此，我正在寻找可以满足扫描仪的配置更改，但我找不到。 这是对这个问题的一个体面的解释。有什么我可以做的吗？完全禁用 PKCS#11？
我有一个完全打补丁的 CentOS 5.5 服务器，它没有通过 Trustwave PCI 合规性扫描。它抱怨的项目是 openssl < 0.9.8.o。
rpm -q openssl 显示：openssl-0.9.8e-12.el5_5.7
apache 标头横幅显示：服务器：Apache/1.3.41 (Unix) PHP/5.2.14 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b mod_macro/1.1.2
（注意：那个 apache 横幅甚至没有显示已安装的版本）
openssh 和 php 有类似的情况（报告的版本低于 PCI 合规性的最小值）。
我是否需要从源代码构建所有这些库才能使它们使用最新版本？或者有没有办法告诉 CentOS yum 安装新版本而不是他们向后移植的补丁版本？如果可能的话，我宁愿不去 yum 之外，这样以后的维护将得到简化
我们目前正在对运行 CentOS 的服务器进行 PCI 合规性评估。
我们收到了很多关于建议修复的“严重”问题。解决问题的建议主要是将软件包更新到最新版本。我认为合理的建议，直到我运行“sudo yum update”，然后再次运行该扫描，令人沮丧的是问题并没有消失。
我与我们的托管服务提供商（它是一个专用服务器）进行了交谈，他们说虽然版本是最新的，但它会有各种补丁来修复已知的安全问题。
他们建议为软件包运行更改日志命令，然后针对扫描中标记的每个严重问题提出申诉。所以我去为第一个问题创建一个上诉，它要求提供软件包的版本、补丁级别以及我认为我们可以免除的原因。
那么，在 CentOS 中，显示每个已安装软件包的版本号和补丁级别的最简单方法是什么？
我有一台运行带有 HVM 的 xen 的服务器，并且想让一台 VM 符合 PCI 标准。我已经阅读了 PCI 虚拟化指南，它说我需要确保 VM 之间没有信息泄漏。如何确保每个操作系统都无法拦截来自其他 DomU 的数据？
我是 PCI 领域的新手，但需要为我的团队研究 ETL（提取-转换-加载）解决方案，以将数据从一个地方移动到另一个地方。我查看了亚马逊的PCI DSS 合规资源列表，发现 Glue 不在那里。这是否意味着当需要 PCI DSS 合规性时不应使用 Glue？或者它不需要，因为它不存储数据，只是转换数据并将数据加载到 RDS 数据存储中？