Вы можете, используя ч - заголовок
аргумент:
Вы могли высмеять свой 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:".
Ссылки:
Я думаю, что принятый ответ на самом деле не поможет вам полностью подделать ваш IP-адрес. Вы не сможете подделать исходный IP-адрес, если у вас нет доступа к маршрутизаторам, близким к целевой машине.
TCP работает по механизму трехстороннего подтверждения. Вы не сможете завершить это рукопожатие, поскольку ответ на рукопожатие от целевой машины пойдет на ваш поддельный IP-адрес, а не на ваш собственный (если, как было сказано ранее, вы не управляете его ближайшими маршрутизаторами и не перенаправляете ответ на себя).
P.S .: Возможно, вы сможете отправить UDP-сообщение, но я не пробовал.
Можно изменить исходный IP-адрес, если ваш локальный сетевой интерфейс имеет несколько IP-адресов.
Предположим, у вас есть сервер с двумя 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-адреса из записей DNS A
:
$ 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 3 -не удастся, как указано здесь .