Сервер в облаке редко становится публичным из-за одной большой ошибки. Чаще складывается цепочка обычных действий: ВМ получила внешний адрес, Security Group (группа безопасности) сохранила широкое правило, внутри ОС запустился сервис, а временно открытый SSH пережил диагностику. Каждый шаг кажется безобидным, пока вся цепочка не соединится.
Свежий отчёт Cloud Advisor показывает, к чему приводят такие комбинации. Компания изучила обезличенные данные более 40 тыс. ВМ в Cloud.ru и Yandex Cloud. В этой выборке у 88% организаций нашли критические уязвимости с CVSS выше 9,0 на публичных машинах, у 39% там же лежали ключи, токены или пароли, а у 24% обнаружилось вредоносное ПО. Речь идёт о данных конкретного коммерческого исследования, а не о статистике всего рынка.
Из чего складывается публичность виртуальной машины
У ВМ есть несколько сетевых слоёв. Машина получает частный адрес во внутренней подсети. Затем ей могут назначить публичный IP либо поставить перед ней балансировщик или другой шлюз. Дальше трафик проходит через маршрутизацию и Security Group, а внутри Linux или Windows его встречают локальный firewall и само приложение.
Ни один слой не заменяет остальные. Если Security Group разрешает TCP/22, а ufw блокирует порт, SSH снаружи не заработает. Если ufw разрешает SSH, но облачная группа запрещает входящий трафик, соединение тоже остановится. Риск появляется, когда один барьер считают достаточным, а позже его настройка меняется.
| Уровень | Что решает | Типичная ошибка |
|---|---|---|
| Публичный IP | Есть ли внешний путь к ВМ | Адрес назначили служебной машине |
| Маршруты | Куда идёт трафик | Открыли путь наружу и забыли |
| Security Group | Какие порты и источники разрешены |
0.0.0.0/0 для SSH или RDP
|
| Firewall ОС | Что принимает сама ВМ | Сервис разрешён для всех интерфейсов |
| Приложение | Где слушает процесс |
Админ-панель слушает 0.0.0.0
|
Что означает 0.0.0.0/0 и чем опасны временные правила
Запись 0.0.0.0/0 охватывает весь IPv4. Во входящем разрешающем правиле она означает доступ с любого IPv4-адреса, если совпадают протокол и порт. Для публичного сайта доступ к 80 и 443 портам может быть нормальным. Для SSH, RDP, базы данных или административной панели такой источник резко расширяет поверхность атаки.
Типичный сценарий начинается с диагностики. Администратор временно открывает SSH или RDP для 0.0.0.0/0, решает проблему и переключается на следующую задачу. Через неделю о правиле забывают. Интернет постоянно сканируют автоматические системы, поэтому расчёт на то, что «адрес сервера никто не знает», не работает.
Настройки по умолчанию у провайдеров различаются. Yandex Cloud предупреждает, что группа безопасности по умолчанию разрешает весь входящий IPv4-трафик, если объекту не назначили пользовательскую группу. AWS и Azure используют другие наборы правил. При переносе шаблона между облаками сетевой периметр нужно проверять заново.
Почему один открытый сервер может привести к следующему
Публичная ВМ часто хранит больше, чем предполагает её роль. В каталогах остаются .env, API-токены, SSH-ключи, пароли к базам и учётные данные сервисных аккаунтов. После взлома атакующему не всегда приходится ломать соседние системы. Найденный секрет с широкими правами может дать доступ к другим ресурсам облака.
Поэтому опасен не отдельный порт, а комбинация факторов: публичный IP, широкое сетевое правило, уязвимый сервис, секреты на диске и избыточные IAM-права. Вместе такие настройки превращают обычную ошибку конфигурации в маршрут для дальнейшего продвижения внутри инфраструктуры.
Как проверить, что доступно из интернета прямо сейчас
Начните с инвентаризации публичных ресурсов. Найдите ВМ с внешними IP, балансировщики и другие точки входа, затем сопоставьте их с Security Groups. Для каждого ресурса ответьте на три вопроса: нужен ли ему внешний доступ, какие порты действительно требуются и какие адреса должны иметь право подключения.
- Уберите публичные IP у ВМ, которым нужен только исходящий интернет, и используйте NAT.
- Найдите входящие правила с
0.0.0.0/0; SSH и RDP ограничьте доверенными адресами, VPN или бастион-хостом. - Сверьте Security Groups с firewall ОС и реальным списком слушающих портов.
- Проверьте диски и конфигурации на пароли, токены и ключи.
- Повторяйте инвентаризацию после изменений инфраструктуры.
«Внутренняя ВМ» не остаётся внутренней навсегда. Публичность задают текущая конфигурация сети, правила доступа и запущенные сервисы. Поэтому облачный периметр нужно проверять как единую цепочку от внешнего адреса до процесса внутри ОС, а не полагаться на один firewall или одну Security Group.
FAQ: часто задаваемые вопросы
Что означает 0.0.0.0/0 в Security Group?
Во входящем IPv4-правиле
0.0.0.0/0означает доступ с любого IPv4-адреса к указанному протоколу и порту.
Достаточно ли удалить публичный IP, чтобы закрыть ВМ?
Нужно также проверить балансировщики, прокси и NAT с пробросом портов, через которые ВМ может оставаться достижимой извне.
Нужен ли firewall внутри ВМ, если есть Security Group?
Да. Security Group фильтрует трафик на облачном уровне, а firewall ОС добавляет независимый слой контроля.
Можно ли оставлять SSH открытым для 0.0.0.0/0?
Для постоянной настройки лучше ограничить источник доверенным IP, VPN или бастион-хостом и не оставлять SSH доступным всему интернету.
Как найти все публичные виртуальные машины в облаке?
Проверьте внешние IP, сетевые интерфейсы, балансировщики, маршруты и Security Groups. В крупной инфраструктуре инвентаризацию лучше автоматизировать через API, CLI или CSPM.
