Обсуждение — Мониторинг вторжений на VPS: auditd, OSSEC и контроль целостности

В статье зацепился за контроль целостности через AIDE. Эталон предлагают хранить вне сервера, и это нужный вопрос. Но между «есть отчёт об изменении» и «пора обновить эталон» остаётся решение человека.

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

Как вы отделяете разрешённые изменения от тех, которые ещё надо разбирать? Мне здесь важнее порядок работы с эталоном, чем ещё одна установленная система. Кто смотрит разницу и на каком основании говорит: теперь это новая исходная точка?

Я бы начинал с записи о разрешённой работе: что меняли и когда. Потом сверял её с отчётом. Сам факт обновления пакетов не объясняет любое соседнее изменение. Предыдущий эталон не затирать автоматически в том же задании, которое делает проверку.

И назначил бы человека, который принимает эту разницу. Не «кто первым увидел письмо», а кто знает, какие работы были согласованы. Иначе один обновил, другой увидел шум, третий нажал принять — и все уверены, что кто-то уже разобрался.

В уведомлении тогда нужны имя машины, время и что именно изменилось. Сообщение «обнаружены изменения» ночью заставляет сначала искать сам отчёт. А ещё полезно видеть, что случай уже взял конкретный человек, чтобы двое не принимали решение независимо.

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