يجيب 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 بالضبط»: فـ uid=0 مع auid يخص شخصًا بعينه يسمّي الفاعل بلا لبس، مهما ادّعى داخل الجلسة.
القرص
تعيش إعدادات الحجم في /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 نادرة ويمكن تفسير كل واحد منها. وشكل ذلك على صفحة واحدة يعرضه العرض التوضيحي أدناه.