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 সিস্টেম কল প্রক্রিয়া করে আর ব্যস্ত যন্ত্রে প্রসেসরে তার প্রভাব টের পাওয়া যায়। আর সার্ভারে একটা সাইট থাকলে আর আপনার এখনও না অখণ্ডতার নজরদারি থাকলে না ঠিকঠাক স্বয়ংক্রিয় হালনাগাদ, তবে শুরুটা এটি দিয়ে করা হয় না।
তার সময় আসে পরে — যখন মৌলিক কাজগুলো হয়ে গেছে আর কেবল এই প্রশ্নই বাকি থাকে যে সার্ভারে এমন কী ঘটছে যা লগ দেখায় না। আর এক ধরনের ঘটনা সে বাকি সবার মিলিত চেষ্টার চেয়েও ভালো ঢাকে: যে শেল ওয়েব সার্ভারের প্রক্রিয়া চালিয়েছে। অগ্রাধিকার ও নিয়ম অনুযায়ী পৃথক করা ঘটনা কেমন দেখায় তা নিচের ডেমো পাতা দেখায়।