IPv4 Turf War(ipv4.games) |
IPv4 Turf War(ipv4.games) |
In Cisco IOS you can configure the source IP address for HTTP requests using the 'ip http client source' configuration-mode command. Then, from exec mode, you can:
#copy http://108.61.215.240/claim?name=hlfuller null:
Loading http://108.61.215.240/claim?name=hlfuller
321 bytes copied in 0.020 secs (16050 bytes/sec)Here is how you win the IPv4 games, in order of most to least effective:
1) Have a large online following that is willing to visit your claim link or a page where you can embed an iframe / img / etc that points to your claim link.
2) Pay to use someone else's (consensual) botnet by paying a residential proxy service, this is the approach I just used and it cost me a few dollars for access to a massive amount of distributed IPv4 space.
3) Abuse cloud / serverless offerings as far as they will go, unlikely to win more than a few blocks this way.
4) Own IPv4 space.
Other less ethical approaches: possibly exploit the system by sending a XFF header the developer forgot to block (probably just checking socket address so unlikely to work here), spin up a Vultr VPS in the same DC and probe for a way to connect with a local address, hijack BGP space, run your own botnet, I'm reminded of an old exploit in WordPress XMLRPC...
From what I can see the current rankings are just me and mike fighting for the same proxy space (the vote goes to the most recent visit per IP), and everyone else falls into buckets 3 & 4.
Sadly, it was considered, and XFF is ignored from non-private source addresses: https://github.com/jart/cosmopolitan/blob/155b378a3962e4d291...
With private addresses defined as: https://github.com/jart/cosmopolitan/blob/7ab15e0b236d085c82...
I do wonder what an IPv6 version of this would look like, but how it'd work, and how active it'd be.
[0]: https://redbean.dev
Can you send an http request spoofing the IP address it's from? I bet you could with enough attempts because you only have to successfully guess the TCP syn cookie once...
Congrats on #1 spot :)
[0] https://spur.us/2020/08/residential-proxies-the-legal-botnet...
In this thread there is a comment wich talks about using AWS API Gateways for scraping. What are other great ways to get many different ips for scraping? Beside residential proxies.
What other options do people have?
http://ipv4.games/claim?name=whatever
I expect you could do an img tag or iframe, buy cheap ad traffic, and win. Tor is an option but last time I looked the exit node count is in the thousands. You could probably use any feed submitter or preview functions (Google docs insert URL, Facebook insert URL, etc).
- Static IP blocks from their ISP (some still lease IPs for surprisingly cheap).
- Releasing/renewing their NAT boxe's DHCP release on carriers that don't pin assignments (usually these are in pools of /22 or 1024 addresses - though most would be in use at any given time and impossible to randomly get you should be able to get a couple dozen).
- Customers of ISPs that use CG-NAT (cheap wired) or NAT64 (some wireless providers), similar to the above just 1 translation layer deeper.
- IP space you control (that's how I have 23.0.0.0/8 for the moment)
- BGP hijacking IP space you want to control (though hopefully in the world of RPKI this is getting harder and harder to do)
I like the test claim from localhost :).
https://www.ietf.org/archive/id/draft-schoen-intarea-unicast...
Some of space they are after, like 240/4, was always just "reserved" and you won't find as much resistance against it as reserved things are intended for exactly this kind of proposal. They just need to convince folks it's reasonably likely to be the best use of the space, overriding any significant unauthorized usage or alternative proposals as being less valid a use case, and it could be reasonably done. Real world implementation of the change might be a different story but they could at least get consensus that it's the intended use going forward.
Other spaces like 127/8 were actually assigned for use in the wild not just reserved for future use and despite 127.0.0.1 being most common address the others in the assigned space were definitely actually in use as well past the /16 they wish to preserve. This is especially in more networking infra focused contexts which are the things that would need to change most universally for this proposal to work. It's unlikely such a breaking standards change would get any consensus i.e. IMO that proposal is likely to never leave draft status.
David Täht, who was one of the authors of that draft, even holds regrets on the 127/8 proposal as it has caused the project to receive a lot of negative focus https://github.com/schoen/unicast-extensions/issues/16 and they have since let that draft proposal expire which is why your link is to an archived copy.
Though apparently it doesn’t help in this case because it’s HTTP/TCP which requires a handshake