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 सिस्टम कॉल संसाधित करता है और व्यस्त मशीन पर प्रोसेसर पर उसका असर महसूस होता है। और अगर सर्वर पर एक साइट हो और आपके पास अभी न अखंडता की निगरानी हो न ढंग के स्वचालित अपडेट, तो शुरुआत इससे नहीं की जाती।

इसका वक़्त बाद में आता है — जब बुनियादी काम हो चुके हों और यही सवाल बाक़ी रह जाए कि सर्वर पर ऐसा क्या हो रहा है जो लॉग नहीं दिखाते। और घटनाओं की एक क़िस्म को यह बाकी सबसे मिलकर भी बेहतर ढँकता है: वह शेल जो वेब सर्वर की प्रक्रिया ने चलाया। प्राथमिकता और नियम के अनुसार अलग की गई घटनाएँ कैसी लगती हैं, नीचे डेमो पेज दिखाता है।