Pentesting 不是一种一刀切的评估类型。适用于一个五旬节的内容可能与另一个不同。保持对潮流和技能的掌握是很重要的，并且要理解这对 pentest 意味着什么。理解 AWS pentesting 可能不同于传统 pentesting 也很重要，正如我们在本书中所看到的，并将在本章中进一步了解。我们必须了解 AWS pentesting 的技术和非技术部分，这正是本章的内容。我们将从 pentest 期间要执行的步骤的概述开始。然后我们将看看 AWS pentesting 的未知数。我们将学习在进行 pentest 之前准备好您的环境，最后，我们将讨论 pentest 之后需要执行的一些实际步骤。

在本章中，我们将介绍以下主题：

• 自动气象站测试方法
• 了解你的五旬节和 AWS 五旬节的未知数
• 五旬节的预调节
• 避免通信中断
• 实现安全而不是默默无闻
• 五旬期后-五旬期后

要遵循本章中的说明，您需要以下内容：

• AWS CLI
• 变质岩

本节将偏离用于非云测试环境的传统测试方法。我们不遵循传统的测试方法，主要是因为我们的目标范围——在这种情况下，我们的目标将是 AWS 环境。此外，我们将使用正在测试的客户端提供的有效凭据执行功能测试。

重要提示

功能测试是扫描和检查用户已实施的漏洞和错误配置服务的手段和方法。

本章将讨论 pentest 的注意事项，并讨论在执行 pentest 前后需要了解的细节。然而，在我们开始之前，我们需要了解如何针对 AWS 交付 pentest 的步骤。

让我们分解在 AWS 目标上执行 pentest 的四个不同步骤：

1. 侦察
2. 剥削
3. 剥削后
4. 报告

让我们详细地看看每一个。

侦察，也就是通常被称为侦察，是我们使用各种工具收集目标信息的地方。我们在第 2 章Pentesting and Ethical Hacking中使用了其中一些工具，并学习了如何收集有关目标的公共信息。

此外，我们使用侦察阶段收集有关服务和用户的信息。诸如 Lambda、S3 和 EC2 等服务是用于从目标环境中发现和枚举信息的服务—发现到 S3 存储桶的完整 URL 路径，通过 EC2 找到公共 DNS 地址作为内部网络的入口点，并识别弱 Lambda 功能和策略。所有这些都是 AWS pentest 期间侦察阶段的一部分。

一旦我们掌握了我们目标环境的所有信息，现在是时候进入利用阶段了，我们将开始创建攻击路径，以及武器化和利用我们易受攻击的服务和目标。

到目前为止，这是 AWS 测试方法中更有趣的部分之一。我们在利用阶段收集所有信息，并创建一条我们认为可以在目标环境中工作的攻击路径——当然，这是我们发现的信息。攻击路径是一个理论上的一步一步的过程，您可以根据侦察阶段发现的信息，构建该过程，强调发起攻击所采取的步骤。让我们来看看我们可以根据在 APEN 阶段的侦察阶段发现的信息创建的几种不同的攻击路径。我们将描述从外部和内部威胁攻击服务的攻击路径。

下面是一条攻击路径，它说明了内部威胁可能造成的后果。请记住，内部威胁是指为公司工作并已使用有效凭据访问环境的人员：

1. 发现一个具有弱策略和可能敏感信息的S3 桶。
2. 修改弱策略以允许内幕人士检索机密信息。
3. Insider 会过滤敏感数据，并创建一个新策略，阻止合法用户访问 S3 存储桶。

以下是 AWS 在不知道任何凭据的情况下的潜在攻击路径示例：

1. 在公共 GitHub 存储库中标识凭据。
2. 使用这些凭据对 AWS 环境进行身份验证。
3. 带有公共 DNS 的 EC2 实例承载一个易受攻击的 web 应用程序，如 WordPress，该应用程序允许 Pentester 攻击和访问主机操作系统。
4. 安装后门以便持久访问。
5. 扫描内部 VPC 网络并发现其他易受攻击的目标。

这些攻击路径说明了可能造成的潜在危害；然而，攻击路径只是基于在环境中发现的东西的理论。为了进行攻击，需要对攻击路径应用方法，以便将攻击路径武器化。

重要提示

方法是用于执行攻击的工具和战术。

作为一名 pentester，您将拥有一些工具来帮助您实现特定攻击路径的结果。诸如Kali Linux、Metasploit、和 AWS CLI等工具可以很好地执行我们在本节中介绍的攻击路径。您也可以使用 Bash 或 Python 编写自己的工具，就像我们在第 4 章利用 S3 bucket中所做的那样。一旦您准备好了所有的工具，并且您的创造性攻击路径很好，就可以利用 AWS 服务了。

利用包括梳理我们的攻击路径和方法，遍历攻击路径的每个步骤，并在可能的情况下进行利用。当然，由于攻击路径是理论上的，而不是实际的，因此有时您可能无法完全执行整个攻击路径。如果发生这种情况，请确保记录和报告您能够做的事情，并说明对组织的影响。在本章中，我们将了解更多关于报告的信息，所以现在让我们继续讨论利用。

关于攻击，需要注意的是拒绝服务攻击，俗称DoS，如第 6 章、设置和测试 AWS Aurora RDS中所述。如果攻击路径包含 DoS 攻击作为攻击路径的一部分，那么您和 pentesting 团队需要与客户讨论 DoS 是否是他们允许在 pentest期间发生的事情。通常，您将有一个服务级别协议，描述是否允许 DoS；然而，最好是通知或询问是否允许 DoS，因为 DoS 具有很强的侵入性，可以关闭系统，使其对用户毫无用处。此外，DoS 不应出现在生产系统上，因为生产系统与推动客户的业务模式有直接的关联——这意味着生产系统通常与帮助产生某种类型的收入有关。如果您怀疑生产系统易受 DoS 攻击，请请求生产一个复制目标系统的测试系统来对其进行测试DoS 攻击。这样，您可以测试您的理论，也不会影响目标组织。

一旦您运行了攻击路径并完全执行了所有操作，我们需要查看是否有任何方法可以在受攻击的环境中创建支点，并检查是否可以访问其他网络。

在这一阶段，我们主要关注的是试图发现我们可以用来推进攻击路径的任何其他资源。关于 AWS pentesting，我们可以使用利用后阶段找到其他可能被利用的服务–通常，我们会发现 EC2 实例上托管的其他易受攻击的服务，就像我们在第 9 章、使用 Metasploit 进行的真实 pentesting 等中所做的那样！

关于后期利用的另一个要点是检查我们是否可以看到 VPC 中可能可见的任何其他网络。在 pentesting 世界中，回想一下术语分段——一个术语涉及不同的网络，它们之间没有不安全的通信。例如，我们希望检查并确保媒体网络无法直接与金融网络通信，因为金融网络将承载个人身份信息（PII）

通过网络或发现其他易受攻击的服务，我们的 AWS pentesting 方法能够通过演示对客户端系统内漏洞的全面攻击，全面详细说明最坏的可能性。这次完整的攻击突出了这些漏洞是真实的且可利用的证据——这意味着攻击者也可以这么做！

一旦我们在网络中完成旋转，是时候回溯我们的步骤，寻找我们可能错过的任何东西了。这意味着要完整地回顾 AWS pentest 神话。一旦完成回溯步骤并回顾任何可能遗漏的项目，就可以开始编写报告了！

接下来，让我们开始讨论报告编写过程

后面的一节后五分钟测试–在五分钟测试之后，将讨论并更详细地分解报告过程；然而，讨论我们如何使用 AWS 报告是很好的。从 pentest 收集信息时，您希望确保详细说明功能部分和更传统的 pentesting 部分。这意味着哪些部分与凭据一起使用，哪些部分可以在没有凭据的情况下被利用。以这种方式突出这些问题可以让目标业务部门了解攻击者或内部人员如何利用您的系统进行攻击，同时也可以查看环境中的一些功能改进方面。

现在，让我们扩展这个想法，并开始进一步讨论报告，以及在 AWS pentest 的技术部分完成后我们应该做什么。

任何一块石头都不应该被推倒——至少俗话说是这样。关于 pentesting AWS，甚至是一般的 pentesting，也可以这样说。一个五旬期考试只和所有参加五旬期考试的人一样好。这意味着目标组织将需要确保他们允许共享所有信息，如果 pentest 团队怀疑需要任何其他信息，则应将此信息提供给团队。这就是我们所说的了解未知的意思。

了解在 pentest 中寻找什么的最好方法是不断地进行 pentest，并且始终对新想法持开放态度。虽然这听起来有点陈词滥调，但它确实有一些优点。经验在引导 pentest 走向成功方面起着巨大的作用，而获得这种经验的唯一途径就是尽可能多地进行道德黑客攻击——我可以补充说，在不同的环境中。这就是为什么在本书中，我们研究了许多基于各种服务和应用程序的不同场景。这些练习中的每一个都有助于在你的头脑中建立数据库，你可以使用存储在数据库中的知识来帮助引导你走向未来

了解未来将完全基于过去的经验。例如，如果您有一个想要执行的功能测试，那么您知道在 pentest 开始之前，您应该拥有 AWS 环境的凭据。您还应该知道，您应该拥有所有正在测试的实例和资源的完整范围。一个年轻的云 pentester 可能没有意识到，也可能不知道该问什么。然而，在阅读了这篇文章并运用了你的经验之后，你知道你应该问更多关于 pentest 应该包含什么的问题，并且知道需要什么资源——因此知道未知。

让我们讨论一些您希望在进入基于 AWS 的 pentest 或具有范围内 AWS 资产的 pentest 之前了解的要点。

收集凭证对于能够有效地对目标执行功能测试来说至关重要。没有这些凭据，您将无法访问任何资源，也无法检查错误配置，例如策略、检测过程和易受攻击的功能。我们在本书的大部分篇幅中都看到，大多数资源都不是外部可用的，而那些可供公众使用的资源应该有某种类型的商业案例，说明它们为什么公开在互联网上。通常，企业会有一个合理的理由，例如运行需要访问 internet 的 web 服务器的实例、共享公共资源的文件服务器或允许用户共享信息的 S3 公共存储桶

虽然这些都是很好的理由，但它们仍然需要证明是合理的，并且需要制定政策，确保敏感信息不被置于公共资源中，并确保安全

知道谁拥有您正在测试的资源是极其重要的。我们不是指整个客户，而是指拥有 AWS 资源的部门。由于 AWS 易于扩展，且极易出现实例管理不善的情况，因此，与操作和拥有测试资源的人员建立直接的通信线路非常重要。这将允许您在五旬考试之前、期间和之后讨论问题。您还可以将任何 pentest 的发现指向该所有者。

当我们为功能测试某个东西时，拥有该应用程序的凭据是很重要的。如果没有凭据，我们将无法访问应用程序并确切了解它是如何工作的，更重要的是，它是如何为目标环境工作的。能够看到应用程序在环境中的使用方式，可以让您真正了解组织的工作方式以及他们是否在实践安全性

例如，web 应用程序可能具有安全性，例如强密码和通过 HTTPS 使用加密流量，但 web 应用程序上的用户可能具有过度许可的控制，允许他们操纵 web 服务器，并可能允许攻击者在用户帐户被利用时进行攻击。如果没有应用程序的凭据，我们将永远无法正确评估应用程序的这一部分。

另一个需要了解的重要事项是您将在哪些网络中运营和评估。这有助于避免麻烦，还可以知道要扫描哪些子网，并且只评估这些子网内的目标。我们还需要知道私有VPC中的任何目标主机是否具有与其关联的公共DNS名称。这让我们知道潜在的低垂果实区域和目标更容易受到攻击，因为它们对网络开放。

我们现在知道如何避免 pentest 中未知的部分，所以现在让我们开始前进，并讨论在 pentest 开始之前我们如何调整我们的团队。

为你的环境做准备对于成功完成 pentest 至关重要。就像知道未知一样，重要的是你和你的团队要把一切都安排好，每个人都对如何执行 pentest 有相同的看法。最好在考试前准备一份检查表，确保所有问题都得到了回答。让你所有的问题都得到回答可以确保在五旬期考试开始之前，没有什么事情没有做或没有回答

在开始 pentest 之前，让我们与您的团队和您的环境讨论一些好事情

虽然这似乎很明显，但 pentest 团队中的每个人都知道他们在 pentest 中的具体工作职责是很重要的。通常，您希望让一个 pentester 执行 pentest 的部分网络或云部分，而另一个 pentester 执行 web 应用程序 pentest。每个 pentester 都知道哪些在范围内，哪些不在范围内，这一点也很重要。特定 API 可能不受限制，高价值生产系统通常不受限制，某些云环境可能不符合条件

无论是什么样的测试，每个测试人员都应该了解他们的职责和应该进行测试的时间。

另一个好的设置是在五旬斋期间，五旬斋教徒存储和共享笔记的中心方式。注释共享可确保戊酯不会重叠，并可在测试各种环境时相互帮助。文档的另一个非常重要的方面是确保 pentest 在 pentest 期间截图。截图帮助 Pentester 在报告中说明他们在 pentest 期间做了什么

有一份个人联系人名单，以便在五旬考试期间与之沟通，这一点非常重要，因为它可以让你知道在五旬考试期间可能遇到的某些问题，你应该与谁联系。您应该有一个详细的列表，列出各种问题的联系人，无论是访问云环境，无法访问网络，还是需要创建一个临时帐户。详细的人员名单将确保您能够快速解决此类问题

既然我们在开始五旬斋之前了解了更多需要发生的事情，那么让我们来讨论一些我们在进行五旬斋时应该了解的事情。最大的问题之一是缺乏沟通，这正是我们将在下一节中详细讨论的问题。

在进行五旬考试时，很容易迷失在杂草中，忘记评估的另一边有人依靠你与他们讨论五旬考试期间发生的事情。有太多次我看到当五旬节开始时，交流完全中断，直到五旬节停止，才有交流。然而，这种情况永远不应该发生

当进行 pentesting 时，你的客户通常对你正在做的事情有点好奇，让他们了解正在发生的事情实际上是有益的。为什么它很重要？不止一种方式。让我们看看如何通过沟通让我们的参与自由流动，让每个人都参与其中，并帮助避免可能出现的任何谈话障碍。

每次你开始和停止 pentest 时都会发送一封电子邮件，这让你的客户知道你什么时候开始，并让他们真正感觉到“Pentester 在电线中，所以如果我们看到警报弹出，不要反应过度。”这也给了客户一种感觉，即他们得到了他们所付出的——而不是说他们没有得到——这也给了他们的决定一种可信度，让你接受 pentesting。此外，你还可以使用当天开始的电子邮件，询问当天五旬节期间可能需要回答的任何问题，或者为你可能遇到的障碍获取答案。障碍可能是无法访问资源，或者被锁定在范围内的某个内容之外

发送停止电子邮件同样至关重要。发送停止电子邮件可以让你的客户知道你已经完成了，如果他们有任何问题，他们通常可以向你发送问题。此外，通过发送停止电子邮件，客户可以与自己的团队交谈，了解他们是否看到了任何异常情况，并让他们了解他们的员工是否发现了任何异常情况。最后一件事——发送停止电子邮件为您提供了一点保险。通过发送停止电子邮件，您可以通知他们，在五天测试后，网络上发现的任何异常情况都不是您或您的团队完成的

会议可能会变得拖沓，而且有点多余，因此重要的是你不要把客户的时间浪费在 pentesting 范围之外的不必要的交流上，或者你不要每天在会议上说同样的话。此外，太多的长时间会议浪费了宝贵的时间。那么，在不浪费时间的情况下，在客户会议上产生影响的最佳方式是什么？在一周的第一天和最后一天安排一个简短的会议。

每周第一天的会议应用于陈述任何评论、担忧、担忧或问题，会议时间不得超过 30 分钟。如果一次会议的时间超过 30 分钟，那么通常情况下，这意味着在五旬斋开始之前信息就丢失了。当然，这条规则也有例外，比如因为敏感信息被泄露而不得不停止 pentest，或者可能是你的 pentest 团队不小心搞坏了什么

在周末举行一次快速的回顾会议，允许您和您的团队提出在您的每日开始和停止电子邮件中可能没有回答的问题，也允许客户向您提出他们可能有的任何问题。这也是一个很好的结束一周的方式，在周末休息之前进行更多的私人友好的交谈。请记住，作为一名 pentester，你的工作是表现出友好，而不是傲慢，因此确保客户从你和你的团队那里得到一贯友好和欢迎的语气是成功的关键之一

其中一个最大的问题是，对于许多参与谈话的人来说，技术谈话往往过于技术化。使用太多的技术术语会使谈话变得混乱，并经常让客户感到困惑。这就是为什么使用简单而简短的讨论来回答技术问题而不出现技术混乱是很重要的。让我们看一个简单的例子，说明如何在技术上回答攻击 S3 存储桶的问题，然后展示一种简单的方法来回答它。

这个答案太专业：

在 pentest 期间，我们发现 S3 存储桶通过绕过允许 PenTester 直接访问 S3 存储桶的弱策略来承载 PII 数据。Pentesters 能够通过 S3 bucket 的完整 URL 查询和过滤数据。

正如您所看到的，这个示例使用了一些非 IT 员工可能无法完全理解的非常重的技术术语。如果有人不理解你使用的术语，他们会问问题，这可能会占用更多的时间，也会占用你的测试时间。另一方面，困惑的人甚至可能不会问问题，然后感到不确定。这也是为什么使用简单术语很重要的原因。让我们用更简单的术语回答同样的问题

这个答案更人性化：

在 pentest 期间，我们发现 S3 资源具有可以直接链接到用户和客户的敏感信息。Pentester 能够破坏 S3 资源上的策略，并将数据复制到自己的攻击机器上。

这个例子偏离了使用非常重的技术术语，使用了资源等术语，而不是桶。铲斗是一个与 AWS 相关的技术术语，很多用户可能不理解；然而，使用资源一词有助于缩小这一差距。我们还使用了break这个词，而不是pass，因为break是一个相当常见的与道德黑客相关的词，并且为公众所知。

我们已经研究了如何准确有效地测试 AWS 的许多不同方面。现在，让我们来看看我们如何不误导我们的客户和我们自己时，说明处罚结果和补救措施期间和之后的五分之一。

本节将讨论我们如何避免默默无闻，如何帮助我们自己、我们的客户和我们的业务，在对一个组织进行测试后，如何保持某种实际的安全实现感。至关重要的是，我们要使用最佳实践，让我们的客户知道并理解如何在不妨碍这些客户进行日常操作的情况下改善他们的安全态势。然而，这并不意味着放置一个安全控制，除了修补一个 TA1 辅助带 T2。

重要提示

一个创可贴是一个暂时的修复并不是最好的修复方法。此外，一个创可贴可以容易地绕过一些网络或系统的一般知识。

让我们来讨论一下一些内容，关于通过模糊性实现的安全性对我们和我们的测试活动真正意味着什么，特别是在讨论我们如何在 AWS 系统中实现这种伪安全性时。如前所述，我们需要确保使用最佳实践来帮助我们的目标企业实现最高级别的安全态势

默默无闻的安全性是一个术语，它应用的技术可能会保护组织，但往往会忽略可能导致其他问题的其他问题。通常，它被认为是实现了安全性，因此只有内部组织才能访问不安全的资源；然而，正如我们所看到的，内部并不意味着安全。AWS pentesting 的大部分是功能测试的一部分，用于帮助公司更好地保护其系统。这类测试使用合法凭证访问内部系统，并查看内幕人士对环境的影响

现在，让我们看一个相关的练习，它将让我们了解 S3 存储桶，以及如何通过模糊性避免安全性

让我们讨论如何通过隐蔽性来确保 AWS S3 桶的安全。假设我们已经在客户的 S3 环境中完成了 pentest，我们发现了一个公共 S3 存储桶，其中也实现了无访问控制。让我们来看看我们发现的资源：

1. First, we discovered the packtawspentesting bucket. We discovered this bucket back in Chapter 4, Exploiting S3 Buckets. Let's pull the public access block information from the bucket:

   $aws s3api 获取公共访问块——bucket packtawspentest

   您将看到以下输出：

   

   图 10.1–公共桶策略块

   所有公共功能都设置为 false，这意味着此桶已打开！ 

   重要提示

   要查找有关公共 bucket 策略的更多详细信息，请访问 AWS 资源，阅读公共 bucket 的输出：https://docs.aws.amazon.com/cli/latest/reference/s3api/get-public-access-block.html 。

2. Now that we see our bucket is public, let's move forward and check the permissions on our target bucket:

   $aws s3api 获取 bucket 策略——bucket packtawspentest——输出文本| python-m json.tool

   下一个屏幕截图说明了策略–注意策略如何为效果设置允许：

   

   图 10.2–公共桶政策

   我们看到 S3 bucket 上允许使用Allow效果，这意味着我们可以用这个 bucket 做任何我们想做的事情。我们可以从桶中过滤、放置和删除数据

3. 因为我们将要报道这个问题，我们需要找到一个简单的方法来找出谁拥有这个桶。在我们的例子中，我们将使用 Metasploit。在 Kali 终端中键入msfdb run命令，启动 Metasploit。一旦 Metasploit 启动，我们将使用辅助/cloud/aws/enum_s3模块。将访问 id和秘钥设置为账号的访问 id，点击运行。如果您需要复习，请返回第 9 章、与 Metasploit 的现实生活 Pentesting 等等！，供审查：

图 10.3–从 Metasploit 检索到的 Bucket 策略

我们可以看到拥有 bucket 的用户以及 bucket 所属的区域。这将允许我们报告问题，并将其直接链接到所有者，以便他们了解并修复此问题。通过 pentest 报告直接向用户报告，我们可以打开一条直接的通信线路，以防用户试图解决任何问题。这是通过模糊驱车远离安全的步骤 1**。**

步骤 1包括确保我们与参与活动的所有人保持直接沟通，并且没有人被排除在外。Pentesting 是一项大型活动，对每个人来说都是一种乐趣和学习体验——但是，只有我们让 pentest 范围内的人参与进来，它才能成为一种学习体验。传统上，受影响的用户只有在他们自己的团队发布 pentest 后才会得到通知。这意味着客户可能只允许他们认为与解决问题相关的内容

重要提示

需要注意的是，有些客户可能不希望您直接与他们的员工合作。如果是这种情况，请理解这是客户的要求，不应忽视。破坏客户的范围和理解意味着破坏客户的信任，从而破坏业务关系

现在，让我们看一看步骤 2，我们如何通过最佳判断和实践帮助保护客户的 S3 资源。为此，我们需要登录 AWS 控制台，并通过 AWS GUI 访问我们的 S3 bucket 存储库。我们将采取这种方法，就像我们是管理员一样，因为我们需要知道如何解决问题的确切细节，并向我们的目标受众说明这一点

让我们从位于的 S3 存储桶开始 https://s3.console.aws.amazon.com/s3/home?region=us-西-2#。

一旦您到达 S3 存储桶的位置，让我们通过将公共存储桶设置为私有来继续前进。删除公共访问将确保组织外部的任何人都无法访问 S3 存储桶：

1. 首先单击名为packtawspentesting的 bucket

2. 接下来，点击权限选项卡。

3. Then, click Edit:

   

   图 10.4–从 AWS 控制台编辑 bucket 策略

4. Check Block all public access:

   

   图 10.5–通过 AWS 控制台阻止公众访问

5. 点击保存结束

现在，目标 bucket 不应该被公众访问，这意味着只有内部主机可以访问它

现在我们需要进入步骤 3。在最后一个也是最后一个步骤中，我们将使 bucket 被所有人拒绝，然后管理员将需要根据他们公司的策略配置 bucket。因此，我们将坚持要求他们制定一项策略，即拒绝所有，然后允许管理员根据需要创建新的规则，以了解访问权限：

重要提示

“需要知道”访问涉及到根据其工作职能只允许那些需要它的人访问

1. 让我们进入packtawsPentestS3 Bucket 中的Bucket Policy选项卡，开始我们的最后一步。

2. After clicking the tab, we need to change Effect:Allow to Effect:Deny:

   

   图 10.6–通过 AWS 控制台手动更改 bucket 策略

3. 完成后，您需要单击保存。那之后你就完了。

干得好，我们现在已经成功地确保了我们的桶，并建议我们的目标改变他们的桶政策，以适应他们的公司政策。通过确保我们在层中实现了强大的安全性，我们采用了深入安全的方法，而不是通过模糊安全的方法。

使用简单的术语，让你和客户彼此建立联系，这是成功为你的 pentesting 方法增加价值的众多关键之一。还要记住，pentest 并非所有内容都是技术性的！

现在我们知道在五点之前和期间需要发生什么，让我们来看看在五点完成之后应该发生什么。

五旬期考试的一个重要部分是复习五旬期考试期间发生的每件事，并且能够在每个人都能理解的水平上说明这一点。除了确保信息清晰地呈现外，还必须确保在测试后采取了正确的步骤。

让我们继续讨论一些简单而实用的步骤，这些步骤在完成 pentest 后可能会用到。

完成五旬考试后，五旬考试团队需要收集和讨论五旬考试期间发生的事情。这意味着任何问题、胜利以及任何可能是有价值的信息以供审查和记录。这样做可以让团队从他们的错误中吸取教训，并将这些错误和学习经验应用于未来的五旬节。另一方面，讨论什么进展顺利可以让团队缩小他们更好的技术规模，为未来的 pentest 实现更好的解决方案。

该会议还应讨论团队在测试期间收集的内容，并讨论哪些发现可以成为报告中的建议。调查结果和建议告诉客户需要解决的严重问题，以帮助确保客户的系统状态。结果将基于如下所示的矩阵：

图 10.7–pentest 报告的风险矩阵

如您所见，它讨论了可能性和影响–这允许我们根据其对客户的影响以及该问题被利用的可能性来调整影响。让我们花一点时间来看看这个例子。

假设 pentester 在生产系统上发现一个易于利用的漏洞。生产系统需要将冲击置于高。需要将其设置为高，因为生产系统是公司产生收入的基础—，因此系统关闭会产生影响客户的问题，并可能造成金钱损失。此外，由于该漏洞很容易被利用（考虑使用 Metasploit），因此很可能是的。这将使该问题在生产系统上的总分处于高。

现在，让我们继续前进，讨论报告以及我们如何将刚刚学到的知识应用到报告中！

报告通常被视为测试中最关键的步骤之一；毕竟，这些建议将提交给客户。在创建报告时，您和整个 pentest 团队在将其发送给客户之前，必须对文档进行检查和编辑。进行大量审查将确保语法准确，并对如何证明调查结果和建议提出不同的理解。

报告中的调查结果应显示给公司的风险和严重程度。风险是指漏洞可能被利用的可能性，而严重性则提醒公司，如果漏洞被利用，该漏洞将对组织产生影响

该报告将提供一个路线图，说明这些建议如何有助于纠正调查结果，同时确保这些调查结果不会再次出现

例如，如果公共 S3 存储桶是在 pentest 期间发现的，pentest 团队可以提供一个 3 个月的路线图，帮助缓解已识别的问题，并防止将来在 AWS 环境中再次出现易受攻击的公共存储桶：

图 10.8–补救路线图

正如您所看到的，这个相当详细地描述了 S3 bucket 问题需要及时解决的问题。现在，让我们讨论一下如何跟进我们的客户。

pentest 预约后 6 个月的跟进允许您检查客户，看看他们是否纠正了您在第一次 pentest 中发现的问题。在 6 个月的后续测试中，最佳实践是使用黑盒方法，因为它允许您只关注在上一次 pentest 中发现的内容，并查看它是否可能带来任何新问题

如果在 6 个月的随访期间发现新问题，则需要记录和报告这些问题，与初始测试期间相同。如果发现另一个问题，那么您的团队也需要在 6 个月后根据这些发现进行另一次检查

重要提示

应在 pentesting 合同中说明，如果在 6 个月的随访期间发现新问题，将需要额外的 pentesting 服务。

我们已经了解了很多关于如何在测试之前、期间和之后测试 AWS 的知识。现在，让我们开始总结，并进入下一章。

本章让我们了解了如何对 AWS 进行 pentest 的更多传统和非传统方法，同时也让我们深入了解 pentesting 最关键的一点：报告。我们还学到了一个宝贵的教训，即如何使我们的 pentesting 对我们和我们的团队既高效又有效，同时也对我们的客户及其组织产生影响。

在下一章中，我们将开始学习更多关于在五旬斋期间要避免的事情，以及我们如何在范围内避免麻烦！

• 五旬斋的艺术：https://blog.rapid7.com/2020/02/13/ask-a-pen-tester-q-a-part-2-everything-you-need-to-know-about-the-art-of-penetration-testing/
• 更多关于模糊安全的讨论：https://www.techopedia.com/definition/21985/security-through-obscurity-sto