最近（但这也是一个反复出现的问题），我们看到了 3 个有关黑客和安全的有趣帖子：
最后一个并没有直接关系，但是它强调了 Web 服务器管理是多么容易陷入混乱。
因为有几件事可以做，前当一些不好的事情发生时，我希望得到您的建议，关于限制攻击的负面影响的良好做法，以及在发生不幸事件时如何应对。
这不仅仅是保护服务器和代码的问题，也是审计、日志记录和对策的问题。
您是否有任何良好的实践列表，或者您是否愿意依赖软件或专家来持续分析您的 Web 服务器（或根本不分析）？
如果是，您能分享您的清单和想法/意见吗？
更新
我收到了一些很好的、有趣的反馈。
我希望有一个简单的列表，这样既可以方便 IT 安全管理员使用，也可以方便网络使用杂役大师。
即使每个人都给出了好的、正确的答案，目前我还是更喜欢罗伯特因为它是最简单、最清晰、最简洁的，也是系统管理员1138因为它最完整、最精确。
但是没有人考虑用户的观点和看法，我认为这是首先要考虑的。
用户访问我被黑的网站时会想些什么，如果你拥有关于他们的敏感数据，那就更是如此了。这不仅仅是在哪里存储数据的问题，而是如何平息愤怒的用户的问题。
数据、媒体、当局和竞争对手又如何呢？
答案1
有两大领域需要关注：
- 使得进入变得困难。
- 制定政策和程序，以便冷静、有效地处理有人越过第 1 点的事件。
很难进入
这是一个非常复杂的话题，其中很多内容都集中在确保你有足够的信息来弄清楚事后发生了什么。为简单起见，以下是摘要要点：
- 保留日志（另请参阅安全信息事件管理）
- 任何授权尝试，无论成功或失败，最好都保持源信息完整。
- 防火墙访问日志（如果使用，则可能必须包括每个服务器的防火墙）。
- Web 服务器访问日志
- 数据库服务器身份验证日志
- 特定于应用程序的使用日志
- 如果可能的话，SIEM 可以对可疑模式发出警报。
- 实施适当的访问控制
- 确保在任何地方都正确设置权限，并尽可能避免“懒惰权限”（“哦，只需让每个人都阅读”）。
- 定期审核 ACL，以确保程序确实得到遵循，并且在故障排除完成后正确删除了临时的故障排除步骤（“让每个人都阅读，然后查看是否有效”）。
- 所有防火墙直通规则都需要合理化，并定期审核。
- Web 服务器访问控制也需要审核，包括 Web 服务器和文件系统 ACL。
- 执行变更管理
- 安全环境的任何变化都需要由多人集中跟踪和审查。
- 补丁应该包含在此过程中。
- 拥有通用的操作系统构建（模板）将简化环境并使更改更易于跟踪和应用。
- 禁用访客帐户。
- 确保所有密码均未设置为默认密码。
- 现成的应用程序可能会为用户设置预定义的密码。更改它们。
- 许多 IT 设备出厂时都附带众所周知的用户名/密码对。即使您每年只登录一次，也请更改这些密码。
- 践行最低权限。给予用户他们真正需要的访问权限。
- 对于管理员用户来说，设置两个帐户是明智的。一个普通帐户用于电子邮件和其他办公任务，另一个用于提升权限的工作。虚拟机使这更容易实现。
- 不鼓励经常使用通用管理员/根帐户，因为很难追踪谁在什么时候做了什么。
制定政策和程序，冷静有效地处理有人闯入的情况
所有组织都必须制定安全事件策略。它大大减少了“手忙脚乱”的响应阶段，因为人们在面对此类事件时往往会失去理智。入侵是重大而可怕的事件。遭受入侵的羞耻感可能会导致原本头脑清醒的系统管理员开始做出错误的反应。
组织的所有层级都需要了解这些政策。事件规模越大，高层管理人员介入的可能性就越大，而制定处理事件的程序将极大地有助于抵御来自高层的“帮助”。它还为直接参与事件响应的技术人员提供了一定程度的保障，即中层管理人员与组织其他部门进行交互的程序。
理想情况下，您的灾难恢复策略已经定义了在 DR 策略生效之前某些服务可能不可用的时间。这将有助于事件响应，因为这些类型的事件是灾难。如果事件属于无法满足恢复窗口的类型（例如：热备份 DR 站点实时接收更改的数据，入侵者在被发现之前删除了复制到 DR 站点的大量数据。因此，需要使用冷恢复程序），那么高层管理人员将需要参与风险评估会谈。
任何事件响应计划都包含以下组成部分：
- 识别受损系统和暴露数据。
- 尽早确定是否需要保留法律证据以供最终起诉。
- 如果需要保留证据除非绝对需要，否则不要触碰该系统的任何内容。不要登录。不要筛选日志文件。不要。触摸。
- 如果要保留证据，则需要保留受损的系统在线的但断开连接直到经过认证的计算机取证专家能够以符合证据处理规则的方式剖析系统。
- 关闭受感染的系统可能会污染数据。
- 如果您的存储系统允许这样做（离散 SAN 设备），请在断开连接之前对受影响的 LUN 进行快照并将其标记为只读。
- 证据处理规则很复杂，很容易搞砸。除非你接受过这方面的培训，否则不要这么做。大多数一般系统管理员都没有接受过这种培训。
- 如果证据被保留，则将服务损失视为硬件损失灾难并使用新硬件启动恢复程序。
- 预先设定了哪些灾害需要哪些通知的规则。法律和法规因地而异。
- 有关“曝光”和“已证明的妥协”的规则确实有所不同。
- 通知规则将要求通讯部门参与。
- 如果所需通知的内容足够多，则必须让高层管理人员参与其中。
- 使用 DR 数据，确定在使服务恢复在线成为更高优先级之前可以花费多少“刚刚发生了什么”的时间。
- 服务恢复时可能需要弄清楚到底发生了什么问题。如果是这样，则在服务恢复后拍摄受影响设备的驱动器映像以供解剖（这不是证据副本，而是供技术人员进行逆向工程）。
- 规划您的服务恢复任务，包括受影响系统的彻底重建，而不仅仅是清理混乱。
- 在某些情况下，服务恢复时间非常紧迫，以至于在发现发生入侵后需要立即获取磁盘映像，并且不能保留法律证据。一旦服务重建，就可以开始查明发生了什么。
- 仔细检查日志文件，了解攻击者如何进入以及进入后可能做了什么。
- 仔细检查更改的文件，以获取有关他们如何进入以及进入后做了什么的信息。
- 仔细检查防火墙日志，了解它们的来源、可能将数据发送到何处以及可能发送了多少数据。
制定政策和程序前妥协，并且为在妥协事件中实施妥协的人所熟知，这是需要做的事情。它在人们无法正常思考的时候为每个人提供了一个应对框架。高层管理人员可以对诉讼和刑事指控大发雷霆，但实际上将案件汇总起来是一项昂贵的过程并提前了解这一点可以帮助抑制愤怒。
我还注意到，这些事件确实需要纳入整体灾难响应计划。入侵很可能会触发“硬件丢失”响应策略，也可能触发“数据丢失”响应。了解服务恢复时间有助于设定预期，即安全响应团队在服务恢复之前可以花多长时间来检查实际被入侵的系统（如果不保留法律证据）。
答案2
适当的帮助台程序如何提供帮助
我们需要考虑如何在这里处理客户（这适用于联系帮助台的内部和外部客户）。
首先，沟通是重要的；用户会对业务中断感到愤怒，也可能担心入侵过程中可能出现的任何信息泄露的程度/后果。让这些人了解情况将有助于控制他们的愤怒和担忧，一方面从分享知识是好事的角度来看，另一方面从可能不太明显的角度来看，他们需要听到的一件事是你在掌控局面。
此时，帮助台和 IT 管理部门需要充当“保护伞”，保护从事这项工作的人员确定入侵的程度并恢复服务，使其免受无数扰乱工作的查询的影响。
- 尝试向客户发布切合实际的更新，并与他们一起确定恢复服务的紧迫性。了解客户需求很重要，但同时不要让他们向您规定不可行的时间表。
- 确保您的帮助台团队知道哪些信息可以发布，哪些信息不能发布，并且他们不应该鼓励谣言和猜测（绝对不应该讨论任何可能损害您的组织可能采取或面临的法律行动的事情）。
- 帮助台应该做的一件好事是记录所有与入侵有关的电话 - 这可以帮助衡量入侵本身以及随后处理入侵的流程所造成的破坏。将时间和财务成本计入入侵和缓解措施，对于完善未来战略非常有帮助，而且显然可能对任何法律行动都很有用。ITIL 事件与问题记录可以在这里提供帮助——入侵本身和缓解都可以记录为单独的问题，并且每个呼叫者都被跟踪为一个或两个问题的事件。
部署标准如何提供帮助
部署到一套模板（或至少是一份清单）也有帮助，同时对部署模板的任何自定义/升级进行变更控制/管理。您可以有多个模板来负责执行不同工作的服务器（例如邮件服务器模板、Web 服务器模板等）。
模板应该适用于操作系统和应用程序，不仅包括安全性，还包括全部您使用的设置，最好是脚本化（例如模板）而不是手动应用（例如清单），以尽可能消除人为错误。
这有多种帮助：
- 使您能够在发生入侵时更快地恢复/重建（请注意，您不应该从此模板“按原样”部署，因为你知道它很脆弱，但它可以让你恢复到“上次已知的正确配置”在实际部署之前需要进一步强化...并且，一旦您确定部署模板已正确锁定，也不要忘记更新它）
- 为您提供与被黑服务器进行比较的“基线”
- 减少可能导致入侵的不必要错误
- 有助于变更和补丁管理，因为当您显然需要补丁/升级或程序变更以确保安全（或任何其他原因）时，它可以更容易地查看哪些系统需要变更，更容易地编写测试来查看变更是否正确应用，等等。
- 如果一切都尽可能一致且合理，它有助于使不寻常和可疑的事件更加突出。
答案3
对于我们的大多数服务器，我们依靠主机和网络防火墙、防病毒/间谍软件、网络 IDS 和主机 IDS 进行大部分预防。此外，我们还遵循所有一般准则，例如最低权限、卸载非必要程序、更新等。然后，我们使用 Nagios、Cacti 和 SIEM 解决方案等产品进行各种基础检查和事件发生时的通知。我们的 HIDS（OSSEC）也进行了大量 SIEM 类型的日志记录，这很好。我们基本上会尽可能多地阻止某些事情，然后集中记录，这样如果确实发生了某些事情，我们就可以对其进行分析和关联。
答案4
正确的安全信息和事件管理（SIEM）政策的实施将大大简化您的安全生活。