Привет, $username!
Хотел рассказать о своём проекте OpenShield. OpenShield – это фарвол для Linux с контролем сетевой активности отдельных приложений, написанный на Rust. Для управления используется терминальный интерфейс, а фильтрацией пакетов занимается nftables с возможностью переключения на iptables. В режиме обучения программа пропускает исходящий трафик и автоматически создаёт разрешающие правила. Затем можно перейти в режим Enforcing: соединения, для которых нет разрешающего правила, будут блокироваться. Правила можно привязывать к cgroup, пути исполняемого файла и параметрам запуска, дополняя ограничениями по адресам, портам и протоколам. Поддерживаются действия accept, drop и reject, а также временное отключение правил без их удаления.
Идея создать свой аналог OpenSnitch появилась довольно давно, но не было окончательного видения проекта. Когда я понял что должно получиться, закипела работа.
Я написал на GitHub, что OpenShield является форком opensnitch, наверное это не совсем так, поскольку заимствована лишь идея, а код написан заново, отличаются механизмы работы и задачи приложения. Поэтому точнее было бы назвать OpenShield самостоятельной реализацией, вдохновлённой OpenSnitch. В OpenSnitch заметный акцент сделан на интерактивном контроле исходящих соединений через графический интерфейс; также есть управление системным фаерволом и несколькими узлами. В OpenShield я делаю упор на локальную политику защиты хоста и работу через терминал, в том числе на серверах без графического окружения. Основной сценарий — собрать правила в режиме обучения, проверить их и перейти к фильтрации по явно разрешённым соединениям.
Отдельное внимание уделяется поведению при ошибках. В режиме Enforcing невозможность достоверно определить приложение не должна превращаться в разрешение трафика: неоднозначная атрибуция приводит к блокировке соответствующего пакета. При критических сбоях предусмотрен аварийный режим BlockAll. Изменять правила и режим работы может только root, а наблюдение доступно участникам группы openshield. Управление и мониторинг разделены между локальными Unix-сокетами с проверкой учётных данных клиента; сетевого управляющего API нет.
Демон и TUI написаны на Rust, в собственном коде запрещён unsafe. Дополнительно ограничены размеры сообщений, очереди и время обработки запросов, предусмотрены проверки сохранённого состояния и тесты поведения при перегрузке. Это не обещание отсутствия уязвимостей и не утверждение, что OpenSnitch небезопасен, а описание выбранных инженерных приоритетов. Обучение тоже не определяет, заслуживает ли приложение доверия: оно лишь фиксирует наблюдавшуюся активность, поэтому полученные разрешения необходимо проверять перед включением Enforcing.
Довольно продолжительное время было уделено производительности приложения, однако она пока остаётся слабым местом при большом количестве коротких соединений и интенсивном исходящем UDP-трафике, особенно состоящем из множества небольших пакетов. Здесь важнее не столько объём переданных данных, сколько количество пакетов и новых соединений, для которых требуется определить приложение.
Это связано со стоимостью проверки правил, привязанных к приложениям. Обычные сетевые правила — адреса, порты, протоколы и интерфейсы — обрабатываются непосредственно ядром через nftables или iptables. Если же решение требует проверки приложения, пакет передаётся демону через NFQUEUE. Демон устанавливает владельца сокета, проверяет идентичность процесса и сопоставляет её с условиями правила: путём исполняемого файла, cgroup, аргументами запуска и другими заданными признаками. Такая проверка существенно дороже сравнения адреса и порта.
Для TCP предусмотрено ускорение: после авторизации соединения его established-трафик может обрабатываться в ядре через conntrack с проверкой поколения политики. Поэтому длительное разрешённое TCP-соединение обычно обходится дешевле постоянного открытия новых. Для UDP, не разрешённого отдельным сетевым правилом, проверка приложения повторяется для каждого пакета, требующего прикладного решения. Именно этот сценарий особенно чувствителен к PPS: даже небольшой по мегабитам поток способен заметно загрузить демон и увеличить задержки. Используемые кеши ускоряют поиск владельца, но не заменяют проверку актуальности его идентичности безусловным повторным разрешением.
Я представляю первую публичную версию, где представлен основной набор функций приложения, над производительность ещё предстоит работать. В OpenSnitch механизм проверок проще, поэтому его работа не даёт подобной нагрузки на систему, возможно схожий режим появится и в OpenShield.
Приложение собирается для Debian 12 и 13, Ubuntu 22.04, 24.04 и 26.04, Fedora 43 и 44, AlmaLinux 9 и 10, Rocky Linux 9 и 10, openSUSE Leap 16.0, openSUSE Tumbleweed, Alpine Linux 3.23 и 3.24, а также Arch Linux. В зависимости от дистрибутива предусмотрены пакеты для x86_64 (amd64), 32-разрядного x86 (i586/i686), ARMv5, ARMv6, ARMv7, ARM64 (aarch64), PowerPC 64 LE (ppc64le), IBM Z (s390x) и RISC-V 64 (riscv64). Это общий перечень архитектур: не каждая комбинация дистрибутива и архитектуры входит в матрицу сборки.
Предрелизные проверки установки пакетов и функциональные тесты фаервола выполняются:
- на x86_64 — для всех перечисленных дистрибутивов и версий;
- на ARM64 — для всех перечисленных, кроме Arch Linux;
- на 32-разрядном x86 — для Debian 12 и 13, AlmaLinux 10, Alpine Linux 3.23 и 3.24, openSUSE Tumbleweed.
Всего получается 37 комбинаций дистрибутива и архитектуры. Для каждой проверяются nftables и резервный iptables, включая обучение, переход в Enforcing и применение правил. Отдельный performance gate запускается на openSUSE Tumbleweed x86_64.
Для остальных архитектур пока выполняются сборка, проверка формата исполняемых файлов и пробный запуск --version; полноценного тестирования установки и фильтрации трафика на них нет. Контейнерные проверки также не означают проверку собственного ядра каждого дистрибутива.
Скачать и попробовать приложение можно по последнему актуальному тегу v0.2.4
Сильно не пинайте, буду благодарен за любые отзывы и комментарии.
Спасибо, что дочитали до конца.
