eBPF: supermoc jądra Linuxa, która działa dla obrońcy i atakującego

Jeśli w ostatnich latach słyszałeś o Cilium, Falco, Tetragon czy „obserwowalności bez agentów”, to za wszystkim stoi jedna technologia: eBPF. To jeden z najważniejszych mechanizmów współczesnego jądra Linuxa — i jednocześnie nowa, słabo rozumiana powierzchnia ataku. Warto zrozumieć, jak działa, bo napędza zarówno nowoczesną obronę, jak i nową generację złośliwego oprogramowania.

Czym jest eBPF

eBPF (extended Berkeley Packet Filter) pozwala uruchamiać małe, piaskownicowane programy wewnątrz jądra, bez pisania modułu jądra i bez rekompilacji. Program eBPF ładujesz z przestrzeni użytkownika (wywołaniem bpf()), a jądro podpina go do zdarzenia — i wykonuje przy każdym jego wystąpieniu.

Kluczowe są miejsca podpięcia (hooki):

kprobes / tracepoints — wywołania funkcji jądra i punkty śledzenia (obserwowalność, wykrywanie zachowań).
XDP (eXpress Data Path) — najwcześniejszy możliwy punkt obsługi pakietu, jeszcze przed alokacją struktur sieciowych; stąd XDP nadaje się do bardzo szybkiego filtrowania i mitygacji DDoS.
tc (traffic control) — kształtowanie i filtrowanie ruchu.
LSM (Linux Security Module) — wpięcie w decyzje bezpieczeństwa jądra (KRSI): pozwól/odmów na poziomie zdarzeń bezpieczeństwa.

Program komunikuje się z przestrzenią użytkownika przez mapy eBPF (tablice, ringbuffery), co pozwala eksportować metryki i zdarzenia bez kosztownego przełączania kontekstu.

Weryfikator — dlaczego to nie jest zwykły moduł jądra

Uruchamianie dowolnego kodu w jądrze brzmi przerażająco. Dlatego sercem bezpieczeństwa eBPF jest weryfikator (verifier) — komponent jądra, który przed załadowaniem programu statycznie dowodzi, że jest on „bezpieczny”:

Kończy się — brak nieograniczonych pętli (historycznie zakaz pętli, dziś dozwolone pętle ograniczone).
Nie sięga poza pamięć — każdy dostęp do pamięci jest sprawdzany pod kątem granic.
Nie wisi w jądrze — ograniczona liczba instrukcji i złożoność.

Dopiero program, który przejdzie weryfikator, jest kompilowany (JIT) do kodu maszynowego i uruchamiany z pełną prędkością. To właśnie weryfikator odróżnia eBPF od klasycznego modułu jądra, który może zrobić w systemie dosłownie wszystko.

eBPF w obronie: obserwowalność i egzekwowanie

Dla zespołów bezpieczeństwa eBPF to przełom, bo daje głęboki wgląd w system bez ingerencji w aplikacje:

Runtime security. Narzędzia jak Falco czy Tetragon obserwują wywołania systemowe, uruchamianie procesów, dostęp do plików i połączenia sieciowe — i wykrywają podejrzane zachowania (np. shell uruchomiony w kontenerze, próba odczytu wrażliwych plików). To szczególnie cenne w bezpieczeństwie Kubernetes i kontenerów, gdzie klasyczne agenty są kłopotliwe.
Sieć i polityki. Cilium realizuje polityki sieciowe i mikrosegmentację (spójne z ideą Zero Trust) bezpośrednio w jądrze, wydajniej niż tradycyjny iptables.
Mitygacja DDoS na XDP. Odrzucanie złośliwych pakietów na najwcześniejszym etapie oznacza minimalny koszt na pakiet — stąd XDP w rozwiązaniach anty-DDoS.

Wielką zaletą jest wydajność: zdarzenia są filtrowane i agregowane w jądrze, więc do przestrzeni użytkownika trafia tylko to, co istotne.

eBPF w ataku: nowa klasa rootkitów

Ta sama moc, która pomaga obrońcy, kusi atakującego. eBPF działający z odpowiednimi uprawnieniami może:

Ukrywać się i ukrywać inne artefakty — manipulować tym, co widzą narzędzia (ukrywanie procesów, plików, połączeń), realizując funkcje rootkita bez ładowania modułu jądra.
Podsłuchiwać i wykradać dane — przechwytywać ruch, dane z wywołań systemowych, poświadczenia, zanim zostaną zaszyfrowane.
Modyfikować zachowanie systemu — wpływać na decyzje jądra tam, gdzie ma wpięte hooki.

Powstały już publiczne frameworki złośliwego eBPF, a badania pokazują, jak trudno taki kod wykryć klasycznymi metodami. Do tego dochodzą podatności w samym weryfikatorze: w historii jądra pojawiały się błędy, które pozwalały obejść jego gwarancje i osiągnąć eskalację uprawnień z lokalnego użytkownika do jądra. eBPF jest więc jednocześnie narzędziem obrony i celem ataku.

Hardening: jak ograniczyć ryzyko

Podstawowa zasada: eBPF to potężne uprawnienie — traktuj je jak dostęp do jądra.

Wyłącz nieuprzywilejowany eBPF. W większości dystrybucji jest to już domyślne, ale zweryfikuj:
```
sysctl kernel.unprivileged_bpf_disabled   # powinno być 1 lub 2
```
Dzięki temu programów eBPF nie załaduje zwykły użytkownik.
Kontroluj uprawnienia. Ładowanie eBPF wymaga CAP_BPF (oraz dodatkowych zdolności zależnie od typu programu). Nie przyznawaj tych zdolności kontenerom ani usługom, które ich nie potrzebują — to element ogólnego hardeningu Linuxa.
Monitoruj użycie bpf(). Skoro atakujący też może użyć eBPF, samo ładowanie programów jest sygnałem wartym obserwacji. Wpięcie w audyt wywołań systemowych i alertowanie na nietypowe bpf() to dobry element monitoringu bezpieczeństwa.
Aktualizuj jądro. Podatności weryfikatora łata się w jądrze — utrzymanie aktualnej wersji jest tu krytyczne.
Minimalizuj bazę. W środowiskach kontenerowych stosuj minimalne obrazy i profile seccomp/AppArmor ograniczające dostępne wywołania.

Podsumowanie

eBPF to jedna z najważniejszych technologii współczesnego Linuxa: daje bezprecedensowy wgląd w system i szybką, programowalną sieć — dlatego napędza nowoczesny monitoring, mikrosegmentację i anty-DDoS. Ta sama moc czyni z niego jednak atrakcyjne narzędzie dla atakującego i cel podatności. Rozsądne podejście to: korzystać z obronnego potencjału eBPF, a jednocześnie traktować ładowanie programów jak uprawnienie klasy jądra — wyłączać nieuprzywilejowany dostęp, kontrolować zdolności, monitorować bpf() i aktualizować jądro.

Jeśli budujecie środowisko kontenerowe lub chcecie ocenić hardening swoich systemów Linux pod kątem takich mechanizmów, odezwijcie się — hardening i audyt konfiguracji to jedna z naszych specjalizacji.

Najczęstsze pytania (FAQ)

Czy eBPF jest bezpieczny, skoro można nim napisać rootkit? Sam mechanizm ma solidne zabezpieczenia — weryfikator i wymóg wysokich uprawnień do ładowania programów. Ryzyko pojawia się, gdy atakujący zdobędzie już odpowiednie uprawnienia (lub gdy nieuprzywilejowany eBPF jest włączony). Dlatego kluczowe jest ograniczanie, kto może ładować programy eBPF, i monitorowanie tego.

Czy potrzebuję eBPF, żeby zabezpieczyć serwery? Nie jest obowiązkowy, ale narzędzia oparte na eBPF (do runtime security i obserwowalności) dają jakościowo lepszy wgląd niż wiele klasycznych rozwiązań, zwłaszcza w kontenerach. To jedna z najlepszych dostępnych opcji nowoczesnego wykrywania zagrożeń na Linuksie.

Jak wykryć złośliwy program eBPF w systemie? To trudne, bo eBPF może aktywnie się ukrywać. Pomaga monitorowanie wywołań bpf(), inwentaryzacja załadowanych programów (bpftool prog list), ograniczenie uprawnień do ich ładowania oraz narzędzia obserwujące jądro. Najskuteczniejsza jest prewencja: nie dopuścić, by atakujący zdobył uprawnienia potrzebne do załadowania programu.

Czym eBPF różni się od modułu jądra? Moduł jądra ma nieograniczony dostęp i może zawiesić lub skompromitować cały system. Program eBPF przechodzi przez weryfikator, który dowodzi jego bezpieczeństwa (ograniczona pamięć, zakończoność), działa w piaskownicy i jest ładowany bez rekompilacji jądra. To znacznie bezpieczniejszy, choć wciąż potężny, model rozszerzania jądra.