Доброго времени суток!

В этом месяце у нас сразу два релиза. Теперь Carbon Reductor доступен на платформе Carbon, проверенной годами эксплуатации Carbon Billing 5. Carbon Reductor 8 успешно внедрён у 5 провайдеров, в него полностью портированы все исправления и доработки из версии, поставляемой в RPM для CentOS (Carbon Reductor 7). Но обо всём по порядку.

Carbon Reductor 7.4.9 300

Файрвол

Снижена нагрузка на модуль SNI-фильтрации

Теперь туда попадают только пакеты длиннее 60 байт. SNI всё равно не может оказаться в SYN/RST/FIN и других коротких пакетах без данных, но полагаться только на TCP-флаги было бы неправильно.

Изменения и исправления в блокировке HTTPS по IP

При отключении блокировки HTTPS по IP не работала блокировка адресов вида https://1.2.3.4.ru/something. Опция «Блокировать HTTPS по IP» немного изменила своё поведение:

• включено: Блокировать HTTPS по IP для всех записей в едином реестре, где встречаются HTTPS-ссылки;
• выключено: Блокировать HTTPS по IP только в случаях, если иначе заблокировать ресурс невозможно.

«Под капотом» это выглядит как разделение списка IP в файрволе на 2 ipset:

• `ip_https` — ресурсы, которые можно заблокировать только по IP, используется всегда, независимо от опций;
• `ip_https_plus` — дополнительные IP адреса для блокировки на портах HTTPS. Включается опцией «Блокировать HTTPS по IP».

Опция «Использовать nslookup» использует резолвер для расширения списка IP для ipset `ip_https_plus`.

Исправлено: не блокировались нестандартные порты HTTPS при включении опции «оптимизация подсистемы роутинга»

На самом деле, пока всего 1 порт. Однако, несмотря на то, что это исправлено — рекомендуем всё равно эту опцию выключить, она является сильно устаревшей и даёт мало пользы в большинстве случаев.

Затем не забудьте проверить изменение нагрузки на сервер (до и после выключения и рестарта) с помощью утилиты `/usr/local/Reductor/bin/net_rx_top.sh`, оно не должно превышать 25000 прерываний на ядро. В противном случае необходимо решать проблему с производительностью, лучше горизонтальным масштабированием.

Опции «Использовать SNI» и «Использовать NOTRACK» теперь включаются при обновлении автоматически

Единоразово, затем их можно отключить. Благодаря тому, что свой IP адрес мы удаляем в цепочке `raw -> PREROUTING -> mirror_info` опция NOTRACK теперь полностью безопасна. SNI-модуль успешно прошёл экспериментальную фазу и хорошо себя зарекомендовал более чем на 80 серверах, перед тем как быть включённым по умолчанию.

Прочие исправления

• редуктор не стартовал при основном маршруте через девайс, а не IP шлюза;
• использование дополнительных правил фильтрации https приводило к невозможности старта Reductor;
• DNS-спуфинг мог зацикливать HSTS-прокси, если его трафик попадал в зеркало. Сейчас трафик с его IP игнорируется.

Утилиты для отладки и обработка списков

Работа обработки списков URL ускорена в 7 раз

Однажды, в выходные была предпринята попытка всё переписать на Go, которая закончилась профилированием, изменением 8 строчек в одной функции.

Результаты замера скорости обработки списков. Окружение: CentOS 6, KVM, 2 виртуальных ядра, 1Gb RAM, виртуальный диск (qcow2, writeback), список `rkn.url_http`, на момент замера 39000 URL.

• Старая версия, python 2.6: 0m21.163s
• Старая версия, pypy2.7: 0m5.310s
• Новая версия, python2.6: 0m3.312s
• Новая версия, pypy2.7: 0m3.560s

Один из наиболее важных вариантов экранирования пропускался

Ошибка, связанная с всего-лишь одной запятой, имелась с ноября 2015 года, но никем не была замечена. Имеется только один подтверждённый факт пропуска одного URL. В итоге число предобработанных для загрузки в ядро на выходе повысилось с ≈43000 до ≈52000 (для алгоритма match-модуля это на самом деле крайне незначительно влияет на производительность).

Небольшое, но важное исправление в связке с маршрутизаторами по BGP

Скрипт для блокировки/разблокировки ресурсов по IP на маршрутизаторах некоторое время не мог найти файл `ip_block.load`. Это исправлено, но возможно имело последствия, так что всем использующим интеграцию с маршрутизаторами средствами BGP рекомендуется обновить хук и проверить, что успешно анонсируются все IP адреса. В противном случае может помочь инструкция.

Прочее

Добавлено:

• утилиты для отладки: `support_info.sh` теперь показывает статистику по дисковому пространству;
• утилиты для отладки: утилита показывающая информацию по доступным обновлениям. Запуск — `/usr/local/Reductor/bin/check_update_human.sh`;
• выгрузка списков: возможность выполнять клиентские хуки до начала выгрузки. В `userinfo/hooks/rkn_download.sh` достаточно определить функцию `client_pre_hook()`.

Исправлено:

• утилиты для отладки: скрипт `url_info.sh` пытался искать данные в старых списках;
• мастер настройки сети: L3 vlan схема не работала из коробки, не хватало опции `VLAN=yes` в шаблоне конфига интерфейса;
• обработка списков: списки Carbon Soft для временных решений качались в старом формате -> не использовались;
• обработка списков: не выкачивались сигнатуры для URL с несколькими пробелами;
• обработка списков: не работала DNS-фильтрация при пустых строках в списках провайдеров. Помимо этого обработка стала активнее и явнее отсекать невалидные данные, например URL с доменами первого уровня при обработке списков URL.

Резолвер

Не удалялись временные файлы

Могло привести к переполнению `/tmp/`, особенно там, где используется реальный `tmpfs`. Благодаря своевременному критическому обновлению проблема успела проявиться только на двух наблюдаемых мониторингом серверах, у одного из которых было отключено критическое обновление, где была устранена вручную.

Прочие исправления логики после переезда на новые списки

Теперь создаётся симлинк `/usr/local/Reductor/lists/https.resolv` для совместимости с `named fakezone generator`

С ним уже найдено и исправлено несколько багов:

• домены для отправки в прокси по DNS могли начать блокироваться по IP из-за попадения в https.resolv;
• запуск старого резолвера в cron.d приводил к занулению https.resolv;
• создание https.resolv происходит даже если резолвер выключен;
• мог быть заблокирован IP адрес страницы-заглушки.

Тесты

«Service reductor restart» всегда возвращал нулевой код возврата, даже если писал об ошибках. Это исправлено, так что у нас появились pairwise тесты параметров фильтрации, позволяющие за полторы минуты достаточно достоверно подтверждать отсутствие проблем в опциях и сочетаниях опций (пусть и только попарных, но это в разы лучше, чем ничего), приводящих к невозможности запуска.

Исправления

• satellite: Carbon Reductor Satellite стал проверять фильтрацию в 2.5 раза быстрее благодаря более оптимальному алгоритму разделения ресурсов для проверки между потоками;
• satellite: не разбирался реестр из-за неполного конфига;
• диагностика/ошибки настройки: не показывались подробности по проблемам: интеграция с маршрутизаторами, уведомления админа редиректом;
• мастер настройки: не запускался выбор метода обновления списков РКН (web, xml, pem);
• интеграция с биллингом: не работала при ненастроенной DNS-фильтрации.

Reductor 8.0.0 1395

Отличия от 7 версии

Форма поставки

Основным различием является форма поставки приложения. Теперь Carbon Reductor поделен на отдельные приложения: reductor, blockpage и https_proxy (последние два могут быть отключены), а на подходе и satellite. Каждое приложение поставляется в виде изолированного chroot-окружения, где есть всё, что ему необходимо для работы. Помимо них есть ещё два обязательных контейнера:

• base — даже не контейнер, а просто папка с утилитами для управления остальными контейнерами и парой конфигов в корне;
• auth — система авторизации в веб-интерфейс управления сервером.

Все обновления бинарные

Подтягиваются только изменения, скачивание обновления отделено от применения. Незначительным минусом является, пожалуй, размер приложений, но он заметен только при первой установке через медленный канал. В чём-то это схоже с Red Hat Atomic Host / Docker, только без заморочек с «только один запущенный процесс на контейнер» и нет ограничений на работу с ядром хост-системы. Есть и минус — больше нет возможности отката на предыдущую версию, но мы что-нибудь придумаем.

Установка происходит с универсального ISO-образа

Образ автоматически сделает надёжную разбивку дисков, используемую платформой Carbon, соберёт при необходимости софтрейд. Подробнее о процессе установки можно узнать в соответствующей статье в документации.

Диагностика происходит раз в 5 минут

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

Изменения в бизнес-процессах

Теперь новые внедрения происходят только для Carbon Reductor 8, а все изменения в первую очередь вносятся в неё, затем при необходимости бэкпортируются в Carbon Reductor 7.

Точного плана по прекращению поддержки Carbon Reductor 7 ещё нет, но мы обязательно сообщим о нём за 2-3 месяца и поможем переехать. Переезжать, пока, стоит только согласовав всё с технической поддержкой, лучше предварительно обкатав восьмую версию на тестовом сервере и убедившись в том, что с ней нет никаких проблем. Проблемы возникшие в результате самостоятельного обновления на 8 версию на продакшне, пока что, не являются критическими и не подлежат приоритетному решению.

Автоматический переезд с 7 версии на 8 сложен технически, в основном из-за недетерминированности хуков и изменений в именовании цепочек файрвола. Тем, кто использует Carbon Reductor без дополнительных наработок, будет значительно проще всё это сделать. Многие типовые хуки уже были включены в виде опций в дистрибутиве, некоторые стали частично бессмысленными после изменения схемы файрвола (ACCEPT в mangle для zabbix например).

Изменения за последний месяц в 8 версии

• исправлены многочисленные мелкие проблемы с путанницей в местоположении файлов (меняющиеся данные находятся на отдельном разделе);
• адаптирована к платформе Carbon система диагностики, теперь каждая проверка находится в отдельном файле и может быть запущена без запуска остальных;
• загрузка списков в ядро стала отказоустойчивее к проблемам отдельных модулей — если один из модулей по какой-либо причине не работает, хотя и должен:
  1. Будет выведено соответствующее сообщение об ошибке.
  2. Скрипт продолжит работу.
  3. Зальёт списки в остальные модули, если это удастся.
  4. Завершится с ошибкой.

Спасибо, что пользуетесь Carbon Reductor!

Мир вокруг меняется, бизнес-правила тоже. Законопроект на 21 ноября 2016 ещё находится на рассмотрении, но скоро будет принят. Теперь нужно внимательней следить за фильтрацией, иначе любой пропущенный пакет от «Ревизора» может обернуться штрафом. Всё, что мы можем делать со своей стороны мы делаем, но многие вещи может сделать только сетевой/системный администратор провайдера.

Пойдём по порядку

Настроить Satellite

Ревизор, конечно, всё проверяет, но когда проверка чревата штрафом спокойно отладить блокировку становится невозможно. Мы сделали аналог АС «Ревизор», проверяющий HTTP, HTTPS и DNS фильтрацию и не «стучащий» никуда, кроме почты администратора.

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

Зеркалировать 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-спуфинга для блокировки по домену. Есть готовое решение.

Можно настроить это на самом 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;
• bind/named;
• другие — либо брать bind/named и дорабатывать под свой dns-сервер по аналогии, либо отключать DNSSEC-валидацию.

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

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

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

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

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

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

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

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

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

В случае с анализом зеркала трафика важно, чтобы срабатывание происходило гарантированно быстро. Подробнее почитать про это можно по ссылке.

Кратко:

• купить хорошие сетевые карты и обязательно настроить их;
• отказаться от виртуальных машин и перейти на железо;
• избавиться даже от единичных потерь на стороне зеркалирующего оборудования;
• озаботиться тем, чтобы 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 5 решение для работы нескольких бизнес-приложений. Бонусы:

• привычно для разработки любым разработчиком Carbon Soft — проще привлечь для помощи коллег из других проектов;
• привычно для обслуживания любым инженером техподдержки Carbon Soft — ответы в хелпдеске будут быстрее;
• с платформой в бонус идут некоторые решения, повышающие общую надёжность системы:
  • watchdog;
  • дефолтные настройки Linux;
  • правильная разбивка дисков;
  • система обновления, позволяющая получать только полностью проверенные обновления, но оставляющая возможность совместно обкатывать новые возможности.
• веб-интерфейс, который даёт авторизацию и возможность конфигурировать приложения в браузере. Более того, его использование снимает около 35% подзадач из эпичной задачи, которую мы пока отложили — веб-интерфейс 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’ом-соответствующим редиректом. Сравнение меток — дело копеечное, так что правил можно будет вешать сколько душе угодно.

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

Если остались вопросы

Создайте заявку на тему в портале технической поддержке Helpdesk, мы поможем Вам с настройкой.