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 מופיעים לעיתים רחוקות וכל אחד מהם ניתן להסבר. איך זה נראה בעמוד אחד מראה ההדגמה למטה.