浅谈红队基础设施架构和配置
最近有很多关于红队基础设施的现代战略的讨论。每一种实现都有很大的不同，但是我们希望能够提供一些深入的信息，特别是关于我们团队如何处理命令和控制的挑战。 这反映了我们所犯的许多错误，比如深夜记录的文档，当前正在进行的研究，以及我们每天使用的现实世界的解决方案。
一点理论
在寻找最佳解决方案之前，我们首先需要清楚地说明我们的目标。 每个操作的细节都是独一无二的，但是我们觉得下面的内容是对红队的一个很好的概括。
· 提供可靠的工具通讯
· 混淆和伪装，以充分避免检测
· 确保操作数据不被篡改和提取
· 最大化动作吞吐量
有些人可能熟悉汽车文化中的一句流行格言: “快速、可靠、廉价。” 选两个吧。” 这些目标在不同的方向上相互冲突，使我们的问题… … 嗯… … 成为了一个问题。 例如：
· 最大吞吐量可能依赖于不可靠的协议或系统
· 保护数据可能涉及潜在的通信路径
· 充分的伪装可能会减少协议选项
你还将注意到，我们目标的优先级是不同的，取决于操作的每个阶段。 在某些方面，我们可能会优先考虑隐形、吞吐量或可靠性。 正是基于这种洞察力，我们得出了第一个结论: “根据目的将你的基础设施进行分类”。 我们在黑暗面行动课程（Dark Side Ops）中大力宣扬这一点，对某些人来说可能已经过时了，但它仍然是真理。 我们的特殊类别看起来像这样：
· 阶段0(分段)-网络钓鱼和初始代码执行
· 阶段1(持久性)——维护对环境的访问
· 阶段2(交互式)——主动进行漏洞利用、枚举和权限升级
· 阶段3(渗出)-数据提取及影响
这种分段可以用来优化基础设施的一切：流量策略、代码设计、协议选择等等。 详细信息不在本文的范围之内。
分段基础设施关系图
分段还提供了固有的弹性，允许在不影响整个系统的情况下对基础设施进行独立的妥协。 我们不希望发现任何单一的 C2域、有效载荷或工具包来危及整个操作。
像任何优秀的系统工程师一样，我们必须假设在每个阶段都会发生破坏。 你的域名会被拉黑，你的服务器会瘫痪，你的回调会被阻止。 每个阶段的基础设施设计应该是健壮的，包括备用、检查和恢复。 一般来说，拥有“更多”的一切(具有复杂性)是一个良好的开端: 多域名、多协议、多工具等等。 所有这些都伴随着设计系统的真正挑战，但始终让你的核心目标成为指南。
堡垒
现在最具攻击性的基础设施包括在你的控制之下(或部分控制之下)从远程端点路由通信。 这可能是一个 VPS，无服务器端点，或被入侵的 web 主机。 我们喜欢称这些资产为“堡垒”。
最佳实践是仅使用一个堡垒来捕获流量，而不是直接存储数据，然而，每个团队都需要对外部基础设施端点进行自己的安全评估。 我们有一个内部网络边界，我们希望在解密、处理或存储之前访问所有数据。 在这里，我们为了更好的安全性而牺牲了流量路由的复杂性。
我们还有许多分布在供应商和其他地区的堡垒。 这种多样化是我们前面提到的阶段划分的一个要求，但也有助于提供我们需要的弹性。 这意味着多个供应商、服务器、 CDN、域名等等。 我们喜欢在一个集中的 wiki 中保持对所有事情的跟踪，以便于参考。
DevOps
一旦我们的资产数量变得相当庞大，我们就开始寻找 DevOps 解决方案，任何人都会这么做。 最初，我们走的是 Ansible 这条路，创建了一个集中管理服务器，用于分散我们所有不同的基础设施。 我们首选 Ansible，主要是因为它的无代理能力，只需要 SSH 访问来进行管理。 它执行工具安装、路由配置、证书生成、加固、依赖安装等。 我们已经看到了很多成功的案例，我们的 VPS 将时间从几个小时提升到10-15分钟。 这一成功得到了我们行业中其他人的响应，他们用自己选择的解决方案(Chef、Puppet、Terraform等)执行类似的管理。
然而，我们从来没有成为过 Ansible 的专家，并且不断地为我们次优的执行付出低廉的代价。 我们也看到了对完整 DevOps 工具的需求减少，因为我们已经过渡到了需求更少的简化堡垒。 尽管如此，对于足够多样化的基础设施来说，某种形式的 DevOps 是绝对必须的。 事实上，如果你觉得不需要自动化来管理基础架构，那么你可能需要更多的自动化。
隧道
随着你的堡垒配置，流量路由本身确实是一个优先项目。 更受欢迎的选择包括：
· Socat——易于使用，但在操作系统中比我们想要的要更麻烦。 当试图同时支持多个端口时，它也可能变得复杂
· IPTables ——正确配置比较棘手，但是非常强大，几乎没有依赖项
· 反向代理——在第7层提供高级选择性路由，但需要端点上的软件、证书和配
作为我们的堡垒，我们喜欢使用 IPTables。 这在一定程度上是因为我们喜欢把堡垒看作是我们内部运营网络的最简单扩展。 任何高于第4层的内容都会使配置复杂化，并引入新的依赖关系。 说到这里，我们还在前面的平面上使用了一个反向代理，类似于两阶段的隧道设置。 我们的设置目前看起来像这样:
流量采集图
我们的操作网络中有一个流量采集器，它创建到公共可访问的堡垒的 OpenVPN 连接。 使用这些隧道 + IPTables，流量从公共域名/ IP 路由到惟一的内部本地隧道接口。 我们使用它在采集器上的公共 IP 地址(1.2.3.4)和它们的隧道等效 IP (10.8.1.42)之间创建一个映射。 这里的一个替代方案是使用 NAT 和端口映射来降低静态复杂性，但是这样就很难对每个可能的目标端口都通用地处理流量(我们喜欢这样做)。