A Falco Kubernetes-eszközként ismert, és szinte minden róla szóló útmutató fürtökhöz készült. Közben nincs fürtökhöz kötve: rendszerhívások figyeléséről van szó, és egy szokásos, webhelyet futtató szerveren pontosan ugyanúgy működik. Csak erről a forgatókönyvről kevesen írnak.

Ott hasznos, ahol a többi eszköz hallgat. A webhelyen lévő webshell nem sért jogosultságokat, nem hoz létre sikertelen bejelentkezéseket, és nem lép működésbe szignatúra alapján, ha kézzel írták. Van viszont olyan viselkedése, amely egy webszerver számára nem normális: a PHP-FPM folyamat shellt indít. Éppen ezt látja a Falco.

Mit vesz észre

Tipikus események egy szokásos szerveren:

  • a webszerver vagy a PHP folyamata által létrehozott shell — gyakorlatilag egyértelmű webshell-jel;
  • program indítása a /tmp, /dev/shm vagy /var/tmp könyvtárból;
  • érzékeny fájlok (/etc/shadow, privát kulcsok) olvasása olyan folyamat által, amelyet ez nem illet meg;
  • rendszerbináris fájlok módosítása;
  • kimenő kapcsolat olyan folyamattól, amelynek nem kellene hálózatot használnia.

Telepítés

A kulcsdöntés a telepítéskor születik — milyen módon jut a Falco a rendszerhívásokhoz. A mai változat eBPF-re épül, és sem kernelmodul fordítását, sem fejlécfájlokat nem igényel:

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

A klasszikus kernelmodulhoz fejlécfájlok kellenek, és minden kernelfrissítés után újrafordul — olyan szerveren, ahol a frissítések automatikusan települnek, ez a nem működő szolgáltatás rendszeres forrása. Ha a kernel elég friss (5.8 vagy újabb), válaszd az eBPF-et, és felejtsd el ezt a problémát.

Annak ellenőrzése, hogy tényleg érkeznek-e események:

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

A zaj és hogyan szabadulj meg tőle

Ez a fő munka. A szabványos szabálykészlet konténeres környezetre készült, és egy szokásos szerveren jelentős része vagy nem alkalmazható, vagy folyamatosan működésbe lép.

A csomagból származó szabályokat (/etc/falco/falco_rules.yaml) nem szerkesztjük — a fájl frissítéskor cserélődik. A saját módosítások az /etc/falco/falco_rules.local.yaml fájlba kerülnek, és ugyanott kapcsoljuk ki a feleslegeseket:

- rule: Terminal shell in container
  enabled: false

Mit kell általában javítani egy konténerek nélküli szerveren:

  • minden konténerekről szóló szabály — ha nincsenek konténerek, csak helyet foglalnak a jelentésben;
  • „Write below etc” — minden csomagtelepítéskor és minden általad végzett konfigurációmódosításkor működésbe lép. Kivétel kell az apt, dpkg és unattended-upgrades számára, különben áradatban jönnek az események;
  • „Read sensitive file untrusted” — figyelő- és mentőügynököknél, valamint az olyan auditeszközöknél lép működésbe, mint a Lynis;
  • indítás ideiglenes könyvtárakból — jogos kivételek előfordulnak: alkalmazás fordítása, automatizált böngésző, amely ideiglenes könyvtárba csomagol ki egy meghajtót. Az ilyen esetek riasztóan néznek ki, de megmagyarázhatók, és a konkrét útvonalhoz tartozó kivételt érdemes rögtön létrehozni, hogy ne kelljen minden alkalommal újra kibogozni.

Az észszerű sorrend ugyanaz, mint bármely más észlelőeszköznél: az első héten csak nézni és kivételeket létrehozni, és csak azután tekinteni jelzésnek egy új eseményt. A szabály egyszerű — ha a jelentésben rendszeresen vannak olyan események, amelyeket nem olvasol el, akkor nincs belőle haszon.

Hová kerüljenek az események

Az /etc/falco/falco.yaml fájlban állítható a kimenet: fájl, rendszernapló vagy átadás külső programnak. Egy szerverhez elég egy fájl a hozzá tartozó rotációval — arról ne feledkezz meg, az eseményfájl úgy nő, mint bármely napló, és alapból senki nem figyeli.

A prioritásokat (priority) érdemes szétválasztásra használni: a kritikus események oda, ahol azonnal látod őket, a többi az általános naplóba elemzésre.

A Falco és az auditd nem ugyanaz

Mindkettő rendszerhívásokat figyel, de eltérő céllal. Az auditd rögzíti a történteket, hogy később rekonstruálni lehessen a képet: semmit nem értékel és nem jelez, naplót vezet. A Falco az esemény pillanatában alkalmaz szabályokat, és azt mondja: „ez gyanús” — vagyis jelzést ad, nem bejegyzést.

Észszerű mindkettőt tartani: a napló az elemzéshez, a jelzések a reagáláshoz. Ha egyet kell választani, akkor olyan szerveren, ahol fontosabb egy incidens után az események sorrendjének rekonstruálása, az auditd hasznosabb; ahol egy elindult bányászról vagy webshellről kell korai jelzés, ott a Falco.

Megéri-e a helyet egy kis szerveren

Az őszinte válasz: nem mindig. A Falco rendszerhívásokat dolgoz fel, és terhelt gépen érezhető a processzoron. Ha a szerver egyetlen webhelyet futtat, és az eszközök közül még sincs sem integritás-ellenőrzés, sem rendes automatikus frissítés, nem ezzel kell kezdeni.

Az ő pillanata később jön el — amikor az alapok már készen vannak, és marad a kérdés: mi történik a szerveren, ami a naplókban nem látszik. Egy eseményosztályt jobban lefed, mint a többi együttvéve — a webszerver folyamata által indított shellt. Hogy néznek ki az események prioritások és szabályok szerinti bontásban, azt az alábbi bemutatóoldal mutatja.