Контрольний список безпеки Proxmox: 2FA, RBAC, брандмауер, оновлення та безпечний віддалений доступ

Модель загроз на одній сторінці: що ви захищаєте

Proxmox — це plane управління, а не лише гіпервізор. Якщо зловмисник потрапляє в Proxmox, він не отримає лише одну ВМ.
Він отримує можливість монтувати диски, створювати снапшоти і вивантажувати дані, читати вихід консолі (привіт, секрети), підключати ISO,
і змінювати мережеві налаштування. «root на хості» — катастрофа; «адмін в UI» часто рівнозначний.

Що зазвичай іде не так

• Відкритий інтерфейс управління (8006) в Інтернеті, іноді з аутентифікацією паролем і без 2FA.
• Надмірні права операторів («дайте їм PVEAdmin, щоби могли робити роботу»), які залишаються назавжди.
• Припущення щодо брандмауера: люди вважають, що брандмауер датацентру «увімкнений», бо в UI є чекбокс.
• Уникнення патчів через «ми не можемо перезавантажитися». Спойлер: можете, або перезавантажитесь о 3 ранку під час інциденту.
• Шляхи віддаленого доступу з хитрощами: SSH звідусіль, спільні jump box-и або ще гірше — спільні облікові записи.

Пріоритети жорсткості (суб’єктивно)

1. Зробіть plane управління недоступним з недовірених мереж. VPN або виділена мережа адміністрування.
2. Забезпечте 2FA для всіх людей. Токени для автоматизації.
3. Правильно використовуйте RBAC: найменші привілеї, явні ролі, розділення «операції з ВМ» і «зміни кластера».
4. Увімкніть і перевірте брандмауер на потрібному шарі, з політикою default-deny там, де це важливо.
5. Патчуйте з планом: передбачувані вікна обслуговування, поетапні оновлення і дисципліна щодо перезавантажень.

Парафраз ідеї від Werner Vogels (надійність/операції): «Усе колись ламається; проєктуйте, припускаючи відмову, а не ідеальність.»
Саме така енергія знадобиться тут.

Цікаві факти й контекст (щоб ви перестали робити помилки 2008 року)

• Факт 1: Порт керування Proxmox VE за замовчуванням — 8006, і сканери його люблять, бо він постійний і «балакучий».
• Факт 2: Брандмауер Proxmox — це не «лише iptables». Він компілює правила і керує ними; потрібно перевіряти ефективні правила на хості.
• Факт 3: RBAC у Proxmox базується на шляхах. Права наслідуються по дереву об’єктів (datacenter → node → VM), що потужно і легко перетворюється на надмірні права.
• Факт 4: Існують API-токени не випадково: автоматизація не має логінитися як людина. Токени можна обмежувати і обертати без драм.
• Факт 5: Мережі для адміністрування стали стандартом у 2000-х, бо «помилка з admin VLAN» була дешевшою за «володіння всім флотом».
• Факт 6: «SSH тільки на паролі» протримався довше, ніж мав би, бо зручно. Зручність — не контроль; це ризик.
• Факт 7: Культура пакування Debian віддає перевагу стабільності, але патчі безпеки приходять регулярно. «Stable» не означає «статичний».
• Факт 8: Кластерний трафік (Corosync) має інші потреби, ніж трафік веб-інтерфейсу; трактувати його як звичайний користувацький трафік — чудовий спосіб створити відмови.

Контрольні списки / поетапний план (робіть це, а не за відчуттями)

День 0–1: Зупиніть витік

1. Заблокуйте публічний доступ до 8006 і SSH на кордоні. Якщо не можете — у вас не management plane, а публічний API.
2. Увімкніть 2FA для всіх інтерактивних користувачів. Ніяких винятків для «тимчасових» обліковок.
3. Аудитуйте користувачів/токени. Видаліть застарілі обліковки, обертайте секрети, припиніть спільні логіни.
4. Підтвердіть стан брандмауера (datacenter + node) і перевірте ефективні правила на хості.
5. Базове оновлення: доведіть усі вузли до поточного стану безпеки; заплануйте перезавантаження.

Тиждень 1: Зробіть усе нудним

1. Визначте ролі RBAC для типових задач (оператор ВМ, оператор бекапів, адміністратор сховища, адміністратор кластера).
2. Ізолюйте адмінмережу на окрему мережу або VPN, і за можливості прив’яжіть сервіси до неї.
3. Ускладніть SSH (ключі, заборона root, обмеження джерел).
4. Логування і оповіщення: відстежуйте відмови автентифікації, зміни конфігурації і відхилення брандмауера.

Місяць 1: Зменшіть площу ураження

1. Розділення обов’язків: зміни членства в кластері і конфігурації сховища повинні бути в дуже вузькому колі людей.
2. Тестуйте шляхи відновлення і заблокуйте доступ до сховищ бекапів; бекапи — перша ціль для вивантаження після основних даних.
3. Документуйте runbook-и для інцидентів: втрата 2FA-пристрою, скомпрометований акаунт, відновлення вузла.

2FA, що дійсно знижує ризик (і не позбавляє адміністраторів доступу)

2FA — це не магія. Це ремінь безпеки: він не запобігає аваріям; він не дає поганому дню стати катастрофою.
Використовуйте TOTP або WebAuthn залежно від культури і інструментів. Насправді TOTP найпростіше розгорнути. WebAuthn приємніший, якщо в організації вже розуміють ключі безпеки і життєвий цикл пристроїв.

Правила, які я застосовую в production

• 2FA обов’язково для всіх людських обліковок з доступом до UI або shell.
• Ніяких спільних обліковок. Спільні обліковки роблять аудит вигаданим.
• Існує break-glass, але він неприємний: запечатана процедура, зберігання офлайн і паперовий слід.
• Автоматика використовує API-токени, а не паролі. Токени обертаються; людям не місце в скриптах з паролями.

Жарт 1: 2FA як чищення зубів — усі згодні, що треба, а потім «починають наступного тижня» три роки.

Режими відмов, про які треба думати

• Втрачений пристрій: якщо немає процесу відновлення, ваше «покращення безпеки» перетвориться на простій.
• Дрейф часу: TOTP не працює, якщо час хоста некоректний. NTP — не опція.
• Шкідливе ПЗ, що записує екран чи буфер обміну: 2FA не вирішує скомпрометовані кінцеві точки. Воно лише підвищує планку.

RBAC: проєктування прав для людей, які помилятимуться

Пастка Proxmox RBAC у тому, що він потужний і оманливо простий. Ви призначаєте роль користувачу на шляху, і вона наслідується.
Через два місяці хтось здивований, чому підрядник може змінювати сховище на всіх вузлах. Відповідь: бо ви дали їм права на /.

Патерн RBAC, що працює

• Використовуйте групи для людей. Призначайте ролі групам, а не індивідуумам. Люди приходять і йдуть; групи — це політика.
• Використовуйте вузькі шляхи. Призначайте операторів ВМ на /vms або конкретні пулли, а не на /.
• Розділяйте «операції» від «змін інфраструктури». Запуск/зупинка ВМ — не те саме, що додавання сховища або приєднання вузла до кластера.
• Обмежуйте доступ до логів. Логи містять секрети частіше, ніж ви думаєте (cloud-init user-data, вихід консолі, токени в змінних оточення).

Ролі, які варто визначити (приклади)

• VM Operator: запуск/зупинка, доступ до консолі, снапшот (можливо), але без прав на сховище та зміни мережі.
• Backup Operator: запуск/моніторинг бекапів, відновлення у quarantine-пул, але без змін продакшн-мережі.
• Storage Admin: конфігурація сховища, реплікація, задачі прибирання. Без прав змінювати автентифікацію користувачів.
• Cluster Admin: рідко. Може змінювати членство в кластері, corosync-конфіг, обслуговування вузлів.

Якщо ви не можете пояснити роль в одному реченні — це не роль. Це відро.

Брандмауер для Proxmox: хост, датацентр і «не відкривайте UI»

Брандмауер Proxmox може бути відмінним. Він також може бути плацебо, якщо ви не розумієте, що саме застосовано.
Безпека не має залежати від одного чекбоксу в GUI. Потрібен defense in depth: крайовий брандмауер, ізоляція мережі адміністрування,
та контролі на рівні хоста.

Безкомпромісні вхідні правила

• UI управління (8006): лише з адмінмережі / VPN.
• SSH (22): лише з адмінмережі / бастіону.
• Кластерний трафік: лише між вузлами по кластерній мережі (і не NAT-те його).
• Бекенди сховища (NFS, iSCSI, Ceph тощо): лише між відповідними учасниками. Ніякого «any to any».

Default deny там, де це важить

Найбезпечніша модель — default-deny для вхідних з’єднань на інтерфейсах управління з явними allow-правилами. Для містків ВМ історія залежить від вашої моделі орендарів.
Якщо ви запускаєте внутрішні навантаження і довіряєте політикам east-west, можна бути менш суворими. Якщо мульти-орендарність — в пріоритеті,
вважайте, що ви хостите креативних противників.

Не плутайте «може ping-нути» з «безпечно»

ICMP нічого не каже. Зловмисникам не потрібен ping. Їм потрібен відкритий сокет і одна помилка.
Ваше завдання — зробити сокет недоступним з місць, де його не має бути.

Оновлення та супровід: швидкі патчі без ризику для працездатності

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

Стратегія патчування для production, що масштабується

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

Жарт 2: «Ми не перезавантажуємо production» — чудова політика, поки ядро не перезавантажить production за вас у найгірший момент.

Оновлення безпеки vs функціональні оновлення

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

Безпечний віддалений доступ: VPN, бастіони та гігієна SSH

Єдиний безпечний спосіб керувати Proxmox віддалено — зменшити кількість місць, звідки доступний management.
«Доступ з Інтернету, але захищено менеджером паролів» — не стратегія. Це зізнання.

Бажані патерни (виберіть один, не імпровізуйте)

1. VPN до адмінмережі: найпростіша модель. Адміни аутентифікуються в VPN, потім доступаються до Proxmox приватно.
2. Бастіон / jump host: SSH до бастіону з сильною автентифікацією, потім хоп до вузлів Proxmox. Доступ до UI через порт-форвардинг або внутрішній проксі.
3. Виділена мережа управління, доступна лише з on-prem або VPN: «нудна корпоративна» модель — і недарма.

Правила жорсткості SSH, що не зіпсують життя

• Лише ключі, ні паролів.
• Заборонити root через SSH. Використовуйте sudo з аудитуємими користувачами.
• Обмежуйте вихідні IP до адмін-підмереж.
• Окремі облікові записи адміністраторів для кожної людини; використовуйте групи і sudo-політики.

Доступ до Web UI без відкриття для всього світу

Якщо потрібно доступатися до UI віддалено — робіть це через VPN. Якщо ні — ставте зворотний проксі з сильною автентифікацією і allowlist-ом IP,
але розумійте, що ви додали складність. Складність не є контролем, але може бути компенсуючим контролем, якщо ви його оперуєте добре.

Аудитні завдання з командами: що запускати, що означає, що вирішувати

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

Завдання 1: Перевірити версію Proxmox і стан кластера

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/9355359f (running kernel: 6.8.12-2-pve)
proxmox-ve/8.2.0 (running kernel: 6.8.12-2-pve)
pve-kernel-6.8/6.8.12-2

Що це означає: Ви на PVE 8.2.x з конкретним ядром. Якщо різні вузли мають різні мінорні версії — це «працює, поки не перестане» середовище.

Рішення: Вирівняйте версії в кластері перед налагодженням дивних проблем або впровадженням нових функцій.

Завдання 2: Перевірити здоров’я кластера і кворум

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 10:14:22 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Що це означає: Кворум здоровий. Якщо Quorate: No, не змінюйте конфігурацію кластера; ви в одному кроці від простою.

Рішення: Якщо немає кворуму, виправте мережу між вузлами першочергово; відкладіть оновлення і перезавантаження.

Завдання 3: Підтвердити NTP/синхронізацію часу (2FA від цього залежить)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:14:42 UTC
           Universal time: Sun 2025-12-28 10:14:42 UTC
                 RTC time: Sun 2025-12-28 10:14:41
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Годинник синхронізований. Якщо ні — TOTP відмови і TLS-проблеми з’являться як привиди.

Рішення: Якщо не синхронізовано, виправте NTP перед розгортанням або вимаганням 2FA.

Завдання 4: Перелік користувачів і виявлення локальних vs realm-акаунтів

cr0x@server:~$ pveum user list
┌──────────────┬─────────┬───────────────────────┬────────────┬────────┬──────────────┐
│ userid       │ enable  │ expire                │ firstname  │ lastname│ email        │
╞══════════════╪═════════╪═══════════════════════╪════════════╪════════╪══════════════╡
│ root@pam     │ 1       │                       │            │        │              │
│ alice@pam    │ 1       │                       │ Alice      │ Ops    │              │
│ bob@pve      │ 1       │ 2026-01-31 00:00:00   │ Bob        │ Eng    │              │
└──────────────┴─────────┴──────────────┴────────────┴────────┴──────────────┘

Що це означає: У вас є користувачі в різних realms (@pam, @pve). Існують терміни дії; використовуйте їх для підрядників.

Рішення: Вимикайте або встановлюйте термін дії для обліковок, що не належать поточній людині з тикетом.

Завдання 5: Перевірити конфіг TOTP/2FA для користувача

cr0x@server:~$ pveum user get alice@pam
enable: 1
expire: 0
firstname: Alice
lastname: Ops
groups: ops
keys:
totp:
  enabled: 1
  issuer: pve
  realm: pam

Що це означає: TOTP увімкнено для користувача. Якщо enabled: 0, вони все ще можуть увійти лише паролем, якщо політика не накладається зовні.

Рішення: Вимагайте 2FA для інтерактивних користувачів; реалізуйте auditable break-glass.

Завдання 6: Переглянути групи і призначення ролей (аудит RBAC)

cr0x@server:~$ pveum group list
┌────────────┬────────┬─────────────┐
│ groupid    │ comment│ users       │
╞════════════╪════════╪═════════════╡
│ ops        │        │ alice@pam   │
│ vm-ops     │        │ bob@pve     │
└────────────┴────────┴─────────────┘

cr0x@server:~$ pveum acl list
┌────────────┬──────────┬───────────────┬───────────┐
│ path       │ type     │ ugid          │ roleid    │
╞════════════╪══════════╪═══════════════╪═══════════╡
│ /          │ group    │ ops           │ PVEAdmin  │
│ /vms       │ group    │ vm-ops        │ PVEVMAdmin│
└────────────┴──────────┴───────────────┴───────────┘

Що це означає: Група ops має PVEAdmin на /, що фактично дає «режим бога». Це поширена надмірність.

Рішення: Перемістіть широкі ролі з /. Надавайте PVEAdmin лише невеликій групі cluster-admin, а інші ролі скопуйте по пулам/шляхам.

Завдання 7: Перевірити API-токени (гігієна автоматизації)

cr0x@server:~$ pveum user token list alice@pam
┌───────────────┬────────┬──────────────┬──────────┐
│ tokenid       │ enable │ expire       │ privsep  │
╞═══════════════╪════════╪══════════════╪══════════╡
│ backup-bot    │ 1      │ 2026-03-01   │ 1        │
└───────────────┴────────┴──────────────┴──────────┘

Що це означає: Токени існують і privsep увімкнено (добре). Термін дії встановлено (ще краще).

Рішення: Обертайте токени по графіку; відключайте ті, що не прив’язані до керованого workflow.

Завдання 8: Підтвердити, що брандмауер Proxmox увімкнено (datacenter і node)

cr0x@server:~$ pvesh get /cluster/firewall/options
{ "enable": 1, "policy_in": "DROP", "policy_out": "ACCEPT", "log_level_in": "info" }

cr0x@server:~$ pvesh get /nodes/pve1/firewall/options
{ "enable": 1, "policy_in": "DROP", "policy_out": "ACCEPT", "log_level_in": "info" }

Що це означає: Брандмауер увімкнено і політика вхідних — DROP. Якщо вимкнено на будь-якому рівні, правила можуть не застосовуватись там, де ви думаєте.

Рішення: Якщо вхідна політика встановлена в ACCEPT на інтерфейсах управління, змініть її і явним чином дозволіть потрібні адмін-підмережі.

Завдання 9: Перевірити сервіси, що слухають, і адреси прив’язки

cr0x@server:~$ ss -lntp | head
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=1520,fd=6))
LISTEN 0      4096   0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=1042,fd=3))
LISTEN 0      4096   127.0.0.1:85       0.0.0.0:*     users:(("pvedaemon",pid=1400,fd=12))

Що це означає: UI і SSH слухають на всіх інтерфейсах (0.0.0.0). Це не автоматично неправильно, але підвищує ставки: брандмауер і мережна ізоляція мають бути коректні.

Рішення: Якщо можете — прив’яжіть management до адмін-інтерфейсу; інакше забезпечте суворі allowlist-и для вхідних з’єднань.

Завдання 10: Перевірити фактичні правила брандмауера на хості (правда)

cr0x@server:~$ nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    ip saddr 10.50.0.0/24 tcp dport { 22, 8006 } accept
    ip saddr 10.50.0.0/24 icmp type echo-request accept
    counter log prefix "PVE-DROP " drop
  }
}

Що це означає: Default drop, явний дозвіл з адмін-підмережі на SSH/UI. Це те, чого ви прагнете: читабельні, мінімальні, контрольовані правила.

Рішення: Якщо політика — accept або правила відсутні, виправте конфіг брандмауера і перевірте тут — не лише в UI.

Завдання 11: Перевірити, що конфіг SSH не тихо ліберальний

cr0x@server:~$ sshd -T | egrep '^(passwordauthentication|permitrootlogin|pubkeyauthentication|allowusers|allowgroups)'
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Що це означає: Парольна автентифікація вимкнена; root входи вимкнені; ключі увімкнені. Якщо passwordauthentication yes, ви запрошуєте brute-force, якщо відкрито зовні.

Рішення: Вимкніть парольну автентифікацію й обмежте джерела; потім протестуйте доступ з другої сесії відкритою.

Завдання 12: Перевірити наявність потрібного перезавантаження після оновлень ядра/безпеки

cr0x@server:~$ [ -f /var/run/reboot-required ] && echo "reboot required" || echo "no reboot required"
reboot required

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

Рішення: Заплануйте міграцію і перезавантаження в наступному вікні. Не дозволяйте цьому сидіти місяцями.

Завдання 13: Подивитись, які оновлення очікують (щоб не здивуватися)

cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,40p'
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-manager pve-kernel-6.8 proxmox-widget-toolkit
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Що це означає: Симуляція апгрейду показує, що зміниться. Якщо ви бачите corosync або libc — плануйте перезавантаження і обережне послідовне оновлення.

Рішення: Погодьте зміни у вашому плані обслуговування; оновіть один вузол першим.

Завдання 14: Перевірити стан TLS-сертифіката UI (щоб не створювати недовіру)

cr0x@server:~$ openssl s_client -connect 127.0.0.1:8006 -servername pve1 -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = pve1
issuer=CN = pve1
notBefore=Sep  1 00:00:00 2025 GMT
notAfter=Sep  1 00:00:00 2035 GMT

Що це означає: Ви використовуєте самопідписаний сертифікат (issuer = subject). Це прийнятно всередині, якщо ви довіряєте/поширюєте його; це недбало, якщо UI відкритий зовні.

Рішення: Тримайте UI внутрішнім. Якщо потрібно відкривати — термінуйте TLS правильно з керованим сертифікатом і сильною автентифікацією попереду.

Завдання 15: Перевірити відмови автентифікації в логах (реальність поверхні атаки)

cr0x@server:~$ journalctl -u pveproxy --since "24 hours ago" | egrep -i 'authentication|login|failed' | tail -n 10
Dec 28 08:41:12 pve1 pveproxy[1520]: authentication failure; rhost=198.51.100.23 user=root@pam
Dec 28 08:41:14 pve1 pveproxy[1520]: authentication failure; rhost=198.51.100.23 user=admin@pve

Що це означає: Хтось стукає. Якщо цей IP не ваш VPN/бастіон — ваш management plane доступний з недовірених мереж.

Рішення: Виправте маршрутизацію/брандмауер зараз. Потім подумайте про бан на грані; блокування на хості — пластир, а не броня.

Завдання 16: Підтвердити, що лише очікувані підмережі можуть дістатися UI з віддаленої точки

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

Що це означає: З цієї точки UI недоступний. «Connection refused» або «timed out» — бажаний результат з неадмінмереж.

Рішення: Якщо порт відкритий з загальних мереж — виправте ACL і повторіть перевірку з кількох мереж.

Швидкий план діагностики (перші/другі/треті перевірки)

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

Сценарій A: Адмін не може увійти в UI

1. Перевірте синхронізацію часу (відмова TOTP/WebAuthn часто через дрейф годинника). Запустіть timedatectl. Якщо не синхронізовано — виправте NTP і повторіть спробу.
2. Перевірте доступність з потрібної мережі. Ви в VPN/адмін VLAN? Перевірте nc -vz pve1 8006.
3. Перегляньте логи pveproxy на предмет помилок автентифікації проти TLS чи мережевих блокувань (journalctl -u pveproxy).

Сценарій B: Операції кластера повільні або не працюють після змін брандмауера

1. Перевірте кворум (pvecm status). Якщо кворум нестабільний — припиніть зміни.
2. Перевірте зв’язок між вузлами на кластерній мережі (ping недостатній; перевірте потрібні порти і відсутність скидань).
3. Перевірте лічильники/логи nftables (nft list ruleset, потім шукайте лічильники drop). Якщо бачите drop між IP вузлів — виправте allow-правила.

Сценарій C: Підозра, що UI відкрито публічно

1. Перевірте логи на зовнішні IP, що звертаються до endpoint-ів автентифікації (journalctl -u pveproxy).
2. Підтвердіть bind/listen (ss -lntp). Прослуховування на 0.0.0.0:8006 не доказ експозиції, але підвищує ризик.
3. Перевірте крайові контроли: чи може неадмінська точка доступу дістатися 8006? Якщо так — закрийте кордон і на хості.

Поширені помилки: симптом → корінь проблеми → виправлення

1) Симптом: коди 2FA «ніколи не працюють» у кількох користувачів

Корінь проблеми: Дрейф часу на вузлі (або клієнтах), NTP вимкнено або проблеми з годинником гіпервізора.

Виправлення: Увімкніть NTP, переконайтесь, що timedatectl показує синхронізацію, потім перевстановіть профілі при потребі. Не знижуйте вимоги автентифікації, щоб «поправити» це.

2) Симптом: Оператор може видалити сховище або змінити мережу «випадково»

Корінь проблеми: Роль RBAC призначена на / або використовуються надто широкі вбудовані ролі заради зручності.

Виправлення: Створіть сфокусовані групи та ACL на конкретних шляхах/пулах; залишіть PVEAdmin лише для невеликої групи cluster-admin.

3) Симптом: Брандмауер увімкнений, але порт 8006 все ще доступний звідусіль

Корінь проблеми: Брандмауер увімкнено на датацентрі, але вимкнено на вузлі, або правила застосовані не до того інтерфейсу, або upstream брандмауер/NAT обходить очікування.

Виправлення: Перевірте опції datacenter і node через pvesh. Підтвердіть ефективні правила через nft list ruleset. Виправте крайові ACL.

4) Симптом: Кластер стає нестабільним після «затягування» правил брандмауера

Корінь проблеми: Блокування corosync/knet трафіку між вузлами або змішування мереж управління і кластера з асиметричними правилами.

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

5) Симптом: Після оновлень ВМ мігрують, але продуктивність падає

Корінь проблеми: Несумісність ядра/драйверів, зміни налаштувань NIC offload, або вплив на шлях сховища; також можливо, що один вузол став «іншим».

Виправлення: Уніфікуйте версії по вузлах. Перевірте dmesg, версії драйверів NIC і стан сховища. Впроваджуйте зміни поступово наступного разу.

6) Симптом: SSH-доступ втрачено після жорсткіших налаштувань

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

Виправлення: Завжди тримайте активну консоль root (iLO/IPMI/KVM) перед зміною SSH. Впроваджуйте allowlist-и обережно і тестуйте з другої сесії.

7) Симптом: Бекапи виконуються, але відновлення не працює під час інциденту

Корінь проблеми: Відновлення не тестували; права/шляхи до сховища бекапів змінилися; ключі шифрування недоступні; або RBAC блокує ціль відновлення.

Виправлення: Тестуйте відновлення щокварталу (хоча б). Зберігайте ключі в контрольованій системі. Надайте операторам бекапів права відновлювати в quarantine-середовище.

Три корпоративні міні-історії з практики

Історія 1: Інцидент через неправильне припущення

Середньої величини компанія тримала три-вузловий Proxmox кластер для внутрішніх сервісів: CI-ранери, кілька баз даних і «тимчасовий» jump box,
який став постійним, бо все тимчасове стає постійним. На краю стояв next-gen брандмауер і команда вірила, що UI «не відкритий». Ніхто не міг вказати правило, але всі мали переконання.

Аудит почався після того, як вендор попросив IP allowlist. Команда безпеки швидко просканувала зовні і знайшла порт 8006 відкритим.
Не «фільтрований». Відкритий. На краю був NAT для зручності під час міграції місяці тому, який ніхто не прибрав.
UI був доступний лише з паролем для кількох застарілих обліковок.

Події не були драматичними. Бот торкнувся UI, підбирав стандартні імена, знайшов обліковку з застарілим шаблоном пароля і зайшов.
Всередині не потребував експлойтів ядра. Використав UI як адмін: скачав бекапи ВМ, змонтував диски і створив нового привілейованого користувача.
«Компрометація гіпервізора» фактично була компрометацією plane управління.

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

Історія 2: Оптимізація, що обернулася проти

Інша організація хотіла «менше тертя» для операторів. Вони помістили UI Proxmox за внутрішнім реверс-проксі,
а потім відкрили проксі для ширшої корпоративної мережі, щоб on-call могли дістатися звідусіль по VPN. Також додали схожий на SSO потік для зручності. Працювало. Поки не перестало.

Проксі стало єдиною точкою відмови і компрометації. Під час рутинного апгрейду проксі TLS змінився і деякі клієнти почали падати.
Оператори, під тиском, почали обходити проксі і прямо відкривати 8006 «тихо на ніч».
Тимчасовий стан затягнувся і в логах з’явився постійний потік спроб автентифікації з мереж, що ніколи не мали торкатися управління.

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

Виправлення — спростити: доступ до UI лише через виділений адмін VPN сегмент; нічого широкого корпоративного доступу. Проксі лишили для кількох робочих потоків, але прибрали його як «функцію безпеки».
Урок простий: шари зручності — це системи, і системи потребують власників.

Історія 3: Нудна, але правильна практика, що врятувала ситуацію

Невелика команда, що тримала Proxmox для SaaS-продукту, мала одну звичку, яка виглядала майже застарілою: щотижневе вікно обслуговування з письмовим runbook-ом.
Щосереди вони патчували один вузол, мігрували навантаження, перезавантажували при потребі, потім переходили до наступного вузла. Вони записували зміни і спостереження.
Це не було гламурно. Це було надійно.

Одного тижня після оновлень pvecm status показав періодичні попередження кворуму під час міграцій. Оскільки вони завжди перевіряли стан кластера після кожного вузла, вони виявили проблему раніше.
Причина — фліпання порту на комутаторі в кластерній мережі — не пов’язане з патчем, але виявлене рутиною.

Вони призупинили rollout, виправили фізичну проблему і продовжили. Без впливу на клієнтів. Інженер на чергуванні навіть поспав.
Перемога в безпеці — не тільки «вони пропатчили». Їх процес робив аномалії очевидними до того, як вони стали інцидентом.

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

Питання та відповіді (FAQ)

1) Чи можу я коли-небудь відкрити Proxmox порт 8006 в Інтернеті, якщо в мене є 2FA?

Ні. 2FA знижує ризик захоплення обліковки; він не зменшує ризик експозиції сервісу. Тримайте 8006 в адмінмережі або за VPN/бастіоном.

2) Чи достатньо RBAC Proxmox, чи все ще потрібні Linux-користувачі й контролі?

Потрібні обидва. RBAC керує діями в Proxmox API/UI. Linux-користувачі/SSH керують доступом до хосту. Розглядайте shell-доступ як вищий привілей, ніж доступ лише до UI.

3) Яка мінімально життєздатна «безпечна віддалена» конфігурація?

VPN у адмін-підмережу, з правилами брандмауера, що дозволяють 22 і 8006 лише з цієї мережі, плюс 2FA для UI і SSH-ключі для shell.

4) Як обробляти break-glass доступ, коли 2FA обов’язкова?

Створіть виділену break-glass обліковку з сильними контролями: збережені офлайн облікові дані, обмеження по IP, моніторинг використання і задокументована процедура.
Використовуйте лише для відновлення доступу, потім обертайте.

5) Чи безпечніші API-токени за паролі?

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

6) Чи потрібен fail2ban на Proxmox?

Якщо ваша management plane правильно ізольована — fail2ban опціональний. Якщо підозрюєте експозицію, fail2ban зменшить шум, але не замінить фікс експозиції.

7) Яку політику брандмауера обрати: DROP чи REJECT?

Для інтерфейсів управління віддавайте перевагу DROP, щоб зменшити сигнал. Для внутрішньої зручності REJECT може допомогти. Виберіть усвідомлено і документуйте.

8) Як часто патчити вузли Proxmox?

Щотижня або раз на два тижні — нормальний ритм для більшості середовищ, з можливістю пришвидшення при термінових advisories. Головне — послідовність і стадіїрування.

9) Якщо я ізолюю управління на VLAN, чи потрібен брандмауер Proxmox?

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

10) Який найбільший «мовчазний» ризик у безпеці Proxmox?

Надто широкі права, що залишаються. Більшість організацій не зламують генії; їх підриває учорашня зручність.

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

1. Доведіть, що management не експонований: з неадмінської мережі підтвердіть, що 8006 і 22 недоступні. Якщо доступні — виправте крайові правила негайно.
2. Увімкніть 2FA для кожної людини. Спершу виправте NTP. Створіть задокументований процес break-glass.
3. RBAC-спринт очищення: перелікуйте ACL, приберіть PVEAdmin з /, крім дуже малої адмініт групи, і скопуйте все інше по шляхах.
4. Перевірте ефективність брандмауера: перевірте конфігурацію через pvesh і реальність через nft list ruleset.
5. Патчі з стадіруванням: змоделюйте оновлення, оновіть один вузол, перевірте кворум і ключові робочі процеси, потім розгорніть далі.
6. Жорсткість SSH обережно: лише ключі, без root, обмежені джерела; зберігайте консольний доступ під час змін.
7. Напишіть два runbook-и: «втрата 2FA-пристрою» і «скомпрометований адмін-акаунт». Інциденти не чекають документації.

Мета не в тому, щоб побудувати неприступну фортецю. Мета — зробити доступ до управління Proxmox навмисно рідкісним, права — навмисно вузькими,
а зміни — навмисно рутинними. Решта — просто Linux.