Предыстория
После принятия всем известных законов в нашем Отечестве, я выхожу в инет через западный VPN-сервер.
Вчера, по причине некоторых проблем с основным провайдером, я временно переключился на провайдера под названием Дом.ру.
Сегодня, я лазил в гугле и искал некоторую информацию по уходу за кактусами. Одна из ссылок привела меня на сайт psy*****s.org. Там, как выяснилось, вовсю торгуют «веществами». И кактусы тоже продают, правда, довольно специфические.
Но, об этом я узнал позже, а сначала, я был шокирован показом мне странички «доступ к данному ресурсу был заблокирован...» с логотипом Дом.РУ.
С тех пор, как купил ВПН, я такие страницы не наблюдал вообще, по понятной причине.
Расследование
Для начала, я решил проверить, а работает ли мой VPN?
Проверил самым тупым способом — зашёл на сайт my-ip.ru. Увидел свой свой голландский IP, следовательно, c VPN всё в порядке.
Начал разбираться дальше. Мысль, что Дом.РУ каким-то образом может расковырять ssl, я отмёл сразу.
Проверил маршрут при помощи traceroute. Маршрут до сайта psy*****s.org ведёт, как положено, через мой VPN-сервер, а потом приводит на ДОМРУшную заглушку с адресом 92.255.241.100.
Остаётся ДНС. Но, на моём домашнем сервере настроен кэширующий ДНС-сервер bind, и в качестве forwarders указаны гугловские 8.8.8.8 и 8.8.4.4. Есть только одно «но»: доступ к этим серверам идёт по открытому каналу.
Проверяем:
ksh@master:~$ nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> psy*****s.org
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: psy*****s.org
Address: 92.255.241.100
Теперь, заворачиваем трафик до внешних ДНС-серверов через VPN и проверяем снова:
ksh@master:~$ nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> psy*****s.org
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: psy*****s.org
Address: 37.252.124.170
Ситуация понятна.
Морально-этическую и законную стороны действий провайдера, думаю, обсуждать смысла нет. По сути, речь идёт об атаке MITM.
Что делать?
Использовать DNSSEC — не выход, хотя, публичные сервера от Google и поддерживают этот протокол. Да, фальшивые ответы не пройдут валидацию, и в результате у вас попросту отвалится ДНС.
Выход один — любым способом шифровать трафик до публичных ДНС-серверов.
Интересна, также, позиция Google по этому вопросу.
Комментарии (148)
schors
28.01.2017 20:22DNSSEC надо везде. Чтобы с ним было сложно бороться. Вообще это ФАС — навязанная услуга. Да ещё и без соглашения о качестве услуги. Это ведь услуга «наш DNS»
Archon
29.01.2017 07:28+1Чем он поможет? По факту, у вас просто отвалится DNS, и вместо одного неработающего сайта перестанет работать всё целиком. И ничего вы провайдеру не докажете, они будут советовать поменять DNS на указанный в договоре или выдаваемый по DHCP.
Shvedov
01.02.2017 05:05+1Ага, тут r01 какую-то трубу у себя шатал, так у нас DNS половину суток радостно простаивали.
schors
01.02.2017 08:29А можно поподробнее про r01? Мне как DNSSEC евангелисту интересно. Третьего дня они отказались ставить в планы внедрение передачи DS-записей в реестр RU/РФ. Так что не знаю что за трубу они шатал.
zuborg
28.01.2017 20:27+1Ставьте себе резолвер локально, а трафик через VPN пусть идет весь (ну кроме торрентов, может, и то не факт).
Nord001
28.01.2017 21:01+6ужасная компания этот дом.ру) подключиться легко а отключиться уже в разы сложнее, а если лично не отказываться от договора — будете ещё и должны.
ivan386
28.01.2017 22:32+5Это они у Ростелекома такую фишку взяли чтоль? Недавно от него отключался ещё и денег должен остался. Знакомые не хотят больше к нему подключаться из за этого. Подключать к тебе приедут всё сделают а отключаться только через офис и очередь на час-два. Ещё и кредитная система. Инетом можешь не пользоваться а счёт в минус уходит. Приостановка интрнета тоже платная. Бесплатная только один месяц в год. Да ещё отказали делать приостановку если в этом же месяце инет включил. ФАС на них нет!
vicont_freetime
31.01.2017 21:36Кредитная система, ИМХО, — один из плюсов РТК. Странно, что подключили новому клиенту. Обычно всех новичков они правдами-неправдами стремятся загнать на авансовую, даже премию выдают подключающему, если он подписал клиента именно на авансовую систему расчётов.
ivan386
31.01.2017 22:54У меня была вроде как авансовая несколько лет. Мне его отключали из за нехватки рубля на счету. Потом они самостоятельно видимо включили кредитную.
Любые кредиты плюсом не считаю. Это вытягивание денег у клиента. У многих провайдеров есть "обещанный платёж" который позволяет включить интернет на некоторое время в случае отсутствия денег на счету.
buggykey
29.01.2017 14:01+3Так и есть, в свое время (лет 5 с лишним назад) переключился с купленного Билайном провайдера к InterZet-у — он тогда как раз стал очень приличным, раньше это вообще были «цыгане в проводах», грешили даже тем, что резали витую пару у конкурентов. До начала прошлого года все было замечательно, пока InterZet не был куплен Дом.RU. Мало того, что поломали приоритезацию типов трафика, что проявилось в лагах на моем игровом сервере при малейшем шорохе в торрентах, так еще и периодически стали демонстрировать свою рекламную страничку при попытке открытия произвольного адреса в браузере. Т. е. открываешь ты, например, google, а на экране — «Подключись к нам и пользуйся IPTV полгода бесплатно». Жаловались на нее, что если не заплатить за следующий месяц — инета не будет, но и деньги со счета в минус будут уходить, т. е. пока не напишешь заявление на отключение и не оплатишь — будешь должником. А потом сам, лично видел такой пункт у них в договоре.
instalator
30.01.2017 10:48ТТК аналогично
cpcat
31.01.2017 12:01ТТК списывает ежедневную оплату в полночь, как только деньги кончаются — услуга прекращается, никакого минуса.
Vindicar
28.01.2017 21:06+7OpenVPN умеет посылать настройки DNS клиентам. Таким образом, если поднять свой DNS-сервер (тот же bind или dnsmasq), и настроить его на ответы внутрь VPN, то можно будет пользоваться.
У меня настройка такая:
— внутрь VPN смотрят bind, lighttpd и privoxy
— VPN не прописывается как шлюз по умолчанию.
— клиенты цепляются к VPN всегда, и настроены использовать bind как первичный DNS-сервер, и гуглоднс — как вторичный.
— браузеры настроены на использование proxy autoconfig file, который отдаётся lighttpd на сервере.
— proxy autoconfig файл генерируется по крону и направляет запросы для сайтов из черного списка на privoxy (черный список беру с antizapret). Остальные запросы идут напрямую.
Таким образом, VPN используется выборочно, для DNS-запросов и для загрузки сайтов из чёрного списка, что очень удобно.
Минус такого подхода — необходимость полноценного доступа к VPN серверу (VPN-провайдеры не подойдут), и наличие знаний для настройки всего этого хозяйства.
В качестве апгрейда я накатил openvpn клиент на роутер, открыв всем устройствам в домашней сети доступ в VPN, и настроив dnsmasq на роутере на работу с bind. Так что любое устройство с минимальными настройками может пользоваться туннелем.
Envek
28.01.2017 22:02+6Запрашиваю статью-мануал по настройке такой конфигурации. Хочется иметь почти всегда включенный VPN специально для веб-морды рутрекера. А то я себе OpenVPN по мануалу от Digita Ocean быстренько поднял, но во первых ничего не понял :-), а во вторых включать его на время поиска торрента и выключать на время скачивания — неудобно.
ivan386
28.01.2017 22:41Ну если вам чисто для рутрекера нужно то можно и по ipv6 на него ходить напрямую. Прописав его в hosts.
Envek
29.01.2017 02:19Увы, IPv6 у моего провайдера нет (я всё скучаю по Онлайму, у которого он неофициально был, но мой нынешний дом они подключать не спешат, хотя «холодный обзвон» делают каждый месяц и каждый раз я им говорю, что я к ним хочу), а с 6to4-тоннелями я поигрался и отключил — то youtube нафиг посылает (нельзя смотреть российские ролики, если у тебя тоннель в Германию ведёт) то ещё что-нибудь не открывается. Поэтому «выборочный VPN» был бы лучшим решением.
navion
29.01.2017 04:11+5Именно для рутрекера есть почти официальный плагин к браузеру, а есть более универсальный для всей запрещёнки от ПростоVPN.
NickKolok
31.01.2017 13:34К слову о плагинах: а есть ли OpenSource-решение, которое отправляло бы через TOR все неудачные запросы, а остальные оставляло как есть? Желательно в виде плагина для лисы или чугуния.
perlestius
30.01.2017 10:48Тоже ушел от Онлайма из-за переезда. Они, кстати, белые адреса выдавали, правда, динамические, статика — за доп. плату, но выручал DynDNS.
По поводу рутрекера и ему подобным — выручает Opera VPN
Vindicar
29.01.2017 13:09Как выше написал navion, именно так работает ProstoVPN. Насчёт статьи-руководства… трудно сказать о чём тут писать. Мануалов по настройке OpenVPN выше крыши, фишка с роутером едва ли будет полезна — у меня DIR-320 с прошивкой Vampik'а (продолжение Олеговской), а не OpenWRT/DD-WRT… а кроме этого и писать-то особо нечего. Как PAC-файл генерировать, что ли? =)
rogoz
29.01.2017 18:08Есть ещё интересная штука stunnel.
Преимущество (в некоторых случаях), что работает через TLS, не надо держать постоянное соединение, keepalive пинги.
Ну и ща tcpdump'ом посмотрел, firefox не отправляет открытый DNS запрос, когда сайт указан в PAC-файле для открытия через SOCKS stunnel'а. А на VPS'ке даже днс-сервера нет, просто указан внешний днс в resolv.conf.
Ну и указать флажок нужно
POS_troi
28.01.2017 21:23+6> По сути, речь идёт об атаке MITM.
По сути провайдер вообще занимается постоянным MITM, уж позиция у него такая «по середине».
Да и атакой это назвать доволи сложно.
Ничего тут не поделаешь — есть закон и пров должен его выполнять, подмена днс-ов это вообще самое безобидное чт они могли сделать. Завтра выпустят новый закон и заставят всех ставить «государственный SSL сертификат» и будут смотреть весь трафик — вот тогда и нужно будет волноваться а сейчас ниочем пост :)schors
28.01.2017 22:54В законе ничего не ни про MITM, ни про DNS. Вот не надо тут.
degorov
29.01.2017 09:17+3В самом законе технических терминов в любом случае никогда не будет. Провайдерам РКН рассылает инструкцию с рекомендациями как и что блокировать, про подмену DNS там сказано прямо. Без MITM выполнение закона в принципе невозможно, вопрос только в том, на каком уровне эту самую MITM делать.
schors
29.01.2017 13:03-51. Инструкцией РКН можно подтереться — она не имеет юридической силы. Судить будут не по инструкции.
2. Невозможно. Ну что же делать. Им это еще в 2011 говорили
TimsTims
30.01.2017 10:59> 1. Инструкцией РКН можно подтереться — она не имеет юридической силы.
На самом деле вполне себе имеют.
Взять аналог: ~2008й год, письмо-рекомендация Центрального Банка об учёте кредитов. Так вот, там было сказано, что для ведения бухгалтерских(считай банковских) счетов кредитов, банк может взимать за это плату. И вот так, до 2009 года все банки взимали комиссию за выдачу кредита, и за «ежемесячное обслуживание кредита». Поэтому ставки по кредитам были довольно низкими, но за счёт комиссий доходность банка повышалась. На банка подавали в суды, а они защищались (причём довольно успешно до 2010), прикрываясь такой «рекомендацией» ЦБ. Поэтому не стоит недооценивать силу «рекомендаций» компетентного органа.schors
30.01.2017 11:04-2Погодь. 1. То что у нас нет судебной системы, это отдельный вопрос. 2. Есть закон о Центробанке. О РКН такого закона нет. 3. Все нормативы так или иначе имеют некие признаки, которых не имеет вот эта июньская или июльская рекомендация. Регистрация там, публикация в СМИ.
schors
30.01.2017 11:05-1Самое интересное, что МинКомСвязи со мной согласен. Хачатуровразрешил подтираться рекомендациями РКН,
degorov
30.01.2017 21:07-1Какие ещё признаки оно должно иметь? :) Это официальное распоряжение РосКомНадзора под №8 от 07.07.2016 за подписью господина Жарова непосредственно.
schors
30.01.2017 23:40-2Что такое «официальное распоряжение»? Вот этот мой комментарий — официальное распоряжение или нет? Признаки законов, подзаконных актов и нормативов устанавливаются Конституцией и законодательством. У этой бумажки их нет. Есть текст за подписью Жарова, не несущий правовых последствий. Это примерно как письмо МинФина — рассказ на тему ни к чему не обязывающий.
andreyle
29.01.2017 19:08+3Уже делают MitM. Как минимум мой магистральный провайдер. И как заблокировать его сертификат я не знаю :(
navion
30.01.2017 15:08Можно внести сертификат в недоверенные, тогда будет показывать заглушку с кодом ERR_CERT_REVOKED и без кнопки пропуска.
navion
30.01.2017 20:08Оказывается в NSS нет хранилища для недоверенных сертификатов, но можете попробовать добавить ТТКшный сертификат в базу с флагом prohibited:
certutil -A -n "TTC BAD CA" -t "p,p,p" -d "~/.pki/nssdb" -i BAD_CA.crtnavion
30.01.2017 20:16Точнее в хранилище есть недоверенные сертификаты, но интерфейс этого не показывает.
Labunsky
29.01.2017 00:02+4Завтра выпустят новый закон и заставят всех ставить «государственный SSL сертификат» и будут смотреть весь трафик — вот тогда и нужно будет волноваться
Волноваться, все-таки, надо заранее. Пост-фактум будет поздноватоnApoBo3
29.01.2017 11:55+5Волноваться уже поздно.
Mechanist
29.01.2017 14:01+2Так пост-фактум уже. Как то никто про это не пишет, ни здесь, ни на GT, но уже осенью 2016-го провайдеры ЭДО (электронного документооборота, причём не только с ФНС и прочими госструктурами, но и просто между контрагентами) сменили свои CA-ключи на подчинённые некоему CA от МинСвязи.
Последствия, думаю, всем понятны.
И не поставить нельзя — обмен нужен.kirillaristov
31.01.2017 21:36Это сделано для того, чтобы использовать одну ЭП на всех площадках, а не как до середины 16 года — тогда надо было иметь столько ЭП, сколько посещаешь площадок. Однако это изменение еще не вошло в массы — до сих пор пытаются продавать ЭП под конкретные площадки.
mikeus
29.01.2017 14:10+4Я не очень понимаю, честно говоря: вот подмену записей при запросах на их ДНС-сервера провайдеры могут спокойно делать — это их сервера и что там они у себя пропишут для ответов клиентским запросам это их дело.
Но из статьи не совсем ясно — они подменяют ответ от стороннего (гугловского) ДНС-сервера что-ли? На сколько мне известно по закону провайдер не имеет право менять что-либо в трафике клиента. Либо он пропускает трафик к узлу / от узла как есть, либо законно блокирует подключение к узлу. Промежуточного варианта не предусмотренно и это все противоречит закону. Запросы клиетнов к узлам сети и все ответы на них должны передаваться по сетям связи в немодифицированном виде.Shaltay
29.01.2017 14:11+2Но из статьи не совсем ясно — они подменяют ответ от стороннего (гугловского) ДНС-сервера что-ли?
Да, так и есть. А в каком моменте это не ясно?mikeus
29.01.2017 15:14А вы не проверяли может они вообще весь клиентский трафик на 53 порт на свои DNS заворачивают?
p00h
29.01.2017 19:00Челябинск. Именно так и делают. Подозреваю, что в других регионах совершенно также
degorov
29.01.2017 14:48На многих сайтах закон требует ограничить доступ только к отдельным страницам. Как Вы предлагаете это делать, не вмешиваясь в http-трафик клиентов?
mikeus
29.01.2017 15:12Либо провайдер пропускает трафик к узлу / от узла как есть, либо законно блокирует подключение к узлу. Когда он блокирует доступ к отдельной html-странице он просто не пропускает её к вам, заменяя на соответствующее уведомление. Предствьте себе, если провайдер вдруг начнет пропускать некоторые страницы, но фильтровать/подменять какую-либо содержащуюся в них информацию или данные. Это мне кажется мягко говоря будет очень не хорошо и насколько я понимаю не законно. Точно так же и с запросами не по HTTP.
degorov
29.01.2017 15:22Что значит «просто не пропускает её к вам, заменяя на соответствующее уведомление»? :)
Чтобы заблокировать отдельную страницу сайта нужно направить весь http-шный трафик, который идёт на ip-адреса этого сайта на демона, который будет а) смотреть заголовки, выясняя, какую именно страницу клиент хочет открыть и б) если клиент хочет открыть страницу, которая заблокирована, подменить ответ на страничку «сайт заблокирован…» ну или просто разорвать соединение.
Если же делать «Либо провайдер пропускает трафик к узлу / от узла как есть, либо законно блокирует подключение к узлу.» то это тогда получается, что Вы предлагаете блокировать тупо всё по ip, при этом будут заблокированы тысячи сайтов, которые находятся на одних ip с теми, что находятся в реестре, учитывая повсеместное распространение облачных хостингов, это будет означать блокировку целых подсетей оптом, десятки или сотни тысяч сайтов. Зато провайдеры не будут вмешиваться в трафик! :)
mikeus
29.01.2017 15:43Чтобы заблокировать отдельную страницу сайта нужно направить весь http-шный трафик, который идёт на ip-адреса этого сайта на демона, который будет а) смотреть заголовки, выясняя, какую именно страницу клиент хочет открыть и б) если клиент хочет открыть страницу, которая заблокирована, подменить ответ на страничку «сайт заблокирован…» ну или просто разорвать соединение.
Да, и в таком виде это получается по-закону.
Если же делать «Либо провайдер пропускает трафик к узлу / от узла как есть, либо законно блокирует подключение к узлу.» то это тогда получается, что Вы предлагаете блокировать тупо всё по ip
Я ничего не предлагаю. Не надо привязываться к слову «узел». Можно уточнить: либо провайдер пропускает трафик к узлу / от узла как есть, либо законно блокирует подключение к узлу по запрещенному URI. Вы же понимаете… Главное чтобы провайдер это понимал.degorov
29.01.2017 15:48Надо просто определиться что такое «узел». Если узел это IP-адрес, то это одно, если домен то другое, если урл, то третье. А там ещё в реестре есть протоколы, порты…
В некоторых случаях, чтобы заблокировать подключение по запрещённому URI самый гуманный способ — это как раз описанный автором в статье. Альтернативные способы намного менее гуманные, а закон исполнять надо в любом случае — это лично я обсуждать смысла не вижу.
mikeus
29.01.2017 17:05-2Закон, мораль, этика, нравственность, гуманность. Если задаться поросом: исходя из жизненного опыта убрать лишнее понятие из этого списка, то это — «закон».
Я думаю что это так. И тогда становится ясно как к этому понятию относится — не стоит смешивать его с другими понятиями. И такое отношение к пониамнию закона и законности очень на мой взгляд справедливо и правильно.
И когда на процессе по запрету доступа к какому-нибудь интернет-ресурсу какой-нибудь прокурор свое видение соблюдения морали и защиты нравственности начинает смешивать с соблюдением закона, то на самом деле на практике это выливается в то, что закон подменяется его видением.
Мне из-за этого становится тревожно, потому что именно из-за этого явления несмотря на то, что в законе ясно и четко определен круг информации запрещенной к распространению и имеется недвусмысленное указание что «ограничение доступа к информации устанавливается федеральными законами» (т.е. исключительно — должен быть ФЗ в котором четко указано что такая-то информация запрещена к распространению), мы фактически имеем ситуацию когда запрещается любая информация, которая признается противоправной с точки зрения прокурора/судьи. Именно из-за того что защита нравственности начинает смешиваться с защитой законов.
И мы тут потом вынуждены рассуждать про «самый гуманный способ» блокировок URI…
trublast
29.01.2017 20:36Есть разные способы.
— Заворачивание всех ДНС-запросов на свой сервер через DNAT к примеру. Оператор может держать у себя зоны заблокированных сайтов и отвечать айпишником сервера с заглушкой, а остальные домены резолвить как положено.
— Анализ запросов и отравка в случае необходимости «фейкового» днс-ответа. Так как они UDP, про проблем вообще никаких, у разработчиков систем блокировки это модуль к ядру, все в кернелспейсе. По этой причине любой гугловый ДНС-сервер (да впрочем и более менее близкий, но «софтовый», типа бинда или анбонда) ответит медленнее, чем к вам придет фейковый ДНС-ответ от блокировщика, работающего на уровне ядра.
Вся эта билиберда с подменой ДНС не работает, если использовать DNSSEC резолвер у себя, но дело в том, что:
а) у вас все равно ничего не работает, потому как «фейковые» пакеты считаются битыми, а настоящие или не приходят (в случае 1) или уже не ожидаются (в случае 2)
б) днссек настроен довольно на небольшом количестве доменов, от общей массы
кстати от варианта 2 можно более или менее успешно отбиваться, используя -m ttl и DROP (хотя бы на домашнем роутере с опенврт), подобрав нужный TTL (количество хопов от/до сервера блокировки) Чтобы встраивали в пакеты рандомный TTL — не замечал. Чисто из академического интереса пробовал — работает. Но просто держу для всяких непонятных случаев TOR под рукой, так как ноутбук перемещается по городу/стране, а роутер дома стоит. С TOR-а пока все работает, его еще у нас не блокируют.
kemko
28.01.2017 21:38+7Морально-этическую и законную стороны действий провайдера, думаю, обсуждать смысла нет
Если вы имели в виду, что нет смысла в очередной раз обсуждать местное законодательство, то да, уже всё, что только можно обсуждено. Пытаться менять пора, если что-то не устраивает.
Если вы имели в виду, что нарушение законов тут очевидно, то не факт: описанное поведение присутствует в памятке для провайдеров по блокировкам от Роскомнадзора. Так что или Роскомнадзор распространяет противоречащую текущему законодательству памятку, или провайдерам так всё-таки можно в рамках исполнения 139-ФЗ.
schors
29.01.2017 13:01+4РКН распространяет противоречащую закону памятку. Подразумевающую слишком расширенное толкование. Которого в оригинале нет. Я уже три месяца обещаю, но руки не доходят, написать в прокуратуру, указать на явное нарушение законодательства. Пусть проверят.
iborzenkov
28.01.2017 21:51+12Открытие сделали блин.
Проверка на подмену DNS запросов уже есть в https://github.com/ValdikSS/blockcheck
turone
28.01.2017 22:40просто поменяйте днс сервера на другие малоизвестные. Скорее всего провайдер как-то фильтрует данные днс запросов на известные днс сервера или государство уже договорилось с гуглом про фильтрацию днс для российских айпи. Меня например пускает на все запретные https при простой установке малоизвестных нероссийских днс.
mickvav
28.01.2017 22:55+8Тупо весь 53 порт tcp и udp DNAT-ится на сервер провайдера, и все.
turone
29.01.2017 10:04вначале попробуйте, сомневаюсь, что весь 53 DNAT-ится.
m0Ray
29.01.2017 16:01Весь 53 заворачивать проще, чем по спискам.
turone
30.01.2017 16:41если это так, то конечно жесть, а если у мне специфичный днс сервер нужен? хотя у меня при установке гугловского днс всё блокирует, а какойнибудь малоизвестный в другой стране то полный доступ, не пишу провайдера, а то тоже забанят
m0Ray
30.01.2017 16:51Ну так дальше уже разбирается DNS-сервер провайдера: что-то из кэша достанет (что снижает нагрузку на внешние каналы), что-то заблокирует, а что-то и передаст наружу.
GennPen
28.01.2017 22:55Не поможет, только если заворачивать в шифрованный канал.
По сути они слушают DNS трафик и посылают ответ быстрей, чем отвечающий сервер, из-за этого клиент первым принимает ответ заглушки от DNS-сервера ДомРУ, а второй запоздалый ответ от сервера просто игнорируется. Таким образом с ДомРУ практически без разницы к какому DNS подключаться, ответы все равно с ДомРУ приходят.BuDDiE
29.01.2017 14:01Именно, что быстро отвечают. Поэтому для микротика:
/ip firewall filter add action=drop chain=input in-interface=PPPoE-dom.ru protocol=udp src-port=53 comment=92.255.241.100 content="\\\FF\F1d"
/ip firewall filter add action=drop chain=input in-interface=PPPoE-dom.ru protocol=udp src-port=53 comment=2a02:2698:a000::64 content="*\02&\98\A0\00\00\00\00\00\00\00\00\00\00d"
Diman89
29.01.2017 21:49+1можно банить и так
/ip firewall filter add action=drop chain=input ttl=equal:126
/ip firewall filter add action=drop chain=forward ttl=equal:125
или скомбинировать для цепочек и TTL>X, например
heizen
30.01.2017 14:15Или даже при помощи IPTables:
https://rutracker.cr/forum/viewtopic.php?t=5126394
darii
28.01.2017 23:00+2Отвечаю, что делать пошагово.
1) настрой dnscrypt-proxy на своем впн сервере, например, запрашивающий всё у какого-то из провайдеров (список лежит примерно в /usr/local/share/dnscrypt-proxy/dnscrypt-resolvers.csv) и отдающий результаты по 127.0.0.1:53
2) опционально — подними named на 10.8.0.1:53 (или какой там у тебя внутренний адрес впн-серера)
3) в /etc/openvpn/server.conf пропиши что-то типа
push «redirect-gateway def1 bypass-dhcp»
push «dhcp-option DNS 10.8.0.1»
вот так должно работатьdarii
28.01.2017 23:04+1Отвечаю, что делать пошагово.
1) настрой dnscrypt-proxy на своем впн сервере, например, запрашивающий всё у какого-то из провайдеров (список лежит примерно в /usr/local/share/dnscrypt-proxy/dnscrypt-resolvers.csv) и отдающий результаты по 127.0.0.1:53
2) опционально — подними bind на 10.8.0.1:53 (или какой там у тебя внутренний адрес впн-серера), записав в /etc/bind/named.conf.options примерно вот это
options { directory "/var/cache/bind"; forwarders { 127.0.0.1; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on port 53 { 10.18.0.1/32; }; };
3) в /etc/openvpn/server.conf пропиши что-то типа
push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 10.8.0.1"
вот так должно работатьVindicar
29.01.2017 01:03С таким подходом есть одна маленькая проблема — директива redirect-gateway завернёт весь трафик через VPN. Чтобы не тормозить почем зря, придётся постоянно подключаться/отключаться.
Проще и впрямь поднять bind, но настроить клиентов статически на 10.8.0.1 как первый DNS, и 8.8.8.8 как второй.
Однако тут всплывает Windows 10 со своим DNS leak (манерой отправлять запрос сразу на все известные ей сервера).
Кардинальное решение будет развернуть клиент на перешитом роутере, настроить роутинг между сетями (возможно, с маскараидингом), и настроить dnsmasq на роутере так, чтобы он опирался на bind, когда туннель поднят (и на что-нибудь другое, когда нет).
Вот тогда все устройства в сети будут видеть только один доступный DNS-сервер — роутер, и никаких других вариантов у них не будет.
vadimr
29.01.2017 00:50+2Многие смотрят на интернет-провайдера, как на передатчика пакетов ip между пользователем и интернетом. Это не так. Провайдер передаёт определённую информацию по определённым протоколам, не более того.
В данном случае провайдер просто закрыл запросы к чужим dns с целью оптимизации (с его точки зрения) трафика. Такое ряд провайдеров практиковал и до появления фильтрационных законов. Также часто у домашних пользователей бывают перекрыты почтовые порты, особенно входящие.ivan386
29.01.2017 01:41+2Вы забыли про сетевой нейтралитет. Провайдеры и другие организации нарушают его ради оптимизации каналов и собственной выгоды. Пытаются добиться его отмены.
Archon
29.01.2017 07:36+1Чисто теоретически они могут вообще обосновать это заботой о пользователях, у которых по какой-то причине вирус прибил гвоздями какой-то левый статический DNS и перенаправляет весь трафик на мошеннические сайты. Они «просто» помогают вам настроить подключение согласно договору (в котором скорее всего русским по белому прописано, что вы обязаны использовать выданные ими IP-адреса и DNS-серверы), не более того.
Ни в коем случае не пытаюсь никого оправдать, но доказать какое-либо нарушение со стороны провайдера в данном случае будет затруднительно.buggykey
29.01.2017 15:39Это как таксист, которого попросили отвезти в больницу, а он посчитал, что пациент «подозрительный» и отвез сразу на кладбище. Позаботился, да? ;)
vsb
29.01.2017 01:44Обязательно надо весь трафик в VPN заворачивать. Пусть даже пользуетесь гугловым DNS, но UDP-пакеты до них должны идти через VPN. А лучше, конечно, полноценный рекурсивный кеширующий DNS-сервер развернуть у себя на сервере.
pyrk2142
29.01.2017 08:45Насколько я понимаю, много кто этим пользуется. Та же Yota через VPN тоже блокирует сайты.
aamonster
29.01.2017 09:57+4Вы меня шокировали.
Не поведением провайдера, а тем, что часть трафика идёт мимо VPN. Как так?!Vindicar
29.01.2017 14:15Зависит от настройки. Если VPN не прописывает себя как default gateway, то трафик будет ходить как обычно, за исключением ресурсов внутри VPN (например, прокси). Это удобно, поскольку можно держать VPN включённым, и при этом не замедлять другие виды трафика понапрасну. Но это же означает, что DNS трафик будет гулять мимо, если не настроить DNS-сервер внутри VPN как единственный доступный.
А еще можно вспомнить обсуждавшуюся на хабре манеру Windows 10 посылать запросы сразу на все известные DNS-сервера, и реагировать на первый положительный ответ. Ответ от перехваченного провайдером запроса (или просто от запроса на DNS провайдера) вполне может придти раньше, чем ответ от сервера за VPN. Эта фишка отключается, но недокументированным образом.
demfloro
29.01.2017 14:01Тогда можно сразу поднять рекурсивный резолвер на том же unbound на VPN-сервере. Заодно история DNS-запросов не будет так очевидна для самого Google.
stork_teadfort
29.01.2017 14:01Можно пользоваться DNSCrypt Есть клиенты для всех платформ, плюс встроены из коробки в некоторые открытые прошивки для роуторов, в частности в Tomato.
eth3
29.01.2017 14:01+1Тут ситуация еще веселее оказалась. У моего датацентра (Датахаус, г. Москва) упал «Роскомнадзоровский» сервер. Из-за чего более суток (с вечера пятницы до ночи субботы), запросы к 8.8.8.8 отваливались целиком.
TriLka
29.01.2017 14:01Была же уже точна такая же статья, с такими же шутками про кактусы. Где-то 1-2 года назад. Зачем вы её скопировали?
Bsplesk
29.01.2017 14:02Полнейшая беда, когда в качестве хакера выступает провайдер — десятая сторона, тот кто пользуется megafon и знаком с безопасностью, возможно невольно отслеживали это печальное развитие, особенно было неприятно наблюдать за MITM атаками на SSL, когда подменялся сертификат, на нужный, при этом ты заходил на сайт интернет банка, видно было рассчитано на пользователей нужных «браузеров» — с зашитым нужным сертификатом, по факту 2 ключа из двух, двухфакторной авторизации, у одной стороны — провайдера. Тоесть какой-нибудь «админ» в megafon_e может получить доступ к миллионам банковских счетов. Так, что осторожней.
DNS — аналогично, принудительно подменяется :(
mhome ~]$ tracepath 8.8.8.8
1?: [LOCALHOST] pmtu 1500
1: gateway 1.046ms
1: gateway 1.233ms
2: no reply
3: 10.152.206.242 166.751ms
4: 10.152.189.37 108.446ms asymm 5
5: no reply
6: 10.52.137.194 164.642ms asymm 4
7: 10.152.189.42 118.637ms asymm 6
8: 10.152.211.141 169.149ms asymm 7
9: 46.229.142.76 398.808ms asymm 8
10: 37.29.4.129 167.031ms asymm 9
11: no reply
12: 10.222.99.57 354.692ms asymm 14
13: 83.169.204.34 248.690ms asymm 12
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
AlexanderY
29.01.2017 14:02+2Тоже пользуюсь Дом.ру. Блокировки обхожу с помощью ПростоВПН, но раздражает кое-что другое. Периодически, вместо сайта, который я хочу открыть, мне показывается домрушевская страница с каким-нибудь промо-предложением. То ТВ предлагают, то антивирус. В углу ссылка на тот сайт, куда я собственно пытался изначально попасть.
Это из той же оперы, лечится также, или тут что-то другое?
wizard31337
05.02.2017 14:45Лечится путем наезда на саппорт провайдера. Проверено собой, 100% результат.
navion
06.02.2017 12:01У саппорта (любого, не только провайдерского) иммунитет к наездам, вы просто их развлечёте испортив себе настроение.
wizard31337
06.02.2017 14:49Это вы исключительно с целью возразить, да?
Против аргументированного, подкрепленного ссылками на ФЗ наезда еще пока ни один адекватный саппорт не устоял, либо решение проблемы на месте, либо эскалация и решение проблемы. Ну, кроме Ростелекома (о адекватных же), но с этой волшебной компанией вопрос о навязчивой телефонной рекламе решается уже в уполномоченных органах.navion
07.02.2017 10:15Адекватная поддержка вам поможет без угроз и мозгоклюйства, если имеют такую возможность.
А для юридических претензий есть два канала: заказное письмо или вручение с регистрацией в канцелярии.
anonslou
29.01.2017 14:02+1Контроль DNS трафика на самом деле гораздо важнее VPN.
Во-первых, потому что даже если сайт через TLS работает, а при его использовании URL шифруется, защищенная сессия все равно строится поверх TCP соединения, а значит нам надо знать IP адрес сервера. В теории, если бы все сайты поддерживали https, то VPN для веба был бы и не нужен, если не брать в счет MiTM атак, конечно.
Во-вторых, не защищая DNS вы подвергаете себя дополнительным рискам связанным с малварью. Она любит оборачивать в DNS-трафик управляющие команды или сливать через него инфу. Хуже того, малварь может тупо подменить DNS сервера, что ведет к рекламе, фишингу и позволяет обойти защиту через сервисы, вроде, opendns.
Поэтому нужно не только обязательно заворачивать DNS в VPN, но и фильтровать собственный исходящий трафик запрещая обращения к недоверенным DNS серверам.
bebebe
29.01.2017 16:10-1Есть еще интересный проект от Google DNS.
https://developers.google.com/speed/public-dns/docs/dns-over-https
Никто не встречал реализации для client side?Erelecano
29.01.2017 17:41-1dns over https вам дает dnscrypt(не путайте с dnssec, они не однофамильцы)
dnscrypt по дефолту использует 443/tcp и делает вид, что он https
В этом топике dnscrypt уже несколько раз упомянули, но вам же не хочется получать информацию, вам надо задавать глупые вопросы.
Ivan_83
29.01.2017 17:45+1Катай жалобу в РКН.
Напиши там что хотел воспользоваться OpenDNS для фильтрации всяких плохих сайтов, потом попробовал SkyDNS для того же самого и потом даже YandexDNS пробовал, но везде облом.
Ихние специалисты сказали что ничего не работает потому что твой провайдер принудительно заворачивает все DNS запросы к себе, тем самым лишая тебя возможности воспользоваться столь жизненно небходимими сервисами для повышения безопасности интернет сёрфинга.
Нужно быть готовым что к тебе приедут чтобы удостоверится, и нужно будет показать/воспроизвести, чтобы было ясно-понятно видно что днс подменяется у провайдера а не твой роутер похакали и прописали туда левый днс.
Если что, РКН в рекомендациях про заворот днс трафика ничё не писал совсем, поэтому то что тебе словали нормальную работу DNS вина провайдера а не законов.
«8.8.8.8 и 8.8.4.4» — вот нахрена!?
Так гугель о тебе будет знать намного больше. Ну и все кто попути отзеркалил себе на коллектор. (думаю таких любопытных не одна организация)
Снеси бинд и поставь unbound, ему вообще никакие форвадеры не нужны (хотя он умеет), он и сам прекрасно умеет рекурсию с кешированием, для чего и был создан.
2 schors
DNSSec зло.
Если его повсеместно внедрить то можно будет выключать любые сайты и даже страны (нац домены).
Я принципиально ни где не включаю проверку DNS, ибо мне ехать а не шашечки (якобы безопасность).
В данном случае он бы никак не помог, ТС просто бы остался без инета.
2 buggykey
В твоём случае ты договор с домсру не подписывал вроде как…
2 Envek
Будь мужиком — сделай себе IPv6 сам!
В инете 100500 инструкций как это сделать, желательно при этом иметь белый IPv4.
2 degorov
РКН уже давно выпустил рекомендации как нужно что делать, не нужно тут умничать.
2 vadimr
Провайдер и есть тупая труба, все попытки стать умной пресекаются другими игроками, типа того же гугла который через жопу протащил TLS везде, а теперь ещё и quick тащит, чтобы сломать шейперы и приоритезацию окончательно.
Никакой заботы в завороте нет, см выше.
2 anonslou
Глупости это.
Ничего не мешает вбить статикой IP vpn серверов в клиента и преспокойно обойти все извраты с DNS.
И потом выше я уже написал, заворот днс не позволяет пользоваться вполне легитимными сервисами в инете.
Между прочим некоторые типа детей так от прона ограждают, ну по крайней мере так сами эти сервисы заявляют.degorov
29.01.2017 19:32«Если что, РКН в рекомендациях про заворот днс трафика ничё не писал совсем»
http://eais.rkn.gov.ru/docs/Recomendation.pdf Пункты 9.2 и 10
Ivan_83
30.01.2017 22:47Это не мешает жаловаться им же что мешают пользоваться ДНС сервисами, если они будут отмораживаться можно и в прокуратуру.
ZoraX
29.01.2017 18:11А не пробовали последнюю версию openvpn-as использовать? И указать ему использовать явно сервера VDS хостинга, плюс включить -block-outside-dns?
sergeysakirkin
30.01.2017 03:14ТТК так-же развлекается подменой днс-ов делаю два запроса на уникальный домен bbbaaa.com,
dig @8.8.8.8 bbbaaa.com
;; Query time: 296 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
откуда второй ответ за 59 msec????
;; Query time: 59 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
Ну а метод прост избавления от этой заботы провайдера — DNSCrypt.
wget https://download.dnscrypt.org/dnscrypt-proxy/LATEST.tar.bz2
polar11beer
30.01.2017 11:25Остаётся ДНС. Но, на моём домашнем сервере настроен кэширующий ДНС-сервер bind, и в качестве forwarders указаны гугловские 8.8.8.8 и 8.8.4.4. Есть только одно «но»: доступ к этим серверам идёт по открытому каналу.
Многие на этом палятся, когда настраивают прокси в браузере и думают что админ теперь никак не отследит историю их сёрфинга.
И кстати если вместо VPN настроить ssl-туннель и сказать браузеру ходить в инет через него, то тоже DNS будет по умолчанию идти мимо туннеля. В Мозилле нужно явно выставить настройку network.proxy.socks_remote_dns = true.
grossws
30.01.2017 19:36Или в foxyproxy указать, что заворачивать всё включая DNS в SOCKS. Часто использую совместно с
ssh -D.
inscriptios
31.01.2017 21:35Использую на роутере с прошивкой от Олега dnsmasq + dnscrypt + tor (выборочно для сайтов, внесенных в реестр).
Nicks_TechSupport
31.01.2017 21:35Народ, а кто в курсу как с этим дела у Ростелекома обстоят??
К сожалению, он монополист в нашем доме, но подозреваю, что тоже такими вещами занимается, кто силён и может подсказать?
Спасибо.GennPen
01.02.2017 02:17Судя по инфе — как обычно: подсовывание своего пакета с адресом на заглушку, спустя чего приходит настоящий пакет от сервера, который отбрасывается системой как неправильный. Выше была ссылка как это фиксить на Микротике, там же и ссылка на инфу.
Nicks_TechSupport
01.02.2017 10:18Спасибо! У мены обычный роутер Асус, попробую.
inscriptios
01.02.2017 12:55Тогда вам, возможно, подойдет Защита DNS-трафика от перехвата. И обязательно Запрет использования собственных DNS-настроек на клиентах.
GennPen
04.02.2017 14:42К сожалению, как минимум у ДомРу и Ростелеком подсовывают свои пакеты не только в DNS-трафик. Пробовал подставлять адреса в hosts, но все равно подсовывают пакеты с перенаправлением на заглушку, видать еще смотрят по адресу в заголовках запросов.
androidformax
31.01.2017 21:35Спасибо за дискуссию в комментариях, очень много для себя интересного почерпнул!
degorov
Ну а куда провайдерам деваться? Как альтернатива можно или делать MITM уже на HTTPS или просто тупо банить по IP, причём ещё и подрезолвливая самому адреса для доменов, внесённых в реестр — на практике это будет означать, что cloudflare и прочие aws будут забанены целыми подсетями, например.
shifttstas
Полная блокировка по IP лучше чем MITM и намного чеснее (и даёт понимание людям об ограничениях)
schors
Да. Я кстати везде топил за блокировку по IP.
degorov
В задачи провайдера не входит ведение просветительской и тем более правозащитной деятельности. В задачи провайдера входит обеспечение народа интернетами. Большинство клиентов в принципе не знает, что такое IP-адрес и тем более что такое MITM, зато если у них отвалятся сайты, которые у провайдера-конкурента не отваливаются и по закону и не должны отваливаться — они уйдут к другому провайдеру, которых сейчас в любом подъезде минимум 3-4 штуки. Суровая реальность…
schors
Пустые отговорки. Провайдеры оказались безвольными уборщицами. Вот поэтому такая и срань. Если они вообще хотят сохранить свой бизнес — входит. Хостерам почему-то всё это не помешало хоть как-то побуянить. Хотя им-то вообще чего — пришла малява — закрыл, или не закрыл — вообще закон не касается.
navion
Там внизу написали про хостеров.
schors
Ну и где это про хостеров?
navion
ДЦ уже не хостер?
schors
Да там и не про ДЦ.
schors
Но учитывая то, что работа в окружении безвольных тряпок — часть нашей жизни, я конечно же предлагал сделать это на уровне нормативной базы. И до сих пор придерживаюсь этого мнения и когда меня как эксперта спрашиваю — озвучиваю. Когда не спрашивают — тоже :) Да, блокировка должна быть только по IP.
degorov
?_(?)_/?
shifttstas
Вы поменяете провайдера если вас в нем устраивает стабильность работы но один сайт не открывается?
Что-то мне подсказывает, что «домохозяйка» загуглит не открывается сайт Х и получит ссылку на тор браузер
degorov
«один сайт не открывается» — оно так будет только если на одном ip-адресе сайтов два, обычно это не так. Это даже не говоря о том, что для того, чтобы выполнить требования РКН, провайдеру не достаточно блокировать те ip-адреса, которые указаны в реестре — провайдеру приходится резолвить актуальные самому.
shifttstas
Так и замечательно, больше людей начинают обходить блокировки. Приличные сайты, к слову, находятся на своих личных IP, а не на shered хостинге (он еще не вымер?)
grossws
Shared более-менее пофигу, но есть saas-платформы (тот же wordpress, blogspot и т. п.), которые пострадали. Ещё из больно ударивших в своё время cloudflare (CDN), github, slideshare.
В общем-то под угрозой любой сайт, который позволяет публиковать пользовательский контент.
schors
slideshare и cloudflare это конечно трындец :(((
schors
Прально. Значит дожно быть в нормативах — все по IP. У меня и так половина нужных сайтов не открываются, так что я всё уже решил :)
shifttstas
Не переживайте, скоро все переедут на HTTPS only и будет только по IP =)
schors
SNI же. Я скорее ставлю на то, что у меня руки дойдут написать в прокуратуру на саботаж Роскомнадзором законодательства — на Youtube есть запрещенные судами ролики, которые там есть, а блокировки youtube нету.
shifttstas
Ок, IP + домен, но это не MITM c фильтрацией по контенту.
Shvedov
Нет таких урлов, все с http. Меня уже в этом обвиняли, два суда выиграл.
А те, что в списке минюста, то Роскомнадзор не виноват.
schors
Как это нет? https :// www. youtube. com/watch?v=nD65tSYjZPM
Решение суда. Даже в списке РКН есть. Но почему-то со статусом «не блокируется». И такого дохрена.
navion
Некоторые перенаправляют трафик до заблокированных IP-адресов на Squid, где смотрят URL в SNI и блокируют только внесённые в реестр (остальное пропускают). А CDN уже давно забанены целыми подсетями.
schors
И получается полное гавно. Потому что мало того, что кто-то трекает мой SNI, так ещё и качество этих сквидов оставляет желать лучшего
grossws
в sni нет url, только хост (server_name)
navion
Спасибо, все время путаю название.