Falco е известен като инструмент за Kubernetes и почти всички ръководства за него са писани за клъстери. Междувременно той не е обвързан с клъстери: става дума за наблюдение на системни извиквания, а на обикновен сървър със сайт то работи точно по същия начин. Просто за този сценарий пишат малцина.

Полезен е там, където останалите инструменти мълчат. Уеб обвивката на сайта не нарушава права за достъп, не създава неуспешни влизания и не се задейства по сигнатура, ако е написана ръчно. Но има поведение, което за уеб сървър е ненормално: процесът PHP-FPM стартира обвивка. Точно това вижда Falco.

Какво забелязва

Типични събития на обикновен сървър:

  • обвивка, породена от процеса на уеб сървъра или на PHP — практически еднозначен признак на уеб обвивка;
  • стартиране на програма от /tmp, /dev/shm или /var/tmp;
  • четене на чувствителни файлове (/etc/shadow, частни ключове) от процес, на когото това не се полага;
  • промяна на системни двоични файлове;
  • изходяща връзка от процес, който не бива да ползва мрежата.

Инсталиране

Ключовият избор се прави при инсталирането — по какъв начин Falco получава системните извиквания. Съвременният вариант е базиран на eBPF и не изисква нито компилиране на модул на ядрото, нито заглавни файлове:

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

Класическият модул на ядрото изисква заглавни файлове и се прекомпилира след всяко обновяване на ядрото — на сървър, където обновяванията се инсталират автоматично, това е редовен източник на неработеща услуга. Ако ядрото е достатъчно ново (5.8 и по-високо), изберете eBPF и забравете за този проблем.

Проверка, че събитията наистина постъпват:

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

Шумът и как да се премахне

Това е основната работа. Стандартният набор правила е разчетен за контейнерна среда и на обикновен сървър значителна част от него или не е приложима, или се задейства постоянно.

Правилата от доставката (/etc/falco/falco_rules.yaml) не се редактират — файлът се заменя при обновяване. Собствените промени се слагат в /etc/falco/falco_rules.local.yaml, и там също се изключват излишните:

- rule: Terminal shell in container
  enabled: false

Какво обикновено се налага да се поправи на сървър без контейнери:

  • всички правила за контейнери — ако контейнери няма, те само заемат място в отчета;
  • „Write below etc“ — задейства се при всяко инсталиране на пакет и при всяка ваша промяна на конфигурацията. Нужно е изключение за apt, dpkg и unattended-upgrades, иначе събитията ще потекат на поток;
  • „Read sensitive file untrusted“ — задейства се при агенти за наблюдение и резервно копиране и при одитни инструменти като Lynis;
  • стартиране от временни директории — законни изключения има: компилиране на приложение, автоматизиран браузър, който разопакова драйвер във временна директория. Такива задействания изглеждат тревожно, но се обясняват, и изключение за конкретния път си струва да се направи веднага, за да не се разнищва всеки път наново.

Разумният ред е същият както при всеки друг инструмент за откриване: първата седмица само да се гледа и да се правят изключения, и едва после появилото се събитие да се приема като сигнал. Правилото е просто — ако в отчета редовно има събития, които не четете, полза от него няма.

Къде да отиват събитията

В /etc/falco/falco.yaml се настройва изходът: файл, системен журнал или предаване към външна програма. За един сървър стига файл с последваща ротация — не забравяйте за нея, файлът със събития расте като всеки журнал и по подразбиране никой не го следи.

Приоритетите (priority) си струва да се използват за разделяне: критичните събития — там, където ще ги видите веднага, останалото — в общ журнал за разбор.

Falco и auditd не са едно и също

И двата следят системни извиквания, но с различни цели. auditd записва случващото се, за да може после да се възстанови картината: той нищо не оценява и не съобщава, води дневник. Falco прилага правила в момента на събитието и казва „ето това е подозрително“ — тоест дава сигнал, а не запис.

Разумно е да се държат и двата: дневникът за разбор и сигналите за реакция. Ако трябва да се избере един, то на сървър, където е по-важно да се възстанови последователността от събития след произшествие, е по-полезен auditd; там, където е нужен ранен сигнал за стартиран копач или уеб обвивка, е Falco.

Струва ли си мястото на малък сървър

Честният отговор: не винаги. Falco обработва системни извиквания и на натоварена машина се усеща по процесора. Ако сървърът държи един сайт, а от инструментите още няма нито контрол на целостта, нито нормални автоматични обновявания, не бива да се започва с него.

Неговият момент идва по-късно — когато основните неща вече са направени и остава въпросът: какво се случва на сървъра, което не се вижда в журналите. Един клас събития той закрива по-добре от всички останали, взети заедно — обвивка, стартирана от процеса на уеб сървъра. Как изглеждат събитията с разбивка по приоритети и правила, показва демонстрационната страница по-долу.