题 黑客预防,取证,审计和对策


最近(但这也是一个反复出现的问题)我们看到了3个关于黑客和安全的有趣线索:

我如何处理受感染的服务器?
查找被黑客入侵的服务器是如何被黑客攻击的
文件权限问题 

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

因为有几件事情可以做, 之前 发生了一些不好的事情,我想就良好做法提出建议,以限制攻击的背后效果,以及如何在悲伤的情况下作出反应。

这不仅仅是保护服务器和代码的问题,还包括审计,记录和对策措施。

您是否有任何良好实践列表,或者您更愿意依赖软件或不断分析您的Web服务器的专家(或根本没有)?

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

UPDATE

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

我想有一个简单的列表,这对IT安全管理员和Web都很方便 FACTOTUM 主人。

即使每个人都给出了正确的答案,但此刻我更喜欢这个答案 罗伯特 因为它是最简单,最简洁,最简洁的 sysadmin1138 因为它是最完整和最精确的。

但没有人会考虑用户的观点和看法,我认为这是第一个必须考虑的问题。

如果您拥有关于它们的合理数据,用户在访问我的黑客网站时会想到什么。这不只是存储数据的位置问题,而是如何平息愤怒的用户。

数据,媒体,权威和竞争对手呢?


11
2018-01-03 14:46




从...开始 security.stackexchange.com 。虽然这里有一些好的答案...... - AviD
好点子!我不知道有一个,我认为完整列表是在每个堆栈网站的页脚。 - tmow
我认为测试网站不会出现在成熟的网站上。而且,完整的网站也不是beta版的页脚:) - AviD


答案:


有两个重点领域:

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

让它很难进入

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

  • 保留日志(另请参阅安全信息事件管理)
    • 任何授权尝试,无论是成功还是失败,最好是源信息完好无损。
    • 防火墙访问日志(如果使用,可能必须包括每服务器防火墙)。
    • Web服务器访问日志
    • 数据库服务器验证日志
    • 特定于应用程序的使用日志
    • 如果可能,SIEM可以针对可疑模式发出警报。
  • 实施适当的访问控制
    • 确保在任何地方正确设置权利,并尽可能避免“懒惰权利”(“哦,只是让每个人都阅读”)。
    • 定期审核ACL以确保实际遵循程序,并在故障排除完成后正确删除临时故障排除步骤(“让每个人都阅读,看看它是否正常”)。
    • 所有防火墙传递规则都需要合理,并定期进行审核。
    • 还需要审核Web服务器访问控制,包括Web服务器和文件系统ACL。
  • 实施变革管理
    • 安全环境的任何更改都需要由多个人集中跟踪和审核。
    • 补丁应包含在此过程中。
    • 拥有通用的OS构建(模板)将简化环境并使更改更容易跟踪和应用。
  • 禁用访客帐户。
  • 确保所有密码均未设置为默认值。
    • 现成的应用程序可以使用预定义的密码设置用户。改变它们。
    • 许多IT设备都附带了众所周知的用户/密码对。改变这些,即使你每年只登录一次这件事。
  • 练习最小特权。为用户提供他们实际需要的访问权限
    • 对于管理员用户,明智的是两个帐户设置。一个常规帐户用于电子邮件和其他办公任务,另一个用于提升私有工作。虚拟机使这更容易使用。
    • 不要鼓励经常使用通用管理员/ root帐户,很难跟踪谁在做什么。

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

安全事件策略是所有组织必须具备的。它大大减少了“随着我们的头部切断”的响应阶段,因为人们在面对诸如此类事件时往往会变得不合理。入侵是一件大而可怕的事情。遭受入侵的耻辱可能导致其他高级别的系统管理员开始不正确地做出反应。

组织的所有级别都需要了解策略。事件越大,上层管理人员就越有可能以某种方式参与其中,而设定处理事务的程序将大大有助于抵御高层的“帮助”。它还为直接参与事件响应的技术人员提供了一定程度的保障,其形式是中层管理人员与组织其他部门联系的程序。

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

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

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

制定政策和程序 之前 妥协,并且在妥协的情况下将实施它们的人所熟知,这是需要做的事情。在人们不会直接思考的时候,它为每个人提供了一个响应框架。高层管理人员可以对诉讼和刑事指控进行抨击和轰炸,但实际上将案件结合起来就是一个问题 昂贵 过程并知道事先可以帮助抑制愤怒。

我还注意到,这些事件确实需要考虑到整个灾害响应计划中。折衷方案很可能会触发“丢失硬件”响应策略,并可能触发“数据丢失”响应。了解您的服务恢复时间有助于设定安全响应团队在服务恢复中需要多长时间来倾倒实际受感染系统(如果没有保留法律证据)的预期。


11
2018-01-03 18:59



我选择了你的答案,因为它是最完整的,这就是公司,比如我们工作的公司,他们使用并不断改进,但我想知道如何简化普通网站管理员,必须尽快找到解决方案,更多没有巨额资金。 - tmow
你和罗伯特之间的回答仍然不确定。 - tmow
这是一个很好的答案,希望我能+2而不是+1 - Rob Moir


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

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

首先,沟通是 重要;用户会对业务中断感到愤怒,也可能会担心可能发生的任何信息泄露的程度/后果是入侵的一部分。让这些人了解情况将有助于管理他们的愤怒和关注,无论是从分享知识是否良好的角度,以及从可能稍微不那么明显的观点来看,他们需要听到的一件事是你控制了情况。

此时,服务台和IT管理部门需要充当“保护伞”,庇护执行工作的人员,以确定入侵和恢复服务的程度,从无数的查询中破坏这项工作。

  1. 尝试向客户发布实际更新,并与他们合作以确定将服务重新联机的紧迫性。了解客户需求很重要,但在 同时不允许他们为你指定一个不可行的时间表。
  2. 确保您的服务台团队知道哪些信息可以发布和不发布,并且他们不应该鼓励谣言和推测(绝对不应该讨论任何可能损害您的组织可能采取或面临的任何法律行动的事情)。
  3. 帮助台应该做的一件好事是记录与入侵有关的所有呼叫 - 这可以帮助衡量入侵本身和处理它的过程所造成的中断。在入侵和缓解方面投入时间和财务成本对于完善未来战略非常有帮助,并且显然可能对任何法律行动都有用。 ITIL事件与问题记录 在这里可以提供帮助 - 入侵本身和缓解都可以记录为单独的问题,并且每个呼叫者都被视为一个或两个问题的事件。

部署标准如何提供帮助

部署到设置模板(或至少是清单)也有助于实施对部署模板的任何自定义/升级的更改控制/管理。您可以使用多个模板来考虑执行不同作业的服务器(例如,邮件服务器模板,Web服务器模板等)。

模板应该适用于操作系统和应用程序,不仅包括安全性,还包括安全性 所有 您使用的设置,理想情况下应该是脚本(例如模板),而不是手动应用(例如检查表)以尽可能消除人为错误。

这有助于多种方式:

  • 使您能够在发生入侵的情况下更快地恢复/重建(请注意您 不应该 从这个模板“按原样”部署,因为你 知道 它很脆弱,但它可以让你回到“最后一次正确的配置” 在实际部署之前需要进一步强化...一旦确定已正确锁定部署模板,请不要忘记更新部署模板
  • 为您提供一个“基线”来比较被黑客入侵的服务器
  • 减少可能导致入侵的不必要的错误
  • 帮助进行更改和补丁管理,因为当您显然需要修补程序/升级或程序更改以确保安全性(或任何其他原因)时,可以更轻松地查看需要更改的系统,从而更轻松地编写测试查看更改是否正确应用等)。
  • 如果一切尽可能保持一致并且明智,那么有助于使不寻常和可疑的事件更加突出。

7
2018-01-03 16:09



+1。是的,这是正确的,但是,如果一切都发生,这意味着您的模板不像您想象的那样安全,因此您无法使用它来部署新网站。您至少需要一个维护页面,通知客户有关临时问题的信息,并最好将其托管在其他地方(另一台服务器,另一台IP和旧版本的重定向)。我认为我们应该始终考虑最坏的情况。 - tmow
@tmow - 你是对的,但模板允许你快速将系统恢复到“已知”配置,然后在再次部署服务器之前需要修改它。我会修改答案,以反映因为它应该提到它,你绝对是在那里。 - Rob Moir
谢谢。不要忘记用户的观点和感知。 - tmow
@tmow添加了一些关于用户的信息,并让支持服务台帮助解决这些问题。 - Rob Moir


对于我们的大多数服务器,我们依靠主机和网络防火墙,防病毒/间谍软件,网络IDS和主机IDS来实现我们的大部分预防。这与所有一般指导原则相关,例如最低权限,未安装的非必要程序,更新等。从那里我们使用Nagios,Cacti和SIEM解决方案等产品,用于各种基础内容和事件发生时的通知。我们的HIDS(OSSEC)也做了很多SIEM类型的日志记录,这很好。我们基本上尽可能地尝试阻止东西,但是然后集中记录,所以如果确实发生了什么,我们可以分析并关联它。


4
2018-01-03 16:55



一切都正确,我认为不需要更多,但同样,当它发生时,因为它发生了,你到底做了什么,你需要快速做出什么反应?分析数千行日志,在压力情况下更多,不会提供快速解决方法或临时解决方案,至少通知用户。 - tmow
当确实发生了某些事情时,那就是您需要适当的程序以及经过培训并知道该怎么做的事件响应团队。我知道分析数千行日志是一项艰巨的任务,但通过培训和正确的工具,您可以将其缩小到相当多的范围。它最终仍然很糟糕,但可能是唯一的解决方案。您还需要确保您对管理层有很好的理解,以及如何控制任何事件公告。此外,如果系统完全无法恢复,良好的备份程序可以最大限度地缩短您的停机时间。
我习惯每天研磨数十亿行日志,而我所知道的是,在了解发生了什么之前,修复或解决方法更为重要,甚至可以是只有静态页面的临时服务器向用户解释等等,等等......,等等。这是第一步,然后您考虑什么以及何时可以重新建立服务(或部分服务),最后您调查并实施任何对策。 - tmow


你真正想要的可以归结为3个基本领域:

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

如果您有任何信息(保证|安全)人员,那么您一定要与他们交谈。虽然事件响应通常是该办公室的唯一权限,但其余部分应该是所有受影响方的共同开发工作。

冒着自我拉皮条的风险,这个相关问题的答案应该为你索引很多有用的资源: 保护LAMP服务器的提示。

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

你绝对应该进行某种定期的日志审查。鉴于SIEM可以选择 非常 有帮助,但他们也有购买价格和建筑成本昂贵的缺点。从IT安全SE站点查看此问题,以获取有关日志分析的一些注释: 你如何处理日志分析?  如果这仍然太重,那么像LogWatch这样的常用工具可以为正在发生的事情提供一些良好的背景信息。但重要的是,只是花时间看日志。这将帮助您了解正常行为的构成,以便您可以识别异常。

除了日志审查之外,监视服务器的状态也很重要。知道何时发生变化,无论是否有计划,都是至关重要的。利用本地监控工具,如  可以提醒管理员更改。不幸的是,很像SIEM和IDS有调整和/或购买昂贵的缺点。此外,如果没有良好的调整,您的警报阈值将会非常高,以至于任何好消息都会在噪音中丢失并变得无用。


4
2018-01-03 17:08



我几乎同意所有事情,但这主要适用于大中型公司。小型公司不需要或不需要如此昂贵的结构。 - tmow


正确的 安全信息和事件管理 (SIEM)的政策将大大有助于您的安全生活更轻松。


3
2018-01-03 15:43



这就是我想在这里讨论的内容:-) - tmow


我不是安全专家,所以我主要是顺从他们;但从开始 最低权限原则 几乎总能让他们的工作变得更加轻松将其应用于治疗药膏非常适用于安全性的许多方面:文件权限,运行时用户,防火墙规则等。  永远不会伤害。


2
2018-01-03 15:29





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

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


2
2018-01-08 20:39