Falco tunnetaan Kubernetes-työkaluna, ja lähes kaikki sitä koskevat oppaat on kirjoitettu klustereille. Se ei kuitenkaan ole sidottu klustereihin: kyse on järjestelmäkutsujen seurannasta, ja tavallisella sivustopalvelimella se toimii täsmälleen samoin. Tuosta käyttötapauksesta vain kirjoittaa harva.

Se on hyödyllinen siellä, missä muut työkalut vaikenevat. Verkkokuori sivustolla ei riko oikeuksia, ei luo epäonnistuneita kirjautumisia eikä laukaise allekirjoitusta, jos se on kirjoitettu käsin. Mutta sillä on käyttäytyminen, joka on verkkopalvelimelle epänormaalia: PHP-FPM-prosessi käynnistää komentotulkin. Juuri sen Falco näkee.

Mitä se havaitsee

Tyypilliset tapahtumat tavallisella palvelimella:

  • verkkopalvelimen tai PHP:n prosessin synnyttämä komentotulkki — käytännössä yksiselitteinen merkki verkkokuoresta;
  • ohjelman käynnistys hakemistoista /tmp, /dev/shm tai /var/tmp;
  • arkaluonteisten tiedostojen (/etc/shadow, yksityiset avaimet) lukeminen prosessilta, jolle se ei kuulu;
  • järjestelmän binääritiedostojen muuttaminen;
  • lähtevä yhteys prosessilta, jonka ei pidä käyttää verkkoa.

Asennus

Ratkaiseva valinta tehdään asennuksessa — millä tavalla Falco saa järjestelmäkutsut. Nykyaikainen vaihtoehto perustuu eBPF:ään eikä vaadi ytimen moduulin kääntämistä eikä otsikkotiedostoja:

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

Klassinen ytimen moduuli vaatii otsikkotiedostot ja käännetään uudelleen jokaisen ydinpäivityksen jälkeen — palvelimella, jolla päivitykset asentuvat automaattisesti, se on säännöllinen lähde toimimattomalle palvelulle. Jos ydin on riittävän tuore (5.8 ja uudempi), valitse eBPF ja unohda tuo ongelma.

Tarkistus siitä, että tapahtumia todella tulee:

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

Kohina ja miten siitä pääsee eroon

Tämä on päätyö. Vakiosääntökokoelma on suunniteltu konttiympäristöön, ja tavallisella palvelimella merkittävä osa siitä joko ei sovellu tai laukeaa jatkuvasti.

Mukana tulevia sääntöjä (/etc/falco/falco_rules.yaml) ei muokata — tiedosto korvataan päivityksessä. Omat muutokset laitetaan tiedostoon /etc/falco/falco_rules.local.yaml, ja siellä myös kytketään ylimääräiset pois:

- rule: Terminal shell in container
  enabled: false

Mitä yleensä joutuu korjaamaan palvelimella, jolla ei ole kontteja:

  • kaikki kontteja koskevat säännöt — jos kontteja ei ole, ne vain vievät tilaa raportista;
  • ”Write below etc” — laukeaa jokaisen paketin asennuksen ja jokaisen tekemäsi asetusmuutoksen yhteydessä. Tarvitaan poikkeus paketeille apt, dpkg ja unattended-upgrades, muuten tapahtumia tulee virtana;
  • ”Read sensitive file untrusted” — laukeaa valvonta- ja varmuuskopiointiagenteista sekä auditointityökaluista kuten Lynis;
  • käynnistys väliaikaishakemistoista — laillisia poikkeuksia esiintyy: sovelluksen kääntäminen, automatisoitu selain joka purkaa ajurin väliaikaishakemistoon. Tällaiset laukeamiset näyttävät huolestuttavilta mutta selittyvät, ja poikkeus tietylle polulle kannattaa luoda heti, jottei samaa tarvitse selvittää joka kerta uudelleen.

Järkevä järjestys on sama kuin minkä tahansa muun havaitsemistyökalun kanssa: ensimmäinen viikko vain katsotaan ja luodaan poikkeuksia, ja vasta sitten uutta tapahtumaa kohdellaan signaalina. Sääntö on yksinkertainen — jos raportissa on säännöllisesti tapahtumia, joita et lue, siitä ei ole hyötyä.

Minne tapahtumat ohjataan

Tiedostossa /etc/falco/falco.yaml asetetaan tuloste: tiedosto, järjestelmäloki tai välitys ulkoiselle ohjelmalle. Yhdelle palvelimelle riittää tiedosto ja sen kierto — älä unohda sitä, tapahtumatiedosto kasvaa kuten mikä tahansa loki, eikä sitä oletuksena valvo kukaan.

Prioriteetteja (priority) kannattaa käyttää erotteluun: kriittiset tapahtumat sinne, missä näet ne heti, loput yleiseen lokiin läpikäyntiä varten.

Falco ja auditd eivät ole sama asia

Molemmat seuraavat järjestelmäkutsuja mutta eri tarkoituksissa. auditd kirjaa tapahtuvan, jotta kuva voidaan jälkeenpäin rekonstruoida: se ei arvioi mitään eikä ilmoita, se pitää päiväkirjaa. Falco soveltaa sääntöjä tapahtuman hetkellä ja sanoo ”tämä on epäilyttävää” — se siis antaa signaalin eikä merkintää.

Molempien pitäminen on järkevää: päiväkirja läpikäyntiin ja signaalit reagointiin. Jos on valittava yksi, palvelimella, jolla tärkeintä on pystyä rekonstruoimaan tapahtumaketju tapauksen jälkeen, auditd on hyödyllisempi; siellä missä tarvitaan varhainen signaali käynnistetystä louhijasta tai verkkokuoresta, se on Falco.

Onko se tilansa arvoinen pienellä palvelimella

Rehellinen vastaus: ei aina. Falco käsittelee järjestelmäkutsuja ja näkyy kuormitetulla koneella suorittimessa. Jos palvelin pitää yhtä sivustoa eikä työkaluista ole vielä eheystarkistusta eikä kunnollisia automaattipäivityksiä, aloittaa ei kannata siitä.

Sen hetki tulee myöhemmin — kun perusasiat on tehty ja jäljelle jää kysymys: mitä palvelimella tapahtuu sellaista, mikä ei näy lokeissa. Yhden tapahtumaluokan se kattaa paremmin kuin kaikki muut yhteensä — verkkopalvelimen prosessin käynnistämän komentotulkin. Miltä tapahtumat näyttävät prioriteeteittain ja säännöittäin jaoteltuina, näkyy alla olevalla esittelysivulla.