Falco znany jest jako narzędzie do Kubernetesa i niemal wszystkie poradniki o nim napisano dla klastrów. Tymczasem do klastrów nie jest przywiązany: to obserwacja wywołań systemowych i na zwykłym serwerze z witryną działa dokładnie tak samo. Po prostu o tym zastosowaniu mało kto pisze.

Przydaje się tam, gdzie pozostałe narzędzia milczą. Webshell na witrynie nie narusza uprawnień, nie tworzy nieudanych logowań i nie wpada w sygnaturę, jeśli napisano go ręcznie. Ma jednak zachowanie nienormalne dla serwera WWW: proces PHP-FPM uruchamia powłokę. Falco widzi właśnie to.

Co zauważa

Typowe zdarzenia na zwykłym serwerze:

  • powłoka zrodzona przez proces serwera WWW albo PHP — praktycznie jednoznaczna oznaka webshella;
  • uruchomienie programu z /tmp, /dev/shm albo /var/tmp;
  • czytanie plików wrażliwych (/etc/shadow, klucze prywatne) przez proces, któremu to nie przysługuje;
  • zmiana systemowych plików wykonywalnych;
  • połączenie wychodzące od procesu, który z sieci korzystać nie powinien.

Instalacja

Kluczowy wybór zapada przy instalacji — w jaki sposób Falco pozyskuje wywołania systemowe. Współczesny wariant opiera się na eBPF i nie wymaga ani budowania modułu jądra, ani nagłówków:

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

Klasyczny moduł jądra wymaga nagłówków i jest przebudowywany po każdej aktualizacji jądra — na serwerze z automatycznymi aktualizacjami to stałe źródło niedziałającej usługi. Jeśli jądro jest dostatecznie świeże (5.8 i nowsze), wybierajmy eBPF i zapomnijmy o tym problemie.

Sprawdzenie, że zdarzenia rzeczywiście napływają:

sudo systemctl status falco
sudo journalctl -u falco -n 50

Szum i jak go usunąć

To główna praca. Standardowy zestaw reguł nastawiony jest na środowisko kontenerowe i na zwykłym serwerze znaczna jego część albo nie ma zastosowania, albo działa bez przerwy.

Reguł z pakietu (/etc/falco/falco_rules.yaml) nie edytuje się — plik jest zastępowany przy aktualizacji. Własne zmiany kładzie się w /etc/falco/falco_rules.local.yaml i tam też wyłącza się zbędne:

- rule: Terminal shell in container
  enabled: false

Co zwykle trzeba poprawić na serwerze bez kontenerów:

  • wszystkie reguły o kontenerach — jeśli kontenerów nie ma, zajmują tylko miejsce w raporcie;
  • „Write below etc” — działa przy każdej instalacji pakietu i przy każdej naszej poprawce konfiguracji. Potrzebny jest wyjątek dla apt, dpkg i unattended-upgrades, inaczej zdarzenia pójdą strumieniem;
  • „Read sensitive file untrusted” — działa na agentach monitorowania, kopii zapasowych oraz na narzędziach audytu w rodzaju Lynisa;
  • uruchamianie z katalogów tymczasowych — uzasadnione wyjątki się zdarzają: budowanie aplikacji, zautomatyzowana przeglądarka rozpakowująca sterownik do katalogu tymczasowego. Takie zadziałania wyglądają niepokojąco, ale dają się wyjaśnić, a wyjątek dla konkretnej ścieżki warto założyć od razu, żeby nie rozbierać tego za każdym razem od nowa.

Rozsądna kolejność jest ta sama, co przy każdym innym narzędziu wykrywania: pierwszy tydzień tylko patrzeć i zakładać wyjątki, a dopiero potem traktować nowe zdarzenie jak sygnał. Zasada jest prosta — jeśli w raporcie regularnie są zdarzenia, których nie czytamy, pożytku z niego nie ma.

Gdzie kierować zdarzenia

W /etc/falco/falco.yaml ustawia się wyjście: plik, dziennik systemowy albo przekazanie zewnętrznemu programowi. Dla jednego serwera wystarczy plik z późniejszą rotacją — nie zapomnijmy o niej, plik zdarzeń rośnie tak samo jak każdy dziennik, a domyślnie nikt go nie pilnuje.

Priorytety (priority) warto wykorzystać do rozdzielenia: zdarzenia krytyczne tam, gdzie zobaczymy je od razu, resztę do ogólnego dziennika na później.

Falco i auditd to nie to samo

Oba obserwują wywołania systemowe, ale w różnych celach. auditd zapisuje to, co się dzieje, żeby dało się potem odtworzyć obraz: niczego nie ocenia i o niczym nie informuje, prowadzi dziennik. Falco stosuje reguły w chwili zdarzenia i mówi „to jest podejrzane” — czyli daje sygnał, a nie zapis.

Trzymanie obu jest rozsądne: dziennik do rozbierania i sygnały do reakcji. Jeśli wybierać jedno, to na serwerze, gdzie ważniejsze jest odtworzenie kolejności zdarzeń po incydencie, przydatniejszy jest auditd; tam, gdzie potrzebny jest wczesny sygnał o uruchomionej koparce albo webshellu — Falco.

Czy wart jest miejsca na małym serwerze

Uczciwa odpowiedź: nie zawsze. Falco przetwarza wywołania systemowe i na obciążonej maszynie jest odczuwalny na procesorze. Jeśli serwer trzyma jedną witrynę, a z narzędzi nie ma jeszcze ani kontroli integralności, ani porządnych automatycznych aktualizacji, zaczynać należy nie od niego.

Jego moment nadchodzi później — kiedy rzeczy podstawowe są już zrobione i zostaje pytanie: co takiego dzieje się na serwerze, czego nie widać w dziennikach. Jedną klasę zdarzeń zamyka lepiej niż wszystkie pozostałe razem wzięte — powłokę uruchomioną przez proces serwera WWW. Jak wyglądają zdarzenia z podziałem na priorytety i reguły, pokazuje strona demonstracyjna poniżej.