Документация
Bcloud Catalyst — гибридный файрвол с ядром на eBPF/XDP. Эта документация описывает установку, модель политик, работу с 5 зонами доступности и API.
Введение
Catalyst работает на двух уровнях: локальном (ядро на узле — XDP-программа, конвертирует YAML-политики в BPF-байткод) и облачном (контроллер, агрегирует телеметрию, распространяет политики и обновления Threat Intelligence).
Даже при полной потере связи с контроллером каждый узел продолжает фильтровать трафик по последней применённой версии политики — это fail-static, а не fail-open.
Быстрый старт
Установка за 60 секунд на чистом Ubuntu 24.04:
eu-central-1 (Frankfurt).
Сменить зону можно в панели или флагом --zone при catalyst init.
Требования
| Компонент | Минимум | Рекомендуется |
|---|---|---|
| CPU | 4 vCPU | 8+ vCPU (XDP native) |
| RAM | 4 GB | 16 GB |
| Диск | 20 GB SSD | NVMe, RAID1 |
| Ядро Linux | 5.15 | 6.1+ (полная поддержка XDP) |
| ОС | Ubuntu 22.04 / Debian 12 | Ubuntu 24.04 |
| Сеть | 1 Gbps | 10 Gbps |
Установка
Из репозитория (рекомендуется)
Бинарник вручную
Docker
--privileged и сетевой интерфейс
в host-режиме. В generic-режиме (без XDP-native) privileged не требуется,
но задержка вырастает с ~18 µs до ~200 µs.
Узлы
Узел (node) — это один сервер или VM, на котором запущен демон Catalyst.
Каждый узел имеет уникальный идентификатор вида Pl-1_FH, привязан к зоне
доступности и обменивается с контроллером по mTLS.
Команды управления узлом:
Правила
Правило (rule) — минимальная единица фильтрации: одно условие, одно действие, один приоритет. Правила компилируются в BPF-байткод и хранятся в кольцевом буфере ядра.
Доступные действия:
| Действие | Описание | Задержка |
|---|---|---|
allow | Пропустить пакет | ~2 µs |
deny | Отбросить (XDP_DROP) | ~18 µs |
rate_limit | Ограничить по pps | ~22 µs |
redirect | Перенаправить в другой CPU / интерфейс | ~15 µs |
log_only | Пропустить + залогировать | ~35 µs |
Политики
Политика (policy) — набор правил + дефолты + метаданные, применяемый атомарно. Политики хранятся в Git-совместимом репозитории, применение требует явного подтверждения (или включённого auto-apply в CI).
Жизненный цикл политики:
draft— черновик, ещё не влияет на трафикstaged— скомпилирована в BPF, ждёт примененияapplied— активна на узлахarchived— откатили, хранится для истории
Зоны доступности
Catalyst работает в 5 зонах. Узел привязан к одной зоне, контроллер — глобальный; между зонами политики синхронизируются через gossip-протокол.
Кросс-зонное взаимодействие работает через control.catalyst.b-cloud.xyz
(anycast). При падении одной зоны остальные продолжают обслуживать трафик
без потери консистентности политик.
CLI
Основные команды catalyst:
| Команда | Описание |
|---|---|
catalyst status | Краткий статус узла |
catalyst rules list | Список активных правил |
catalyst rules add -f rule.yaml | Добавить правило из файла |
catalyst policy apply -f policy.yaml | Применить политику |
catalyst policy rollback | Откат к предыдущей версии |
catalyst metrics | Метрики в реальном времени |
catalyst logs tail -f | Поток логов |
catalyst zone switch us-east-1 | Перевести узел в другую зону |
Web UI
Панель доступна по адресу catalyst.b-cloud.xyz. Разделы: Обзор, Правила, Трафик, Журнал, Узлы, Политики, Настройки. Все действия логируются и видны в журнале аудита.
REST API
Полная спецификация — в разделе API Reference.
База: https://control.catalyst.b-cloud.xyz/v1. Аутентификация — Bearer-токен.
Threat Intelligence
Catalyst подтягивает индикаторы компрометации (IoC) из трёх источников: Catalyst Global (собственный фид), AbuseIPDB и AlienVault OTX. Обновление — каждые 30 секунд, приоритет — high-confidence фиды.
| Фид | Обновление | Объём |
|---|---|---|
| Catalyst Global | 30 сек | ~ 2.4M IoC |
| AbuseIPDB | 5 мин | ~ 800k IoC |
| AlienVault OTX | 1 час | ~ 3.1M IoC |
Мониторинг
Метрики экспортируются в Prometheus-формате на :9100/metrics.
Ключевые:
catalyst_xdp_latency_us— задержка XDP-фильтраcatalyst_pps_total— пакетов в секундуcatalyst_drops_total— отброшено пакетов (по правилам)catalyst_bpf_programs_loaded— активные BPF-программыcatalyst_conntrack_entries— активные соединения
Алерты по умолчанию:
| Условие | Уровень | Действие |
|---|---|---|
| Latency > 100 µs | WARN | Уведомление в Telegram |
| Latency > 500 µs | CRIT | Уведомление + email |
| Drops > 10k/мин | WARN | Telegram |
| BPF load fail | CRIT | PagerDuty + rollback |
Бэкапы
Политики хранятся в Git — бэкап делается автоматически каждый пуш. Метрики хранятся 90 дней. Журналы событий — 30 дней (в Enterprise — 365 дней).
Безопасность
- Все узлы общаются с контроллером по mTLS (X.509, ротация 90 дней)
- Ключи хранятся в kernel keyring + опционально HashiCorp Vault
- Подпись BPF-байткода — Ed25519, узел отказывается загружать неподписанные программы
- Аудит-лог immutable (write-once), экспорт в S3 с object lock
- Все API-вызовы — OAuth2 + IP allowlist + rate limit
FAQ
Что будет, если контроллер недоступен?
Узел продолжает работать по последней применённой политике (fail-static). Попытки синхронизации возобновляются с exponential backoff до 5 минут.
Можно ли использовать Catalyst без облака?
Да — в режиме standalone. Локальная панель, локальный Git,
без центрального контроллера. Доступно в тарифе STARTER.
Как перевести узел в другую зону?
catalyst zone switch <zone-id>. Соединения дренируются,
узел переподключается к контроллеру в новой зоне. Downtime: ~200 мс.
Что происходит при переполнении conntrack?
XDP-слой продолжает блокировать пакеты по правилам, но stateful-проверки
(established-соединения) могут отбрасываться. Мониторь
catalyst_conntrack_entries — при 80% от лимита настраивай алерт.
Поддерживается ли Windows?
Нет. Catalyst работает только на Linux с ядром ≥ 5.15. Поддержка FreeBSD и OpenBSD — в roadmap на 2027.