С новосельем!

Наша команда знает и видит на практике, как ломают VM. Поэтому сегодня поговорим о том, как защитить только что арендованную машину. Ловите пошаговый гайд от нашего руководителя группы KVM Александра Степанчука. Осторожно, здесь что-то на техническом :)

⏪ Свежую виртуальную машину с белым IP начинают брутфорсить буквально через несколько минут после поднятия. По интернету постоянно ходят боты, которые сканируют диапазоны адресов и атакуют SSH и RDP. Поэтому конфигурацию VM «из коробки» стоит донастроить сразу после запуска.

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

1️⃣ Закрыть SSH

Это самый атакуемый вектор на Linux-VM.

Первым делом лучше перейти с паролей на ключи. Сгенерировать SSH-ключ, положить публичный на сервер, в sshd_config выключить PasswordAuthentication. Брутфорс пароля после этого теряет смысл.

Дальше стоит запретить root-логин по SSH: нужно установить PermitRootLogin no. Работать рекомендую под обычным пользователем, а права повышать через sudo. Атакующий не знает имя вашего юзера — уже +1 неизвестная.

Еще два дополнительных шага: сменить стандартный порт и поставить fail2ban. Первый не защищает сам по себе, но сокращает количество автоматических попыток входа в логах. Второй блокирует IP после нескольких неудачных попыток.

2️⃣ Настроить файрвол

Здесь запрещаем все кроме нужного. На входящие соединения — default deny. Наружу открываем только порты, которые действительно нужны: например, SSH и 80/443 для веба. Настроить такие правила проще всего через ufw в Ubuntu/Debian или firewalld в RHEL.

Отдельно стоит проверить, не выставлено ли наружу служебное: базы данных, Redis, админки, метрики. Это становится частой причина утечек: подняли для localhost, а оно слушает 0.0.0.0. Команда ss -tulpn покажет, какие сервисы и порты доступны на внешнем интерфейсе.

Кстати, фильтровать трафик можно и на уровне провайдера — до того, как он дойдет до VM.

3️⃣ Накатить обновления

Большинство массовых взломов — это эксплуатация давно закрытых уязвимостей на необновленных системах. Образ мог собираться недели назад, и в нем могут оказаться уже известные дыры.

После запуска сразу обновляем систему: apt update && apt upgrade или dnf upgrade. Дальше включаем автообновления безопасности. Например, unattended-upgrades для Debian/Ubuntu, тогда критические патчи будут «прилетать» без ручного участия.

4️⃣ Проверить пользователей и доступы

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

Для каждого сервиса лучше завести отдельного пользователя с минимально необходимыми правами. Тогда компрометация одного приложения не даст атакующему сразу получить root-доступ.

5️⃣ Настроить мониторинг

Периодически проверяйте логи входов: last, /var/log/auth.log. Незнакомый успешный вход дает повод для тревоги.

На компрометацию также могут указывать непонятная нагрузка на CPU или сеть, незнакомые процессы и исходящий трафик на подозрительные адреса. Если VM начинает генерировать «абузный» трафик, мы видим это со своей стороны и уведомляем клиента. Но лучше обнаружить проблему раньше самостоятельно.

6️⃣ Навести порядок в приложениях

Часто VM ломают не через ОС, а через установленное на ней ПО. Поэтому сервисы без необходимости не стоит запускать под root, а CMS, фреймворки, панели и плагины нужно регулярно обновлять. Админки тоже не стоит оставлять открытыми в интернет с дефолтным паролем. Для веб-сервисов — использовать HTTPS

P.S. И не забывайте про бэкапы на своей стороне. Снапшот провайдера не заменяет резервную копию данных. Восстановление быстрее с бэкапом, который клиент держит отдельно ⏩.

#дорогой_бэклог

😏 Облакотека | TG | MAX