qf хостовый firewall на eBPF
горизонтальный доступ

За периметром — не значит закрыто

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

иллюзия закрытого доступа

Периметр закрывает вход снаружи, а доступ между серверами внутри остаётся открытым

Периметровый файрвол и NGFW закрывают вход снаружи (north-south) — попытку зайти в сеть с улицы. Но внутри сегмента доступ между серверами ничем не ограничен: горизонтальный доступ (east-west) между ними не заблокирован, просто невидим и никем не проверяется. Галочка «файрвол есть» стоит, а доступ между серверами открыт.

Стоит атакующему закрепиться на одном сервере, он двигается вбок: боковое перемещение (lateral movement) по открытым внутренним связям охватывает весь парк. Периметр этого не видит: он смотрит на границу, а не на трафик между машинами внутри. Это не то, за что уже платят периметровому файрволу; это отдельный слой, которого в схеме просто нет.

Проще на бытовом примере: вокруг района стоит забор с охраной на въезде, а между домами внутри замков нет, и попавший внутрь ходит свободно. qf ставит замки на двери между серверами: разграничение доступа между серверами (микросегментация) на уровне каждого хоста. Это отдельный слой, он дополняет периметровый NGFW, а не заменяет его; где проходит честная граница покрытия, разобрано на странице архитектуры.

Архитектура и границы →
ручной iptables

Три вещи, которые ломаются первыми

Закрыть горизонтальный доступ вручную, правкой iptables на каждом хосте, теоретически можно. На масштабе это разъезжается. Конкурент здесь не другой продукт, а статус-кво: скрипты, Ansible-роли и iptables, размазанные по парку.

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

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

qf не «ещё один скрипт раскатки». Правила описываются один раз централизованно и применяются на каждом сервере детерминированно. Это правила как код (firewall as code).

01 · один источник

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

Доступ описывается метками-селекторами (label selectors) в центре управления (control plane), один раз, с ревью, а не руками на каждой машине. Хосты попадают под правило по меткам, а не по спискам IP.

02 · до применения

Каскад и сухой прогон

При изменении центр управления каскадом находит затронутые хосты и показывает в сухом прогоне (dry-run), какие правила добавятся и уберутся — до того, как что-либо уедет в прод.

03 · доказуемость

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

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

это работает на масштабе

Централизация — не в ущерб парку

Один центр управления обслуживает парк агентов; политика доезжает до всех затронутых хостов за секунды, а не за ручной обход.

5000+
агентов на один центр управления
5–15 с
раскатка политики на 500 хостов
≥ 5.15
минимальная версия ядра Linux
поведение по умолчанию

По умолчанию трафик не рвётся (fail-open) — выбор надёжности, а не дыра

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

вопросы

Частые вопросы

Нужно ли полностью отказываться от iptables?

qf работает на eBPF/TC-хуке инлайн, без цепочек iptables и без их конфликтов. Он заменяет ручное управление правилами на парке централизованной политикой; локальный iptables на отдельной машине это не отменяет, но источником правды для парка становится политика в центре управления.

Что qf не закрывает?

qf работает на L3/L4 по IPv4: адреса, диапазоны портов, протоколы, состояние соединения. Вне охвата: L7/DPI нет; непарсимый L4 (SCTP/GRE/ESP) проходит мимо правил и не попадает под запрет по умолчанию; IPv6-CIDR не энфорсится (v6 — best-effort по протоколу и порту, по умолчанию дропается). qf закрывает горизонтальный доступ на уровне L3/L4 и дополняет периметровый NGFW, а не заменяет его; подробная граница разобрана на странице архитектуры.

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

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

Нужен ли для этого Kubernetes?

Нет. Центр управления автономен — это Go-сервис и PostgreSQL, без Kubernetes и без etcd. Агенты — лёгкие процессы на хостах. Подходит для парков, которые не живут в Kubernetes.

Работает ли рядом с Cilium?

На ядрах 6.6+ qf крепится через TCX и сосуществует с Cilium. На ядрах ниже 6.6 без Cilium используется классический TC; на <6.6 вместе с Cilium агент не стартует из-за конфликта qdisc: это честный предел, а не тихий сбой.

Одна политика с аудитом вместо ручной правки правил по всему парку

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