Безпека Proxmox: 5 помилок доступу, які призводять до компрометації лабораторії

Кілька фактів (і трохи історії), які пояснюють, чому доступ провалюється

Помилки у безпеці, пов’язані з контролем доступу в Proxmox, не випадкові. Це повторюваний набір звичок — багато з яких успадковані з попередніх етапів інфраструктури, мислення «тільки для лабораторії» або від команд, які вчилися адмініструвати Linux до того, як загальноприйнятим стало моделювання загроз перед інцидентом.

• Факт 1: Веб-UI Proxmox VE (pveproxy) історично за замовчуванням був доступний на TCP/8006 з будь-якого місця, де доступний хост. Це зручно в лабораторії і ризиковано в маршрутизованій мережі.
• Факт 2: Модель дозволів PVE — не післядумка: це RBAC з ролями, користувачами, групами та ACL. Багато зламів починаються з ігнорування цього й роботи під root@pam.
• Факт 3: Концепція «площини керування» стала загальновживаною, бо атаки на контрольні площини приваблюють атакувальників. Контроль гіпервізора важливіший за компрометацію гостьових ОС: одні облікові дані відкривають доступ до багатьох VM.
• Факт 4: Двофакторна автентифікація спершу з’явилася для споживачів, а потім прийшла в операційну практику, коли повторне використання паролів і фішинг перестали бути рідкістю. Портали адміністратора без двофакторної автентифікації сьогодні — рідкість; для атакувальників вони надто приємні.
• Факт 5: Розростання SSH-ключів — це сучасна версія залишення запасного ключа під килимком. Ключі зазвичай переживають співробітників, ноутбуки і ті VM, для яких їх створили.
• Факт 6: VLAN популяризували для зменшення доменів широкомовлення і сегментації мереж; самі по собі вони не є кордоном безпеки, якщо між ними вільно маршрутизують із дозволяючими правилами файрвола.
• Факт 7: Кластерні системи змінюють радіус ураження. Один скомпрометований вузол часто стає сходинкою до порушення всього кластера, особливо якщо довіра між вузлами не обмежена.
• Факт 8: «Резервні копії — це безпека» частково правда. Резервні копії також — високовартісний шлях доступу: якщо атакувальник може їх видалити або зашифрувати, ваш план відновлення перетворюється на інтерпретативне мистецтво.

Одна цитата, щоб визначити пріоритети. Це перефразована ідея від Gene Kim (автор з DevOps/операцій): Покращення надійності здебільшого залежить від покращення системи, а не від героїзму окремих людей.
Застосуйте це до контролю доступу: припиніть покладатися на «обережних адміністраторів» і побудуйте огородження.

Помилка №1: Відкривати UI та API Proxmox, ніби це блог для хобі

Якщо TCP/8006 доступний із мереж, якими ви повністю не керуєте, ви граєте в азартну гру. Так, Proxmox використовує TLS. Ні, це не те саме, що «безпечний в інтернеті». UI — це площина керування адміністратора.
Атакувальнику не потрібно експлуатувати екзотичну вразливість гіпервізора. Достатньо одного входу в неправильному місці, повторного використання пароля або залишеного ввімкненого облікового запису.

Найбільше непорозуміння: «Це просто моя лабораторія». Лабораторії стають продакшеном так само, як малюк стає підлітком: ви відвернулися на п’ять хвилин — і раптом у нього є власна думка й бюджет.

Що «відкрито» насправді означає

«Відкрито» — це не лише «публічна IP-адреса». Це «доступно з будь-якого місця, куди ви не впевнені, що дали б фізичний кабель консолі».
Це включає: плоский корпоративний Wi‑Fi, «тимчасову» VPN-підмережу, якою користуються підрядники, вашу ігрову VLAN, бо ви поспішали, або зворотний проксі, який термінує TLS і форвардить /api2, бо це здавалося зручним.

Що робити натомість

• Розмістіть керування PVE у виділеній мережі керування (окремий інтерфейс або VLAN) зі строгими правилами вхідного трафіку.
• Дозвольте доступ до UI/API лише з адміністративного перехідного сервера або підмережі VPN, якій ви справді довіряєте.
• Якщо потрібно використовувати зворотний проксі, ставтеся до нього як до критичного компонента безпеки (автентифікація, MFA, жорстке налаштування, логування). Якщо ні — не використовуйте.

Жарт №1: Розміщення Proxmox UI у відкритому інтернеті — як залишити ключ від дому під килимком. Працює чудово, поки хтось інший не читає той самий блог про безпеку дому.

Помилка №2: Використовувати root як робочий обліковий запис

Root — це не ідентичність. Root — це можливість. Коли ви виконуєте щоденні операції в UI як root@pam, ви поєднуєте «адміністрування» і «суперкористувач всюди» в один домен відмови.
Саме так невеликі помилки стають великими, і як фішинг перетворюється на контроль над інфраструктурою.

Механізми відмови

• Фішинг/повторне використання облікових даних: один обліковий запис — це все.
• Неоднозначний аудит: «root зробив це» — це не журнал аудиту; це знизування плечима у формі логів.
• Операційна помилка: ви хотіли перезапустити VM; видалили конфігурацію сховища. Root зробив це швидко.

Що робити: іменовані адміністи + межі привілеїв

Створіть іменовані облікові записи адміністраторів, використовуйте ролі RBAC і залишайте root для екстрених ситуацій. Якщо потрібні дії на рівні root, надавайте їх цілеспрямовано — краще ролі, а не довготривалий обліковий запис людини.

Якщо ви думаєте «але це лише я», ви все одно готуєтеся на майбутнє. Майбутнє-ви — це інша людина. Минуле-ви — тим паче.

Помилка №3: Один «адмінський» обліковий запис замість RBAC і розмежування

Дозволи Proxmox потужні й трохи недовикористовувані. Поширений антипатерн — вести невелику організацію (або лабораторію) як одноосібний робочий стіл: один адмін, спільні облікові дані і доступ, що переходить через вузли, пулі та сховище.

Що потрібно розділити (мінімально життєздатне розмежування)

• Людські адміністратори проти автоматизації (API-токени для машин, MFA для людей).
• Управління кластером проти управління VM (не всім треба додавати сховище або змінювати мережу).
• Оператори резервного копіювання проти операторів VM (права на відновлення потужні; права на видалення небезпечні).
• Робочі навантаження орендарів навіть у домашніх лабораторіях — особливо якщо ви хостите сервіси для «друзів і родини».

Що дає вам RBAC

Принцип найменших привілеїв — це не паранойя. Це мінімізація радіусу ураження звичайної помилки:
скомпрометований ноутбук, токен, що потрапив у репозиторій, активований обліковий запис підрядника або інтерн, який вивчає, що означає «Datacenter» в UI.

Помилка №4: Токени, ключі та секрети без циклу життя

Лабораторії люблять статичні секрети. Корпоративні середовища теж, але роблять вигляд, що ні. Схема зламу послідовна: токен створено для скрипта, скрипт працює, токен забувають, і згодом він стає найчистішим входом.

Типові порушники

• API-токени з широкими правами та без процесу прострочення.
• SSH-ключі, скопійовані на кілька ноутбуків адміністраторів і авторизовані всюди.
• Облікові дані для резервного копіювання, які також дозволяють видаляти резервні копії.
• Basic-auth проксі, що зберігається в відкритому вигляді у конфігурації без ротації.

Краще: мислення «цикл життя»

Кожна облікова інформація має мати власника, область дії, спосіб зберігання і історію ротації. Якщо ви не можете відповісти на ці чотири питання — це не облікові дані. Це майбутній інцидент.

Жарт №2: Прострочені токени як прострочене молоко: неприємно, але принаймні ви помічаєте. Токени без терміну дії — як молоко, яке здається нормальним, поки не стане зовсім поганим.

Помилка №5: Плутати «є файрвол» з «є сегментація»

Хост Proxmox може мати правила файрвола і водночас бути відкритим на практиці. Чому? Бо сегментація — це архітектурне рішення, а не галочка в списку.
Якщо ваш інтерфейс керування, трафік VM, трафік сховища і кластерний трафік ділять ту саму L2/L3 зону, ви побудували середовище, де компрометація поширюється природно.

Як має виглядати сегментація

• Мережа керування: UI/API/SSH. Доступ лише з адміністративних пристроїв або перехідних серверів.
• Кластерна мережа: коросинк-трафік. Жорстке членство. Краще виділений VLAN або фізичні NICи.
• Мережа сховища: NFS/iSCSI/Ceph. Лише кінцеві точки сховища і хости, а не випадкові VM.
• Мережі VM: кілька VLAN/бриджів залежно від зон довіри.

Чому це важливо для контролю доступу

Атакувальники люблять латеральний рух більше, ніж початковий доступ. Якщо скомпрометована VM може зв’язатися з площиною керування хоста, це вже не «компрометація VM». Це перший крок.
Зменшуйте радіус ураження настільки, щоб ваша реакція на інцидент мала шанс бути нудною.

Швидкий план діагностики: що перевірити насамперед, по-друге, по-третє

Коли в контролі доступу щось здається «не так» — несподівані запити входу, дивна поведінка UI, флапінг вузлів, збій резервних копій — не метушіться. Проведіть швидку триаж-діагностику з визначеним порядком дій.
Цей план оптимізований для швидкого виявлення поширених, високоприоритетних проблем.

По-перше: підтвердіть експозицію та точки входу

• Чи доступний TCP/8006 з місць, де він не має бути?
• Чи доступний SSH на інтерфейсі керування з ненадійних підмереж?
• Чи є в ланцюжку зворотні проксі або переадресації портів?

По-друге: перевірте контролі ідентичності

• Чи адміністратори використовують іменовані облікові записи чи root?
• Чи застосовано двофакторну автентифікацію для людських адміністраторів?
• Чи існують токени для автоматизації, і чи вони мають обмежену область дії?

По-третє: перегляньте логи за доказами, а не відчуттями

• Недавні спроби входу та відмови (UI і SSH).
• Зміни дозволів, нові користувачі, нові токени.
• Зміни файрвола, зміни мережевих інтерфейсів.

По-четверте: перевірте сегментацію і межі довіри

• Чи можуть VM достукатися до IP-адрес керування?
• Чи можуть неадміністраторські VLANи дістатися до corosync або мережі сховища?
• Чи доступні кінцеві точки резервного копіювання з мереж орендарів?

Якщо ви знайдете одну серйозну проблему (відкритий UI, відкритий root SSH, відсутність двофакторної автентифікації), зупиніться і виправте її до продовження. «Я спочатку перевірю все» — так виникають додаткові глави у історії зламу.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: У логах стрибок спроб входу, UI працює повільно

Корінна причина: Веб-UI відкритий для широкої мережі; автоматизований масовий вхід або сканування.

Виправлення: Обмежте TCP/8006 через файрвол хоста та верхньорівневі ACL. Перенесіть керування на виділену підмережу. Додайте двофакторну автентифікацію і обмеження швидкості через правильний шлях доступу адміністратора (VPN/перехідний сервер).

2) Симптом: «root@pam» використовується для всього, немає підзвітності

Корінна причина: Культура зручності, відсутність дизайну RBAC, відсутня політика break-glass.

Виправлення: Створіть іменовані облікові записи адміністраторів, застосуйте двофакторну автентифікацію, вимкніть парольний SSH для root і резервуйте root лише для консолі/аварійних ситуацій.

3) Симптом: Скрипти автоматизації працюють… поки токен не витече

Корінна причина: Довготривалі API-токени зберігаються в відкритому вигляді, мають занадто широкі права.

Виправлення: Створюйте сфокусовані API-токени для кожного робочого навантаження, зберігайте їх у сховищі секретів (або хоча б у файлах доступних лише root), регулярно ротуйте і видаляйте зайві привілеї як Sys.Modify, якщо вони не потрібні.

4) Симптом: Компрометація VM перетворюється на компрометацію хоста

Корінна причина: Плоска мережа; VMs можуть дістатися до площини керування або кінцевих точок сховища; дозволяючі правила файрвола.

Виправлення: Сегрегуйте мережі, за замовчуванням блокуйте доступ VM→керування, і явно дозвольте лише необхідні схеми руху трафіку.

5) Симптом: Після інциденту резервні копії зникають або стають непридатними

Корінна причина: Облікові дані резервного копіювання дозволяють видаляти, сховище резервних копій доступне звідусіль, відсутність імунітету/примусових політик збереження.

Виправлення: Відокремте роль оператора резервних копій, обмежте мережеву доступність, забезпечте політику збереження і заборону видалення за замовчуванням.

6) Симптом: Нестабільність кластера після змін «посилення безпеки»

Корінна причина: Правила файрвола застосовані без розуміння трафіку corosync/кластеру; блоковані потрібні порти або шляхи multicast/unicast.

Виправлення: Застосовуйте зміни поступово, спочатку перевіряйте зв’язок кластера, тримайте запасний канал доступу і тестуйте на одному вузлі перед поширенням.

Практичні завдання: команди, очікуваний вивід і рішення

Це практичні завдання, які можна виконати на вузлі Proxmox (або вашому перехідному сервері), щоб відповісти на одне питання за раз: «Чи безпечно це?» і «Що робити далі?»
Команди припускають Debian-подібний хост Proxmox VE. Налаштуйте імена інтерфейсів та підмережі відповідно до вашого середовища.

Завдання 1: Підтвердити, що слухає хост (і де)

cr0x@server:~$ sudo ss -lntp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:8006       0.0.0.0:*     users:(("pveproxy",pid=1234,fd=6))
LISTEN 0      128    0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=987,fd=3))
LISTEN 0      4096   127.0.0.1:85       0.0.0.0:*     users:(("pvedaemon",pid=1100,fd=10))

Що означає вивід: pveproxy прив’язаний до 0.0.0.0:8006, отже доступний на всіх інтерфейсах, що маршрутизуються до хоста.

Рішення: Якщо хост має будь-який інтерфейс, не призначений для керування, обмежте доступ за допомогою правил файрвола або прив’яжіть сервіси керування до IP керування через дизайн мережі (переважно: доступ лише з мережі керування).

Завдання 2: Перевірити статус файрвола хоста в Proxmox

cr0x@server:~$ sudo pve-firewall status
Status: enabled/running

Що означає вивід: Фреймворк файрвола PVE активний.

Рішення: «Увімкнено» не означає «налаштовано». Продовжуйте: перевірте політики й правила. Якщо він вимкнений — увімкніть його і переконайтеся, що маєте запасний шлях доступу перед посиленням правил.

Завдання 3: Перевірити ефективні правила файрвола (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 ip saddr 10.10.10.0/24 accept
    tcp dport 8006 ip saddr 10.10.10.0/24 accept
    counter drop
  }
}

Що означає вивід: Політика за замовчуванням — drop з явними дозволами для SSH і 8006 лише з 10.10.10.0/24. Це бажана форма.

Рішення: Якщо ви бачите policy accept або широкі дозволи (наприклад, ip saddr 0.0.0.0/0), посиліть обмеження. Якщо правил бракує — реалізуйте їх на хості й на верхньому рівні файрвола.

Завдання 4: Протестувати досяжність з ненадійної мережі (зовнішня перевірка)

cr0x@server:~$ nc -vz 192.0.2.10 8006
nc: connect to 192.0.2.10 port 8006 (tcp) failed: Connection refused

Що означає вивід: З точки тестування сервіс недоступний (refused або timeout — обидва прийнятні залежно від політики).

Рішення: Якщо підключення встановлено — у вас проблема з експозицією. Виправте мережеві ACL/файрвол перед тим, як «просто додати двофакторну автентифікацію». Захист у глибину, а не захист від відчуттів.

Завдання 5: Перевірити, які користувачі існують у Proxmox і їхні домени

cr0x@server:~$ sudo pveum user list
Userid             Enable Expire Firstname Lastname Email Comment
root@pam           1             -        -        -     -
alice@pve          1             Alice    Admin    -     human admin
ci-bot@pve         1             -        -        -     automation

Що означає вивід: Користувачі існують у різних доменах (PAM, PVE). Це показує, чи ви ще живете з моделлю root@pam-лише.

Рішення: Якщо root — єдиний увімкнений адмін, створіть іменованих адміністраторів і обмежте використання root. Якщо автоматизація використовує людський обліковий запис — переведіть на токен.

Завдання 6: Перелічити API-токени (знайти забуті двері)

cr0x@server:~$ sudo pveum user token list ci-bot@pve
Tokenid     Privsep  Expire Comment
deploy      1        0      used by pipeline
oldscript   0        0      legacy

Що означає вивід: Токени існують; Expire 0 зазвичай означає «термін дії не встановлено». Privsep 1 краще, ніж 0, бо відокремлює права токена від користувача.

Рішення: Видаліть «legacy» токени. Ротуйте активні. Переконайтеся, що привілейоване розділення увімкнено і ACL токенів мають явну область дії.

Завдання 7: Аудит ACL (хто що може робити, де)

cr0x@server:~$ sudo pveum acl list
Path            Userid         Roleid
/               alice@pve      Administrator
/vms/100        ci-bot@pve     PVEVMAdmin

Що означає вивід: alice@pve має глобальний адміністраторський доступ (велике право). ci-bot@pve обмежений до шляху VM (хороший патерн).

Рішення: Приберіть широкі ролі з автоматизації. Зробіть область дії явною (для кожного VM, пулу або шляху ресурсів). Розгляньте розділення глобального адміністратора на ролі для сховища/мережі/кластера.

Завдання 8: Перевірити налаштування SSH root login

cr0x@server:~$ sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication'
permitrootlogin prohibit-password
passwordauthentication no
pubkeyauthentication yes

Що означає вивід: Root може входити лише за ключами; паролі вимкнені (добре). Ідеально, щоб root був no, якщо не потрібен для break-glass через консоль.

Рішення: Якщо passwordauthentication yes або permitrootlogin yes, виправте негайно. Якщо зберігаєте root-доступ за ключем, мінімізуйте та керуйте ключами.

Завдання 9: Знайти, які ключі авторизовані для root (перевірка розростання ключів)

cr0x@server:~$ sudo wc -l /root/.ssh/authorized_keys
12 /root/.ssh/authorized_keys

Що означає вивід: Дванадцять ключів. Це не обов’язково помилка, але рідко виправдано в невеликому середовищі.

Рішення: Видаліть застарілі ключі, впровадьте іменовані облікові записи і відмовтеся від моделі «root має ключі всіх». Розгляньте перехідний сервер з короткочасним доступом.

Завдання 10: Переглянути недавні події автентифікації (SSH і PAM)

cr0x@server:~$ sudo journalctl -u ssh -S "24 hours ago" | tail -n 20
Feb 04 08:11:32 pve1 sshd[22101]: Failed publickey for root from 203.0.113.50 port 51234 ssh2: RSA SHA256:...
Feb 04 08:11:37 pve1 sshd[22104]: Failed password for invalid user admin from 203.0.113.50 port 51261 ssh2
Feb 04 08:14:02 pve1 sshd[22210]: Accepted publickey for alice from 10.10.10.25 port 49152 ssh2: ED25519 SHA256:...

Що означає вивід: Ви бачите сканування з публічної IP-адреси і успішний вхід з підмережі керування.

Рішення: Якщо бачите повторні публічні сканування — перевірте шляхи експозиції. Якщо успішні входи з несподіваних підмереж — розглядайте це як потенційний інцидент і негайно посилюйте вхідні правила.

Завдання 11: Переглянути журнали завдань Proxmox для адміністративних дій

cr0x@server:~$ sudo tail -n 25 /var/log/pve/tasks/index
UPID:pve1:0002A1B3:0F3A2B1C:65C0F5E2:vzstart:100:alice@pve:
UPID:pve1:0002A1D8:0F3A2C90:65C0F61A:aclmod:/:root@pam:
UPID:pve1:0002A1F2:0F3A2D10:65C0F640:useradd::root@pam:

Що означає вивід: Адміністративні зміни виконані від імені root@pam. Це сигнальний показник для підзвітності і часто ознака «спільної сесії консолі».

Рішення: Міґруйте рутинні адміністративні операції на іменовані облікові записи. Встановіть правило: зміни root мають супроводжуватися квитком/примітками, навіть у лабораторії.

Завдання 12: Перевірити конфігурацію corosync і членство

cr0x@server:~$ sudo pvecm status
Cluster information
-------------------
Name:             labcluster
Config Version:   5
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Feb 04 09:02:11 2026
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Що означає вивід: Кластер здоровий і використовує захищену автентифікацію. Це ваша відправна точка, перш ніж торкатися правил файрвола навколо кластерного трафіку.

Рішення: Якщо кворум нестабільний або вузли відсутні — не переходьте до агресивних змін файрвола. Вирішіть проблеми з мережею кластера спочатку, інакше ви «забезпечите» кластер вимкненням.

Завдання 13: Перевірити, які інтерфейси несуть трафік керування і VM

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.10/24
vmbr0            UP             192.168.50.10/24
vmbr1            UP             172.16.20.10/24

Що означає вивід: У вас є окремі мережі. Якщо eno1 (керування) відрізняється від бриджів VM — ви на правильному шляху.

Рішення: Якщо керування і VM ділять той самий бридж — переробіть схему. Якщо сьогодні не можете переробити, екстрено заблокуйте підмережі VM від доступу до 8006/22.

Завдання 14: Перевірити, що VM не можуть дістатися до площини керування (швидкий тест з хоста)

cr0x@server:~$ sudo tcpdump -ni eno1 tcp port 8006 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
0 packets captured

Що означає вивід: Під час інтервалу захоплення трафіку до 8006 на NIC керування не зафіксовано. Це не доказ, але корисний сигнал.

Рішення: Якщо бачите IP-підмережі VM, що б’ють по 8006 — у вас збій сегментації. Впровадьте блокування на файрволі хоста і на межі L3.

Завдання 15: Визначити, чи доступні резервні копії з ненадійних мереж

cr0x@server:~$ sudo ss -lntp | egrep '(:8007|:9022|:22|:2049)'
LISTEN 0      4096   0.0.0.0:8007   0.0.0.0:* users:(("proxmox-backup-proxy",pid=1444,fd=10))
LISTEN 0      128    0.0.0.0:9022   0.0.0.0:* users:(("proxmox-backup-api",pid=1401,fd=9))

Що означає вивід: Сервіси Proxmox Backup Server слухають на всіх інтерфейсах.

Рішення: Обмежте ці порти лише для підмереж клієнтів резервного копіювання/адмінів. Резервні копії — частина вашого периметра безпеки, а не побічне завдання.

Завдання 16: Перевірити синхронізацію часу (тиха залежність безпеки доступу)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-04 09:10:22 UTC
           Universal time: Tue 2026-02-04 09:10:22 UTC
                 RTC time: Tue 2026-02-04 09:10:22
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що означає вивід: Годинник синхронізовано. Це важливо для кореляції логів, дійсності токенів і хронології інцидентів.

Рішення: Якщо час має зсув або NTP неактивний — виправте це перш ніж інтерпретувати «коли стався цей вхід?» між вузлами.

Три корпоративні міні-історії з відділу «таке траплялося»

Міні-історія 1 (неправильне припущення): «UI не публічний, він за NAT»

Середня компанія експлуатувала кластер Proxmox для внутрішніх сервісів. Команда була компетентною, зайнятою та полюбляла фразу «він за NAT». Інтерфейс керування був у підмережі сервера, яка вважалася «тільки внутрішньою».
Потім компанія розрослася. Зʼявився новий site-to-site VPN і додали партнерську мережу для спрощення спільного проєкту. Маршрутизація стала простішою. Безпека — менш чіткою.

Ніхто не оновив модель загроз, бо ніхто її не записував. TCP/8006 Proxmox став доступний із партнерської підмережі. Не навмисно. Просто як побічний ефект «давайте мережа працювала».
Тиждень потому логи показали потік невдалих спроб входу з IP партнера. Це не виглядало як інтернет, тому не викликало тривоги.

Початковий доступ не був магією. Адмін використав спільний пароль (так, досі так буває) «для тимчасової зручності». Той пароль зʼявився в дампі облікових даних, повʼязаному з іншою службою.
Отримавши доступ до UI, атакувальнику не знадобилися вразливості ядра. Він створив нового привілейованого користувача, змонтував ISO і використав гостя як проміжний пункт.

Постмортем не був про баги Proxmox. Він був про неправильне припущення, що «внутрішні маршрути = надійні маршрути». Виправлення було нудним і рішучим:
керування перемістили на виділену підмережу, UI/API дозволялися лише з перехідного сервера, двофакторну автентифікацію зробили обовʼязковою, а спільні облікові дані стали забороненими в скриптах і предметом навчання для людей.

Міні-історія 2 (оптимізація, що обернулась проти): «Давайте поставимо UI за зворотним проксі»

Інша організація хотіла «одну панель для всього». У них уже був стек зворотних проксі для додатків з автоматичними сертифікатами і приємними дашбордами.
Хтось запропонував і Proxmox закинути за нього. Чисті URL, централізований TLS, узгоджені шаблони доступу. Усі люблять узгодженість — до моменту, коли вона систематично неправильна.

Проксі був доступний з більшої кількості місць, ніж первісна мережа керування, бо обслуговував загальні внутрішні додатки. Контроль доступу був на шарі проксі, який підтримувала інша команда, не віртуалізаційна.
Команда віртуалізації думала, що проксі- команда відповідає за автентифікацію. Проксі‑команда думала, що Proxmox відповідає. Обидві були частково праві. Жодна — повністю.

Справжня проблема: зміна конфігурації внесла обхід автентифікації для певного патерну шляху. Це не було зловмисно; це був «дозволити health checks», який скопіпастили.
Раптом API Proxmox мав частковий неавторизований доступ із внутрішніх мереж. Не досить, щоб одразу заволодіти кластером, але достатньо для переліку інформації. Перелік — спосіб зробити таргетовані атаки тихішими.

Вони помітили це, бо інженер з безпеки провів рутинне сканування і ввічливо, але наполегливо запитував, чому API гіпервізора відповідає інакше, ніж очікувалось.
Вирішення: прибрати Proxmox з загального проксі, тримати доступ через VPN+перехідний сервер і вимагати, щоб будь-яке майбутнє проксування площин керування проходило через огляд безпеки з явними allowlist шляхами.

Оптимізація не безкоштовна. Централізація зменшує операційну працю і збільшує радіус ураження. Робіть це лише коли можете гарантувати відповідальність, огляд і логування на тій самій якості, що й у системи, які ви фронтуєте.

Міні-історія 3 (нудна, але правильна практика): «Політика перехідного сервера, яку ніхто не любив»

Велике підприємство експлуатувало кілька кластерів Proxmox для краєвих навантажень. Політика була надто сувора: прямий доступ до UI лише з жорстко налаштованого перехідного сервера; MFA обовʼязкова; немає SSH з ноутбуків; токени привʼязані до сервісів; щотижневий перегляд логів.
Інженери нарікали. Дехто намагався обійти правила. Служба безпеки сказала «ні». Це було, чесно кажучи, не популярне рішення.

Потім робочу станцію розробника зламали через експлойт у браузері. Атакувальник отримав доступ до внутрішніх мереж, зібрав купу SSH-ключів і спробував рухатися в інфраструктуру.
В більшість днів це перетворилося б на дорого обійшовся інцидент.

Але ключі не працювали проти хостів Proxmox, бо SSH був доступний лише з підмережі перехідного сервера. UI теж був недоступний.
Атакувальник потім спробував зайти на перехідний сервер, натрапив на MFA і застряг. Він перейшов до легших мішеней: dev‑сервісів, тестових середовищ, низьковартісних систем.

Інцидент все одно спричинив збитки — скомпрометовані кінцеві точки завжди болять — але він не перетворився на «володіння гіпервізорами». Ота нудна політика тримала коштовності за дверима, які атакувальник не зміг тихо відкрити.
На післяінцидентному зібранні команда рідко мала таке щастя: керівні контролі виявилися найдешевшою страховкою.

Контрольні списки / покроковий план

Покроково: закрийте доступ, не відрізаючи себе

1. Підтвердіть запасний шлях: переконайтеся, що маєте фізичну консоль/IPMI/iDRAC або KVM-over-IP. Якщо ні — не переходьте до агресивних змін файрвола.
2. Інвентаризація точок входу: перелічіть порти, що слухають (ss -lntp), і зіставте їх з інтерфейсами (ip -br addr).
3. Визначте підмережу керування: оберіть одну адмінську мережу (приклад: 10.10.10.0/24) і задокументуйте її.
4. Обмежте UI/API: дозволяйте TCP/8006 лише з підмережі адміністраторів/перехідного сервера. Блокуйте все інше.
5. Обмежте SSH: дозволяйте TCP/22 лише з підмережі адміністраторів. Вимкніть парольну автентифікацію. Де можливо — забороніть root входи.
6. Припиніть використовувати спільні ідентичності: створіть іменовані облікові записи адміністраторів. Переведіть людей на вхід із MFA.
7. Реалізуйте RBAC: створіть ролі для VM-операцій, операцій зі сховищем і для аудиту/перегляду логів. Уникайте глобального адміністратора без потреби.
8. Виправте автоматизацію: використовуйте API-токени для кожного пайплайна/сервісу, обмежені до мінімального набору шляхів. Зберігайте токени у сховищі секретів і ротуйте їх.
9. Сегментуйте мережі: розділіть мережі керування, VM, сховища, кластер. Якщо не можете — застосуйте файрвол для логічної ізоляції.
10. Захистіть резервні копії: обмежте порти резервного копіювання, розділіть облікові дані, забороніть видалення за замовчуванням і перевіряйте процедури відновлення.
11. Увімкніть і переглядайте логи: перевіряйте SSH-логи, журнали завдань Proxmox та логи файрвола. Встановіть щотижневу звичку.
12. Зробіть перевірку валідації: протестуйте доступність з ненадійної мережі і переконайтеся, що підключення до 8006/22 відмовляється.

Контрольний список доступу (запам’ятати в голові)

• UI/API доступні лише з перехідного сервера або підмережі VPN, якій ви довіряєте.
• Жодного парольного SSH. Ніякого прямого root SSH (або суворо контрольований break-glass).
• Іменовані адміністратори з MFA; жодних спільних облікових записів.
• Автоматизація використовує API-токени з привілейованим розділенням і явними ACL.
• Мережі VM не можуть дістатися до інтерфейсів керування.
• Резервні копії мають окремий доступ, окремі облікові дані і захищене видалення.
• Логи переглядаються регулярно; підозрілі спроби автентифікації — це дія, а не декорація.

ЧаПи

1) Чи коли-небудь нормально відкривати Proxmox TCP/8006 в інтернет, якщо я використовую сильні паролі?

Ні. Сильні паролі зменшують один ризик. Вони не зменшують сканування, фішинг, викрадення токенів у браузері, баги в UI або повторне використання облікових даних з часом.
Розміщуйте UI за VPN або перехідним сервером і обмежуйте вхід на мережевому рівні.

2) Чи можна просто змінити порт з 8006 на інший?

Зміна порту зменшує шум, але не ризик. Атакувальники сканують діапазони і визначають сервіси за сигнатурами. Якщо ви розраховуєте на прихованість порту, ви почуватиметеся в безпеці, поки раптом ні.
Краще зробити належне обмеження доступу.

3) Чи слід повністю вимкнути root?

У Linux root існує. Питання — як його використовують. Ставте root як break-glass: доступ через консоль, аварійні випадки, контрольовані зміни.
Для щоденних операцій використовуйте іменовані облікові записи і RBAC.

4) Яка мінімальна конфігурація RBAC, що реально допомагає?

Створіть принаймні: одну роль адміністратора для змін на рівні кластера, одну роль оператора VM для щоденних дій з VM і одну роль оператора резервних копій.
Потім обмежуйте ролі до шляхів ресурсів (по пулу або діапазону VM), а не давайте глобальні права за замовчуванням.

5) Чи достатньо VLAN-сегментації, щоб блокувати скомпрометовану VM від доступу до керування?

Тільки якщо маршрутизація між VLANами строго контролюється. У багатьох лабораторіях між-VLAN маршрути відкриті «бо так зручно».
Використовуйте правила файрвола на межах L3 і, де можливо, тримайте мережу керування в мережі, недоступній для VM взагалі.

6) Чи безпечніші API-токени, ніж збереження логіна і пароля для автоматизації?

Так, якщо їх використовувати правильно. Токени можна обмежувати, ротуйте і відокремлювати від прав користувача.
Але токен з широкими правами й без циклу життя — це просто краще упакований пароль.

7) Як дізнатися, чи хтоось брутфорсить мій Proxmox або SSH?

Шукайте повторні невдалі спроби автентифікації в journalctl -u ssh і в логах автентифікації Proxmox.
Також стежте за підвищеною завантаженістю CPU у pveproxy і за незвичними діапазонами IP-адрес джерел. Потім виправте експозицію; не просто блокуйте окрему IP.

8) Що щодо використання зворотного проксі з SSO перед Proxmox?

Можна, але це легко зробити небезпечно. Ви додаєте критичну залежність: якщо проксі неправильно маршрутизує або обходить автентифікацію для шляху, ваша площина керування буде експонована.
Тримайте площину керування на виділеному шляху доступу, якщо не можете гарантувати жорстке налаштування, відповідальність і аудит стеку проксі.

9) Якщо я ввімкну двофакторну автентифікацію, чи можу послабити мережеві обмеження?

Ні. Двофактор — це шар, а не заміна мережевих меж. Спочатку обмежте досяжність, потім додайте двофактор для людей і обмежте токени для автоматизації.
Шари допомагають пережити відмову одного шару.

10) Як резервні копії вписуються в контроль доступу?

Резервні копії — це площина керування для відновлення. Якщо атакувальники можуть отримати до них доступ або видалити їх, вони можуть використовувати ваші дані проти вас.
Розміщуйте служби резервного копіювання в обмежених мережах, мінімізуйте права на видалення і тестуйте відновлення під припущенням, що продакшен-облікові дані скомпрометовано.

Наступні кроки, які ви можете зробити цього тижня

Якщо ваше середовище Proxmox сьогодні — лабораторія, поводьтеся так, ніби воно матиме значення завтра. Бо воно матиме.
Ось практичний порядок, який дає швидке зниження ризику без місячного редизайну.

1. Приберіть експозицію: обмежте TCP/8006 і TCP/22 до вашої підмережі адміністраторів/перехідного сервера.
2. Перестаньте використовувати root для рутинної роботи: створіть іменованих адміністраторів і змініть звички.
3. Увімкніть MFA для людей: не відкладайте це до наступного кварталу.
4. Виправте ідентичність автоматизації: замініть спільні людські облікові дані на сфокусовані токени.
5. Сегментуйте або блокуйте: забезпечте, щоб VM не могли дістатися до площини керування; робіть це через мережевий дизайн або файрвол (краще обидва).
6. Захистіть резервні копії: обмежте кінцеві точки резервного копіювання, розділіть права і переконайтеся, що можете відновити.
7. Заплануйте перегляд логів: щотижневі 15 хвилинні перевірки вловлять більше, ніж ви готові визнати.

Мета не в ідеальній безпеці. Мета — зробити компрометацію дорогою, гучною і локалізованою. Якщо ваша лабораторія переживе ваші власні помилки, вона має шанс протистояти чийомусь зловмисному наміру.