อัปเดตล่าสุด: 10 สิงหาคม 2026
Lynis คือเครื่องมือตรวจสอบความปลอดภัย (security auditing tool) แบบโอเพ่นซอร์สที่รันบนตัวเซิร์ฟเวอร์ Linux โดยตรง เพื่อประเมินการตั้งค่ามากกว่า 300 รายการเทียบกับแนวปฏิบัติที่ดีที่สุดของ CIS Benchmarks, NIST และ ISO 27001 แล้วให้ค่า Hardening Index เป็นคะแนน 0–100 พร้อมข้อเสนอแนะที่ปฏิบัติได้จริง คู่มือนี้อธิบายวิธีติดตั้ง Lynis 3.1.6 (รีลีสล่าสุดเมื่อ 23 ตุลาคม 2025), รันการตรวจสอบตามมาตรฐาน CIS Level 1/2, ยกคะแนน Hardening Index จาก 65 เป็น 90+, และรวมเข้ากับ CI/CD สำหรับการตรวจสอบอัตโนมัติในปี 2026
- Lynis 3.1.6 เป็นเวอร์ชันเสถียรล่าสุด (ตุลาคม 2025) รองรับการตรวจสอบมากกว่า 2,000 รายการโดยไม่ต้องติดตั้ง agent
- ระบบใหม่ที่ยังไม่ได้ hardening มักได้คะแนน Hardening Index อยู่ที่ 55–65 เท่านั้น เป้าหมายสำหรับ production ควรอยู่ที่ 85+
- Lynis เหมาะกับการตรวจสอบต่อเนื่องรายสัปดาห์ ส่วน OpenSCAP ใช้สำหรับรายงาน compliance ที่ผ่านมาตรฐาน NIST
- ใช้ CIS profile ผ่านคำสั่ง
lynis audit system --profile เพื่อ scan ตาม Level 1 หรือ Level 2 อย่างเจาะจง
- ห้าการเปลี่ยนแปลงที่ทำให้ระบบ production พังบ่อยที่สุด ได้แก่
AllowGroups, noexec /tmp, ip_forward=0, auditd -e 2, และ account lockout
- ผลลัพธ์ของ Lynis สามารถ map เข้ากับ PCI-DSS, HIPAA, และ ISO 27001 ได้โดยตรง เหมาะสำหรับการเตรียม audit
Lynis คืออะไร และทำงานอย่างไร
Lynis เป็น security audit tool ที่พัฒนาโดย CISOfy (ผู้ก่อตั้งคือ Michael Boelen) เปิดตัวครั้งแรกในปี 2007 และเขียนด้วย shell script ล้วน ทำให้พกพาไปรันบนระบบ Linux, macOS, FreeBSD, OpenBSD และ Solaris ได้ทันทีโดยไม่ต้องคอมไพล์อะไรเพิ่ม ผมชอบตรงที่มันเป็น agentless อย่างแท้จริง คือไม่มี daemon ค้างไว้กินหน่วยความจำ ไม่มี agent ที่ต้องอัปเดตแยก และการรัน scan ครั้งหนึ่งใช้ทรัพยากรน้อยมากจนสามารถใส่ใน cron ของ production ได้โดยไม่รู้สึกว่าเซิร์ฟเวอร์ช้าลง
Lynis ทำงานเป็นสามขั้นตอน คือ Scanning (ตรวจการตั้งค่ากว่า 300 รายการรวมถึง boot loader, kernel parameters, sysctl, filesystem permissions, PAM, SSH, cron, containers, และ log rotation), Analysis (สรุปผลเป็นหมวดหมู่ Authentication, Networking, Storage และอื่นๆ), และ Recommendation (จัดลำดับความสำคัญของสิ่งที่ควรแก้ไข) ผลลัพธ์ทั้งหมดจะถูกบันทึกใน /var/log/lynis.log และ /var/log/lynis-report.dat ซึ่งเป็นไฟล์แบบ machine-readable เหมาะสำหรับส่งเข้า SIEM หรือ Grafana
ต่างจาก vulnerability scanner ทั่วไป (เช่น OpenVAS หรือ Nessus) ที่มองหา CVE เฉพาะเจาะจง Lynis จะประเมิน configuration posture ทั้งระบบ ดังนั้นแม้แพ็คเกจของคุณจะไม่มี CVE ค้าง Lynis ก็ยังเตือนได้ว่าคุณเปิด SSH root login, ไม่ได้ตั้ง firewall, หรือไม่ได้เปิด auditd อยู่ ในทางปฏิบัติทั้งสองแบบต้องใช้คู่กัน ไม่มีอันไหนแทนกันได้
CIS Benchmarks กับ Lynis: ความสัมพันธ์ที่ต้องเข้าใจ
CIS Benchmarks คือชุดเอกสารมาตรฐานความปลอดภัยจาก Center for Internet Security ซึ่งกำหนดการตั้งค่าที่ปลอดภัยไว้ระดับต่างๆ สำหรับระบบปฏิบัติการและซอฟต์แวร์ยอดนิยม แต่ละ benchmark แบ่งเป็นสองระดับ คือ Level 1 เน้นการ hardening พื้นฐานที่ไม่กระทบต่อ usability ในระบบทั่วไป และ Level 2 เข้มงวดกว่า เหมาะสำหรับระบบที่มีข้อมูล sensitive สูง เช่น เซิร์ฟเวอร์ที่ต้องผ่าน PCI-DSS หรือ HIPAA
Lynis ไม่ใช่เครื่องมือรับรอง CIS อย่างเป็นทางการ (เครื่องมือทางการคือ CIS-CAT Pro ซึ่งต้องเสียเงินสมัครสมาชิก) แต่ชุดการทดสอบภายในของ Lynis อ้างอิง CIS Benchmarks, NIST 800-53, NSA guides และ vendor recommendations โดยตรง ในความเป็นจริง หน่วยงานส่วนใหญ่ที่ต้องผ่าน audit ของ ISO 27001 หรือ PCI-DSS จะใช้ Lynis เป็นเครื่องมือหลักในการ pre-check ก่อนเรียกทีม audit จากภายนอกเข้ามาจริง เพราะราคาถูกกว่าและปรับ profile ได้เอง
สำหรับผู้ที่ทำ Linux hardening อยู่แล้ว โปรดอ่านคู่มือ Hardening เคอร์เนล Linux ด้วย sysctl ควบคู่กัน เพราะการปรับ sysctl ที่ถูกต้องจะช่วยปิดคำเตือน Lynis หมวด KRNL-6000 ทั้งหมดในครั้งเดียว
ติดตั้ง Lynis 3.1.6 บน Ubuntu, RHEL และ Debian
วิธีติดตั้งขึ้นอยู่กับว่าคุณต้องการเวอร์ชันไหน ระบบดิสโทรจะให้เวอร์ชันเก่ากว่ารีลีสของ upstream หลายเดือน ถ้ารับได้ให้ติดตั้งจาก repository ตามปกติ แต่ถ้าคุณต้องการ scan ตาม CIS Benchmark ล่าสุดหรือใช้ profile ใหม่ๆ ให้ติดตั้งจาก CISOfy repo แทน
# --- ตัวเลือกที่ 1: ติดตั้งจาก distro repo (เร็ว แต่เวอร์ชันเก่า) ---
# Ubuntu / Debian
sudo apt update && sudo apt install -y lynis
# RHEL / Rocky / AlmaLinux 9
sudo dnf install -y lynis
# --- ตัวเลือกที่ 2: CISOfy repository (แนะนำสำหรับ production) ---
# Debian/Ubuntu
curl -fsSL https://packages.cisofy.com/keys/cisofy-software-public.key \
| sudo gpg --dearmor -o /usr/share/keyrings/cisofy.gpg
echo "deb [signed-by=/usr/share/keyrings/cisofy.gpg] \
https://packages.cisofy.com/community/lynis/deb/ stable main" \
| sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
sudo apt update && sudo apt install -y lynis
# --- ตัวเลือกที่ 3: รันจาก GitHub โดยไม่ต้องติดตั้ง ---
cd /opt
sudo git clone https://github.com/CISOfy/lynis.git
cd lynis
sudo ./lynis audit system
# ตรวจสอบเวอร์ชัน ควรได้ 3.1.6 หรือใหม่กว่า
lynis show version
ผมมักจะเลือกวิธีที่ 3 บน jump host หรือ CI runner เพราะไม่มีการเปลี่ยนแปลง state ของระบบ (ไม่ต้อง register package) และอัปเดตด้วย git pull ได้ทันที ถ้าใช้ในสภาพแวดล้อม air-gapped ให้ mirror repo ไว้ภายในและ pull เข้ามาผ่าน artifact server
รันการตรวจสอบครั้งแรกและอ่านค่า Hardening Index
เมื่อ Lynis พร้อมแล้ว การรัน audit ครั้งแรกใช้เวลาเพียง 2–5 นาทีบน VPS ทั่วไป Lynis จะ scroll คำเตือนและข้อเสนอแนะไปเรื่อยๆ ก่อนสรุปด้วย Hardening Index ที่ท้าย output ผมแนะนำให้รันสองครั้ง คือครั้งแรกด้วยโหมด --quick เพื่อดูภาพรวม แล้วครั้งที่สองด้วยโหมดเต็มเพื่อลงรายละเอียด
# รันแบบเต็ม (สแตนดาร์ด)
sudo lynis audit system
# รันแบบเร็ว ข้ามการรอ keypress
sudo lynis audit system --quick
# รันโดยไม่มี output สี (เหมาะกับ log file / CI)
sudo lynis audit system --quiet --no-colors
# ดูคะแนน Hardening Index จาก report file
grep "hardening_index" /var/log/lynis-report.dat
# ผลลัพธ์ตัวอย่าง: hardening_index=67
# ดูรายละเอียดของ finding เฉพาะ ID
sudo lynis show details SSH-7408
Output ที่ต้องอ่านมีสามระดับ ได้แก่ [WARN] คือปัญหาความปลอดภัยที่ต้องแก้ทันที (เช่น root login ผ่าน SSH เปิดอยู่, ไม่มี malware scanner), [SUGGESTION] คือข้อเสนอที่ควรพิจารณา (เช่น เปิด process accounting, ปรับ permissions ของบางไฟล์) และ [INFO] คือข้อมูลเชิงบริบทที่ไม่ต้องดำเนินการ ระบบใหม่ที่เพิ่งติดตั้ง Ubuntu 24.04 หรือ Rocky Linux 9 มักได้คะแนนเริ่มต้นราว 55–65 ซึ่งต่ำเกินไปสำหรับ production ตามแนวปฏิบัติที่ผมใช้อยู่
คะแนน Hardening Index คำนวณจากอัตราส่วนของการทดสอบที่ผ่านต่อการทดสอบทั้งหมดที่รัน โดยแต่ละกลุ่มมีน้ำหนักต่างกัน หมวด Authentication และ Networking มีน้ำหนักสูงกว่าหมวด Banners หรือ Time Synchronization ดังนั้นการแก้ปัญหาใน SSH จะขยับคะแนนเร็วกว่าการแก้ปัญหาใน MOTD หลายเท่า
Lynis vs OpenSCAP vs CIS-CAT: เลือกเครื่องมือให้เหมาะกับงาน
คำถามที่ผมเจอบ่อยที่สุดจากทีม compliance คือ "ทำไมไม่ใช้ OpenSCAP อย่างเดียว?" คำตอบสั้นๆ คือแต่ละเครื่องมือถูกออกแบบมาเพื่องานที่ต่างกัน Lynis เหมาะกับการตรวจสอบต่อเนื่องและปรับปรุง posture อย่างสม่ำเสมอ, OpenSCAP เหมาะกับการทำรายงาน compliance ตามมาตรฐาน NIST ที่มีรูปแบบทางการ, ส่วน CIS-CAT เป็นเครื่องมือทางการเพียงตัวเดียวที่สามารถออกรายงาน CIS Level 1/2 อย่างเป็นทางการได้ ตารางด้านล่างสรุปความแตกต่างสำคัญ
| คุณสมบัติ |
Lynis |
OpenSCAP |
CIS-CAT |
| License | GPLv3 (ฟรี) | โอเพ่นซอร์ส | Lite ฟรี / Pro เสียเงิน |
| รับรอง NIST SCAP | ไม่ | ใช่ | ใช่ |
| Auto-remediation | ไม่ (แนะนำเท่านั้น) | ใช่ (bash / ansible) | ไม่ (Pro มี snippet) |
| Platform รองรับ | Linux / macOS / BSD | Linux (RHEL-centric) | Linux / Windows / macOS |
| จำนวนการทดสอบ | 2,000+ | ตามจำนวน datastream | ตาม CIS profile |
| ความยากในการติดตั้ง | ง่ายมาก | ปานกลาง | ง่าย (แต่ต้องมี Java) |
| เหมาะกับความถี่ | รายวัน/รายสัปดาห์ | รายเดือน | รายไตรมาส |
| รายงานที่ auditor รับ | ต้องแปลงรูปแบบ | XCCDF / ARF (ยอมรับ) | รายงานทางการ CIS |
ในทางปฏิบัติ ผมใช้ทั้งสามตัวคู่กันในลักษณะ layered คือ Lynis รัน scan รายคืนบน production ทุกเครื่องเพื่อจับ drift, OpenSCAP รันเดือนละครั้งเพื่อ generate รายงาน SCAP ที่ compliance team ส่งให้ auditor, และ CIS-CAT รันเฉพาะ quarter สำหรับระบบที่ต้อง submit รายงาน CIS อย่างเป็นทางการ (ปกติจะทำก็ต่อเมื่อบริษัทต้องการ CIS Certification จริงๆ ไม่ใช่แค่ compliance ทั่วไป)
ยก Hardening Index จาก 65 เป็น 90+
คำถามที่ทีมมือใหม่มักถามคือ "จะเพิ่ม Hardening Index ได้เร็วที่สุดยังไง?" คำตอบคือลุยที่ [WARN] ก่อนเสมอ เพราะแต่ละ warning มีน้ำหนักเยอะกว่า suggestion หลายเท่า ในระบบใหม่ ผมพบว่าการแก้เพียง 5 จุดต่อไปนี้ก็สามารถยกคะแนนจาก 65 ขึ้นเป็น 85+ ได้ในเวลาไม่ถึงชั่วโมง
- ปิด SSH root login และเข้ารหัสด้วย key เท่านั้น: แก้ไฟล์
/etc/ssh/sshd_config ให้ PermitRootLogin no และ PasswordAuthentication no
- เปิด firewall: ติดตั้ง nftables หรือ ufw และเปิดเฉพาะพอร์ตที่จำเป็น
- ติดตั้ง auditd:
apt install auditd แล้วเปิด service ทันที Lynis จะลด warning ไปกว่า 10 รายการ
- ตั้ง sysctl hardening: เพิ่ม
net.ipv4.conf.all.rp_filter=1, kernel.kptr_restrict=2, kernel.dmesg_restrict=1
- เพิ่ม password quality: ติดตั้ง
libpam-pwquality และตั้ง minlen=14 ใน /etc/security/pwquality.conf
# ตัวอย่างการปรับ sshd_config สำหรับ Lynis SSH-7408
sudo tee -a /etc/ssh/sshd_config.d/50-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowTcpForwarding no
LogLevel VERBOSE
Protocol 2
EOF
sudo systemctl reload ssh
# ตัวอย่าง sysctl hardening ที่ Lynis จะให้คะแนนเพิ่ม
sudo tee /etc/sysctl.d/99-lynis.conf <<'EOF'
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.yama.ptrace_scope = 2
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
EOF
sudo sysctl --system
# รัน Lynis อีกครั้งเพื่อดูคะแนนใหม่
sudo lynis audit system --quick
grep "hardening_index" /var/log/lynis-report.dat
สำหรับการตั้งค่า SSH เชิงลึกกว่านี้รวมถึงการเปิดใช้ FIDO2 และ post-quantum key exchange โปรดอ่าน คู่มือ SSH Hardening OpenSSH 10.x ที่ผมเขียนไว้แยกต่างหาก การใช้สอง guide นี้คู่กันจะทำให้ Hardening Index ทะลุ 90 ได้ในเซิร์ฟเวอร์ที่ไม่มีข้อจำกัดพิเศษ
สร้าง Custom Profile สำหรับ CIS Level 1 และ Level 2
Profile ของ Lynis คือไฟล์ .prf ที่ควบคุมว่าจะรัน test อะไรบ้าง, ข้ามอะไร, และกำหนด threshold อย่างไร ค่าเริ่มต้นอยู่ที่ /etc/lynis/default.prf การสร้าง custom profile ช่วยให้ audit ตรงกับ compliance framework ที่บริษัทใช้จริง เช่น ถ้าคุณต้องผ่าน PCI-DSS ให้เปิดเฉพาะ test ที่ mapping กับ PCI และปิด test ที่ไม่เกี่ยวข้อง
# สร้าง custom profile สำหรับ CIS Level 1
sudo tee /etc/lynis/custom.prf <<'EOF'
# ตั้งชื่อ profile ให้เห็นใน report
config-data=profile_name:CIS-L1-Production
compliance-standard=cis
compliance-standard=pci-dss
# ปิด test ที่ไม่เกี่ยวกับ server ของเรา
# (เช่น ระบบไม่ใช่ mail server จึงข้าม test mail)
skip-test=MAIL-8802
skip-test=MAIL-8804
skip-test=MAIL-8814
# ตั้งเกณฑ์ warning สำหรับอายุ password
config-data=password_max_days:60
config-data=password_min_days:1
# บันทึก report ใน format machine-readable ทุกครั้ง
show-report-solution=yes
EOF
# รันด้วย profile ที่สร้าง
sudo lynis audit system --profile /etc/lynis/custom.prf
# ตรวจสอบว่า Lynis อ่าน profile ถูกต้อง
sudo lynis show profiles
ข้อควรระวังคือการ skip-test จะทำให้คะแนน Hardening Index สูงขึ้นจริง แต่ทำให้การเปรียบเทียบระหว่างเซิร์ฟเวอร์ยากขึ้น เพราะระบบสองเครื่องอาจใช้ profile คนละชุด ทางแก้คือกำหนด profile เป็นชุดเดียวทั้งองค์กร แล้ว version-control ผ่าน Git เก็บไว้ใน repo กลาง เพื่อให้ทุก host ได้ profile version เดียวกัน
อัตโนมัติ Lynis ผ่าน Cron และรวมเข้ากับ CI/CD
การรัน Lynis ครั้งเดียวไม่ค่อยมีประโยชน์ ประโยชน์จริงเกิดจากการรันซ้ำแล้วเทียบ trend ของ Hardening Index ตามเวลา เพื่อจับ configuration drift ให้เร็วที่สุด แนวทางที่ผมใช้กับลูกค้าคือรัน Lynis ทุกคืน (02:00) ใน cron แล้ว push report เข้า central S3 หรือ Loki สำหรับ visualize ผ่าน Grafana
# เพิ่มเข้าใน crontab ของ root
sudo crontab -e
# รันทุกคืนเวลา 02:00 ในโหมด quiet
0 2 * * * /usr/sbin/lynis audit system --cronjob --quiet \
--report-file /var/log/lynis/report-$(date +\%Y\%m\%d).dat > \
/var/log/lynis/cron-$(date +\%Y\%m\%d).log 2>&1
# สำหรับ CI/CD (GitLab CI ตัวอย่าง) - ทดสอบ image ก่อน push
lynis_audit:
stage: test
image: alpine:3.20
script:
- apk add --no-cache bash git
- git clone https://github.com/CISOfy/lynis.git /opt/lynis
- cd /opt/lynis
- ./lynis audit system --no-log --profile /custom.prf
- HI=$(grep hardening_index /var/log/lynis-report.dat | cut -d= -f2)
- echo "Hardening Index: $HI"
- test "$HI" -ge 85 || exit 1 # ไม่ผ่าน ถ้าคะแนน < 85
only:
- main
ตัวอย่าง GitLab CI ด้านบนแสดงหลักการ "hardening gate" นั่นคือ ถ้า image ที่จะขึ้น production ได้คะแนนต่ำกว่า 85 ให้ pipeline fail ทันที วิธีนี้จับ regression ก่อนที่ image จะไปถึง registry และป้องกันไม่ให้ dev เผลอลบ hardening ที่คุณเพิ่งใส่ ตัวเลข threshold ควรปรับตามเวลา โดยเริ่มจาก 65 แล้วขยับขึ้น 5 คะแนนทุกไตรมาสจนถึงเป้าหมาย
สำหรับ intrusion detection คู่กัน แนะนำให้ตั้ง Wazuh IDS/SIEM ไว้รับ log ของ auditd และ Lynis report เพื่อ correlate event ระหว่างการเปลี่ยน config กับพฤติกรรมผิดปกติ อีกทางเลือกคือ CrowdSec แบบชุมชน สำหรับป้องกัน brute-force ที่ตรวจได้จาก Lynis
ข้อผิดพลาดที่ทำให้ production ล่มและวิธีหลีกเลี่ยง
เรียนรู้จากประสบการณ์จริงที่ผมเจอ (และเคยล่ม production ด้วยตัวเอง) มีห้าจุดที่ทำให้ระบบพังบ่อยที่สุดเมื่อทำ CIS hardening ตามที่ Lynis แนะนำแบบไม่ระวัง
AllowGroups ผิด: ทำให้ user ที่ไม่ได้อยู่ใน group ที่ระบุถูกล็อกออกจาก SSH ทันที รวมถึง admin ที่กำลัง SSH อยู่ ทดสอบด้วย session ที่สองก่อนเสมอnoexec บน /tmp: Java installer, systemd tmp scripts, และ apt hooks บางตัวจะทำงานไม่ได้ ตรวจ dependency ก่อน applyip_forward=0 บน docker host: คอนเทนเนอร์จะเชื่อมต่อภายนอกไม่ได้เพราะ NAT ไม่ทำงาน ยกเว้นให้ Docker หรือใช้ user namespacesauditd -e 2 (immutable mode): เมื่อรัน mode นี้แล้วจะแก้ config rule ไม่ได้จนกว่าจะ reboot เหมาะสำหรับ production ที่ตั้งค่านิ่งแล้วเท่านั้น- Account lockout ที่เข้มเกินไป: service account (เช่น jenkins, gitlab-runner) โดน lock เมื่อ password ผิดครั้งเดียว ให้ exempt account เหล่านี้ผ่าน
pam_faillock
หลักการที่ผมยึดคือ Audit first, change second โดยรัน lynis audit system ก่อนแตะอะไร แล้วค่อยแก้ทีละหมวด อย่าใช้ CIS hardening script แบบ one-shot ที่ไปเปลี่ยน 200 config พร้อมกัน เพราะเมื่อล่มคุณจะไม่รู้ว่าตัวไหนเป็นตัวแตก แนะนำให้แบ่งเป็น phase ตามลำดับ filesystem → services → network → SSH → PAM → auditd แต่ละ phase ต้อง verify ว่าระบบยังใช้งานได้ก่อนไป phase ถัดไป
สุดท้าย ห้ามลืม backup config file ก่อนแก้ทุกครั้ง คำสั่ง cp /etc/ssh/sshd_config{,.bak-$(date +%F)} คือ safety net ที่ช่วยชีวิตผมมาหลายครั้ง (ผมโดนมากับตัวตอนงานแรกที่ทำ hardening บน production ปี 2019 เลยไม่ลืมอีก)
ข้อมูลอ้างอิงเพิ่มเติมจากแหล่งทางการ ได้แก่ เว็บทางการของ CISOfy Lynis, Release notes บน GitHub, CIS Benchmarks จาก Center for Internet Security และ NIST SP 800-53 Rev. 5
คำถามที่พบบ่อย
Lynis ฟรีใช้งานได้ทั้งในเชิงพาณิชย์หรือไม่?
ใช่ Lynis ปล่อยภายใต้ GNU GPLv3 ทำให้สามารถใช้งานได้ทั้งในระบบส่วนตัวและ production ในเชิงพาณิชย์โดยไม่ต้องเสียค่าลิขสิทธิ์ CISOfy มี "Lynis Enterprise" เวอร์ชันเสียเงินที่เพิ่ม dashboard, plugins เพิ่มเติม, และ SLA support แต่เวอร์ชันคอมมูนิตี้ก็ใช้งานได้เต็มรูปแบบ
ควรรัน Lynis บ่อยแค่ไหน?
สำหรับ production แนะนำรันรายวันหรืออย่างน้อยรายสัปดาห์ผ่าน cron เพื่อจับ configuration drift สำหรับ CI/CD pipeline ควรรันทุกครั้งที่ build image ใหม่ ส่วน compliance report ที่ต้องส่ง auditor ควรรันรายเดือนพร้อม OpenSCAP
Hardening Index เท่าไหร่ถึงจะถือว่าปลอดภัย?
เป้าหมายขั้นต่ำสำหรับ production คือ 80 และเป้าหมายที่ดีคือ 90+ ระบบใหม่ที่เพิ่งติดตั้งมักได้ 55–65 คะแนน 70 ขึ้นไปถือว่ายอมรับได้สำหรับ dev/staging แต่ต่ำกว่า 70 คือ red flag ที่ต้อง action ทันที ไม่ควรตั้งเป้าที่ 100 เพราะบางการทดสอบขัดกันเอง
Lynis ตรวจจับ CVE ได้หรือไม่?
Lynis ไม่ใช่ vulnerability scanner โดยตรง มันตรวจ configuration posture เป็นหลัก ไม่ได้ scan CVE เฉพาะเจาะจงเหมือน Nessus หรือ OpenVAS สำหรับการ scan CVE ควรใช้เครื่องมืออื่นเช่น Trivy หรือ Grype ควบคู่ Lynis จะเตือนเฉพาะแพ็คเกจที่ไม่ได้อัปเดตนานผ่าน package manager เท่านั้น
Lynis รองรับการตรวจสอบ container และ Kubernetes หรือไม่?
Lynis รองรับการ scan Docker container image และ container runtime บนโฮสต์ แต่ไม่ได้ออกแบบมาสำหรับ Kubernetes cluster โดยตรง สำหรับ container security ใน Kubernetes แนะนำใช้ Trivy สำหรับ image scan, Falco สำหรับ runtime security, และ kube-bench สำหรับ CIS Kubernetes benchmark โดยเฉพาะ
