OmniProx:简化多云IP轮换的终极方案

本文详细介绍OmniProx工具,它解决了AWS政策变更导致的FireProx失效问题,支持Azure、GCP、Alibaba和CloudFlare等多云平台的IP轮换,包含架构设计、实现挑战及操作安全考量。

OmniProx:多云IP轮换简化方案

Andy Gill
2025年9月28日 · 5分钟阅读

内容提要

如果您想直接使用工具而不阅读全文,请访问GitHub:ZephrFish/OmniProx

如果您过去使用过FireProx(FP)或CredMaster(使用FP)来代理流量到目的地,您会知道它们都非常有用。特别是FP使用亚马逊的API网关进行IP轮换,效果非常好。然而最近AWS改变了政策,禁止将API网关用于外渗透测试,这使得许多人无法继续使用FP和CM。因此我开始研究一个使用多个提供商并具备故障转移功能的不同解决方案。

AWS政策更新

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

初始架构规划

首先了解AWS API网关在后台的运作方式:AWS API网关不仅仅是一个API代理,当您将其置于流量或域前面时,它还会提供自动IP轮换,因为每次调用都可以从AWS拥有的大型共享IP池中出口。

考虑到这一点,云提供商提供的其他选项相当有限,但在我进行研究时,有几个选项脱颖而出:

Microsoft Azure

  • 最接近API网关的匹配(策略引擎、速率限制、转换)
  • 公共IP来自微软的共享范围,如果您不锁定到静态IP,实际上会轮换

Google Cloud Platform (GCP)

  • API网关(GCP)——谷歌有一个直接称为API网关的服务
  • 与AWS API网关类似的功能(无服务器后端代理)
  • 流量从谷歌拥有的IP池出口,而非客户端IP

Alibaba Cloud

  • API网关——直接类似于AWS API网关
  • 除非您绑定弹性IP,否则提供跨阿里云范围的共享出口IP

CloudFlare Workers

  • 能够将JavaScript工作线程部署为无服务器代码
  • 您可以在边缘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)暗示"包罗万象”,与多云覆盖范围一致。它很吸引人(“Om-nuh-procks”),并且可以缩短为omni用于CLI工具。我还计划至少构建三个提供商作为起点,并将其余的模板化,以便其他人将来添加更多。

挑战

在构建过程中,我面临的两个最大挑战是:让提供商与共享命令协调工作,以及让各种服务为提供商工作。例如,我开始使用Azure API网关,但由于限制,部署工作正常但需要对基线代码进行一些更改才能使其工作。然后我继续研究可以用于轮换和URI传递的不同Azure服务,这是两个非常重要的要求。

操作安全考虑

除了挑战之外,在使用时还需要记住一些额外的操作安全(opsec)考虑因素。例如,CloudFlare会为您创建的每个工作线程添加一个静态子域,因此在首次设置帐户时可能需要考虑保持通用性。

故障转移与弹性

我还没有深入讨论的一个方面是故障转移,这在我的实现中没有太多考虑,但我希望将来添加更多功能,以应对诸如自动重新部署失败部署、能够使用多个提供商进行轮询请求(即启动网关,然后编写流量和响应生成脚本)以及区域平衡等更广泛用例的情况。

使用案例

FireProx和CredMaster的用途一直非常侧重于进攻性安全,但我希望OmniProx的用途更广泛,允许诸如绕过地理围栏或隐藏源IP在噪音中、使用轮换标头和源IP抓取内容等功能。我希望使用的其他用途是通过--all标志在多个提供商之间并行分布,您可以组合多个提供商以获得更好的分布。

限制

没有哪个提供商是完美的,每个都有需要注意的事项或考虑因素。API网关、工作线程和无服务器函数都有调用配额和速率限制。激进使用(高请求量)将触及限制或导致您的帐户被标记。

每次请求的IP轮换

提供商 真实IP轮换 标头轮换 实现
Cloudflare 使用generateIP()函数每次请求轮换标头
Azure 是 * 每个容器具有唯一IP;每次请求轮换标头
GCP 单一网关IP;标头可以轮换
Alibaba 单一API IP;标头可以轮换

*Azure通过使用多个容器(每个容器都有自己的公共IP)提供真正的IP轮换

结语

多年来我一直想为FireProx构建一个补充,因为过度依赖一个提供商总是会导致问题,无论是提供商改变政策还是某些东西出现问题。因此,通过OmniProx,我希望改变这种情况,为所有人带来更好的跨云、跨域解决方案。

GitHub:ZephrFish/OmniProx

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计