OmniProx：简化多云IP轮换

TLDR：若不想阅读全文直接使用工具，请访问GitHub：GitHub - ZephrFish/OmniProx

如果你过去使用过FireProx（FP）或CredMaster（使用FP）来代理流量到目标地址，你会知道它们都非常有用。特别是FP利用亚马逊的API网关进行IP轮换，效果很好。然而最近AWS修改政策，禁止将API网关用于外网渗透测试，这使得许多用户无法继续使用FP和CM。因此我开始开发使用多提供商并支持故障转移的替代方案。

AWS政策更新

随着AWS政策变更导致FireProx失效，许多红队成员和研究人员失去了通过一次性API网关实现隐蔽IP轮换的核心能力。本文深入探讨OmniProx的设计理念及其如何满足需求，不仅是替代方案，更是向前迈进了一步，提供多云覆盖、通过模块化提供商实现可扩展性——只需编写简单的Python插件即可像框架一样工作。

初始架构规划

首先理解AWS API网关的幕后工作原理：AWS API Gateway不仅是API代理，当置于流量或域名前端时，还能自动进行IP轮换，因为每次调用都可以从AWS拥有的大型共享IP池出口。基于此，云提供商的其他选项相当有限，但我在研究时发现几个优选方案：

Microsoft Azure

• 最接近API网关的功能（策略引擎、速率限制、转换）
• 公共IP来自微软共享范围，如果不锁定静态IP则会有效轮换

Google Cloud Platform (GCP)

• API Gateway服务 - 功能类似AWS API Gateway（无服务器后端代理）
• 流量从Google拥有的IP池出口，而非客户端IP

Alibaba Cloud

• API Gateway - 直接对应AWS API Gateway
• 提供跨阿里云范围的共享出口IP，除非绑定弹性IP

CloudFlare Workers

• 能够将JavaScript workers部署为无服务器代码
• 可在边缘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”），CLI工具可简写为omni。我首先构建了至少三个提供商，其余模板化以便他人未来添加。

挑战

构建过程中面临的两个最大挑战是：让提供商与共享命令协调工作，以及让各种服务为提供商正常工作。例如，最初使用Azure API网关时，由于限制，部署有效但需要修改基础代码才能正常工作，随后转向研究可用于轮换和URI透传的其他Azure服务——这两个非常重要的需求。

操作安全考量

除了技术挑战，使用时还需注意操作安全（opsec）因素。例如CloudFlare会为每个worker添加静态子域名，初次设置账户时需考虑保持通用性。

故障转移与弹性

我尚未深入讨论故障转移功能，当前实现中考虑不多，但希望未来添加更多特性，如自动重新部署失败部署、通过多提供商轮询请求（即启动网关后编写流量和响应生成脚本）以及区域平衡以满足更广泛用例。

使用场景

FireProx和CredMaster的使用一直非常偏向进攻性安全，但我希望OmniProx的用途更广泛，支持诸如绕过地理围栏、隐藏源IP于噪声中、使用轮换头部和源IP抓取内容等场景。另一个希望实现的用途是通过--all标志并行分布到多个提供商，实现更好的分布。

限制

没有提供商是完美的，每个都有注意事项。API网关、Workers和无服务器函数都有调用配额和速率限制。激进使用（高请求量）会触发节流或导致账户被标记。

每次请求的IP轮换

*Azure通过使用多个容器（每个有独立公网IP）实现真实IP轮换

结语

多年来我一直希望扩展FireProx，因为过度依赖单一提供商终将导致问题——无论是提供商改变政策还是服务中断。通过OmniProx，我希望能改变这一现状，为所有人带来更好的跨云、跨域解决方案。

GitHub - ZephrFish/OmniProx