To be fair the code actually creates a new API gateway server that acts as a proxy on to an already existing server and you're possibly meant to use this header with your own gateway service.
So, it's set as a header, sent to a user owned proxy, then to the actual external endpoint.
On the other hand I think the receiving API Gateway will be able to see and log your AWS account identifier when you do this. So your IP may not be the only identifying information that needs to be obscured for this to actually work.
The original code is explicit as to the intended purpose:
# Auto generate random X-Forwarded-For if doesn't exist.
# Otherwise AWS forwards true IP address in X-Forwarded-For header
x_forwarded_for = request.headers.get("X-Forwarded-For")
if x_forwarded_for is None:
x_forwarded_for = ipaddress.IPv4Address._string_from_ip_int(randint(0, MAX_IPV4))
The DOGE guy just stripped the comments out.
The code seems like a "creative" use of API gateway to turn it into a proxy for other external sites (single site, really, since you need one per site.) Wouldn't it be simpler to send the requests through a lambda (with a function URL) and get better control of the outbound requests?
tbh the ip space of lambda is large, but not as large as you might think. i did some experiments ages ago with the hypothesis that lambda could be a decent proxy network (if many ip addresses are needed) but iirc the upper limit in my testing was about ~50 ip's.
Even this example if you maxx out your usage of regions appears to only give (2,4 * num_regions) or let's say 70-80 ip's maximum. And they are AWS ip's, which means it is gonna be really easy to detect and block that traffic.
But if you know your target receives lots of traffic from AWS systems all around the world ... this is a good way to mimic that.
To be fair the code actually creates a new API gateway server that acts as a proxy on to an already existing server and you're possibly meant to use this header with your own gateway service.
So, it's set as a header, sent to a user owned proxy, then to the actual external endpoint.
On the other hand I think the receiving API Gateway will be able to see and log your AWS account identifier when you do this. So your IP may not be the only identifying information that needs to be obscured for this to actually work.
The original code is explicit as to the intended purpose:
The code seems like a "creative" use of API gateway to turn it into a proxy for other external sites (single site, really, since you need one per site.) Wouldn't it be simpler to send the requests through a lambda (with a function URL) and get better control of the outbound requests?
This actually a very common way that hackers have used api gateway for years now.
You can take a look at plugins like IPRotate. We are currently working on bringing that into our product.
This is cheaper in that you don't have to pay for any compute time.
tbh the ip space of lambda is large, but not as large as you might think. i did some experiments ages ago with the hypothesis that lambda could be a decent proxy network (if many ip addresses are needed) but iirc the upper limit in my testing was about ~50 ip's.
Even this example if you maxx out your usage of regions appears to only give (2,4 * num_regions) or let's say 70-80 ip's maximum. And they are AWS ip's, which means it is gonna be really easy to detect and block that traffic.
But if you know your target receives lots of traffic from AWS systems all around the world ... this is a good way to mimic that.