В частности рассылаются письма следующего содержания (интимные места письма замазаны в графическом редакторе):
Снова и снова мы ходим по тем же самым граблям. Сколько от этого пострадает ресурсов, вина которых лишь в том что разместились на «неправильном» хостинге, никто из отдающих распоряжения подсчитывать не будет. Как известно, проблемы индейцев шерифа не волнуют.
По этой же логике такие ресурсы как Youtube должны быть заблокированы полностью —
Хочется напомнить свой же пост от 5 ноября 2014 года "Размер базы доменных имен в списке Роскомнадзора" — за прошедшее с тех пор время XML файл вырос с 1 770 422 байт до 22 763 225 байт, т.е. почти в 13 раз. У меня этим файлом «давится» Notepad++. Мы близки к введению «белых» списков, что несомненно облегчит жизнь операторам связи.
Комментарии (57)
NoRegrets
28.03.2017 18:37+6Если кто не курсе, в логике работы роскомнадзора произошли изменения. Если первоначально они требовали обновлять IP адреса соответствующие отдельным доменам, то после парочки удачных атак они переключились на позицию «блокируйте только то, что есть в реестре».
Так вот, в начале этого года они поменяли свой курс и снова начали требовать блокировать все. Фактически они перешли в позицию «нам насрать как вы это сделаете, но если хотя бы один ресурс не будет заблокирован, вы будете оштрафованы». Обновляйте ip адреса, используйте DPI, делайте что хотите, но все что есть в реестре должно быть недоступно,особенно призывы выйти на митинги и тд..
Вот ссылочка на из прессконференцию https://rkn.gov.ru/press/conference/conf19.htm.
Большинство провайдеров (у которых нет DPI) работает по такой схеме:
1. определяются ip адреса доменов + ip адреса из реестра
2. трафик по указанным адресам выделяется (есть разные способы — bgp, другой маршрутизацией, ipsetами и тд)
3. выделенный трафик фильтруется через прокси, все что не http блокируется.
Поэтому, сейчас можно троллить большинство провайдеров, указывая IP левые адреса для заблокированных ресурсов. Адреса, соответствующие ютубу, сбербанку и т.д. Один провайдер, в котором работает мой друг, блокирует только адреса из реестра, поскольку проверять валидность адресов он не может. Кроме того, есть судебные решения, где суд учитывает какие IP в действительности были в реестре, а какие нет.
dartraiden
28.03.2017 19:54-1Лучше повторить старую добрую историю, когда один заблокированный ресурс указал в качестве своего IP адрес сервера, с которого производится выгрузка реестра.
Провайдеры тогда недоумевали «а чего это у нас доступ к реестру пропал?».
S_Sannikov
28.03.2017 23:18Кроме того, есть судебные решения, где суд учитывает какие IP в действительности были в реестре, а какие нет.
Решение суда есть в общем доступе?
KorDen32
29.03.2017 01:43+2Увы, в феврале-марте именно это и происходит у магистрала ТТК,
Легко гуглится куча разрозненных тем по «filter-gw.transtelecom.net» (или «blacklist-gw.transtelecom.net»).
ТТК на магистральном уровне блочит рандомные не значащиеся в реестре IP (видно как раз потому, что детектят другие IP для заблоченных доменов, и кто-то троллит/или CDN).
В итоге не открываются рандомные сайты. Из последних крупных, что были замечены — сайты Uniquiti, служебные домены EVE Online, Ingress — правда все они на CDN сидят. Недавно пара IP Github.com была заблочена, со всеми вытекающими — гитхаб тупо не открывался несколько часов, но это было не сильно массово…
Pakos
29.03.2017 13:12Ну так пополнять бюджет хоть на сколько-то надо — вот и повод нашёлся. Такое в каждой сфере периодически проскакивает.
VeldRiN
29.03.2017 16:40+1Есть уточнение по 3-му пункту. squid умеет прозрачно блочить https домены, не трогая остальные домены на cdn
вот статья https://habrahabr.ru/post/272733/.
Минусы:
то что не умеет показывать заглушку, без подмены сертификата (ну это не критично, т.к. лучше блокировать 1 сайт, чем весь айпи).
Ну и ресурсоемкая, при большом кол-ве пользователей создается большое кол-во файловых дескрипторов, мне пришлось сделать tuning ядра в этом вопросе.
Надо чтобы днсы у клиентов и сквида были одинаковые, через политики АД или перенаправление днс запросов к себе, блокирование 53 порта всем клиентам во внешку вообще как варик.
Банится только домен из SNI, поэтому я составляю список url'ов с https и преобразовываю их в новый где присутствуют только домены, плюсую к ним список заблокированных доменов, сортирую, резолвлю все это нонстоп скриптами. Полученные айпи заливаются в циско, которое роутмапит их по порту 443 в сквид.
Хотя, можно еще 1 сервер специально для ревизора сделать, завернуть туда весь https трафик, чтобы не париться насчет динамических адресов.
Newbie2
28.03.2017 22:42Мне вот интересно, а хоть один владелец сайта, которого заблокировали «паровозом», подавал иск против роскомнадзора за такие действия? Ведь упущенная выгода, неправомерное ограничение в осуществлении хозяйственно-финансовой деятельности налицо.
funca
28.03.2017 23:31+2Какие такие действия? РКН это надзорный орган, сам он ни чего не блокирует, и ни когда не предписывал блокировать законопослушные сайты.
Sly_tom_cat
28.03.2017 22:48На самом деле все еще проще, по крайней мере у одного большого провайдера. Он ничего не лочит, просто возвращает быстрее чем сервер куда послан запрос свою страницу с предупреждением о блокировке.
Лечится простой записью в файервол (iptables). Вот тут все расписано: http://www.opennet.ru/tips/2999_iptables_block_tor.shtml
swelf
28.03.2017 23:32+3проблема в том, современные системы посылают пакеты в обе стороны, клиенту на http_redirect, серверу tcp с R флагом. Так что такой записью ты просто убьешь свою переадресацию, сайт не заработает.
Sly_tom_cat
29.03.2017 10:20Только вот сервер имеет право на tcp c R флагом не реагировать, что большинство и делают. Так что, с одним большим оператором — все прекрасно работает: проверено на куче сайтов из списка блокировки.
qw1
30.03.2017 13:20Это как не реагировать, если клиент хочет прервать соединение? Зачем серверу держать в памяти лишние завершённые соединения, ресурсы некуда девать?
Sly_tom_cat
30.03.2017 15:18Если вы разрабатывали сервисы то должны знать:
Прервать выполнение запроса иногда бывает затратнее чем доделать все до конца (т.е. игнорировать прерывание).
Да и не факт, что прерывание отсылается.
Но, я предлагаю закончить теоретизирование на тему отмены запроса. Просто возьмите рецепт на который я сослался и попробуйте. Практика она такая — все теории на места расставляет очень быстро.qw1
30.03.2017 18:10Если вы разрабатывали сервисы то должны знать:
Плохой аргумент. TCP и прикладной сервис работают на разных уровнях. Стеку TCP абсолютно пофиг, насколько затратно прервать запрос для уровня выше. На его уровне совершенно беспроблемно закрыть соединение при получении RST.
Прервать выполнение запроса иногда бывает затратнее чем доделать все до конца (т.е. игнорировать прерывание).
Просто возьмите рецепт на который я сослался и попробуйте
Как я узнаю, что провайдер отсылает RST серверу? Скорее всего, не отсылает, раз рецепт работает.Sly_tom_cat
30.03.2017 19:10А вам нужно знать отсылается RST или нужен доступ?
Вот мне пофигу до этого RST, для меня это не важно, для меня важно то, что я имею доступ к тому что мне нужно, а не к тому к чему мне дают доступ.
Поэтому я и советую от теорий перейти к практике, но вы меня не услышали. Жаль.qw1
30.03.2017 19:51Доступ у меня и так есть.
Это у вас теоретические измышления, насчёт трудоёмкости завершения запроса.Sly_tom_cat
30.03.2017 20:35Спасибо кэп, что открыли мне глаза на то, что мой опыт нужно выкинуть на помойку как теоретические измышления. :)
qw1
31.03.2017 13:04Ваш опыт в том, что сервер не реагирует на RST? (кстати, за это отвечает ОС, а не веб-сервер — какая ОС имеет такое поведение в TCP/IP стеке?).
Или опыт в том, что фильтруя на клиенте RST, мы получаем соединение к заблокированным сайтам, а насчёт отправки RST серверу ничего не известно?
Если стек TCP/IP игнорит RST, зачем его блокировать на клиенте, он же проигнорируется…Sly_tom_cat
31.03.2017 14:11Вы для начала определитесь куда RST идет на сервер или на клиента и как его блокировать на клиенте, если оно идет на сервер. Вы что-то уже совсем запутались похоже…
Однако если для вас главное оставить последнее слово за собой, то так тому и быть. Можете дальше свои теории теоретизировать сколько вам угодно. Я только повторю — практика она точки над и расставляет гораздо лучше рассуждений и теорий.
webmasterx
29.03.2017 11:40Как раз по этому причине Equestria Daily не работает. Все из-за того, что на этом же айпишнике находились нехорошие вещи. А провайдер, вместо того, чтобы показывать свою стандартную заглушку, дропает пакеты
maa_boo
29.03.2017 14:24+1Наверное не совсем правильно употреблять слова «логика» и «Роскомназдор» (на самом деле <впишите любое название госструктуры>) в одном месте, если только это не выражения вроде «логика отсутствует».
swelf
неопнял откуда паника.
В реестре сайт rogaikopita.sru допустим имеет адрес 1.1.1.300, dns говорит что у них уже адрес 1.1.1.400, в итоте тут говорится что проверка rogaikopita.sru будет осуществляться как по адресу 1.1.1.300 так и по адресу 1.1.1.400, а уж как блокировать, по домену, по урл или по ip, это уже указано в реестре.
Ничего собственно не изменилось, только раньше было указание проверять только трафик к ip из реестра, теперь проверяем весь трафик.
по какой такой логике ютубчик должен быть заблочен? там есть https ссылки? нету, значит блокируем отдельные урлы.
qw1
Очень просто. Владелец rogaikopita.sru создаёт для своего домена множественные A-записи с IP-адресами ютюба, контакта, mail.ru и т.п. (а что — его домен, его DNS-сервер, пиши что хочешь).
DNS-сервер провайдера сливает NS-записи о домене от владельца к себе. Утилита блокировки ресолвит домен, получает 100500 адресов, и по требованиям этой директивы, должна заблочить все эти IP
swelf
Да оно и раньше так было, только сейчас комуто бумажки пришли. Все эти отмазки «по реестру сайт должен быть на другом ip» никогда не работали. Все мы понимаем, что сменить ip это дело 5 минут. Но дело в том, что от того что rogaikopita.sru поставит себе ip адрес гугла, гугел не заблокируют, провайдер все равно блочит по урлу. исключение https сайты, которые часто(а может редко) блочат по ip, но я о прецедентах такой подмены не слышал.
для блокировки ip там есть отдельный тип адреса, который с блоком по урлу не имеет ничего общего. В данном случае идет речь о блоке по урлу.
qw1
Сможете поработать с Google Search по http? У меня никак не получается, всё время переходит на https.
StjarnornasFred
Кстати, а почему HTTPS препятствует блокировке одной отдельно взятой страницы? Объясните нубу, почему нельзя «забанить по URL» — неужели провайдер не способен отловить именно URL и заблокировать (редиректнуть на заглушку) именно его?
rogoz
Потому что провайдер в запросе «https://test.example.com/megabombizspichek» видит только запрос на IP test.example.com, и если есть SNI (современные браузеры давно отправляют) то увидит «test.example.com». Всё остальное зашифровано. И отличить от запроса на «https://test.example.com/nobomb» невозможно.
sumanai
Как будто проблема завести в реестр https сайт.
mickvav
Все еще проще. Оператор, видя, что доменное имя rogaikopita.sru валяется в списке на блокировку, добавляет в свой днс зону rogaikopita.sru с чем-нибудь вида * IN CNAME www.rkn.gov.ru.
И все, кто за рогами и копытами — весело топают в роскомнадзор.
Как-то так.
qw1
Хорошо, если так. Тогда достаточно узнать ip-адрес через любой веб-сервис, предоставляющий утилиты вроде whois, ping, lookup, traceroute и вписать его себе в hosts.
swelf
Такое не прокатит, потомучто как написал qw1 резивор делает часть проверок без запроса ДНС, со статическими записями
qw1
swelf
о мой бог. Как оно работает? я расскажу
в реестре у нас запись
http://youtube.com/?video=grgrdghrghfdhfds
Вариант http -> https
1)Устанавливаем подключение к 80 порту
2)Делаем запрос http://youtube.com/?video=grgrdghrghfdhfds
3)ютуб говорит нам, иди ка ты на https://youtube.com/?video=grgrdghrghfdhfds
так вот, провайдер блокирует на шаге 2, и блокирует(делает редирект на загрушку) еще на этапе http
вариант 2 hsts или как оно там, браузер автоматом все запросы http сразу же посылает на https
1)идем на https://youtube.com/?video=grgrdghrghfdhfds
в реестре такой ссылки нету, там только http -> ничего не блокируется, мы пользуемся ютубчиком.
Вот когда там появятся https сслыки на ютуб(а они появлялись, но быстро уходили оттуда) вот тогда и начнутся проблемы
qw1
1. Есть плохой сайт https://rogaikopita.sru
2. Владелец этого сайта вводит A-запись для своего домена, указывающую на youtube.com, например, 74.125.232.233
3. Провайдер блочит любой https-трафик на этот IP, потому что понять в нём ничего не может.
4. Юзер идёт по ссылке https://youtube.com/?video=grgrdghrghfdhfds
5. Получает блок по IP.
или пусть даже
4. Юзер идёт по ссылке http://youtube.com/
5. Провайдер понимает, что URL разрешённый и пропускает.
6. Гугл делает редирект на https://youtube.com/
7. Юзер получает блок по IP.
swelf
Да, если сайт в реестре по https, то такое возможно, я это отметил в своем коментарии выше. Многие(а может уже и нет) блочат такие сайты по ip. Но при установке ssl соединения браузер посылает client-hello пакет, в котором(вроде как не обзяательно) посылает server_name с которым он хочет соедениться, так вот, сейчас многие блочат ssl соединения именно по sni в clienthello.
qw1
Какие провайдеры реально учитывают SNI? Насколько я знаю, все блочат по IP простым правилом в firewall. Одно дело, когда в DPI идёт трафик маленького сайта-засранца, перенаправляемый в DPI по IP, а другое дело, если в него запулить весь трафик ютюба )))
А вообще, недавно проскакивала статья, что клиент может писать в SNI что угодно, веб-сервера всё равно смотрят на заголовок Host в http-запросе под SSL. Ждём появления браузеров, которые в SNI будут писать легитимный или рандомный домен )))
swelf
врятли ктото будет раскрывать эту информацию, но сам лично знаю таких. А вот ТТК некоторое время назад делал подмену сертификата, причем весьма странно, я думал «ну ладно, сертификат щас свой мне подсунут, но хотяб весь ресурс тогда не заблокируют, а только урл», а вот фигушки, делали подмену и блокировали весь ресурс.
но зачем им это делать? наверно ж не с проста sni поле появилось и его используют.
qw1
qw1
sumanai
Так для SSL его и используют, для того, чтобы сервер послал правильный сертификат. Но если сайт на IP один или сертификат по умолчанию содержит нужный домен, то будет работать без SNI.
throttle
Ссылочкой не поделитесь? Что-то я себе слабо представляю, как оно работает.
Если несколько https-сайтов на одном ip — надо знать, какой сертификат выдавать до всяких Host.
a1ien_n3t
Читайте про SNIПрошу прощения. Неправильно прочел ваш комент.
В client-hello можно писать всякую фигню только если один сайт на одном IP.
qw1
Это работает и без SNI (Клиенты на Windows XP и Android 2.x не умеют SNI). В сервер загружаются сертификаты всех обслуживаемых им доменов и всё. С этим я сталкивался, администрируя Microsoft IIS, за другие сервера не скажу.
SNI придуман позже, чтобы можно было использовать балансировщики нагрузки, проксирующие SSL-соединения на другие хосты, не тратя время на расшифровку трафика.
galaxy
И? А клиенту что отдавать? Все сразу, типа сам разберешься?
a1ien_n3t
Там все просто. Там ОДИН сертификат, на кучу доменов.
sumanai
Такой сертификат стоит больших денег. А из кучи простых сертификатов один никак не слепить.
В LE, насколько я знаю, максимум 100 записей в одном сертификате.
qw1
Да, точно. У нас сертификат типа *.companyname.ru, и сайты в IIS подключены типа www.companyname.ru, shop.companyname.ru
Komei
Да нет, клиент даст нормальный URL запрос уже после установки шифрованного канала. Тут как раз всё просто.
Fess
https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf
Появилась идея шифровать SNI. Те, кто пытался не фильтровать трафик хотя бы по домену, будут вынуждены вернуться к блокировкам по IP.
Ещё и http/2.0 грядёт, который в принципе хотят сделать шифрованным.
Провайдеров загоняют в угол ещё и штрафами: "Вводится новая статья 13.34 КоАП. Согласно ей, штраф на должностных лиц определен в размере от 3 тысяч до 5 тысяч. рублей, на лиц, осуществляющих предпринимательскую деятельность без образования юридического лица, — от 10 тысяч до 30 тысяч рублей; на юридических лиц — от 50 тысяч до 100 тысяч рублей." (с) rg.ru/2017/02/10/gosduma-vvela-shtrafy-dlia-provajderov-za-otkaz-blokirovki-sajtov.html
Блокировать будут самым надёжным способом, — по ip. Ну, кроме самых жирных операторов, готовых разориться на, сначала штрафы, а потом крутой DPI с огромной пропускной способностью. Причём, количество штрафов, на сколько знаю, тоже ограничено. Потом лицензию отнимут.
sumanai
Как там, в 2014? У меня в 2017 он уже пришёл.
Fess
Я не веб-программист, так что да, ошибся. Смысл фразы был: "грядёт в массы". Но, если вам очень хочется поёрничать, можете ещё до чего-нибудь докопаться, не обижусь.
funca
Можно поставить дополнительные условия с целью ограничить использовани https, а дальше web-сервисы уже сами подстроятся, чтобы не терять аудиторию. Особого технического резона использовать шифрование повсеместно нет, несколько лет тому назад Интернет прекрасно работал по http.
Либо терминировать весь https на входе. В пределе новые доверенные сертификаты можно распространять прямо с апдейтами локализированных версий операционных систем или какого-нибудь официального браузера. Certificate pinning, стараниями все того же энтерпрайза, уже давно толком ни где не работает по умолчанию.
Судя по тому, как развиваются события, вопрос «как?» уже не стоит. Сейчас главный вопрос «когда?».
sumanai
Ибо будет через жопу.
nidheg666
«по какой такой логике ютубчик должен быть заблочен? там есть https ссылки? нету, значит блокируем отдельные урлы. » чувааак… тебе лень посмотреть в каком формате ютуб даёт ссылки?)
AlexDPR
добавил к урлу видео ютуба &= и смотри дальше…