Falco bir Kubernetes aracı olarak bilinir ve ona dair neredeyse her rehber kümeler için yazılmıştır. Oysa kümelere bağlı değildir: sistem çağrılarını izler ve sitesi olan sıradan bir sunucuda bu tam olarak aynı biçimde çalışır. Yalnızca o durumu neredeyse hiç kimse yazmaz.

Öteki araçların sustuğu yerde işe yarar. Bir sitedeki web kabuğu hiçbir izni ihlal etmez, başarısız oturum açma üretmez ve elle yazılmışsa hiçbir imzayla eşleşmez. Ama bir web sunucusu için anormal bir davranışı vardır: PHP-FPM süreci bir kabuk başlatır. Falco’nun gördüğü şey budur.

Neyi fark eder

Sıradan bir sunucudaki tipik olaylar:

  • web sunucusu ya da PHP süreci tarafından doğurulan bir kabuk — pratikte bir web kabuğunun kesin işareti;
  • /tmp, /dev/shm ya da /var/tmp içinden başlatılan bir program;
  • hassas dosyaların (/etc/shadow, özel anahtarlar) bunu yapmakla hiçbir işi olmayan bir süreç tarafından okunması;
  • sistem ikililerinin değiştirilmesi;
  • ağı kullanmaması gereken bir süreçten giden bir bağlantı.

Kurulum

Anahtar seçim kurulumda yapılır: Falco sistem çağrılarını nasıl elde eder. Çağdaş seçenek eBPF tabanlıdır ve ne bir çekirdek modülü derlemeyi ne de çekirdek başlıklarını gerektirir:

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

Klasik çekirdek modülü başlıklara ihtiyaç duyar ve her çekirdek güncellemesinden sonra yeniden derlenir — güncellemelerin otomatik kurulduğu bir sunucuda bu, ölü bir servisin yinelenen kaynağıdır. Çekirdek yeterince güncelse (5.8 ve üzeri) eBPF’i seçin ve sorunu unutun.

Olayların gerçekten geldiğini kontrol etmek için:

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

Gürültü ve onu gidermek

Asıl iş budur. Standart kural kümesi konteyner ortamlarına yöneliktir ve sıradan bir sunucuda önemli bir kısmı ya uygulanamaz ya da sürekli tetiklenir.

Gelen kurallar (/etc/falco/falco_rules.yaml) düzenlenmez — dosya güncellemede değiştirilir. Kendi değişiklikleriniz /etc/falco/falco_rules.local.yaml içine gider ve istenmeyen kurallar da orada kapatılır:

- rule: Terminal shell in container
  enabled: false

Konteynersiz bir sunucuda genellikle ayarlanması gerekenler:

  • bütün konteyner kuralları — konteyner yokken raporda yalnızca yer kaplarlar;
  • «Write below etc» — her paket kurulumunda ve bir yapılandırma dosyasına yaptığınız her düzenlemede tetiklenir. apt, dpkg ve unattended-upgrades için bir istisna gerektirir, yoksa olaylar akış halinde gelir;
  • «Read sensitive file untrusted» — izleme etmenlerinde, yedekleme araçlarında ve Lynis gibi denetim araçlarında tetiklenir;
  • geçici dizinlerden başlatmalar — meşru istisnalar vardır: bir uygulamanın derlenmesi ya da bir sürücüyü geçici bir dizine açan otomatik bir tarayıcı. Bu tür olaylar endişe verici görünür ama açıklanabilirdir ve her seferinde yeniden çıkarmak yerine belirli yol için hemen bir istisna eklemeye değer.

Makul sıra başka herhangi bir tespit aracındakiyle aynıdır: ilk hafta yalnızca izleyin ve istisnalar ekleyin, ancak ondan sonra beliren bir olayı bir sinyal sayın. Kural basittir — rapor düzenli olarak okumadığınız olaylar içeriyorsa, sizin için hiçbir şey yapmıyor demektir.

Olaylar nereye gönderilmeli

Çıktı /etc/falco/falco.yaml içinde yapılandırılır: bir dosya, sistem günlüğü ya da harici bir programa borulama. Tek bir sunucu için döndürmeyle birlikte bir dosya yeter — döndürmeyi unutmayın, olay dosyası başka herhangi bir günlük gibi büyür ve varsayılan olarak onu kimse izlemez.

Ayırmak için öncelikleri kullanmaya değer: kritik olaylar hemen göreceğiniz yere, geri kalanı sonradan gözden geçirmek üzere genel günlüğe.

Falco ile auditd aynı şey değildir

İkisi de sistem çağrılarını izler, ama farklı amaçlarla. auditd, resim sonradan yeniden kurulabilsin diye olanları kaydeder: hiçbir şeyi değerlendirmez ve hiçbir şey bildirmez, bir günlük tutar. Falco kuralları olay anında uygular ve «bu şüpheli görünüyor» der — yani bir kayıt değil, bir sinyal verir.

İkisini birden tutmak mantıklıdır: yeniden kurmak için günlük, tepki vermek için sinyaller. Birini seçmek gerekirse, bir olaydan sonra olayların sırasını yeniden kurmanın en çok önem taşıdığı bir sunucuda auditd daha faydalıdır; çalışan bir madenci ya da bir web kabuğu hakkında erken bir sinyal istediğiniz yerde ise Falco.

Küçük bir sunucuda yer kaplamaya değer mi

Dürüst yanıt: her zaman değil. Falco sistem çağrılarını işler ve yoğun bir makinede işlemcide fark edilir. Sunucuda tek bir site barınıyorsa ve hâlâ ne bütünlük izlemeniz ne de düzgün otomatik güncellemeleriniz varsa, başlanacak yer burası değildir.

Onun anı sonra gelir — temeller yapıldıktan ve geriye kalan soru, sunucuda günlüklerin göstermediği neler olduğu haline geldikten sonra. Hepsinden daha iyi kapsadığı bir olay sınıfı vardır: web sunucusu süreci tarafından başlatılan bir kabuk. Olayların önceliğe ve kurala göre ayrılmış hali aşağıdaki demo sayfasında.