Уроки реального взлома сервера: 8 привычек, которые защищают хостинговую инфраструктуру

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

Как развивался взлом

1. Общий пароль root. На нескольких серверах, включая сервер управления и jump-хост, использовался один и тот же пароль root, а вход по SSH с паролем был разрешён.
2. Тихий первый вход. Злоумышленник один раз вошёл с этим паролем и оставил открытым SSH-туннель. Туннель не открывает терминал, поэтому он ни разу не появился в who. Он оставался открытым девять дней.
3. Шумная вторая фаза. Больше чем через неделю с нескольких IP выполнили вход с тем же паролем, добавили свои SSH-ключи, создали службы systemd и задания cron и подбросили на сайт веб-шелл.
4. Заметание следов. Злоумышленник сдвинул время изменения файлов на неделю назад, чтобы новые файлы выглядели старыми, использовал одноразовый веб-шелл, удаливший сам себя, и оставил скрытый PHP-файл в /tmp.
5. Обнаружение. Взлом нашли, потому что владелец запросил плановую проверку безопасности, а в логе входов оказались входы root по паролю с IP, которые никто не узнал.

8 привычек, которые разрывают цепочку

1. Только ключи и никаких повторяющихся паролей

Отключите вход по паролю для SSH и выдайте каждому сотруднику собственный ключ. Тогда утёкший пароль бесполезен, а одна украденная учётная запись никогда не открывает все машины. См. статью настройка входа по SSH-ключу.

2. Относитесь к jump-хостам и серверам управления как к главной ценности

Jump-хост или сервер управления имеет доступ ко всему остальному, что делает его самой ценной целью. Выдайте ему отдельные учётные данные, самый строгий файрвол и самый пристальный мониторинг. Если такой сервер когда-либо скомпрометирован, пересоберите его, а не пытайтесь вычистить.

3. Получайте оповещение о каждом входе

Туннель проработал девять дней, потому что о входе никто не узнал. Сообщение в Telegram о каждом входе по SSH и в панель сразу выделяет неизвестный IP. Настройка занимает около десяти минут: аудит входов с оповещениями в Telegram.

4. Ищите соединения, а не только сессии

Проверяйте ss -tnp на долгоживущие SSH-соединения с неизвестных IP, а не только who. Туннели и сессии SFTP не видны обычным командам.

5. Двухфакторная аутентификация на каждой панели

Хостинг-панели, биллинговые системы и панели управления серверами — это ключи ко всему. Включите двухэтапную проверку и по возможности ограничьте доступ к страницам администрирования известными IP. Для aaPanel см. руководство по усилению безопасности aaPanel.

6. Не доверяйте датам файлов

Время изменения легко подделать. При поиске подброшенных файлов используйте время изменения метаданных (ctime) и время создания (birth), которые обычный процесс в пространстве пользователя не может сдвинуть назад:

find /var/www /tmp /dev/shm -newerct "-14 days" -type f 2>/dev/null
stat /path/to/suspicious.php    # compare Modify with Change and Birth

7. Закройте всё, что не обязано быть открытым

Порты баз данных, порты панелей и пути к админкам не должны быть доступны всему интернету. Разрешите доступ только своим IP, поставьте сайты за прокси, скрывающий исходный сервер, и держите политику файрвола по умолчанию в режиме запрета. См. статью как скрыть IP исходного сервера с помощью Cloudflare.

8. После инцидента смените всё и сохраните улики

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

Что даёт хорошая инфраструктура, когда что-то идёт не так

Возможность локализовать инцидент зависит от того, какой контроль у вас есть до того, как что-то случилось. На выделенных серверах IMIDC вы можете открыть экран сервера через консоль VNC, даже закрыв файрволом всё остальное, загрузить систему восстановления, чтобы изучить диски в офлайне, и переустановить сервер, которому больше не доверяете, — всё самостоятельно из личного кабинета (см. руководство по панели управления выделенным сервером). Наша круглосуточная служба поддержки поможет с анализом логов и очисткой, когда вам нужен свежий взгляд.

Самопроверка за 10 минут

grep "Accepted password" /var/log/auth.log* | tail     # any password logins?
ssh-keygen -lf /root/.ssh/authorized_keys              # do you know every key?
ss -tnp | grep sshd                                    # unknown long-lived connections?
crontab -l; ls /etc/cron.d /etc/systemd/system         # anything you did not add?
find /tmp /var/tmp /dev/shm -name ".*" -type f         # hidden files in temp dirs?

Если что-то выглядит незнакомым, остановитесь и разберитесь, прежде чем вносить дальнейшие изменения. Создайте тикет, и команда IMIDC поможет вам во всём разобраться.

Похожие статьи

• Кто входил на мой сервер? Аудит входов по SSH и в панель с оповещениями в Telegram
• Взломан ли ваш сервер Linux? Поиск и удаление майнеров и бэкдоров
• Защита SSH и сайтов с помощью Fail2ban