Как оператору экономно блокировать ресурсы из Реестра запрещенных сайтов?

Хотим мы этого или нет, но реестр запрещённых сайтов — это наша реальность. 30 июля 2012 был опубликован Федеральный Закон за номером 139 «О внесении изменений в Федеральный закон „О защите детей от информации, причиняющей вред их здоровью и развитию“ и отдельные законодательные акты Российской Федерации по вопросу ограничения доступа к противоправной информации в сети Интернет». А собственно сам Единый Реестр Запрещённых Сайтов вступил в силу 1-го ноября 2012.

Прежде чем переходить к собственно технической составляющей статьи, надо бы пару слов сказать о том, что нужно сделать, чтобы попасть в этот злополучный реестр. Всем вам известно, что теперь на территории России запрещено распространение информации о детской порнографии, наркотиках, способах самоубийства и прочем. Если какая-то страница попала под прицел, владелец сайта в течение суток должен удалить эту страницу. Если он этого не сделал, хостинг-повайдер должен заблокировать доступ в течение тех же суток. Если и этого не сделано, то тогда уж сайт попадает в реестр и ответственность за блокировку ложится на операторов связи. Реестр обновляется каждый час и в течение суток оператор должен заблокировать новые сайты.

В идеальном мире это должно работать именно так, но с одной стороны не всегда владелец получает уведомления, с другой всё-таки Роскомнадзор понимает, что далеко не все провайдеры имеют техническую возможность реализовать всё быстро, и закрывают глаза на некоторые задержки.

При этом в законе хоть и дифференцируются понятия “доменное имя”, “URL” и “IP-адрес”, но порядок применения блокировки не оговаривается. Главное, чтобы сайт не открывался. То есть вы можете ограничить доступ на конкретный URL, можете прикрыть весь домен или вовсе IP-адрес. И никто вам ничего не скажет, ну, кроме разве что клиентов, которые переметнутся к более адекватному провайдеру.

*Это если грубо, а тут в подробностях.

Вот собственно отсюда и начинается весь сыр бор. Дело в том, что без преувеличения можно сказать, что инфраструктура большинства провайдеров оказалась не готова к такому нововведению. Если сам законопроект потихоньку изживает свои детские болячки с блокировкой целых блогосайтов, лигитимных ресурсов и шутливых рекламных роликов, то провайдером приходится тяжко, ещё хуже приходится их клиентам.

Почему же?
Для этого надо разобраться в способах блокирования ресурсов.

1) Худший из способов во всех отношениях — по IP. Грубо говоря, берётся вывод nslookup по доменному имени, которое нужно заблокировать, и добавляется в ACL. При таком подходе, во-первых блокируются абсолютно все ресурсы, расположенные за этим публичным адресом, что является совершенно типичной ситуацией, во-вторых, владельцам заблокированных сайтов ничего не стоит сменить хостинг-провайдера или даже просто IP-адрес и продолжить работу.

С другой стороны — это самый простой и реализуемый практически на любом оборудовании способ. Любой аппаратный маршрутизатор даёт возможность настройки так называемых ACL (Access Control List) — список контроля доступа. С его помощью можно запретить любой диапазон IP-адресов и TCP/UDP-портов.

Как правило такие вещи делаются централизованно на границе сети

Но вполне возможен вариант, когда ACL применяются на узлах агрегации или доступа. Проблемы у такого подхода (кроме озвученных уже выше) заключаются в сложности поддержки и обслуживания. Это известно любому сетевому инженеру. Менять ACL каждый день (тем более на нескольких устройствах сразу) — удовольствия мало.

С точки зрения абонента он в таком случае не увидит никаких заглушек — просто стандартную ошибку, сайт будет недоступен по таймауту.

Другое решение — это создать отдельный маршрут для этого IP-адреса. Либо в NULL, тогда ошибка вылезет сразу и скажет о том, что сервер не обнаружен, либо специальным маршрутом можно зарулить трафик на внутренний сервер, который в виде ответа вернёт страницу с информацией о том, что ресурс заблокирован на основании ФЗ-139.

На самом деле тут более рационально использовать механизм Policy Based Routing и уводить/блокировать не весь трафик, а только TCP-запросы на порт 80. Тогда все другие виды трафика не будут заблокированы.

Обойти можно анонимайзером или VPN.

Часть провайдеров блокирует доступ таким образом до сих пор.

2) Подмена DNS-записи. Поскольку провайдер, как правило, имеет свои DNS-сервера и именно их выдаёт своим абонентам, то не составляет никакого труда подменить DNS-запись.

Например, при запросе IP-адреса telecomza.ru, DNS-сервер должен возвращать адрес 93.95.98.95, полученный в свою очередь от вышестоящего DNS-сервера. Но злобный провайдер может подменить IP-адрес домена на адрес своего внутреннего сервера, например.

Теоретически при этом вы можете увидеть заглушку либо стандартную ошибку.

Обходится это заменой адреса DNS-сервера в настройках сетевых подключений (например, на публичный адрес DNS гугла — 8.8.8.8). Единственный момент: если у провайдера есть свои внутренние ресурсы, при замене адреса они станут недоступны (решается настройкой двух DNS-серверов на ПК).

Второе решение по-прежнему — использование анонимайзера, поскольку в этому случае DNS-запросы будет отправлять не ваш локальный ПК, а сайт-анонимайзер.

3) Блокировка доменного имени или конкретного URL. Обычно оборудование, которое может осуществить одно, справляется и с другим. При этом, разумеется, лучше всего блокировать конкретный URL. Например, при необходимости ограничения доступа к конкретной записи в ЖЖ, было бы странным блокировать весь домен livejournal.com.

Если в вашей сети для выхода в интернет используется прокси-сервер, то никаких проблемы быть не должно. Практически любая реализация поддерживает такой функционал (Squid, Kerio итд).

Для небольших провайдеров вполне подойдёт решение в виде перенаправления HTTP/HTTPS трафика на дополнительный сервер, где установлен программный анализатор трафика (тот же Squid)

Но, как вы понимаете, это не подходит для крупных провайдеров масштаба города или региона.

Операторы могут для этих целей использовать аппаратные файрволы или DPI-системы.

К выбору первых нужно подходить очень ответственно, потому что обычно все файрволы поддерживают анализ пакетов до 4-го уровня модели OSI. То есть это максимум TCP/UDP-порты и IP-адреса.

Но многие-таки могут работать на всех уровнях. Примерами могут служить Cisco ASA-CX, PaloAlto, Juniper SRX. Такой функционал они поддерживают либо что-называется “из коробки”, либо путём покупки дополнительных плат.

Строго говоря такие файрволы уже смело можно причислять к DPI-системам, ведь по сути это и есть Deep Packet Inspection.

И тем не менее существует класс самостоятельных DPI платформ. Практически у любого крупного вендора есть свои решения: Cisco SCE (на базе их проприетарного протокола NBAR), Huawei SIG9800, Juniper на платформе Netscreen и т.д. Из компаний чётко сосредоточенных на DPI можно вспомнить Allot, Procera, Arbor.

Наряду со всеми другими возможностями таких платформ, они прекрасно справляются с блокировкой URL и доменных имён. Можно указывать чёткое совпадение, а можно маску URL.

Списки либо создаются непосредственно на устройстве, либо импортируются из какого-либо внешнего хранилища.

То есть с помощью DPI/Firewall можно создать довольно гибкую систему, позволяющую выполнять требования Роскомнадзора. Вопрос в другом — целесообразность? Оборудование такого плана стоит десятки и сотни тысяч долларов и покупать его для блокирования сайтов, всё равно что круизный лайнер для рыбалки на Оби.

Нужно придумать применение для них, которое напрямую или косвенно будет приносить прибыль или уменьшать расходы. Не каждый оператор, особенно из мелких, может себе это позволить.

Да, конечно, в 2015 году всем придётся ставить DPI-системы, но до него ещё нужно дожить, а выполнять требования Роскомнадзора нужно уже сейчас.

Можно было бы положиться на то, что неугодные сайты заблокирует апстрим и он это сделает, имея, наверняка, в распоряжении DPI, но как это будет выглядеть, когда ваш провайдер называется — Балаган Телеком, а заглушку ваши клиенты увидят Ростелекомовскую?

На помощь спешат специализированные решения, которые сейчас начинают заполнять пустые места.

Есть программные продукты (Traffic Inspector, TMeter), которые по сути мало чем отличаются от упомянутого прежде Squid, просто они более заточены под задачи.

Есть гораздо более интересные аппаратные — Gatewall DNS Filter от Entensys, Периметр-Ф от МФИ Софт. Их цена на порядки ниже DPI и для тысяч небольших провайдеров это весьма удачный вариант.

Как правило, DPI и анализаторы трафика перехватывают первый же HTTP-запрос и перенаправляют его на свой внутренний сервер. И в этом случае вы как раз видите заглушку провайдера.

Как инженер техподдержки вендора могу сказать, что первые недели после активации реестра запрещённых сайтов была волна запросов по DPI системам.
Также остро стояла проблема с запретом видео “Невинность мусульман” и его вхождений на других сайтах

Вариантов обхода два — использовать всё те же сайты-анонимайзеры, либо на месте владельца сайта использовать HTTPS — пока ещё его не пытаются расшифровать и вообще, данные действия являются типичной атакой MITM.

Вопросы про HTTPS задают с завидной популярностью. Главный вопрос-претензия: “Как это вы не можете заблокировать конкретный URL в HTTPS? Другие могут, а вы нет?” И никакие доводы, отсылки к RFC и объяснения принципов работы SSL не дают эффекта.

Ну, а поскольку до сих пор метод блокировки не регламентирован Роскомнадзором вариант с подменой DNS вполне легитимный. Но это подвид Потёмкинской деревни.

В общем каждый провайдер сам определяет, какое решение внедрять, учитывая свои возможности и потребности.