บทนำ: ทำไม Wazuh ถึงเป็นเครื่องมือตรวจจับการบุกรุกที่ทุกองค์กรต้องมีในปี 2026
ถ้าคุณเป็น System Administrator หรือ Security Engineer ที่ดูแลเซิร์ฟเวอร์ Linux มาสักพัก คำถามที่ต้องตอบให้ได้คือ "ตอนนี้มีใครกำลังพยายามเจาะระบบของเราอยู่หรือเปล่า?" คำตอบที่น่ากลัวก็คือ... ใช่ครับ เกือบตลอดเวลาเลย
จากสถิติปี 2025 เซิร์ฟเวอร์ Linux ที่เปิด SSH ออกสู่อินเทอร์เน็ตจะถูก brute-force โจมตีภายในไม่กี่นาทีหลังจาก deploy เลยนะครับ ไม่ใช่หลายชั่วโมง — ไม่กี่นาทีจริงๆ
นี่คือเหตุผลที่ระบบตรวจจับการบุกรุก (Intrusion Detection System — IDS) ไม่ใช่แค่ "nice-to-have" อีกต่อไป แต่เป็น สิ่งจำเป็นสำหรับทุกระบบที่ต้องการความปลอดภัย และในบรรดาเครื่องมือ IDS ทั้งหมดที่มีอยู่ตอนนี้ Wazuh คือตัวเลือกที่โดดเด่นที่สุดในปี 2026 ด้วยเหตุผลหลายประการ:
- ฟรีและโอเพนซอร์ส — ไม่มีค่าใช้จ่ายแม้แต่บาทเดียว ไม่มี feature gating แบบที่หลาย commercial tools ชอบทำ
- รวมทุกอย่างในที่เดียว — HIDS, SIEM, Vulnerability Detection, File Integrity Monitoring, Compliance Auditing ครบจบในตัวเดียว
- พัฒนาอย่างต่อเนื่อง — เวอร์ชันล่าสุด 4.14.3 เพิ่งปล่อยเมื่อ 11 กุมภาพันธ์ 2026
- รองรับ eBPF — ตั้งแต่เวอร์ชัน 4.12 เป็นต้นมา FIM module ใช้ eBPF สำหรับการตรวจจับแบบ real-time ที่เร็วขึ้นมาก
- Scale ได้ — รองรับตั้งแต่เซิร์ฟเวอร์เดียวไปจนถึงหลายหมื่นเครื่อง
บทความนี้จะพาคุณผ่านทุกขั้นตอนตั้งแต่การทำความเข้าใจสถาปัตยกรรมของ Wazuh, การติดตั้งทั้ง Server และ Agent, การตั้งค่า FIM, การเขียน Custom Rules, Active Response ไปจนถึงการสแกนช่องโหว่และ compliance — ทั้งหมดพร้อมคำสั่งที่ใช้งานได้จริงทุกบรรทัดครับ
ทำความเข้าใจสถาปัตยกรรมของ Wazuh
ภาพรวม Components ทั้งหมด
ก่อนจะลงมือติดตั้ง เรามาทำความเข้าใจกันก่อนว่า Wazuh ประกอบด้วย 4 components หลักที่ทำงานร่วมกัน:
- Wazuh Agent — โปรแกรมขนาดเล็กที่ติดตั้งบนเครื่องที่ต้องการมอนิเตอร์ ทำหน้าที่เก็บข้อมูล log, ตรวจสอบ file integrity, สแกนหา malware และ rootkit แล้วส่งข้อมูลกลับไปยัง Wazuh Server
- Wazuh Server (Manager) — ถือว่าเป็นสมองกลของระบบเลย รับข้อมูลจาก agents มาวิเคราะห์ผ่าน decoders และ rules สร้าง security alerts แล้วก็สั่ง active responses
- Wazuh Indexer — เป็น search engine (ใช้ OpenSearch เป็น backend) สำหรับจัดเก็บและ index alerts ให้สามารถค้นหาได้อย่างรวดเร็ว
- Wazuh Dashboard — web interface สำหรับดู security events, alerts, vulnerabilities และ compliance reports แบบ visual ที่ใช้งานง่าย
การสื่อสารระหว่าง Components
Ports สำคัญที่ต้องเปิดมีดังนี้ (จดไว้เลยครับ จะได้ไม่ต้องมานั่งงงทีหลังว่าทำไมเชื่อมต่อไม่ได้):
- 1514/TCP — Agent ส่ง events ไปยัง Server
- 1515/TCP — Agent enrollment (ลงทะเบียน agent ใหม่)
- 1516/TCP — Cluster daemon (สำหรับ multi-node deployment)
- 55000/TCP — Wazuh RESTful API
- 9200/TCP — Indexer RESTful API
- 443/TCP — Dashboard web interface (HTTPS)
ติดตั้ง Wazuh Server แบบ All-in-One บน Ubuntu/Debian
System Requirements
สำหรับการติดตั้งแบบ All-in-One (ทุก component อยู่บนเครื่องเดียว) ซึ่งเหมาะกับการใช้งานขนาดเล็กถึงกลาง — agent ไม่เกินสัก 100 ตัว — ข้อกำหนดขั้นต่ำคือ:
- CPU: 4 cores
- RAM: 8 GB (แนะนำ 16 GB ถ้าเป็นไปได้)
- Disk: 50 GB SSD ขึ้นไป
- OS: Ubuntu 22.04/24.04 LTS, Debian 11/12, CentOS 8/9, RHEL 8/9
วิธีที่ 1: ติดตั้งด้วย Installation Assistant (แนะนำ)
วิธีที่ง่ายและเร็วที่สุดคือใช้ official installation assistant ที่จะติดตั้งทุก component ให้อัตโนมัติ พูดตรงๆ คือถ้าแค่อยากลองใช้งานหรือเป็น environment ที่ไม่ได้ซับซ้อนมาก วิธีนี้สะดวกสุดแล้ว:
# อัปเดตระบบก่อน
sudo apt update && sudo apt upgrade -y
# ติดตั้ง dependencies
sudo apt install -y curl apt-transport-https unzip wget
# ดาวน์โหลดและรัน installation assistant
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a
เมื่อการติดตั้งเสร็จสมบูรณ์ script จะแสดง URL สำหรับเข้า Dashboard พร้อม username และ password เริ่มต้น อย่าลืมบันทึก credentials เหล่านี้ไว้นะครับ! เพราะจะไม่แสดงซ้ำอีก
# ตัวอย่าง output หลังติดตั้งสำเร็จ:
# INFO: --- Summary ---
# INFO: You can access the web interface https://:443
# User: admin
# Password:
# INFO: Installation finished.
วิธีที่ 2: ติดตั้งแบบ Step-by-Step (สำหรับ Production)
สำหรับ production environment ที่ต้องการ customize การตั้งค่าจริงจัง แนะนำให้ติดตั้งแต่ละ component แยกกัน ยาวหน่อยแต่คุ้มครับ เพราะคุณจะเข้าใจทุกส่วนของระบบ
ขั้นตอนที่ 1 — เตรียม SSL Certificates
# ดาวน์โหลด certificate generation tool
curl -sO https://packages.wazuh.com/4.14/wazuh-certs-tool.sh
curl -sO https://packages.wazuh.com/4.14/config.yml
# แก้ไข config.yml ให้ตรงกับ IP ของเซิร์ฟเวอร์
# ตัวอย่าง config.yml สำหรับ single-node:
# nodes:
# indexer:
# - name: node-1
# ip:
# server:
# - name: wazuh-1
# ip:
# dashboard:
# - name: dashboard
# ip:
# สร้าง certificates
sudo bash ./wazuh-certs-tool.sh -A
sudo tar -cvf ./wazuh-certificates.tar -C ./wazuh-certificates/ .
sudo rm -rf ./wazuh-certificates
ขั้นตอนที่ 2 — ติดตั้ง Wazuh Indexer
# เพิ่ม Wazuh GPG key
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring \
--keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
# เพิ่ม repository
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | \
sudo tee -a /etc/apt/sources.list.d/wazuh.list
# ติดตั้ง Wazuh Indexer
sudo apt update
sudo apt install -y wazuh-indexer
# ตั้งค่า vm.max_map_count สำหรับ OpenSearch
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
sudo sysctl -w vm.max_map_count=262144
# คัดลอก certificates
NODE_NAME=node-1
sudo mkdir -p /etc/wazuh-indexer/certs
sudo tar -xf ./wazuh-certificates.tar -C /etc/wazuh-indexer/certs/ ./$NODE_NAME.pem ./$NODE_NAME-key.pem ./admin.pem ./admin-key.pem ./root-ca.pem
sudo mv -n /etc/wazuh-indexer/certs/$NODE_NAME.pem /etc/wazuh-indexer/certs/indexer.pem
sudo mv -n /etc/wazuh-indexer/certs/$NODE_NAME-key.pem /etc/wazuh-indexer/certs/indexer-key.pem
sudo chmod 500 /etc/wazuh-indexer/certs
sudo chmod 400 /etc/wazuh-indexer/certs/*
sudo chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs
# เริ่มต้น service
sudo systemctl daemon-reload
sudo systemctl enable wazuh-indexer
sudo systemctl start wazuh-indexer
# Initialize security settings
sudo /usr/share/wazuh-indexer/bin/indexer-security-init.sh
ขั้นตอนที่ 3 — ติดตั้ง Wazuh Server
# ติดตั้ง Wazuh Manager
sudo apt install -y wazuh-manager
# เริ่มต้น service
sudo systemctl daemon-reload
sudo systemctl enable wazuh-manager
sudo systemctl start wazuh-manager
# ตรวจสอบสถานะ
sudo systemctl status wazuh-manager
# ติดตั้ง Filebeat
sudo apt install -y filebeat
# ดาวน์โหลด Filebeat config สำหรับ Wazuh
curl -so /etc/filebeat/filebeat.yml \
https://packages.wazuh.com/4.14/tpl/wazuh/filebeat/filebeat.yml
# ดาวน์โหลด alerts template
curl -so /etc/filebeat/wazuh-template.json \
https://raw.githubusercontent.com/wazuh/wazuh/v4.14.3/extensions/elasticsearch/7.x/wazuh-template.json
# ติดตั้ง Wazuh module สำหรับ Filebeat
curl -s https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.4.tar.gz | \
sudo tar -xvz -C /usr/share/filebeat/module
# คัดลอก certificates สำหรับ Filebeat
sudo cp ./wazuh-certificates.tar /etc/filebeat/
cd /etc/filebeat
sudo tar -xf wazuh-certificates.tar ./wazuh-1.pem ./wazuh-1-key.pem ./root-ca.pem
sudo mv wazuh-1.pem filebeat.pem
sudo mv wazuh-1-key.pem filebeat-key.pem
sudo chmod 400 /etc/filebeat/*.pem
# เริ่มต้น Filebeat
sudo systemctl enable filebeat
sudo systemctl start filebeat
ขั้นตอนที่ 4 — ติดตั้ง Wazuh Dashboard
# ติดตั้ง Dashboard
sudo apt install -y wazuh-dashboard
# คัดลอก certificates
NODE_NAME=dashboard
sudo mkdir -p /etc/wazuh-dashboard/certs
sudo tar -xf ./wazuh-certificates.tar -C /etc/wazuh-dashboard/certs/ ./$NODE_NAME.pem ./$NODE_NAME-key.pem ./root-ca.pem
sudo mv -n /etc/wazuh-dashboard/certs/$NODE_NAME.pem /etc/wazuh-dashboard/certs/dashboard.pem
sudo mv -n /etc/wazuh-dashboard/certs/$NODE_NAME-key.pem /etc/wazuh-dashboard/certs/dashboard-key.pem
sudo chmod 500 /etc/wazuh-dashboard/certs
sudo chmod 400 /etc/wazuh-dashboard/certs/*
sudo chown -R wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs
# เริ่มต้น Dashboard
sudo systemctl daemon-reload
sudo systemctl enable wazuh-dashboard
sudo systemctl start wazuh-dashboard
ติดตั้ง Wazuh Agent บนเครื่อง Linux ที่ต้องการมอนิเตอร์
ติดตั้งบน Ubuntu/Debian
ส่วนนี้ค่อนข้างตรงไปตรงมาครับ แค่เพิ่ม repo แล้วก็ install:
# เพิ่ม Wazuh GPG key
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring \
--keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
# เพิ่ม repository
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | \
sudo tee /etc/apt/sources.list.d/wazuh.list
# ติดตั้ง agent พร้อมระบุ IP ของ Wazuh Server
WAZUH_MANAGER="192.168.1.100" sudo apt update && sudo apt install -y wazuh-agent
# เริ่มต้น service
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
# ตรวจสอบสถานะ
sudo systemctl status wazuh-agent
ติดตั้งบน CentOS/RHEL/AlmaLinux
# นำเข้า GPG key
sudo rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
# เพิ่ม repository
cat > /etc/yum.repos.d/wazuh.repo << EOF
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-\$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
priority=1
EOF
# ติดตั้ง agent พร้อมระบุ IP ของ Wazuh Server
WAZUH_MANAGER="192.168.1.100" sudo yum install -y wazuh-agent
# เริ่มต้น service
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
ปิด Automatic Updates (สำคัญมาก!)
ตรงนี้สำคัญมากครับ หลายคนลืมทำแล้วมาเจอปัญหาทีหลัง หลังติดตั้งเสร็จ ควรปิด automatic updates ของ Wazuh repository ทันที เพราะถ้า agent อัปเดตไปเป็นเวอร์ชันที่ใหม่กว่า manager จะเกิดปัญหา compatibility ได้:
# สำหรับ Ubuntu/Debian
sudo sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/wazuh.list
sudo apt update
# สำหรับ CentOS/RHEL
sudo sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
ตั้งค่า File Integrity Monitoring (FIM)
FIM คืออะไรและทำไมถึงสำคัญ
File Integrity Monitoring คือความสามารถในการตรวจจับการเปลี่ยนแปลงของไฟล์บนระบบ ไม่ว่าจะเป็นการแก้ไข การสร้างใหม่ หรือการลบ
ฟีเจอร์นี้สำคัญมากเพราะถ้ามีคนเปลี่ยนแปลง /etc/passwd, /etc/shadow, /etc/ssh/sshd_config หรือไฟล์ config สำคัญอื่นๆ โดยที่คุณไม่ได้สั่ง คุณจะได้รู้ทันที ซึ่งในสถานการณ์จริง การรู้เร็ว 1 นาทีอาจหมายถึงความแตกต่างระหว่างการป้องกันได้ทันกับการถูก compromise ไปแล้ว
Wazuh 4.14 รองรับ 3 โหมดการทำงาน:
- Scheduled — สแกนตามรอบเวลาที่กำหนด (ค่าเริ่มต้น 12 ชั่วโมง) ใช้ทรัพยากรน้อยที่สุด
- Real-time — ใช้ inotify (Linux) ตรวจจับทันทีที่มีการเปลี่ยนแปลง
- Who-data — เหมือน real-time แต่เพิ่มข้อมูลว่า "ใคร" เป็นคนเปลี่ยน โดยใช้ Linux Audit system หรือ eBPF (อันนี้ผมแนะนำเลยครับ ข้อมูลที่ได้ละเอียดมาก)
การตั้งค่า FIM บน Agent
แก้ไขไฟล์ /var/ossec/etc/ossec.conf บน agent ในส่วน <syscheck>:
<syscheck>
<!-- เปิดใช้งาน FIM -->
<disabled>no</disabled>
<!-- สแกนทุก 6 ชั่วโมง (21600 วินาที) -->
<frequency>21600</frequency>
<!-- แจ้งเตือนเมื่อมีไฟล์ใหม่ถูกสร้าง -->
<alert_new_files>yes</alert_new_files>
<!-- ตรวจสอบ checksum เมื่อ agent เริ่มต้น -->
<scan_on_start>yes</scan_on_start>
<!-- ไดเรกทอรีที่ต้องการมอนิเตอร์แบบ real-time -->
<directories realtime="yes" check_all="yes">/etc</directories>
<directories realtime="yes" check_all="yes">/usr/bin</directories>
<directories realtime="yes" check_all="yes">/usr/sbin</directories>
<directories realtime="yes" check_all="yes">/sbin</directories>
<directories realtime="yes" check_all="yes">/bin</directories>
<!-- มอนิเตอร์ไฟล์ config สำคัญแบบ who-data (บอกว่าใครเปลี่ยน) -->
<directories whodata="yes">/etc/ssh</directories>
<directories whodata="yes">/etc/sudoers.d</directories>
<directories whodata="yes">/etc/cron.d</directories>
<!-- มอนิเตอร์ web root -->
<directories realtime="yes" report_changes="yes">/var/www</directories>
<!-- ไฟล์และไดเรกทอรีที่ต้องการข้ามไม่ตรวจสอบ -->
<ignore>/etc/mtab</ignore>
<ignore>/etc/hosts.deny</ignore>
<ignore>/etc/mail/statistics</ignore>
<ignore type="sregex">.log$|.swp$</ignore>
<!-- ใช้ eBPF สำหรับ who-data (Wazuh 4.12+) -->
<whodata>
<restart_audit>yes</restart_audit>
</whodata>
</syscheck>
ทดสอบ FIM
หลังตั้งค่าแล้ว ลองทดสอบดูเลยครับ สร้างไฟล์ทดสอบแล้วดูว่า Wazuh จับได้ไหม:
# สร้างไฟล์ทดสอบใน /etc
sudo touch /etc/test-fim-detection.conf
echo "test content" | sudo tee /etc/test-fim-detection.conf
# รอสักครู่แล้วตรวจสอบ alerts บน Wazuh Dashboard
# หรือดู alerts จาก command line บน Wazuh Server
sudo cat /var/ossec/logs/alerts/alerts.json | grep "test-fim"
# ลบไฟล์ทดสอบ
sudo rm /etc/test-fim-detection.conf
ตั้งค่า Vulnerability Detection
เปิดใช้งาน Vulnerability Detector
Wazuh สามารถสแกนช่องโหว่บนทุก agent โดยเปรียบเทียบ software inventory กับฐานข้อมูล CVE จากหลายแหล่ง ตั้งค่าบน Wazuh Server โดยแก้ไข /var/ossec/etc/ossec.conf:
<vulnerability-detector>
<enabled>yes</enabled>
<interval>5m</interval>
<min_full_scan_interval>6h</min_full_scan_interval>
<run_on_start>yes</run_on_start>
<!-- National Vulnerability Database -->
<provider name="nvd">
<enabled>yes</enabled>
<update_interval>1h</update_interval>
</provider>
<!-- Canonical (Ubuntu) -->
<provider name="canonical">
<enabled>yes</enabled>
<os>jammy</os>
<os>noble</os>
<update_interval>1h</update_interval>
</provider>
<!-- Debian -->
<provider name="debian">
<enabled>yes</enabled>
<os>bookworm</os>
<os>bullseye</os>
<update_interval>1h</update_interval>
</provider>
<!-- Red Hat -->
<provider name="redhat">
<enabled>yes</enabled>
<os>8</os>
<os>9</os>
<update_interval>1h</update_interval>
</provider>
</vulnerability-detector>
หลังแก้ไขแล้ว restart Wazuh Manager:
sudo systemctl restart wazuh-manager
ดูผลการสแกนช่องโหว่
ผลการสแกนจะแสดงบน Dashboard ในส่วน Vulnerability Detection โดยแบ่ง severity เป็น Critical, High, Medium, Low ในเวอร์ชัน 4.12+ จะมี CTI links ไปยังข้อมูล CVE โดยตรงด้วย ทำให้สามารถดูรายละเอียดช่องโหว่ได้ทันทีโดยไม่ต้องไป search เอง
เขียน Custom Rules สำหรับตรวจจับภัยคุกคาม
โครงสร้างของ Wazuh Rules
Wazuh มี rules เริ่มต้นมากกว่า 4,000 rules ซึ่งครอบคลุมเยอะมาก แต่สิ่งที่ทำให้มันทรงพลังจริงๆ คือความสามารถในการเขียน custom rules ไฟล์ custom rules อยู่ที่ /var/ossec/etc/rules/local_rules.xml บน Wazuh Server
มาดูตัวอย่าง rules ที่ผมแนะนำให้เพิ่มกันครับ:
Rule 1: ตรวจจับการ Login สำเร็จจาก IP ภายนอก
<group name="custom_ssh,">
<!-- ตรวจจับ SSH login สำเร็จ -->
<rule id="100001" level="10">
<if_sid>5715</if_sid>
<NOT_srcip>10.0.0.0/8|172.16.0.0/12|192.168.0.0/16</NOT_srcip>
<description>SSH login สำเร็จจาก IP ภายนอก: $(srcip)</description>
<group>authentication_success,external_access,</group>
</rule>
</group>
Rule 2: ตรวจจับการสร้าง User ใหม่
<group name="custom_user_management,">
<rule id="100002" level="12">
<if_sid>5902</if_sid>
<description>ตรวจพบการสร้าง user account ใหม่บนระบบ</description>
<group>account_management,high_priority,</group>
</rule>
<!-- ตรวจจับการเพิ่ม user เข้ากลุ่ม sudo/wheel -->
<rule id="100003" level="14">
<if_sid>5904</if_sid>
<match>sudo|wheel|admin</match>
<description>ตรวจพบการเพิ่ม user เข้ากลุ่มที่มีสิทธิ์ admin!</description>
<group>privilege_escalation,critical,</group>
</rule>
</group>
Rule 3: ตรวจจับ Web Shell
อันนี้สำคัญมากครับสำหรับเครื่องที่รัน web server ถ้ามีไฟล์ .php หรือ .jsp โผล่มาใน web directory โดยไม่ได้ deploy เอง นั่นคือสัญญาณอันตราย:
<group name="custom_webshell,">
<rule id="100004" level="15">
<if_sid>550</if_sid>
<field name="file">/var/www</field>
<match>\.php$|\.jsp$|\.asp$</match>
<description>ตรวจพบไฟล์ script ใหม่ใน web directory — อาจเป็น web shell!</description>
<group>web_shell,malware,critical,</group>
</rule>
</group>
Rule 4: ตรวจจับ Brute Force แบบ Custom
<group name="custom_bruteforce,">
<!-- ตรวจจับ SSH brute force ที่เร็วผิดปกติ (5 ครั้งใน 30 วินาที) -->
<rule id="100005" level="12" frequency="5" timeframe="30">
<if_matched_sid>5710</if_matched_sid>
<description>SSH brute force แบบเร็ว — อาจเป็น automated tool: $(srcip)</description>
<same_source_ip />
<group>bruteforce,rapid_attack,</group>
</rule>
<!-- ตรวจจับ distributed brute force (หลาย IP พร้อมกัน) -->
<rule id="100006" level="13" frequency="20" timeframe="120">
<if_matched_sid>5710</if_matched_sid>
<description>ตรวจพบ distributed SSH brute force จากหลาย IP พร้อมกัน</description>
<group>bruteforce,distributed_attack,</group>
</rule>
</group>
หลังเพิ่ม rules แล้ว อย่าลืมตรวจสอบ syntax ก่อน restart นะครับ ไม่งั้น Wazuh อาจไม่ start:
# ตรวจสอบ syntax ก่อน
sudo /var/ossec/bin/wazuh-analysisd -t
# ถ้าไม่มี error ให้ restart
sudo systemctl restart wazuh-manager
ตั้งค่า Active Response เพื่อบล็อก IP อัตโนมัติ
Active Response คืออะไร
Active Response คือความสามารถของ Wazuh ในการตอบสนองต่อภัยคุกคามโดยอัตโนมัติ เช่น บล็อก IP ที่โจมตี, ลบไฟล์ที่เป็นอันตราย หรือรัน script เฉพาะ ทุกอย่างเกิดขึ้นภายในมิลลิวินาทีหลังจาก rule ถูก trigger
พูดง่ายๆ คือมันตอบโต้แทนคุณโดยอัตโนมัติ ไม่ต้องรอให้ admin ตื่นนอนมาจัดการตอนตี 3 ครับ
ตั้งค่าบล็อก SSH Brute Force
แก้ไข /var/ossec/etc/ossec.conf บน Wazuh Server:
<ossec_config>
<!-- กำหนด command สำหรับบล็อก IP -->
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<!-- Active Response สำหรับ SSH brute force -->
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5763</rules_id>
<timeout>600</timeout>
</active-response>
<!-- Active Response สำหรับ custom rapid brute force -->
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100005</rules_id>
<timeout>1800</timeout>
</active-response>
<!-- Whitelist IP ที่ไม่ต้องการบล็อก -->
<global>
<white_list>127.0.0.1</white_list>
<white_list>10.0.0.0/8</white_list>
<white_list>192.168.1.0/24</white_list>
</global>
</ossec_config>
ทดสอบ Active Response
# ทดสอบจากเครื่องอื่น (ใช้ IP ที่ไม่ได้อยู่ใน whitelist)
# ลอง SSH ด้วยรหัสผ่านผิดซ้ำๆ
ssh wronguser@target-server
# ตรวจสอบ active response logs บน agent
sudo tail -f /var/ossec/logs/active-responses.log
# ตรวจสอบ iptables rules ที่ถูกเพิ่ม
sudo iptables -L INPUT -n | grep DROP
# ตรวจสอบ alerts บน server
sudo tail -f /var/ossec/logs/alerts/alerts.json | python3 -m json.tool
ตรวจสอบ Compliance ด้วย SCA (Security Configuration Assessment)
SCA คืออะไร
Wazuh มีโมดูล SCA ที่ช่วยตรวจสอบว่าการตั้งค่าระบบของคุณเป็นไปตามมาตรฐานความปลอดภัยหรือไม่ โดยเทียบกับ CIS Benchmarks และมาตรฐานอื่นๆ ตัวอย่างสิ่งที่ SCA ตรวจสอบ:
- SSH ปิด root login หรือยัง?
- ไฟร์วอลล์เปิดอยู่หรือเปล่า?
- File permissions ของไฟล์สำคัญถูกต้องไหม?
- มี unneeded services ทำงานอยู่ไหม?
- Password policy เข้มงวดพอไหม?
สรุปคือมันเป็นเหมือน checklist อัตโนมัติที่ช่วยตรวจว่าเซิร์ฟเวอร์ของคุณตั้งค่าถูกต้องตามมาตรฐานหรือเปล่า
เปิดใช้งาน SCA Policies
SCA ถูกเปิดใช้งานโดยค่าเริ่มต้นบน agent แล้ว policy files อยู่ที่ /var/ossec/ruleset/sca/ สามารถเลือก policies ที่ต้องการใน /var/ossec/etc/ossec.conf:
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
<!-- CIS Benchmark สำหรับ Ubuntu 22.04 -->
<policies>
<policy>cis_ubuntu22-04.yml</policy>
</policies>
</sca>
ผลการตรวจสอบจะแสดงบน Dashboard ในหมวด Security Configuration Assessment โดยแบ่งเป็น Passed, Failed และ Not Applicable พร้อมคำแนะนำในการแก้ไขสำหรับแต่ละข้อที่ไม่ผ่าน ซึ่งสะดวกมากถ้าคุณต้องทำ compliance audit
รวม Wazuh กับ Suricata สำหรับ Network IDS
ทำไมต้องรวม HIDS กับ NIDS
Wazuh เป็น HIDS (Host-based IDS) ที่ดูข้อมูลจากภายในเครื่อง แต่เพื่อให้เห็นภาพครบถ้วน ควรรวมกับ NIDS (Network-based IDS) อย่าง Suricata ที่ตรวจสอบ network traffic ด้วย
เมื่อรวมกันแล้วจะสามารถตรวจจับได้ทั้ง:
- การโจมตีผ่าน network เช่น port scanning, SQL injection ผ่าน HTTP
- การเชื่อมต่อไปยัง C2 (Command and Control) servers
- การส่งข้อมูลออก (data exfiltration) แบบผิดปกติ
จริงๆ แล้วการรวม HIDS กับ NIDS เป็นแนวทางที่ security team ส่วนใหญ่แนะนำกันครับ เพราะมันช่วยให้เห็นภาพรวมได้ครบถ้วนกว่าใช้อย่างใดอย่างหนึ่ง
ติดตั้งและเชื่อมต่อ Suricata
# ติดตั้ง Suricata บน Ubuntu
sudo apt install -y software-properties-common
sudo add-apt-repository -y ppa:oisf/suricata-stable
sudo apt update
sudo apt install -y suricata
# อัปเดต rules
sudo suricata-update
# ตั้งค่า Suricata ให้เขียน log ในรูปแบบ EVE JSON
# แก้ไข /etc/suricata/suricata.yaml
# outputs:
# - eve-log:
# enabled: yes
# filetype: regular
# filename: /var/log/suricata/eve.json
# เริ่มต้น Suricata
sudo systemctl enable suricata
sudo systemctl start suricata
จากนั้นตั้งค่า Wazuh agent ให้อ่าน Suricata logs โดยเพิ่มใน /var/ossec/etc/ossec.conf บน agent:
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
# Restart agent
sudo systemctl restart wazuh-agent
Wazuh จะ parse และสร้าง alerts จาก Suricata events โดยอัตโนมัติ แสดงผลบน Dashboard ในหมวด Threat Hunting — ไม่ต้องตั้งค่าอะไรเพิ่มเติมเลยครับ
Hardening Wazuh Server ให้ปลอดภัย
ก่อนจบบทความ สิ่งสำคัญอีกอย่างที่อยากย้ำคือ ตัว Wazuh Server เองก็ต้อง hardening ด้วยนะครับ เพราะถ้า security tool ของเราถูกเจาะ ก็แทบจะเหมือนกับไม่มีเลย
เปลี่ยน Default Passwords
# เปลี่ยน password ของ admin user บน Wazuh Dashboard
sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh \
-u admin -p
จำกัด Access ด้วย Firewall
# อนุญาตเฉพาะ subnet ที่ต้องการ
sudo ufw default deny incoming
sudo ufw default allow outgoing
# เปิดเฉพาะ ports ที่จำเป็น
sudo ufw allow from 10.0.0.0/8 to any port 1514 proto tcp # Agent events
sudo ufw allow from 10.0.0.0/8 to any port 1515 proto tcp # Agent enrollment
sudo ufw allow from 192.168.1.0/24 to any port 443 proto tcp # Dashboard
sudo ufw allow from 192.168.1.0/24 to any port 55000 proto tcp # API
sudo ufw enable
ตั้งค่า TLS สำหรับการสื่อสาร
การสื่อสารระหว่าง Wazuh components ทั้งหมดใช้ TLS encryption โดยค่าเริ่มต้นอยู่แล้ว (ซึ่งดีมาก) แต่สิ่งที่หลายคนลืมคือต้องตรวจสอบให้แน่ใจว่า certificates ยังไม่หมดอายุ:
# ตรวจสอบวันหมดอายุของ certificate
sudo openssl x509 -enddate -noout -in /etc/wazuh-indexer/certs/indexer.pem
sudo openssl x509 -enddate -noout -in /etc/filebeat/filebeat.pem
sudo openssl x509 -enddate -noout -in /etc/wazuh-dashboard/certs/dashboard.pem
การแก้ไขปัญหาที่พบบ่อย
ตรงนี้ผมรวบรวมปัญหาที่เจอบ่อยๆ มาให้ครับ จากประสบการณ์ส่วนตัวแล้ว 3 ปัญหานี้คือสิ่งที่คนติดตั้ง Wazuh ครั้งแรกมักจะเจอ
Agent เชื่อมต่อ Server ไม่ได้
# ตรวจสอบสถานะ agent
sudo /var/ossec/bin/wazuh-control status
# ตรวจสอบ log
sudo tail -50 /var/ossec/logs/ossec.log
# ตรวจสอบ connectivity
telnet 1514
telnet 1515
# ตรวจสอบ firewall บน server
sudo ufw status
sudo iptables -L INPUT -n | grep -E "1514|1515"
# Re-register agent ถ้าจำเป็น
sudo /var/ossec/bin/agent-auth -m
Dashboard ไม่แสดง Alerts
ปัญหานี้เจอบ่อยที่สุดเลยครับ สาเหตุส่วนใหญ่คือ Filebeat ไม่ทำงานหรือเชื่อมต่อ Indexer ไม่ได้:
# ตรวจสอบว่า Filebeat ทำงานอยู่และส่งข้อมูลไป Indexer
sudo systemctl status filebeat
sudo filebeat test output
# ตรวจสอบ Indexer health
curl -k -u admin: https://localhost:9200/_cluster/health?pretty
# ตรวจสอบว่ามี alerts index หรือไม่
curl -k -u admin: https://localhost:9200/_cat/indices?v | grep wazuh-alerts
FIM ไม่ตรวจจับการเปลี่ยนแปลง
# ตรวจสอบว่า syscheck ทำงานอยู่
sudo /var/ossec/bin/wazuh-control info | grep syscheck
# บังคับสแกนใหม่
sudo /var/ossec/bin/agent_control -r -a
# ตรวจสอบว่า directory ถูกมอนิเตอร์
sudo grep -A5 "directories" /var/ossec/etc/ossec.conf
คำถามที่พบบ่อย (FAQ)
Wazuh กับ OSSEC ต่างกันอย่างไร?
Wazuh เป็น fork ของ OSSEC ที่พัฒนาต่อยอดอย่างต่อเนื่อง ความแตกต่างหลักคือ Wazuh มี web dashboard ที่ทันสมัย (OSSEC ใช้ CLI เป็นหลัก), รองรับ RESTful API, มี vulnerability detection ในตัว, integrate กับ OpenSearch/ELK ได้, และมี update ใหม่ทุกไตรมาส ขณะที่ OSSEC อัปเดตล่าสุดในปี 2021 พูดตรงๆ ครับ สำหรับการ deploy ใหม่ในปี 2026 ไม่มีเหตุผลที่จะเลือก OSSEC แล้ว
Wazuh ใช้ทรัพยากรระบบมากแค่ไหน?
สำหรับ agent ใช้ RAM ประมาณ 50-100 MB และ CPU ต่ำมาก (น้อยกว่า 1% ในสภาวะปกติ) แทบไม่รู้สึกเลยครับ สำหรับ server แบบ all-in-one ที่ดูแล agents 50-100 ตัว แนะนำ RAM 8-16 GB, 4 CPU cores และ SSD 50 GB ขึ้นไป การใช้ทรัพยากรจะเพิ่มขึ้นตามจำนวน agents และปริมาณ events ต่อวินาที
สามารถใช้ Wazuh แทน Fail2Ban ได้ไหม?
ได้ครับ Wazuh Active Response ทำทุกอย่างที่ Fail2Ban ทำได้ (บล็อก IP จากการ brute force) และยังทำได้มากกว่าอีก เช่น ตรวจจับ distributed brute force, รวม logs จากหลายเครื่อง, สร้าง custom rules ที่ซับซ้อน และมี dashboard สำหรับดู alerts แบบ centralized ข้อดีคือเป็น "all-in-one" ไม่ต้องติดตั้งเครื่องมือหลายตัวแยกกัน
Wazuh รองรับ Container Security หรือไม่?
รองรับครับ Wazuh สามารถมอนิเตอร์ Docker containers ได้โดยตรง ตรวจจับการสร้าง/ลบ containers, มอนิเตอร์ Docker daemon logs, ตรวจสอบ image vulnerabilities และยังสามารถ deploy Wazuh เองใน Docker ได้ด้วย สำหรับ Kubernetes สามารถใช้ Wazuh agent แบบ DaemonSet เพื่อมอนิเตอร์ทุก node ใน cluster
ต้อง update Wazuh บ่อยแค่ไหน?
แนะนำให้ตรวจสอบ release notes ทุกเดือนครับ และ update เมื่อมี security fixes ที่สำคัญ สำหรับ minor version (เช่น 4.14.2 → 4.14.3) สามารถ update ได้ค่อนข้างปลอดภัย แต่สำหรับ major version (เช่น 4.12 → 4.14) ควรทดสอบใน staging ก่อนเสมอ สิ่งสำคัญที่ต้องจำไว้: agent version ต้องเท่ากับหรือต่ำกว่า manager version เสมอครับ