qf хостовый firewall на eBPF
разграничение доступа между серверами Linux

Периметр держит границу. А доступ между серверами внутри сети открыт.

Файрвол на границе не ограничивает доступ между серверами, поэтому одно проникновение растекается по всему парку. qf — файрвол на каждом сервере (host-firewall) на eBPF: одна политика на все машины, доступ между серверами под контролем, каждое изменение с аудитом «было → стало».

Финтех с распределённым Linux-паркомWeb/DevOps-платформа на арендованных серверах Пилотные внедрения — по ролям, без раскрытия названий.
5000+
агентов на один центр управления (control plane)
≥ 5.15
минимальная версия ядра Linux
5–15 с
раскатка политики на 500 хостов
за периметром ≠ закрыто

Граница под контролем, а горизонтальный доступ между серверами внутри никем не ограничен

Купленный на границе файрвол закрывает вход снаружи, но горизонтальный доступ (east-west) между серверами внутри сегмента не заблокирован, просто невидим и никем не проверяется. Одно проникновение растекается по всему парку. Забор вокруг района есть, а между домами внутри замков нет.

«iptables не масштабируется. Точка.» · «легко отрезать себе доступ к удалённой машине» · «менять iptables на 500 машинах из одного окна браузера»
— практики, публичные обсуждения (перевод) — дословный спрос на то, что делает qf
Разбор проблемы →
как это работает

Источник правды — политика, а не хост

Управление централизовано, применение распределено: центр управления хранит политику, а eBPF на каждом сервере её применяет.

  1. 01

    Политика как код

    Правила описываются метками-селекторами (label selectors) в центре управления — один раз, с ревью, а не руками на каждом хосте.

  2. 02

    Компиляция в BPF

    Центр управления находит затронутые хосты каскадом и компилирует политику в BPF-карты. До применения — сухой прогон (dry-run).

  3. 03

    Подписанные бандлы

    Пакет политики (бандл) подписывается Ed25519 и раздаётся по взаимному TLS (mTLS). Агент применяет только проверенную подпись.

  4. 04

    Применение на eBPF/TC

    Агент пишет правила в путь данных (datapath) на TC-хуке. Без цепочек iptables и без их конфликтов.

Трафик не рвётся при потере связи (fail-open) — это выбор надёжности

Забытое правило не должно ронять прод, а разрыв связи с центром управления не рвёт трафик. Дефолт — пропускать; переход к режиму «по умолчанию запрещать» (default-deny) вводится поэтапно и наблюдаемо, а не разом из коробки.

Архитектура →
что вы получаете

Чего нет у ручного iptables

01 · аудит

Централизация с записью «было → стало»

Каждое изменение доступа фиксируется до/после. Одна консоль на весь парк вместо N разрозненных наборов правил.

02 · eBPF

eBPF на TC-хуке — без Kubernetes и etcd

Автономный центр управления, не требует кластера. «Проще Cilium» там, где парк — не Kubernetes.

03 · суверенность

Изолированный контур без интернета (air-gap) и работа без облака

Ставится из локальных артефактов, наружу не обращается (phone-home). Подходит для закрытого контура.

Предпросмотр эффекта — сухой прогон (dry-run) до применения

Видно, какие хосты и правила добавятся и уберутся и какой наблюдаемый трафик это затронет — до того, как политика уедет в прод. Это избавляет от бесконечной ручной правки и от слепого радиуса изменений.

госсектор · импортозамещение

Отечественный файрвол на каждом сервере для закрытого контура

Работает без интернета и без облака. Централизованное разграничение доступа между серверами на замену ушедшим Illumio и Guardicore — там, где периметр не видит горизонтальный трафик внутри.

слой ИБ / CISO

Доказуемое разграничение против бокового перемещения

Детерминированный файрвол: срабатывает ваше правило, а не эвристика. Одно проникновение не растекается по парку, потому что горизонтальное перемещение (lateral movement) между серверами ограничено, а каждое изменение доступа доказуемо.

Аудит «было → стало»

Каждое изменение доступа — с записью состояния до и после. Для комплаенса и разбора инцидентов.

Только проверенная подпись (verify-before-apply)

Агент применяет лишь подписанный Ed25519 пакет политики, проверив подпись до применения. Подключение хоста — одноразовым токеном (расходуется при подключении). Наружу агент не обращается — phone-home нет.

Привилегии агента — под контролем PKI

Агент работает в ядре с широкими привилегиями — это прямой фактор модели угроз. Закрыто взаимным TLS (mTLS), подписью бандлов и PKI под управлением заказчика: сертификаты выпускает центр управления.

В вашу систему сбора событий (SIEM)

События — вердикты (verdict), системные и аудит — в форматах CEF/LEEF/ECS/RFC5424 по syslog/HTTP/Kafka. Вердикт = сработавшее ваше правило, без шума ложных тревог.

слой DevOps / SRE

Централизованный eBPF host-firewall. Без Kubernetes, без etcd, без ручного iptables

Файрвол теперь в вашем GitOps: Terraform, ревью в PR, подписанные бандлы и аудит-след. Один процесс для Dev, Sec и Ops.

Terraform-провайдер (устанавливается локально, не в публичном Registry) · сухой прогон (dry-run) + каскад + откат к прошлому поколению бандла (история версий политики, аудит «было → стало») · адаптивное подключение (attach): TCX на ядре ≥6.6 сосуществует с Cilium.

≤ 24k/с
приём событий
256 МБ
от — минимальный след центра управления
32 / 2048
правил на ядрах 5.15–5.16 / ≥5.17
30–90 с
раскатка на 1000 хостов

Пределы: до 2048 правил на ядрах ≥5.17; на ядре <6.6 вместе с Cilium attach невозможен.

Ранний доступ (early access)облако

Управляемый qf без своего центра управления — в раннем доступе

Облачная версия в приватной бете: ограниченные места, без гарантий доступности. Доступ по запросу.

Доступ к бете
частые вопросы

Вопросы перед внедрением

Чем qf отличается от iptables?

Одна политика в центре управления вместо ручных правил на каждом хосте: метки-селекторы, каскад на затронутые хосты, сухой прогон (dry-run) и аудит «было → стало». Применение — на eBPF/TC, без цепочек iptables.

Нужен ли Kubernetes?

Нет. Центр управления автономен, без k8s и etcd. Агенты ставятся на любые хосты Linux (deb/rpm/Ansible).

Работает ли в закрытом контуре?

Да. Ставится из локальных артефактов, обновления — через registry-mirror внутри периметра, привязка CA по отпечатку. Никакого обращения наружу.

Это default-deny из коробки?

Нет. По умолчанию — fail-open (пропускать), чтобы забытое правило не отрезало хост. Переход к режиму «по умолчанию запрещать» (default-deny) — управляемый и поэтапный: сначала наблюдение, потом запрет.

Вы в реестре российского ПО?

Внесение в реестр запланировано на Q4 2026, сертификацию ФСТЭК — на 2027. Аналог класса (Segment, №27030) в реестре уже есть; qf идёт этим путём. Коммерческие внедрения возможны и до внесения.

qf рядом с текущими правилами (coexist) — без риска для прода

Демо и пилот работают в режиме сосуществования с текущими правилами и ничего не ломают. Модель владения: установка в вашем контуре (self-hosted), поддержка по тарифу. Продукт проходит два пилота по ролям. Ограниченные места в облачной бете.