Panel nie zmienia konfiguracji Falco — pokazuje tylko fragment i polecenia, które stosuje Pan/Pani na serwerze przez SSH.
# /etc/falco/rules.d/local-tuning.yaml - rule: <DOKŁADNA NAZWA REGUŁY z listy powyżej> condition: and not fd.name = /path/to/exclude append: true
sudo nano /etc/falco/rules.d/local-tuning.yaml sudo falco --validate /etc/falco/rules.d/local-tuning.yaml sudo systemctl restart falco 2>/dev/null || sudo systemctl restart falco-modern-bpf
Proszę użyć dokładnej nazwy reguły. Jeśli na liście widnieje treść komunikatu, a nie nazwa — proszę włączyć wyjście JSON w falco.yaml (json_output: true), wtedy panel otrzyma dokładne nazwy reguł.
O Falco mówi się zwykle jak o narzędziu dla Kubernetes i niemal wszystko, co się o nim pisze, zakłada klaster. Działa doskonale na zwyczajnym serwerze z Linuksem, gdzie obserwuje wywołania systemowe i podnosi alarm, gdy proces robi coś, co do niego nie należy: uruchamia powłokę z serwera WWW, zapisuje w katalogu binariów systemowych, czyta wrażliwe pliki albo otwiera nieoczekiwane połączenie wychodzące.
Ta strona pokazuje alerty z priorytetem, wyzwoloną regułą oraz procesem i wierszem poleceń, który za nimi stoi. To właśnie ten ostatni szczegół odróżnia Falco od narzędzi opartych na dziennikach: raportuje, co proces naprawdę zrobił, a nie to, co usługa postanowiła o tym napisać.
Domyślny zestaw reguł napisano z myślą o kontenerach i na gołym serwerze będzie hałaśliwy, dopóki się go nie dostroi. Menedżery pakietów, zadania kopii zapasowych i skrypty crona regularnie wyzwalają reguły pomyślane do łapania intruzów. Przewidź godzinę lub dwie na wyciszanie zachowań legalnych, zanim wynik stanie się użyteczny: strumień alertów, którego nikt nie czyta, to to samo, co brak alertów.