Sending CURL request with custom IP
You can using the -H/--header
argument:
You could spoof your ip address:
curl --header "X-Forwarded-For: 192.168.0.2" http://example.com
Example:
client
$ curl http://webhost.co.uk
web host
$ tailf access.log | grep 192.168.0.54
192.168.0.54 - - [10/Nov/2014:15:56:09 +0000] "GET / HTTP/1.1" 200 14328 "-"
"curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3
libidn/1.18 libssh2/1.4.2"
client with ip address changed
$ curl --header "X-Forwarded-For: 192.168.0.99" http://webhost.co.uk
web host
$ tailf access.log | grep 192.168.0.99
192.168.0.99 - - [10/Nov/2014:15:56:43 +0000] "GET / HTTP/1.1" 200
14328 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0
zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
man curl
-H/--header <header>
(HTTP) Extra header to use when getting a web page. You may
specify any number of extra headers. Note that if you should add
a custom header that has the same name as one of the internal
ones curl would use, your externally set header will be used
instead of the internal one. This allows you to make even
trickier stuff than curl would normally do. You should not
replace internally set headers without knowing perfectly well
what you’re doing. Remove an internal header by giving a
replacement without content on the right side of the colon,
as in: -H "Host:".
References:
Modify_method_and_headers
I think the accepted answer will not really help you spoof your IP all the way. You can't really spoof your source IP unless you have access to routers close to the target machine.
TCP works on a 3-way handshake mechanism. You'll not be able to complete this handshake as the handshake response from the target machine will go to your spoofed IP and not your own (unless, as said before, you control his nearby routers and redirect the response towards yourself).
P.S.: You might be able to send a UDP message, but I haven't tried it.
It is possible to change the source IP address, if your local network interface has multiple IP addresses.
Suppose you have a server which has 2 IP addresses, 1.1.1.10
and 2.2.2.20
:
$ ip route
default via 1.1.1.193 dev eth0
1.1.1.192/27 via 1.1.1.193 dev eth0
1.1.1.192/27 dev eth0 proto kernel scope link src 1.1.1.10
2.2.2.20 via 2.2.2.20 dev eth0 scope link
You can verify your current public IP address with the awesome ifconfig.co web service:
$ curl -4 ifconfig.co
1.1.1.10
To access the ifconfig.co web service using the other IP address (2.2.2.20
), you can create a route based on the target server's IP address. Use dig to find the target IP addresses from the DNS A
records:
$ dig ifconfig.co
...
ifconfig.co. 39 IN A 104.28.18.94
ifconfig.co. 39 IN A 104.28.19.94
...
Now add custom routes for these IP addresses:
$ ip route add 104.28.18.94/32 via 1.1.1.193 dev eth0 src 2.2.2.20
$ ip route add 104.28.19.94/32 via 1.1.1.193 dev eth0 src 2.2.2.20
Running curl again, you see that you are using the other source IP address:
$ curl -4 ifconfig.co
2.2.2.20
Also, your routing information is updated:
$ ip route
default via 1.1.1.193 dev eth0
1.1.1.192/27 via 1.1.1.193 dev eth0
1.1.1.192/27 dev eth0 proto kernel scope link src 1.1.1.10
2.2.2.20 via 2.2.2.20 dev eth0 scope link
104.28.18.94 via 1.1.1.193 dev eth0 src 2.2.2.20
104.28.19.94 via 1.1.1.193 dev eth0 src 2.2.2.20
Note: this only works if the source IP address can be resolved to your server, otherwise the TCP 3-way handshake will fail, as pointed out here.