Диссертации утверждена распоряжением по нгу № от 200 г (стр. 7 из 9)

Перевод правила масок в текстовый формат.

Утилита iptables не позволяет задать больше одного диапазона для адреса отправителя или получателя в одном правиле. Чтобы иметь такую возможность, нужно воспользоваться разработкой под названием ipset [15], которая поставляется в виде модуля ядра Linux и является официальным дополнением к netfilter/iptables. Этот модуль, в числе прочего, решает проблему с проверкой адреса на принадлежность сразу нескольким диапазонам. Причем, по выражению создателей, реализация ipset обеспечивает «молниеносную» проверку записи на соответствие набору параметров. Поэтому далее работу с диапазонами с помощью ipset можно считать за одну проверку.

При вызове метода распечатки правила масок сначала проверяется, не является ли правило отключенным. Если да, то возвращается пустая строка. Именно поэтому во фрагменте правил, приведенном в главе об общей архитектуре генератора, нет проверки на адрес назначения в строке X — все соединения, попавшие туда, имели внешний адрес назначения.

Если правило не отключено, то проверяется, сколько диапазонов фигурирует в его описании. При единственном диапазоне строка проверки выводится в формате «чистого» iptables. Если при этом еще и количество различных адресов во множестве равно единице, то вместо диапазона выводится точный адрес. Если диапазонов больше одного, для проверки используются возможности ipset.

10 Структура и использование генерируемых правил.

При запуске генератора пользователь должен в параметрах командной строки указать статистику, а также желаемое имя для файла правил. В дальнейшем предполагаем, что это имя — rules. Результатом работы генератора являются несколько файлов скриптов, содержащих команды для утилит iptables и ipset:

1. rules — файл с деревом правил на языке команд iptables. Выполнение этого файла с привилегиями администратора приведет к применению в системе содержащихся в нем правил. Перед запуском файла нужно запустить файл rules.ipset;
2. rules.ipset — генерирует наборы ipset, используемые в правилах. Должен быть выполнен до выполнения файла rules, иначе возникнут ошибки;
3. rules.rm — набор команд, предназначенный для корректного удаления из системы сгенерированных правил и наборов ipset.

Разделение команд iptables и наборов ipset на два файла может показаться не лучшей идеей. Это решение принято с целью обеспечения легкой правки файла rules администратором. В начало этого файла вынесено несколько команд, которые могут вызвать интерес (описано ниже).

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

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

Но такой вариант трудно реализуем, т.к. требует наличия ОС 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 нужно прописать удаление этих цепочек, иначе придется удалять их вручную.

11 Оповещение об аномальной активности.

Для автоматического разбора системного журнала и оповещения администратора о появлении аномальной активности предусмотрен специальный скрипт. Для регулярных проверок можно настроить его периодический запуск (например, с помощью crontab [7]).

Из командной строки скрипт принимает два имени файла. Первый файл содержит журнал для анализа[2] (он открывается только для чтения), во второй файл будет собираться информация об аномальных соединениях. В файле логов скрипт ищет записи с префиксом «IS:reject». Из их числа выбираются новые (те, которых еще нет во втором файле). Информация о них добавляется во второй файл и отправляется администратору по электронной почте. Есть возможность регулирования подробностей описания аномальных соединений. По умолчанию проверяются поля адресов и порта назначения.

12 Тестовые испытания и их результаты.

Тестирование системы проводилось на одном из сегментов локальной сети НГУ. Целью его было не только обнаружение и устранение ошибок, но и подтверждение возможности практического применения системы.

Основная статистика состояла из 292 тысяч уникальных соединений, собранных в результате непрерывного мониторинга локальной сети на протяжении недели. Построение дерева ЛРП заняло 46 минут и 35 секунд на компьютере, оснащенном процессором Intel Core2 Duo E4500 2.2ГГц и 1 Гб оперативной памяти. Такое время кажется нам удовлетворительным, учитывая то, что данную операцию нужно выполнить лишь единожды. Но если в дальнейшем это будет вызывать проблемы, имеется потенциал для улучшения данного параметра, так как серьезные работы по оптимизации по скорости построения дерева еще не проводились.