在 Root 妥协后重新安装？

Question

在 Root 妥协后重新安装？

Zor*_*che 59 security hacking

在阅读有关服务器入侵的这个问题后，我开始想知道为什么人们似乎仍然相信他们可以使用检测/清理工具或仅通过修复用于入侵系统的漏洞来恢复受损系统。

考虑到所有各种 root kit 技术和黑客可以做的其他事情，大多数专家建议您应该重新安装操作系统。

我希望能更好地了解为什么更多的人不只是从轨道上起飞并摧毁该系统。

这里有几点，我希望看到解决。

是否存在格式化/重新安装无法清理系统的情况？
您认为在什么类型的条件下可以清理系统，何时必须进行完全重新安装？
你有什么理由反对完全重新安装？
如果您选择不重新安装，那么您使用什么方法来合理地确信您已经清洁并防止再次发生任何进一步的损坏。

Answer 1

K. *_*ley 31

安全决策最终是关于风险的业务决策，就像关于将什么产品推向市场的决策一样。当您在这种情况下构建它时，不调平和重新安装的决定是有道理的。当您从技术角度严格考虑它时，事实并非如此。

以下是该业务决策的典型内容：

我们的停机时间将给我们带来多少可衡量的成本？
当我们不得不向客户透露我们失败的原因时，我们可能会付出多少代价？
为了重新安装，我还需要做哪些其他活动？费用是多少？
我们是否有合适的人知道如何无误地启动系统？如果没有，当他们解决错误时，我会付出什么代价？

因此，当您将这些成本加起来时，可能会认为继续使用“可能”仍然受到损害的系统比重新安装系统要好。

我想了一会儿，但想不出为什么部署一个可能会受到损害的系统更有意义的原因。 (2认同)

Answer 2

Rob*_*oir 31

基于我多年前写的一篇文章，当时我仍然可以打扰写博客。

黑客入侵他们的网络服务器的受害者不断地问这个问题。答案很少改变，但人们一直在问这个问题。我不知道为什么。也许人们只是不喜欢他们在寻求帮助时看到的答案，或者他们找不到他们信任的人来给他们建议。或者，也许人们阅读了这个问题的答案，并过多地关注了为什么他们的案例很特别并且与他们在网上找到的答案不同的 5% 并且错过了他们的案例足够接近的问题和答案的 95%正如他们在网上阅读的那样。

这让我想到了第一个重要的信息块。我真的很感激你是一片特别独特的雪花。我也很欣赏您的网站，因为它反映了您和您的企业，或者至少反映了您代表雇主的辛勤工作。但是对于外部的人来说，无论是计算机安全人员查看问题以尝试帮助您还是攻击者本人，您的问题很可能与他们遇到的所有其他情况至少有 95% 相同曾经看过。

不要把攻击个人化，也不要把这里遵循的建议或你从其他人那里得到的建议当作个人。如果您在成为网站黑客的受害者之后才阅读本文，那么我真的很抱歉，我真的希望您能在这里找到一些有用的东西，但这不是让您的自我妨碍您需要做的事情的时候做。

您刚刚发现您的服务器被黑了。怎么办？

不要恐慌。绝对不要仓促行事，也绝对不要试图假装事情从未发生过，根本不采取行动。

第一：明白灾难已经发生。现在不是否认的时候；现在是接受已经发生的事情、现实地看待它并采取措施管理影响后果的时候了。

其中一些步骤会受到伤害，并且（除非您的网站包含我的详细信息的副本）我真的不在乎您是否忽略所有或部分这些步骤，但这样做最终会使事情变得更好。该药的味道可能很糟糕，但有时如果您真的希望治疗有效，您就必须忽略这一点。

阻止问题变得比现在更糟：

您应该做的第一件事是断开受影响的系统与 Internet 的连接。无论您遇到什么其他问题，让系统连接到网络只会让攻击继续进行。我的意思是字面意思；如果需要的话，请某人亲自访问服务器并拔下网络电缆，但在尝试执行其他任何操作之前，请先断开受害者与其劫匪的连接。
更改与受感染系统位于同一网络的所有计算机上所有帐户的所有密码。不完全是。所有账户。所有电脑。是的，你是对的，这可能有点矫枉过正；另一方面，它可能不会。两种方式你都不知道，是吗？
检查您的其他系统。特别注意其他面向 Internet 的服务，以及那些持有金融或其他商业敏感数据的服务。
如果系统保存了任何人的个人数据，请立即向可能受到影响的任何人全面而坦率地披露。我知道这个很难。我知道这个会很痛。我知道很多企业都想把这类问题抛在脑后，但恐怕你只需要处理它。

还在犹豫要不要迈出这最后一步？我明白，我明白。但是这样看：

在某些地方，您可能有法律要求通知当局和/或此类隐私泄露的受害者。不管你的客户让你告诉他们一个问题有多恼火，如果你不告诉他们，他们会更加恼火，而且只有在有人使用他们的信用卡详细信息收取价值 8,000 美元的商品后，他们才会发现自己从您的网站窃取。

还记得我之前说过的话吗？坏事已经发生了。现在唯一的问题是你如何处理它。

完全理解问题：

在这个阶段完全完成之前，不要让受影响的系统重新上线，除非你想成为那个帖子是我真正决定写这篇文章的引爆点的人。我没有链接到帖子，以便人们可以得到廉价的笑声；我正在链接以警告您未能遵循第一步的后果。
检查“受攻击”系统以了解攻击如何成功危及您的安全。尽一切努力找出攻击“来自哪里”，以便您了解您遇到的问题以及需要解决的问题，以确保您的系统在未来安全。
再次检查“被攻击”的系统，这一次是为了了解攻击的去向，以便您了解哪些系统在攻击中遭到破坏。确保您跟进任何表明受感染系统可能成为进一步攻击您的系统的跳板的指示。
确保完全理解任何和所有攻击中使用的“网关”，以便您可以开始正确关闭它们。（例如，如果您的系统受到 SQL 注入攻击的危害，那么您不仅需要关闭它们侵入的特定有缺陷的代码行，还需要审核所有代码以查看是否存在相同类型的错误在别处制造的）。
了解攻击可能因不止一个缺陷而成功。通常，攻击的成功不是通过发现系统中的一个主要错误，而是通过将几个问题（有时本身是次要的和微不足道的）串在一起来破坏系统。例如，使用 SQL 注入攻击向数据库服务器发送命令，发现您正在攻击的网站/应用程序在管理用户的上下文中运行，并使用该帐户的权限作为踏脚石来破坏其他部分一个系统。或者正如黑客喜欢称之为：“在办公室利用人们犯的常见错误的另一天”。

制定恢复计划并使您的网站重新上线并坚持下去：

没有人愿意长时间离线。那是给定的。如果该网站是一种创收机制，那么将其快速恢复上线的压力将是巨大的。即使唯一受到威胁的是您/您公司的声誉，这仍然会产生很大的压力，需要迅速恢复原状。

但是，不要屈服于过快重新上线的诱惑。相反，尽快了解导致问题的原因并在您重新上线之前解决它，否则您几乎肯定会再次成为入侵的受害者，并记住，“被黑客攻击一次可以归类为不幸；之后再次被黑客攻击看起来很粗心”（向奥斯卡王尔德道歉）。

我假设您在开始本节之前已经了解了导致成功入侵的所有问题。我不想夸大这个案子，但如果你还没有先这样做，那么你确实需要这样做。对不起。
永远不要支付勒索/保护费。这是一个简单标记的标志，你不希望这个短语曾经用来描述你。
不要试图在没有完全重建的情况下将相同的服务器重新联机。在旧硬件上构建新盒子或“从轨道上核对服务器并进行全新安装”应该比审核旧系统的每个角落以确保它在放回之前是干净的要快得多又上线了。如果您不同意这一点，那么您可能不知道确保系统完全清理的真正含义是什么，或者您的网站部署程序是一团糟。您大概有站点的备份和测试部署，可以用来构建实时站点，如果没有，那么被黑客攻击不是您最大的问题。
重新使用黑客攻击时系统上“实时”的数据时要非常小心。我不会说“永远不要这样做”，因为你会无视我，但坦率地说，我认为当你知道你不能保证数据的完整性时，你确实需要考虑保留数据的后果。理想情况下，您应该从入侵之前的备份中恢复它。如果你不能或不会这样做，你应该非常小心这些数据，因为它被污染了。如果这些数据属于客户或网站访问者而不是直接属于您，您应该特别注意对他人的后果。
仔细监控系统。您应该决心在未来将其作为一个持续的过程来执行（更多内容见下文），但在您的网站重新上线后的这段时间里，您会格外小心地保持警惕。入侵者几乎肯定会回来，如果你能发现他们试图再次闯入，你肯定能够很快看到你是否真的关闭了他们之前使用的所有漏洞以及他们为自己制造的任何漏洞，并且你可能会收集到有用的信息您可以传递给当地执法部门的信息。

减少未来的风险。

您需要了解的第一件事是，安全性是您必须在设计、部署和维护面向 Internet 的系统的整个生命周期中应用的过程，而不是您可以像廉价一样在代码上打几层的东西画。为了确保安全，服务和应用程序的设计需要从一开始就将此作为项目的主要目标之一。我意识到这很无聊，而且您之前已经听过这一切，而且我“只是没有意识到让您的测试版 web2.0（测试版）服务在网络上进入测试版状态的压力人”，但事实是这一直保持被重复是因为它第一次说的时候是真的，而且还没有变成谎言。

你无法消除风险。你甚至不应该尝试这样做。但是，您应该做的是了解哪些安全风险对您很重要，并了解如何管理和减少风险的影响以及风险发生的可能性。

您可以采取哪些步骤来降低攻击成功的可能性？

例如：

允许人们闯入您网站的缺陷是否是供应商代码中的已知错误，有补丁可用？如果是这样，您是否需要重新考虑在面向 Internet 的服务器上修补应用程序的方法？
允许人们闯入您网站的缺陷是否是供应商代码中的未知错误，没有补丁可用？我当然不提倡在这样的事情困扰你时更换供应商，因为他们都有自己的问题，如果你采用这种方法，你最多会在一年内耗尽平台。但是，如果系统不断让您失望，那么您应该迁移到更强大的系统，或者至少重新构建您的系统，以便将易受攻击的组件包裹在棉绒中，并尽可能远离敌意。
该缺陷是您（或为您工作的承包商）开发的代码中的错误吗？如果是这样，您是否需要重新考虑如何批准将代码部署到实时站点的方法？是否可以通过改进的测试系统或更改您的编码“标准”来捕获该错误（例如，虽然技术不是万能药，但您可以通过使用有据可查的编码技术来降低成功 SQL 注入攻击的可能性）。
该缺陷是由于服务器或应用程序软件的部署方式存在问题造成的吗？如果是这样，您是否在可能的情况下使用自动化程序来构建和部署服务器？这些对于在所有服务器上保持一致的“基线”状态有很大帮助，最大限度地减少必须在每个服务器上完成的自定义工作量，从而有望最大限度地减少出错的机会。代码部署也是如此——如果你需要做一些“特殊”的事情来部署最新版本的 Web 应用程序，那么努力让它自动化并确保它始终以一致的方式完成。
通过更好地监控您的系统，是否可以更早地发现入侵？当然，为您的员工提供 24 小时监控或“随叫随到”系统可能不符合成本效益，但有些公司可以为您监控面向网络的服务，并在出现问题时提醒您。您可能会决定您负担不起或不需要它，这很好……考虑一下。
在适当的情况下使用tripwire和nessus等工具 - 但不要因为我说过就盲目使用它们。花时间学习如何使用一些适合您的环境的优秀安全工具，更新这些工具并定期使用它们。
考虑聘请安全专家定期“审核”您的网站安全。同样，您可能会决定您负担不起或不需要它，这很好……只是考虑一下。

您可以采取哪些步骤来减少成功攻击的后果？

如果您认为您家下层被淹的“风险”很高，但不足以保证搬家，您至少应该将不可替代的传家宝搬上楼。对？

你能减少直接暴露在互联网上的服务数量吗？您能否在内部服务和面向 Internet 的服务之间保持某种差距？这确保即使您的外部系统受到损害，将其用作攻击内部系统的跳板的机会也是有限的。
您是否正在存储不需要存储的信息？当这些信息可以在其他地方存档时，您是否“在线”存储此类信息。这部分有两点；显而易见的一点是人们不能从你那里窃取你没有的信息，第二点是你存储的信息越少，你需要维护和编码的就越少，因此错误进入的机会就越少您的代码或系统设计。
您是否在为您的 Web 应用程序使用“最少访问”原则？如果用户只需要从数据库中读取，那么请确保 Web 应用程序用于为其提供服务的帐户只有读取访问权限，不允许其写入访问权限，当然也不允许系统级访问权限。
如果您在某件事上不是很有经验，并且它对您的业务并不重要，请考虑将其外包。换句话说，如果您运行一个讨论编写桌面应用程序代码的小型网站，并决定开始从该站点销售小型桌面应用程序，那么请考虑将您的信用卡订单系统“外包”给像 Paypal 这样的人。
如果可能，将练习从受损系统恢复作为灾难恢复计划的一部分。这可以说只是你可能遇到的另一种“灾难场景”，只是一个有自己的一系列问题和问题，这些问题和通常的“服务器机房着火”/“被巨型服务器吃掉毛茸茸的东西入侵”之类的事情不同。（编辑，根据 XTZ）

......最后

我可能没有遗漏其他人认为重要的东西，但是如果您不幸成为黑客的受害者，上面的步骤至少应该可以帮助您开始整理事情。

最重要的是：不要惊慌。三思而后行。一旦你做出决定，就坚定地采取行动，如果你有什么要添加到我的步骤列表中，请在下面发表评论。