Как проверить сервер Linux на взлом: ключи, cron, systemd
Как проверить сервер Linux на взлом, если пароль уже сменили, а осадок остался? Смотреть туда, где злоумышленник закрепляется: authorized_keys, cron, unit-файлы systemd и sudoers. Ниже — команды для ручной проверки, почему её мало и как следить за этими местами постоянно.
Что злоумышленник делает сразу после входа на сервер
Подобрать пароль или украсть ключ — полдела. Пароль сменят, уязвимость закроют, поэтому первым делом атакующий оставляет себе запасной вход. Набор приёмов почти всегда одинаков, в матрице MITRE ATT&CK они описаны отдельными техниками: добавление своего ключа в authorized_keys, задание cron, новый сервис systemd, строка в sudoers.
Все четыре способа переживают перезагрузку и смену пароля, не требуют своих бинарников в памяти и легко теряются среди сотен легальных файлов. Поэтому вопрос «взломан ли сервер» на практике сводится к вопросу «что изменилось в этих местах и кто это сделал».
Как проверить SSH-ключи в authorized_keys
Сначала узнайте, какие файлы ключей sshd вообще читает: sshd -T | grep -iE "authorizedkeys(file|command)". По умолчанию OpenSSH смотрит не только .ssh/authorized_keys, но и .ssh/authorized_keys2 — второй файл часто забывают. Если задан AuthorizedKeysCommand, ключи приходят из внешней программы, и проверять нужно её.
Дальше — все учётки с оболочкой входа, а не только root: getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $6}'. Для каждой домашней папки выведите отпечатки ключей: ssh-keygen -lf /home/user/.ssh/authorized_keys. Сверьте отпечатки со списком ключей своей команды. Обратите внимание на опции перед ключом: command="…" и from="…" в чужом ключе — повод разбираться дальше.
Как найти подозрительные задания cron
Заданий cron больше, чем видно в crontab -l. Проверьте все места:
— /etc/crontab и каталог /etc/cron.d;
— /etc/cron.hourly, cron.daily, cron.weekly, cron.monthly — там лежат обычные скрипты, их запускает run-parts;
— личные crontab: /var/spool/cron/crontabs/ в Debian и Ubuntu, /var/spool/cron/ в RHEL и производных; удобнее перебрать пользователей командой crontab -l -u <имя>.
Тревожные признаки: загрузка через curl или wget с передачей в sh, base64 в строке задания, запуск из /tmp, /dev/shm или скрытых каталогов с точкой в имени, задание раз в минуту без понятного владельца.
Новые сервисы systemd и таймеры: где искать
Сервис с Restart=always — идеальный бэкдор: он поднимется после перезагрузки и после того, как его убили. Список включённых юнитов даёт systemctl list-unit-files --state=enabled, таймеры — systemctl list-timers --all. Смотреть нужно и сами unit-файлы в /etc/systemd/system, /lib/systemd/system, /usr/lib/systemd/system, и дополнения в каталогах *.d/*.conf: через drop-in можно подменить ExecStart у легального сервиса, не трогая его файл.
Чей это файл, подскажет пакетный менеджер: dpkg -S <путь> или rpm -qf <путь>. Юнит в /etc/systemd/system, которого нет ни в одном пакете и о котором не знает команда, — первый кандидат на разбор.
sudoers: одна строка NOPASSWD
Чтобы вернуть себе root с обычной учётки, достаточно одного файла в /etc/sudoers.d. Проверьте: grep -rE "NOPASSWD|ALL=\(ALL" /etc/sudoers /etc/sudoers.d и visudo -c. Отдельно посмотрите, кто входит в группы sudo, wheel и docker: участник группы docker фактически получает root на хосте.
Почему ручной проверки мало
Время изменения файла не доказательство: touch -d подставит любую дату. Командой stat видно ещё время Change (ctime) — его touch не задаёт, но и оно скажет только «когда», а не «что именно поменялось».
Надёжнее сравнивать содержимое: снять хеши файлов в чистом состоянии и сверять с ними. Файлы из пакетов сверяются с базой пакетного менеджера: dpkg -V в Debian и Ubuntu, rpm -Va в RHEL. В выводе будут и честно отредактированные конфиги (помечены буквой c) — это нормально, разбирайте каждую строку.
Главная проблема в другом: такую проверку делают после подозрения, раз в месяц или никогда. Классический вариант постоянного контроля — auditd с правилами вида auditctl -w /etc/sudoers -p wa -k sudoers и разбором ausearch -k sudoers. В Zabbix похожее собирают элементами контрольной суммы файлов vfs.file.cksum, но список файлов надо вести вручную, и новый файл в /etc/cron.d по такой схеме легко пропустить — об этом стоит помнить, если вы ищете альтернативу Zabbix или пересматриваете шаблоны.
Что проверить у себя
— Какие файлы ключей читает sshd (sshd -T) и есть ли на серверах authorized_keys2.
— Отпечатки ключей у всех учёток с оболочкой входа, а не только у root.
— Все каталоги cron, включая личные crontab в /var/spool/cron.
— Unit-файлы и drop-in в /etc/systemd/system, не принадлежащие пакетам.
— Файлы в /etc/sudoers.d и строки NOPASSWD; состав групп sudo, wheel, docker.
— Места, которые часто пропускают: ~/.config/systemd/user, /etc/rc.local, /etc/ld.so.preload, /etc/profile.d, задания at (atq), модули PAM.
— Есть ли постоянный контроль этих мест с оповещением, а не разовая проверка.
Если нашли чужой ключ, что делать первым?
Не удаляйте сразу: сохраните файл, отпечаток и время изменения — пригодятся для разбора. Затем удалите ключ, смените пароли и ключи всех учёток на хосте и проверьте остальные серверы: тот же ключ часто разносят по всей сети. Если ключ появился у root, сервер надёжнее переустановить.
Не будет ли шума от обновлений системы?
Будет, если сравнивать файлы вслепую: обновление пакета меняет unit-файлы и задания в /etc/cron.d. Поэтому изменения сверяют с базой dpkg или rpm: файл совпал с пакетом — это обновление, не совпал или пакету не принадлежит — повод разбираться.
Чем это отличается от поиска перебора паролей?
Перебор — это попытка войти, закрепление — след уже удавшегося входа. Алерт на перебор полезен, но молчит, если ключ украли или вход был с первой попытки. Оба сигнала дополняют друг друга, так же как в статье о том, как увидеть перебор паролей 1С по журналу регистрации.
Как это сделано в Voltir
Агент Linux с версии 1.14 раз в минуту снимает отпечатки authorized_keys, unit-файлов systemd, cron и sudoers и сообщает об изменениях; файлы пакетов, совпавшие с базой dpkg/rpm, и первый снимок алертов не дают, содержимое ключей и файлов на платформу не уходит. Изменения видны в разделе «Закрепление» дашборда «Безопасность», подробности и список того, что агент не видит, — в документации по безопасности, обновление агента — в инструкции по установке. Посмотреть дашборды можно в живом демо, а если ночью реагировать на такие алерты некому — есть мониторинг как услуга с дежурством. Стоимость — на странице тарифов.