OmniProx: Multi-Cloud IP Rotation Made Simple
TLDR: If you want to use the tool without reading the post here's the GitHub:
ZephrFish
If you have used FireProx (FP) or CredMaster (which uses FP) in the past for proxying traffic to a destination you'll know how useful they both are, specifically FP uses Amazon's API Gateways for IP rotation and it does it really well. However as of recently, AWS have changed their policy to prohibit the use of the API gateway for outbound penetration testing, which if you're in the same boat as many puts a bit of a stop to using FP and CM, therefore I set out to work on a different solution that uses multiple providers with failover.
With the death of FireProx due to AWS policy changes, many red teamers and researchers lost a core capability stealthy IP rotation via disposable API gateways. This post dives into how OmniProx is designed and why it might be a solution for your needs and wants. Not just as a replacement, but a step forward as it brings multi-cloud coverage, modular extensibility through providers as modules so if you have a provider you want to use just write a quick python plugin and it'll work like a framework.
Initial Architecture Planning
Firstly understanding how AWS API gateways operate behind the scenes, AWS API Gateway isn’t just an API proxy, it also gives you automatic IP rotation when you put it in front of your traffic or domain, since each invocation can egress from a large shared pool of AWS-owned IPs.
With this in mind, the other options available from the cloud providers were fairly limited but a few options bubbled up to the top when I was doing research:
- Microsoft Azure
- Closest match to API Gateway (policy engine, rate limiting, transformations)
- Public IPs come from Microsoft’s shared ranges, which effectively rotate if you don’t lock down to a static IP.
- Google Cloud Platform (GCP)
- API Gateway (GCP)– Google has a service literally called API Gateway. Similar functionality to AWS API Gateway (serverless backend proxy).
- Traffic egresses from Google-owned IP pools, not client IPs.
- Alibaba Cloud
- API Gateway– Direct analogue to AWS API Gateway.
- Provides shared egress IPs across Alibaba Cloud ranges unless you bind an Elastic IP.
- CloudFlare Workers
- The ability to deploy javascript workers as serverless code and You can run serverless logic at edge POPs. Requests egress from Cloudflare’s massive IP pool, which is globally distributed and rotates frequently.
Building the Thing
As FireProx only supports AWS, I wanted to have a modular design that future providers could be added to easily allowing for better alternatives and lesser single reliance on one service or another. I opted to base the design around the same command structure of FireProx with the following commands and arguments:
--command {create, delete, list, cleanup}
--api_id <API ID>
--url https://URLGOESHERE
--provider {azure, az, gcp, cloudflare, cf, alibaba}
Initially I was going to name this tool FireProx2 but as I removed the AWS functionality and re-architected the way the tooling works for different providers I opted for a new name, OmniProx.
"Omni-" (from omnipresent) implies "all-encompassing," which aligns with multi-cloud coverage. It’s catchy ("Om-nuh-procks"), and can be shortened to omni for the cli tooling.
I also set out to build out at least three providers to start with and templated out the rest to allow others to add more in future.
Challenges
Two of the biggest challenges I faced when building this out was getting the providers working in harmony with shared commands and secondly getting the various services working for the providers, for example I started out with Azure API Gateways but due to limitations, the deployment worked but requires some changes to be made to the baseline code to get it working, I then moved on to looking at different Azure services that could be leveraged for rotations and URI passthrough, two really important requirements.
OPSEC Considerations
In addition to the challenges, there are some additional operational security (opsec) considerations to keep in mind when it comes to usage. CloudFlare for example adds a static subdomain to each worker you create so it may be something to consider when you first setup your account to keep it generic.
Failover & Resilience
Something I haven't really touched much on is failover, something not massively considered in my implementation but I hope to add some more features in future to account for things like failed deployments to auto re-deploy, have the ability to to round robin requests with multiple providers, i.e spin up the gateways then script up generation of traffic and responses along with regional balancing for more broader use-cases.
Use Cases
The uses for FireProx and CredMaster have been very offensive security focused but I hope that with OmniProx the uses are broader and allow for things like bypassing geofencing or masking source IP to hide within noise, scraping content with rotating headers in addition to source IP. The other uses I hope to use is the distribution across multiple providers in parallel with the --all flag you can combine multiple providers for better spread.
Limitations
None of the providers are perfect and each of them has a caveat or thing to consider. API Gateways, Workers, and serverless functions have invocation quotas and rate limits. Aggressive use (high request volume) will hit throttling or get your account flagged.
IP Rotation with Every Request
| Provider | True IP Rotation | Header Rotation | Implementation |
|---|---|---|---|
| Cloudflare | No | Yes | Headers rotate on every request using generateIP() function |
| Azure | Yes * | Yes | Each container has unique IP; headers rotate per request |
| GCP | No | Yes | Single gateway IP; headers can rotate |
| Alibaba | No | Yes | Single API IP; headers can rotate |
*Azure provides true IP rotation by using multiple containers, each with its own public IP
Closing Thoughts
I've wanted to build an addition to FireProx for years because having an over reliance on one provider was always going to result in something giving, be it the provider changing policy or something falling over, so with OmniProx I hope to change that and bring a better cross-cloud, cross-domain solution for all.
ZephrFish