Как злоумышленники скрывают следы на взломанном Linux-сервере: методы пост-эксплуатации

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

Блокировка SSH-доступа и отключение авторизации

Первый шаг — обезопасить точку входа. Злоумышленник очищает список разрешённых ключей и делает файл неизменяемым. Для этого используется команда:

1
echo "" > ~/.ssh/authorized_keys ; chattr +i ~/.ssh/authorized_keys

Флаг +i (immutable) запрещает запись, переименование и удаление файла даже для root. Отменить можно только через chattr -i. Параллельно отключается логирование аутентификации. В системах на базе Debian/Ubuntu комментируется строка auth,authpriv.* в /etc/rsyslog.conf, которая ведёт запись в /var/log/auth.log. На CentOS аналогично для /var/log/secure. Далее файл очищается и получает атрибут +i.

1
2
3
4
5
6
7
8
9
# Дебиан/Убунту

> /var/log/auth.log

chattr +i /var/log/auth.log

service rsyslog restart



# ЦентОС

> /var/log/secure

chattr +i /var/log/secure

service rsyslog restart

После этих операций ни новые подключения по SSH (из-за пустого authorized_keys), ни записи о попытках входа не сохранятся. Администратор не увидит в логах факт взлома.

Скрытие приглашения и смена порта SSH

Чтобы не выдать себя баннером при входе, создаётся файл ~/.hushlogin. Его наличие отключает вывод сообщений motd, новостей и последнего времени входа. Дополнительно применяется chattr +i, чтобы пользователь не удалил этот файл.

1
2
touch ~/.hushlogin

chattr +i ~/.hushlogin

Следующий шаг — смена порта SSH по умолчанию. В файле /etc/ssh/sshd_config строка Port 22 заменяется на любой неиспользуемый порт (например, 443 или 2222). После правки выполняется перезапуск службы: service ssh restart (или service sshd restart на CentOS). Это затрудняет обнаружение открытого SSH-сервера сканерами портов.

Уничтожение истории команд и логов входа

Оболочка bash сохраняет все набранные команды в ~/.bash_history. Злоумышленник отключает сохранение и очищает существующую историю:

1
set +o history; history -c ; echo "set +o history" >> ~/.bashrc ; rm ~/.bash_history

Разберём по частям: set +o history отключает запись истории для текущей сессии. history -c очищает память сессии. Строка echo добавляет ту же команду в ~/.bashrc, чтобы при каждом новом входе история не включалась. rm удаляет сам файл. Дополнительно удаляется /var/log/wtmp — файл, хранящий данные о всех входах в систему (команда last покажет пустоту).

1
rm /var/log/wtmp

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

Очистка логов веб-сервера Apache

Если на сервере работает Apache, атакующий удалит все файлы с логами и перенаправит вывод в /dev/null. Сначала удаление:

1
rm /var/log/apache2/*log*

Затем находятся все конфигурационные файлы, содержащие директивы CustomLog и ErrorLog. Злоумышленник использует grep и цикл for для открытия каждого файла в vi/vim, где вручную заменяет строки на перенаправление в /dev/null.

1
2
3
cd /etc/apache2/

for i in `grep -lnr "CustomLog " /etc/apache2/*`; do vim "$i"; done

for i in `grep -lnr "ErrorLog " /etc/apache2/*`; do vim "$i"; done

После правки каждой строки вида CustomLog /var/log/apache2/access.log combined новая строка выглядит так: CustomLog /dev/null combined. Аналогично для ErrorLog. Завершает процесс перезапуск Apache: apachectl restart. Теперь все обращения к веб-серверу не оставляют следов.

Будьте внимательны: команды с vim внутри цикла требуют ручного вмешательства в каждый файл. Автоматизировать можно через sed, но злоумышленник часто действует вручную, чтобы не оставить лишних записей в процессах.

Как обнаружить признаки такого сокрытия

Противодействие начинается с проверки неизменяемых файлов. Команда lsattr ~/.ssh/authorized_keys покажет атрибут i. Если он установлен, это повод для расследования. Аналогично для /var/log/auth.log, /var/log/secure, ~/.hushlogin.

Следующий шаг — проверка запущенных процессов. Злоумышленник мог оставить активную сессию. Команда who -a покажет текущих пользователей, а lastlog — время последнего входа (если wtmp не удалён). Для восстановления удалённых логов используют инструменты типа foremost, но это сложно и не всегда эффективно.

Просмотр истории команд через histfile в /proc//histfile не сработает, если история отключена. Однако можно проверить, не добавлена ли команда set +o history в общесистемные файлы (например, /etc/profile, /etc/bash.bashrc).

Для Apache полезно проверять конфигурации на наличие /dev/null в директивах логов. Команда

быстро выявит подмену.

Часто задаваемые вопросы

Ниже собраны ответы на типичные вопросы по теме сокрытия следов.

Почему злоумышленник не удаляет файлы полностью, а очищает и защищает через chattr +i?

Удаление вызывает подозрения — администратор видит отсутствие файла и может быстро восстановить его из резервной копии. Очистка содержимого с сохранением файла и атрибутом +i создаёт видимость нормальной работы. Лог просто перестаёт расти, но файл остаётся на месте.

Можно ли вернуть историю команд после rm ~/.bash_history?

Нет, файл удаляется безвозвратно, если не настроено резервное копирование. Однако некоторые системы ведут логирование команд через syslog или auditd. Проверьте настройки /etc/audit/audit.rules и журналы systemd journal (journalctl).

Как защититься от таких действий заранее?

Используйте систему обнаружения вторжений (OSSEC, Wazuh) с мониторингом изменений атрибутов файлов. Настройте неизменяемые флаги для критичных логов, но с другого аккаунта. Ограничьте использование chattr через возможности ядра (например, модуль integrity). Регулярно отправляйте копии логов на удалённый сервер syslog.

Действуют ли эти команды на все дистрибутивы?

Основные команды (chattr, echo, rm, grep, sed, service) работают на любом Linux с ext3/ext4/xfs. Отличаются пути к логам: Debian/Ubuntu используют /var/log/auth.log, CentOS/RHEL — /var/log/secure. Apache на CentOS имеет конфиги в /etc/httpd/, а не /etc/apache2/. Учитывайте это при анализе.

Мы разобрали типовой набор команд, который злоумышленник применяет после взлома Linux-сервера: очистка authorized_keys и логов аутентификации, отключение истории, удаление журналов входа и подмена конфигурации Apache. Знание этих приёмов позволяет администраторам находить следы атаки и усиливать защиту. Проверьте свои серверы на наличие неизменяемых файлов и перенаправлений логов в /dev/null.

Сталкивались ли Вы с ситуацией, когда логи внезапно переставали писаться, а файлы оказывались защищены флагом +i? Поделитесь опытом обнаружения скрытых действий в комментариях.