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 نظامی کالیں پروسیس کرتا ہے اور مصروف مشین پر پروسیسر پر اس کا اثر محسوس ہوتا ہے۔ اور اگر سرور پر ایک سائٹ ہو اور آپ کے پاس ابھی نہ سالمیت کی نگرانی ہو نہ ڈھنگ کی خودکار تازہ کاریاں، تو آغاز اس سے نہیں کیا جاتا۔

اس کا وقت بعد میں آتا ہے — جب بنیادی کام ہو چکے ہوں اور یہی سوال باقی رہ جائے کہ سرور پر ایسا کیا ہو رہا ہے جو لاگ نہیں دکھاتے۔ اور واقعات کی ایک قسم کو یہ باقی سب سے مل کر بھی بہتر ڈھانپتا ہے: وہ شیل جو ویب سرور کے عمل نے چلایا۔ ترجیح اور قاعدے کے اعتبار سے الگ کیے گئے واقعات کیسے لگتے ہیں، نیچے ڈیمو صفحہ دکھاتا ہے۔