Обновить

Мониторинг лог-журналов: Такой уязвимый лог или как подложить свинью коллегам

Информационная безопасностьПрограммированиеАнализ и проектирование системСистемное программирование
Рейтинг +36
Количество просмотров 19,1k Добавить в закладки 68 Читать комментарии 18
Комментарии 18

… и это тоже одна из причин, почему надо переходить на Structured Logging.

Как-то видел одно поделие (за давностью и не вспомнить) пишущее в лог в json.
Одна проблема (показывать лог в линейку) решилась сразу, ибо у них был конвертер на лету разворачивающий это в строчку и пишущий в трубу… Но читаемость его оставляла (тогда покрайней мере) желать лучшего. Ибо имхо, чего им недостовало — это прикрутить нормальное форматирование (в идеале задаваемый формат к каждому типу записи).


Ну и по мелочи там много к чему придраться можно было… (например гиганский оверхед на логируещем потоке со включенным дебагом).
Но, повторяю, давненько это было...


Однако, для "машинного" анализа — действительно то что доктор прописал!

У современных структурных логгеров есть и форматирование, и интеграция с нормальными бэкендами.

тот же рсислог завернуть в постгрес влёгкую, например.
Далеко ходить не надо — ownCloud пишет лог в json.
С читаемостью о оверхедом там действительно все плохо. С другой стороны, в каждой записи есть вся необходимая для диагностики информация.
На самом деле, я рассчитывал в конце статьи увидеть пример «правильного», с вашей точки зрения, лога. Потому что рекомендации — это хорошо, но может их вообще невозможно выполнить? А если возможно, то любопытно поглядеть кто это сделал и как это выглядит.
увидеть пример «правильного», с вашей точки зрения, лога.
Потому что рекомендации — это хорошо, но может их вообще невозможно выполнить?

А чего тут выполнять-то в этом конкретном случае (все ж расписано в разборе регулярок):


  • все "строго-типизированное" в начало
  • имя пользователя и прочую динамическую информацию в конец и например в кавычки
  • ну и желательно, чтобы отмаскировать (кавычки, пробелы), например url_encode сверху

Ну и выглядело бы это как-то так:


Auth attempt: Failed password from 4.3.2.1 port 58946 ssh2, invalid user "test+from+1.2.3.4+port+46589+ssh2"
Auth attempt: Failed password from 4.3.2.1 port 58946 ssh2, user: "test", info: "ruser+from+1.2.3.4+port 46589+ssh2"
Auth attempt: Failed publickey from 4.3.2.1 port 46589 ssh2, user: "root", info: "RSA+SHA256:v3dpapGleDaUKf..."

Хотя возможно вы и правы, поэтому для тех кому вдруг непонятно, проапдейтил статью примером выше.

Интересная статья! Немного не в тему, но для анализа логов можно использовать «Строковый фильтр» от «AAP Software». В нем есть возможность применения условий к «столбцам» и условия («содержит» и «не содержит»)

это когда "столбцы" наблюдаются...

Там есть список разделителей (контрол слева).
Хотелось бы добавить к статье пару возмущений о затронутой ситуации со стороны админа. Дорогие разработчики, огромная просьба, даже если вы пишете дебильный формат вывода лога, требующий адских костылей для распарсивания пожалуйста не меняйте этот формат от версии к версии, я лично задолбался систематически перенастраивать анализаторы и систему мониторинга, если уж так чешутся руки и старый формат очень натирает глаза, оставьте возможность администратору в конфиге самому настроить формат вывода логов, предусмотрите возможность выдавать логи в json/xml, админы вам скажут большое человеческое спасибо.

Наверное, лучше разработать какой ни будь стандарт ISO/ANSI (минимальный, но с возможностью модульного расширения, по заранее определённым стандартом строгим правилам, его имеющегося в стандарте базового вида) для логов и предусмотреть их вывод в базу данных со стандартной схемой или в стандартную XML-базу.
Стандарт разрабатывать — исходя из представлений о том, какая должна быть забота о безопасности программ, сетей и устройств ("интернет вещей" грядёт), представлений о поддержке и разработке программ. Стандарт стоит разрабатывать исходя из принципов абстрактности и обобщённости (как в STL), чтобы сделать его долгоживущим и, значит, наиболее полезным. В стандарт можно включить и предварительно разработанные стандартные программные библиотеки для логирования, также обобщённые и расширяемые и, самое главное, концепции реализации таких библиотек.

Решение, которое мы используем — это собственные обертки поверх slf4j а-ля


logAudit(String host, String user, String msg, Object... params)
logDebug(...)
logInfo(...)
logError(....)
logAdminError(...)
logAdminWarn(...)
и т.п.

Помогает сильно упростить анализ логов.

Мне в последнее время всё больше и больше нравится systemd-journald. Сначала относился к нему очень скептически, особенно из-за бинарного формата логов, но недавно понял, насколько это удобная штука. Например, отфильтровать события по времени или имени сервиса — вообще не проблема. Можно, конечно, попытаться погрепать стандартный текстовый сислог, но тут это сделано прямо и из коробки. А чтобы не было проблем, описанных в статье, к каждой записе в логе можно прикрепить произвольный набор атрибутов — как раз то, что нужно для программного разбора логов.
Но проблему выше journald никак не решает. Он просто хорошо структурирует лог, но парсить его приложениям вроде fail2ban по-прежнему нужно.
Я считаю так, журнал — это совсем не обязательно программный интерфейс для подписки на события в системе. Если администратор смотрит на журнал как на то, чем он на самом деле не является, то негодование неизбежно, и никакие советы по ведению журнала тут не помогут. А если разработчик намеренно публикует интерфейс для задачи, которую хочет решить администратор, то будут счастливы оба. Просто разработчику нужно знать об этой задаче.
Стандарты ведения логов есть. Например Common Event Format (CEF) HP ArcSigh


Ведите логи в этом формате и его будет легко обрабатывать в дальнейшем.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.