Panelet ændrer ikke Falco-konfigurationen — det viser kun et snippet og de kommandoer, du selv anvender på serveren via SSH.
# /etc/falco/rules.d/local-tuning.yaml - rule: <NØJAGTIGT REGELNAVN fra listen ovenfor> 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
Brug det præcise regelnavn. Hvis listen viser beskedteksten i stedet for navnet, så aktivér JSON-output i falco.yaml (json_output: true), så får panelet de præcise regelnavne.
Falco omtales som regel som et Kubernetes-værktøj, og næsten alt, hvad der skrives om det, forudsætter en klynge. Det virker fremragende på en helt almindelig Linux-server, hvor det følger systemkald og alarmerer, når en proces gør noget, den ikke har med at gøre: starter en shell fra webserveren, skriver i en mappe med systembinærfiler, læser følsomme filer eller åbner en uventet udgående forbindelse.
Denne side viser alarmerne med prioritet, den regel der udløstes, samt processen og kommandolinjen bag. Netop den sidste detalje adskiller Falco fra logbaserede værktøjer: det melder, hvad en proces faktisk gjorde, ikke hvad en tjeneste valgte at skrive om sagen.
Standardregelsættet er skrevet med containere for øje og vil være støjende på en nøgen server, indtil det er trimmet. Pakkehåndtering, backupjob og cron-scripts udløser jævnligt regler, der var tænkt til at fange indtrængere. Regn med en time eller to til at dæmpe legitim adfærd, før udskriften bliver brugbar: en alarmstrøm, ingen læser, er det samme som ingen alarmer.