auditd: وہ قواعد جن کے ہونے سے بعد میں پڑھنے کو کچھ ہو

auditd اُن سوالوں کا جواب دیتا ہے جو واقعے کے بعد اٹھتے ہیں: یہ فائل کس نے بدلی، یہ صارف کب بنایا گیا، یہ عمل کہاں سے چلا۔ اور کوئی دوسرا اوزار ان کا جواب نہیں دیتا — ایپلیکیشنوں کے لاگ میں یہ معلومات ہوتی ہی نہیں، اور شیل کی تاریخ وہی ترمیم کر دیتا ہے جو اسے چھوڑ کر گیا۔

مشکل یہ ہے کہ پیکج کی تنصیب بذاتِ خود آپ کو کچھ نہیں دیتی۔ طے شدہ قواعد عملاً ہیں ہی نہیں، جرنل لکھا تو جاتا ہے مگر جوہر میں خالی ہوتا ہے، اور یہ بات بدترین ممکنہ لمحے پر کھلتی ہے — جب ڈیٹا درکار ہو اور موجود نہ ہو۔

تنصیب

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

ایک خصوصیت: کچھ نسخوں میں auditd کو systemctl restart سے دوبارہ نہیں چلایا جا سکتا — سروس اپنی الگ کمانڈ سے چلتی ہے۔ قواعد یوں دوبارہ پڑھے جاتے ہیں:

sudo augenrules --load
sudo auditctl -l

دوسری کمانڈ دکھاتی ہے کہ واقعی کیا لوڈ ہے۔ اسی پر بھروسا کریں، فائلوں کے مواد پر نہیں۔

مجموعۂ قواعد

قواعد /etc/audit/rules.d/ میں الگ فائل کے طور پر رکھے جاتے ہیں۔ نیچے ایک کم سے کم مجموعہ ہے جو اپنی قیمت وصول کر لیتا ہے: یہ ڈسک کو دفن کیے بغیر کسی واقعے کے دوران اٹھنے والے بیشتر سوالوں کا جواب دیتا ہے۔

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## صارفین اور اختیارات
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges

## SSH تک رسائی
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## شیڈول شدہ کام
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## کرنل کے ماڈیول
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## sudo اور su کا استعمال
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

نحو مختصر ہے: -w نگرانی کا راستہ ہے، -p wa کا مطلب لکھنے اور خصوصیات کی تبدیلی پر ردعمل، -p x چلانے پر، اور -k بعد میں تلاش کے لیے کلید۔ اور یہی کلیدیں اصل سہولت ہیں: ان کے بغیر جرنل میں تلاش ایک گیگابائٹ متن چھاننے میں بدل جاتی ہے۔

اس فہرست میں کیا نہیں ہے اور کیوں

رہنمائیاں اکثر ہر execve کال درج کرنے کا مشورہ دیتی ہیں — یعنی ہر پروگرام کا ہر آغاز۔ لالچ سمجھ میں آتا ہے: جو کچھ ہوا اس کی مکمل تصویر۔ مگر عملاً چلتے ہوئے سرور پر یہ روزانہ سیکڑوں میگابائٹ پیدا کرتا ہے، پروسیسر کا نمایاں حصہ کھا جاتا ہے، اور اس کا نتیجہ یہ نکلتا ہے کہ جرنل ضرورت پڑنے سے پہلے ہی کاٹ دیا جاتا ہے۔ اگر اتنی تفصیل درکار ہو تو اسے تنگ دائرے میں فعال کریں — ایک صارف کے لیے یا کسی تحقیق کی مدت کے لیے۔

یہی بات سائٹ کی ڈائریکٹری کی نگرانی پر بھی لاگو ہے: اس میں لکھنا مسلسل ہوتا ہے، اور یہ قاعدہ جرنل کو بے معنی واقعات کے بہاؤ میں بدل دیتا ہے۔

اسے کیسے پڑھیں

کلید سے تلاش کریں، عددی شناخت کنندے ناموں میں بدلوا کر:

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

-i جھنڈا پڑھنے کی سہولت کے لیے ناگزیر ہے: اس کے بغیر آپ کو صارفوں کے ناموں اور نظامی کالوں کی جگہ اعداد ملیں گے۔ اور -ts مدت محدود کرتا ہے (today، recent یا کوئی مخصوص تاریخ)۔

کسی مدت کا خلاصہ:

sudo aureport --summary -i
sudo aureport --auth -i --failed

واقعے کے اندراج میں تین خانے دلچسپ ہیں: auid اُس صارف کا شناخت کنندہ جس نے سیشن شروع کیا، uid وہ شناخت جس کے تحت عمل چلا، اور exe وہ پروگرام جس نے اسے انجام دیا۔ اور auid اور uid کا فرق ہی اس سوال کا جواب ہے کہ «ٹھیک ٹھیک کون root بنا»: کسی مخصوص فرد کے auid کے ساتھ uid=0 مجرم کا نام بلا ابہام بتا دیتا ہے، چاہے اُس نے سیشن کے اندر خود کو کچھ بھی ظاہر کیا ہو۔

ڈسک

حجم کی ترتیبات /etc/audit/auditd.conf میں رہتی ہیں:

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

اور disk_full_action کو الگ سے دیکھیں۔ کچھ ترتیبات میں بطور طے شدہ ڈسک بھرنے پر نظام روک دینا مقرر ہوتا ہے — ایسا رویہ جو آڈٹ کے تقاضوں والی مشینوں پر جائز ہے اور ویب سرور پر بالکل بے محل۔ ڈسک ختم ہونے سے پہلے اس قدر کو جانچ لیں۔

ناقابلِ تبدیل قواعد

قواعد کی فائل کے آخر میں -e 2 سطر انہیں دوبارہ آغاز تک بدلنے سے روک دیتی ہے — بشمول اُس کے جس نے root حاصل کر لیا ہو۔ اور یہ جرنل کی قدر نمایاں طور پر بڑھا دیتی ہے: حملہ آور مشین دوبارہ چلائے بغیر نگرانی بند نہیں کر سکتا، اور دوبارہ آغاز خود ہی نمایاں ہوتا ہے۔

دوسرا پہلو واضح ہے: آپ بھی دوبارہ آغاز کے بغیر اپنے قواعد نہیں بدل سکیں گے۔ اسے تب فعال کریں جب مجموعۂ قواعد ٹھہر جائے اور آپ ایک مہینہ اس کے ساتھ گزار لیں۔

ایک عام سرور پر یہ جھنجھٹ کیوں

auditd کسی چیز کو روکتا نہیں۔ اس کی قدر ٹھیک ایک بار ظاہر ہوتی ہے — جب واقعات کی ترتیب دوبارہ جوڑنی ہو، اور ڈیٹا یا تو ہوتا ہے یا نہیں۔ اور اسے پیچھے جا کر جمع نہیں کیا جا سکتا، اسی لیے مجموعۂ قواعد پہلے سے رکھا جاتا ہے اور پھر چھیڑا نہیں جاتا۔

ترتیب درست ہونے کی عملی علامت: قواعد کی فہرست خالی نہیں، جرنل بے قابو نہیں بڑھتا، اور identity اور privileges کلیدوں والے واقعات شاذ آتے ہیں اور ہر ایک قابلِ وضاحت ہوتا ہے۔ یہ ایک صفحے پر کیسا لگتا ہے، نیچے ڈیمو دکھاتا ہے۔