Linux Hardening Secure Boot bez marketingu – odpowiedzi na pytania, które naprawdę zadają administratorzy
Linux Hardening: Secure Boot bez marketingu – odpowiedzi na pytania, które naprawdę zadają administratorzy
Secure Boot od lat budzi skrajne emocje. Dla jednych jest niezbędnym elementem bezpieczeństwa nowoczesnych komputerów, dla innych przeszkodą utrudniającą instalację Linuksa lub własnych sterowników. Prawda – jak zwykle – leży gdzieś pośrodku. Sam mechanizm jest prosty w założeniach: komputer powinien uruchamiać wyłącznie zaufany kod jeszcze zanim wystartuje system operacyjny. W praktyce jednak wokół Secure Boot narosło tyle mitów, że nawet doświadczeni administratorzy często nie są pewni, co faktycznie chroni, a czego nie.
Poniżej zebrałem pytania, które najczęściej pojawiają się podczas wdrażania Linuksa na nowych komputerach, serwerach i maszynach roboczych.
„Czy Secure Boot chroni Linuksa przed wirusami?”
Nie.
To prawdopodobnie największe nieporozumienie.
Secure Boot nie analizuje plików, nie skanuje procesów ani nie wykrywa złośliwego oprogramowania działającego po uruchomieniu systemu. Jego zadanie kończy się znacznie wcześniej – na etapie weryfikacji komponentów rozruchowych.
Wyobraźmy sobie start komputera.
UEFI
│
▼
Secure Boot
│
▼
Bootloader
│
▼
Kernel
│
▼
Initramfs
│
▼
LinuxJeżeli któryś z podpisanych elementów zostanie podmieniony, komputer powinien przerwać proces uruchamiania.
Jeżeli natomiast użytkownik uruchomi zainfekowany program po zalogowaniu – Secure Boot nie ma już nic do powiedzenia.
„Dlaczego Linux uruchamia się z Secure Boot, skoro Microsoft podpisuje klucze?”
To bardzo dobre pytanie.
Wiele dystrybucji korzysta z niewielkiego programu o nazwie Shim.
Shim jest podpisany kluczem zaufanym przez większość firmware UEFI i pełni rolę pośrednika pomiędzy firmware a właściwym bootloaderem GRUB.
Schemat wygląda mniej więcej tak.
UEFI
│
▼
Shim
│
▼
GRUB
│
▼
LinuxDzięki temu Ubuntu, Fedora czy openSUSE mogą uruchamiać się na większości komputerów z włączonym Secure Boot bez ręcznej ingerencji użytkownika.
„Czy wyłączenie Secure Boot zawsze jest złym pomysłem?”
Nie zawsze.
To zależy od zastosowania.
Na komputerze testowym, gdzie często uruchamiasz własne jądra, sterowniki lub eksperymentalne moduły, wyłączenie Secure Boot może ułatwić pracę.
Na laptopie z danymi firmowymi sytuacja wygląda inaczej.
Tam dodatkowa weryfikacja kodu startowego ma realną wartość.
Najważniejsze jest świadome podjęcie decyzji, a nie wyłączanie funkcji „bo tak działa poradnik z Internetu”.
„Co właściwie sprawdza Secure Boot?”
Firmware nie analizuje całego dysku.
Sprawdza podpis cyfrowy komponentów uczestniczących w rozruchu.
Można to porównać do kontroli biletów.
Firmware
│
▼
Czy podpis jest zaufany?
│
┌──┴──┐
│ │
Tak Nie
│ │
▼ ▼
Start BlokadaTo właśnie dlatego modyfikacja bootloadera bez odpowiedniego podpisu kończy się komunikatem o błędzie.
„Czy rootkit może ominąć Secure Boot?”
To zależy od momentu ataku.
Jeżeli rootkit próbuje podmienić bootloader lub jądro przed uruchomieniem systemu, Secure Boot znacząco utrudnia taki scenariusz.
Jeżeli jednak napastnik uzyskał uprawnienia administratora już po uruchomieniu systemu, pojawiają się zupełnie inne możliwości ataku.
Dlatego Secure Boot należy traktować jako ochronę łańcucha rozruchowego, a nie całego systemu.
„Czy własne jądro Linuksa przestanie działać?”
Może.
Jeżeli skompilujesz własne jądro i nie podpiszesz go odpowiednim kluczem, firmware może odmówić jego uruchomienia.
Rozwiązaniem jest podpisanie własnego kernela i dodanie własnego klucza do zaufanej bazy.
To właśnie dlatego bardziej zaawansowani administratorzy często korzystają z mechanizmu Machine Owner Key (MOK).
„Co to jest MOK?”
MOK, czyli Machine Owner Key, pozwala właścicielowi komputera dodać własne zaufane klucze bez całkowitej rezygnacji z Secure Boot.
Proces wygląda następująco.
Administrator
│
▼
Generuje klucz
│
▼
MOK
│
▼
UEFI zapisuje zaufanie
│
▼
Podpisany moduł działaTo bardzo eleganckie rozwiązanie.
Nie trzeba wyłączać całego mechanizmu tylko dlatego, że potrzebujemy własnego sterownika.
„Dlaczego VirtualBox albo sterowniki NVIDIA czasem przestają działać?”
Najczęściej dlatego, że moduł jądra nie został poprawnie podpisany.
W praktyce scenariusz wygląda tak:
- Instalujesz sterownik.
- Sterownik dodaje moduł do kernela.
- Secure Boot odrzuca niepodpisany moduł.
- Urządzenie przestaje działać.
Wiele nowoczesnych instalatorów potrafi automatycznie podpisać moduły przy użyciu MOK, ale warto wiedzieć, dlaczego ten mechanizm w ogóle istnieje.
„Czy można sprawdzić, czy Secure Boot jest aktywny?”
Tak.
Najprościej użyć:
Bash
mokutil --sb-statePrzykładowy wynik:
SecureBoot enabledMożna również sprawdzić zmienne EFI:
Bash
efibootmgr -vTo dobre polecenie przy diagnostyce problemów z rozruchem.
„Czy Secure Boot ma sens na serwerze?”
Zdecydowanie częściej, niż się wydaje.
Serwer stojący w centrum danych również posiada fizyczny nośnik.
Atak na bootloader nie jest najbardziej prawdopodobnym scenariuszem, ale należy do grupy ataków, które trudno wykryć później.
Jeżeli ktoś zmodyfikuje kod uruchamiany przed jądrem, zwykłe narzędzia systemowe mogą już nie zobaczyć pełnego obrazu sytuacji.
Właśnie dlatego ochrona łańcucha rozruchowego ma sens również poza laptopami.
„Czy Secure Boot współpracuje z LUKS?”
Tak – i to jedno z najciekawszych połączeń.
Secure Boot chroni etap uruchamiania.
LUKS chroni dane zapisane na dysku.
Razem tworzą dwa niezależne poziomy ochrony.
UEFI
│
▼
Secure Boot
│
▼
Kernel
│
▼
LUKS
│
▼
Odszyfrowanie dysku
│
▼
LinuxTo właśnie takie warstwowe podejście jest fundamentem nowoczesnego hardeningu.
„Czy Secure Boot jest nie do obejścia?”
Nie.
Historia bezpieczeństwa pokazuje, że pojawiały się podatności dotyczące komponentów UEFI, bootloaderów czy podpisanych narzędzi rozruchowych. Mechanizm znacząco podnosi poprzeczkę, ale nie daje absolutnej gwarancji bezpieczeństwa.
To ważna lekcja.
Bezpieczeństwo nie polega na znalezieniu jednej funkcji, która „rozwiązuje problem”.
Polega na budowaniu wielu niezależnych warstw.
„Jaki jest najczęstszy błąd administratorów?”
Paradoksalnie nie chodzi o konfigurację.
Najczęściej spotykam dwa skrajne podejścia.
Pierwsze:
„Wyłącz Secure Boot, bo przeszkadza.”
Drugie:
„Mam Secure Boot, więc jestem zabezpieczony.”
Oba są uproszczeniem.
Dobry administrator rozumie, gdzie kończy się odpowiedzialność danego mechanizmu.
Secure Boot nie zastąpi aktualizacji.
Nie zastąpi AppArmor.
Nie zastąpi LUKS.
Nie zastąpi dobrego SSH.
Ale potrafi skutecznie chronić pierwszy etap uruchamiania komputera – etap, którego większość użytkowników nigdy nie widzi.
I właśnie dlatego warto go rozumieć, a nie tylko włączać lub wyłączać.
Wykorzystanie narzędzi do dynamicznej analizy (np. strace, ltrace) do monitorowania działania aplikacji i wykrywania błędów W świecie hacking i bezpieczeństwa Czytaj dalej
Jak stworzyć platformę e-learningową Moodle na Ubuntu? Moodle to jedno z najbardziej popularnych rozwiązań do tworzenia platform e-learningowych. Jest to Czytaj dalej
