Respostas:
Você pode usar o -H/--header
argumento:
Você pode falsificar seu endereço IP:
curl --header "X-Forwarded-For: 192.168.0.2" http://example.com
Exemplo:
cliente
$ curl http://webhost.co.uk
host da web
$ 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"
cliente com endereço IP alterado
$ curl --header "X-Forwarded-For: 192.168.0.99" http://webhost.co.uk
host da web
$ 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"
homem enrolar
-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:".
Referências:
Eu acho que a resposta aceita não vai realmente ajudar você a falsificar seu IP todo o caminho. Você realmente não pode falsificar seu IP de origem, a menos que tenha acesso a roteadores próximos à máquina de destino.
O TCP funciona em um mecanismo de handshake de três vias. Você não será capaz de concluir este handshake, pois a resposta do handshake da máquina de destino irá para o seu IP falsificado e não o seu próprio (a menos que, como dito anteriormente, você controle os roteadores próximos e redirecione a resposta para si mesmo).
PS: Você pode enviar uma mensagem UDP, mas eu não tentei.
curl
, suponho que eles estejam tentando acessar algum recurso HTTP. HTTP sobre UDP não é algo que curl
suporte o AFAIK nem é algo além do experimental neste momento.
É possível alterar o endereço IP de origem, se a interface de rede local tiver vários endereços IP.
Suponha que você tenha um servidor com 2 endereços IP 1.1.1.10
e 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
Você pode verificar seu endereço IP público atual com o incrível serviço web ifconfig.co :
$ curl -4 ifconfig.co
1.1.1.10
Para acessar o serviço da web ifconfig.co usando o outro endereço IP ( 2.2.2.20
), você pode criar uma rota com base no endereço IP do servidor de destino. Use dig para encontrar os endereços IP de destino dos A
registros DNS :
$ dig ifconfig.co
...
ifconfig.co. 39 IN A 104.28.18.94
ifconfig.co. 39 IN A 104.28.19.94
...
Agora adicione rotas personalizadas para estes endereços IP:
$ 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
Executando curl novamente, você vê que está usando o outro endereço IP de origem:
$ curl -4 ifconfig.co
2.2.2.20
Além disso, suas informações de roteamento são atualizadas:
$ 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
Nota: isso funciona apenas se o endereço IP de origem puder ser resolvido no servidor, caso contrário, o handshake de 3 vias do TCP falhará, conforme indicado aqui .