Checklista bezpieczeństwa klastra Proxmox

Najczęstsze znaleziska z naszych audytów to nie wyrafinowane luki zero-day, tylko zaniedbane podstawy: wspólne konto root, na które loguje się cały zespół, interfejs GUI dostępny z sieci biurowej bez 2FA, backup, którego nikt nigdy nie próbował przywrócić. Klaster Proxmox potrafi działać z takimi zaniedbaniami latami, aż do dnia, w którym przestaje. Wtedy okazuje się, że nie wiadomo, kto co zmienił, a jedyna kopia zapasowa leży na tym samym storage co produkcja.

Ta checklista zbiera punkty, które sprawdzamy podczas audytu klastra Proxmox. Nie jest to lista życzeń: każdy punkt wynika z realnego incydentu albo problemu, który widzieliśmy u klientów lub na własnym klastrze produkcyjnym, na którym działa hosting IQHost. Przejdźcie ją z zespołem, odhaczcie to, co macie, a resztę potraktujcie jako plan pracy na najbliższe tygodnie.

Dostęp i tożsamość

• 2FA dla wszystkich kont GUI. Proxmox wspiera TOTP i klucze WebAuthn od dawna. Interfejs webowy to pełna kontrola nad wszystkimi maszynami, więc samo hasło to za mało, nawet jeśli GUI jest dostępne tylko z sieci wewnętrznej.
• Brak logowania root hasłem po SSH. W sshd_config ustawcie logowanie tylko kluczem, a do roota przechodźcie przez su lub sudo z konta imiennego. Hasło roota zostaje jako awaryjny dostęp przez konsolę, nie jako codzienna droga na serwer.
• Osobne konta imienne i RBAC zamiast wspólnego roota. Proxmox ma wbudowany model ról i uprawnień na poziomie datacenter, puli, a nawet pojedynczej VM. Administrator sieci nie musi mieć prawa kasowania backupów, a helpdesk restartujący maszyny nie potrzebuje dostępu do konfiguracji klastra.
• Integracja z AD/LDAP tam, gdzie jest. Jeśli firma ma katalog użytkowników, podepnijcie go jako realm w Proxmoksie. Odejście pracownika załatwia wtedy jedna blokada konta w AD, a nie ręczne przeszukiwanie wszystkich systemów.
• Przegląd uprawnień co kwartał. Konta byłych pracowników, uprawnienia nadane "na chwilę" do projektu, tokeny API bez daty ważności. To wszystko rośnie samo. Kwartalny przegląd z krótką notatką zajmuje godzinę i wyłapuje większość takich pozostałości.
• Sekrety poza wiki, w managerze haseł. Hasła do IPMI, klucze API do backupów i dane dostępowe do przełączników nie mogą leżeć w Confluence ani w pliku tekstowym na dysku sieciowym. Manager haseł z kontrolą dostępu i historią zmian to minimum.

Sieć

• Management w osobnym VLAN. Interfejs GUI (port 8006) i SSH węzłów nie mogą być osiągalne z sieci użytkowników. Osobny VLAN zarządzania z dostępem tylko dla stacji administratorów to pierwsza rzecz, którą sprawdzamy w audycie sieci.
• Firewall Proxmox włączony na poziomie datacenter i node. Proxmox ma wbudowany firewall z regułami na trzech poziomach: datacenter, węzeł, VM. W wielu klastrach, które audytujemy, jest wyłączony, bo "kiedyś coś blokował". Włączcie go świadomie, z regułami dopasowanymi do waszej sieci.
• Osobna sieć corosync. Corosync jest wrażliwy na opóźnienia: gdy dzieli łącze z ruchem backupu albo migracji, klaster potrafi stracić kworum w środku okna backupowego. Dedykowana sieć, najlepiej z redundantnym drugim ringiem, to standard, nie luksus.
• Osobna sieć storage i replikacji. Ruch Ceph, ZFS replication czy NFS nie powinien konkurować ani z corosync, ani z ruchem VM. Poza wydajnością to też kwestia bezpieczeństwa: storage w osobnej sieci jest niedostępny dla maszyn gości.
• Dostęp administracyjny przez VPN, nie wystawiony na świat. Port 8006 dostępny z publicznego internetu to zaproszenie do skanów i prób logowania. Dostęp zdalny prowadźcie przez VPN (WireGuard, OpenVPN, IPsec na pfSense/OPNsense), z osobnymi tożsamościami dla każdego administratora.
• Certyfikaty zamiast self-signed tam, gdzie się da. Zaufany certyfikat na GUI (ACME/Let's Encrypt jest wbudowany w Proxmoksa) kończy erę klikania "akceptuję ryzyko" w przeglądarce. To ważne nie dla estetyki, tylko dlatego, że zespół przyzwyczajony do ignorowania ostrzeżeń nie zauważy prawdziwego ataku man-in-the-middle.

System i aktualizacje

• Regularne aktualizacje z ustalonym oknem. Klaster, który nie był aktualizowany od dwóch lat, to nie stabilność, to dług. W klastrze HA aktualizacje robi się bez przestoju: live migration maszyn z węzła, aktualizacja, powrót. Ustalcie stałe okno serwisowe i trzymajcie się go.
• Enterprise repo albo świadoma decyzja o no-subscription. Subskrypcja Proxmox nie jest licencją, system działa w pełni bez niej. Daje jednak dostęp do enterprise repo z pakietami przetestowanymi dłużej. Dla produkcji rekomendujemy enterprise repo; jeśli zostajecie na no-subscription, niech to będzie decyzja zapisana w dokumentacji, a nie przypadek. Szczegóły opisaliśmy w artykule o subskrypcjach Proxmox.
• Monitoring CVE dla usług wystawionych na zewnątrz. Jeśli cokolwiek z klastra jest osiągalne z internetu (VPN, reverse proxy, panel), ktoś w zespole musi śledzić podatności tych usług. Wystarczy subskrypcja list bezpieczeństwa i procedura: kto ocenia, kto łata, w jakim czasie.
• Minimalizacja pakietów na hoście. Host PVE to hipernadzorca, nie serwer aplikacyjny. Każdy dodatkowy pakiet to dodatkowa powierzchnia ataku i potencjalny konflikt przy aktualizacji. Narzędzia, agenty monitoringu i skrypty trzymajcie w VM lub kontenerach LXC.
• Żadnych kontenerów Docker bezpośrednio na hoście PVE. Docker zainstalowany obok Proxmoksa modyfikuje iptables i potrafi wystawić usługi na świat z pominięciem firewalla hosta. Widzieliśmy skutki takiej konfiguracji na produkcji: opisaliśmy je w case study incydentu z Dockerem i iptables. Docker uruchamiajcie w dedykowanej VM.

Backup i disaster recovery

• Backup szyfrowany. Proxmox Backup Server szyfruje dane po stronie klienta, zanim opuszczą hosta. Klucz przechowujcie poza serwerem backupu, w managerze haseł. Backup bez szyfrowania to kopia wszystkich waszych danych czekająca na wyciek.
• Kopia offsite. Backup na tym samym storage co produkcja albo w tej samej serwerowni chroni przed skasowaniem VM, ale nie przed pożarem, zalaniem ani ransomware, które dosięga wszystkiego w sieci. Zasadę 3-2-1 z PBS opisaliśmy osobno w artykule o backupie 3-2-1 z Proxmox Backup Server.
• Verify jobs włączone. PBS potrafi cyklicznie weryfikować integralność snapshotów. Bez tego cicha korupcja danych na storage backupowym wychodzi na jaw dopiero przy próbie przywracania, czyli w najgorszym możliwym momencie.
• Restore testowany co miesiąc. Backup, którego nie przywracaliście, to hipoteza, nie zabezpieczenie. Comiesięczny test: przywrócenie wybranej VM do izolowanej sieci, uruchomienie, sprawdzenie aplikacji, notatka z czasem trwania. Jak to zorganizować, opisujemy w artykule o testach restore i disaster recovery.
• Runbook DR istnieje i ktoś go czytał. Dokument, który opisuje krok po kroku, co robić po awarii węzła, storage albo całej serwerowni: kolejność przywracania, adresy, hasła awaryjne (a raczej gdzie ich szukać), osoby i telefony. Runbook, którego nikt poza autorem nie otwierał, w praktyce nie istnieje.

Monitoring

• Alerty na padnięcie węzła, dysku i backupu. Minimum: powiadomienie, gdy węzeł znika z klastra, gdy SMART lub ZFS zgłaszają problem z dyskiem i gdy zadanie backupu kończy się błędem. Nieudany backup, o którym nikt nie wie przez trzy tygodnie, to klasyka naszych audytów.
• Logi zbierane centralnie. Syslog z węzłów wysyłany na osobny serwer (lub do SIEM, u nas Wazuh) ma dwie zalety: korelację zdarzeń z wielu maszyn i to, że atakujący po przejęciu hosta nie może wyczyścić śladów.
• Audit log włączony. Kto, kiedy i co zmienił w klastrze: utworzenie VM, zmiana uprawnień, skasowanie backupu. Bez tego analiza incydentu kończy się na zgadywaniu, a rozliczalność w zespole nie istnieje.
• Testowy alarm raz na kwartał. Monitoring, który nigdy nie zadzwonił, mógł po cichu przestać działać: wygasły token do powiadomień, zmieniony adres e-mail, pełna skrzynka. Raz na kwartał wywołajcie alert kontrolowanie i sprawdźcie, czy dotarł do właściwych osób.

Co dalej z wynikami

Jeśli po przejściu listy macie kilka braków, potraktujcie je jako backlog i zamykajcie po kolei, zaczynając od dostępu i backupu. Jeśli braków jest kilkanaście albo nie macie pewności, jak niektóre punkty sprawdzić (osobna sieć corosync, verify jobs, audit log), sensownym pierwszym krokiem jest zewnętrzny przegląd. W ramach Proxmox Health Check przechodzimy tę listę i sporo głębszych punktów na waszym klastrze, a raport z rekomendacjami dostajecie w 2-3 dni. Bieżące pilnowanie tych punktów można też oddać nam w ramach administracji i utrzymania.

Częste pytania