Эта история расскажет вам, как ваш интернет-ресурс, особенно если вы заботитесь о безопасности и используете на своем сайте SSL, может внезапно стать недоступным для посетителей из России якобы по указанию Роскомнадзора.
Вы можете сколько угодно пытаться найти причину для себя, но оказывается, что от вас ничего не зависит и либо вам повезет и все рассосется само собой, либо вам придется долго и упорно бороться за сохранение своего IP адрес чистый.
Ну и еще можно отказаться от SSL, что вряд ли является хорошей идеей.
Все началось вечером 28 декабря.
В нашем чате поддержки было обсуждение пары тикетов, в которых пользователи жаловались на недоступность своих сайтов.
Никаких уведомлений о том, что их IP не понравились системе защиты от атак, не было, поэтому в поддержку было предложено прогнать клиентов через стандартную систему диагностики: пинги, трассировки и все такое.
Утром 29 декабря подобных жалоб поступило уже с десяток, что дало повод для беспокойства.
Да и у меня самого что-то было не так: я мог получить доступ к нашим ресурсам по HTTP, но не по HTTPS. Я пытался отследить логи nginx, чтобы увидеть, есть ли какие-либо злоупотребления при вызовах, но не увидел там ни одного вызова от имени моего IP. Просмотр заголовков при открытии сайта по HTTP показал, что запросы стали проходить через прокси-сервер провайдера с добавлением заголовков типа X-Cache:MISS от zapret. Так что да, мы были под наблюдением.
Пример попытки добраться до нашего IP с помощью Curl kemko@dell-work: ~ $ curl --insecure --resolve 'testtest. test:443:185.129.101.243 ' -I https://testtest.test
curl: (7) Failed to connect to testtest.test port 443: Connection refused
kemko@dell-work: ~ $ curl --resolve 'testtest. test:80:185.129.101.243 ' -I http://testtest.test
HTTP/1.1 404 Not Found
Server: nginx
Date: Fri, 30 Dec 2016 08:09:41 GMT
Content-Type: text/html; charset=utf-8
Status: 404 Not Found
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
Set-Cookie: request_method=GET; path=/
Set-Cookie: first_current_location=%2F; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: first_referer=; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: referer=; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: current_location=%2F; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
X-Request-Id: d16e4994ddeae80bec73120545035e75
X-Runtime: 0.025788 X-Cache: MISS from zapret
Via: 1.1 zapret (squid/3.5.19)
Connection: keep-alive
Только ради чего? Я попробовал взять свежий дамп загрузки с одного из зеркал реестра, вытащил оттуда заблокированные домены, сравнил их с нашей базой, но не нашел ни одного совпадения.
Потом я вспомнил, что на самом деле сейчас нахожусь дома и испытываю прелести самоизоляции.
И я подключен к провайдеру, в техподдержке которого я когда-то работал и некоторые контакты того времени сохранились до сих пор.
Мне повезло и после того, как я смог доходчиво объяснить, что с нами не так и какая помощь мне нужна, админ провайдера откопал для меня домен, из-за которого заблокировали наш IP.
Причиной всему оказался домен telzakaz.ru, но ситуация прояснилась не потому, что, судя по зеркала реестра , блокировать следует только 193.150.0.212. 
Разрешим этот домен и увидим замечательную картину: 
Ну да ладно, теперь он будет разрешаться и по нашему IP. Но в закачке Роскомнадзора у этого домена только один IP-адрес, и он не наш!
Я спросил, какое программное обеспечение использует мой провайдер для блокировки, потому что раньше он явно использовал другие механизмы.
Как оказалось, в этом году они реализовали решение от БанСервис .
На сайте был довольно интересный абзац:
ZapretService использует DNS-запросы для расчета IP-адресов серверов, на которых перечисленные URL-адреса расположены в реестре.Получается, что это программное обеспечение работает проактивно: система самостоятельно резолвит все домены, содержащиеся в выгрузке, собирает полученные IP в таблицу и работает по ней.
Далеко не факт, что именно этот софт используют все провайдеры, для клиентов которых мы были недоступны.
Но им воспользовался мой провайдер.
Дозвониться до каждого провайдера за разумное время не получится, тем более что подобное поведение уже было замечено и раньше даже с ТТК и Рунетом, поэтому я написал письмо владельцу домена с просьбой исключить наш IP, и на заодно начал общаться с хостингом, DNS которого использовал.
Хозяин молчал; его DNS-хостинг не захотел удалять А-запись с нашим IP по нашей просьбе (и он правильно сделал, но нам от этого легче не становится).
И в какой-то момент домен просто потерял все 14 А-записей.
Поскольку в поддержке DNS-хостинга сказали, что это не они, видимо это была реакция владельца домена на чей-то запрос.
Либо наш, либо владелец одного из 13 оставшихся IP.
Нижняя граница
Ваш веб-сайт может быть недоступен в любое время у большого количества провайдеров, в том числе у крупных автомагистралей.Для этого даже не обязательно размещать что-то запрещенное; достаточно того, что владелец любого заблокированного домена случайно наткнулся на ваш IP. Это вызывает ряд вопросов и мыслей.
Сначала, конечно, возникает вопрос: могут ли производители такого ПО и провайдеры легально сами взять и расширить список IP, которые необходимо заблокировать по своей дополнительной эвристике? Признаюсь, я не изучал закон досконально, но, видимо, могут. Скорее всего, в законе прямо не указано обратное, но это делается на всякий случай: завтра придет комиссия и попытается проверить, открывается ли ваш заблокированный сайт, а он откроется, потому что его владелец изменил ИП, но Роскомнадзор пока не успел обновить адреса в списках.
Но мы с вами понимаем возможные причины, и до инспекторов может оказаться настолько сложно достучаться, что им придется оспаривать свои выводы в суде.
Во-вторых, если закон действительно позволяет провайдерам это делать, то закон нужно менять.
Потому что важно не то, есть ли домен и/или IP в реестре, а то, содержит ли он еще информацию, запрещенную к распространению.
Это означает, что суды должны четко сформулировать причины блокировки, а Роскомнадзор, прежде чем добавить в список еще один заблокированный по IP сайт, должен проверить, существует ли еще контент, который привел к блокировке.
Ну и в-третьих, пока это светлое будущее не наступило, что нам делать? В любой момент (кажется, начинаю повторяться) с вами может случиться такое, что без доброй воли человека с заблокированным доменом вообще ничего сделать невозможно.
На данный момент мы для себя решили, что нам нужно сделать монстра, который будет периодически получать текущие загрузки, чтобы:
- Не разрешать прикреплять заблокированные домены к сайтам на нашем движке;
- Разрешить заблокированные домены и проверить, не начал ли кто-нибудь из них возвращать наш IP;
- На всякий случай также парсите логи nginx в поисках посещений заблокированных доменов (мало ли!).
Но вопрос, как это исправить, не полагаясь на чудо, остается открытым.
Теги: #ит-инфраструктура #Администрирование серверов #блокировка сайтов #HTTPS #SSL #Роскомнадзор #dura lex #как вас поздравили с Новым годом?
-
Стюв Василий Яковлевич
19 Oct, 24 -
Нужна Ли Интернету Премодерация?
19 Oct, 24 -
Или Метеор
19 Oct, 24
