В этой истории будет рассказано о том, как ваш интернет-ресурс, особенно если вы беспокоитесь о безопасности и используете на сайте 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 yacpa-api.insales.ru 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 в поисках заходов на заблокированные домены (ну мало ли!).
И то, этот монстр поможет нам лишь быстрее узнать о наличии проблемы и её причине. А вопрос о том, как её исправлять не уповая на чудо остаётся открытым.
ссылка на оригинал статьи https://habrahabr.ru/post/318806/
Добавить комментарий