Мир вокруг меняется, бизнес-правила тоже. Законопроект http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=1102471-6 на 10 ноября 2016 ещё находится на рассмотрении, но скоро будет принят. Теперь Carbon Reductor должен работать идеально, иначе каждый пропущенный пакет от ревизора может обернуться штрафом. Всё, что мы можем делать со своей стороны - мы делаем, но многие вещи может сделать только сетевой/системный администратор провайдера.

Настроить satellite

Ревизор, конечно всё проверяет, но когда проверка чревата штрафом - спокойно отладить блокировку становится невозможно. Мы сделали аналог ревизора, проверяющий HTTP, HTTPS и DNS фильтрацию и не “стучащий” никуда, кроме почты администратора: https://github.com/carbonsoft/reductor_satellite_installer

Обновить настройки зеркала трафика

Зеркалировать tcp/80, tcp/443 и udp/53 недостаточно. Нужно отправлять либо весь исходящий трафик абонентов, либо автоматически, или хотя бы периодически следить за тем, что нужно Carbon Reductor для анализа:

  • udp/53 - пока единственный порт на котором анализируется DNS трафик
  • /usr/local/Reductor/lists/load/port_http.load - файл-список tcp dst портов
  • /usr/local/Reductor/lists/load/port_https.load - файл-список tcp dst портов
  • /usr/local/Reductor/lists/load/ip_port.load - файл-список связок из ip + dst портов (tcp и udp)
  • /usr/local/Reductor/lists/load/ip_block.load - файл-список IP которые надо блокировать целиком, независимо от IP.

Настроить свою страницу-заглушку

На отдельном сервере с IP адресом, доступным абонентам. Это нужно для корректной работы DNS-спуфинга для блокировки по домену. Есть готовое решение: https://github.com/carbonsoft/reductor_blockpages

Можно настроить это на самом Carbon Reductor, но по причине в конце статьи - лучше на отдельном веб-сервере.

Настроить SNI-фильтрацию

Появился довольно неплохой модуль, фильтрующий обращения к HTTPS ресурсам по домену, указанному в поле SNI в пакете Client Hello.

menu -> “Настройка алгоритма фильтрации” -> “Фильтровать HTTPS по SNI”

Настроить DNS-фильтрацию

В реестре появилось много ресурсов, которые требуется блокировать по домену. А это означает не только по HTTP/HTTPS, а любое обращение к этому домену. В Carbon Reductor появился модуль DNS-спуфинга, вам нужно:

  1. Включить его
  2. Указать IP адрес настроенной выше страницы-заглушки.
  3. Указать IP адрес ревизора (облегчит отладку пропусков блокировок, если это не дай бог произойдёт, происходящую пост-фактум)

Интеграция с DNS-серверами

Когда DNS-запросы от Ревизора попадают в DNS-сервера провайдера, они:

  1. Не факт, что попадут в зеркало трафика Carbon Reductor
  2. А если и попадут, то не факт, что DNS-сервер примет их из-за DNSSec-валидации

Поэтому хорошим решением будет подружить DNS-сервера с Carbon Reductor, научив его отвечать на блокируемые домены IP адресом страницы-заглушки с помощью простого набора скриптов:

unbound

https://github.com/carbonsoft/named_fakezone_generator/tree/master/unbound

bind/named

https://github.com/carbonsoft/named_fakezone_generator

другие

Либо брать https://github.com/carbonsoft/named_fakezone_generator и дорабатывать под свой dns-сервер по аналогии, либо отключать DNSSec-валидацию.

Интеграция с маршрутизатором

Некоторые ресурсы необходимо блокировать полностью по IP вообще по всем протоколам. Находясь в зеркале такого сделать невозможно (хотя мы и присылаем соответствующие tcp/icmp ответы на такие обращения), поэтому блокировать их лучше на маршрутизаторе. Каким образом - на ваше усмотрение:

  1. Использование BGP/OSPF Remote Triggered Blackhole: https://github.com/carbonsoft/reductor_bgp_rtbh
  2. Настроить отправку команд на оборудование для добавления/удаления/получения списка заблокированных IP в хуке events.sh.

Скорее всего почистить собственные белые списки

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

Настроить дополнительные параметры мониторинга

Первым делом стоит вообще настроить хоть какой-то мониторинг за Carbon Reductor. Внутри там Linux, так что следить хотя бы за его состоянием будет уже хорошо. Но помимо прочего, стоит следить и за состоянием самого Carbon Reductor:

Есть готовые плагины для collectd, на их основе можно соорудить аналоги для используемых вами систем мониторинга. https://github.com/carbonsoft/collectd-reductor

Вообще мы подумываем сделать полноценный облачный мониторинг, куда сливать кучу подробностей о состоянии серверов и самостоятельно заниматься отслеживанием аномалий итд, но здесь есть много “privacy issues”, по крайней мере без согласия представителей провайдера мы это делать точно не можем.

Добиться идеального latency

В случае с анализом зеркала трафика важно, чтобы срабатывание происходило гарантированно быстро. Подробнее почитать про это можно по ссылке: https://strizhechenko.github.io/2016/11/09/reductor-and-vm.html

Кратко:

  • Купить хорошие сетевые карты и обязательно настроить их.
  • Отказаться от виртуальных машин и перейти на железо.
  • Избавиться даже от единичных потерь на стороне зеркалирующего оборудования.
  • Озаботиться тем, чтобы Carbon Reductor не занимался ничем кроме фильтрации, в том числе и веб-сервера.
  • Отправить критически важных абонентов в разрыв через Carbon Reductor чтобы не беспокоиться о потерях на свитче.
  • Заиметь резервный сервер Carbon Reductor (бесплатно) и настроить схему с их взаимодействием (скоро появится)

Что мы планируем сделать со своей стороны в будущем

Возможность разнести управление и фильтрацию по отдельным машинам.

Управление - сервер, отслеживающий и поддерживающий одинаковую конфигурацию на всех фильтрующих серверах.

  • Конфигурация
  • Веб-интерфейс
  • Выгрузки
  • Обработка списков
  • Принятие решения об обновлении себя и серверов фильтрации
  • Часть диагностики
  • Активация
  • Резолв
  • Взаимодействие с оборудованием провайдера

Фильтрация - сервер который занимается только фильтрацией трафика, не имеющий никаких периодических задач.

  • Фильтрация HTTP запросов
  • Фильтрация HTTPS по Client Hello и IP
  • Фильтрация DNS запросов без DNSSec
  • Фильтрация других протоколов по IP / IP+port
  • Загрузка URL/доменов/IP при необходимости
  • Часть самодиагностики

В итоге планируется получить схему, в которой возможно полностью избежать:

  1. Downtime при обновлениях и перезагрузках, даже если необходимо заменить модули в памяти.
  2. Нагрузки на сервере фильтрации, способной привести к задержке ответа -> пропуску фильтрации.

Это потребует выноса Carbon Reductor для управления на отдельную машину, но - к ней не будет требований по скорости работы! А это означает возможность его работы в виртуальных машинах, даже внутри легковесных Linux-контейнеров. И тут появляется возможность держать прямо на этом же сервере:

  • Carbon Reductor Manager
  • Carbon Reductor Satellite
  • Carbon Reductor Blockpage

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

Переход на Carbon Platform 5.

Готовое и проверенное годами работы Carbon Billing решение для работы нескольких бизнес-приложений. Бонусы:

  • привычно для разработки любым разработчиком Carbon Soft - проще привлечь для помощи коллег из других проектов.
  • привычно для обслуживания любым инженером техподдержки Carbon Soft - ответы в хелпдеске будут быстрее.
  • с платформой в бонус идут некоторые решения, повышающие общую надёжность системы:
    • watchdog
    • дефолтные настройки Linux
    • правильная разбивка дисков
    • система обновления, позволяющая получать только полностью проверенные обновления, но оставляющая возможность совместно обкатывать новые возможности.
  • веб-интерфейс даёт: авторизацию и возможность конфигурировать приложения в браузере. Более того, его использование снимает около 35% подзадач из эпичной задачи, которую мы пока отложили - web-интерфейс 2.0.

Изменение схемы файрвола

Использование iptables для фильтрации трафика даёт много удобств (не надо писать свой ip/tcp-стэк, логика с проходом пакетов по цепочкам тоже довольно упрощает жизнь), но и много неудобств, одно из них - match-модули не могут возвращать что-то кроме boolean значений (true/false). Это не подходит для классификации. По уму надо давно взять PF_RING / NETMAP / что-то ещё и переписать всё на работу в userspace, но это по сути разработка нового продукта и требует достаточно времени свободного от срочных задач. Увы, Роскомнадзор и Государственная Дума не спят и постоянно эти задачи создают.

Но недавно мы продумали одну хорошую идею как дать возможность классификации нашим http / https / dns модулям при использовании многих списков практически без потери производительности!

  1. match-модули будут заниматься только проверкой факта, что пакет можно разобрать и проанализировать, в противном случае пакет отбрасывается.
  2. поиск по базам доменов и URL будет происходить в TARGET модуле (который не будет получать “мусорных” пакетов), оставляющем метку с ID базы, в котором данный домен/URL найден.
  3. Далее в зависимости от этой метки будет срабатывать отдельное правило с TARGET’ом-соответствующим редиректом. Сравнение меток - дело копеечное, так что правил можно будет вешать сколько душе угодно.

Оптимизации в работе модулей фильтрации

TODO