最近（但这也是一个经常性的问题），我们看到了有关黑客和安全性的3个有趣的线索：

如何处理受到感染的服务器？。
查找被黑服务器被黑的方式
文件权限问题

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

由于可以做的事情很多，因此在不良事件发生之前，我想就如何限制攻击的负面影响以及如何在可悲的情况下做出反应的良好做法向您提出建议。

这不仅是保护服务器和代码安全的问题，而且还涉及审计，日志记录和对策。

您是否有任何良好做法清单，还是希望依靠持续分析Web服务器的软件或专家（或根本不分析）？

如果是，可以分享您的清单和想法/意见吗？

更新

我收到了一些很好的有趣的反馈。

我希望有一个简单的列表，以便IT安全管理员可以方便地使用，也可以使用Web Factotum管理员。

即使每个人都给出了正确正确的答案，此刻，我还是更喜欢Robert，因为它是最简单，清晰和简洁的；而我更喜欢sysadmin1138，因为它是最完整，最精确的。

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

用户将在什么时候访问我的被黑网站时会想到什么，如果您拥有关于它们的敏感数据，则更重要。这不仅关系到在何处存储数据，还关系到如何使生气的用户平静下来。

数据，媒体，权威机构和竞争对手呢？

有两个主要领域需要关注：

1. 很难进入。
2. 制定政策和程序以冷静有效地处理某人进入第1点的事件。

很难进入

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

• 保留日志（另请参阅安全信息事件管理）
  • 任何授权尝试（无论成功还是失败）都最好保持源信息完整。
  • 防火墙访问日志（如果正在使用，则可能必须包括每服务器防火墙）。
  • Web服务器访问日志
  • 数据库服务器身份验证日志
  • 特定于应用程序的使用日志
  • 如果可能，SIEM可以针对可疑模式发出警报。
• 实施适当的访问控制
  • 确保在所有地方正确设置权利，并在可能的情况下避免使用“懒惰的权利”（“哦，让所有人阅读”）。
  • 对ACL进行定期审核，以确保确实遵循了步骤，并且在完成故障排除后已正确删除了临时的故障排除步骤（“让所有人阅读，然后看看它是否可以工作”）。
  • 所有防火墙通过规则都必须得到证明，并定期进行审核。
  • Web服务器访问控制（包括Web服务器ACL和文件系统ACL）也需要进行审核。
• 实施变更管理
  • 安全环境的任何更改都需要由多个人进行集中跟踪和审查。
  • 修补程序应包括在此过程中。
  • 具有通用的操作系统构建（模板）将简化环境，并使更改更易于跟踪和应用。
• 禁用访客帐户。
• 确保未将所有密码设置为默认密码。
  • 现成的应用程序可以为用户设置预定义的密码。改变他们。
  • 许多IT设备附带了众所周知的用户/密码对。即使您每年仅登录一次，也要更改这些设置。
• 练习最小特权。为用户提供他们实际需要的访问权限。
  • 对于管理员用户，明智的做法是使用两个帐户。一个普通帐户用于电子邮件和其他办公室任务，另一个用于高级保密工作。VM使它更易于使用。
  • 不要鼓励定期使用通用管理员/根帐户，这很难跟踪谁在什么时候做什么。

制定政策和程序以从容有效地处理某人进入的事件

所有组织都必须拥有安全事件策略。由于人们在遇到诸如此类的事件时往往会变得不理智，因此它大大减少了“断头转转”响应的阶段。入侵是件令人恐惧的大事。遭受入侵而感到羞耻会导致否则为首的系统管理员开始错误地做出反应。

组织的各个级别都需要了解这些策略。事件越严重，高层管理人员就越有可能参与其中，设置处理程序的程序将极大地帮助抵御高层的“帮助”。它还以中间管理人员与组织的其余部分进行交互的过程的形式，为直接参与事件响应的技术人员提供了一定程度的保障。

理想情况下，灾难恢复策略已经定义了某些策略在实施灾难恢复策略之前可能不可用的时间。这将有助于事件响应，因为此类事件是灾难。如果该事件属于无法满足恢复窗口的类型（例如：热备份DR站点获得更改数据的实时提要，并且入侵者删除了复制到DR站点之前的大量数据，因此，将需要使用冷恢复程序），然后高层管理人员将需要参与风险评估讨论。

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

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

仅需要做的就是在妥协之前制定政策和程序，并在发生妥协后被实施的人们所熟知。在人们不会直截了当的时候，它为每个人提供了一个响应框架。高级管理人员可能会因诉讼和刑事指控而大放异彩，但实际上将案件合并在一起是一个昂贵的过程，并且知道事前可以帮助减轻愤怒。

我还注意到，确实需要将此类事件纳入整体灾难响应计划中。妥协很可能触发“硬件丢失”响应策略，也可能触发“数据丢失”响应。知道您的服务恢复时间有助于确定安全响应团队在服务恢复之前需要注入实际受损系统的时间（如果没有保留法律证据）。

适当的服务台程序如何提供帮助

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

首先，沟通很重要；用户将对业务中断感到生气，并且还可能担心作为入侵的一部分而发生的任何信息泄露的程度/后果。从共享知识的观点出发，以及从可能稍微不那么明显的观点来看，使这些人保持知情将有助于管理他们的愤怒和担忧，他们需要听的一件事就是您控制了情况。

此时，服务台和IT管理人员需要充当“伞”，以避开从事工作的人员来确定入侵的范围，并从无数中断该工作的查询中恢复服务。

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

部署标准如何提供帮助

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

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

这在许多方面有帮助：

• 使您能够在确实发生入侵的情况下更快地还原/重建（请注意，您不应从此模板“按原样”进行部署，因为您知道它很容易受到攻击，但是可以让您回到“最近的正确配置” “ ，这需要在实时部署之前进行进一步的强化 ……并且，一旦确定其已正确锁定，也不要忘记更新您的部署模板）
• 为您提供“基准”，以将被入侵的服务器与
• 减少不必要的错误，这些错误可能首先导致入侵
• 帮助进行更改和补丁管理，因为当出于安全性目的而明显需要补丁/升级或程序更改时（或其他任何原因），它使查看哪些系统需要更改变得更加容易，使编写测试变得更加容易查看更改是否正确应用等）。
• 如果一切都尽可能一致和合理，它将有助于使异常和可疑事件进一步突出。

对于我们的大多数服务器，在大多数情况下，我们都依赖主机和网络防火墙，防病毒/间谍软件，网络IDS和主机IDS。这与所有一般准则（例如最低特权，已卸载的非必要程序，更新等）一起使用。从那里开始，我们使用Nagios，Cacti等产品和SIEM解决方案来处理各种事件，并提供事件发生时的通知。我们的HIDS（OSSEC）也执行许多SIEM类型日志记录，这很好。我们基本上会尝试尽可能多地阻止内容，但随后集中记录，以便在发生某些事情时我们可以对其进行分析和关联。

您真正想要的东西可以分为3个基本领域：

1. 标准系统配置
2. 系统/应用监控
3. 事件响应

如果您有任何可用的信息（保证|安全）人员，那么您绝对应该与他们联系。尽管事件响应通常是该办公室的唯一权限，但其余的工作应该是所有受影响各方的共同开发工作。

冒着自拔的风险，这个相关问题的答案应为您索引许多有用的资源：保护LAMP服务器的提示。

理想情况下，您应拥有最少数量的受支持操作系统，并使用基本映像构建每个操作系统。您仅应根据提供服务器提供的任何服务所需的数量偏离基本数量。偏差应记录在案，或者如果必须满足PCI / HIPAA / etc则可能需要。或其他合规性。使用部署和配置管理系统可以在这方面提供很多帮助。具体细节在很大程度上取决于您的操作系统，补鞋匠/人偶/ Altiris / DeployStudio / SCCM等。

您绝对应该执行某种常规的日志检查。如果选择该选项，SIEM可能会非常有帮助，但缺点是购买价格和扩建成本都很高。请从IT Security SE网站上查看此问题，以获取有关日志分析的一些评论：您如何处理日志分析？ 如果这仍然太繁琐，那么即使是LogWatch之类的常用工具也可以为发生的事情提供一些良好的上下文。但是，重要的一点是花时间完全查看日志。这将帮助您熟悉什么是正常行为，以便您识别异常。

除了日志查看之外，监视服务器状态也很重要。了解何时发生变更（无论是否计划）至关重要。使用本地监控工具（例如Tripwire）可以提醒管理员更改。不幸的是，就像SIEM和IDS一样，其缺点是调整和/或购买的价格昂贵。而且，如果没有良好的调整，您的警报阈值将很高，以至于任何好的消息都将在噪音中丢失并且变得毫无用处。

适当的安全信息和事件管理（SIEM）策略将大大有助于简化安全性生活。

我不是安全专家，所以我主要遵从他们。但是从最低特权负责人开始，几乎总是使他们的工作变得容易得多。文件权限，运行时用户，防火墙规则等：应用此像治疗药膏安全的许多方面效果很好KISS从来没有伤害任何。

这里提到的大多数解决方案都适用于主机和网络级别，但是我们经常忘记不安全的Web应用程序。Web应用程序是最常被忽视的安全漏洞。通过Web应用程序，攻击者可以访问您的数据库或主机。没有防火墙，IDS，防火墙可以保护您免受这些威胁。OWASP维护了十大最关键的漏洞列表，并为它们提供了修复程序。

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide