С новосельем!
Наша команда знает и видит на практике, как ломают 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
Наша команда знает и видит на практике, как ломают 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