Wysyłanie żądania CURL z niestandardowym adresem IP

Czy nie powinno to być możliwe? Załóżmy, że nie potrzebuję odpowiedzi, chcę tylko wysłać zapytanie. Czy nie powinniśmy być w stanie zmieniać nagłówków tcp / ip, ponieważ nasz komputer je wysyła? Prawdopodobnie czegoś mi brakuje, po prostu bardzo ciekawy, dowiadując się o tym na uniwersytecie.

Możesz użyć -H/--headerargumentu:

Możesz sfałszować swój adres IP:

curl --header "X-Forwarded-For: 192.168.0.2" http://example.com

Przykład:
klient

$ curl http://webhost.co.uk  

Host sieciowy

$ 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"

klient ze zmienionym adresem IP

$ curl --header "X-Forwarded-For: 192.168.0.99" http://webhost.co.uk   

Host sieciowy

$ 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"  

zwinięty mężczyzna

 -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:".

Bibliografia:

Modify_method_and_headers

Myślę, że zaakceptowana odpowiedź tak naprawdę nie pomoże ci sfałszować twojego adresu IP przez całą drogę. Nie możesz tak naprawdę sfałszować źródłowego adresu IP, chyba że masz dostęp do routerów w pobliżu komputera docelowego.

TCP działa na 3-kierunkowym mechanizmie uzgadniania. Nie będziesz w stanie ukończyć tego uzgadniania, ponieważ odpowiedź uścisku dłoni z maszyny docelowej przejdzie do twojego sfałszowanego adresu IP, a nie twojego (chyba że, jak powiedziano wcześniej, kontrolujesz jego pobliskie routery i przekierujesz odpowiedź do siebie).

PS: Być może możesz wysłać wiadomość UDP, ale ja tego nie próbowałem.

Można zmienić źródłowy adres IP, jeśli lokalny interfejs sieciowy ma wiele adresów IP.

Załóżmy, że masz serwer, który ma 2 adresy IP 1.1.1.10i 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

Możesz zweryfikować swój obecny publiczny adres IP za pomocą niesamowitej usługi internetowej ifconfig.co :

$ curl -4 ifconfig.co
1.1.1.10

Aby uzyskać dostęp do usługi internetowej ifconfig.co przy użyciu drugiego adresu IP ( 2.2.2.20), możesz utworzyć trasę na podstawie adresu IP serwera docelowego. Użyj dig, aby znaleźć docelowe adresy IP z Arekordów DNS :

$ dig ifconfig.co
...
ifconfig.co.            39      IN      A       104.28.18.94
ifconfig.co.            39      IN      A       104.28.19.94
...

Teraz dodaj niestandardowe trasy dla tych adresów 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

Po ponownym uruchomieniu curl widać, że używasz innego źródłowego adresu IP:

$ curl -4 ifconfig.co
2.2.2.20

Ponadto informacje o routingu są aktualizowane:

$ 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

Uwaga: działa to tylko wtedy, gdy źródłowy adres IP można rozwiązać na serwerze, w przeciwnym razie potrójny uścisk protokołu TCP nie powiedzie się, jak wskazano tutaj .