Var HOME_NET $ имя_интерфейса
где имя_интерфейса заменяется интерфейсом, который должен слушать Snort (например, eth0 или eth1).
С помощью аналогичной инструкции можно определить внешние сети, заменяя HOME_NET на EXTERNAL_NET. Подразумеваемым значением обеих переменных служит any. Можно оставить их в таком виде или определить одну или обе. Рекомендуется определить внутреннюю сеть, но оставить внешние сети заданными как any.
Задание внутренних серверов. В конфигурационном файле можно определить ряд серверов, включая WEB, MAIL, DNS, SQL и TELNET. Это уменьшит число ложных срабатываний для этих сервисов на этих машинах.
Можно также задать номера портов для этих сервисов, чтобы регистрировались только атаки на указанные порты. Все эти опции конфигурации позволяют сократить число ложных срабатываний, чтобы до вас доводилась только информация, обладающая реальной ценностью. Имеется также раздел для добавления серверов AIM, чтобы отслеживать применение AOL Instant Messenger. Это имеет смысл только в том случае, если включен класс правил Chat.
Конфигурирование декодировщиков и препроцессоров Snort. Ряд ключей и настроек в конфигурационном файле управляют декодировщиками и препроцессорами Snort. Эти процедуры применяются к трафику, прежде чем он пройдет через какой-либо набор правил, обычно с целью правильного форматирования или для обработки определенного вида трафика, который проще препроцессировать, чем применять наборы правил. Примером подобного типа трафика служат фрагментированные пакеты. В Snort присутствует декодировщик, собирающий фрагментированные пакеты. Многие атаки пытаются скрыть свою истинную природу, фрагментируя пакеты, так что описываемые возможности Snort являются весьма ценными.
Другой декодировщик предназначен для пакетов сканирования портов. Так как они имеют склонность приходить группами и в большом количестве, лучше обрабатывать их заранее общей массой, чем пытаться сравнивать каждый пакет с сигнатурой. Это также делает систему обнаружения вторжений более защищенной от атак на доступность. Подразумеваемые настройки для этих подсистем должны работать хорошо, однако, получив некоторый опыт работы со Snort, вы можете попытаться изменить их, чтобы повысить производительность и достичь лучших результатов.
Конфигурирование модулей вывода. Это важный шаг, если вы хотите использовать базу данных при обработке вывода Snort. Здесь вы указываете программе, как обрабатывать данные сигналов тревоги. Имеется несколько модулей вывода, которые можно применять в зависимости от требуемого формата данных: Syslog, Database и новый модуль Unified, который поддерживает универсальный бинарный формат, полезный для импорта данных другими программами.
Общий формат для конфигурирования модулей вывода таков:
Output имя_модуля: конфигурация опции
где имя_модуля следует заменить на alert_syslog, database или alert_unified в зависимости от используемого модуля.
Опции конфигурации для различных модулей вывода.
Syslog
Для систем UNIX/Linux нужно использовать следующую директиву:
Output alert_syslog: LOG_AUTH LOG_ALERT
Для Windows-систем можно использовать любой из следующих форматов:
Output alert_syslog: LOG_AUTH LOG_ALERT
output alert_syslog: host=имя_хоста, LOG_AUTH LOG_ALERT
output alert_syslog: host=имя_хоста:порт, LOG_AUTH LOG_ALERT
где имя_хоста и порт нужно заменить, соответственно, на IP-адрес и порт сервера Syslog.
Database
Общий формат для настройки вывода в базу данных таков:
output database: log, тип_базы_данных, user=имя_пользователя
password=пароль dbname=имя_БД host=адрес_БД
где тип_базы_данных заменяется одной из допустимых для Snort разновидностей баз данных (MySQL, postgresql, unixodbc или mssql), имя_пользователя – допустимым именем пользователя машины базы данных, а пароль – его паролем. Переменная dbname задает имя базы данных для протоколирования. Наконец, адрес_базы_данных является IP-адресом сервера базы данных. Не рекомендуется устанавливать Snort и базу данных на один сервер. Помимо того, что безопаснее держать данные сигналов тревоги на другом компьютере, работа Snort и базы данных на одной машине будет существенно снижать производительность.
Unified
Это основной бинарный формат быстрого протоколирования и сохранения для будущего использования. Поддерживаются два аргумента – filename и limit, а вся директива может выглядеть примерно так: