3. Конфигурирование и определение, куда будет вестись вывод;

4. Выбор необходимых правил.

1-й этап

Переменная $HOME_NET определяет IP-адреса, считаемые адресами нашей домашней сети. Это нужно, чтобы Snort знал, что считать своим, а что чужим. Например, если мы имеем одну машину с адресом 123.45.45.45, то следует написать:

var HOME_NET 123.45.45.45

В случае маскируемых сетей и если их несколько, пишем без пробелов в скобках:

var HOME_NET [10.1.1.0/24,192.168.1.0/24]

Можно использовать ключевое слово «any» – оно означает любой адрес. Далее следует определить адрес внешней сети. Обычно это все адреса:

var EXTERNAL_NET any

Далее идёт секция с выбором серверов, используемых в сети. Нужно это для того, чтобы не распылять ресурсы напрасно и повысить эффективность работы. Вопрос, конечно, открытый: какой смысл ловить атаки на веб-сервера, если у вас в сети нет ни одного веб-сервера? Но большая часть ответит, что никакого, поэтому в этой секции следует убрать лишнее либо задать более конкретно. Спешу вас предупредить, что бездумное комментирование этих строчек может привести к не запуску Snort и сообщениям об ошибках, так как некоторые включаемые ниже файлы с правилами, возможно, будут иметь ссылки на несуществующие переменные. Далее определяются порты для некоторых служб и прочие переменные. Для первого запуска лучше бегло пробежать, пропустив некоторые сложные моменты, и запуститься, а после уже заниматься более детальным изучением тех или иных правил и строчек в конфигурационном файле с целью выбора оптимальных настроек. Переменную $RULE_PATH следует определить как rules:

var RULE_PATH rules

а не:

var RULE_PATH ../rules

что написано по умолчанию, либо необходимо переписать правила в другую директорию.

2-й этап

Конфигурирование препроцессоров. На первый взгляд может показаться, что препроцессоры – это лишняя и ненужная вещь, и, наверное, это будет по большей части правдой, только если не одно «но», что в сети одно и то же сообщение может быть разбито на две части и на много маленьких пакетов вплоть до содержания в 1 байт. Такие пакеты, не обнаруживая себя, будут проходить через любую СОА без особых трудностей; в зарубежной литературе, в том числе и электронной, эта классическая ситуация очень хорошо и с рисунками расписана. Поэтому разумнее накапливать все маленькие пакеты в буфере и пересобирать до нужного размера, а после уже проверять на наличие признаков той или иной атаки. Пересобирать можно и обычные, среднестатистические пакеты при необходимости. Также, если необходимо, препроцессоры могут выполнять предварительные преобразования веб-адресов. Не секрет, что через процент и шестнадцатеричное число в строке адреса можно передавать любые символы. Так, в истории есть один интересный факт, ставший примером классической глупости компании Microsoft, связанной с этим преобразованием, когда оная, обнаружив одну ошибку, исправила её другой. Некоторое время назад в серверах IIS была найдена ошибка, которая заключалась в том, что если в конце URL-адреса какого-либо asp-сценария дописать точку, то вместо запуска сценария на выполнение выводился его исходный текст. (Подобная ситуация была и со знаком пробела). На сообщения об этом известная фирма выпустила тут же заплатку, заключавшуюся в установке простой проверки синтаксиса запроса на наличие в конце знака «.» и удалении его перед передачей запроса непосредственно обрабатывающему его серверу. На что специалисты только посмеялись, а взломы серверов продолжились как ни в чём не бывало, с тем лишь различием, что в конце запроса вместо точки стал использоваться её шестнадцатеричный код со знаком процента, который беспрепятственно пропускался всеми фильтрами. Этот обходной манёвр несколько позже тоже прикрыли, но факт остался фактом. Поэтому лучше 7 раз подумать и один раз сделать, чем один раз подумать и 7 раз переделывать. Если, прочитав комментарии к препроцессорам, вы поняли, что всё ещё не сильны в их настройке или даже не поняли, зачем они вообще нужны, то лучше оставьте пока эту секцию без изменений.