מדריך auditd לינוקס מלא (2026)

מבוא: למה auditd הוא הכלי שאתם חייבים להכיר ב-2026

בגילוי לב? אני חושב ש-auditd הוא אחד הכלים הכי מוערכים-בחסר בעולם הלינוקס. בשנת 2026, עם למעלה מ-5,500 פגיעויות CVE שנרשמו בליבת לינוקס בשנה שעברה בלבד — עלייה של 28% לעומת 2024 — ניטור אבטחה ברמת הקרנל כבר לא מותרות. זה הכרח.

וכאן נכנס auditd — מערכת הביקורת המובנית של לינוקס, שנותנת לכם ראות מלאה לכל מה שקורה במערכת ברמת system calls.

בניגוד לכלי לוגינג רגילים שמתמקדים באפליקציות, auditd עובד ברמת הקרנל. הוא רואה הכל — גישה לקבצים, הרצת תהליכים, שינויי הרשאות, חיבורי רשת, טעינת מודולים. בעצם, כל system call שנעשה על המכונה. וזה בדיוק מה שצוותי SOC, מנהלי מערכת ואנשי compliance צריכים כדי לזהות חדירות, לבצע forensics, ולעמוד בתקני אבטחה כמו PCI-DSS, HIPAA ו-CIS Benchmarks.

הבעיה? רוב המדריכים באינטרנט עוצרים ברמה של "התקינו auditd ותכתבו כמה כללים". אבל מערכת ביקורת שמוגדרת לא נכון היא יותר גרועה ממערכת שלא קיימת — היא נותנת תחושת ביטחון מזויפת בזמן שהאיומים האמיתיים חומקים. במדריך הזה נלך הרבה יותר רחוק: מארכיטקטורה וחשיבה, דרך כללים מותאמים ל-CIS ו-MITRE ATT&CK, ועד כיוונון ביצועים ל-production ואינטגרציה עם מערכות SIEM.

מבנה מערכת הביקורת של לינוקס: הרכיבים שחשוב להבין

לפני שנצלול לכללים ותצורות, בואו נבין את הארכיטקטורה. זה אולי נשמע תיאורטי מדי, אבל תאמינו לי — הבנה של מה שקורה מאחורי הקלעים תחסוך לכם שעות של debug בהמשך.

מערכת הביקורת של לינוקס מורכבת ממספר שכבות שעובדות יחד, וכל שכבה ממלאה תפקיד קריטי.

תת-מערכת הביקורת בקרנל (Kernel Audit Subsystem)

זו השכבה הבסיסית ביותר — hooks שמוטמעים ישירות בקרנל ולוכדים אירועים לפני שהם מסתיימים. המשמעות המעשית? אין דרך לעקוף את הלוגינג בלי לשנות את הקרנל עצמו. זה מה שהופך את auditd לאמין הרבה יותר ממנגנוני לוגינג ברמת האפליקציה.

תת-מערכת הקרנל תלויה ב-CONFIG_AUDIT ו-CONFIG_AUDITSYSCALL, שמופעלים כברירת מחדל ברוב ההפצות (אז סביר שזה כבר עובד אצלכם).

ה-Daemon — auditd

זהו התהליך שרץ ב-user space ומקבל את האירועים מהקרנל. הוא אחראי על כתיבת הלוגים לדיסק — כברירת מחדל ל-/var/log/audit/audit.log. בגרסה 4.0.3 (2025-2026) התווספו שיפורים לא רעים בכלל: תמיכה בארכיטקטורת RISC-V, יכולת הגדרת דוחות מצב מחזוריים (state reports), ועדכון טבלאות system calls עד ליבה 6.19.

auditctl — כלי ניהול הכללים

הכלי שמאפשר להוסיף, למחוק ולשנות כללי ביקורת בזמן ריצה. מאוד שימושי ל-debugging ובדיקות, אבל — וזה חשוב — שינויים שנעשים עם auditctl הם זמניים ונעלמים אחרי אתחול. לשינויים קבועים, צריך לכתוב לקבצי הכללים.

ausearch ו-aureport — חיפוש ודיווח

ausearch מאפשר חיפוש ממוקד בלוגים לפי מפתח, משתמש, טווח זמנים וסוג אירוע. aureport מייצר דוחות מסכמים שמזהים דפוסים ואנומליות. שני הכלים האלה הם קריטיים לעבודה יומיומית עם מערכת הביקורת, ונגיע אליהם בהמשך עם דוגמאות מעשיות.

audispd — שילוח אירועים בזמן אמת

ה-Event Dispatcher שמאפשר להעביר אירועים בזמן אמת לצרכנים חיצוניים — כמו מערכות SIEM, סקריפטים מותאמים, או plugins. בגרסאות האחרונות, התור של audispd שוכתב מחדש למנגנון lockless שמשפר ביצועים בצורה משמעותית. אם אתם עובדים עם Elastic או Splunk, זה הרכיב שמחבר את auditd לשאר המערכת שלכם.

התקנה ותצורה בסיסית

ברוב ההפצות, auditd מגיע מותקן מראש (במיוחד ב-RHEL, CentOS, AlmaLinux ו-Rocky Linux). אם לא — ההתקנה ממש פשוטה:

# RHEL/CentOS/Fedora
sudo dnf install audit audit-libs

# Ubuntu/Debian
sudo apt install auditd audispd-plugins

# Verify installation and enable at boot
sudo systemctl enable --now auditd
sudo systemctl status auditd

קובץ תצורה ראשי — auditd.conf

קובץ התצורה הראשי נמצא ב-/etc/audit/auditd.conf. הנה תצורה שמותאמת ל-production — עם הסברים לכל פרמטר שחשוב להבין:

# /etc/audit/auditd.conf — Production-Ready Configuration

# Log file location — preferably on a dedicated partition
log_file = /var/log/audit/audit.log
log_format = ENRICHED

# Log rotation
num_logs = 10
max_log_file = 50
max_log_file_action = ROTATE

# Buffer and backlog — critical for performance
flush = INCREMENTAL_ASYNC
freq = 50
disp_qos = lossy

# Space management
space_left = 150
space_left_action = SYSLOG
admin_space_left = 75
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

# Network options (for remote logging)
tcp_listen_queue = 5
tcp_max_per_addr = 1
tcp_client_max_idle = 0

# Priority boost — keep auditd running even under load
priority_boost = 4

נקודה שכדאי לשים לב אליה: הפורמט ENRICHED מוסיף מידע מפוענח ישירות ללוגים (כמו שמות משתמשים במקום UID בלבד), מה שמקל משמעותית על ניתוח. ב-production, השתמשו ב-INCREMENTAL_ASYNC כמצב flush — הוא נותן את האיזון הטוב ביותר בין ביצועים לאמינות.

כתיבת כללי ביקורת: מהבסיס למתקדם

אוקיי, הגענו לחלק המעניין. כללי auditd מתחלקים לשלושה סוגים עיקריים, וחשוב להבין את ההבדלים ביניהם לפני שמתחילים לכתוב כללים:

1. כללי בקרה (Control Rules)

כללים שמגדירים את התנהגות המערכת עצמה. אלה תמיד צריכים להופיע ראשונים:

# Delete all existing rules (always first!)
-D

# Set buffer size — increase for high-traffic systems
-b 8192

# Set backlog wait time in milliseconds
--backlog_wait_time 60000

# Set failure mode: 0=silent, 1=printk, 2=panic
-f 1

2. כללי מעקב אחר קבצים (File Watch Rules)

כללים שמנטרים גישה ושינויים בקבצים ותיקיות ספציפיים. הם הסוג הכי פשוט לכתיבה, ולרוב גם הכי שימושי בהתחלה:

# Syntax: -w [path] -p [permissions] -k [key]
# Permissions: r=read, w=write, x=execute, a=attribute change

# Monitor identity files
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# Monitor SSH configuration
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d -p wa -k sshd_config

# Monitor sudo configuration
-w /etc/sudoers -p wa -k sudo_changes
-w /etc/sudoers.d -p wa -k sudo_changes

# Monitor PAM configuration
-w /etc/pam.d -p wa -k pam_changes

# Monitor cron jobs
-w /etc/crontab -p wa -k cron_changes
-w /etc/cron.d -p wa -k cron_changes
-w /var/spool/cron -p wa -k cron_changes

3. כללי System Calls

הסוג המתקדם ביותר — מנטר קריאות מערכת ספציפיות. זה נותן לכם את השליטה הכי מדויקת, אבל גם דורש יותר משאבים (וזהירות — כלל גנרי מדי יכול להציף את הלוגים):

# Syntax: -a [action,list] -S [syscall] -F [filter] -k [key]
# Actions: always/never | Lists: task/exit/user/exclude

# Monitor process execution — THE most important rule
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

# Monitor file deletion by non-root users
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -k delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -k delete

# Monitor failed file access attempts
-a always,exit -F arch=b64 -S open,openat,creat,truncate,ftruncate -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open,openat,creat,truncate,ftruncate -F exit=-EPERM -k access_denied

# Monitor permission changes
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=4294967295 -k owner_mod

# Monitor kernel module operations
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules

# Monitor mount operations
-a always,exit -F arch=b64 -S mount,umount2 -F auid>=1000 -F auid!=4294967295 -k mounts

# Monitor time changes
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change
-w /etc/localtime -p wa -k time_change

שימו לב לפילטר auid!=4294967295 — ערך זה (שווה ל--1 בייצוג unsigned) מסנן תהליכים שלא עברו login כמשתמש אנושי, כלומר שירותי מערכת. בלי הפילטר הזה, תקבלו הצפה של אירועים לא רלוונטיים. למדתי את זה בדרך הקשה.

כללים תואמי CIS Benchmark ו-STIG

ארגונים שצריכים לעמוד בתקני אבטחה כמו CIS Benchmarks, DISA STIG או PCI-DSS צריכים מערך כללים מקיף ומובנה. הגישה המומלצת ב-2026 היא לארגן את הכללים בקבצים נפרדים תחת /etc/audit/rules.d/, כשכל קובץ מכסה תחום ספציפי.

הנה המבנה שאני ממליץ עליו:

# View the recommended file structure
ls /etc/audit/rules.d/
# 10-base-config.rules      — Initial setup, buffer, backlog
# 30-actions.rules           — Monitor sudo activity
# 31-usergroup-mod.rules     — User and group changes
# 32-elevated-priv.rules     — Elevated privilege commands
# 33-access.rules            — Failed access attempts
# 34-delete.rules            — File deletion operations
# 35-logins.rules            — Login tracking
# 36-session.rules           — Session file monitoring
# 71-mac-policy.rules        — MAC policy changes
# 72-maintenance.rules       — Maintenance activities
# 73-modules.rules           — Kernel module operations
# 74-perm-mod.rules          — Permission modifications
# 75-privileged.rules        — Privileged command execution
# 78-time-change.rules       — System time changes
# 99-finalize.rules          — Lock rules (immutable)

הסדר חשוב — הקבצים נטענים לפי סדר מספרי, ואת כללי ה-exclusion צריך לשים בתחילת הרשימה.

יצירת קובץ כללים לפקודות מיוחסות (Privileged Commands)

דרישה מרכזית של CIS Benchmark היא ניטור כל הפקודות שמוגדרות עם SUID/SGID. במקום לכתוב את זה ידנית (ויש הרבה כאלה), הנה סקריפט שמייצר את הכללים באופן אוטומטי:

#!/bin/bash
# Generate audit rules for all SUID/SGID binaries
# Run this script and redirect output to a rules file

OUTPUT_FILE="/etc/audit/rules.d/75-privileged.rules"
echo "# CIS Benchmark — Privileged Command Monitoring" > "$OUTPUT_FILE"
echo "# Auto-generated on $(date -u +%Y-%m-%dT%H:%M:%SZ)" >> "$OUTPUT_FILE"

# Find all SUID/SGID binaries and create rules
for PARTITION in $(findmnt -n -l -k -it ext4,xfs,btrfs -o TARGET); do
    find "$PARTITION" -xdev \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null | \
    while read -r BINARY; do
        echo "-a always,exit -F path=$BINARY -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged" >> "$OUTPUT_FILE"
    done
done

echo "Generated $(wc -l < "$OUTPUT_FILE") rules"

טיפ: הריצו את הסקריפט הזה אחרי כל עדכון מערכת — חבילות חדשות עלולות להוסיף קבצי SUID שלא היו קודם.

קובץ הסיום — נעילת הכללים

הקובץ 99-finalize.rules הוא קריטי. הוא נועל את כל כללי הביקורת ומונע שינויים בזמן ריצה — ברגע שהוא נטען, אי אפשר לשנות כללים בלי לאתחל את המכונה:

# /etc/audit/rules.d/99-finalize.rules
# Make the audit configuration immutable
# This MUST be the last rule loaded
-e 2

אזהרה חשובה: אל תפעילו את המצב הזה לפני שסיימתם לכוונן את הכללים. ברגע ש--e 2 פעיל, כל שינוי דורש אתחול מלא. בשלב פיתוח הכללים? השאירו אותו מושבת. רציני.

זיהוי איומים עם MITRE ATT&CK: כללים ממופים לטקטיקות תקיפה

אז הנה הדבר שבאמת הופך את auditd מכלי לוגינג רגיל למערכת זיהוי איומים אמיתית: מיפוי כללים ישירות ל-MITRE ATT&CK Framework. כשעושים את זה נכון, אתם לא רק רושמים אירועים — אתם מבינים מה התוקף מנסה להשיג.

הנה כללים ממופים לטקטיקות ה-ATT&CK הנפוצות ביותר:

TA0002 — Execution (הרצה)

# T1059 — Command and Scripting Interpreter
# Monitor execution of scripting engines
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/python3 -k T1059_python
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/perl -k T1059_perl
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ruby -k T1059_ruby
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/bash -k T1059_bash

# T1053 — Scheduled Task/Job
-w /etc/crontab -p wa -k T1053_cron
-w /etc/cron.d -p wa -k T1053_cron
-w /var/spool/cron -p wa -k T1053_cron
-w /etc/anacrontab -p wa -k T1053_cron
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/at -k T1053_at

TA0003 — Persistence (התמדה)

# T1543 — Create or Modify System Process
-w /etc/systemd/system -p wa -k T1543_systemd
-w /usr/lib/systemd/system -p wa -k T1543_systemd
-w /run/systemd/system -p wa -k T1543_systemd

# T1546 — Event Triggered Execution
-w /etc/profile -p wa -k T1546_profile
-w /etc/profile.d -p wa -k T1546_profile
-w /etc/bashrc -p wa -k T1546_bashrc
-w /home -p wa -k T1546_user_profile

# T1136 — Create Account
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/useradd -k T1136_create_user
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/adduser -k T1136_create_user

TA0005 — Defense Evasion (חמיקה מהגנות)

זה אולי החלק הכי חשוב — לזהות מתי תוקף מנסה לכסות את העקבות שלו:

# T1562 — Impair Defenses
# Monitor attempts to disable auditd itself!
-w /etc/audit -p wa -k T1562_audit_config
-w /etc/audit/auditd.conf -p wa -k T1562_audit_config
-w /etc/audit/rules.d -p wa -k T1562_audit_rules
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/auditctl -k T1562_auditctl

# T1070 — Indicator Removal (log tampering)
-w /var/log/audit -p wa -k T1070_log_tampering
-w /var/log/messages -p wa -k T1070_log_tampering
-w /var/log/syslog -p wa -k T1070_log_tampering
-w /var/log/auth.log -p wa -k T1070_log_tampering
-w /var/log/secure -p wa -k T1070_log_tampering

# T1014 — Rootkit Detection
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k T1014_rootkit

TA0006 — Credential Access (גישה לאישורים)

# T1003 — OS Credential Dumping
-w /etc/shadow -p r -k T1003_credential_access
-w /etc/security/opasswd -p r -k T1003_credential_access

# T1552 — Unsecured Credentials
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/find -F auid>=1000 -k T1552_cred_search

# T1110 — Brute Force Detection
-w /var/log/faillog -p r -k T1110_bruteforce
-w /var/log/lastlog -p r -k T1110_bruteforce

זיהוי LOTL — Living off the Land

אם יש נושא אחד שממש שווה לתת לו תשומת לב מיוחדת, זה LOTL. טקטיקות Living off the Land הן מהאיומים המסוכנים ביותר שיש — תוקפים שמשתמשים בכלים לגיטימיים שכבר קיימים על המערכת כדי לבצע את המתקפה. אין malware חדש, אין קבצים חשודים. רק כלי מערכת רגילים שפועלים בצורה לא רגילה.

ב-2025, סוכנויות מודיעין מובילות — כולל ASD/ACSC (אוסטרליה), CISA, FBI, NSA וה-NCSC הבריטי — פרסמו המלצות משותפות לזיהוי LOTL עם auditd. הנה הכללים המרכזיים:

# LOTL — Network reconnaissance tools
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/curl -k lotl_network
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/wget -k lotl_network
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/nc -k lotl_network
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ncat -k lotl_network
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ssh -k lotl_network

# LOTL — Data exfiltration tools
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/scp -k lotl_exfil
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/rsync -k lotl_exfil
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/sftp -k lotl_exfil
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/base64 -k lotl_exfil

# LOTL — Compilation and code execution
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/gcc -k lotl_compile
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/g++ -k lotl_compile
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/make -k lotl_compile

# LOTL — System enumeration
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/whoami -k lotl_enum
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/id -k lotl_enum
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/hostname -k lotl_enum
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/uname -k lotl_enum
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ifconfig -k lotl_enum
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/ip -k lotl_enum

חיפוש וניתוח אירועים: שליטה ב-ausearch ו-aureport

כללי ביקורת הם רק חצי מהסיפור. החצי השני — ואולי הקריטי יותר ביום-יום — הוא היכולת לחפש, לנתח ולהבין את האירועים שנרשמו.

בואו נעבור על הפקודות שכל מנהל מערכת חייב להכיר:

ausearch — חיפוש ממוקד

# Search by key — find all events tagged with a specific rule
sudo ausearch -k identity -ts recent

# Search by user — find all actions by a specific user (use auid!)
sudo ausearch -ua 1001 -ts today

# Search failed access attempts
sudo ausearch -k access_denied -ts today -i

# Search for specific system calls
sudo ausearch -sc execve -ts today --just-one

# Search for events in a time range
sudo ausearch -ts 03/01/2026 09:00:00 -te 03/01/2026 17:00:00 -k exec

# Search for specific file access
sudo ausearch -f /etc/shadow -i

# Combine filters — specific user + specific key + time range
sudo ausearch -ua 1001 -k sudo_changes -ts recent -i

הפלאג -i (interpret) מפענח UID/GID/syscalls לשמות קריאים — השתמשו בו תמיד כשאתם מנתחים ידנית. ו--ts recent? מציג אירועים מ-10 הדקות האחרונות. מאוד נוח לבדיקות מהירות.

aureport — דוחות מסכמים

# Summary report — overview of all events
sudo aureport --summary

# Authentication report — login successes and failures
sudo aureport --auth -ts today

# Failed authentication attempts
sudo aureport --auth --failed -ts today

# Executable events report
sudo aureport -x -ts today

# File access report
sudo aureport -f -ts today

# Anomaly report — detect suspicious patterns
sudo aureport --anomaly

# Key summary — which rules generated the most events
sudo aureport -k -ts today --summary

טיפ שחוסך הרבה כאב ראש: הריצו aureport -k --summary בכל בוקר. אם כלל מסוים מייצר מספר מוגזם של אירועים — זה או שצריך לכוונן אותו עם יותר פילטרים, או שמשהו חריג באמת קורה על המערכת. בכל מקרה, שווה לבדוק.

כיוונון ביצועים ל-Production

הנה האמת שלא הרבה מדריכים אומרים לכם: auditd עם תצורה אגרסיבית יכול להוסיף 10-15% לניצולת ה-CPU ולייצר כמויות עצומות של I/O לדיסק. ראיתי שרתים שהפכו לעצלנים רק בגלל כללי auditd גנריים מדי.

ב-production, צריך לכוונן בקפידה.

עקרונות מפתח לכיוונון

# STEP 1: Benchmark BEFORE adding rules
# Run a baseline performance test
perf stat -a sleep 30 2>&1 | tee /tmp/audit_baseline.txt

# STEP 2: Identify noisy rules with aureport
sudo aureport -k --summary -ts today
# Look for rules generating thousands of events

# STEP 3: Add exclusions for known-safe processes AT THE TOP
# Place these BEFORE all other rules in 10-base-config.rules

# Exclude specific system services from exec monitoring
-a never,exit -F arch=b64 -S execve -F exe=/usr/lib/systemd/systemd -k exclude
-a never,exit -F arch=b64 -S execve -F exe=/usr/sbin/chronyd -k exclude

# Exclude high-frequency network connections (e.g., web server)
-a never,exit -F arch=b64 -S connect -F exe=/usr/sbin/nginx -k exclude

# STEP 4: Use precise filters instead of broad rules
# BAD — monitors ALL file opens (millions of events per hour)
# -a always,exit -F arch=b64 -S open -k file_open

# GOOD — monitors file opens only by human users, only failures
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k file_access_denied

המלצות לשרתי Production

אחסנו לוגים על SSD: הכתיבה הרציפה של auditd מכבידה על דיסקים מכניים (HDD). SSD מפחית משמעותית את ה-latency ואת העומס הכללי על ה-I/O.
הפרידו את מחיצת הלוגים: הגדירו /var/log/audit על mount point נפרד — זה מונע מהלוגים למלא את מערכת הקבצים הראשית ומאפשר זיהוי מדויק של שטח פנוי.
השתמשו ב-INCREMENTAL_ASYNC: מצב ה-flush הזה מאגד כתיבות לדיסק ומפחית עומס I/O, בלי לוותר על אמינות.
הגבילו את גודל ה-backlog: ערך -b 8192 מספיק לרוב המערכות. ערכים גבוהים מדי צורכים זיכרון קרנל מיותר.
עקבו אחר auditd_lost: הפקודה auditctl -s מציגה את מספר האירועים שאבדו. אם המספר עולה — יש צוואר בקבוק ואתם מפספסים אירועים.

# Monitor audit health metrics
sudo auditctl -s
# Look for:
#   lost = 0        (events that were dropped)
#   backlog = ...   (current queue depth)
#   enabled = 2     (immutable mode active)

# If lost > 0, increase buffer:
# sudo auditctl -b 16384

אינטגרציה עם מערכות SIEM

auditd לבד נותן ראות מצוינת על מכונה בודדת, אבל בסביבה ארגונית זה לא מספיק. אתם צריכים לרכז את הלוגים ולנתח אותם בהקשר רחב יותר — ולזה בדיוק נועדה אינטגרציה עם SIEM.

שימוש ב-audisp plugin לשילוח לוגים

# /etc/audit/plugins.d/syslog.conf
# Forward audit events to syslog (then to SIEM via rsyslog)
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
args = LOG_LOCAL6
format = string

תצורת rsyslog להעברה מרוכזת

# /etc/rsyslog.d/audit-forward.conf
# Forward audit logs to central SIEM server

# Define template for audit events
template(name="AuditFormat" type="string"
    string="%HOSTNAME% %msg%\n"
)

# Send audit events via TCP (reliable delivery)
local6.* action(
    type="omfwd"
    target="siem.company.local"
    port="514"
    protocol="tcp"
    action.resumeRetryCount="-1"
    queue.type="LinkedList"
    queue.filename="audit_fwd"
    queue.maxDiskSpace="1g"
    queue.saveOnShutdown="on"
    template="AuditFormat"
)

אינטגרציה עם Elastic Stack

אם אתם עובדים עם Elastic (וב-2026, רבים כן), יש Auditd Manager Integration שמקלה משמעותית על ניהול כללי auditd בקנה מידה גדול. האינטגרציה מקבלת אירועי ביקורת ישירות מה-Linux Audit Framework ומזרימה אותם ל-Elasticsearch לניתוח ו-visualization ב-Kibana:

# Filebeat configuration for audit logs
# /etc/filebeat/filebeat.yml

filebeat.modules:
  - module: auditd
    log:
      enabled: true
      var.paths:
        - /var/log/audit/audit.log*

output.elasticsearch:
  hosts: ["https://elasticsearch.company.local:9200"]
  ssl.certificate_authorities: ["/etc/pki/tls/certs/ca.crt"]
  index: "auditd-%{+yyyy.MM.dd}"

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~

סקריפט ביקורת מקיף: בדקו את המצב שלכם

לפני שמסכמים, הנה סקריפט שנתתי הכי הרבה ערך בעבודה שלי — הוא בודק את מצב מערכת הביקורת שלכם ומזהה פערים מול דרישות CIS. שווה להריץ אותו אחרי כל שינוי בכללים:

#!/bin/bash
# audit-health-check.sh — Comprehensive auditd health verification
# Run as root

echo "========================================"
echo " auditd Health Check — $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "========================================"

# 1. Check if auditd is running
echo -e "\n[1] Service Status:"
if systemctl is-active --quiet auditd; then
    echo "  OK: auditd is running"
else
    echo "  FAIL: auditd is NOT running — CRITICAL"
fi

# 2. Check audit system status
echo -e "\n[2] Audit System Status:"
AUDIT_STATUS=$(auditctl -s)
echo "$AUDIT_STATUS" | while IFS= read -r line; do
    echo "  $line"
done

LOST=$(echo "$AUDIT_STATUS" | awk '/lost/' | awk -F= '{print $2}')
if [ "$LOST" -gt 0 ] 2>/dev/null; then
    echo "  WARNING: $LOST audit events have been lost!"
fi

# 3. Count active rules
echo -e "\n[3] Active Rules:"
RULE_COUNT=$(auditctl -l | wc -l)
echo "  Total rules loaded: $RULE_COUNT"

# 4. Check for immutable mode
echo -e "\n[4] Immutable Mode:"
ENABLED=$(echo "$AUDIT_STATUS" | awk '/enabled/' | awk -F= '{print $2}')
if [ "$ENABLED" = "2" ]; then
    echo "  OK: Audit rules are immutable (locked)"
else
    echo "  WARNING: Audit rules are NOT immutable"
fi

# 5. Check log file size and rotation
echo -e "\n[5] Log Storage:"
if [ -f /var/log/audit/audit.log ]; then
    LOG_SIZE=$(du -sh /var/log/audit/audit.log | awk '{print $1}')
    LOG_COUNT=$(ls /var/log/audit/audit.log* 2>/dev/null | wc -l)
    echo "  Current log size: $LOG_SIZE"
    echo "  Log files: $LOG_COUNT"
fi

# 6. Check CIS-required rules
echo -e "\n[6] CIS Benchmark Rule Coverage:"
declare -A RULES=(
    ["/etc/passwd"]="Identity file monitoring"
    ["/etc/shadow"]="Shadow file monitoring"
    ["/etc/sudoers"]="Sudo config monitoring"
    ["execve"]="Process execution monitoring"
    ["modules"]="Kernel module monitoring"
    ["time_change"]="Time change monitoring"
)

for pattern in "${!RULES[@]}"; do
    if auditctl -l | grep -q "$pattern"; then
        echo "  OK: ${RULES[$pattern]}"
    else
        echo "  MISSING: ${RULES[$pattern]}"
    fi
done

echo -e "\n========================================"
echo " Health check complete"
echo "========================================"

שאלות נפוצות (FAQ)

מה ההבדל בין auditd ל-syslog ולמה צריך את שניהם?

שאלה טובה, ומתבקשת. syslog (ומימושים כמו rsyslog ו-journald) אוספים לוגים מאפליקציות ושירותים — הודעות שגיאה, אירועי התחברות, לוגים של שירותי רשת. auditd עובד ברמה אחרת לגמרי — הוא מנטר system calls ברמת הקרנל.

בפועל? syslog יגיד לכם ש-SSH login נכשל. auditd יגיד לכם בדיוק אילו קבצים המשתמש ניסה לגשת אליהם, אילו פקודות הריץ, ואילו הרשאות ניסה לשנות. בסביבת production רצינית אתם צריכים את שניהם — syslog לניטור כללי ו-auditd לביקורת אבטחה מעמיקה.

האם auditd משפיע על ביצועי המערכת ואיך ממזערים את ההשפעה?

כן, auditd יכול להוסיף 10-15% לניצולת ה-CPU עם תצורת אבטחה מלאה. זה לא מעט. שלוש הדרכים העיקריות למזער את ההשפעה: (1) כתבו כללי exclusion ממוקדים עבור תהליכים רועשים ידועים ושימו אותם בראש קובץ הכללים, (2) השתמשו בפילטרים מדויקים — auid, uid, exe — כדי לצמצם את היקף הניטור, ו-(3) אחסנו את לוגי הביקורת על SSD במחיצה ייעודית.

איך auditd עוזר לעמוד בתקני PCI-DSS ו-HIPAA?

PCI-DSS דורש ניטור גישה לנתוני כרטיסי אשראי ומעקב אחר פעולות אדמיניסטרטיביות — auditd מספק בדיוק את זה דרך כללי file watch ו-syscall monitoring. HIPAA דורש תיעוד ביקורת למערכות שמטפלות במידע רפואי מוגן — auditd מתעד גישות לקבצים, שינויי הרשאות ופעולות משתמשים.

בשני המקרים, השילוב של auditd עם CIS Benchmarks נותן כיסוי מקיף שעומד בדרישות הביקורת. זה לא מבטיח תאימות מלאה (יש עוד דרישות מעבר ללוגינג), אבל זה חלק משמעותי מהפאזל.

האם auditd יכול לזהות rootkits ואיומים מתקדמים?

auditd יכול לזהות סימנים של rootkits — למשל, טעינת מודולי קרנל לא מוכרים (init_module), שינויים בקבצי מערכת קריטיים, או הרצת פקודות חשודות. אבל חשוב להגיד — הוא לא כלי anti-rootkit ייעודי.

עם כללים ממופים ל-MITRE ATT&CK (כמו אלה שהצגנו למעלה), auditd מזהה את הפעולות שתוקפים עושים — גם אם הם משתמשים בכלים לגיטימיים (LOTL). לזיהוי rootkits ייעודי, שלבו auditd עם כלים כמו OSSEC, Wazuh או rkhunter.

איך מנהלים כללי auditd בקנה מידה של מאות שרתים?

ניהול ידני של כללים על מאות שרתים פשוט לא ישתלם — זה מתכון לשגיאות וחוסר עקביות. הגישות המומלצות ב-2026: (1) ניהול תצורה עם Ansible — הגדירו כללי auditd כקוד ב-playbooks ושלחו אותם לכל השרתים באופן אוטומטי, (2) OpenSCAP — סרקו באופן אוטומטי מול CIS Benchmarks וייצרו דוחות תאימות, ו-(3) Policy-as-Code — שלבו את כללי auditd ב-CI/CD pipeline כך שכל שרת חדש מקבל תצורת ביקורת תקנית כחלק מתהליך ה-provisioning.