การรัน Lynis ครั้งแรกบน VPS ใหม่มักให้ผลราว 60 พร้อมรายการข้อเสนอแนะยาวเหยียดที่ไม่ชัดเจนว่าควรเริ่มจากอะไร ข่าวดี: 80 ถึง 85 เป็นงานเย็นเดียว และขั้นตอนส่วนใหญ่ไม่ใช่แค่ความสวยงามแต่ควรทำจริง ๆ ข่าวร้าย: สิบห้าคะแนนสุดท้ายเอื้อมไม่ถึงบนเครื่องเสมือนที่เช่ามา และการไล่ตามมันคือความผิดพลาด

index แสดงอะไรและไม่แสดงอะไร

hardening index คือสัดส่วนของการทดสอบที่ผ่านต่อทั้งหมด โดยมีการถ่วงน้ำหนัก — ไม่ใช่เปอร์เซ็นต์ความปลอดภัย Lynis รันการทดสอบราวสามร้อยรายการและให้รายการแยกกันสองชุด: warnings ซึ่งดูเหมือนปัญหาจริง และ suggestions ซึ่งเป็นสิ่งที่ปรับปรุงได้ เริ่มจากคำเตือนเสมอ มันมักมีเพียงไม่กี่รายการ

ร้อยคะแนนไม่เกิดขึ้น: ข้อเสนอแนะบางข้อต้องการการตัดสินใจตอนติดตั้งระบบ (พาร์ทิชันแยกสำหรับ /home, /tmp และ /var) บางข้อต้องการสิทธิ์เข้าถึง bootloader ซึ่ง VPS ไม่มี และบางข้อขัดแย้งกันเอง และการเปรียบเทียบ index ของคุณกับของคนอื่นไร้ความหมาย: Lynis หักคะแนนตามสิ่งที่ทำงานอยู่บนเครื่อง ทุกบริการที่ทำงานคือพอร์ตที่เปิดเพิ่มอีกหนึ่ง ไฟล์ตั้งค่าของมันเอง และข้อเสนอแนะใหม่อีกโหลหนึ่ง จึงเป็นเหตุผลว่าทำไมตัวเลขสูง ๆ จึงพบมากกว่าในที่ที่ไม่มีอะไรทำงานนอกจาก SSH สำหรับเซิร์ฟเวอร์ที่ใช้งานจริงพร้อมเว็บไซต์ ฐานข้อมูล และเมล 85 คือผลลัพธ์ที่ดี

รันในฐานะ root

sudo lynis audit system

ถ้าไม่มี sudo Lynis จะข้ามการทดสอบทุกอย่างที่ต้องใช้ไฟล์ระบบและรายงาน index ต่ำกว่าความจริง — ไม่ใช่เพราะเซิร์ฟเวอร์แย่ แต่เพราะการตรวจสอบมองไม่เห็น รายงานถูกเขียนไปที่ /var/log/lynis-report.dat ล็อกที่อ่านได้อยู่ที่ /var/log/lynis.log

ผลลัพธ์ทุกบรรทัดเริ่มด้วยตัวระบุการทดสอบ เช่น SSH-7408 หรือ KRNL-6000 ตัวระบุนี้คือสิ่งที่ใช้ค้นหาทั้งคำอธิบายและวิธีปิดการทดสอบ — จำรูปแบบของมันไว้ ทุกอย่างข้างล่างวนอยู่รอบสิ่งนี้

อะไรที่ขยับตัวเลขจริง ๆ

SSH (SSH-7408) ส่วนที่หนักที่สุด: การทดสอบเดียวตรวจพารามิเตอร์เป็นโหลพร้อมกัน อย่าแก้ sshd_config ทั้งไฟล์ ให้วางไฟล์แยกไว้เพื่อไม่ให้การอัปเดตแพ็กเกจลบงานของคุณ:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh

sshd -t ก่อนโหลดบริการใหม่เป็นสิ่งบังคับ: ความผิดพลาดในไฟล์ตั้งค่าขณะที่เซสชันของคุณยังเปิดอยู่จะทิ้งคุณไว้ข้างนอก และก่อนตั้ง PasswordAuthentication no ให้แน่ใจว่าคีย์ใช้งานได้จริง — จากเทอร์มินัลที่สองที่เปิดอยู่

พารามิเตอร์เคอร์เนล (KRNL-6000) การทดสอบตรวจค่า sysctl ราวสองโหล ไฟล์สำหรับพวกมัน:

sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system

เครื่องมือที่ยังไม่มี ข้อเสนอแนะส่วนใหญ่พอสมควรเป็นเพียง «ติดตั้งสิ่งที่ยังไม่มี»: auditd (บันทึกเหตุการณ์ระบบ), aide (ความสมบูรณ์ของไฟล์), debsums (ความสมบูรณ์ของแพ็กเกจ), unattended-upgrades (อัปเดตความปลอดภัยอัตโนมัติ), sysstat และ acct (บัญชีกระบวนการ), ตัวสแกนมัลแวร์ แต่ละตัวปิดข้อเสนอแนะไปหนึ่งหรือสองข้อ แต่อย่าติดตั้งเพื่อคะแนน: ถ้าไม่มีพวกมัน หลังเกิดเหตุคุณจะประกอบอะไรกลับมาไม่ได้เลย

สิ่งเล็ก ๆ ที่คุ้มกับความพยายาม umask 027 ใน /etc/login.defs; อายุรหัสผ่านในไฟล์เดียวกัน; แบนเนอร์ใน /etc/issue และ /etc/issue.net; คอมไพเลอร์ที่อ่านได้เฉพาะ root (chmod 700 /usr/bin/gcc) พูดตรง ๆ เรื่องแบนเนอร์: มันไม่ได้ช่วยเรื่องความปลอดภัยเลย มันเป็นพิธีการทางกฎหมาย — แต่มันให้คะแนนจริง

กับดักหนึ่งใน login.defs

การแก้ umask ด้วยการแทนที่บรรทัดด้วย sed มักทิ้งบรรทัด UMASK ไว้หลายบรรทัดพร้อมกันในไฟล์ Lynis จึงไม่นับค่านั้นเลย และการทดสอบ AUTH-9328 ยังคงเป็นสีแดงทั้งที่การตั้งค่าดูเหมือนทำแล้ว ตรวจหลังการแก้ไข:

grep -c '^UMASK' /etc/login.defs

ต้องมีเพียงหนึ่งเท่านั้น เช่นเดียวกันกับพารามิเตอร์อื่นทุกตัวในไฟล์นั้น

ผลบวกลวงและวิธีปิดปากมันอย่างถูกต้อง

คำเตือนบางข้อใช้ไม่ได้กับเซิร์ฟเวอร์ของคุณเลย ตัวอย่างจริง: บน VPS ของผู้ให้บริการรายใหญ่รายหนึ่ง การทดสอบ PKGS-7388 รายงานว่าไม่พบ repository ความปลอดภัย — เพียงเพราะ repository ถูกอธิบายในรูปแบบ deb822 พร้อมการอ้างอิงไฟล์ mirror และ Lynis กำลังมองหาบรรทัดที่คุ้นเคย อัปเดตความปลอดภัยมาถึงตามปกติดี

ปิดปากมันด้วยโปรไฟล์ ไม่ใช่ด้วยการลบบรรทัดออกจากรายงาน ไฟล์โปรไฟล์ใช้นามสกุล .prf (ไม่ใช่ .prof — ตรงนี้เสียเวลาไปครึ่งชั่วโมงได้ง่าย ๆ) และกฎของคุณเองไปอยู่ที่ /etc/lynis/custom.prf:

skip-test=PKGS-7388
skip-test=KRNL-5788

กฎข้อเดียว: ทุกบรรทัดต้องมีคำอธิบายกำกับว่าทำไมจึงข้ามการทดสอบนั้น อีกหกเดือนคุณจะจำไม่ได้ว่ามันถูกปิดเพราะใช้ไม่ได้หรือเพราะแก้แล้วยุ่งยากเกินไป — และความต่างระหว่างสองกรณีนี้คือประเด็นทั้งหมด

สิ่งที่ไม่ควรทำ

อย่าไล่ตามตัวเลข index เพิ่มได้ง่าย ๆ ด้วยการปิดการทดสอบที่ไม่สะดวก และเลยระดับหนึ่งไปแล้วนั่นคือทางเดียว — เพียงแต่เซิร์ฟเวอร์ไม่ได้ปลอดภัยขึ้นจากการนั้น สิ่งที่มีประโยชน์คืออีกอย่าง: บันทึกค่าของตัวเองไว้แล้วเฝ้าดูการเปลี่ยนแปลง index ที่ลดลงหลังการอัปเดตหรือหลังคนอื่นแก้ไฟล์ตั้งค่าคือสัญญาณที่มีค่ามากกว่าขนาดสัมบูรณ์ของมันมาก

ด้วยเหตุนี้เอง Lynis จึงควรถูกรันตามตารางเวลาแทนที่จะรันครั้งเดียว และควรเก็บรายงานไว้เพื่อให้มีอะไรเทียบ ภาพเมื่อรวมไว้บนหน้าเดียวเป็นอย่างไรดูได้ที่เดโมด้านล่าง: index รายการคำเตือนพร้อมตัวระบุการทดสอบ และอะไรเปลี่ยนไปตั้งแต่การรันครั้งก่อน