Po ataku ransomware zespół odtwarza serwer: czysta instalacja systemu, przywrócenie danych z kopii, nowe hasła. Dwa tygodnie później na tym samym serwerze znów pojawia się podejrzany ruch. System jest świeży, EDR milczy, a jednak coś przetrwało. Jeśli atakujący miał wcześniej dostęp do interfejsu zarządzania serwerem albo zmienił firmware, reinstalacja systemu nie usunęła niczego, co miało znaczenie.
Zabezpieczenia systemu operacyjnego zakładają, że warstwa pod nim jest zaufana. W tym tekście sprawdzamy to założenie: czym jest kontroler BMC, jak atakujący wykorzystują interfejsy zarządzania, co daje sprzętowy root of trust i o co pytać przy zakupie serwera x86. Jako przykład konkretnej implementacji służą serwery Lenovo ThinkSystem, ale pytania dotyczą każdego producenta.
Dlaczego atak na firmware serwera jest groźniejszy niż infekcja systemu?
Bo działa poniżej wszystkiego, co zwykle chroni serwer. Zmiana w UEFI, firmware kontrolera zarządzania czy układów płyty głównej przetrwa reinstalację systemu i wymianę dysków. Narzędzia działające w systemie operacyjnym, takie jak EDR czy antywirus, jej nie widzą, bo same uruchamiają się później.
NIST w publikacji SP 800-193 „Platform Firmware Resiliency Guidelines” (maj 2018) opisuje platformę jako zestaw podstawowych komponentów sprzętowych i firmware potrzebnych do uruchomienia i działania systemu. Publikacja zaznacza, że udany atak na firmware platformy może unieruchomić system, być może trwale, albo wymagać jego ponownego zaprogramowania przez producenta.
Złośliwe oprogramowanie ukrywające się na tym poziomie nazywa się bootkitem albo rootkitem firmware — pojęcia wyjaśniamy w słowniku pod hasłem rootkit. Dla obrony oznacza to jedno: kontrola musi zaczynać się w sprzęcie, a nie w systemie, który ma być chroniony.
Czym jest BMC i dlaczego to osobny komputer w twoim serwerze?
Baseboard management controller to osobny procesor na płycie głównej, z własnym systemem, własnym interfejsem sieciowym i własnymi kontami. Działa, gdy serwer jest podłączony do zasilania — także wtedy, gdy system operacyjny jest wyłączony. Służy do zdalnej administracji: włączania i wyłączania, podglądu konsoli, podłączania obrazów nośników, monitorowania sprzętu i aktualizacji firmware.
Każdy producent ma własną implementację. Lenovo nazywa ją XClarity Controller, HPE — iLO, Dell — iDRAC. Według przewodnika Lenovo Press dla serwera SR650 V4 kontroler XClarity Controller 3 opiera się na układzie BMC ASPEED AST2600 i obsługuje OpenBMC. Udostępnia standardowe protokoły zarządzania: IPMI 2.0, SNMPv3 i Redfish REST API.
Z punktu widzenia bezpieczeństwa BMC ma uprawnienia większe niż administrator systemu. Kto przejmie kontroler, może zrestartować serwer z własnego obrazu, podglądać konsolę i zmieniać firmware. Kopie zapasowe, szyfrowanie dysków i hasła systemowe tracą wtedy znaczenie, bo atakujący działa pod nimi.
BMC w trzech zdaniach: to drugi komputer w serwerze, z własną siecią i kontami. Działa, gdy system jest wyłączony. Kto go kontroluje, kontroluje serwer — niezależnie od tego, co jest zainstalowane na dyskach.
Jak atakujący wykorzystują interfejsy zarządzania serwerem?
Najczęściej najprostszą drogą: przez dostęp sieciowy do kontrolera, który nie powinien być osiągalny. Interfejs BMC wpięty do płaskiej sieci biurowej albo, co gorsza, dostępny z internetu, staje się celem skanowania. Domyślne lub słabe hasła i nieaktualne firmware kontrolera robią resztę.
Drugą drogą są podatności samego oprogramowania BMC. Przykład z katalogu CISA Known Exploited Vulnerabilities to CVE-2024-54085. Podatność w firmware AMI MegaRAC SPx, stosowanym przez wielu producentów płyt serwerowych, pozwala zdalnie obejść uwierzytelnianie przez interfejs Redfish Host Interface. CISA dodała ją do katalogu podatności aktywnie wykorzystywanych 25 czerwca 2025 r.
To przykład klasy zagrożenia, nie konkretnego producenta z tego tekstu. Czy dana podatność dotyczy twoich serwerów, rozstrzyga wyłącznie komunikat bezpieczeństwa ich producenta. Wniosek ogólny jest jednak prosty: firmware BMC wymaga łatania tak samo jak system, a jego podatności trafiają do katalogów aktywnie wykorzystywanych.
Przykład z KEV: CVE-2024-54085 dotyczy AMI MegaRAC SPx, nie Lenovo XClarity Controller. Pokazuje, że podatności BMC są aktywnie wykorzystywane — i że o tym, których serwerów dotyczą, decyduje komunikat producenta.
Co oznacza sprzętowy root of trust i zgodność z NIST SP 800-193?
To niezależny element sprzętowy, któremu ufa się bezwarunkowo i który sprawdza wszystko, co uruchamia się później. NIST SP 800-193 opiera odporność firmware na trzech zasadach: ochronie przed nieautoryzowaną zmianą, wykrywaniu zmiany, która już nastąpiła, i odtwarzaniu do znanego, poprawnego stanu. Każda z nich wymaga elementu, którego nie da się zmienić z poziomu oprogramowania.
W serwerach Lenovo ThinkSystem tę rolę pełni moduł Root of Trust z funkcją Platform Firmware Resiliency, opisywany jako część Lenovo ThinkShield. Według przewodnika Lenovo Press dla SR650 V4 moduł obejmuje trzy obrazy: UEFI, firmware kontrolera XCC oraz kod układu FPGA sterującego płytą główną. Dla każdego z nich realizuje wykrywanie, czyli weryfikację autentyczności firmware i aktualizacji, oraz odtwarzanie uszkodzonego obrazu do znanego, bezpiecznego stanu.
Trzecią funkcją jest ochrona, czyli pilnowanie, by poprawne firmware nie zostało złośliwie nadpisane. Lenovo podaje, że funkcje realizuje osobny procesor bezpieczeństwa i że dzięki modułowi serwer spełnia NIST SP 800-193. SR650 V4 jest też według producenta zgodny z NIST SP 800-147B, wytycznymi ochrony BIOS w serwerach.
Deklaracja zgodności jest punktem wyjścia, a nie końcem weryfikacji. Warto zapytać, które komponenty obejmuje ochrona, bo karty sieciowe, kontrolery RAID i dyski mają własne firmware.
Czym różnią się Secure Boot, TPM 2.0 i weryfikacja firmware?
Chronią trzy różne warstwy i żadna nie zastępuje pozostałych. Secure Boot to funkcja UEFI, która pozwala uruchomić tylko podpisane oprogramowanie ładujące system. Lenovo zaznacza, że Secure Boot pomaga zapobiegać ładowaniu złośliwego kodu i atakom takim jak instalacja rootkitów, a w serwerach V4 można go włączyć już w fabryce.
Secure Boot jest jednak częścią firmware UEFI. Jeżeli samo firmware zostanie zmodyfikowane, przestaje być wiarygodnym strażnikiem. Tu wchodzi root of trust, który sprawdza firmware, zanim ono sprawdzi cokolwiek innego.
TPM 2.0 to sprzętowy moduł kryptograficzny. Przechowuje klucze, na przykład do szyfrowania dysków, i zapisuje pomiary kolejnych etapów uruchamiania. Lenovo wskazuje, że zintegrowany TPM 2.0 umożliwia podpisy cyfrowe i zdalne poświadczanie stanu (remote attestation). Dzięki temu zewnętrzny system może sprawdzić, czy serwer uruchomił się w oczekiwanej konfiguracji.
Razem tworzą łańcuch: root of trust weryfikuje firmware, firmware z Secure Boot weryfikuje program ładujący, a TPM zapisuje, co się uruchomiło, i chroni klucze. Brak któregokolwiek ogniwa zostawia lukę w miejscu, którego nie obejmują pozostałe.
Jak wygląda to w praktyce na przykładzie Lenovo ThinkSystem?
Jako zestaw funkcji, z których część jest w standardzie, a część wymaga rozszerzonej licencji kontrolera. W najnowszej generacji Lenovo ThinkSystem V4, na przykład w SR650 V4 (2U, procesory Intel Xeon 6), standardem są XClarity Controller 3, moduł Root of Trust z PFR, TPM 2.0 i Secure Boot. Dostępny jest też czujnik otwarcia obudowy.
Licencja XCC3 Premier dodaje funkcje istotne dla bezpieczeństwa. System Guard monitoruje inwentarz sprzętu pod kątem nieoczekiwanych zmian komponentów i może zarejestrować zdarzenie albo zablokować uruchomienie. Przy zamówieniach konfigurowanych na zamówienie Lenovo może włączyć go w fabryce i zapisać pierwszy stan konfiguracji. Premier dodaje też tryb zgodny z CNSA, tryb zgodny z FIPS 140-3 i rozszerzone wsparcie NIST SP 800-193.
Lenovo opisuje także zabezpieczenia łańcucha dostaw. Dostawców weryfikuje program Trusted Supplier Program, a firmware jest podpisywane cyfrowo w sprzętowych modułach bezpieczeństwa (HSM). Dodatkowo dostępna jest usługa Intel Transparent Supply Chain, dokumentująca pochodzenie komponentów.
Jedna uwaga dla flot mieszanych. W serwerach generacji V3 z procesorami AMD, na przykład SR665 V3, kontrolerem jest poprzednia wersja, XCC2, z innym zestawem licencji. Procedury, uprawnienia i harmonogram aktualizacji trzeba więc prowadzić per generacja, a nie dla „serwerów Lenovo” jako całości.
Gdzie powinien wisieć port zarządzania i kto powinien mieć do niego dostęp?
W wydzielonej sieci zarządzania, do której dostęp mają tylko wskazane stacje administracyjne. Serwery Lenovo V4 mają dedykowany port Ethernet do zarządzania kontrolerem, a opcjonalnie drugi, instalowany w gnieździe karty OCP. Ten port powinien trafić do osobnej sieci lub VLAN-u bez routingu z sieci użytkowników i bez dostępu z internetu.
Przewodnik Lenovo Press dla SR650 V4 opisuje też drugą możliwość: jeden port każdej zainstalowanej karty OCP można współdzielić z kontrolerem XCC. To wygodne, bo oszczędza okablowanie. Oznacza jednak, że ruch kontrolera płynie tą samą fizyczną drogą co ruch produkcyjny. Taka konfiguracja wymaga świadomej decyzji i starannej separacji logicznej, a nie przypadkowego włączenia.
Dostęp do sieci zarządzania warto prowadzić przez serwer pośredniczący z uwierzytelnianiem wieloskładnikowym. Konta kontrolera powinny być imienne, a nieużywane protokoły zarządzania — wyłączone. Logi z kontrolerów trzeba przesyłać do centralnego systemu, bo logowanie do BMC o trzeciej w nocy jest zdarzeniem bezpieczeństwa, a nie administracyjnym.
Jak aktualizować firmware floty serwerów, nie tracąc kontroli nad zmianami?
Traktując firmware jako osobny strumień poprawek, z własną inwentaryzacją i harmonogramem. W serwerze jest kilka warstw firmware: kontroler BMC, UEFI, karty sieciowe, kontrolery pamięci masowej i dyski. Każda ma własne wersje i własne komunikaty bezpieczeństwa, a łatki systemowe żadnej z nich nie obejmują.
Pierwszy krok to inwentaryzacja wersji w całej flocie. Drugi — śledzenie komunikatów bezpieczeństwa producenta i katalogu CISA KEV pod kątem posiadanych modeli. Trzeci to testowanie aktualizacji na serwerze nieprodukcyjnym przed wdrożeniem, bo aktualizacja firmware bywa nieodwracalna w prosty sposób.
Lenovo zapewnia narzędzia do aktualizacji firmware i platformę XClarity One do centralnego zarządzania flotą. Root of trust dodaje tu ważną właściwość: aktualizacja jest weryfikowana przed zapisem, więc podmieniony pakiet nie powinien trafić do pamięci. Proces opisujemy szerzej w tekście o zarządzaniu poprawkami, a pozostałe materiały — w bazie wiedzy o zarządzaniu podatnościami.
Czy bezpieczeństwo firmware ma związek z NIS2 i łańcuchem dostaw?
Tak, i to w dwóch miejscach dyrektywy. Art. 21 ust. 2 lit. d NIS2 wymaga bezpieczeństwa łańcucha dostaw, w tym relacji z bezpośrednimi dostawcami. Producent serwera i jego podwykonawcy dostarczają firmware, które działa z najwyższymi uprawnieniami w twojej infrastrukturze. Jego pochodzenie i sposób podpisywania są więc częścią oceny dostawcy.
Art. 21 ust. 2 lit. e wymaga bezpieczeństwa w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych, w tym postępowania z podatnościami. Zakup serwera jest nabyciem, a aktualizacja firmware — utrzymaniem. Pytania o root of trust, podpisywanie firmware i cykl poprawek BMC mają więc miejsce już w zapytaniu ofertowym.
W polskich realiach ocenę dostawców opisujemy w tekście o dostawcach wysokiego ryzyka w ustawie o KSC, a pojęcie łańcucha dostaw IT wyjaśniamy w słowniku.
Jak ocenić bezpieczeństwo firmware w ofercie serwerowej?
Zamieniając każde wymaganie na pytanie do dostawcy i sposób, w jaki da się je zweryfikować. Poniższa tabela porządkuje te pytania od warstwy najniższej do procesowej.
| Wymaganie | Pytanie do dostawcy | Jak zweryfikować |
|---|---|---|
| Sprzętowy root of trust | Które obrazy firmware chroni i czy potrafi odtworzyć poprawny obraz? | przewodnik produktu, opis komponentów objętych ochroną |
| Zgodność z NIST SP 800-193 | Czy deklaracja obejmuje wszystkie trzy funkcje: ochronę, wykrywanie, odtwarzanie? | dokumentacja producenta, wymagana licencja kontrolera |
| Podpisywanie firmware | Gdzie i czym podpisywane są aktualizacje? | opis procesu podpisu, np. w modułach HSM |
| Secure Boot i TPM 2.0 | Czy są dostępne i czy można je włączyć fabrycznie? | konfiguracja przy odbiorze serwera |
| Kontrola zmian sprzętu | Czy kontroler wykrywa zmianę komponentów i może zablokować start? | test: wymiana komponentu na serwerze testowym |
| Separacja zarządzania | Czy jest dedykowany port BMC i jak działa port współdzielony? | projekt sieci zarządzania przed wdrożeniem |
| Protokoły i konta | Które protokoły można wyłączyć i czy konta mogą być imienne? | przegląd konfiguracji kontrolera |
| Cykl poprawek | Gdzie publikowane są komunikaty bezpieczeństwa BMC i UEFI? | subskrypcja komunikatów, porównanie z CISA KEV |
| Łańcuch dostaw | Jak producent weryfikuje dostawców komponentów? | opis programu weryfikacji dostawców |
Kolejność ma znaczenie. Pierwsze wiersze decydują o tym, czy firmware da się zaufać. Ostatnie decydują o tym, czy to zaufanie przetrwa kilka lat eksploatacji.
Od czego zacząć w istniejącej serwerowni?
Od znalezienia wszystkich kontrolerów BMC i sprawdzenia, skąd są osiągalne. W wielu serwerowniach część interfejsów zarządzania trafiła do sieci użytkowników przy instalacji i nikt ich nie przeniósł. Skanowanie sieci pod kątem interfejsów zarządzania i porównanie wyniku z listą serwerów zwykle przynosi niespodzianki.
Drugi krok to przegląd kont i wersji: domyślne hasła, konta wspólne, wersje firmware BMC i UEFI zestawione z komunikatami producenta. Trzeci — włączenie Secure Boot tam, gdzie system operacyjny i sterowniki na to pozwalają, oraz rejestrowania otwarcia obudowy. Czwarty to przesyłanie logów kontrolerów do systemu monitoringu.
Piąty krok to test. Konfigurację serwerów i sieci zarządzania weryfikujemy w ramach przeglądu konfiguracji systemów i infrastruktury, a odporność samego firmware i interfejsów BMC — w testach penetracyjnych oprogramowania wbudowanego. Przy nowych zakupach dobieramy konfigurację z funkcjami bezpieczeństwa w ramach wdrożeń infrastruktury serwerowej. Podstawy budowy serwerowni opisujemy w tekście o serwerach rackowych.
Checklista: 7 pytań do dostawcy serwerów: które firmware chroni root of trust; czy odtwarza poprawny obraz; jak podpisywane są aktualizacje; czy Secure Boot i TPM można włączyć fabrycznie; czy kontroler wykrywa zmianę komponentów; jak odseparować port BMC; gdzie publikowane są komunikaty bezpieczeństwa.
Źródła przywołane w tekście: NIST SP 800-193 „Platform Firmware Resiliency Guidelines” (maj 2018); NIST SP 800-147B „BIOS Protection Guidelines for Servers”; NVD, CVE-2024-54085, i katalog CISA Known Exploited Vulnerabilities (wpis z 25 czerwca 2025); Lenovo Press, przewodniki produktów ThinkSystem SR650 V4, SR630 V4, SR665 V3 i SR850 V4 oraz Lenovo Servers and Storage Portfolio Guide (stan na wrzesień 2026); dyrektywa (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. d i e.
Najczęściej zadawane pytania
Czym jest BMC w serwerze?
Baseboard management controller to osobny procesor na płycie głównej serwera, z własnym oprogramowaniem, interfejsem sieciowym i kontami. Pozwala zdalnie włączać i wyłączać serwer, podłączać obrazy nośników, przejmować konsolę i aktualizować firmware — także wtedy, gdy system operacyjny nie działa. W serwerach Lenovo ThinkSystem V4 tę rolę pełni XClarity Controller 3.
Dlaczego atak na firmware jest groźniejszy niż infekcja systemu?
Bo działa poniżej systemu operacyjnego. Zmiana w UEFI lub firmware kontrolera przetrwa reinstalację systemu i jest poza zasięgiem narzędzi działających w systemie, takich jak EDR. NIST w publikacji SP 800-193 (maj 2018) zaznacza, że udany atak na firmware platformy może trwale unieruchomić system albo wymagać jego ponownego zaprogramowania przez producenta.
Czym jest sprzętowy root of trust?
To niezależny element sprzętowy, który weryfikuje autentyczność firmware przed jego uruchomieniem i przy aktualizacji, chroni go przed nieautoryzowanym zapisem i potrafi przywrócić znany, poprawny obraz. NIST opisuje te trzy funkcje — ochronę, wykrywanie i odtwarzanie — w wytycznych SP 800-193 Platform Firmware Resiliency.
Czy Secure Boot wystarczy do ochrony firmware?
Nie. Secure Boot pilnuje, by uruchamiał się tylko podpisany program ładujący system, ale sam jest częścią firmware UEFI. Jeżeli firmware zostanie zmodyfikowane, Secure Boot nie jest już wiarygodnym punktem kontroli. Ochronę samego firmware zapewnia sprzętowy root of trust, a TPM 2.0 przechowuje klucze i pomiary.
Czy port zarządzania serwera może być w sieci produkcyjnej?
Może, ale nie powinien. Interfejs BMC daje pełną kontrolę nad serwerem, więc powinien działać w wydzielonej sieci zarządzania, dostępnej przez wskazane stacje z silnym uwierzytelnianiem. Część serwerów, np. Lenovo SR650 V4, pozwala współdzielić port karty sieciowej z kontrolerem — to wygoda, która wymaga świadomej decyzji.
