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

Аналитика
dpi

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


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

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

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

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

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

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

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

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

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

С помощью маршрутизатора  можно запретить любой диапазон IP-адресов и TCP/UDP-портов
С помощью маршрутизатора можно запретить любой диапазон IP-адресов и TCP/UDP-портов

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

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

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

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

Также можно создать отдельный маршрут для этого IP-адреса
Также можно создать отдельный маршрут для этого IP-адреса

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

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

2) Подмена -записи. Поскольку провайдер, как правило, имеет свои 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)

Еще одно решение в виде перенаправления HTTP/HTTPS трафика на дополнительный сервер, где установлен программный анализатор трафика
Еще одно решение в виде перенаправления HTTP/HTTPS трафика на дополнительный сервер, где установлен программный анализатор трафика

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

Операторы могут для этих целей использовать аппаратные файрволы или 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 вполне легитимный. Но это подвид Потёмкинской деревни.

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

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

Возможно, вас также заинтересует:

  • Антон

    Хотелось бы уточнить, а каким обращом тот же traffic inspector может заблокировать не просто конкретный URL(эта задача решается всеми решениями такого типа) а заблокировать URL из списка запрещённых, т.е. он же должен от куда-то получить информацию о том, что этот URL запрещённый. Например в продукте компании Керио есть веб фильтр, но там нет категории которая была бы привязана к этому списку запрешённых сайтов в РФ. Основной вопрос это ведь автоматизация.

  • Dima

    Зачем использовать специализированные затычки и тратить на них свое время и деньги, когда можно совершенно бесплатно установить на свой сервер полноценную DPI платформу с производительностью до 40 Гигабит/c и с полной автоматизацией закачки всевозможных реестров
    http://vasexperts.ru/vas/index.php/site/filtering4free

    Ее ведь можно использовать не только (и не столько) для блокировки, сколько для более полезных оператору сервисов — экономии полосы, получения аналитики по протоколам и направлениям, получения доп. доходов за счет VAS услуг

    • М

      работал админом в рт-коме, был крайне негативный опыт использования
      периметра мфи софта — настоятельно не рекомендую. Когда то по заказу
      синтерры слепили «аномалию» (вероятно без откатов не обошлось), она с
      треском провалилась и на ее основе получился «пеример» для фильтрации
      ддоса и теперь на его основе блокировка урл. Крайне глючная платформа,
      постоянные зависания, перегрев и жуткие тормоза в браузере.

      Сейчас тестируем КРОЗ (блокирка урл) компании норси-транс — дешевле, работает на ура.

      • Dima

        M, зачем отвечать на тему, которая к мфи софт не имеет никакого отношения?

    • admin

      это развод!!! DPI системы жутко дорогие, чем больше гигабит пишут, тем хуже работает! ни одна система на софтварном уровне не в состоянии полноценно обрабатывать более 10 гигабит по одной простой причине, скорость последовательного чтения современной оперативной памяти порядка 10гбит/сек, записи 7-8гбит/сек, процесс приема пакетов это запись в память, процесс отправки — это чтение из памяти, а еще надо и обрабатывать данные, а там уже будет случайный доступ, а еще всякие прерывания и т.д.

      • admin

        захват трафика по BGP протоколу может привести к повышеной нагрузке на роутеры, а также расходу памяти, тк увеличивается кол-во анонсов, сейчас запрещенных урл порядка 500-600, но если их кол-во увеличится до десятков тысяч, ни к чему хорошему для роутера это не приведет!

      • Dima

        Вот это точно развод! Продаете жутко дорогие DPI ? :)
        скорость чтения памяти на порядок больше, чем вы указали
        а современные сетевые карты позволяют заливать данные прямо в кеш процессора
        скорость кеша сами найдете?

        • admin

          ага, тырю из серверной и продаю, только тссс)

          скорость кэша 20-25 Гбит/сек, скорость оперативки при последовательном чтении 10-15 Гбит, при записи меньше в полтора раза. Для серверной оперативки — медленней чем для обычной, тк серверное железо нацелено в первую очередь не на скорость, а на надежность.

          Запись в кэш — полная чушь, не возможно, ребята из интела между ядрами его кое как синхронизили, а вы говорите что сетевая карта туда пишет. Устройства пишут в оперативку минуя процессор а следовательно и кэш, отсюда и аббревиатура DMA (Direct memory access).

          Реально производительные системы делаются путем:
          - аппаратный уровень (фспга по моему)

          - специализированных платформ (а не какой то там х86х64 подобном сервере как у вас)

          - распараллеливание на ящик серверов

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

          • Dima

            для admin: не по джентльменски удалять мои комментарии, но раз вы это сделали, то удалите и свой пост, демонстрирующий вашу некомпетентность

            для остальных (пока опять не удалили):
            1) в linux команда numatest memcpy 256M
            (тест чтение + запись) 120 Гбит/сек
            2) DCA (Direct Cache Access) allows a capable I/O device, such as a network controller, to place data directly into CPU cache, reducing cache misses and improving application response times.

          • admin

            DCA пишет не в кэш level1, отсюда на порядки меньше, те 25 Гбит/сек на чтение получится, на запись естественно меньше.

  • admin

    ни кто здесь не сказал об одной крайне важной вещи, сеть оператора связи — это не один толстый кабель, куда входит и выходит трафик. Реально сеть провайдера взаимодействует с сетьями других провайдеров не в одной точке, не по одному каналу, реально от 50-500 каналов (интернет — это же паутина!) и все сводится к тому, что на КАЖДУЮ точку взаимодействия необходимо ставить подобную систему!!! смысл ставить 40гбит/сек систему на 500 каналов в 1 гигабит?) чтобы охватить все точки взаимодействия будут гигантские суммы!!!
    п.с. нужно гнать трафик по БГП в одну точку и там фильтровать. Рекламировать ни кого не буду, я за свободный интернет)

При копировании материалов ссылка обязательна.