يُعرف Falco بوصفه أداة لـ Kubernetes، وكل دليل عنه تقريبًا مكتوب للعناقيد. غير أنه ليس مرتبطًا بالعناقيد: فهو يراقب استدعاءات النظام، وعلى خادم عادي عليه موقع يعمل بالطريقة نفسها تمامًا. ولكن لا أحد تقريبًا يكتب عن هذه الحالة.

وهو مفيد حيث تصمت الأدوات الأخرى. فالـ web shell على موقع لا ينتهك أي أذونات، ولا ينتج عمليات دخول فاشلة، ولا يطابق أي توقيع إن كُتب يدويًا. لكن له سلوكًا غير طبيعي بالنسبة إلى خادم ويب: عملية PHP-FPM تُطلق صدفة. وهذا ما يراه Falco.

ماذا يلاحظ

أحداث نموذجية على خادم عادي:

  • صدفة ولّدها خادم الويب أو عملية PHP — علامة شبه قاطعة على web shell؛
  • برنامج أُطلق من /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: ملف، أو سجل النظام، أو تمرير إلى برنامج خارجي. ولخادم واحد يكفي ملف مع تدوير بعده — ولا تنسَ التدوير، فملف الأحداث ينمو كأي سجل آخر ولا يراقبه أحد افتراضيًا.

ويستحق استخدام الأولويات للفصل: فالأحداث الحرجة تذهب حيث تراها فورًا، والبقية إلى السجل العام للمراجعة لاحقًا.

Falco و auditd ليسا الشيء نفسه

كلاهما يراقب استدعاءات النظام، لكن بغايتين مختلفتين. فـ auditd يسجّل ما يحدث كي يمكن إعادة بناء الصورة لاحقًا: فهو لا يقيّم شيئًا ولا يبلّغ عن شيء، بل يمسك سجلًا. أما Falco فيطبّق القواعد لحظة الحدث ويقول «هذا يبدو مريبًا» — أي أنه يعطي إشارة لا سجلًا.

والاحتفاظ بكليهما معقول: السجل لإعادة البناء والإشارات للاستجابة. وإن توجّب اختيار واحد، فـ auditd أنفع على خادم يكون فيه إعادة بناء تسلسل الأحداث بعد حادثة هو الأهم؛ و Falco حيث تريد إشارة مبكرة عن مُعدِّن يعمل أو web shell.

هل يستحق مكانًا على خادم صغير

الجواب الصادق: ليس دائمًا. فـ Falco يعالج استدعاءات النظام وأثره ملحوظ على المعالج في آلة مزدحمة. وإن كان على الخادم موقع واحد ولم تكن لديك بعد لا مراقبة سلامة ولا تحديثات تلقائية لائقة، فليس هو ما تبدأ به.

وتأتي لحظته لاحقًا — بعد إنجاز الأساسيات وبقاء سؤال واحد: ماذا يجري على الخادم مما لا تُظهره السجلات. وثمة صنف واحد من الأحداث يغطيه أفضل من كل ما عداه مجتمعًا: صدفة أطلقتها عملية خادم الويب. وشكل الأحداث مقسّمة حسب الأولوية والقاعدة تعرضه صفحة العرض التوضيحي أدناه.