Непосредственно у провайдера устанавливается модуль «Агент Ревизор»:
Модуль «Агент Ревизор» является структурным элементом автоматизированной системы «Ревизор» (АС «Ревизор»). Данная система предназначена для осуществления контроля над выполнением операторами связи требований по ограничению доступа в рамках положений, установленных статьями 15.1-15.4 Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации».Основной целью создания АС «Ревизор» является обеспечение мониторинга соблюдения операторами связи требований, установленных статьями 15.1-15.4 Федерального закона от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» в части выявления фактов доступа к запрещенной информации и получения подтверждающих материалов (данных) о нарушениях по ограничению доступа к запрещенной информации.
С учётом того что, если не все, то многие провайдеры установили данное устройство у себя, должна была получиться большая сеть из пробников-маяков наподобие RIPE Atlas и даже больше, но с закрытым доступом. Однако, маяк он и есть маяк чтобы посылать сигналы во все стороны, а что если их поймать и посмотреть, что мы поймали и сколько?
Прежде чем считать, посмотрим почему это вообще может быть возможно.
Немного теории
Агенты проверяют доступность ресурса, в том числе, посредством HTTP(S) запросов, как этот например:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /somepage HTTP/1.1"
TCP, 80 > 14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"
TCP, 14678 > 80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80 > 14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678 > 80, "[ACK] Seq=72 Ack=480"
Запрос помимо полезной нагрузки, состоит ещё из фазы установки соединения: обмен
SYN и SYN-ACK, и фазы завершения соединения: FIN-ACK.
Реестр запрещённой информации содержит несколько типов блокировок. Очевидно, что если ресурс будет блокироваться по IP адресу или доменному имени, то никаких запросов мы не увидим. Это самые разрушительные типы блокировок, которые приводят к недоступности всех ресурсов на одном IP адресе или всей информации на домене. Существует также тип блокировки «по URL». В этом случае система фильтрации должна разбирать HTTP заголовок запроса, чтобы точно определить что блокировать. А до него, как видно выше, должна случится фаза установки соединения которую можно попытаться отследить, так как скорее всего фильтр её пропустит.
Для этого надо выбрать подходящий свободный домен с типом блокировки «по URL» и HTTP, чтобы облегчить работу системе фильтрации, желательно давно заброшенный, для минимизации попадания постороннего трафика кроме как с Агентов. Эта задача оказалась совсем не сложной, свободных доменов в реестре запрещённой информации достаточно много и на любой вкус. Поэтому домен был приобретён, привязан к IP адресам на VPS с запущенным tcpdump и начался подсчёт.
Ревизия «Ревизоров»
Я ожидал увидеть периодические всплески запросов, что говорило бы на мой взгляд об управляемом действии. Нельзя сказать чтобы я совсем этого не увидел, но чёткой картины определённо не было:
Что неудивительно, даже на никому ненужный домен на никогда не используемый IP будет поступать просто масса не запрашиваемой информации, таков современный Интернет. Но к счастью, мне нужны были только запросы конкретного URL, поэтому все сканеры и переборщики паролей быстро были найдены. Также, достаточно просто было понять где флуд по массе однотипных запросов. Дальше я составил частоты появления IP адресов и прошёлся по всему топу вручную отделяя тех кто проскочил на предыдущих этапах. Дополнительно я вырезал все источники которые прислали по одному пакету, их было уже не много. И получилось вот это:
Небольшое лирическое отступление. Чуть больше суток спустя мой хостинг провайдер прислал письмо довольно обтекаемого содержания, дескать на ваших мощностях есть ресурс из запрещённого списка РКН поэтому он блокируется. Сначала я подумал что заблокировали мой аккаунт, это было не так. Потом я подумал что меня просто предупреждают о том, о чём я и так знаю. Но оказалось, что хостер включил свой фильтр перед моим доменом и в итоге я попал под двойную фильтрацию: со стороны провайдеров и со стороны хостера. Фильтр пропускал только концы запросов: FIN-ACK и RST срезая весь HTTP по запрещённому URL. Как видно из графика выше, после первых суток я стал получать меньше данных, но я всё равно их получал чего вполне хватило для задачи подсчёта источников запросов.
Ближе к делу. На мой взгляд совершенно чётко видно два всплеска каждый день, первый поменьше, после полуночи по Москве, второй ближе к 6 утра с хвостом до 12 дня. Пик не приходится точно на одно и то же время. Сначала я хотел выделить IP адреса попавшие только в эти периоды и каждый во все периоды, исходя из предположения что проверки Агентами выполняются периодически. Но при внимательном просмотре я достаточно быстро обнаружил периоды попадающее в другие интервалы, с другими частотами, вплоть до одного запроса каждый час. Потом я подумал про часовые пояса и что возможно в них дело, потом я подумал что вообще система может быть не синхронизирована глобально. Кроме того, наверняка, свою роль сыграет NAT и один и тот же Агент может сделать запросы с разных публичных IP.
Так как изначальная моя цель не была в точности, я посчитал вообще все адреса которые попались за неделю и получил — 2791. Количество TCP сессий установленных с одного адреса в среднем по 4, с медианой 2. Топ сессий на адрес: 464, 231, 149, 83, 77. Максимум из 95% выборки — 8 сессий на адрес. Медиана не очень высокая, напомню что по графику видна явная суточная периодичность поэтому можно было ожидать что-то около 4 до 8 за 7 суток. Если выкинуть все единожды встречающиеся сессии то как раз получим медиану равную 5. Но я не смог их исключить по чёткому признаку. Наоборот, выборочная проверка показала, что они имеют отношение к запросам запрещённого ресурса.
Адреса адресами, а в Интернете важнее автономные системы — AS, которых получилось 1510, в среднем 2 адреса на AS с медианой 1. Топ адресов на AS: 288, 77, 66, 39, 27. Максимум из 95% выборки — 4 адреса на AS. Вот тут медиана ожидаема — один Агент на провайдера. Топ тоже ожидаем — в нём крупные игроки. В большой сети Агенты, наверное, должны стоять в каждом регионе присутствия оператора, не забываем и про NAT. Если взять по странам, то максимумы будут: 1409 — RU, 42 — UA, 23 — CZ, 36 из других регионов, не RIPE NCC. Запросы не из России обращают на себя внимание. Наверное, это можно объяснить ошибками геолокации или ошибками регистраторов при заполнении данных. Или тем что Российская компания может иметь не Российские корни, или иметь иностранное представительство потому что так проще, что естественно имея дело с заграничной организацией RIPE NCC. Какая-то часть несомненно является лишней, но отделить её достоверно сложно, так как ресурс находится под блокировкой, а со вторых суток под двойной блокировкой и большинство сессий представляют собой лишь обмен несколькими служебными пакетами. Условимся на том что это небольшая часть.
Эти числа можно уже сравнивать с количеством провайдеров в России. По данным РКН лицензий на «Услуги связи по передаче данных, за исключением голоса» — 6387, но это сильно задранная оценка сверху, не все эти лицензии относятся именно к провайдерам Интернет которым нужно ставить Агента. В зоне RIPE NCC похожее число AS зарегистрированных в России — 6230, из которых не все провайдеры. UserSide делал более строгий подсчёт и получил 3940 компаний в 2017 году, и это скорее оценка сверху. В любом случае мы имеем число засветившихся AS в два с половиной раза меньше. Но тут стоит понимать что AS не строго равно провайдеру. У некоторых провайдеров нет своей AS, у некоторых их больше одной. Если предположить что Агенты всё же стоят у всех, значит кто-то фильтрует сильнее остальных, так что их запросы неотличимы от мусора если вообще доходят. Но для грубой оценки вполне терпимо, даже если что-то и потерялось из-за моей оплошности.
Про DPI
Несмотря на то что мой хостинг провайдер включил свой фильтр начиная со вторых суток, по информации за первый день можно сделать вывод что блокировки работают успешно. Только 4 источника смогли пробиться и имеют полностью законченные HTTP и TCP сессии (как в примере выше). Ещё 460 могут прислать
GET, но сессия мгновенно обрывается по RST. Обратите внимание на TTL:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80 > 14678, "[ACK] Seq=1 Ack=294"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"
TTL 50, TCP, 14678 > 80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80 > 14678, "[FIN, ACK] Seq=171 Ack=295"
TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"
#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Вариации этого могут быть различны: меньше
RST или больше ретрансмитов — зависит ещё от того что фильтр посылает исходному узлу. В любом случае это наиболее достоверный шаблон, из которого видно что запрашивался именно запрещённый ресурс. Плюс всегда есть ответ который появляется в сессии с TTL большим чем в предыдущих и последующих пакетах.
От остальных не видно даже GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Или так:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
#Опять фильтр, много раз
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Обязательно видна разница в
TTL если что-то прилетает от фильтра. Но часто может вообще ничего не прилететь:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...
Или так:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Прошло несколько секунд без трафика
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
И всё это повторяется и повторяется и повторяется, как видно на графике, точно не один раз, каждые сутки.
Про IPv6
Хорошая новость — он есть. Я могу сказать достоверно что с 5 различных IPv6 адресов происходят периодические запросы к запрещённому ресурсу, именно то поведение Агентов которое я ожидал. Причём один из IPv6 адресов не попадает под фильтрацию и я вижу полноценную сессию. Ещё с двух я увидел только по одной незавершённой сессии, одна из которых прервалась по
RST от фильтра, вторая по времени. Итого всего 7.
Так как адресов мало я подробно изучил все их и оказалось, что собственно провайдеров там всего 3, им можно аплодировать стоя! Ещё один адрес — облачный хостинг в России (не фильтрует), ещё один — исследовательский центр в Германии (есть фильтр, где?). А вот зачем они проверяют по расписанию доступность запрещённых ресурсов вопрос хороший. Оставшиеся два сделали по одному запросу и находятся в не пределов России, причём один из них фильтруется (всё-таки на транзите?).
Блокировки и Агенты это большой тормоз для IPv6, внедрение которого итак движется не очень быстро. Это печально. Те кто решил эту задачу в полной мере могут собой гордиться.
В заключение
Я не гнался за 100% точностью прошу меня за это простить, надеюсь кто-то захочет повторить такую работу с большей аккуратностью. Для меня было важно понять будет ли в принципе работать такой подход. Ответ — будет. Полученные цифры в первом приближении, я думаю, вполне достоверны.
Что можно было бы ещё сделать и что я поленился сделать — посчитать запросы к DNS. Они не фильтруются, но и не дают большой точности так как работают только для домена, а не для всего URL. Периодичность должно быть видно. Если совместить с тем что видно непосредственно в запросах, то это позволит отделить лишнее и получить больше сведений. Возможно даже определить разработчиков DNS используемых провайдерами и много что ещё.
Я совершенно не ожидал того, что для моего VPS хостер включит ещё и свой фильтр. Может быть это обычная практика. В конце концов РКН присылает запрос на удаление ресурса как раз хостеру. Но меня это не удивило и даже где-то сыграло на пользу. Фильтр работал очень эффективно срезая все правильные HTTP запросы к запрещённому URL, но не правильные, прошедшие до этого через фильтр провайдеров долетали, пусть только в виде концовок: FIN-ACK и RST — минус на минус и почти получился плюс. Кстати, IPv6 хостером не фильтровался. Конечно это повлияло на качество собранного материала, но всё равно дало возможность увидеть периодичность. Оказалось это важный момент при выборе площадки для размещения ресурсов, не забывайте интересоваться вопросом организации работы со списком запрещённых сайтов и запросами от РКН.
В начале я сравнил АС «Ревизор» с RIPE Atlas. Это сравнение вполне оправдано и большая сеть из Агентов может приносить пользу. Например, определение качества доступности ресурса из различных провайдеров различных частей страны. Можно посчитать задержки, можно строить графики, можно это всё анализировать и видеть изменения происходящие как локально так и глобально. Это не самый прямой путь, но используют же астрономы «стандартные свечи», почему не использовать Агенты? Зная (найдя) их стандартное поведение можно определять изменения которые происходят вокруг них и как это влияет на качество оказываемых услуг. И при этом не надо самостоятельно расставлять пробники по сети, их уже поставил Роскомнадзор.
Ещё один момент который я хочу затронуть, каждый инструмент может быть оружием. АС «Ревизор» закрытая сеть, но Агенты сдают всех с потрохами посылая запросы на все ресурсы из запрещённого списка. Заиметь такой ресурс не представляет ровным счётом никаких проблем. Итого, провайдеры через Агентов, сами того не желая рассказывают о своей сети много больше, чем возможно стоило бы: типы DPI и DNS, местоположение Агента (центрального узла и служебной сети?), сетевые маркеры задержек и потерь — и это только самое очевидное. Так же как кто-то может мониторить действия Агентов для улучшения доступности своих ресурсов, кто-то может это делать в других целях и этому нет препятствий. Обоюдоострый и очень многогранный инструмент получился, любой может в этом убедиться.
Комментариев нет:
Отправить комментарий