У контроля целостности есть неприятная особенность: он требует эталона, снятого с заведомо чистой системы. Если сервер работает третий год и вопрос о взломе возник только сегодня, снимать эталон уже поздно — вы зафиксируете как норму то, что есть.

Но на Debian и Ubuntu эталон уже существует, и он не ваш: каждый установленный пакет несёт контрольные суммы своих файлов. Сверка с ними не требует ни настройки, ни предварительного снимка и работает на любой системе в любой момент. Инструмент называется debsums.

Использование

sudo apt install debsums
sudo debsums -c

Ключ -c печатает только файлы, не совпавшие с эталоном. Без него вывод — построчный отчёт по каждому файлу в системе, десятки тысяч строк.

Проверка занимает несколько минут и нагружает диск, поэтому на рабочем сервере её стоит запускать с пониженным приоритетом:

sudo ionice -c3 nice -n19 debsums -c

Как читать результат

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

Конфигурационные файлы под /etc. Их изменение — это нормальная работа: вы правили sshd_config, настраивали nginx, добавляли параметры ядра. Такие расхождения ожидаемы. Чтобы они не мешали, есть отдельный режим:

sudo debsums -e -c

-e проверяет только конфигурационные файлы — иногда полезно, чтобы увидеть список того, что вы вообще меняли на этой машине.

Исполняемые файлы и библиотеки. Расхождение в /usr/bin, /usr/sbin, /bin или /usr/lib — это то, ради чего проверка и запускалась. Законные причины у него есть, но их немного: файл менялся вручную при отладке, применялся сторонний патч, пакет обновлялся в момент проверки. Если ни одна из них не подходит, дальше нужно разбираться всерьёз.

Классические цели подмены — ls, ps, netstat, ss, find, sshd. Подменённая версия скрывает из вывода нужные строки, и все ваши дальнейшие проверки перестают показывать правду.

Покрытие неполное — и это надо знать

Ограничение, о котором обычно не пишут: не все пакеты поставляют контрольные суммы. Файлы таких пакетов не проверяются вообще, и в отчёте они не появятся ни при каких обстоятельствах. Посмотреть список можно так:

sudo debsums -l

Чистый отчёт debsums, таким образом, означает «в проверенной части всё в порядке», а не «система не изменялась». То же касается всего, что установлено мимо пакетного менеджера: скомпилированное из исходников, скачанное бинарником, поставленное скриптом с сайта разработчика — за этим debsums не следит по определению, и именно здесь нужен AIDE.

Регулярный запуск

В пакете есть готовое задание, включается в /etc/default/debsums:

CRON_CHECK=weekly

Раз в неделю — разумная частота: проверка заметно нагружает диск, а изменения системных файлов между обновлениями происходят редко. Ежедневный запуск ничего не добавляет, кроме нагрузки.

Если файл действительно подменён

Первое побуждение — переустановить пакет и вернуть оригинал:

sudo apt install --reinstall coreutils

Команда правильная, но не первым действием. Подменённый системный бинарник означает, что у кого-то был root, и восстановление файла эту проблему не решает — оно только уничтожает следы. Порядок должен быть обратным: сначала сохранить копию подозрительного файла и его время изменения, посмотреть, что ещё менялось в тот же период, проверить задания cron, ключи SSH и список пользователей. И только после этого восстанавливать.

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

Место в общей картине

debsums хорош тем, что не требует ничего и работает сразу, — поэтому с него удобно начинать проверку сервера, историю которого вы не знаете. Его слабость — неполное покрытие и отсутствие сведений обо всём, что стоит не из пакетов. Пара «debsums плюс AIDE» закрывает обе стороны: готовый эталон дистрибутива для системных файлов и собственный снимок для остального.

Как обычно, дело не в запуске, а в том, чтобы результат последней проверки был на виду вместе с датой. Как это выглядит — на демо ниже.