Lần chạy Lynis đầu tiên trên một VPS mới thường cho ra khoảng 60 kèm một danh sách gợi ý dài mà không rõ nên bắt đầu từ đâu. Tin tốt: 80 đến 85 là công việc của một buổi tối, và phần lớn các bước không phải mang tính hình thức mà thực sự đáng làm. Tin xấu: mười lăm điểm cuối cùng nằm ngoài tầm với trên một máy ảo đi thuê, và đuổi theo chúng là một sai lầm.
Chỉ số cho thấy gì và không cho thấy gì
Chỉ số hardening là tỷ lệ các bài kiểm tra đã qua trên tổng số, có trọng số — chứ không phải phần trăm an toàn. Lynis chạy khoảng ba trăm bài kiểm tra và cho ra hai danh sách riêng: warnings, những thứ trông như vấn đề thật, và suggestions, những thứ có thể cải thiện. Luôn bắt đầu từ cảnh báo; chúng thường chỉ có vài cái.
Một trăm điểm không xảy ra: một số gợi ý đòi hỏi quyết định đưa ra lúc cài hệ thống (phân vùng riêng cho /home, /tmp và /var), một số đòi quyền truy cập bootloader mà VPS không có, và một số mâu thuẫn với nhau. Còn so sánh chỉ số của bạn với của người khác là vô nghĩa: Lynis trừ điểm cho những gì đang chạy trên máy. Mỗi dịch vụ đang chạy là thêm một cổng mở, tệp cấu hình riêng của nó và cả tá gợi ý mới, vì thế những con số cao thường gặp hơn ở nơi chẳng có gì chạy ngoài SSH. Với một máy chủ đang làm việc có trang web, cơ sở dữ liệu và thư, 85 là kết quả tốt.
Hãy chạy nó với quyền root
sudo lynis audit system
Không có sudo, Lynis bỏ qua mọi bài kiểm tra cần đến tệp hệ thống và báo chỉ số thấp hơn — không phải vì máy chủ tệ mà vì các phép kiểm tra không nhìn thấy được. Báo cáo được ghi vào /var/log/lynis-report.dat, nhật ký dễ đọc nằm ở /var/log/lynis.log.
Mỗi dòng kết quả bắt đầu bằng mã định danh bài kiểm tra, chẳng hạn SSH-7408 hay KRNL-6000. Chính mã đó là thứ dùng để tìm cả phần giải thích lẫn cách tắt bài kiểm tra — hãy nhớ hình dạng của nó, mọi thứ bên dưới đều xoay quanh điều này.
Cái gì thực sự làm con số nhích lên
SSH (SSH-7408). Khối nặng nhất: một bài kiểm tra duy nhất xem xét cả tá tham số cùng lúc. Đừng sửa toàn bộ sshd_config; hãy thả vào một tệp riêng để bản cập nhật gói không xóa mất công sức của bạn:
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 trước khi nạp lại dịch vụ là bắt buộc: một lỗi trong tệp cấu hình khi phiên của bạn đang mở sẽ bỏ bạn lại bên ngoài. Và trước khi đặt PasswordAuthentication no, hãy chắc chắn rằng khóa thực sự hoạt động — từ một cửa sổ terminal thứ hai đang mở.
Tham số nhân (KRNL-6000). Bài kiểm tra xem xét khoảng hai chục giá trị sysctl. Tệp dành cho chúng:
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
Các công cụ còn thiếu. Một phần kha khá các gợi ý đơn giản là «hãy cài cái chưa có»: auditd (ghi nhận sự kiện hệ thống), aide (tính toàn vẹn tệp), debsums (tính toàn vẹn gói), unattended-upgrades (cập nhật bảo mật tự động), sysstat và acct (kế toán tiến trình), một trình quét mã độc. Mỗi cái đóng lại một hai gợi ý, nhưng đừng cài chúng vì điểm số: thiếu chúng thì sau một sự cố bạn sẽ chẳng dựng lại được gì.
Những việc nhỏ có tỷ lệ công sức trên lợi ích tốt. umask 027 trong /etc/login.defs; tuổi thọ mật khẩu trong cùng tệp đó; các banner trong /etc/issue và /etc/issue.net; trình biên dịch chỉ root đọc được (chmod 700 /usr/bin/gcc). Nói thật về các banner: chúng chẳng làm gì cho an toàn cả, chúng là thủ tục pháp lý — nhưng đúng là chúng cho điểm.
Một cái bẫy trong login.defs
Việc sửa umask bằng cách thay dòng với sed thường để lại vài dòng UMASK cùng lúc trong tệp. Khi đó Lynis không tính giá trị nào cả, và bài kiểm tra AUTH-9328 vẫn đỏ dù cấu hình trông như đã làm. Hãy kiểm tra sau khi sửa:
grep -c '^UMASK' /etc/login.defs
Phải có đúng một dòng. Điều tương tự áp dụng cho mọi tham số khác trong tệp đó.
Kết quả dương tính giả và cách bịt miệng chúng cho đúng
Một số cảnh báo hoàn toàn không áp dụng cho máy chủ của bạn. Ví dụ sống động: trên VPS của một nhà cung cấp lớn, bài kiểm tra PKGS-7388 báo rằng không tìm thấy kho bảo mật — chỉ đơn giản vì các kho được mô tả theo định dạng deb822 với tham chiếu tới tệp mirror, còn Lynis lại tìm dòng quen thuộc. Bản cập nhật bảo mật vẫn đến hoàn toàn bình thường.
Hãy bịt miệng nó bằng một profile, chứ không phải bằng cách xóa dòng khỏi báo cáo. Tệp profile dùng phần mở rộng .prf (không phải .prof — ở đây rất dễ mất nửa tiếng), và các quy tắc của riêng bạn đi vào /etc/lynis/custom.prf:
skip-test=PKGS-7388
skip-test=KRNL-5788
Một quy tắc: mỗi dòng cần một chú thích bên cạnh nói vì sao bài kiểm tra bị bỏ qua. Sáu tháng sau bạn sẽ không nhớ nó bị tắt vì không áp dụng được hay vì sửa thì quá phiền — và khác biệt giữa hai trường hợp ấy chính là toàn bộ vấn đề.
Điều không nên làm
Đừng đuổi theo con số. Chỉ số rất dễ thổi phồng bằng cách tắt những bài kiểm tra bất tiện, và qua một mức nào đó thì đó là con đường duy nhất — chỉ có điều máy chủ chẳng an toàn hơn vì thế. Cái hữu ích là chuyện khác: hãy ghi lại giá trị của mình và theo dõi sự thay đổi của nó. Một chỉ số tụt xuống sau bản cập nhật hoặc sau khi ai đó sửa tệp cấu hình là tín hiệu giá trị hơn nhiều so với độ lớn tuyệt đối của nó.
Chính vì thế nên chạy Lynis theo lịch thay vì chỉ một lần, và giữ lại các báo cáo để có cái mà so sánh. Khi gom lại trên một trang thì nó trông ra sao — xem ở demo bên dưới: chỉ số, danh sách cảnh báo kèm mã bài kiểm tra, và những gì đã thay đổi so với lần chạy trước.