TLDR： 如果您想在不阅读文章的情况下使用该工具，请访问GitHub：GitHub - ZephrFish/OmniProx: 来自不同服务商的IP轮换 - 类似FireProx，但支持GCP、Azure、Alibaba和CloudFlare

如果您过去曾使用过FireProx（FP）或CredMaster（使用FP）来代理流量到目的地，您就会知道它们有多么有用。具体来说，FP利用亚马逊的API网关进行IP轮换，并且做得非常好。然而，最近AWS更改了政策，禁止将API网关用于外网渗透测试。如果您和许多人处境相同，这在一定程度上阻碍了FP和CM的使用。因此，我开始着手研究一个使用多个服务商并具备故障转移功能的不同解决方案。

AWS的更新政策 随着FireProx因AWS政策变更而失效，许多红队成员和研究人员失去了一项核心能力——通过一次性API网关进行隐蔽的IP轮换。本文将深入探讨OmniProx的设计原理，以及它为何可能满足您的需求和愿望。它不仅仅是一个替代品，更是一个进步，因为它带来了多云覆盖、通过服务商作为模块实现的模块化可扩展性。因此，如果您想使用某个服务商，只需编写一个快速的Python插件，它就能像框架一样工作。

初始架构规划 首先，需要了解AWS API网关在幕后的运作方式。AWS API Gateway不仅仅是一个API代理，当您将其置于流量或域名前端时，它还会为您提供自动的IP轮换，因为每次调用都可以从AWS拥有的庞大的共享IP池中出口。考虑到这一点，云服务商提供的其他选项相当有限，但在我进行研究时，有几个选项脱颖而出：

• Microsoft Azure
  • 与API网关最匹配（策略引擎、速率限制、转换）。
  • 公共IP来自微软的共享范围，如果您不锁定静态IP，这些IP实际上会轮换。
• Google Cloud Platform (GCP)
  • API Gateway（GCP） - Google有一项服务就叫做API Gateway。功能类似于AWS API Gateway（无服务器后端代理）。
  • 流量从Google拥有的IP池出口，而非客户端IP。
• Alibaba Cloud
  • API Gateway - 直接类比AWS API Gateway。
  • 除非您绑定弹性IP，否则在阿里云范围内提供共享出口IP。
• CloudFlare Workers
  • 能够将JavaScript Worker部署为无服务器代码。
  • 您可以在边缘POP运行无服务器逻辑。请求从Cloudflare庞大的、全球分布且频繁轮换的IP池出口。

构建过程 由于FireProx仅支持AWS，我希望采用模块化设计，以便未来可以轻松添加更多服务商，从而获得更好的替代方案，减少对单一服务的依赖。我选择基于与FireProx相同的命令结构进行设计，具有以下命令和参数：

1
2
3
4

--command {create, delete, list, cleanup}
  --api_id <API ID>
--url https://URLGOESHERE
--provider {azure, az, gcp, cloudflare, cf, alibaba}

最初我打算将这个工具命名为FireProx2，但当我移除了AWS功能，并为不同服务商重新构建了工具的工作方式后，我选择了一个新名字——OmniProx。“Omni-"（源自"omnipresent”）意味着"包罗万象"，这与多云覆盖的目标一致。它很上口，并且可以缩写为"omni"用于CLI工具。我还着手构建至少三个初始服务商，并将其余部分模板化，以便其他人未来添加更多。

挑战 构建过程中面临的两个最大挑战是：让不同服务商在共享命令下协同工作；以及让各种服务为这些服务商正常工作。例如，我最初从Azure API网关开始，但由于一些限制，部署虽然能工作，但需要对基线代码进行一些更改才能使其正常运行。随后，我开始研究Azure中其他可用于轮换和URI直通的服务（这是两个非常重要的需求）。

OPSEC考量 除了技术挑战，使用时还需要考虑一些额外的操作安全（opsec）因素。例如，CloudFlare会为您创建的每个Worker添加一个静态子域名，因此在首次设置账户时，为了保持通用性，可能需要考虑这一点。

故障转移与弹性 我还没有深入讨论的一个方面是故障转移，这在我的实现中考虑得不多，但我希望在未来添加更多功能，以处理诸如部署失败自动重新部署、能够使用多个服务商进行请求轮询（例如，启动网关，然后编写脚本生成流量和响应），以及针对更广泛用例的区域负载均衡。

使用场景 FireProx和CredMaster的用途一直非常侧重于主动安全，但我希望OmniProx的用途能更广泛，允许实现诸如绕过地理围栏、通过隐藏源IP来融入噪音、使用轮换的标头和源IP抓取内容等。我希望能实现的另一个用途是通过--all标志并行分布在多个服务商上，您可以组合多个服务商以实现更好的流量分布。

限制 没有任何服务商是完美的，每个都有需要注意的注意事项或限制。API网关、Worker和无服务器函数都有调用配额和速率限制。过度使用（高请求量）会触发节流或被标记账户。

每次请求的IP轮换

* 通过使用多个容器（每个容器有自己的公共IP），Azure提供了真正的IP轮换。

结束语 多年来我一直想构建一个FireProx的补充工具，因为过度依赖单一服务商迟早会出问题，无论是服务商更改政策还是其他故障。因此，我希望通过OmniProx来改变这一点，为所有人带来一个更好的跨云、跨域的解决方案。

GitHub - ZephrFish/OmniProx: 来自不同服务商的IP轮换 - 类似FireProx，但支持GCP、Azure、Alibaba和CloudFlare