It happens that I participate in a bug hunting program and analyzing the app I realized that there is a particular parameter that is very important for access control and that only changes with the IP address.
Anyway, the question here is if I can set a specific public IP address. I don't need to receive a response, just issue a request to parse the request.
You can send out a packet with whatever IP address you like.
Then, one of the routers along the way might decide the packet makes no sense (it is a "martian packet") and discard it. Consider this:
| 192.1.1.1
+------------------- GW4
| 192.168.1.1
+----------------- GW2------+
| 192.168.16.1 | 192.168.33.1
+---- GW1 -----+ ---- GW3 ----
| |
192.168.16.15 192.168.16.243
YOU ALICE
You send out a packet with a source address of 10.0.0.36 and directed to, say, 172.16.16.172. GW1, serving your network which is 192.168.16.0/24, only expected to receive packets matching 192.168.16.0/24, and your packet doesn't match, so it is dropped. You could spoof a connection coming from your "neighbour" Alice, but no more.
Even if GW1 did not complain, it would forward the packet to the next hop, which serves the whole 192.168.0.0/16 branch and also would ignore your packet.
And so on and so forth (the IP I used are actually not all that routable, but it's an example).
Granted, many routers won't do "ingress filtering" because they'll be obsolete or will believe it unnecessary and not cost-effective. But it only takes one hop to wreck the transmission.
Even without this hurdle, the difficulties are not over, because let's say you succeed in delivering to your target a packet coming from 10.0.0.36. The target will reply -- and will reply to 10.0.0.36, so the reply packet will never get back to you. Indeed, should the reply packet arrive to 10.0.0.36, the latter would simply reset the connection as unsolicited.
This is a problem, because most protocols where you "only need to issue a request" are in fact sent over TCP, which requires a handshake between the communicating parties before any data can be sent. The major exception is HTTP/2,
And without that first reply packet you have precious little chance (not the same as zero chances, but still) of establishing a full TCP connection, without which you probably won't be able to send your request.
You might be able to do this using UDP, or other protocols which have no handshake, if the target application uses UDP (it probably doesn't).
Probably not, depending upon whether or not your ISP is implementing Ingress Filtering:
a technique used to ensure that incoming packets are actually from the networks from which they claim to originate.
If your ISP is implementing Ingress Filtering, then your forged packets will be dropped as they traverse your ISP's network, and will never reach your target.
The odds are that your ISP does implement it:
As of 2012, one report suggests that, contrary to general opinion about the lack of BCP 38 deployment, some 80% of the Internet (by various measures) were already applying anti-spoofing packet filtering in their networks.
Even in the absence of ingress filtering as described in the other answers, IP spoofing will hit another hurdle: the TCP 3-way handshake, and possibly higher-level handshakes.
TCP is the basis for many of the most common protocols, including HTTP, FTP, SMTP, POP3, IMAP and their TLS-secured counterparts, as well as SSH, and many many more.
When you attempt a TCP connection, you send a first packet (SYN). Server replies with SYN-ACK. Client sends ACK. During the SYN and SYN-ACK exchange, random sequence numbers are chosen and transmitted.
If you use a spoofed IP address, the server will send the SYN-ACK to the device which actually has that IP, not you. So you won't receive the server's sequence number, and no communication will be possible.
There used to be issues a few eons ago when the sequence numbers were predictable. That allowed you to send packets blindly on the TCP connection (you would not receive any answer, but you could still send requests). This should now be fixed everywhere (see RFC1948).
If somehow you still manage to do so, most protocols now use TLS on top of TCP, which adds yet another handshake which will very definitively prevent you from sending anything if you don't receive the return traffic.
The story is different for UDP and raw IP protocols, but those have more limited use.
If access control is done in the application layer and it's a HTTP-based application, you might be able to bypass the check by forging the relevant HTTP headers (e.g. X-Forwarded-For, True-Client-IP, or X-Real-IP).
Your public IP address, if issued dynamically, cannot be switched until your ISP decides to. Static IP addresses assigned by your ISP can be switched, but your internet connection won't work unless the specific IP address has been assigned to you and in your IP range/scope.
Note
So, can you change your public IP address to a specific one?
Yes, and a working internet connection will reside only if you own that IP address and it is in your IP scope/range.
Thanks for covering the TCP-IP basics with us this morning.
I think we might be overcomplicating things. If it does not have to be a specific hard-coded value, just use another endpoint.
Of course, if you are a well-funded developer you can build a testbed independently of the internet (your own internet) and re-use public addresses. If you only need different values, you can have multiple IP addresses on the same host, but likely similar.
Consider VPN, VLAN, and VM's, even cloud. Also out of band such as GSM.
Are you filtering with IPTables/Apache2 directives or similar that rely upon any kind of reverse DNS? This will be extra work but bread and butter type work. It may be as simple as configuration management of dev and prod files.
