LIMB
Вход Регистрация

тема

Анализ безопасности гипервизора Proxmox

mike_vazovski · · 2 ответов · 866 просмотров

Майк возовски, отец пятерых птенцов на связи.​

Сегодня я хотел бы сделать обзор администрирование гипервизора Proxmox


Эта статья поможет как начинающим админам, так и профи, потому что даст взглянуть на эту историю изнутри с точки зрения разграничения прав доступа - тут все начиная с мандатных и дискреционных атрибутов доступа, и заканчивая тем, какие каналы утечки могут возникнуть или существовать, даже если защита настроена на 99 процентов. ​
Мы пройдемся от базовых принципов безопасности до тонкостей, которые упускают даже опытные админы. Да, я знаю — «я же настроил фаервол и сменил пароль root!». Но спойлер: этого недостаточно. В этой статье разберем:

  • Мандатные и дискреционные атрибуты доступа — не пугайтесь терминов, это проще, чем кажется.
  • Скрытые каналы утечек, которые работают даже когда «всё закрыто».
  • Реальные кейсы, как ломают Proxmox (и как этому помешать).

итак, газ!

Для начала краткий экскурс​

Глава 1: Архитектура безопасности Proxmox — что стоит за красивым веб-интерфейсом?​

Proxmox VE — это не просто оболочка для KVM/LXC. Это экосистема, где безопасность строится на трех китах:


  1. RBAC (Role-Based Access Control) — основа всего. Пользователи, роли, права, группы.
  2. Сетевая сегментация — VLAN, Open vSwitch, фаерволы на уровне хоста.
  3. Шифрование данных — от LUKS для хранилищ до TLS для API.

Но вот в чем фокус: большинство админов настраивают только первый пункт (и то — поверхностно). Остальное оставляют «по умолчанию». А умолчания в Proxmox — это когда:


Не удалось прогрузить медиа



Не удалось прогрузить медиа



Архитектура:

Введение: Что скрывает этот экран?​

На скриншоте — веб-интерфейс Proxmox VE 8.1.10 после входа. Кажется, всё под контролем: логи, навигация, кнопки «Reboot» и «Shutdown». Но если копнуть глубже — архитектура интерфейса — это луковая метафора: слои уязвимостей, пока не плачь.


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



Глава 1: Общая архитектура — Клиент-сервер vs Реальность​

Как должно быть​

Proxmox VE использует:

  • Веб-интерфейс на JavaScript (ExtJS), который взаимодействует с REST API.
  • Все запросы идут через HTTPS (порт 8006), с шифрованием TLS 1.2+.
  • Аутентификация через PAM/LDAP/AD, сессии хранятся в куках.

Как есть на самом деле​

  1. Сессии без таймаута по умолчанию
    • На скриншоте видно, что пользователь root@pam выполняет операции с 29 ноября (см. логи).
    • Проблема: Если сессия не завершается автоматически, злоумышленник, получивший доступ к браузеру, может управлять гипервизором дни напролет.

      Не удалось прогрузить медиа


2. REST API без ограничений
  • Все действия в интерфейсе — это вызовы API (например, POST /api2/json/nodes/fly/tasks).
  • Уязвимость: Если API доступен из интернета (а он по умолчанию слушает на всех интерфейсах), то:
    • Даже без веб-интерфейса можно удалить ВМ через curl.
    • Токены API (если не настроены) живут вечно.

      Не удалось прогрузить медиа




Начну с анализа структуры интерфейса. Proxmox VE использует веб-интерфейс на основе JavaScript, который взаимодействует с API. Важно рассмотреть, как архитектура обеспечивает безопасность: аутентификация, авторизация, шифрование, логирование.


В левой панели есть разделы: Datacenter, Nodes, Virtual Machines, Storage и т.д. Каждый из них может быть источником уязвимостей, если права доступа неправильно настроены. Например, если пользователь имеет доступ к Storage, он может манипулировать дисками виртуальных машин.


В центральной части отображаются задачи (Task History), где видно, что пользователь root@pam выполнял различные операции. Это указывает на использование локальной аутентификации (PAM). Нужно проверить, как система обрабатывает сессии, есть ли механизм 2FA, настройки таймаута сессий.

Теперь оформлю все это в структурированный обзор, как в предыдущих ответах, с юмором и практическими советами.

Архитектура Proxmox VE 8.1.10: Как интерфейс выглядит как «безопасный», но таит дыры, как решето​



Введение: Что скрывает этот экран?​

На скриншоте — веб-интерфейс Proxmox VE 8.1.10 после входа. Кажется, всё под контролем: логи, навигация, кнопки «Reboot» и «Shutdown». Но если копнуть глубже — архитектура интерфейса — это луковая метафора: слои уязвимостей, пока не плачь.


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



Авторизация и RBAC — Иллюзия контроля​

Роли и привилегии: «Кто может, тот может»​

  • В левой панели (см. скриншот) видны разделы: Virtual Machines, Storage, Firewall.
  • Проблема:
    • Если пользователь имеет роль Administrator, он видит все разделы, включая критически важные (например, Storage или Firewall).
    • Но если вы даете права на VM.PowerMgmt, пользователь может остановить ВМ, но не увидит раздел Storage. Однако через API он все равно получит доступ к дискам.
Не удалось прогрузить медиа



«Слепая зона» в Task History​

  • На скриншоте виден раздел Task History, где отображаются все операции.
  • Уязвимость:
    • Логи показывают что сделано, но не как (например, не видно, что пользователь запустил rm -rf / через Shell).
    • Если злоумышленник удалит логи через CLI (rm /var/log/pve/tasks/*), вы никогда не узнаете, что он был.


(метаданные)

Не удалось прогрузить медиа


Не удалось прогрузить медиа
​



Не удалось прогрузить медиа






Архитектура конфигов — Где лежит «мозг» Proxmox​

/etc/pve/                     # Корень всех конфигов Proxmox
authkey.key               # Ключ для шифрования паролей в user.cfg
priv/                     # Приватные данные
authorized_keys       # SSH-ключи пользователей (НЕ путать с ~/.ssh/authorized_keys!)
shadow                # Хеши паролей (PAM)
<realm>.key           # Ключи для LDAP/AD
storage.cfg               # Все хранилища (NFS, Ceph, LVM)
network/                  # Сетевые настройки
interfaces            # Основной файл сетей (как /etc/network/interfaces)
vmbr0.fw              # Правила фаервола для bridge
qm.conf                   # Глобальные настройки КВМ
vz.conf                   # Глобальные настройки LXC
cluster.conf              # Конфиг кластера (если есть)


Не удалось прогрузить медиа


Bash:
# Найти запущенные процессы
ps aux | grep cloudflared
# Пример опасного вывода:
# root 1234 ... cloudflared tunnel run --token eyJhIjoiZWE0NDI2NzI2ZjdlNDk5YzYxZWJjN2UwOTAzZGU2MTki...

# Найти токены в конфигах (ОПАСНО!)
grep -r "token" /etc/systemd/system/ /etc/cloudflared/
# Пример пути: /etc/systemd/system/cloudflared.service


Что утекает в интернет — VPN, Cloudflare и «тихие предатели»​

→ Токен Cloudflare даёт полный доступ к вашему аккаунту. Если скомпрометирован — злоумышленник может перенаправить весь трафик на свой сервер.

VPN-клиенты​



Bash:
# Проверить активные коннекты
wg show  # Для WireGuard
openvpn --status  # Для OpenVPN

# Найти конфиги (часто с паролями!)
ls /etc/wireguard/*.conf
grep -r "password" /etc/openvpn/

 Если VPN-конфиг содержит PrivateKey, его утечка = доступ к вашей сети.
Не удалось прогрузить медиа


Токены API не имеют TTL по умолчанию. Удаленный пользователь может использовать их годами.

Не удалось прогрузить медиа


Утечки credentials в логах:
Не удалось прогрузить медиа


Сколько я варюсь в информационной безопасности - вердикт один.

Рут - это собирательная личность которую все знают, и ... порой она должна быть урезана, отрезана, подрезана, ее не должно существовать в открытом доступе. 
Берегите себя и свою админку. 

С вами был Майк, best wishes!
👍40 🔥4 😁11 😢16
Спасибо за материал.

Жаль, картинки недоступны.
Перезалить нереально? или таки можно?)
Ценю материал.

Гостевой просмотр. Чтобы отвечать и ставить реакции, войдите или зарегистрируйтесь.