Snort 2.9.20 не регистрирует трафик в snort.log.

Вопрос или проблема

Я запускаю snort 2.9.20 на Ubuntu 24.04.1 и не могу заставить работать журналируемый пакет, используя команду

sudo snort -l /var/log/snort/ -i eth0 -A full -c /etc/snort/snort.conf

Оповещения корректно появляются в var/log/snort/alert, но трафик не появляется в snort.log.

Я искал “$NO_PACKET_LOG” в скрипте запуска Snort в /etc/init.d/snort, но его не существует.

Я запускал snort без файла конфигурации, и пакеты начинают записываться правильно.

Следовательно, похоже, что что-то не так в snort.conf, но я использую последнюю версию для snort 2.9.

Есть какие-нибудь предложения?

Ответ или решение

Для решения проблемы с тем, что Snort 2.9.20 не логгирует пакеты в файл snort.log на Ubuntu 24.04.1, необходимо подробно рассмотреть несколько аспектов настройки Snort и возможные конфигурационные ошибки.

Теория

Snort—это мощный инструмент для анализа сетевого трафика и обнаружения вторжений (IDS/IPS). Когда вы запускаете Snort с параметрами -l (указание директории для логов), -i (интерфейс), -A (формат алертов) и -c (конфигурационный файл), он должен записывать обнаруженный трафик в указанные места. Параметр -l указывает Snort, куда записывать бинарные лог-файлы с трафиком, то есть, в вашем случае, в /var/log/snort/. Формат файла будет snort.log.[timestamp].

Однако, если пакеты правильно идентифицируются и алерты записываются, но трафик не логгируется, возможно, есть настройки в snort.conf, которые блокируют или переопределяют нормальное поведение логгирования пакетов.

Пример

Вы упомянули, что попробовали запустить Snort без конфигурационного файла и логгирование пакетов началось нормально. Это указывает на то, что проблема действительно кроется в файле конфигурации snort.conf.

Приложение

Вот пошаговое руководство, которое может помочь в решении проблемы:

Проверьте конфигурацию конфигурационного файла snort.conf:
- Убедитесь, что в конфигурации не прописан параметр config logdir с альтернативной директории для логов. Если такой параметр существует, он может переопределять директиву командной строки -l.
- Проверьте наличие строк, которые могут предотвращать логгирование пакетов, такие как output log_tcpdump:, которая задает формат лог-файлов.
Убедитесь в правильной настройке директорий и прав доступа:
- Проверьте, что директория /var/log/snort/ доступна для записи пользователя, под которым запускается Snort. Используйте ls -ld /var/log/snort/ для проверки прав доступа.
- Параметры SELinux или AppArmor также могут блокировать запись в директорию логов. Используйте sudo aa-status или sudo getenforce для проверки активного профиля безопасности, а затем при необходимости снимите ограничения.
Проверьте активные настройки включений и исключений в snort.conf:
- Убедитесь, что в snort.conf отсутствуют директивы, которые могут ограничить детализацию логов, такие как config log_bin: no или аналогичные.
Обновите и проверьте правила Snort:
- Возможно, что правила, используемые в настройке, конфликтуют с логгированием пакетов. Попробуйте протестировать с минимальным набором правил (или созданием тестового набора), чтобы понять, влияют ли они на результат.
Запустите Snort в режиме отладки:
- Используйте параметр -T для проверки конфигурации на наличие синтаксических ошибок или конфликтов (например, sudo snort -T -c /etc/snort/snort.conf).
Проверьте снапшот интерфейса сети:
- Убедитесь, что собираемый сетевой трафик достаточно широкий и позволяет Snort заметить трафик для логгирования. Может быть полезно проверить интерфейс с помощью tcpdump на наличие ожидаемого трафика.

Если после выполнения этих шагов проблема не исчезла, возможно, стоит рассмотреть возможность проверки лога ошибок или консольного вывода Snort на предмет более детальной информации о сбоях в логгировании. Вы можете использовать параметр -K ascii для указания формата записи лога для более простого анализа данных.

Резюмируя, проблема, скорее всего, связана с определенными конфигурационными директивами в snort.conf, которые изменяют стандартное поведение Snort, и их корректировка может помочь решить возникшую проблему.