Netfence: eBPF-фаервол для ВМ и контейнеров

В режиме списка разрешений IPv4 link-local (169.254.0.0/16) больше не разрешён автоматически по умолчанию — сервис метаданных облака (169.254.169.254) заблокирован, если явно не добавлен в список разрешений. Это сделано намеренно: сервис метаданных является мишенью для кражи учётных данных, и изолированные рабочие нагрузки не должны иметь к нему неявный доступ. Localhost (127.0.0.0/8, ::1) и IPv6 neighbor discovery (fe80::/10, ff02::/16) по-прежнему разрешены по умолчанию, чтобы обеспечить базовую связность и работу NDP. Чтобы разрешить сервис метаданных для конкретной нагрузки, добавьте 169.254.169.254/32 в список разрешений (переопределение на уровне отдельного вложения через управляющую плоскость запланировано в дальнейшем).

IPv4 broadcast (255.255.255.255) и multicast (224.0.0.0/4) исключений не имеют и подпадают под действие политики: в режиме списка разрешений через TC трафик вида DHCP-renewal broadcasts блокируется, если не разрешён явно. Проверки исключений выполняются до применения списка запретов, поэтому заблокировать диапазон из исключения можно только отключив само исключение. Поскольку IPv4 link-local теперь отключён по умолчанию, режим списка запретов тоже способен блокировать сервис метаданных.

Бенчмарк прогретого сокета использует подключённые UDP-сокеты, чтобы изолировать стоимость хука eBPF cgroup/connect4 от задержки TCP-рукопожатия. На этом пути DNS уже разрешил домен, IP находится в пределах TTL, а IP/CIDR уже присутствует в eBPF-таблице (map).

Измеренный разброс между обычным путём, защищённым LPM и точным DNS-хостом укладывается в шум замеров.

Пути «промах в ядре — запрос к родительскому процессу» на данный момент не существует. Промах в cgroup-списке разрешений обрабатывается локально eBPF и сразу же блокируется.

Эти числа измеряют путь DNS-сервера, а не прогретый путь connect.

«Холодные» строки синхронизируются через реальный барьер мутации вложения и сбрасывают граф владения бенчмарка и снимок фиктивной exact-таблицы между запросами. Таймер работает непрерывно для сохранения локальности UDP-планировщика, а ns/op вычитает отдельно сообщаемое wall-time fixture-reset-ns/op (включая хвост предыдущего обработчика после получения пакета клиентом) и тем самым измеряет текущий клиентский Exchange. raw-total-ns/op отражает оба значения вместе. Сброс сохраняет настроенные домены политики и базовое хранилище; бенчмарк проверяет одно физическое добавление в exact-таблицу на запрос. «Прогретые» строки инициализируют владение один раз и проверяют одно физическое добавление на всю серию.

Приведённые ниже внутренние микробенчмарки владения — это диагностика масштабируемости, а не приёмочные строки для сквозного пути DNS-запросов. Кешированный хелпер оставлен только для тестов и бенчмарков; он оборачивает по одной записи за раз и повторяет валидацию домена. Как он, так и обычный трафик резолвера проходят через барьер мутации вложения, тогда как обычный трафик принимает каждый полный ответ одной транзакцией.

dns.listen_addr должен указывать на конкретный IPv4- или IPv6-адрес, доступный каждой подключённой рабочей нагрузке. Wildcard-адреса отклоняются, поскольку их нельзя объявить как конечные точки резолвера. Настроенное имя хоста разрешается один раз при запуске демона, а полученный конкретный IP используется для привязки, объявления, хранения и начальной загрузки фильтра. Значение по умолчанию 127.0.0.1 подходит только тогда, когда рабочая нагрузка разделяет сетевое пространство имён (network namespace) с демоном; контейнеру или виртуальной машине в другом namespace обычно требуется доступный адрес хоста или моста.

Attach возвращает конкретный dns_address; настройте именно этот адрес как резолвер рабочей нагрузки. Netfence устанавливает защищённую, не истекающую запись /32 или /128 для IP слушателя, чтобы режим списка разрешений мог загрузиться без правила DNS-IP от управляющей плоскости. Текущие фильтры применяют IP-префиксы, а не порты назначения, поэтому эта защищённая запись разрешает все порты на IP слушателя (не только его DNS-порт) — это особенно важно для моделей угроз при вложении в cgroup. Используйте выделенный IP слушателя, если такая широкая доступность неприемлема.

Назначенная конечная точка обслуживает UDP и TCP одновременно. UDP-ответы обрезаются до 512-байтового лимита устаревшего клиента или до объявленного им размера EDNS и несут флаг TC при необходимости — это позволяет рабочей нагрузке повторить запрос к той же конечной точке по TCP. При резолвинге на вышестоящем сервере усечённый UDP-ответ сначала повторяется по TCP к тому же вышестоящему серверу. Сбой транспорта, SERVFAIL или REFUSED переключают запрос на следующий настроенный вышестоящий сервер по порядку.

DnsConfig.upstream_servers переопределяет глобальный dns.upstream демона для одного вложения. Записи используют синтаксис host:port (IPv6-литералы в скобках), канонизируются и дедуплицируются в порядке первого появления, максимум восемь уникальных серверов. Пустой список выбирает глобальный запасной вариант.

В режимах фильтрации Netfence удаляет параметры ipv4hint и ipv6hint из ответов HTTPS/SVCB, включая соответствующие ссылки mandatory, поскольку подсказанные адреса независимо не прошли допуск фильтра. В отключённом режиме ответы вышестоящего сервера передаются без изменений.

Счётчики DNS-запросов взаимно исключают друг друга: dns_queries_allowed считает успешно отвеченные запросы, разрешённые политикой (включая NXDOMAIN), dns_queries_blocked — ответы REFUSED по политике, dns_queries_errors — пути ошибок резолвера, прокси, допуска фильтра, записи ответа и прочих. Каждый запрос увеличивает ровно один счётчик.

Каждый содержащий адреса ответ в фильтрующем режиме DNS принимается в exact IPv4/IPv6 HASH-уровень вложения одной транзакцией до возврата любого A/AAAA-адреса из секций ответа, авторитетной части или дополнительных секций. Если полный ответ не может быть представлен, резолвер возвращает SERVFAIL без адреса и сохраняет ранее принятое рабочее множество. Решения PROXY, возвращающие адреса, должны устанавливать add_to_filter; иначе они тоже закрываются с SERVFAIL. Отключённый DNS-режим является явным исключением сквозной передачи.

Exact-записи несут TTL-рёбра от нормализованного запроса к совпавшему владельцу политики. Удаление или запрет домена оперативно удаляет его последние DNS-only exact-адреса, тогда как общий адрес сохраняется, пока у него есть другой живой владелец запроса, а перекрывающийся CIDR управляющей плоскости продолжает независимо существовать в защищённом LPM-уровне. DNS DENYLIST default-allow и explicit-allow ответы тоже отслеживаются — даже пока пакетный DENYLIST игнорирует exact-разрешения — чтобы при последующем переключении пакетного режима в ALLOWLIST можно было использовать уже возвращённые кешированные адреса без повторного запроса.

Всё обычное/живое пользовательское состояние владения ограничено пятью настройками выше. Восстановленные синтетические временные рёбра освобождены от этих логических лимитов, чтобы их нельзя было забыть до сверки, но остаются ограничены физическими exact-картами IPv4/IPv6. Настроенные домены политики и живые домены запросов совместно используют max_tracked_domains, а каждая запись TTL (запрос, совпавший владелец, IP) занимает один слот max_ownership_edges.

При давлении допуск сначала проецирует прочь истёкшие TTL-рёбра. Затем он возвращает полные логические рёбра запроса/владельца с наименьшим физическим сопутствующим ущербом перед новизной, после чего применяет детерминированный наблюдаемый резолвером LRU (канонический IP разрешает равенство). Физическое вытеснение удаляет весь DNS exact-ключ и всех его DNS-владельцев. Входящий физический IP и точное входящее ребро (IP, запрос, владелец) защищены на время транзакции ответа. Восстановленное временное владение защищает свой физический ключ до авторитетной сверки, но несвязанные обычные DNS-метаданные, разделяющие этот ключ, всё равно могут быть возвращены. Авторитетные разрешения управляющей плоскости/системы и все запреты остаются в отдельных LPM-уровнях и никогда не являются кандидатами для DNS-возврата.

Скользящий бюджет churn на вложение начисляет одну единицу за новый физический exact-ключ и одну за каждый вытесненный живой физический DNS-ключ; полная замена старого на новый стоит две единицы. Обновления, только логический возврат, истечение и удаление политики стоят ноль. События остаются активными, пока их возраст меньше dns.churn_window, и истекают ровно на границе. DnsConfig.max_churn_units может только снизить потолок демона; ноль наследует его. Окно не может быть изменено управляющей плоскостью, а изменение потолка/окна демона требует перезапуска. Снижение и последующее повышение лимита вложения не сбрасывает всё ещё активную историю.

Отдельный скользящий реестр работы ограничивает дорогостоящее планирование графа владения. Быстрые обновления и обычные допуски его никогда не затрагивают. Перед тем как путь давления клонирует или анализирует граф, Netfence начисляет стабильные рабочие единицы, выведенные из текущих физических ключей, рёбер владения, отслеживаемых доменов и размера ответа относительно неизменяемых потолков демона/таблицы. Эта попытка начисления сохраняется, даже если план оказывается невозможным или последующая транзакция exact-таблицы терпит неудачу — это закрывает путь повторной попытки без мутаций при давлении CPU/аллокаций, не изменяя транзакционный физический churn-учёт выше. При потолках по умолчанию допуск обеспечивает восемь эквивалентных максимальных проходов графа в окне; снижение DnsConfig.max_churn_units оставляет как минимум один. Снижение и последующее повышение лимита никогда не пересчитывает и не забывает активную историю работы.

Когда ни одно подходящее DNS-состояние не удовлетворяет ограничению или какой-либо из скользящих допусков исчерпан, Netfence сохраняет принятое рабочее множество и возвращает SERVFAIL, не возвращая недопущенный адрес. Отказы ёмкости увеличивают map_full_drops; дроссели физического churn и работы планирования — нет. Heartbeat-ы открывают текущее состояние exact-таблицы, ёмкость и максимальные значения поколения процесса, а также совокупные LRU-вытеснения DNS, все отказы допуска и агрегированный счётчик дросселя бюджета, охватывающий оба скользящих стража. Логи давления/восстановления ёмкости, физического бюджета и рабочего бюджета ограничены по частоте независимо. Операторы могут дождаться восстановления TTL/окна, снизить churn ответов/доменов или повторные попытки при давлении на потолок либо поднять DnsConfig.max_churn_units до потолка dns.max_churn_units демона. Поднятие потолка демона требует перезапуска; увеличение filter.max_dns_rule_entries также требует пересоздания вложения, поскольку закреплённые (pinned) таблицы нельзя изменить в размере на месте.

Авторитетные CIDR управляющей плоскости и правила системы демона используют четыре независимых, невытесняемых LPM-таблицы: allow/deny × IPv4/IPv6. Каждая таблица имеет filter.max_rule_entries слотов. Начальная запись /32 или /128 DNS-слушателя является системным разрешением и учитывается в соответствующей защищённой allow-таблице. Exact-host записи DNS остаются в своих отдельных таблицах и не могут занимать эти слоты. Ни одно защищённое правило никогда не вытесняется LRU: явные разрешения, системные правила и все запреты остаются до авторизованного удаления или полной замены.

Полный SubscribedAck или BulkUpdate канонизируется, и его итоговая заполненность проверяется для всех четырёх таблиц перед мутацией. Ёмкость основана на итоговом состоянии, поэтому замена ключей в полной таблице допустима; избыточное состояние отклоняется без вытеснения или частичного принятия правил. Уцелевшие не удаляются и не добавляются повторно. Если последующий вызов syscall таблицы завершится неудачей, Netfence восстанавливает и проверяет точный инвентарь четырёх таблиц перед вызовом. Доказанный режим после отката — старый режим или BLOCK_ALL (обычно BLOCK_ALL), поэтому демон удерживает вложение в закрытом состоянии (fail-closed) до успешной полной авторитетной повторной попытки.

Состояние безопасности защищённой политики сохраняется вместе с вложением и экспортируется в heartbeat-ах. BLOCK_ALL сам по себе является нормальным, исправным настроенным режимом: policy_degraded имеет значение false, когда policy_degraded_reason пуст. Рискованная защищённая мутация, начинающаяся при исправном BLOCK_ALL, сначала журналирует protected_policy_mutation_in_progress. Это временный журнал сбоев при краше, а не стабильная диагностика: живая операция может опубликовать предполагаемый режим до окончательного сохранения с очисткой журнала, а успешное завершение само очищает журнал. Если при запуске он обнаружен после краша, запуск сначала принудительно доказывает BLOCK_ALL, затем сохраняет protected_policy_mutation_interrupted. Стабильные коды причины деградации:

Это стабильные классификации, никогда не содержащие сырой текст syscall/store. Журнал in-progress является внутренней сохранённой границей при краше; статистика heartbeat сериализуется вместе с владеющей мутацией и поэтому наблюдает либо её успешную очистку, либо стабильное преобразование отказа, но не живой промежуточный журнал. Стабильные причины деградации/прерывания удерживают пакетное применение в доказанном BLOCK_ALL и отклоняют инкрементальные команды CIDR и пакетного режима. Независимые изменения DNS-конфигурации и истечение TTL DNS могут продолжаться под этой доказанной блокировкой, но не могут очистить стабильную причину или повторно активировать пакетную политику. Для восстановления из стабильной причины требуется одно полное желаемое состояние LPM и DNS: примените BulkUpdate через управляющую плоскость или локальный API (или ответьте на свежий Subscribed восстановленного вложения с SubscribedAck). Netfence подготавливает полное защищённое состояние, применяет авторитетное DNS-состояние, активирует запрошенный режим и очищает устойчивую причину только после успешного выполнения всех шагов. При восстановлении BulkUpdate через управляющую плоскость предпочтительно использовать уникальный command_id и требовать успешного CommandResult; локальный API отклоняет command_id, поскольку его унарный RPC-результат уже сообщает об успехе или неудаче.

Heartbeat-ы открывают текущие физические записи, жёсткую ёмкость и максимальные значения поколения демона независимо для всех четырёх защищённых таблиц. Начальная загрузка включена; принятые закреплённые записи инициализируют максимальное значение нового поколения. map_full_drops является накопительным и включает отклонения при нехватке защищённой ёмкости. Если чтение заполненности завершается неудачей, демон сохраняет последний доказанный снимок и выдаёт предупреждение не чаще одного раза в 30 секунд вместо того, чтобы выдумывать новые счётчики. Для восстановления при давлении сократите полные желаемые правила ниже ёмкости каждой таблицы и повторите полное обновление. Поднятие filter.max_rule_entries применяется только при загрузке и требует пересоздания существующего закреплённого вложения. Если демон не может доказать BLOCK_ALL или надёжно записать свой маркер безопасности, он прекращает приём мутаций; устраните неисправность таблицы/хранилища и перезапустите, а не предполагайте, что применение открылось.

Локальный gRPC API не имеет аутентификации на уровне RPC. Границей авторизации является доступ к файловой системе его Unix-сокета, и каждый процесс, который может подключиться, является полностью доверенным администратором сети хоста: он может подключать или отключать хостовые eBPF-программы, заменять пакетную политику и DNS-политику, а также открывать или закрывать трафик рабочих нагрузок. Держите членство в группе сокета минимальным и защищайте родительский каталог сокета.

NETFENCE_SOCKET и NETFENCE_SOCKET_GROUP — эквивалентные переменные окружения. При запуске демон привязывает сокет в приватном промежуточном каталоге, устанавливает его группу и режим 0660, пока он недоступен, а затем публикует его атомарно. Демон удаляет любой существующий Unix-сокет по настроенному целевому пути — он не отличает устаревший сокет от сокета другого живого демона — поэтому ровно один демон должен владеть путём к сокету. Он отказывается удалять нецелевой сокет. В Linux переименование без замены (no-replace rename) предотвращает перезапись нового пути, созданного после этого удаления; при завершении демон удаляет опубликованный путь, только пока тот по-прежнему идентифицирует собственный inode сокета демона. Неверная группа, сбой владения/режима или нецелевой сокет прерывают запуск без публикации незащищённой конечной точки.

Канал управляющей плоскости является наиболее ценной поверхностью атаки в системе (тот, кто контролирует его, может отправить правила ALLOW каждой рабочей нагрузке), поэтому демон закрывается при отказе (fails closed): если control_plane.url задан, конфигурация должна явно выбрать транспорт — либо блок control_plane.tls, либо control_plane.insecure: true. URL без ни того ни другого отклоняется при запуске; неявного незашифрованного соединения по умолчанию нет. (Это намеренное изменение поведения: более старые версии молча подключались к управляющей плоскости без шифрования.)

TLS только с системными корневыми сертификатами (серверный сертификат от публичного CA, без mTLS) — просто пустой блок:

Незашифрованное соединение для локальной разработки — явное включение (взаимоисключает tls):

Сертификаты и ключи загружаются один раз при запуске, поэтому неверный путь/PEM прерывает запуск с понятной ошибкой, а не проявляется при каждом переподключении.

Демон отправляет HTTP/2 keepalive-пинги по соединению с управляющей плоскостью, чтобы молчаливо мёртвый путь (обрыв кабеля, потерянное NAT-отображение, заблокированный маршрут) был обнаружен и разорван примерно за keepalive_time + keepalive_timeout — вместо того чтобы оставаться в состоянии CONNECTED минутами до истечения TCP retransmission timeout ядра, пока каждый проксируемый DNS-запрос съедает весь свой таймаут. Переподключения регулируются джиттерированным экспоненциальным откатом (начинается с 1 с, удваивается, ±20% джиттер, ограничен reconnect_backoff_max); откат сбрасывается к минимуму только после того, как соединение оставалось стабильным 30 с, поэтому управляющая плоскость, принимающая соединения и сразу их сбрасывающая, продолжает увеличивать откат, а не молотить на минимуме.

Нулевые/незаданные значения означают значения по умолчанию — они не отключают keepalive или откат. Ваша управляющая плоскость должна разрешать эту периодичность пингов в своей политике применения keepalive gRPC (см. ниже), иначе она отклонит демон с ENHANCE_YOUR_CALM (too_many_pings).

Демон закрепляет (pin) BPF-ссылки и таблицы правил каждого вложения в bpffs (filter.bpf_pin_dir, по умолчанию /sys/fs/bpf/netfence, по одному каталогу на ID вложения). Поскольку закреплённое состояние удерживается ядром, а не процессом демона, применение продолжается, пока демон не запущен: краш (kill -9), плановая остановка или обновление оставляют последнюю известную политику (режим + все правила) в действии, а следующий запуск демона повторно принимает закреплённое состояние как есть. Восстановление никогда не повторно подключает и не перезаписывает живые таблицы, поэтому нет окна, в котором разрешённая рабочая нагрузка оказывается заблокирована или заблокированный адрес становится доступен, и нет дублирующихся вложений.

Поведение при остановке является явной настройкой (filter.detach_on_stop):

Явный Detach (RPC/CLI) или удаление живого согласованно-принадлежащего целевого объекта уничтожает закреплённое состояние вместе с вложением. При перезапуске отсутствие цели не авторизует угадывание: будущие, не зафиксированные, смешанные или иначе непроверяемые сохранённые закрепления сохраняются, а запуск прерывается для проверки.

Каталоги закреплений являются версионированным форматом хранения. Маркер схемы закрепляется последним, только после того как существуют все необходимые таблицы и ссылки. Обновление вложения предшествующего exact-уровня закрепляет две новые пустые exact-таблицы с маркером in-progress, атомарно заменяет программу каждой ссылки, повторно используя живые авторитетные таблицы, проверяет идентичность программы/таблицы и фиксирует маркер последним. Краш или неоднозначное обновление оставляет маркер незафиксированным; следующий запуск повторно обновляет каждую ссылку, используя те же таблицы. Старые и новые поколения программ применяют одну авторитетную LPM-политику во время этого ограниченного смешанного состояния, поэтому миграция никогда не открепляет и не пересоздаёт рабочий фильтр. Неизвестные, неполные или непроверяемые наборы закреплений сохраняются и прерывают запуск для проверки вместо того, чтобы быть угаданными.

Замечания о повторно принятом состоянии:

Каждая локальная мутация является тонкой CLI-кодировкой единственного RPC DaemonService.ApplyCommand(ControlCommand). Укажите ID вложения, возвращённый командой attach:

Пакетные режимы: disabled, allowlist, denylist, block-all; DNS-режимы: disabled, allowlist, denylist, proxy. DNS proxy требует доступной настроенной управляющей плоскости. Сопоставление доменов использует наиболее конкретный совпадающий суффикс; при одинаковой специфичности правил allow и deny оба совпадают — побеждает deny. CIDR и домены канонизируются. Отрицательные, некорректные или иначе недействительные TTL, перечисления, CIDR, домены, селекторы и вложенные сообщения отклоняются до мутации, поэтому недействительная команда является no-op политики.

Для полной замены apply-rules читает существующую форму BulkUpdate в protobuf JSON из файла или stdin: