黑客预防、取证、审计和反措施

Question

最近（但它也是一个反复出现的问题）我们看到了 3 个关于黑客和安全的有趣主题：

如何处理受感染的服务器？.
查找被黑服务器是如何被黑的
文件权限问题

最后一个没有直接关系，但它强调了搞乱 Web 服务器管理是多么容易。

由于有几件事情可以做，在不好的事情发生之前，我想就限制攻击的背面影响的良好实践以及如何在不幸的情况下做出反应方面提出您的建议。

这不仅仅是保护服务器和代码的问题，也是审计、日志记录和反措施的问题。

您是否有任何好的做法列表，或者您更喜欢依赖软件或专家来持续分析您的 Web 服务器（或根本不分析）？

如果是，你能分享你的清单和你的想法/意见吗？

更新

我收到了几个很好的和有趣的反馈。

我想要一个简单的列表，这样既可以方便 IT 安全管理员使用，也可以方便网络事实管理员。

即使每个人都给出了很好和正确的答案，但目前我更喜欢Robert的一个，因为它最简单、清晰和简洁，而sysadmin1138的一个最完整和精确。

但是没有人考虑用户的观点和感知，我认为这是首先必须考虑的。

用户在访问我被黑网站时会怎么想，如果您拥有有关他们的合理数据，则更多。这不仅仅是在何处存储数据的问题，而是如何安抚愤怒的用户的问题。

数据、媒体、权威和竞争对手呢？

Answer 1

有两个大的领域需要关注：

1. 让人进不去。
2. 制定政策和程序以冷静有效地处理某人超过第 1 点的事件。

让人进不去

这是一个非常复杂的主题，其中很多都集中在确保您有足够的信息来确定事件发生后发生的 WTF。为简单起见，抽象要点：

• 保留日志（另请参阅安全信息事件管理）
  • 任何授权尝试，无论成功与否，最好是源信息完整无缺。
  • 防火墙访问日志（这可能必须包括每个服务器的防火墙，如果正在使用）。
  • 网络服务器访问日志
  • 数据库服务器身份验证日志
  • 特定于应用程序的使用日志
  • 如果可能，SIEM 可以对可疑模式发出警报。
• 实施适当的访问控制
  • 确保在任何地方正确设置权限，并在可能的情况下避免“懒惰”（“哦，让每个人都阅读”）。
  • 定期审核 ACL 以确保实际遵循程序，并在故障排除完成后正确删除临时故障排除步骤（“让每个人都阅读，看看它是否有效”）。
  • 所有防火墙直通规则都需要进行论证，并定期进行审计。
  • 还需要审核 Web 服务器访问控制，包括 Web 服务器和文件系统 ACL。
• 实施变更管理
  • 安全环境的任何变化都需要由一个以上的人集中跟踪和审查。
  • 在这个过程中应该包括补丁。
  • 拥有通用操作系统构建（模板）将简化环境并使更改更易于跟踪和应用。
• 禁用访客帐户。
• 确保所有密码都没有设置为默认值。
  • 现成的应用程序可以使用预定义的密码设置用户。改变它们。
  • 许多 IT 设备都带有众所周知的用户/密码对。改变那些，即使你每年只登录一次那个东西。
• 实践最低权限。为用户提供他们实际需要的访问权限。
  • 对于管理员用户，两个帐户设置是明智的。一个用于电子邮件和其他办公任务的常规帐户，以及一个用于高级隐私工作的帐户。虚拟机使这更容易接受。
  • 不要鼓励经常使用通用管理员/root 帐户，很难跟踪谁在做什么。

制定政策和程序以冷静有效地处理有人进入的事件

安全事件策略是所有组织都必须具备的。它大大减少了“脑子被切断了”的反应阶段，因为人们在面对诸如此类的事件时往往会变得不理智。入侵是一件大而可怕的事情。因遭受入侵而感到羞耻可能会导致头脑清醒的系统管理员开始做出错误的反应。

组织的所有级别都需要了解这些政策。事件越大，上层管理人员就越有可能以某种方式介入，制定处理事情的程序将大大有助于抵御来自高层的“帮助”。它还为直接参与事件响应的技术人员提供了一定程度的保护，以中层管理人员与组织其余部分交互的程序的形式。

理想情况下，您的灾难恢复策略已经定义了在 DR 策略启动之前某些服务可能不可用的时间。这将有助于事件响应，因为这些类型的事件是灾难。如果事件属于无法满足恢复窗口的类型（例如：热备份 DR 站点获取更改数据的实时馈送，并且入侵者删除了一组在它们被复制到 DR 站点之前复制到 DR 站点的数据）注意到。因此，需要使用冷恢复程序）然后高层管理人员需要参与风险评估会谈。

任何事件响应计划的一些组成部分：

• 识别受感染的系统和暴露的数据。
• 尽早确定是否需要保留法律证据以备最终起诉。
  • 如果要保留证据，除非绝对需要，否则不要涉及该系统的任何内容。不要登录它。不要筛选日志文件。做。不是。触碰。
  • 如果要保留证据，受感染的系统需要保持在线但断开连接，直到经过认证的计算机取证专家能够以与证据处理规则兼容的方式剖析系统。
    • 关闭受感染系统的电源可能会污染数据。
    • 如果您的存储系统允许此（离散 SAN 设备）在断开连接之前对受影响的 LUN 进行快照并将其标记为只读。
  • 证据处理规则很复杂，而且很容易搞砸。除非您接受过有关它们的培训，否则不要这样做。大多数一般系统管理员没有接受过这种培训。
  • 如果保留证据，请将服务丢失视为硬件丢失灾难，并使用新硬件启动恢复程序。
• 什么样的灾难需要什么样的通知的预先设定的规则。法律法规因地区而异。
  • 有关“暴露”和“经证实的妥协”的规则确实有所不同。
  • 通知规则将要求通讯部门参与。
  • 如果要求的通知足够大，就必须涉及到高层管理人员。
• 使用 DR 数据，确定在让服务重新上线成为更高优先级之前可以花费多少“刚刚发生的 WTF”时间。
  • 服务恢复时间可能需要弄清楚发生了什么从属。如果是这样，则在服务恢复后拍摄受影响设备的驱动器映像以进行剖析（这不是证据副本，它是供技术人员进行逆向工程的）。
  • 计划您的服务恢复任务以包括对受影响系统的完全重建，而不仅仅是清理混乱。
  • 在某些情况下，服务恢复时间非常紧迫，需要在确定发生危害后立即获取磁盘映像，并且不保留法律证据。一旦服务被重建，搞清楚发生了什么的工作就可以开始了。
• 筛选日志文件以获取有关攻击者如何进入以及他们进入后可能做了什么的信息。
• 筛选更改后的文件，了解有关他们如何进入以及进入后做了什么的信息。
• 筛选防火墙日志以获取有关它们来自何处、它们可能将数据发送到何处以及可能已发送了多少数据的信息。

在妥协之前制定政策和程序，并为将在妥协的情况下实施这些政策和程序的人所熟知，这是只需要做的事情。它为每个人提供了一个在人们无法直视的时候的响应框架。高层管理人员可能会大肆宣传诉讼和刑事指控，但实际上将案件合并是一个昂贵的过程，并且事先知道这可以帮助平息愤怒。

我还注意到，这些类型的事件确实需要考虑到整体灾难响应计划中。妥协将很可能触发“丢失硬件”响应策略，也可能触发“数据丢失”响应。了解您的服务恢复时间有助于设定安全响应团队可以在服务恢复需要多长时间之前倾倒实际受损系统（如果不保留法律证据）。

Answer 2

正确的帮助台程序如何提供帮助

我们需要考虑如何处理客户（这适用于联系服务台的内部和外部客户）。

首先，沟通很重要；用户会对业务中断感到愤怒，并且还可能担心作为入侵的一部分而发生的任何信息泄露的程度/后果。让这些人了解情况将有助于控制他们的愤怒和担忧，无论是从分享知识的角度来看，还是从可能不太明显的角度来看，他们需要听到的一件事是你可以控制情况。

在这一点上，服务台和 IT 管理需要充当“保护伞”，为从事工作的人员提供庇护，以确定入侵的程度，并从无数扰乱该工作的查询中恢复服务。

1. 尝试向客户发布真实的更新，并与他们一起确定将服务重新上线的紧迫性。了解客户的需求很重要，但同时不要让他们向您规定不可行的时间表。
2. 确保您的服务台团队知道哪些信息可以发布，哪些不可以发布，并且他们不应该鼓励谣言和猜测（绝对不应该讨论任何可能损害您的组织可能采取或面临的任何法律行动的事情）。
3. 帮助台应该做的一件积极的事情是记录与入侵有关的所有呼叫 - 这可以帮助衡量由入侵本身和随后处理它的过程造成的中断。在入侵和缓解上投入时间和财务成本对于完善未来的策略非常有帮助，并且显然可能对任何法律行动都有用。ITIL 事件与问题记录在这里可以提供帮助 - 入侵本身和缓解措施都可以记录为单独的问题，并且每个调用者都可以作为一个或两个问题的事件进行跟踪。

部署标准如何提供帮助

部署到一组模板（或至少是清单）也有帮助，同时对部署模板的任何自定义/升级进行变更控制/管理。您可以使用多个模板来说明执行不同工作的服务器（例如邮件服务器模板、Web 服务器模板等）。

模板应该适用于操作系统和应用程序，不仅包括安全性，还包括您使用的所有设置，并且理想情况下应该编写脚本（例如模板）而不是手动应用（例如清单）以尽可能消除人为错误。

这在很多方面都有帮助：

• 使您能够在确实发生入侵的情况下更快地恢复/重建（请注意，您不应“按原样”从该模板进行部署，因为您知道它易受攻击，但它可以让您回到“上次已知的良好配置” “这需要在实时部署之前进行进一步的强化......一旦你确定它被正确锁定，不要忘记更新你的部署模板，要么）
• 给你一个“基线”来比较被黑的服务器
• 首先减少可能导致入侵的不必要的错误
• 有助于更改和补丁管理，因为当您明显需要补丁/升级或安全程序更改（或任何其他原因）时，它可以更轻松地查看哪些系统需要更改，更易于编写测试查看更改是否正确应用等）。
• 如果一切都尽可能一致和合理，它有助于使异常和可疑事件进一步突出。