Межсетевые экраны и сетевая безопасность

В предыдущих темах сеть рассматривалась как механизм доставки: коммутатор пересылает кадр, маршрутизатор — пакет, TCP гарантирует доставку потока байтов, DNS превращает имя в адрес. Каждый из этих механизмов проектировался в расчёте на добросовестных участников. Адрес источника в заголовке IP никем не проверяется, ответ ARP принимается без доказательства его подлинности, а TCP-сервер выделяет ресурсы любому, кто прислал сегмент SYN. В теме 17 было показано, как криптография защищает содержимое соединения: TLS обеспечивает конфиденциальность, целостность и подлинность сервера. Однако TLS ничего не говорит о том, кому вообще разрешено устанавливать соединение с сервером базы данных, и не мешает чужому узлу заполнить очередь входящих соединений веб-сервера.

Тема посвящена второй половине сетевой безопасности — управлению доступом и потоками. Центральное средство здесь — межсетевой экран (англ. firewall): узел или функция ядра, который пропускает или отбрасывает пакеты в соответствии с явно записанной политикой. Вокруг него строятся сегментация сети на зоны доверия, демилитаризованная зона для публичных сервисов, ограничение частоты запросов и журналирование. Экран реализует политику, а политика выводится из модели угроз, поэтому изложение идёт от принципов к устройству экранов и их реализации в Linux (netfilter и nftables), затем к зонам и DMZ, типовым угрозам и обнаружению вторжений.

Угрозы рассматриваются с позиции защищающейся стороны: каков механизм, по каким признакам его можно заметить и какие меры ему противостоят. Трансляция адресов (NAT), которая в Linux реализуется тем же netfilter, разобрана в теме 14 и здесь лишь упоминается; защищённые туннели и VPN — предмет темы 19.

Модель угроз и принципы защиты сети

Активы, нарушители и поверхность атаки

Безопасность всегда определяется относительно чего-то: защищать «сеть вообще» невозможно, потому что непонятно, от кого и ценой каких ограничений. Модель угроз (англ. threat model) отвечает на три вопроса. Первый — какие активы защищаются: данные клиентов в базе, доступность интернет-магазина, учётные записи администраторов. Второй — каковы свойства, которые нужно сохранить; классическая триада — конфиденциальность (англ. confidentiality), целостность (англ. integrity) и доступность (англ. availability), сокращённо CIA. Третий — кто нарушитель и каковы его возможности: внешний узел в Интернете, который может отправить любой пакет на публичный адрес; узел внутри локальной сети, который может отправить любой кадр в свой сегмент; администратор, ошибившийся в конфигурации.

Для «Северного узла» из сквозного примера курса модель угроз выглядит так. Порты 80 и 443 публичного веб-сайта открыты для всех, и нарушитель может отправлять на них что угодно. База данных и служба удалённого управления по SSH должны быть недоступны снаружи: их компрометация означает утечку данных или полный захват сервера. Рабочие места сотрудников обращаются в Интернет, но никто извне не должен устанавливать с ними соединения. Наконец, сотрудник или заражённый ноутбук внутри офиса — тоже возможный нарушитель, хотя и с другими возможностями.

Поверхность атаки (англ. attack surface) — совокупность точек, через которые нарушитель может взаимодействовать с системой. На сетевом уровне это множество пар «адрес — порт», до которых доходят пакеты нарушителя, плюс сами сетевые протоколы, обрабатываемые ядром (ARP, ICMP, разбор заголовков). Каждый открытый порт — это программа, разбирающая данные чужого узла. Отсюда основная инженерная цель сетевой защиты: сделать поверхность атаки минимальной и известной. Межсетевой экран решает именно эту задачу — он определяет, какие пары «источник — назначение — сервис» вообще достижимы.

Минимальные привилегии и политика «запрещено всё, что не разрешено»

Принцип минимальных привилегий (англ. principle of least privilege) сформулирован Зальцером и Шрёдером в 1975 году: каждая программа и каждый пользователь должны обладать лишь теми правами, которые необходимы для выполнения их задачи ¹². В той же работе сформулирован родственный принцип умолчаний, безопасных при отказе (англ. fail-safe defaults): решение о доступе должно основываться на явном разрешении, а не на явном запрете, поскольку ошибка в списке разрешений проявляется как отказ в доступе и быстро замечается, а ошибка в списке запретов проявляется как незамеченная брешь ¹².

В применении к межсетевым экранам эти принципы дают политику «запрещено всё, что не разрешено явно» (англ. default deny). Чесвик и Белловин, авторы одной из первых книг о межсетевых экранах, называют её единственной разумной отправной точкой: список того, что нужно, конечен и известен администратору, а список того, что опасно, бесконечен и пополняется каждый день ¹. Рекомендации NIST по межсетевым экранам предписывают то же самое: входящий трафик, не разрешённый политикой явно, должен блокироваться, а политика должна описывать как входящие, так и исходящие потоки ².

Противоположная политика «разрешено всё, что не запрещено» (англ. default allow) кажется удобнее, но страдает от асимметрии ошибок. Забытый отладочный сервис на порту 8080 при такой политике оказывается доступен из Интернета незаметно, а при default deny он просто не работает снаружи, и ошибка обнаруживается сразу.

Минимальные привилегии касаются и исходящего трафика. Веб-серверу, который только отвечает на запросы, незачем самому устанавливать соединения в Интернет. Если такой сервер скомпрометирован, запрет исходящих соединений мешает нарушителю загрузить инструменты и передать данные наружу. Фильтрацию исходящего трафика называют egress-фильтрацией; NIST рекомендует применять её наряду с фильтрацией входящего ².

Эшелонированная защита и границы её возможностей

Ни одна мера защиты не безупречна: в правилах межсетевого экрана бывают ошибки, в программах — уязвимости, у пользователей — слабые пароли. Эшелонированная защита (англ. defense in depth) предполагает несколько независимых рубежей, так что прорыв одного не означает полной компрометации. Для веб-сервера «Северного узла» рубежи выглядят так: пограничный межсетевой экран пропускает к серверу только HTTP и HTTPS; локальный межсетевой экран на самом сервере дублирует это правило; веб-приложение работает от непривилегированного пользователя; база данных принимает соединения только с адреса веб-сервера и требует пароль; все действия журналируются, а журналы уходят на отдельный сервер, недоступный из DMZ.

Важно понимать, чего межсетевой экран не делает. Он решает, какие пакеты доходят до сервиса, но не проверяет, безопасно ли содержимое разрешённых пакетов: SQL-инъекция приходит в обычном HTTPS-запросе на разрешённый порт 443. Он не защищает от нарушителя, находящегося по ту же сторону экрана, что и цель, и от вредоносной программы, устанавливающей разрешённое исходящее соединение. Экран уменьшает число мест, где нужна тщательная защита, но не заменяет её ¹.

Межсетевые экраны: от пакетного фильтра к NGFW

Пакетный фильтр без состояния

Простейший межсетевой экран — пакетный фильтр без состояния (англ. stateless packet filter). Он рассматривает каждый пакет независимо от остальных и принимает решение по полям заголовков: адресам источника и назначения, протоколу, портам, флагам TCP, входному и выходному интерфейсу. Политика записывается упорядоченным списком правил вида «условие — действие», и для пакета применяется первое совпавшее правило; если не совпало ни одно, применяется политика по умолчанию. Так работали списки доступа (ACL) маршрутизаторов конца 1980-х годов, и так до сих пор работают ACL на коммутаторах и маршрутизаторах.

Рассмотрим, как разрешить сотрудникам открывать внешние сайты. Запрос идёт от адреса 192.168.18.10 с эфемерного порта, например 45678, на адрес 203.0.113.10, порт 80. Правило для запроса очевидно: «из LAN на любой адрес, TCP, порт назначения 80 — пропустить». Но ответ сервера идёт в обратную сторону — с порта 80 на порт 45678, и для него нужно второе правило. Фильтр без состояния не знает, что этот пакет — ответ на разрешённый запрос, поэтому правило придётся записать как «из Интернета в LAN, TCP, порт источника 80, порт назначения выше 1023 — пропустить». Такое правило пропускает любой пакет нарушителя, отправленный с порта 80 на любой высокий порт внутренней сети, то есть открывает внутреннюю сеть шире, чем требуется.

Приём смягчения — проверять флаг ACK: первый сегмент TCP-соединения (SYN) его не имеет, а все последующие имеют. Правило «из Интернета пропускать только сегменты с ACK» не даёт извне начать соединение, но не мешает отправлять сегменты с ACK, не относящиеся ни к какому соединению; для UDP и ICMP подобного признака нет вовсе ¹. Ещё одна трудность — фрагментация (тема 7): номера портов есть только в первом фрагменте, и фильтру приходится либо пропускать последующие фрагменты вслепую, либо собирать пакет.

Достоинства фильтра без состояния — скорость и отсутствие памяти, которую можно исчерпать, поэтому ACL без состояния применяются на магистральных маршрутизаторах, в частности для фильтрации адресов источника по BCP 38.

Фильтр с отслеживанием состояния

Межсетевой экран с отслеживанием состояния (англ. stateful firewall) хранит таблицу соединений. Когда первый пакет нового потока разрешён политикой, экран создаёт запись, в которой записан набор из пяти полей (англ. 5-tuple): протокол, адреса и порты источника и назначения, — и вычисляет, как будет выглядеть ответный пакет (адреса и порты меняются местами). Все последующие пакеты сначала сверяются с таблицей. Пакет, принадлежащий известному соединению в любом направлении, пропускается одним общим правилом, а политика пишется только для новых соединений.

Тот же пример с веб-сайтом записывается теперь двумя строками: «пакеты известных соединений — пропустить» и «новое соединение из LAN на TCP-порт 80 — пропустить». Ответ сервера проходит потому, что он принадлежит соединению, которое начал внутренний узел; пакет нарушителя с порта 80 на высокий порт отбрасывается, потому что такого соединения в таблице нет. Политика описывает намерение, а не его следствия для отдельных пакетов.

Отслеживание состояния распространяется и на протоколы без соединений. Для UDP запись создаётся по первой датаграмме, а ответные датаграммы с переставленными адресами и портами считаются частью того же «соединения», пока не истечёт тайм-аут неактивности. Для ICMP эхо-запрос и эхо-ответ сопоставляются по идентификатору. Особую роль играют сообщения об ошибках ICMP — «адресат недостижим», «время жизни истекло», «требуется фрагментация»: они несут внутри себя заголовок исходного пакета, и экран по нему находит соединение, к которому относится ошибка. Такие пакеты называют связанными (англ. related). Их пропуск критически важен: если экран отбрасывает сообщения «требуется фрагментация», ломается определение MTU пути (тема 7), и соединения зависают на больших пакетах.

Цена состояния — память и уязвимость к её исчерпанию. Каждая запись занимает сотни байтов, таблица имеет предельный размер, и если нарушитель создаёт новые записи быстрее, чем истекают старые, таблица переполняется и экран перестаёт принимать новые соединения легитимных пользователей. Эта угроза рассматривается ниже вместе с атакой SYN flood.

Прикладные шлюзы, прокси и межсетевые экраны нового поколения

Фильтр видит заголовки до транспортного уровня, но не понимает протокол приложения. Прикладной шлюз (англ. application-level gateway), или прокси (англ. proxy), работает иначе: клиент устанавливает соединение с прокси, прокси разбирает запрос на уровне протокола (HTTP, SMTP, DNS), проверяет его по политике и сам устанавливает второе соединение с сервером. Между внутренней и внешней сетью нет сквозного TCP-соединения, и любой пакет, дошедший до сервера, сформирован программой прокси, а не нарушителем. Чесвик и Белловин описывают такие шлюзы как наиболее надёжный, но и наиболее трудоёмкий тип экрана: для каждого протокола нужна своя программа, и каждая сама становится поверхностью атаки ¹. В современной сети прикладные шлюзы — это прямые прокси для выхода сотрудников в Интернет и обратные прокси перед веб-серверами (тема 16), к которым часто добавляется фильтр веб-приложений (англ. web application firewall, WAF).

Межсетевой экран нового поколения (англ. next-generation firewall, NGFW) — маркетинговый, но устоявшийся термин для устройства, совмещающего фильтр с отслеживанием состояния, распознавание приложений по содержимому потока независимо от номера порта, систему предотвращения вторжений и привязку правил к пользователям, а не к адресам. Для анализа зашифрованного трафика такие устройства вынуждены либо ограничиваться метаданными (именем сервера SNI), либо расшифровывать трафик, выступая доверенным посредником ².

Сравнение типов межсетевых экранов приведено в таблице.

Отбросить или отклонить

У межсетевого экрана два способа не пропустить пакет. Действие drop молча уничтожает пакет: отправитель не получает ничего и через тайм-аут повторяет попытку. Действие reject уничтожает пакет и отправляет отправителю уведомление — сегмент TCP RST или сообщение ICMP «адресат недостижим» с кодом «запрещено администратором».

Выбор влияет и на удобство, и на то, что видит внешний наблюдатель. Для легитимного клиента reject лучше: программа сразу получает ошибку Connection refused или No route to host вместо зависания на десятки секунд. Для внешней границы чаще выбирают drop: нарушитель, проверяющий порты, не получает ответа и вынужден ждать тайм-аута на каждой попытке, а сам экран не тратит ресурсы на генерацию ответов — что существенно, если адрес источника подделан и ответы ушли бы третьему лицу. Разница хорошо видна при проверке политики: порт за reject с ответом TCP RST или ICMP «порт недостижим» выглядит «закрытым», порт за reject с кодом «запрещено администратором» и порт за drop — «фильтруемыми», и по этому различию можно понять, где именно и каким правилом остановлен пакет.

netfilter и nftables в Linux

Хуки netfilter и путь пакета через ядро

В ядре Linux фильтрация пакетов, трансляция адресов и отслеживание соединений построены на подсистеме netfilter. Её идея — набор хуков (англ. hooks), точек на пути пакета через сетевой стек, в которых зарегистрированные модули могут осмотреть пакет и вынести вердикт: пропустить, отбросить, поставить в очередь для программы пользователя ⁷. Для IPv4 и IPv6 определено пять хуков, а их расположение определяется тем, куда направляется пакет.

• prerouting — сразу после приёма пакета, до решения о маршрутизации. Здесь выполняется трансляция адреса назначения (DNAT, тема 14) и создаётся запись conntrack для нового потока.
• input — пакет адресован самому узлу и будет передан локальному сокету.
• forward — пакет транзитный: узел работает маршрутизатором и пересылает пакет на другой интерфейс.
• output — пакет порождён локальным процессом.
• postrouting — последняя точка перед отправкой в интерфейс; здесь выполняется трансляция адреса источника (SNAT, маскарадинг).

В семействе netdev есть ещё хук ingress, срабатывающий сразу после драйвера. Схема на рисунке ниже показывает три возможных пути пакета: входящий к локальному процессу, транзитный и исходящий от локального процесса.

Отсюда первое практическое следствие: межсетевой экран, стоящий между сетями, фильтрует в цепочке forward, а защита самого экрана (например, его службы SSH) — в цепочке input. Частая ошибка начинающих — написать правила для веб-сервера DMZ в input и удивляться, что они не действуют: пакеты к серверу через экран транзитные и в input не попадают.

В одном хуке может быть зарегистрировано несколько цепочек; порядок их вызова задаётся числовым приоритетом, меньшее значение срабатывает раньше. Отслеживание соединений регистрируется с приоритетом −200, трансляция адреса назначения — −100, фильтрация (ключевое слово filter) — 0, трансляция адреса источника — 100 ⁷. Поэтому к моменту фильтрации пакет уже сопоставлен с записью conntrack, а после DNAT фильтр видит уже новый адрес назначения.

Отслеживание соединений: conntrack и его состояния

Подсистема отслеживания соединений (англ. connection tracking, conntrack) хранит таблицу потоков, проходящих через узел, и каждому пакету присваивает состояние относительно этой таблицы ⁸. В правилах доступны следующие состояния.

• new — пакет начинает поток, которого ещё нет в таблице (для TCP — обычно сегмент SYN).
• established — пакет принадлежит потоку, в котором уже наблюдались пакеты в обоих направлениях; к этому же состоянию относятся и последующие пакеты исходного направления.
• related — пакет начинает новый поток или является сообщением об ошибке ICMP, но связан с уже существующим соединением: ICMP-ошибка, несущая заголовок пакета известного соединения, или канал данных FTP, ожидаемый по командам канала управления.
• invalid — пакет не удаётся отнести ни к одному потоку или он противоречит состоянию соединения: например, сегмент TCP с недопустимым сочетанием флагов (SYN вместе с FIN или RST) или сегмент с номером последовательности далеко за пределами окна.
• untracked — пакет явно исключён из отслеживания правилом notrack.

Важно не путать состояния conntrack с состояниями конечного автомата TCP из темы 12. Состояние established в conntrack наступает, как только экран увидел ответ, — для TCP это сегмент SYN+ACK, то есть ещё до завершения тройного рукопожатия. Внутри записи для TCP conntrack ведёт и собственный автомат (SYN_SENT, SYN_RECV, ESTABLISHED, FIN_WAIT, TIME_WAIT и т. д.), от которого зависят тайм-ауты записи. Временная диаграмма на рисунке ниже показывает, как меняется состояние при установлении соединения через экран.

Содержимое таблицы можно увидеть утилитой conntrack из пакета conntrack-tools.

# на межсетевом экране: показать отслеживаемые соединения TCP
conntrack -L -p tcp

tcp      6 431995 ESTABLISHED src=192.168.18.10 dst=203.0.113.10 sport=45678 dport=80 src=203.0.113.10 dst=192.168.18.10 sport=80 dport=45678 [ASSURED] mark=0 use=1
tcp      6 118 SYN_SENT src=203.0.113.10 dst=198.51.100.10 sport=51022 dport=22 [UNREPLIED] src=198.51.100.10 dst=203.0.113.10 sport=22 dport=51022 mark=0 use=1

Разберём первую строку. tcp 6 — протокол и его номер в заголовке IP. Число 431995 — оставшееся время жизни записи в секундах; для установленного TCP-соединения в Linux по умолчанию задано 432000 секунд, то есть пять суток, и отсчёт сбрасывается каждым пакетом ¹⁴. Далее — внутреннее состояние автомата TCP. Первая группа адресов и портов описывает исходное направление (англ. original), вторая — ожидаемое обратное (англ. reply). Если бы на экране работал маскарадинг, вторая группа содержала бы публичный адрес экрана вместо 192.168.18.10 — именно так NAT из темы 14 «вспоминает», кому вернуть ответ. Флаг ASSURED означает, что трафик наблюдался в обоих направлениях и запись не будет вытеснена первой при переполнении таблицы. Вторая строка — попытка соединения, на которую ответа не было (UNREPLIED): запись проживёт 120 секунд и исчезнет.

Основные параметры таблицы задаются переменными sysctl в net.netfilter ¹⁴. Некоторые значения по умолчанию сведены в таблицу; конкретные числа зависят от версии ядра, поэтому их стоит сверять с sysctl -a | grep conntrack на своей системе.

Когда таблица заполнена, ядро пытается вытеснить запись без флага ASSURED, а если это не удаётся, отбрасывает новый пакет и пишет в журнал ядра сообщение nf_conntrack: table full, dropping packet. Оно говорит о потоке новых соединений или о слишком малой таблице.

Язык nftables: таблицы, цепочки, правила, наборы

Исторически правила netfilter задавались утилитой iptables (и отдельными ip6tables, arptables, ebtables), в которой каждая таблица и цепочка были зашиты в ядро. С 2014 года в ядре есть nftables — новый каркас, в котором ядро предоставляет небольшую виртуальную машину для классификации пакетов, а вся структура политики определяется пользователем ⁷. Утилита nft пишет политику на едином языке для IPv4, IPv6, ARP и мостов. В современных дистрибутивах команда iptables — это обычно iptables-nft, транслирующая старый синтаксис в правила nftables; утилита iptables-translate показывает, как старое правило записывается на новом языке.

Объекты nftables образуют иерархию. Таблица (англ. table) — контейнер, принадлежащий семейству: ip, ip6, inet (IPv4 и IPv6 вместе), arp, bridge, netdev. Цепочка (англ. chain) — упорядоченный список правил; базовая цепочка привязана к хуку и имеет тип, приоритет и политику по умолчанию, а обычная цепочка вызывается из других правил переходом jump или goto и служит для структурирования. Правило (англ. rule) состоит из выражений-условий и операторов (англ. statements): accept, drop, reject, jump, counter, log, limit и т. д. Правило, у которого все условия истинны, выполняет операторы слева направо; вердикт accept или drop завершает обработку пакета в данной базовой цепочке.

Минимальная политика узла, принимающего только SSH и ICMP-эхо, выглядит так.

table inet host {
    chain input {
        type filter hook input priority filter; policy drop;
        iif "lo" accept
        ct state established,related accept
        ct state invalid drop
        tcp dport 22 ct state new counter accept
        icmp type echo-request limit rate 5/second accept
        icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert, echo-request } accept
    }
}

Порядок правил здесь существенен. Первым разрешается интерфейс lo: многие программы общаются с собой через 127.0.0.1, и его блокировка ломает их непредсказуемым образом. Вторым — пакеты известных соединений; это правило срабатывает для подавляющего большинства пакетов, и его раннее положение экономит процессорное время. Строка для ICMPv6 нужна потому, что обнаружение соседей в IPv6 (тема 11) идёт через ICMPv6.

Сильная сторона nftables — наборы (англ. sets) и словари (англ. maps). Набор — это множество значений одного типа, проверка принадлежности к которому выполняется за время, почти не зависящее от размера набора (используется хеш-таблица или дерево интервалов). Вместо сотни правил «запретить адрес X» пишется одно правило ip saddr @blocklist drop, а адреса добавляются и удаляются командами nft add element без перезагрузки политики. Наборы бывают анонимными (tcp dport { 80, 443 }) и именованными, могут содержать интервалы и префиксы (флаг interval), элементы с тайм-аутом (флаг timeout) и составные ключи, записываемые через точку: ip saddr . tcp dport. Словарь вердиктов (англ. verdict map, vmap) сопоставляет ключу действие, что позволяет одним правилом выбрать цепочку по паре интерфейсов:

iifname . oifname vmap {
    "lan0" . "ext0" : jump lan_to_inet,
    "lan0" . "dmz0" : jump lan_to_dmz,
    "ext0" . "dmz0" : jump inet_to_dmz
}

Такая запись прямо отражает матрицу «из какой зоны — в какую зону» (о ней — в следующем разделе), и каждой ячейке матрицы соответствует своя короткая цепочка. Пакет, для которого в словаре нет ключа, продолжает обработку следующим правилом и в итоге попадает под политику drop.

Политика загружается из файла командой nft -f, и загрузка атомарна: ядро либо принимает весь файл, либо, при ошибке в любой строке, оставляет старую политику нетронутой. Файл обычно начинается строкой flush ruleset, удаляющей прежние правила, — благодаря атомарности между удалением старых и добавлением новых правил нет момента, когда экран открыт.

Счётчики, журналирование и ограничение частоты

Оператор counter подсчитывает пакеты и байты, прошедшие через правило. Счётчики — главный инструмент отладки политики: если после обращения клиента счётчик разрешающего правила не изменился, а счётчик правила перед политикой drop вырос, причина отказа найдена. Просмотр — nft list ruleset или nft list chain inet filter forward; обнуление — nft reset counters.

Оператор log записывает сведения о пакете в журнал ядра (dmesg, journalctl -k) с заданным префиксом:

fw-fwd-drop: IN=ext0 OUT=lan0 MAC=... SRC=203.0.113.10 DST=192.168.18.10 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=8812 DF PROTO=TCP SPT=51034 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0

Из такой строки видно, через какие интерфейсы шёл пакет, кто и куда пытался подключиться, и какие флаги TCP были установлены (здесь SYN — попытка нового соединения). Журналирование каждого отброшенного пакета само может стать проблемой: поток мусорного трафика превращается в поток записей на диск. Поэтому перед log обычно ставят ограничение частоты, а в нагруженных системах журналируют через log group N в программу пользователя (например, ulogd2), которая агрегирует записи. Для отладки отдельного пакета удобнее трассировка: правило meta nftrace set 1 помечает пакеты, а команда nft monitor trace показывает, через какие цепочки и правила прошёл каждый помеченный пакет и каким вердиктом всё закончилось ⁷.

Оператор limit реализует ограничение частоты алгоритмом маркерного ведра (англ. token bucket). В ведро ёмкостью burst маркеров маркеры поступают с постоянной скоростью rate; каждый пакет забирает один маркер, а если ведро пусто, условие limit ложно (или, в форме limit rate over, истинно). Разберём численный пример для правила limit rate over 10/second burst 20 packets drop, применённого к новым соединениям с одного адреса. В начальный момент ведро полно: 20 маркеров. Пусть клиент открывает соединения со скоростью 50 в секунду, то есть каждые 20 мс. За первую секунду придёт 50 попыток, а маркеров будет 20 исходных плюс 10 пополненных — 30; первые примерно 30 попыток пройдут, остальные 20 будут отброшены. Во вторую и последующие секунды ведро пусто, и проходит ровно столько, сколько поступает маркеров, — 10 соединений в секунду, а 40 из 50 отбрасываются. Обычный пользователь, открывающий страницу с десятком ресурсов, укладывается в запас 20 и ограничения не замечает; источник, непрерывно создающий соединения, получает не больше 10 в секунду.

Если такое правило написать без привязки к источнику, ограничение будет общим для всех клиентов, и один шумный источник исчерпает лимит для всех остальных. Поэтому ограничение привязывают к адресу источника с помощью динамического набора: оператор update @meter { ip saddr limit rate over 10/second burst 20 packets } заводит отдельное ведро для каждого адреса, а флаг timeout набора удаляет вёдра неактивных адресов. Лабораторная работа 18 проверяет такое правило на практике.

Сегментация сети и зоны доверия

Зоны и матрица потоков

Плоская сеть, в которой любой узел может связаться с любым, удобна, но означает, что компрометация одного узла даёт нарушителю доступ ко всем остальным. Сегментация (англ. network segmentation) делит сеть на зоны — группы узлов со сходными требованиями к безопасности и сходным уровнем доверия — и пропускает трафик между зонами только через точки контроля, где действует политика. Внутри зоны трафик обычно не фильтруется, между зонами — фильтруется по принципу минимальных привилегий ².

Технически зоны создаются средствами, изученными ранее: отдельными подсетями IP (тема 6), виртуальными локальными сетями (тема 5), отдельными физическими сегментами. Граница зон проходит через маршрутизатор или межсетевой экран, и в его правилах зона удобно выражается интерфейсом, через который она подключена. Политика между зонами записывается матрицей потоков: строки — зона-источник, столбцы — зона назначения, в ячейке — какие новые соединения разрешены. Для «Северного узла» матрица выглядит так.

Матрица — это одновременно документ, понятный руководителю, и спецификация, по которой проверяются правила экрана: каждой непустой ячейке соответствует цепочка nftables, а пустые ячейки закрыты политикой drop. При аудите сравнивают не правила с правилами, а правила с матрицей. Ответные пакеты в матрице не указываются: они пропускаются отслеживанием состояния. В лабораторной работе матрица реализуется политикой из трёх частей: правило ct state established,related accept в цепочке forward, словарь iifname . oifname vmap, направляющий новые соединения в цепочку своей ячейки (lan_to_inet, lan_to_dmz, inet_to_dmz), и завершающие счётчик и журнал перед политикой drop.

Проследим несколько пакетов через такую политику. Сотрудник с адреса 192.168.18.20 открывает внешний сайт: сегмент SYN имеет состояние new, словарь направляет его в lan_to_inet, где порт 443 разрешён, а ответ сайта проходит как established. Тот же сотрудник пробует подключиться по SSH к веб-серверу: в цепочке lan_to_dmz SSH разрешён только адресам из набора admin_hosts, цепочка заканчивается без вердикта, обработка возвращается в forward, где срабатывают счётчик, журнал и политика drop. Пар ext0 . lan0 и dmz0 . ext0 в словаре нет, и во втором случае это особенно важно: если веб-сервер скомпрометирован и пытается открыть соединение наружу, оно не устанавливается, а запись в журнале с входным интерфейсом dmz0 становится серьёзным поводом для расследования.

Две ошибки в такой политике встречаются чаще прочих. Без правила ct state established,related accept SYN разрешённого соединения уходит, но ответный SYN+ACK отбрасывается политикой, и клиент видит тайм-аут, хотя «разрешающее правило есть». Правило чёрного списка, поставленное после разрешающего, для разрешённого трафика не срабатывает никогда: первое совпавшее правило с вердиктом accept завершает обработку.

Демилитаризованная зона

Публичный сервис — веб-сайт, почтовый шлюз, внешний DNS-сервер — по определению принимает соединения от любого узла Интернета и потому имеет наибольшую вероятность быть скомпрометированным. Размещать его во внутренней сети опасно: взломав веб-сервер, нарушитель окажется рядом с рабочими станциями и базами данных. Решение, описанное ещё в первых работах о межсетевых экранах, — демилитаризованная зона (англ. demilitarized zone, DMZ), или экранированная подсеть (англ. screened subnet): отдельный сегмент для публичных серверов, отделённый экраном и от Интернета, и от внутренней сети ¹.

Ключевое свойство DMZ отражено в матрице: из DMZ во внутреннюю сеть новые соединения запрещены. Внутренние узлы могут обращаться к серверам DMZ, но не наоборот. Если веб-сервер нужно связать с внутренней базой данных, разрешается ровно одно направление и один порт («с адреса веб-сервера на адрес СУБД, TCP 5432»), а сама СУБД доступна только из этой точки. Тогда компрометация веб-сервера даёт нарушителю доступ к базе через уязвимость приложения, но не ко всей внутренней сети.

DMZ строится по одной из двух схем. В схеме с одним экраном и тремя интерфейсами (англ. three-legged firewall) все потоки проходят через одно устройство — так устроена учебная топология лабораторной работы, показанная на рисунке ниже. В схеме с двумя экранами внешний экран отделяет DMZ от Интернета, а внутренний — внутреннюю сеть от DMZ; для проникновения во внутреннюю сеть нарушителю нужно преодолеть оба, и если они разных производителей, одна уязвимость не открывает обоих. Первая схема дешевле и проще в сопровождении, вторая лучше соответствует идее эшелонированной защиты.

Микросегментация и модель нулевого доверия

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

Микросегментация (англ. microsegmentation) доводит сегментацию до предела: политика задаётся не для подсетей, а для отдельных рабочих нагрузок — виртуальных машин, контейнеров, процессов. Правило вида «сервис заказов может обращаться к сервису оплаты на порт 8443» исполняется распределённо — локальным экраном на каждом узле или виртуальным коммутатором гипервизора (тема 21), — а не одним устройством на границе.

Модель нулевого доверия (англ. zero trust), описанная в стандарте NIST SP 800-207, обобщает эту идею: местоположение в сети само по себе не даёт никакого доверия ³. Каждый запрос к ресурсу проходит через точку применения политики (англ. policy enforcement point), которая спрашивает у механизма принятия решений (англ. policy decision point), допустим ли доступ данного субъекта с данного устройства к данному ресурсу именно сейчас. Решение учитывает пользователя, состояние устройства и чувствительность ресурса и принимается для каждой сессии ³. Межсетевой экран в такой архитектуре не исчезает, но перестаёт быть единственным рубежом: он ограничивает, какие точки применения политики вообще достижимы, а решение о доступе к данным принимается выше, с учётом идентичности.

Архитектура межсетевого экрана на основе зон (Zone-Based Policy Firewall)

В классической модели межсетевого экрана правила привязывались к конкретным интерфейсам («входящий трафик на eth0», «исходящий на eth1»). При росте числа интерфейсов и виртуальных сетей (VLAN) такая конфигурация экспоненциально усложняется: добавление нового интерфейса требует пересмотра сотен правил на всех остальных интерфейсах.

Архитектура Zone-Based Policy Firewall (ZBF) отвязывает правила фильтрации от интерфейсов и вводит абстракцию зон безопасности (англ. security zones) ¹⁵:

1. Каждый сетевой интерфейс маршрутизатора или экрана назначается ровно в одну зону безопасности (например, ZONE_INSIDE, ZONE_OUTSIDE, ZONE_DMZ).
2. Для интерфейсов, находящихся в одной зоне, трафик по умолчанию пересылается свободно без фильтрации.
3. Между разными зонами трафик по умолчанию полностью запрещён (default drop).
4. Для разрешения передачи трафика администратор явно определяет пару зон (англ. zone-pair) с указанием источника и назначения: например, ZONE_INSIDE -> ZONE_OUTSIDE и ZONE_INSIDE -> ZONE_DMZ.
5. К конкретной паре зон применяется карта политик (англ. policy-map), задающая действие: drop (отбросить), pass (пропустить без отслеживания состояния) или inspect (активировать stateful-инспекцию с автоматическим пропуском обратных сессий).

Модель ZBF кардинально упрощает масштабирование: при подключении нового физического канала или подсети интерфейс просто добавляется в уже существующую зону, мгновенно наследуя все её политики безопасности.

Централизованное управление доступом AAA: RADIUS и TACACS+

В корпоративной сети контроль доступа распределён по сотням устройств: коммутаторам, беспроводным точкам, VPN-шлюзам и маршрутизаторам. Хранение локальных учётных записей на каждом узле невозможно поддерживать централизованно. Эту задачу решает архитектурный фреймворк AAA (Authentication, Authorization, Accounting):

• Аутентификация (Authentication): проверка подлинности субъекта (кто запрашивает доступ — логин/пароль, сертификат, одноразовый OTP-токен);
• Авторизация (Authorization): определение прав и привилегий (какие ресурсы разрешено открывать или какие команды в CLI разрешено выполнять);
• Учёт (Accounting): регистрация факта использования ресурсов (время начала и конца сессии, объём переданных байт, введённые команды конфигурации).

В сетевой индустрии закрепились два основных протокола AAA: RADIUS и TACACS+, спроектированные под принципиально разные сценарии ¹⁶¹⁷.

Точки съёма трафика и видимость: Network TAP vs SPAN

Системы обнаружения вторжений (IDS), анализаторы протоколов и средства поведенческого анализа (NDR/NTA) пассивны: они не стоят в разрыве канала, а анализируют копию сетевого трафика. Качество их работы критически зависит от метода съёма данных:

• Зеркалирование портов (SPAN / Port Mirroring): коммутатор программно дублирует кадры с одного или нескольких портов на выделенный порт мониторинга (а при RSPAN/ERSPAN — инкапсулирует их в GRE через транзитную сеть). Недостаток SPAN — перегрузка буферов: при суммарном трафике двух дуплексных гигабитных направлений в 2 Гбит/с на исходящий порт SPAN в 1 Гбит/с коммутатор вынужден сбрасывать кадры. При этом сбрасываются именно кадры аномалий или всплесков DDoS, искажая результаты анализа. Кроме того, коммутатор отбрасывает повреждённые кадры с ошибками CRC, делая их невидимыми для криминалистического анализа.
• Аппаратные ответвители (Network TAP — Test Access Point): пассивные оптоволоконные призменные сплиттеры или специализированные электронные устройства, физически врезаемые в кабель. TAP передаёт точную физическую копию каждого бита (включая повреждённые кадры и ошибки преамбулы) на раздельные приёмные порты без задержки и риска переполнения буферов коммутатора.

Серьёзным вызовом для всех средств сетевого мониторинга стало внедрение шифрования TLS 1.3 и расширения Encrypted Client Hello (ECH): имя запрашиваемого домена (SNI), сертификат сервера и прикладные заголовки больше не передаются в открытом виде. Для сохранения видимости современные центры обработки данных либо применяют дешифрующие прокси (TLS Inbound/Outbound Inspection) на выделенных шлюзах, либо переходят от сигнатурного анализа полезной нагрузки к поведенческому анализу метаданных сетевых потоков (длительности, распределению размеров пакетов, энтропии и профилям задержек).

Типовые угрозы сетевого уровня и защита от них

Сканирование портов: что видит защищающаяся сторона

Прежде чем атаковать сервис, нарушитель выясняет, какие сервисы существуют. Сканирование портов (англ. port scanning) — систематическая отправка пакетов на диапазон адресов и портов с классификацией ответов. Тем же приёмом (например, утилитой Nmap) администраторы проверяют собственные сети; проверять чужие сети без разрешения владельца нельзя.

Механизм классификации вытекает из уже изученного поведения TCP (тема 12). Если на порт приходит SYN и порт слушается, узел отвечает SYN+ACK — порт открыт (англ. open). Если порт не слушается, ядро отвечает сегментом RST — порт закрыт (англ. closed), но узел явно существует. Если ответа нет вовсе, пакет был отброшен по пути — порт фильтруется (англ. filtered). Сообщение ICMP «адресат недостижим, запрещено администратором» говорит о правиле reject на экране. Для UDP отсутствие ответа неоднозначно: многие UDP-сервисы молчат на неожиданный запрос.

Для защищающейся стороны из этого следуют три вывода. Во-первых, политика drop на внешней границе делает сканирование медленным и малоинформативным: каждый закрытый экраном порт отвечает тайм-аутом, а не мгновенным RST, и нарушитель не может отличить отсутствующий узел от защищённого. Во-вторых, сканирование оставляет хорошо заметный след: от одного источника за короткое время поступает много новых соединений к разным портам или разным адресам, большая доля их не получает ответа или получает RST. Такой рисунок легко выявляется по журналу экрана и правилами систем обнаружения вторжений. В-третьих, регулярное сканирование собственных адресов — обязательная часть эксплуатации: оно показывает фактическую поверхность атаки, которая часто отличается от задуманной. В лабораторной работе этот приём применяется именно так: из каждой зоны проверяется доступность портов, а результат сравнивается с матрицей потоков.

Подмена ARP и перехват в локальном сегменте

Протокол ARP (тема 7) сопоставляет IP-адрес с MAC-адресом и не содержит никакой аутентификации: узел, получивший ответ ARP, записывает сопоставление в таблицу соседей, не проверяя, кто его прислал. Подмена ARP (англ. ARP spoofing, ARP cache poisoning) использует это: узел нарушителя в том же широковещательном сегменте рассылает ответы ARP, в которых IP-адресу шлюза сопоставлен его собственный MAC-адрес. Жертвы начинают отправлять кадры, предназначенные шлюзу, нарушителю, а тот пересылает их дальше и оказывается посредником (англ. man-in-the-middle, MITM) — может читать незашифрованный трафик, изменять его или просто отбрасывать.

Атака возможна только изнутри сегмента второго уровня; межсетевой экран на границе от неё не защищает, потому что кадры между узлами одной VLAN через него не проходят. Признаки подмены, доступные для наблюдения:

• в таблице соседей (ip neigh) у двух разных IP-адресов — шлюза и какого-то узла — оказывается один и тот же MAC-адрес;
• MAC-адрес, соответствующий адресу шлюза, меняется без видимой причины, и в захвате трафика видны ответы ARP, о которых никто не спрашивал, причём повторяющиеся каждые несколько секунд;
• на коммутаторе один MAC-адрес попеременно появляется на разных портах (в таблице коммутации моста Linux — bridge fdb show), если нарушитель подставил чужой MAC.

Те же признаки — дублирующийся MAC-адрес, конфликт IP-адресов — возникают и при безобидных ошибках конфигурации, например при клонировании виртуальной машины вместе с её MAC-адресом, поэтому наблюдение за таблицей соседей полезно и вне контекста атак. Изменения пар «IP — MAC» отслеживает, например, утилита arpwatch.

Меры защиты действуют на разных уровнях. На управляемых коммутаторах применяются функции DHCP snooping и динамической проверки ARP (англ. Dynamic ARP Inspection): коммутатор знает по журналу выдачи DHCP, какой IP-адрес выдан какому порту, и отбрасывает ответы ARP, противоречащие этому знанию. Аутентификация портов по стандарту IEEE 802.1X не пускает в сегмент неизвестные устройства. Для критичных узлов можно задать постоянную запись ARP для шлюза. И, наконец, самая надёжная мера — сквозное шифрование и аутентификация (TLS, SSH, тема 17): посредник, не имеющий ключей, может отбросить трафик, но не может незаметно прочитать или изменить его.

SYN flood и защита сервера

Атака SYN flood направлена на доступность. При получении SYN сервер создаёт запись о полуоткрытом соединении (англ. half-open connection), отправляет SYN+ACK и ждёт завершающего ACK. Нарушитель отправляет поток сегментов SYN, обычно с подделанными адресами источника, и никогда не завершает рукопожатие. Очередь полуоткрытых соединений заполняется, и сервер перестаёт принимать SYN от легитимных клиентов ⁶.

Числовой пример показывает, почему атака дешева. Пусть очередь полуоткрытых соединений вмещает 1024 записи, а сервер повторяет SYN+ACK пять раз с удвоением интервала, начиная с одной секунды. Тогда запись живёт около 1 + 2 + 4 + 8 + 16 + 32 = 63 секунд. Чтобы держать очередь полной, достаточно присылать 1024 / 63 ≈ 16 сегментов SYN в секунду — это около 1 Кбайт/с, что доступно любому подключению.

RFC 4987 рассматривает несколько мер противодействия ⁶. Увеличение очереди и сокращение числа повторов SYN+ACK лишь повышают порог. Главная мера на конечных узлах — SYN cookies: при переполнении очереди сервер не хранит состояние полуоткрытого соединения, а кодирует необходимые сведения (время, MSS, криптографическую свёртку адресов и портов с секретом) в начальном номере последовательности своего SYN+ACK. Когда клиент присылает ACK, сервер восстанавливает из номера подтверждения всё необходимое и создаёт соединение; если ACK не приходит, сервер ничего не потерял. В Linux механизм включён по умолчанию параметром net.ipv4.tcp_syncookies = 1 и срабатывает только при переполнении очереди.

Межсетевой экран со своей стороны может ограничивать частоту новых соединений с одного источника, как было показано выше, и тем защищать сервер от одного слишком активного клиента. Против распределённого потока с подделанных адресов такое ограничение помогает мало: каждый «источник» присылает всего один SYN. Более того, отслеживание состояния делает сам экран мишенью — поток SYN порождает записи в таблице conntrack. Для таких случаев в Linux есть механизм SYNPROXY: экран сам отвечает на SYN с использованием SYN cookies и передаёт соединение серверу только после завершения рукопожатия, не создавая записей для незавершённых попыток.

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

Атаки на отказ в обслуживании (англ. denial of service, DoS) становятся распределёнными (англ. distributed DoS, DDoS), когда трафик поступает от множества источников, и тогда суммарный поток может превышать пропускную способность канала жертвы. Особый класс — атаки с отражением и усилением (англ. reflection and amplification). Их механизм показан на рисунке ниже. Нарушитель отправляет небольшие запросы по UDP к общедоступным серверам — отражателям (англ. reflectors), — подставив в поле адреса источника адрес жертвы. Отражатели добросовестно отвечают на запрос, но ответ уходит жертве. Если ответ больше запроса, трафик ещё и умножается.

Эффективность протокола для такой атаки характеризуется коэффициентом усиления по полезной нагрузке (англ. bandwidth amplification factor, BAF) — отношением размера ответа к размеру запроса. Россов в систематическом исследовании 2014 года измерил его для ряда протоколов ⁹; некоторые значения приведены в таблице.

Числовой пример: при BAF порядка 50 нарушитель, располагающий исходящим каналом 100 Мбит/с, направляет на жертву около 5 Гбит/с ответов, причём источниками этого трафика выглядят тысячи легитимных серверов, которые нельзя просто занести в чёрный список. Общие черты уязвимых протоколов очевидны: UDP (нет рукопожатия, подтверждающего адрес клиента), ответ значительно больше запроса, множество общедоступных серверов. Отсюда меры со стороны владельцев серверов: не держать открытыми резолверы и служебные UDP-сервисы, отключать отладочные команды вроде NTP monlist, ограничивать частоту ответов (для DNS — механизм Response Rate Limiting). Протоколы, проектируемые сегодня, избегают усиления на этапе установления связи: QUIC, например, требует, чтобы сервер до проверки адреса клиента отправлял не более чем втрое больше данных, чем получил.

Корень проблемы — возможность отправить пакет с чужим адресом источника. Маршрутизация в Интернете смотрит только на адрес назначения, и пакет с подделанным источником доставляется так же, как настоящий. Решение известно с 2000 года и опубликовано как лучшая текущая практика BCP 38 (RFC 2827): входная фильтрация (англ. ingress filtering) на границе сети, к которой подключён источник ⁴. Провайдер знает, какие префиксы выданы клиенту, и отбрасывает приходящие от клиента пакеты, у которых адрес источника не принадлежит этим префиксам. Если так поступает каждый провайдер доступа, подделка адреса становится невозможной у самого источника. RFC 3704 (BCP 84) развивает идею для сетей с несколькими подключениями и описывает автоматическую проверку обратного пути (англ. unicast Reverse Path Forwarding, uRPF): пакет принимается, только если маршрут к его адресу источника ведёт через тот же интерфейс, на который он пришёл (строгий режим), или хотя бы существует (свободный режим) ⁵. В Linux аналогичная проверка включается параметром net.ipv4.conf.*.rp_filter, а в nftables записывается выражением fib saddr . iif oif missing drop.

Слабость BCP 38 — экономическая: фильтрация защищает не применяющую её сеть, а других участников Интернета, и потому внедрена не повсеместно. Межсетевой экран жертвы против атаки, заполняющей канал, бессилен — пакеты отбрасываются уже после того, как заняли канал; такие атаки отражают провайдеры и службы очистки трафика, принимающие его на множестве площадок через anycast (тема 10). На собственном пограничном экране BCP 38 сводится к egress-правилу: пакеты из внутренней сети с адресом источника вне 192.168.18.0/24 отбрасываются и журналируются.

Обнаружение вторжений и журналирование

Системы обнаружения и предотвращения вторжений

Межсетевой экран отвечает на вопрос «разрешён ли поток»; система обнаружения вторжений (англ. intrusion detection system, IDS) отвечает на другой вопрос — «не выглядит ли разрешённый поток как атака». Сетевая IDS получает копию трафика (с зеркального порта коммутатора или отвода) и анализирует её: собирает IP-фрагменты и TCP-потоки, разбирает прикладные протоколы и сравнивает результат с правилами. Если система стоит в разрыве линии и может отбрасывать пакеты, её называют системой предотвращения вторжений (англ. intrusion prevention system, IPS).

Различают два подхода к обнаружению. Сигнатурный (англ. signature-based, misuse detection) ищет известные образцы: строку эксплойта в запросе HTTP, характерную последовательность байтов, известный командный сервер вредоносной программы. Он точен для известных угроз и бесполезен против новых. Поведенческий, или поиск аномалий (англ. anomaly detection), строит модель нормального трафика и сообщает об отклонениях: внезапный рост числа соединений, необычный объём передачи данных наружу, обращения к портам, к которым узел никогда не обращался. Он способен заметить неизвестную атаку, но дорого платит за это ложными срабатываниями.

Классические открытые системы — Snort, созданный Мартином Рёшем в 1998 году как «лёгкая» сетевая IDS с простым языком правил ¹⁰, и Suricata, многопоточная система с совместимым языком правил, разбором прикладных протоколов и журналом событий в формате JSON ¹³. Правило Suricata или Snort читается как правило экрана, дополненное условием на содержимое:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Попытка обхода каталога в URI"; flow:established,to_server; http.uri; content:"../"; sid:1000001; rev:1;)

Правило срабатывает на установленный поток к защищаемой сети, в URI которого встречается последовательность ../, и записывает предупреждение с номером sid. Как и межсетевой экран, IDS видит содержимое только открытого трафика: в соединении TLS ей доступны адреса, порты, имя сервера из SNI и статистика потока, но не запрос.

Журналирование и наблюдаемость

Журналы — это память системы защиты. Без них невозможно ни заметить медленную атаку, ни восстановить ход инцидента, ни проверить, что политика действует так, как задумано. Источники журналов — межсетевой экран, IDS, веб-серверы и прокси, системы аутентификации, DNS-резолвер, сводки потоков NetFlow или IPFIX (тема 22). Рекомендации NIST требуют, чтобы межсетевые экраны журналировали как минимум изменения политики и отброшенный трафик, а журналы регулярно анализировались ².

На практике журналирование подчиняется нескольким правилам. Журналы отправляются с узла сразу (по протоколу syslog или агентом) на отдельный сервер сбора, недоступный из зон, где они порождаются: нарушитель, захвативший веб-сервер в DMZ, первым делом попытается стереть следы. Часы всех узлов синхронизированы по NTP, иначе события из разных источников невозможно сопоставить. Наконец, журналы собираются для того, чтобы их читать: в организациях этим занимаются системы управления событиями безопасности (англ. security information and event management, SIEM), которые сводят журналы вместе и строят по ним оповещения.

Пределы обнаружения: проблема базовой частоты

Даже очень точный детектор порождает много ложных тревог, если настоящие атаки редки. Аксельссон показал это в 2000 году, применив к обнаружению вторжений рассуждение о базовой частоте из теории вероятностей ¹¹. Разберём числовой пример. Пусть за сутки IDS анализирует миллион событий (сессий), из которых 10 связаны с настоящей атакой. Детектор обнаруживает 99 % атак и ошибочно срабатывает на 0,1 % нормальных событий. Тогда за сутки он выдаст 0,99 · 10 ≈ 10 верных тревог и 0,001 · 999 990 ≈ 1000 ложных. Доля верных среди всех тревог — 10 / 1010 ≈ 1 %.

Вывод Аксельссона состоит в том, что для практической пригодности доля ложных срабатываний должна быть на порядки меньше, чем кажется достаточным интуитивно, — порядка базовой частоты самих атак ¹¹. Практические следствия — настройка правил под конкретную сеть (отключение сигнатур, не относящихся к используемому ПО), корреляция нескольких слабых признаков вместо реакции на каждый, и прежде всего уменьшение объёма того, что нужно анализировать. Именно здесь межсетевой экран и IDS дополняют друг друга: строгая политика default deny отсекает огромную долю мусорного трафика ещё до анализа, и каждая запись об отброшенном пакете из DMZ наружу становится редким и потому значимым событием.

Модели анализа атак: Cyber Kill Chain, Diamond Model и MITRE ATT&CK

Для обнаружения и нейтрализации сложных целевых атак (англ. Advanced Persistent Threats, APT) защитникам необходимы формальные модели описания действий противника.

1. Цепочка поражения (Lockheed Martin Cyber Kill Chain): военная концепция последовательных фаз нападения, адаптированная для киберпространства Хатчинсом с соавторами ¹⁸:

   • Reconnaissance (Разведка): сбор информации о цели (сканирование сети, DNS, OSINT, фишинг);
   • Weaponization (Вооружение): объединение эксплойта под уязвимость с полезной нагрузкой (пейлоадом);
   • Delivery (Доставка): передача вредоносного объекта жертве (email-фишинг, вредоносный сайт, USB);
   • Exploitation (Эксплуатация): исполнение кода через уязвимость в ПО или ошибку конфигурации;
   • Installation (Закрепление): установка бэкдора, сервиса persistence, скрытие в системе;
   • Command & Control (Управление, C2): открытие канала связи с сервером управления атакующего;
   • Actions on Objectives (Действия по достижению цели): эксфильтрация данных, шифрование вымогателем, деструктивные действия.

   Главная практическая ценность модели Kill Chain — асимметрия защиты: нападающий обязан успешно пройти все фазы подряд, тогда как защитнику для срыва всей атаки достаточно обнаружить и заблокировать противника хотя бы на одном из звеньев цепочки ¹⁸.

2. Алмазная модель анализа вторжений (Diamond Model): разработана Серджио Кальтаджироне для аналитиков центров мониторинга (SOC) ¹⁹. Каждое событие безопасности формализуется в виде четырёх вершин ромба: Противник (Adversary) применяет Возможность (Capability) против Жертвы (Victim) через коммуникационную Инфраструктуру (Infrastructure). Две вспомогательные оси — Технологическая (какие протоколы и платформы задействованы) и Социально-политическая (мотивация и контекст) — позволяют сопоставлять разрозненные сетевые аномалии в единую кампанию вторжения.

3. База знаний MITRE ATT&CK: таксономия реального поведения атакующих, структурированная в виде матрицы «Тактики (зачем действует?) — Техники и Подтехники (как именно делает?) — Процедуры (TTPs)». В отличие от линейной Kill Chain, ATT&CK отражает нелинейное поведение нарушителя внутри скомпрометированного периметра.

Оценка и скоринг уязвимостей: система CVSS

Для приоритизации обновлений сетевого оборудования и серверов используется открытый стандарт CVSS (Common Vulnerability Scoring System) консорциума FIRST ²⁰. Оценка выражается числом от 0.0 до 10.0 и складывается из метрик:

• Базовая группа (Base Metrics): внутренние качества уязвимости, неизменные во времени:
  • Вектор атаки (Attack Vector, AV): Network (сетевой, наивысший риск), Adjacent (соседняя сеть/L2), Local (локальный доступ), Physical (физический);
  • Сложность атаки (Attack Complexity, AC): Low (нет условий) / High (требуются гонки, редкие конфигурации);
  • Требуемые привилегии (Privileges Required, PR): None / Low / High;
  • Взаимодействие с пользователем (User Interaction, UI): None (автономно) / Required (жертва должна нажать ссылку);
  • Область действия (Scope, S): Unchanged / Changed (эксплойт пробивает песочницу или гипервизор наружу);
  • Влияние (Impact): Конфиденциальность (C), Целостность (I), Доступность (A) — None / Low / High.
• Временная группа (Temporal Metrics): наличие публичного эксплойта (Exploit Code Maturity) и официального патча (Remediation Level).
• Контекстная группа (Environmental Metrics): важность конкретного хоста внутри организации.

Каждая уязвимость получает векторный код вида CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (критический рейтинг 9.8), что позволяет автоматизировать обработку результатов сканеров уязвимостей (Vulnerability Scanners) в SIEM.

Жизненный цикл реагирования на инциденты и порядок волатильности улик

Реагирование на инциденты информационной безопасности организуется дежурными командами CSIRT / CERT / SOC по международному стандарту NIST SP 800-61 Rev. 2 в рамках четырёх фаз ²¹:

1. Подготовка (Preparation): составление регламентов, настройка резервных копий, установка датчиков мониторинга, обучение персонала;
2. Обнаружение и анализ (Detection & Analysis): фиксация аномалии, первичная триаж-классификация, валидация ложных срабатываний, определение масштаба компрометации;
3. Локализация, ликвидация и восстановление (Containment, Eradication & Recovery): изоляция скомпрометированных узлов сети (отключение портов коммутатора, блокировка на межсетевом экране), удаление вредоносного ПО, закрытие уязвимостей, восстановление из доверенных бэкапов;
4. Постинцидентная деятельность (Post-Incident Activity / Lessons Learned): анализ извлечённых уроков, модернизация правил фильтрации, подготовка юридических отчётов.

При сборе цифровых доказательств критически важно соблюдать Порядок волатильности данных (Order of Volatility по RFC 3227) ²² — сбор начинается с наиболее быстро исчезающих артефактов до отключения питания узла:

1. Регистры процессора и кэш-память;
2. Таблицы маршрутизации, ARP-кэш, таблица состояний conntrack ядра и содержимое оперативной памяти (RAM);
3. Временная сетевая статистика и активные сетевые подключения;
4. Содержимое дисковых накопителей и локальных файловых систем;
5. Удалённые журналы регистрации и архивные резервные копии.

Для каждого снятого артефакта (образа памяти или диска) немедленно вычисляется криптографический хеш (SHA-256), гарантирующий неизменность улики при передаче в суд в рамках цепочки обеспечения сохранности доказательств (англ. Chain of Custody).

Итоги темы

Сетевые протоколы, изученные в курсе, проектировались в расчёте на добросовестных участников: в них нет проверки адреса источника, подлинности ответа ARP, намерения клиента завершить рукопожатие. Защита сети поэтому строится вокруг явной политики, выведенной из модели угроз: какие активы защищаются, от кого и какие потоки для работы действительно необходимы. Принципы минимальных привилегий и безопасных умолчаний приводят к политике «запрещено всё, что не разрешено», а принцип эшелонированной защиты — к тому, что межсетевой экран остаётся одним из нескольких рубежей и не заменяет защиту самих сервисов.

Межсетевые экраны прошли путь от пакетного фильтра без состояния, которому для пропуска ответов приходилось открывать широкие диапазоны портов, к экрану с отслеживанием соединений, где политика описывает только новые соединения, а ответы и связанные сообщения ICMP пропускаются по таблице состояний. В Linux эта модель реализована подсистемой netfilter: хуки определяют, где пакет может быть рассмотрен, conntrack сопоставляет пакет с потоком, а nftables даёт язык с наборами, словарями, счётчиками, журналированием и ограничением частоты. Порядок правил, правильный выбор цепочки (forward для транзита, input для самого экрана) и правило для состояний established,related — три вещи, ошибки в которых встречаются чаще всего.

Сегментация переводит политику с уровня отдельных правил на уровень архитектуры: зоны доверия, матрица потоков между ними и демилитаризованная зона для публичных сервисов, из которой нельзя инициировать соединения во внутреннюю сеть. Модель нулевого доверия продолжает эту линию, отказываясь считать доверенным любой узел только по его расположению. Защита от типовых угроз сетевого уровня распределена по уровням: политика drop и журналирование на экране, проверки на коммутаторах доступа, SYN cookies на серверах, фильтрация адресов источника по BCP 38 у провайдеров. Обнаружение вторжений и журналирование замыкают цикл, делая видимым то, что политика пропустила или отвергла, но их эффективность ограничена проблемой базовой частоты.

Межсетевой экран управляет тем, какие потоки возможны, но не защищает их содержимое при прохождении через недоверенную сеть. Следующая тема посвящена туннелям и виртуальным частным сетям, которые объединяют криптографию из темы 17 с маршрутизацией и позволяют безопасно связать удалённые площадки и пользователей через Интернет.

Литература

1. Cheswick W. R., Bellovin S. M., Rubin A. D. Firewalls and Internet Security: Repelling the Wily Hacker. 2nd ed. — Addison-Wesley, 2003.
2. Scarfone K., Hoffman P. Guidelines on Firewalls and Firewall Policy. — NIST Special Publication 800-41 Rev. 1, 2009. https://doi.org/10.6028/NIST.SP.800-41r1
3. Rose S., Borchert O., Mitchell S., Connelly S. Zero Trust Architecture. — NIST Special Publication 800-207, 2020. https://doi.org/10.6028/NIST.SP.800-207
4. Ferguson P., Senie D. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. — RFC 2827 (BCP 38), IETF, 2000. https://www.rfc-editor.org/rfc/rfc2827
5. Baker F., Savola P. Ingress Filtering for Multihomed Networks. — RFC 3704 (BCP 84), IETF, 2004. https://www.rfc-editor.org/rfc/rfc3704
6. Eddy W. TCP SYN Flooding Attacks and Common Mitigations. — RFC 4987, IETF, 2007. https://www.rfc-editor.org/rfc/rfc4987
7. The netfilter.org project. nftables wiki. — 2025. https://wiki.nftables.org/
8. Neira Ayuso P. Netfilter's connection tracking system. — ;login: The USENIX Magazine, 2006, Vol. 31, No. 3.
9. Rossow C. Amplification Hell: Revisiting Network Protocols for DDoS Abuse. — Proceedings of the Network and Distributed System Security Symposium (NDSS), 2014.
10. Roesch M. Snort — Lightweight Intrusion Detection for Networks. — Proceedings of the 13th USENIX Conference on System Administration (LISA '99), 1999, С. 229–238.
11. Axelsson S. The Base-Rate Fallacy and the Difficulty of Intrusion Detection. — ACM Transactions on Information and System Security, 2000, Vol. 3, No. 3, С. 186–205, DOI: 10.1145/357830.357849.
12. Saltzer J. H., Schroeder M. D. The Protection of Information in Computer Systems. — Proceedings of the IEEE, 1975, Vol. 63, No. 9, С. 1278–1308, DOI: 10.1109/PROC.1975.9939.
13. Open Information Security Foundation. Suricata User Guide. — 2025. https://docs.suricata.io/
14. The Linux Kernel Documentation. Netfilter Conntrack Sysfs variables. — 2025. https://docs.kernel.org/networking/nf_conntrack-sysctl.html
15. Cisco Systems. Zone-Based Policy Firewall Design Guide. — 2024.
16. Rigney C., Willens S., Rubens A., Simpson W. Remote Authentication Dial In User Service (RADIUS). — RFC 2865, IETF, 2000. https://www.rfc-editor.org/rfc/rfc2865
17. Dahm T., et al. The TACACS+ Protocol. — RFC 8907, IETF, 2020. https://www.rfc-editor.org/rfc/rfc8907
18. Hutchins E. M., Cloppert M. J., Amin R. M. Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. — 6th International Conference on Information Warfare and Security, 2011, С. 113–125.
19. Caltagirone S., Pendergast A., Betz C. The Diamond Model of Intrusion Analysis. — Center for Cyber Intelligence Analysis and Threat Research, 2013.
20. FIRST. Common Vulnerability Scoring System v3.1: Specification Document. — Forum of Incident Response and Security Teams, 2019. https://www.first.org/cvss/v3.1/specification-document
21. Cichonski P., Millar T., Grance T., Scarfone K. Computer Security Incident Handling Guide. — NIST Special Publication 800-61 Rev. 2, 2012. https://doi.org/10.6028/NIST.SP.800-61r2
22. Brezinski D., Killalea T. Guidelines for Evidence Collection and Archiving. — RFC 3227 (BCP 55), IETF, 2002. https://www.rfc-editor.org/rfc/rfc3227

Дополнительные материалы

Вопросы для самопроверки

1. Сформулируйте модель угроз для небольшого интернет-магазина: какие активы, какие свойства (конфиденциальность, целостность, доступность) и какие нарушители рассматриваются?
2. Почему Зальцер и Шрёдер считают, что решение о доступе должно основываться на разрешении, а не на запрете? Как этот принцип выражается в политике межсетевого экрана?
3. Чем эшелонированная защита отличается от простого дублирования одного и того же правила на двух устройствах?
4. Пакетный фильтр без состояния проверяет флаг ACK у входящих TCP-сегментов. От чего это защищает и от чего нет?
5. Почему межсетевой экран с отслеживанием состояния должен пропускать связанные (related) сообщения ICMP и что сломается, если их отбрасывать?
6. В каком хуке netfilter создаётся запись conntrack для нового потока и почему фильтрация в цепочке с приоритетом filter уже видит состояние пакета?
7. Чем состояние established в conntrack отличается от состояния ESTABLISHED конечного автомата TCP?
8. Как в nftables записать одно правило, выбирающее цепочку по паре «входной интерфейс — выходной интерфейс»? Какую документальную сущность (из раздела о сегментации) оно отражает?
9. Почему из DMZ во внутреннюю сеть запрещены новые соединения, а из внутренней сети в DMZ разрешены?
10. Какие признаки в журнале экрана указывают на сканирование портов? Почему политика drop делает сканирование медленнее, чем reject?
11. Опишите механизм подмены ARP и три меры защиты от неё на разных уровнях.
12. Почему SYN cookies устраняют исчерпание очереди полуоткрытых соединений? Какую цену за это платит сервер?
13. Что такое коэффициент усиления атаки отражения? Какие свойства протокола делают его пригодным для таких атак?
14. Почему фильтрация по BCP 38 защищает других, а не применяющую её сеть, и как это влияет на её распространение?
15. Детектор вторжений обнаруживает 99 % атак и ложно срабатывает на 0,1 % нормальных событий. Почему его тревоги могут оказаться почти бесполезными?
16. В чём архитектурное преимущество Zone-Based Policy Firewall (ZBF) перед правилами на отдельных интерфейсах при расширении сети?
17. По каким пяти ключевым критериям различаются протоколы AAA RADIUS и TACACS+? Почему для управления сетевым оборудованием применяется именно TACACS+?
18. Чем физический Network TAP отличается от порта SPAN коммутатора при высокой сетевой нагрузке и атаках?
19. Перечислите семь фаз модели Lockheed Martin Cyber Kill Chain. Почему для защитника эта модель создаёт асимметричное преимущество?
20. Каков порядок волатильности цифровых доказательств согласно RFC 3227 и почему образ RAM снимается раньше создания посекторного образа накопителя?

Глоссарий темы

Шпаргалка по инструментам

Политика и её просмотр:

nft -c -f firewall.nft             # проверить синтаксис, не загружая
nft -f firewall.nft                # атомарно загрузить политику
nft list ruleset                   # вся политика со счётчиками
nft -a list chain inet filter forward   # правила с номерами handle
nft reset counters                 # обнулить счётчики
nft delete rule inet filter forward handle 12

Наборы и динамические изменения:

nft add element inet filter blocklist '{ 203.0.113.10 timeout 10m }'
nft delete element inet filter blocklist '{ 203.0.113.10 }'
nft list set inet filter blocklist
nft flush set inet filter blocklist

Отладка:

nft insert rule inet filter forward ip saddr 192.168.18.20 meta nftrace set 1
nft monitor trace                  # путь помеченных пакетов по правилам
sysctl -w net.netfilter.nf_log_all_netns=1   # журнал из пространств имён
dmesg -w | grep fw-                # сообщения оператора log

Соединения и соседи:

conntrack -L                       # таблица соединений
conntrack -E                       # события создания и удаления записей
cat /proc/net/nf_conntrack         # то же без conntrack-tools
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
ip neigh show                      # таблица соседей (ARP/NDP)
ip neigh show | awk '/lladdr/{print $5}' | sort | uniq -d   # MAC у нескольких IP
bridge fdb show br br0             # таблица коммутации моста
bridge monitor fdb                 # изменения таблицы коммутации
sysctl net.ipv4.tcp_syncookies     # SYN cookies (1 — при переполнении)

Перевод правил iptables на язык nftables:

iptables-translate -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

nft add rule ip filter INPUT tcp dport 22 ct state new counter accept

Так выглядит вывод iptables 1.8.7; более новые версии заключают правило в одинарные кавычки.

Что почитать и посмотреть

• nftables wiki — официальная документация проекта: быстрый старт, хуки netfilter и приоритеты, наборы, словари, ограничение частоты, трассировка. Основной справочник к лабораторной работе.
• Страница руководства nft(8) — полное описание языка nftables; полезно держать открытой при написании политики.
• NIST SP 800-41 Rev. 1 — краткие и практичные рекомендации по типам экранов, проектированию политики и её сопровождению.
• NIST SP 800-207 Zero Trust Architecture — определение модели нулевого доверия, её компонентов и сценариев развёртывания.
• RFC 4987 — обзор атаки SYN flood и всех известных мер противодействия с их достоинствами и ограничениями, включая SYN cookies.
• RFC 2827 (BCP 38) — короткий документ о входной фильтрации; стоит прочитать целиком, чтобы понять, почему подделка адресов источника до сих пор возможна.
• MANRS — инициатива операторов связи по взаимно согласованным нормам безопасности маршрутизации, включая фильтрацию адресов источника.
• Блог Cloudflare, раздел DDoS — разборы реальных атак с отражением и усилением, их масштабы и способы отражения на уровне провайдера.
• Документация Suricata — устройство IDS/IPS, язык правил, журнал событий EVE в формате JSON.
• Документация Nmap: определение состояний портов — описание состояний open, closed, filtered с точки зрения администратора, проверяющего собственную сеть.
• Cheswick W. R., Bellovin S. M., Rubin A. D. Firewalls and Internet Security — классическая книга; первые главы о философии безопасности и архитектуре экранов не устарели.

Углубление (по желанию)

Как появились межсетевые экраны

В конце 1980-х годов Интернет был сетью исследовательских организаций, и большинство узлов было доступно отовсюду. Червь Морриса в 1988 году за сутки поразил тысячи машин через уязвимости в общедоступных сервисах и показал, что защищать каждый узел по отдельности не получается. В начале 1990-х появились первые прикладные шлюзы (DEC SEAL, TIS Firewall Toolkit) и описания архитектуры с экранированной подсетью. Книга Чесвика и Белловина 1994 года, написанная по опыту защиты сети AT&T Bell Labs, популяризировала саму идею периметра и подробно описала, как её реализовать. Отслеживание состояния как коммерческая технология появилось в середине 1990-х (Check Point FireWall-1), а в Linux — с подсистемой netfilter в ядре 2.4 (2001 год), пришедшей на смену ipchains. nftables заменил iptables спустя ещё 13 лет, сохранив ту же подсистему хуков и conntrack.

Почему подделка адресов источника до сих пор работает

Проект Spoofer (начат в MIT в 2005 году, ныне ведётся CAIDA) измеряет, из каких сетей можно отправить пакет с подделанным адресом источника: добровольцы запускают клиент, который пытается это сделать, а серверы проекта фиксируют, дошли ли такие пакеты. Результаты многолетних измерений показывают, что заметная доля автономных систем по-прежнему не фильтрует исходящий трафик клиентов. Причины отчасти технические — входная фильтрация требует знать, какие префиксы принадлежат клиенту, что сложно для клиентов с несколькими провайдерами (им посвящён RFC 3704), — но главная причина экономическая: затраты несёт фильтрующая сеть, а выигрыш получают другие. Это пример «трагедии общин» в сетевой безопасности, и именно поэтому атаки с отражением остаются одной из основных разновидностей DDoS.

eBPF и XDP: фильтрация до стека

При объёмных атаках даже nftables может оказаться слишком медленным: пакет успевает пройти выделение буфера, разбор заголовков и conntrack. Механизм XDP (англ. eXpress Data Path) позволяет загрузить в драйвер сетевой карты программу на eBPF, которая решает судьбу пакета до того, как ядро выделит для него структуру sk_buff. Так отбрасываются миллионы пакетов в секунду на одном ядре процессора. Крупные операторы используют XDP как первый рубеж против DDoS, а более тонкую политику оставляют nftables. Обзор технологий ускорения обработки пакетов — в теме 21.

Лабораторная работа 18. Межсетевой экран на nftables

• Раздел курса: тема 18 «Межсетевые экраны и сетевая безопасность»

Введение

В лабораторной работе 14 netfilter использовался для трансляции адресов: шлюз подменял адрес источника и запоминал соединения в таблице conntrack. В настоящей работе та же подсистема применяется по прямому назначению — как межсетевой экран, реализующий политику доступа между зонами. Учебная топология повторяет типовую схему небольшой организации «Северный узел»: межсетевой экран с тремя интерфейсами отделяет Интернет, демилитаризованную зону с веб-сервером и внутреннюю сеть с рабочими местами.

Работа построена вокруг матрицы потоков из темы 18. Сначала нужно убедиться, что «открытая» сеть доступна отовсюду, затем загружает политику с отбрасыванием по умолчанию и проверяет её из каждой зоны, заранее предсказывая результат для каждой пары «адрес — порт». Далее изучаются наборы, чёрный список, счётчики, журналирование и трассировка, после чего те же средства применяются для поиска ошибок в двух неисправных политиках: забытого правила для установленных соединений и неверного порядка правил. Завершают базовую часть ограничение частоты новых соединений и наблюдение таблицы соседей при дублировании MAC-адреса — неисправности, признаки которой совпадают с признаками подмены ARP.

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

Части 1–6 составляют базовую часть. Часть 7 (фильтрация адреса источника и сравнение drop с reject) — продвинутая, выполняется по желанию.

Цель работы

Освоить настройку, проверку и отладку межсетевого экрана с отслеживанием состояния на nftables в топологии с DMZ.

После выполнения работы можно будет:

• записать политику межсетевого экрана с отбрасыванием по умолчанию по матрице потоков между зонами и загрузить её атомарно;
• предсказать доступность сервисов из каждой зоны и проверить предсказание, объяснив различие состояний open, closed и filtered;
• использовать именованные наборы, словари вердиктов и элементы с тайм-аутом для изменения политики без её перезагрузки;
• найти ошибку в политике по счётчикам правил и трассировке nft monitor trace;
• объяснить по таблице conntrack и захвату трафика, зачем нужно правило ct state established,related accept;
• настроить ограничение частоты новых соединений для каждого источника и рассчитать ожидаемое число пропущенных соединений;
• обнаружить дублирование MAC-адреса по таблице соседей и таблице коммутации и объяснить, как те же признаки выдают подмену ARP.

Теоретический минимум

Необходимый материал изложен в теме 18: разделы «Межсетевые экраны: от пакетного фильтра к NGFW», «netfilter и nftables в Linux», «Сегментация сети и зоны доверия», подразделы «Сканирование портов: что видит защищающаяся сторона» и «Подмена ARP и перехват в локальном сегменте». Ниже приведена сжатая справка.

Учебная топология показана на рисунке. Экран fw — Linux-маршрутизатор с тремя интерфейсами; внутренняя сеть построена на мосту br0 в пространстве имён sw. Трансляция адресов в топологии сознательно не используется, чтобы правила фильтрации были видны в чистом виде: «Интернет» знает маршруты к DMZ и внутренней сети через fw.

Матрица разрешённых новых соединений, которую реализует эталонная политика rulesets/firewall.nft:

Команды nftables, используемые в работе:

Результаты check_ports.py: open — соединение установлено; closed — получен RST (узел есть, порт не слушается); filtered — ответа нет (пакет отброшен); rejected — получено ICMP-сообщение о недостижимости.

Таблица соединений доступна как /proc/net/nf_conntrack или командой conntrack -L. Полезные фильтры захвата: tcp port 22, arp; в Wireshark — tcp.flags.syn == 1, tcp.analysis.retransmission, arp.duplicate-address-detected.

Перечень оснащения

• Ubuntu 24.04 (физическая или виртуальная машина либо WSL2) с правами sudo.
• Пакеты: sudo apt install iproute2 nftables conntrack curl python3 tcpdump wireshark.
• Архив окружения lr-env: скрипты up.sh, down.sh, break-dupmac.sh, fix-dupmac.sh, учебные сервисы services.py, утилита проверки портов check_ports.py, политики rulesets/*.nft. Описание — в README.md архива.
• Ресурсы: около 200 МБ памяти, доступ в Интернет не требуется.

Порядок выполнения работы

Распакуйте архив и перейдите в каталог lr-env. Для краткости определите функцию оболочки:

x() { sudo ip netns exec "$@"; }

Далее x fw nft list ruleset означает выполнение команды в пространстве имён fw. Топология поднимается командой sudo ./up.sh и разбирается командой sudo ./down.sh; при любой путанице разберите топологию и поднимите её заново. Файлы rulesets/broken-1.nft и rulesets/broken-2.nft не открывайте, пока не найдёте ошибку по поведению экрана.

Журнал ведётся по частям. Для каждого опыта, где требуется предсказание, сначала записывайте предсказание, затем результат, затем объяснение расхождения, если оно есть. Предсказание, исправленное задним числом, обесценивает опыт: честно ошибочное предсказание полезнее.

Часть 1. Учебная топология и открытая сеть

Задание

1. Поднимите топологию и убедитесь, что пространства имён созданы:

   sudo ./up.sh
   ip netns list
   x fw ip -br addr
   x fw sysctl net.ipv4.ip_forward
   

2. Проверьте, что экран ещё не содержит правил: x fw nft list ruleset должен вывести пустоту.

3. Предскажите, какие из портов 22, 80, 443, 3306, 8080 на адресах 198.51.100.10 и 192.168.18.10 доступны из Интернета при пустой политике. Проверьте:

   x inet python3 check_ports.py 198.51.100.10 192.168.18.10 -p 22,80,443,3306,8080
   

4. Сравните строки для порта 8080 на двух адресах. На web этот порт не слушается, на pc1 — слушается. Объясните, почему результат одного из них closed, а не filtered, и что из этого узнаёт внешний наблюдатель.

5. Получите страницу рабочего места администратора из Интернета: x inet curl -s http://192.168.18.10:8080/. Запишите, какую строку модели угроз из темы 18 нарушает такая доступность.

Что должно получиться

Вывод check_ports.py из inet с пустой политикой; ответ на вопросы пунктов 4 и 5; перечень сервисов, которые при пустой политике составляют поверхность атаки из Интернета.

Часть 2. Политика drop по умолчанию и проверка из каждой зоны

Задание

1. Прочитайте файл rulesets/firewall.nft. Найдите в нём базовые цепочки, их хуки и политики, наборы admin_hosts, public_tcp, blocklist, syn_meter, словарь вердиктов в цепочке forward и цепочки для каждой ячейки матрицы. Ответьте письменно: почему правила для веб-сервера находятся в цепочке forward, а правило для SSH на сам экран — в цепочке input?

2. До загрузки политики заполните в журнале работы таблицу предсказаний. Строки — зона-источник (inet, pc1, pc2, web), столбцы — пары «адрес — порт»: web:22, web:80, web:3306, pc1:8080, fw(192.168.18.1):22, inet:80. В ячейке — ожидаемый результат open, closed или filtered. Если обращение к паре из данной зоны бессмысленно (узел обращается к себе), поставьте прочерк.

3. Загрузите политику и обнулите счётчики:

   x fw nft -f rulesets/firewall.nft
   x fw nft reset counters > /dev/null
   

4. Выполните проверку из каждой зоны. Для узла inet:

   x inet python3 check_ports.py 198.51.100.10 192.168.18.10 203.0.113.1 -p 22,80,443,3306,8080 -t 0.5
   

   Аналогично выполните проверку из pc1, pc2 и web, подобрав адреса так, чтобы заполнить все ячейки таблицы. Отметьте ячейки, где результат расходится с предсказанием, и объясните каждое расхождение.

5. Объясните, почему в столбце inet:80 для pc1 результат open, а для пары inet:22 из pc1 получается filtered, хотя на узле inet порт 22 не слушается и без экрана дал бы closed.

6. Посмотрите счётчики цепочки forward и цепочек ячеек:

   x fw nft list chain inet filter forward
   x fw nft list chain inet filter lan_to_dmz
   

   Сопоставьте значение счётчика последнего правила (с префиксом fw-fwd-drop) с числом строк filtered в ваших проверках транзитного трафика. Совпадение не обязательно точное: объясните, откуда могут взяться лишние пакеты (подсказка: тайм-аут check_ports.py и повторная передача SYN).

7. Посмотрите таблицу соединений экрана сразу после запроса страницы из pc1:

   x pc1 curl -s http://203.0.113.10/
   x fw cat /proc/net/nf_conntrack
   

   Разберите одну запись: протокол, состояние автомата TCP, оставшееся время жизни, исходное и обратное направления, флаг ASSURED. Объясните, почему состояние — TIME_WAIT, а не ESTABLISHED.

8. Запустите захват на внешнем интерфейсе экрана и повторите попытку подключения из Интернета к SSH веб-сервера:

   x fw tcpdump -ni ext0 'tcp port 22'
   # во втором терминале
   x inet curl -s -m 5 telnet://198.51.100.10:22 < /dev/null
   

   Сколько сегментов SYN отправил клиент за 5 секунд и через какие интервалы? Что увидел бы захват, если бы на экране было правило reject, а не drop?

Что должно получиться

Таблица предсказаний и фактических результатов для четырёх зон с объяснением расхождений; ответы на вопросы пунктов 1, 5, 6, 7, 8; вывод счётчиков; разобранная запись conntrack; фрагмент захвата с повторными SYN.

Часть 3. Наборы, чёрный список, журналирование и трассировка

Задание

1. Сотрудник pc2 назначен администратором. Предскажите, какие строки таблицы из части 2 изменятся, если добавить его адрес в набор admin_hosts. Добавьте адрес, не перезагружая политику:

   x fw nft add element inet filter admin_hosts '{ 192.168.18.20 }'
   x pc2 python3 check_ports.py 198.51.100.10 192.168.18.1 -p 22 -t 0.5
   

   Проверьте предсказание и удалите элемент командой nft delete element. Объясните, почему изменение набора не требует перезагрузки правил и чем это лучше, чем добавление отдельного правила.

2. Узел 203.0.113.10 замечен в подозрительной активности. Внесите его в чёрный список на две минуты и проверьте доступ к веб-серверу:

   x fw nft add element inet filter blocklist '{ 203.0.113.10 timeout 2m }'
   x inet curl -s -m 2 http://198.51.100.10/ ; echo "код возврата $?"
   x fw nft list set inet filter blocklist
   

   Найдите в выводе оставшееся время жизни элемента. Что произойдёт по его истечении? Удалите элемент вручную.

3. Включите вывод журнала netfilter из пространств имён (на основной системе; после работы верните 0) и наблюдайте журнал ядра:

   sudo sysctl -w net.netfilter.nf_log_all_netns=1
   sudo dmesg -w | grep fw-
   

   Во втором терминале повторите проверку из inet к адресу 192.168.18.10. Разберите одну строку журнала: входной и выходной интерфейсы, адреса, порты, флаги TCP. Объясните, почему журналирование каждого отброшенного пакета без ограничения частоты опасно на реальном пограничном экране, и предложите исправление правила.

4. Трассировка. Пометьте для трассировки попытки SSH с pc2 и посмотрите, как пакет проходит по правилам:

   x fw nft insert rule inet filter forward ip saddr 192.168.18.20 tcp dport 22 meta nftrace set 1
   x fw nft monitor trace
   # во втором терминале
   x pc2 curl -s -m 1 telnet://198.51.100.10:22 < /dev/null
   

   В выводе найдите переход по словарю вердиктов, выход из цепочки lan_to_dmz без вердикта (verdict continue) и завершающую строку policy drop. Удалите правило трассировки, найдя его номер командой x fw nft -a list chain inet filter forward.

Что должно получиться

Предсказания и результаты для пунктов 1–2; строка журнала с разбором и предложенное исправление правила журналирования; вывод трассировки с пояснением каждой строки.

Часть 4. Найти ошибку: две неисправные политики

Задание

В каждом сценарии загружается политика с одной ошибкой. Задача — найти её по поведению экрана, счётчикам и трассировке, не читая файл, затем исправить и подтвердить исправление.

1. Сценарий А. Загрузите политику и обнулите счётчики:

   x fw nft -f rulesets/broken-1.nft
   x fw nft reset counters > /dev/null
   x pc1 curl -s -m 3 http://203.0.113.10/ ; echo "код возврата $?"
   

   Симптом: сотрудники не могут открыть внешний сайт, хотя цепочка lan_to_inet разрешает порты 80 и 443. Посмотрите счётчики цепочек lan_to_inet и forward. Какое правило пропустило первый пакет соединения, а какое отбросило следующий? Запустите захват одновременно на lan0 и ext0 экрана и определите, какой именно сегмент рукопожатия теряется и в каком направлении. Сформулируйте причину, затем откройте файл и подтвердите её. Исправьте политику (в копии файла), загрузите и проверьте.

2. Ответьте: почему без правила для состояний established,related первый сегмент SYN проходит, а ответный SYN+ACK — нет, хотя оба пакета принадлежат одному соединению? Какие ещё пакеты, кроме ответов TCP, перестали бы проходить (вспомните сообщения ICMP «требуется фрагментация» из темы 7)?

3. Сценарий Б. Загрузите вторую политику:

   x fw nft -f rulesets/broken-2.nft
   x fw nft list set inet filter blocklist
   x inet curl -s -m 3 http://198.51.100.10/
   

   Симптом: адрес 203.0.113.10 внесён в чёрный список, но получает страницу веб-сервера. Найдите в выводе nft list ruleset все правила, использующие набор blocklist, и их счётчики. С помощью трассировки (пометьте пакеты от 203.0.113.10) определите, на каком правиле завершается обработка. Сформулируйте общее правило порядка: где в цепочке должны стоять запреты относительно разрешений.

4. Верните эталонную политику rulesets/firewall.nft и убедитесь, что оба симптома исчезли.

Что должно получиться

Для каждого сценария: симптом, ход поиска (какие счётчики и строки трассировки указали на причину), причина, исправление в виде фрагмента diff и подтверждающая проверка. Ответ на вопрос пункта 2.

Часть 5. Ограничение частоты новых соединений

Задание

1. Найдите в цепочке inet_to_dmz правило с оператором update @syn_meter. Опишите словами, что оно делает, и объясните, почему ограничение привязано к адресу источника через динамический набор, а не задано одним оператором limit на всё правило.

2. Предсказание. Ограничитель — маркерное ведро ёмкостью 20 маркеров с пополнением 10 маркеров в секунду. Клиент выполняет серию из 60 последовательных HTTP-запросов, на что уходит время T секунд. Выразите через T наибольшее число соединений, которые могут быть приняты. Оцените, сколько запросов будет отброшено, если запросы идут со скоростью около 20 в секунду, и сколько — если со скоростью 5 в секунду.

3. Обнулите счётчики и выполните серию обычных запросов к веб-серверу, измерив её длительность:

   x fw nft reset counters > /dev/null
   time (ok=0; fail=0
     for i in $(seq 60); do
       if x inet curl -s -o /dev/null --connect-timeout 0.5 http://198.51.100.10/
       then ok=$((ok+1)); else fail=$((fail+1)); fi
     done; echo "принято $ok, не установлено $fail")
   x fw nft list chain inet filter inet_to_dmz
   x fw nft list set inet filter syn_meter
   

   Сравните число неудач со счётчиком правила drop и с вашим предсказанием. Найдите в наборе syn_meter элемент для адреса 203.0.113.10 и его тайм-аут.

4. Повторите серию, добавив sleep 0.2 в тело цикла (около 5 запросов в секунду). Объясните результат.

5. Ответьте: защитит ли такое правило веб-сервер от потока SYN с тысяч различных (в том числе подделанных) адресов источника? Какие меры из темы 18 (SYN cookies, SYNPROXY, фильтрация по BCP 38 у провайдера) действуют в этом случае и где каждая из них применяется?

Что должно получиться

Формула и численное предсказание; измеренная длительность и число принятых запросов в двух сериях; значения счётчиков и содержимое syn_meter; ответы на вопросы пунктов 1 и 5.

Часть 6. Таблица соседей и дублирование MAC-адреса

Задание

1. Сгенерируйте трафик от обоих рабочих мест к экрану и посмотрите таблицу соседей экрана и таблицу коммутации моста:

   x pc1 ping -c 1 192.168.18.1 ; x pc2 ping -c 1 192.168.18.1
   x fw ip neigh show dev lan0
   x sw bridge fdb show br br0 | grep -v permanent
   

   Сопоставьте MAC-адреса с адресным планом из README.md. Объясните, какая таблица заполняется по ARP, а какая — по адресам источника кадров, и на каком уровне модели работает каждая.

2. Внесите неисправность: sudo ./break-dupmac.sh. Скрипт имитирует ошибку администрирования, а не атаку: виртуальную машину склонировали вместе с её MAC-адресом. Запустите наблюдение за таблицей коммутации и попеременно генерируйте трафик с обоих узлов:

   x sw bridge monitor fdb
   # во втором терминале: сначала сбросить таблицу соседей экрана, иначе в ней
   # может остаться старая запись pc2 до истечения её срока
   x fw ip neigh flush dev lan0
   for i in 1 2 3; do x pc1 ping -c 1 -W 1 192.168.18.1; x pc2 ping -c 1 -W 1 192.168.18.1; done
   x pc1 ping -c 3 192.168.18.20
   

   Опишите, что происходит с записью для MAC-адреса 02:00:00:00:18:0a в таблице моста, и почему ping между pc1 и pc2 перестал работать.

3. Посмотрите таблицу соседей экрана ещё раз. Найдите признак, по которому можно было бы обнаружить неисправность автоматически, не зная её причины. Запишите его в виде проверки (например, однострочной команды, которая выводит MAC-адреса, встречающиеся у нескольких IP-адресов в выводе ip neigh).

4. Сопоставьте наблюдённые признаки с признаками подмены ARP из темы 18. Какие из них совпадают? По какому дополнительному признаку (что происходит с MAC-адресом, сопоставленным адресу шлюза, и какие сообщения ARP видны в захвате) администратор отличит злонамеренную подмену от клонированной машины? Какие меры на коммутаторе доступа предотвратили бы оба случая?

5. Устраните неисправность: sudo ./fix-dupmac.sh, и убедитесь, что связность восстановлена, а в таблице соседей у каждого IP-адреса свой MAC-адрес.

Что должно получиться

Таблицы соседей и коммутации до и после внесения неисправности; фрагмент вывода bridge monitor fdb; команда автоматической проверки и её вывод; ответы на вопросы пунктов 2 и 4.

Часть 7. Фильтрация адреса источника и сравнение drop и reject (продвинутая)

Задание

1. В цепочке forward найдите правило с префиксом журнала fw-bad-src. Объясните, какую рекомендацию BCP 38 оно реализует на уровне организации и от каких ситуаций защищает.

2. Смоделируйте неверно настроенный узел: добавьте на pc2 адрес вне внутренней сети и попробуйте открыть внешний сайт с этого адреса:

   x pc2 ip addr add 10.99.0.5/32 dev eth0
   x pc2 curl -s -m 2 --interface 10.99.0.5 http://203.0.113.10/ ; echo "код возврата $?"
   x fw nft list chain inet filter forward
   

   Предскажите, какой счётчик вырастет, и проверьте. Почему без этого правила соединение всё равно не установилось бы, даже если бы пакет ушёл в Интернет? Удалите адрес.

3. Добавьте в цепочку input перед завершающим правилом журнала правило, отклоняющее не разрешённые политикой попытки подключения к экрану из внутренней сети: iifname "lan0" reject with icmpx admin-prohibited (номер завершающего правила покажет nft -a list chain inet filter input, вставка перед ним — nft insert rule inet filter input handle N ...). Остальные зоны оставьте с drop. Предскажите результат check_ports.py для fw:80 и fw:22 из pc2 и для fw:80 из inet, проверьте и сравните время ответа в последнем столбце вывода. Затем замените действие на простое reject (nft replace rule ... handle N iifname "lan0" reject) и объясните, почему результат для fw:80 из pc2 стал closed: какое сообщение ICMP отправляет reject по умолчанию и как ядро клиента его интерпретирует.

4. Обоснуйте письменно, где в учебной организации уместен reject, а где drop, с учётом удобства пользователей и того, что видит внешний наблюдатель.

Что должно получиться

Ответы на вопросы пунктов 1, 2, 4; изменённый фрагмент политики; выводы check_ports.py с filtered и rejected и сравнение времени.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Почему политика «запрещено всё, что не разрешено» надёжнее противоположной, если администратор может ошибиться в любой из них?
2. Пакетный фильтр без состояния пропускает веб-трафик сотрудников. Какое правило ему нужно для ответов сервера и почему оно шире, чем правило экрана с отслеживанием состояния?
3. Чем различаются состояния new, established, related и invalid? Приведите пример пакета в состоянии related.
4. В какой цепочке (input или forward) будет обработан пакет из Интернета к веб-серверу DMZ, а в какой — пакет к службе SSH самого экрана? Почему?
5. Чем результат filtered отличается от closed с точки зрения внешнего наблюдателя и что каждый из них говорит о политике экрана?
6. Почему загрузка политики через nft -f с flush ruleset в начале файла не оставляет экран открытым даже на мгновение?
7. Политика содержит правило чёрного списка после разрешающего правила для порта 443. Будет ли оно срабатывать для трафика на порт 443? Для какого трафика будет?
8. Маркерное ведро имеет ёмкость 20 и скорость пополнения 10 в секунду. Сколько новых соединений источник может установить за первые 3 секунды и за любые последующие 3 секунды?
9. Почему ограничение частоты для каждого источника почти не помогает против SYN flood с подделанных адресов, и какие механизмы помогают?
10. Почему межсетевой экран на границе сети не защищает от подмены ARP внутри сегмента? Какие признаки подмены видны в таблице соседей и какие меры её предотвращают?
11. Зачем DMZ, если веб-сервер можно защитить тем же экраном, поместив его во внутреннюю сеть? Какое направление потоков матрица запрещает и почему?
12. Почему журналирование отброшенных пакетов без ограничения частоты может само стать причиной отказа в обслуживании?