Переход от наблюдения к default deny
Переход к default deny выполняется поэтапно: сначала трафик наблюдается правилом
log, затем для проверенных потоков добавляются allow, а оставшийся трафик
закрывается правилом deny. Такой порядок снижает риск потери доступа к хосту.
Почему это работает так
У qf нет отдельного режима наблюдения. Datapath всегда активен, но только действие
deny отбрасывает пакет. Действия allow и log пропускают пакет, а log
дополнительно создаёт событие. Default action хоста равен ALLOW, поэтому трафик
без совпавшего правила проходит.
Поэтому правило log подходит для наблюдения перед переключением того же правила
на deny.
Шаг 1. Установка — хост в режиме ALLOW
Агент ставится и энроллится по install.md или host-enrollment.md. Сразу после энролмента действие по умолчанию — ALLOW: трафик не режется, но датапас уже видит и может логировать пакеты.
Шаг 2. Learn-mode — catch-all log
На хост назначается политика с широким правилом-наблюдателем: action = log,
match = нужное направление и протокол (например, ingress, tcp, без
ограничения по порту), низкий приоритет (большое число Priority — чтобы
пропускать вперёд будущие точечные allow). Поскольку log пропускает трафик,
ничего не ломается, а каждый матч уходит событием (log_events).
Период наблюдения должен покрывать обычную нагрузку, резервное копирование и плановые задания. Готовые периоды отчёта аналитики: сутки, двое суток, две недели и месяц.
Шаг 3. Анализ — список используемых портов
События catch-all log — это ровно тот трафик, который надо разобрать перед
lockdown. Два пути, по объёму:
- Сервис аналитики (analytics.md) показывает наиболее частые
порты и источники за выбранный период. Это кандидаты для allow-list, а не полный
перечень: каждый срез ограничен первыми N значениями. Полнота проверяется по
Verdicts и данным SIEM. Для правил с реальными адресами нужен
redact=noneв доверенном контуре;hashпозволяет сопоставлять адреса, но не подходит как значение CIDR в политике. - Консоль Control Plane, страницы Verdicts и Flows, подходит для разбора одного хоста. Аналитика и Verdicts видят только логируемые события.
Порт управления (SSH, 22) и всё, без чего хост потеряет обслуживаемость, входят
в allow-list обязательно.
Шаг 4. Разрешить используемое
Для каждого нужного порта заводится правило allow с меньшим Priority, чем у
catch-all-наблюдателя (меньше число = раньше проверяется = главнее). Точечные
allow перехватывают легитимный трафик первыми, catch-all остаётся под ними.
На этом шаге catch-all по-прежнему log: allow-правила уже действуют, но
неразрешённый трафик всё ещё проходит и логируется. Остаток в catch-all — то, что
закроется после lockdown — виден в отчёте аналитики с фильтром по имени
catch-all-правила (rule=<имя>) или на странице Verdicts. Правило готово к
переключению, когда в catch-all не остаётся легитимного трафика.
Шаг 5. Lockdown — log → deny
Когда allow-list покрывает легитимный трафик, catch-all-правило переключается с
log на deny. После подтверждения нового поколения агентом трафик без явного
allow попадает в завершающее правило deny и отбрасывается.
Итоговая раскладка на хосте: точечные allow с меньшим Priority + один
baseline-deny с наибольшим Priority (проверяется последним).
Что проверить до переключения
- Порт управления не защищён автоматически. Management guard создаёт исходящие
разрешения для IPv4-адресов gRPC- и enrollment-endpoint при старте агента. При
смене DNS-адреса нужен перезапуск агента. Guard не защищает SSH (
22) и другой административный доступ: baseline-denyзакроет его без явногоallow. - Политика проверяется сначала на одном хосте, затем на небольшой группе.
Baseline
denyс селектором на весь парк требует отдельного подтверждения.
См. также
- policy-management.md — модель правил, поля
match, приоритеты и проверка зоны влияния. - service-consumer.md — тот же приём
log→denyдля одного сервиса (открыть порт только его потребителям). - selector.md — кому применяется политика.
- analytics.md — отчёты по событиям фаервола: breakdown по портам/источникам с фильтром по хосту/правилу, окна, экспорт allow-list.