Таким образом, система работает с завидной стабильностью, присущей Linux/*BSD, некоторое, возможно, и продолжительное время. Позже планомерно появляются новые хосты с сенсорами, меняются правила и происходят другие мелкие события. В общем, всё работает.

Но вот наступает тот самый момент, когда в алгоритме работы системы наступает сбой либо вероятность его возникновения велика. Нет, это не правила неверно скачались. И не изменилось их местоположение, хотя и такое частенько бывает. По этой причине вверху у ссылок стоят звёздочки, ссылки уже не действительны. Так, недавно обновились адреса и форматы правил для Snort после выхода версии 2.1.1-RC1 из серии 2.1.x. Сейчас для разных серий надо скачивать разные правила, в результате имеем следующие реальные ссылки для скачивания:

n  http://www.snort.org/dl/rules/snortrules-snapshot-CURRENT.tar.gz

n  http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz

n  http://www.snort.org/dl/rules/snortrules-snapshot-2_0.tar.g

Старые же правила переехали в поддиректорию: http://www.snort.org/dl/rules/old. При этом на сайте даже нет мягких ссылок для обратной совместимости на новое местоположение старых правил. При попытке загрузить файлы по ссылкам выше со звёздочками выдаётся ошибка о том, что нет таких файлов.

В ситуации выше будем считать, что система проверки правил их не установила и послала письмо-уведомление администратору о возникшей ошибке. Это будет не у всех, подобную обратную связь каждому придётся налаживать вручную. Но что же произошло, если даже и не система отказала из-за сбоев в электропитании? А просто в самой IDS Snort нашли очередную ошибку, например, для временного решения которой необходимо отключение того или иного препроцессора в системе обработки трафика. То есть просто-напросто надо внести изменения в конфигурационные файлы, например, закомментировать одну строчку. И вот ситуация повторяется, администратор залезает и вручную правит правила на каждом из сенсоров. А тут ситуация усугубляется тем, что раньше он работал один, а к моменту сбоя штаты разрослись, и администраторов стало много. Так что для установки всего лишь одного знака комментария необходимо всем знать пароль суперпользователя и прочие неудобства.

Какой же может быть выход? Наиболее оптимальным решением для данного случая было бы использование некой единой конфигурационной БД с правилами для всех сенсоров. Удобно, когда все правила в одном месте, соответственно, для внесения изменений уже требуются права только на доступ к конфигурационной БД с правилами, то есть нет того случая, когда выдаются излишние права и пользователь может сильно повредить работоспособность системы. Всё, казалось бы, хорошо, но только за любое удобство приходится чем-то расплачиваться. В данном случае нам придётся решать проблемы связи сенсоров с центральной конфигурационной БД. Проблем здесь не меньше, а именно:

n  выбор того, кто с кем будет связываться: база данных с сенсорами или сенсоры с БД;

n  защита от пассивных атак (прослушивание трафика);