Comments 46
UFO just landed and posted this here
Ну что у вас показывает? Адреса локальных интерфейсов, не важно за натом они или нет.
0
UFO just landed and posted this here
Ну если нет НАТ, то и так виден ip при посещении сайта. Прелесть в том, что скрипт позволяет увидеть ВСЕ интерфейсы в системе. Так, например, если VPN поверх интернета, будет видно оба айпишника.
+2
Еще одно подтверждение того, что JS — зло
-12
Воу-воу, вот это поворот!
Реально палит IP при работе через VPN.
Реально палит IP при работе через VPN.
+8
Ничего критичного при работе через VPN не палит. Вот что у меня показывает при подключении через ruvpn.net:
37.202.59.215 — Публичный IP шлюза
10.0.0.203 — Мой IP в локальной сети
10.172.76.5 — IP в сети VPN
173.194.98.150 — гугловский DNS
Моего внешнего IP, по которому можно вычислить местоположение, нет.
Так что отставить панику! :-)
37.202.59.215 — Публичный IP шлюза
10.0.0.203 — Мой IP в локальной сети
10.172.76.5 — IP в сети VPN
173.194.98.150 — гугловский DNS
Моего внешнего IP, по которому можно вычислить местоположение, нет.
Так что отставить панику! :-)
+3
А вот еще, к примеру, айпишники с которых вы в скайп заходите:
remote: 2.150.21.98 local: 10.102.236.5
remote: 84.208.74.209 local: 10.0.0.203
Виден один и тот же локальный 10.0.0.203. Довольно редкий.
remote: 2.150.21.98 local: 10.102.236.5
remote: 84.208.74.209 local: 10.0.0.203
Виден один и тот же локальный 10.0.0.203. Довольно редкий.
+1
А если у вас не было бы NAT (ну, предположим, 1 компьютер всего), то был бы виден ваш прямой IP.
+1
ИМХО, в сочетании как раз с локальным NAT бесполезен — ну будет виден адрес вида 192.168.1.* и что?
+2
Анонимность страдает, только если юзер сидит не за NAT, и при этом пользуется прокси-сервером или анонимайзером.
0
Не только. Еще в случае, если есть уникальный локальный адрес, как например habrahabr.ru/post/215071/#comment_7386869 по которому можно трекать при смене внешних адресов.
0
Принцип работы до конца не понял, но впечаление производит!
Правда стоит заметить, что если сидишь за двойным NAT-ом (первый провайдерский, второй домашний), то определится IP последнего, который по сути — бесполезен.
Правда стоит заметить, что если сидишь за двойным NAT-ом (первый провайдерский, второй домашний), то определится IP последнего, который по сути — бесполезен.
+2
Помню, раньше под IE использовался ActiveX, который отображал содержимое локальных дисков, чем то напомнило.
0
Хаха, умно!
Похоже я был прав, когда решил ходить в интернеты из под браузера, засунутого в виртуалку (виртуальная карта в режиме NAT), а VPN поднимать на хост-машине. Спасибо VMWare за наше счастливое детство.
Похоже я был прав, когда решил ходить в интернеты из под браузера, засунутого в виртуалку (виртуальная карта в режиме NAT), а VPN поднимать на хост-машине. Спасибо VMWare за наше счастливое детство.
+4
Firefox -> about:config -> media.peerconnection.enabled = false
+8
Ну вот посмотрел я, под виндой, показывает внешний IPшник виртуалки до которой браузер ходит надев носки(socks5), внутренние 192.168.x.x один выданный точкой доступа и парочка от VMWare, а резолверы вообще чудесные IPv6 и все такое. Как-то не помогает информация вычислить по IP и набить лицо.
-3
UFO just landed and posted this here
По моему скромному мнению, есть еще 1001 (неизвестная мне и многим другим) уловка, позволяющая «вытащить» через браузер инфу о разных «палевных» аспектах локального окружения.
Поэтому VMware, в качестве guestOS ставим Lubuntu, все любимые браузеры (а заодно TOR/TBB) ставим на guestOS'е, сетевую карту VMWare — в NAT-режим, VPN поднимаем на hostOS.
И ходим в эти ваши интернеты только из-под guestOS. Будет небольшой гемор с порт-форвардингом (решаемый), но в остальном все очень даже симпатично получается.
Даже если какая-то дрянь «прогрызет» различные защиты браузера, ей еще надо будет из-под VMWare выкарабкаться, а это уже не вполне заурядное (хотя и не невозможное) мероприятие.
Поэтому VMware, в качестве guestOS ставим Lubuntu, все любимые браузеры (а заодно TOR/TBB) ставим на guestOS'е, сетевую карту VMWare — в NAT-режим, VPN поднимаем на hostOS.
И ходим в эти ваши интернеты только из-под guestOS. Будет небольшой гемор с порт-форвардингом (решаемый), но в остальном все очень даже симпатично получается.
Даже если какая-то дрянь «прогрызет» различные защиты браузера, ей еще надо будет из-под VMWare выкарабкаться, а это уже не вполне заурядное (хотя и не невозможное) мероприятие.
+1
UFO just landed and posted this here
С каких пор через HTTP-прокси можно пустить DNS-резолвер?
0
UFO just landed and posted this here
Изначально. При использовании только HTTP-протокола прокси передаётся нужный домен в заголовке Host. При использовании HTTPS-прокси (через который по факту работает всё кроме обычного HTTP) домен передаётся при использовании CONNECT. То есть, если компьютер знает адрес HTTPS-прокси, то ему для общения с сетью не нужен доступ к DNS. nslookup работать не будет, но это не критично.
+3
Этой новости полгода. https://hacking.ventures/local-ip-discovery-with-html5-webrtc-security-and-privacy-risk/
+2
Ухты, можно и сеть посканировать dl.dropboxusercontent.com/u/1878671/enumhosts.html
+3
а ещё автор забыл упомянуть что скрипт из его фиддла просто исходник страницы net.ipcalf.com/
ссылка на неё там же в этом блоге
ссылка на неё там же в этом блоге
0
Про адреса резолверов на стороне клиента: мой локальный IP — 192.168.77.2
1. на клиенте, с которого хожу:
cat /etc/resolv.conf
# Generated by NetworkManager
domain i-hn.loc
search i-hn.loc
nameserver 192.168.77.1
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
2. на маршрутизаторе:
Яндекс.DNS, безопасный
Плюс, вбиты для IPv6 only — гугловские IP-адреса серверов DNS, которые видны и в п.1.
1. на клиенте, с которого хожу:
cat /etc/resolv.conf
# Generated by NetworkManager
domain i-hn.loc
search i-hn.loc
nameserver 192.168.77.1
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
2. на маршрутизаторе:
Яндекс.DNS, безопасный
Плюс, вбиты для IPv6 only — гугловские IP-адреса серверов DNS, которые видны и в п.1.
0
zhovner.com/jsdetector/test — лихо все друг-друга на одной странице попалили ;)
0
Ага, немного напоминает злую шутку про «программу из одной строчки на Perl»
0
Вы не поняли, те кто перешел по ссылке туда не попадают. Там же виден реферер. Это только те, кто не сменив name=test вставили код себе на сайты.
0
Я таки уже понял :). Как раз этап «бездумно скопипастили» и объединяет ситуацию с той перловой историей.
Кстати результаты довольно любопытные, имхо.
Кстати результаты довольно любопытные, имхо.
0
тр768
0
Извиняюсь, что поднимаю древнюю тему, но очень надо, а в другом месте что-то найти не могу. Вопрос такой: в результате работы снифера в браузер выводится информация о «ssl_cipher» и «ssl_proto». Подскажите, плиз, можно ли эту информацию получить средствами php и, если можно, то как?
0
Вы что конкретно имеет в виду? Вот эту страницу? zhovner.com/jsdetector
Она давно возвращает ошибку 500. Просто у меня так оформлена страница ошибки. Эти данные выплевывает nginx через ssi
Это встроенные переменные nginx nginx.org/en/docs/varindex.html
Их можно прокинуть в бекенд.
Она давно возвращает ошибку 500. Просто у меня так оформлена страница ошибки. Эти данные выплевывает nginx через ssi
<!--# if expr="$https" -->
-------------
https: <!--# echo var="https" -->
<!--# endif -->
<!--# if expr="$spdy" -->
spdy_ver: <!--# echo var="spdy" -->
<!--# endif -->
<!--# if expr="$ssl_cipher" -->
ssl_cipher: <!--# echo var="ssl_cipher" -->
<!--# endif -->
<!--# if expr="$ssl_protocol" -->
ssl_proto: <!--# echo var="ssl_protocol" -->
-------------
<!--# endif -->
Это встроенные переменные nginx nginx.org/en/docs/varindex.html
Их можно прокинуть в бекенд.
0
Sign up to leave a comment.
Определение локальных IP-адресов через WebRTC