LINUX.ORG.RU

Как они это сделали?

 , , ,


0

3

Сижу такой, работаю с корпоративным сервером (вебмордой, скажем на mysite.ru ) в Германии. Подключен корпоративный VPN поднятый на этом же самом сервер. DNSы в настройках сети 80.80.80.80, 8.8.8.8, 8.8.4.4…

Херак, вместо веб морды получаю новогоднюю открытку с детморозом от DOM.RU по url //info.ertelecom.ru/?campId=25370&machine=rostov&ourl=http%3A%2F%2Fmysite.ru%2F&u=98C91EFBB1C6ECDF15A1720642A91243&timestamp$c=1577556053&sid$c=cfad6e8262eb4dfe1feaf26dff059bd7

(нет смысла переходить по ссылки - там редирект)

Какого черта? Как это вообще возможно? Я не имею ввиду моральную сторону вопроса - понятно, провайдеры вообще совесть потеряли полностью, я имею ввиду техническую. Тех.поддержка пишет что-то вроде:

В любом случае Ваш пакет проходит через ядро нашей сети. На сервере произошло перенаправление на страницу с рекламой. Оборудование любого оператора связи просматривает запросы пользователя, например для блокировки запрещенных сайтов.

Скорее всего запросы к DNS у тебя не через корпоративный прокси идут. А там открытый протокол. Распарсили и вернули тебе нужный IP, потому что их DNS ближе. А потом дело техники. Ты переходишь по урлу, они урл сохраняют, хост тоже. Показывают открытку и редиректят куда надо.

turtle_bazon ★★★★★ ()
Ответ на: комментарий от anonymous

Вообще ничего не настраивал мудренно и прошарено - настроил подключение VPN (оно мне необходимо по работе, так на некоторых ресурсах у нас фильтрация по IP) из файла ovpn и указал в настройках network-manager’а DNS. Вот и все настройки которые я сделал.

Suntechnic ★★★★★ ()

Мы надеемся ты пошлешь им новогоднюю открытку с черкашом внутри? Музыкальную. Иначе какой смысл тебе помогать. Пообещай.

Аристоклий

anonymous ()
Ответ на: комментарий от Zhbert

Насколько я понимаю в данном случае пофиг. Потому что домен-то все равно виден в запросе. При включенном https они просто тебя назад вернуть не смогут на url и вернут просто на домен.

Suntechnic ★★★★★ ()
Ответ на: комментарий от imul

Как у тебя ресолвится домен с включенным впн и без него?

Боюсь я не понимаю вопроса.

Теперь уже никак. Но ты же можешь ещё поэкспериментировать.

Почему «Теперь»? А что произошло? Я же могу попробовать другой домен? Дело в том что на все запросы nslookup я вижу что отвечает мне 127.0.0.1 - а как мне увидеть какой ДНС мне прислал реальный ответ, самому кэширующему серверу на машине?

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

Боюсь я не понимаю вопроса.

dig domain.tld
например. Там чуть больше информации. При включенном и выключенном vpn.

Дело в том что на все запросы nslookup я вижу что отвечает мне 127.0.0.1

Посмотри какой процесс тебе отвечает на запросы
netstat -lnp | grep ':53'

imul ★★★★★ ()
Последнее исправление: imul (всего исправлений: 2)
Ответ на: комментарий от Suntechnic

Почему «Теперь»?

Потому что уже поздно что-то где-то искать.
А так ты можешь хотя бы tcpdump или wireshark запустить и смотреть, кто и что тебе возвращает.

как мне увидеть какой ДНС мне прислал реальный ответ, самому кэширующему серверу на машине?

Твой кеширующий сервер может огласить источник? Записать его в логи? Наверняка нет.

imul ★★★★★ ()

DNSы в настройках сети 80.80.80.80, 8.8.8.8, 8.8.4.4…

Пропингуй эти адреса. Пропингуй свой сервер с VPN. Пропингуй эти же адреса напрямую с сервера с VPN. Если time прямого пинга меньше чем время до VPN + время от VPN до DNS - то у тебя утечка DNS. Если время совсем маленькое, сравнимое с пингом до провайдерского шлюза - то твой провайдер перехватывает трафик на гуглоднс и подставляет свой DNS, где и подсовывает тебе страничку.

Если провайдер заруливает только 53 UDP то для надёжности повторить это с dig @DNS_IP somehost.com, смотреть строчку Query time

Stanson ★★★★★ ()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от anonymous

ДНС-утечка

Dns и http они точно перехватывают и подменяют. https тоже, но просто сбрасывают. Перенаправление на уровне http делают, вроде. На уровне dns сломали бы слишком многое, да и проверено, что с надежным dns перенаправление тоже происходит. Перенаправляют, кстати, только с корневой страницы, так что автоматику это практически не ломает.

boowai ★★★★ ()
Последнее исправление: boowai (всего исправлений: 2)
Ответ на: комментарий от imul

Если SNI включено. На этот сайт есть доступ из «дикого» интернета? Натрави на него SSL Server Test.

Да там нет SSL воообще. Это тестовая площадка.

dig domain.tld

например. Там чуть больше информации. При включенном и выключенном vpn. Без VPN: https://pastebin.com/Sp8rrZXQ C VPN: https://pastebin.com/j9WMZwdY

У тебя убунта вроде бы?

Она.

Если система с systemd то есть ещё полезная команда resolvectl status

Не настолько новый systemd, но

> systemd-resolve status
status: resolve call failed: No appropriate name servers or networks for name found

Suntechnic ★★★★★ ()

Это была подмена dns ответа.
Блокируй 53 порт на wan, ставь dns внутри локалки, получай dns записи на свой dns по шифрованным каналам.

anonymous ()
Ответ на: комментарий от Suntechnic

Получается, что нет подмены днс, постоянной во всяком случае.

У одного мобильного оператора заметил, ставишь на клиенте 8.8.8.8, а получаешь совсем другие DNS, принадлежащие оператору.

Jurik_Phys ★★★★★ ()

Подключен корпоративный VPN поднятый на этом же самом сервер.

на этом же самом сервер.

Причина в этом. До адреса твоего сервера трафик идет не через впн, а в открытую. Иначе нельзя, т.к. будет петля в правилах маршрутизации.

Как вариант, попробуй обращаться не на внешний адрес, а на внутренний адрес в тоннеле. Нужные адреса можно поменять через hosts.

unicorne ()
Ответ на: комментарий от Suntechnic

Она.

Написал бы какая. Может не пришлось бы в угадайку играть.
У тебя 127.0.0.1:53 кто слушает? systemd-resolved?
Какие настройки в /etc/systemd/resolved.conf?
Ссылка такая есть?
/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
Что внутри /etc/resolv.conf

DNS-over-TLS

я пользуюсь kresd

imul ★★★★★ ()
Ответ на: комментарий от imul

Написал бы какая. Может не пришлось бы в угадайку играть.

Дык дефолтная же - последняя LTS, т.е. 18.04

У тебя 127.0.0.1:53 кто слушает? systemd-resolved?

Ага - 821/systemd-resolve. Только 127.0.0.53:53. И UDP и TCP.

Какие настройки в /etc/systemd/resolved.conf?

Никаких - сплошные коммент. Секция [Resolve] выглядит так:

#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

Что внутри /etc/resolv.conf

nameserver 127.0.0.53
options edns0
Suntechnic ★★★★★ ()
Ответ на: комментарий от unicorne

Причина в этом. До адреса твоего сервера трафик идет не через впн, а в открытую. Иначе нельзя, т.к. будет петля в правилах маршрутизации.

Странно - я полагал что соединение идет через VPN все равно. Но черте возьми - ты прав!!! В $_SERVER REMOTE_ADDR - ip провайдера, а не VPN!

И нет HTTPS там. Вот оно!

Как вариант, попробуй обращаться не на внешний адрес, а на внутренний адрес в тоннеле. Нужные адреса можно поменять через hosts.

Разумно. Или VPN перенести на другой сервак, как уже давно думаю...

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

Никаких - сплошные коммент.

Значит используются захаркоженые настройки. И наверняка это 8.8.8.8. Который перехватывается провайдером.

Секция [Resolve] выглядит так:

Тогда ставь kresd, вешай его куда-нибудь на 127.0.0.2:53, и
DNS=127.0.0.2
FallbackDNS=127.0.0.2
в /etc/systemd/resolved.conf
Будет у тебя и dns-over-tls и совместимость с nspawn (если используешь) и всяким добром, которое хочет systemd-resolved.

imul ★★★★★ ()