Логи Samba в Elastic Stack: сбор, поля, поиск и диагностика доступа

Samba часто работает годами без внимания — пока пользователь внезапно не теряет доступ к шару, файл не блокируется неизвестным процессом или в журнале не начинается поток ошибок авторизации. Централизованный сбор логов позволяет искать такие проблемы по времени, пользователю, клиентскому IP и серверу, а не листать локальные файлы вручную.

Сначала определите, что именно хотите видеть

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

Откуда брать журналы Samba

Путь зависит от дистрибутива и конфигурации. Часть сообщений может попадать в systemd journal, часть — в отдельные файлы Samba. Перед настройкой Elastic проверьте локально, где появляются нужные события после тестового входа, ошибки пароля или доступа к шару.

journalctl -u smbd --since today
journalctl -u nmbd --since today

На системах и ролях, где используются другие unit names, названия служб будут отличаться. Проверить их можно через systemctl list-units | grep -i samba.

Сбор через Elastic Agent

Если нужные сообщения лежат в текстовых файлах, собирайте их file-based integration или Custom Logs. Для journal можно использовать соответствующий источник событий. Практически важнее не название агента, а стабильные поля: сервер, пользователь, клиентский IP, share, операция, результат и исходное сообщение.

Какие поля стоит нормализовать

• host.name — Samba-сервер;
• source.ip — адрес клиента;
• user.name — пользователь;
• event.outcome — success/failure;
• file.path или отдельное поле ресурса — путь или объект;
• message — исходная строка для случаев, которые ещё не распарсены.

Не парсите всё регулярками в первый день

Хорошая стратегия — сначала стабильно доставлять события, затем разобрать несколько наиболее ценных шаблонов. Огромный grok-фильтр на десятки вариантов Samba легко становится хрупким. Лучше иметь исходное сообщение и постепенно добавлять нормализацию для тех событий, по которым строятся поиск и alert.

Что искать в Kibana

В исходном проекте после нормализации событий был собран отдельный dashboard Samba. Интерфейс старый, но он хорошо показывает целевой результат: в одном месте видны пользователи, операции, клиенты и динамика событий.

• серии отказов авторизации от одного клиента;
• всплески permission denied;
• ошибки открытия или блокировки файлов;
• перезапуски служб;
• необычную активность ночью или от новых адресов;
• резкий рост объёма логов после изменения конфигурации.

Retention важнее бесконечного хранения

Журналы файлового сервера могут быстро расти, особенно при детальном аудите. Задайте срок хранения через lifecycle-политику или lifecycle data stream. Не удаляйте старые индексы случайным cron-скриптом: политика хранения должна быть понятной и воспроизводимой.

Когда нужен полноценный аудит

Если задача — отвечать на вопрос «кто удалил или изменил файл», обычных служебных логов может быть недостаточно. Тогда отдельно проектируйте audit-конфигурацию Samba, проверяйте объём событий и сохраняйте поля операции, пользователя, клиента и объекта. Перед включением на production протестируйте нагрузку.

Итог: цель не в том, чтобы отправить каждый байт Samba в Elasticsearch, а в том, чтобы получить пригодную для поиска историю проблем доступа и безопасности. Начните с небольшого набора полезных событий и расширяйте его только там, где это даёт реальную диагностическую ценность.