Отправка запроса CURL с пользовательским IP

Разве это не возможно? Давайте предположим, что мне не нужен ответ, я просто хочу отправить запрос. Разве мы не должны иметь возможность изменять заголовки tcp / ip, потому что наш компьютер отправляет их? Я, наверное, что-то упускаю, просто очень любопытно, узнавая об этом в универе.

Вы можете использовать -H/--headerаргумент:

Вы можете подделать свой IP-адрес:

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

Пример:
клиент

$ curl http://webhost.co.uk  

веб-хостинг

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

клиент с измененным IP-адресом

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

веб-хостинг

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

локон

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

Ссылки:

Modify_method_and_headers

Я думаю, что принятый ответ не поможет вам полностью подделать ваш IP. Вы действительно не сможете подделать свой исходный IP, если у вас нет доступа к маршрутизаторам, расположенным рядом с целевой машиной.

TCP работает на 3-х стороннем механизме рукопожатия. Вы не сможете завершить это рукопожатие, так как ответ рукопожатия от целевой машины перейдет на ваш поддельный IP-адрес, а не на ваш собственный (если, как сказано выше, вы не контролируете его соседние маршрутизаторы и не перенаправляете ответ на себя).

PS: Вы можете отправить UDP-сообщение, но я не пробовал.

Можно изменить исходный IP-адрес, если ваш локальный сетевой интерфейс имеет несколько IP-адресов.

Предположим, у вас есть сервер, который имеет 2 IP-адреса, 1.1.1.10и 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

Вы можете проверить свой текущий общедоступный IP-адрес с помощью потрясающего веб-сервиса ifconfig.co :

$ curl -4 ifconfig.co
1.1.1.10

Чтобы получить доступ к веб-службе ifconfig.co с помощью другого IP-адреса ( 2.2.2.20), вы можете создать маршрут на основе IP-адреса целевого сервера. Используйте dig, чтобы найти целевые IP-адреса из Aзаписей DNS :

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

Теперь добавьте пользовательские маршруты для этих 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

Запустив curl снова, вы увидите, что используете другой IP-адрес источника:

$ curl -4 ifconfig.co
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
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

Примечание: это работает только в том случае, если исходный IP-адрес может быть разрешен на вашем сервере, в противном случае трехстороннее рукопожатие TCP не будет выполнено, как указано здесь .