Технические требования

1. Система должна функционировать не на уровне отдельных пакетов, а на уровне соединений. Под соединением понимается поток пакетов между клиентом (инициатором соединения) и сервером. Даже для протоколов, не поддерживающих явно соединения (UDP, ICMP), необходимо выделять их логически из общего потока пакетов. Это необходимо для борьбы со случайными параметрами соединений (например, значения портов в некоторых протоколах).

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

3. Система должна предоставлять возможность построения набора правил, описывающих собранную статистику. Скорость построения правил не является критичным параметром. Однако, в целях обеспечения применимости системы на практике, время построения набора не должно быть чрезмерно велико. Здесь трудно дать точные числовые характеристики. Но представляется разумным, если алгоритм будет работать за полиномиальное время.

 4. Набор сгенерированных правил должен обладать следующим важнейшим свойством: чем чаще соединение с определенными параметрами встречается в статистике (то есть, чем чаще такое соединение появляется в сети), тем быстрее оно должно проходить через правила. Это позволяет значительно снизить нагрузку на процессор машины, на которой будут установлены правила, и обрабатывать большие объемы трафика на относительно маломощных компьютерах.

5. Количество генерируемых правил не должно расти с ростом размера статистики. При малых размерах такая зависимость допустима, однако по достижении определенного порога мощности должно происходить насыщение, т.е. прекращение роста количества правил.

6. Система должна поддерживать протоколы TCP, UDP и ICMP [10] и при построении правил использовать как минимум следующие параметры сетевых соединений: тип протокола, IP-адрес отправителя, IP-адрес получателя, порт получателя (имеет смысл для протоколов TCP и UDP. Порт отправителя обычно выбирается случайным образом и не должен учитываться).

7. Система должна предоставлять возможность перевода построенного набора правил в формат правил для iptables. Система должна генерировать файл(ы) с командами, необходимыми для того, чтобы полученные правила iptables вступили в силу. Также система должна генерировать файл(ы) с командами, позволяющими корректно удалить сгенерированные правила.

8. Правила, генерируемые системой, должны пропускать нормальный трафик, а аномальный регистрировать при помощи стандартных средств iptables (записывать его параметры в журнал ОС). Возможна и реализация, когда аномальный трафик будет блокироваться, но для применения таких реализаций необходимо накопить опыт эксплуатации анализатора, в первую очередь — оценить количество и характер ложных срабатываний анализатора.

9. Система должна иметь средства автоматического оповещения администратора о появлении аномального трафика. Администратор не должен быть обязан самостоятельно просматривать журнал сообщений в поисках сообщений об аномальном трафике. Разумным предоставляется наличие в системе скрипта, который можно было бы настроить на периодический запуск и проверку журнала сообщений и, при наличии аномального трафика, формирование электронного письма администратору.

10. Система должна представлять собою набор утилит для ОС Linux, управляемых при помощи интерфейса командной строки и/или конфигурационных файлов.

Дополнительные требования к отдельным компонентам системы будут освещены ниже, в разделах, посвященных этим компонентам.