Способы использования наборов правил

Идеальным вариантом использования правил является размещение их на узле, через который непосредственно проходит трафик (на маршрутизаторе). В этом случае будет доступна полная функциональность.

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

Рисунок 2. Вариант использования правил, основанный на зеркалировании пакетов.

Схема работы изображена на рисунке 2 (вариант, когда зеркалируется один порт). К порту, на который происходит зеркалирование, подключается компьютер с ОС Linux (ее можно развернуть внутри виртуальной машины) и установленными правилами. При таком использовании можно только следить за трафиком, управлять им непосредственно из правил нельзя. К тому же, возникает проблема с отслеживанием соединений.

По умолчанию сетевое устройство отбрасывает входящие пакеты, адресованные не ему (а именно таким и будет большая часть трафика при зеркалировании). Чтобы такие пакеты все-таки принимались и проходили в систему, нужно установить устройство в «неразборчивый режим» (promiscuous mode, [10]). Но даже при этом стандартное ядро Linux на ранних стадиях разбора будет отбрасывать пакеты, предназначенные для других машин. До ловушек netfilter они доходить не будут и в правилах iptables будут невидны. Текущая линейка ядер Linux имеет номер 2.6. Для ядер более ранних версий существовали патчи, решающие данную проблему. Например, нами был найден патч [17], создающий новую цепочку PROMISCUOUS, из которой можно иметь доступ к пакетам в promiscuous mode из правил iptables. Но нам не удалось заставить старые патчи работать на ядрах новой версии.

Проблема была решена с помощью создания собственного патча для ядер версии 2.6.х. Он крайне прост и лишь немного продлевает срок жизни пакетов в promiscuous mode в ядре Linux, чтобы можно было получить к ним доступ из таблицы mangle цепочки PREROUTING. К сожалению, из-за его несовершенства возможность отслеживания соединений (реализована в модуле netfilter'а под названием ip_conntrack) для таких пакетов недоступна. Причина необходимости отслеживания соединений была описана в главе, посвященной правилу портов и протоколов. Без модуля ip_conntrack соединения могут корректно отслеживаться только для протокола TCP благодаря его флагам. Поэтому при использовании набора правил через зеркалирование трафика UDP-пакеты анализируются только по адресам, но не по портам (т.е. невозможно определить, какие номера портов случайны, а какие — нет). В дальнейшем планируется создание полноценного патча для ядер Linux версии 2.6.х, который бы обеспечивал корректное отслеживание соединений для пакетов в promiscuous mode.

Структура правил.

Начальные команды файла rules не относятся к описанию дерева, а проводят подготовительные операции. Создается цепочка chain0 (корень дерева), и туда перенаправляются все нужные пакеты. Вариант использования правил задается в параметре командной строки генератора. Если это установка непосредственно на маршрутизатор, то в цепочку chain0 попадут только те пакеты, которые начинают новые соединения. Если это вариант с зеркалированием, то в chain0 попадут пакеты, которые начинают новые соединения по протоколу TCP, и все пакеты протоколов UDP и ICMP.

В следующих командах описываются цепочки chain_accept и chain_reject:

iptables -N chain_accept

iptables -A chain_accept -j ACCEPT

iptables -N chain_reject

iptables -A chain_reject -j LOG --log-level warn --log-prefix "IS:reject"

iptables -A chain_reject -j ACCEPT

В цепочку chain_accept приходят все нормальные пакеты, а в chain_reject — аномальные. Как видно, chain_accept не содержит никаких действий, а chain_reject записывает в системный журнал параметры пакетов с префиксом «IS:reject» и уровнем «warning». Администратор может изменить обработку нормальных и аномальных пакетов. Например, добавить журналирование нормального трафика или указать, что аномальный трафик должен блокироваться (сработает только в случае установки правил на маршрутизаторе).

После описания цепочек chain_accept и chain_reject начинается описание самого дерева правил. Внесение туда изменений вручную не предусматривается.

Файл rules.ipset содержит описание наборов диапазонов адресов для ipset и также не предполагает внесения изменений вручную. Названия наборов формируются по шаблону «mset» + целое число. Диапазоны в этом файле не повторяются, и нет деления на адреса отправителя и получателя (это делается в самих правилах).

Файл rules.rm удаляет правила из системы. Его изменение может понадобиться только в том случае, если в цепочки chain_accept и/или chain_reject была добавлена логика обработки, включающая в себя создание новых цепочек. В таком случае в файле rules.rm нужно прописать удаление этих цепочек, иначе придется удалять их вручную.