В этой истории будет рассказано о том, как ваш интернет-ресурс, особенно если вы беспокоитесь о безопасности и используете на сайте SSL, может внезапно стать недоступен для посетителей из России, якобы по воле Роскомнадзора. Вы можете сколь угодно долго пытаться найти причину у себя, но окажется, что от вас ничего не зависит и либо вам повезёт и всё разрешится само, либо предстоит долгая и упорная борьба за чистоту своего IP-адреса. Ну ещё можно от SSL отказаться, что вряд ли хорошая идея.
Всё началось вечером 28 декабря. В чате нашего саппорта промелькнуло обсуждение пары тикетов, в которых пользователи жаловались на недоступность своих сайтов. Уведомлений о том, что их IP не понравились системе защиты от атак не было, поэтому саппорту было предложено провести клиентов через стандартную систему диагностики: пинги, трассировки и всё такое.
На утро 29 декабря таких жалоб было уже с десяток, что давало повод для беспокойства. Да и у меня самого что-то было не так: по HTTP я мог зайти на наши ресурсы, а по HTTPS — нет. Я попробовал по логам nginx отследить, нет ли какой-то ругани на заходы, но не увидел там ни одного захода от имени своего IP.
Просмотр заголовков во время открытия сайта по HTTP показал, что запросы начали проходить через провайдерский прокси-сервер с добавлением заголовков типа X-Cache:MISS from zapret. Таки да, нас зароскомнадзорили.
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. Но в выгрузке Роскомнадзора у этого домена указан только один айпишник, и он не наш!
Я спросил, каким ПО пользуется мой провайдер для блокировок, потому раньше он использовал явно другие механизмы. Как оказалось, в этом году они внедрили решение от ZapretService. На сайте обнаружился довольно интересный абзац:
ZapretService путем dns-запросов вычисляет ip-адреса серверов, где располагаются перечисленные url-адреса в реестре
Получается, это ПО работает на опережение: система самостоятельно резолвит все домены, содержащиеся в выгрузке, собирает полученные IP в таблицу и работает именно по ней. Далеко не факт, что именно этим ПО пользуются все провайдеры, для клиентов которых мы оказались недоступны. Но именно мой провайдер пользовался им.
До каждого провайдера за разумное время не достучишься, тем более, что подобное поведение раньше уже замечалось даже у ТТК и Runnet, поэтому я написал владельцу домена письмо с просьбой исключить наш IP, а параллельно стал общаться с , DNS которого он использовал.
Владелец молчал, его DNS-хостинг всячески не хотел по нашей просьбе удалять A-запись с нашим IP (и правильно делал, но нам-то от этого не легче). А в какой-то момент у домена просто пропали все 14 A-записей. Так как поддержка DNS-хостинга сказала, что это не они — видимо, то была реакция владельца домена на чьё-то обращение. То ли на наше, то ли на владельца какого-то из 13 оставшихся IP.
Итог
Ваш сайт в любой момент может оказаться недоступен у большого количества провайдеров, в том числе и у крупных магистралов. Вам для этого даже не обязательно хостить что-то запрещённое, достаточно того, что владельцу любого заблокированного домена случайно попадётся под руку именно ваш IP.
Это вызывает ряд вопросов и мыслей.
Во-первых, конечно же, возникает вопрос а могут ли производители такого ПО и провайдеры по закону сами брать и расширять список IP, которые нужно подвергнуть блокировке согласно своим дополнительным эвристикам? Закон я, каюсь, досконально не изучал, но видимо могут. Скорее всего в законе явно не прописано обратное, а делается это для перестраховки: вот придёт завтра комиссия, попробует проверить, открывается ли у тебя заблокированный сайт, а он возьмёт и откроется, потому что его владелец сменил IP, но Роскомнадзор ещё не успел обновить адреса в списках. Но это мы с вами понимаем возможные причины, а до проверяющих возможно будет настолько трудно достучаться, что придётся оспаривать их выводы в суде.
Во-вторых — если закон действительно позволяет провайдерам так поступать, то закон нужно менять. Потому что должно быть важно не то, находится домен и/или IP в реестре, а то, содержится ли всё ещё на нём запрещённая к распространению информация. А значит, суды должны точно формулировать причины наложения блокировки, а Роскомнадзор, перед внесением в список очередного IP заблокированного сайта, должен проверять, а есть ли там всё ещё повлёкший блокировку контент.
Ну а в третьих — пока не наступило это светлое будущее — что делать то? В любой момент (кажется, я начинаю повторяться) у вас может случиться нечто, с которым, без доброй воли человека с заблокированным доменом, вообще ничего нельзя сделать.
Мы для себя на текущий момент решили, что нужно делать монстра, который будет периодически получать актуальную выгрузку для того, чтобы:
- Не давать прикреплять к сайтам на нашем движке заблокированные домены;
- Резолвить заблокированные домены и проверять, не начал ли какой-то из них возвращать наш IP;
- На всякий случай ещё и парсить логи nginx в поисках заходов на заблокированные домены (ну мало ли!).
И то, этот монстр поможет нам лишь быстрее узнать о наличии проблемы и её причине. А вопрос о том, как её исправлять не уповая на чудо остаётся открытым.
Автор: kemko
