Falco dikenal sebagai perkakas Kubernetes, dan hampir setiap panduan tentangnya ditulis untuk klaster. Tetapi ia tidak terikat pada klaster: ia mengawasi panggilan sistem, dan pada server biasa dengan situs ia bekerja persis sama. Hanya saja hampir tidak ada yang menulis tentang kasus ini.

Dan ia berguna justru di tempat perkakas lain diam. Sebuah web shell di situs tidak melanggar hak akses apa pun, tidak menghasilkan login gagal, dan kalau ditulis dengan tangan juga tidak cocok dengan tanda tangan mana pun. Tetapi ia punya satu perilaku yang tidak lazim bagi server web: proses PHP-FPM menjalankan sebuah shell. Dan itulah yang dilihat Falco.

Apa yang bisa ia rasakan

Peristiwa yang khas pada server biasa:

  • shell yang lahir dari proses server web atau PHP — praktis merupakan tanda tak terbantah dari web shell;
  • program yang dijalankan dari /tmp, /dev/shm atau /var/tmp;
  • pembacaan berkas sensitif (/etc/shadow, kunci privat) oleh proses yang tidak ada urusannya dengan itu;
  • perubahan pada berkas biner sistem;
  • koneksi keluar dari proses yang seharusnya tidak memakai jaringan.

Pemasangan

Pilihan kuncinya ada pada saat pemasangan: bagaimana Falco memperoleh panggilan sistem. Jalur modern berbasis eBPF dan tidak memerlukan pembangunan modul kernel maupun header kernel:

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

Modul kernel klasik memerlukan header dan dibangun ulang setelah setiap pembaruan kernel — dan pada server yang pembaruannya terpasang otomatis, itu adalah sebab berulang layanannya mati. Kalau kernelnya cukup baru (5.8 ke atas) pilihlah eBPF dan lupakan masalah itu.

Untuk memastikan bahwa peristiwanya benar-benar datang:

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

Kebisingan dan cara menghilangkannya

Dan inilah pekerjaan utamanya. Himpunan aturan standar condong ke lingkungan kontainer, dan pada server biasa bagian yang nyata darinya entah tidak berlaku sama sekali atau menyala terus-menerus.

Aturan yang disediakan (/etc/falco/falco_rules.yaml) tidak disunting — saat pembaruan berkasnya diganti. Perubahan Anda masuk ke /etc/falco/falco_rules.local.yaml, dan aturan yang tidak diinginkan juga dimatikan di sana:

- rule: Terminal shell in container
  enabled: false

Pada server tanpa kontainer, biasanya apa yang perlu disetel:

  • semua aturan tentang kontainer — tanpa kontainer mereka hanya memakan tempat di laporan;
  • «Write below etc» — menyala setiap kali paket dipasang dan setiap kali Anda menyunting berkas konfigurasi. Ia memerlukan pengecualian untuk apt, dpkg dan unattended-upgrades, kalau tidak peristiwanya datang seperti banjir;
  • «Read sensitive file untrusted» — menyala pada agen pemantauan, perkakas pencadangan dan perkakas audit seperti Lynis;
  • menjalankan dari direktori sementara — ada pengecualian yang sah: pembangunan sebuah aplikasi, atau peramban otomatis yang membuka driver di direktori sementara. Peristiwa semacam itu tampak mengkhawatirkan tetapi bisa dijelaskan, dan lebih baik langsung menambahkan pengecualian untuk jalur tertentu daripada setiap kali memikirkannya dari awal.

Urutan yang masuk akal sama seperti pada perkakas deteksi mana pun: pekan pertama hanya mengamati dan menambahkan pengecualian, baru setelah itu anggap peristiwa yang muncul sebagai sinyal. Dan aturannya sederhana — kalau di laporan secara berkala ada peristiwa yang tidak Anda baca maka ia tidak melakukan apa pun untuk Anda.

Ke mana mengirim peristiwanya

Keluarannya disetel di /etc/falco/falco.yaml: sebuah berkas, jurnal sistem, atau aliran ke program eksternal. Dan untuk satu server, satu berkas dengan rotasi sesudahnya sudah cukup — jangan lupakan rotasinya, berkas peristiwa juga tumbuh seperti log lain dan secara bawaan tidak ada yang mengawasinya.

Dan sebaiknya pakai prioritas untuk memisahkan: peristiwa kritis pergi ke tempat yang langsung Anda lihat, sisanya ke jurnal umum untuk dilihat nanti.

Falco dan auditd bukan hal yang sama

Keduanya mengawasi panggilan sistem, tetapi dengan tujuan berbeda. auditd mencatat apa yang terjadi supaya gambarannya bisa disusun ulang nanti: ia tidak menilai apa pun dan tidak melaporkan apa pun, ia memegang sebuah jurnal. Sementara Falco menerapkan aturan tepat pada saat peristiwanya dan berkata «ini tampak mencurigakan» — artinya ia memberi sinyal, bukan catatan.

Dan memiliki keduanya itu masuk akal: jurnal untuk menyusun ulang dan sinyal untuk bereaksi. Kalau harus memilih satu maka auditd lebih berguna pada server yang paling penting baginya adalah menyusun ulang urutan peristiwa setelah insiden; sedangkan Falco di tempat yang memerlukan sinyal dini tentang penambang yang berjalan atau web shell.

Apakah ia layak mendapat tempat di server kecil

Jawaban jujurnya: tidak selalu. Falco memproses panggilan sistem dan pada mesin yang sibuk dampaknya terhadap prosesor terasa. Dan kalau di server hanya ada satu situs sementara Anda belum punya pemantauan integritas maupun pembaruan otomatis yang benar, maka jangan mulai dari ini.

Waktunya datang belakangan — ketika pekerjaan dasarnya sudah selesai dan yang tersisa hanya pertanyaan tentang apa yang terjadi di server yang tidak ditampilkan log. Dan ada satu jenis peristiwa yang ia liput lebih baik daripada semua yang lain digabungkan: shell yang dijalankan oleh proses server web. Bagaimana peristiwa yang dipisahkan menurut prioritas dan aturan itu tampak — lihat di halaman demo di bawah.