3 hướng tiếp cận khi rà soát bảo mật Linux server
Cài đặt xong một máy chủ Linux mới chỉ là bước khởi đầu. Mặc định, OS ưu tiên tính tiện dụng hơn bảo mật: cổng SSH mở cho root, quyền file lỏng lẻo, nhiều dịch vụ chạy nền không cần thiết. Để đưa hệ thống vào khuôn khổ an toàn, đội ngũ vận hành thường chọn một trong ba con đường:
- Kiểm tra thủ công bằng checklist: Quản trị viên tự mở file cấu hình, gõ từng lệnh kiểm tra cổng mạng, đối chiếu quyền file với bảng Excel nội bộ khoảng 100–200 tiêu chí.
- Dùng script quét độc lập (như Lynis): Tiện lợi, chạy một lệnh là có ngay điểm số tổng quan sau 2 phút kèm danh sách khuyến nghị.
- Chuẩn hóa với OpenSCAP: Sử dụng khung SCAP đối chiếu cấu hình thực tế với các bộ tiêu chuẩn quốc tế như CIS Benchmark, PCI-DSS hay STIG. Công cụ này chấm điểm rõ ràng và sinh script vá lỗi tự động.
So sánh ưu và nhược điểm thực tế
Mỗi phương pháp đều phục vụ cho một bài toán riêng:
1. Kiểm tra thủ công
- Ưu điểm: Kỹ sư hiểu sâu từng tham số và lý do đằng sau mỗi thiết lập.
- Nhược điểm: Tốn công sức và dễ sót. Kiểm tra kỹ một máy mất từ 2 đến 3 tiếng. Với cụm 30–50 máy chủ, cách này hoàn toàn bế tắc.
2. Script quét độc lập (Lynis)
- Ưu điểm: Cài đặt nhẹ, quét cực nhanh, phù hợp cho việc đánh giá sơ bộ trước khi bàn giao máy chủ.
- Nhược điểm: Kết quả chủ yếu mang tính tham khảo nội bộ. Khi cần tài liệu chứng minh tuân thủ cho kiểm toán viên quốc tế, các script này thường không đủ trọng lượng pháp lý.
3. Bộ công cụ OpenSCAP
- Ưu điểm: Bám sát chuẩn CIS Benchmark — tiêu chuẩn bắt buộc tại các ngân hàng và tổ chức tài chính. Báo cáo HTML trực quan, phân loại rủi ro chi tiết từng mục. Đặc biệt, OpenSCAP tự tạo kịch bản khắc phục (remediation) tương ứng với từng lỗi phát hiện.
- Nhược điểm: Cú pháp lệnh dài. Hồ sơ quy tắc đồ sộ khiến người mới dễ bị ngợp ở vài lần chạy đầu tiên.
Khi nào bạn nên đưa OpenSCAP vào quy trình?
Thực tế khi audit bảo mật cho hơn 10 hệ thống, mình nhận thấy lỗi thường nằm ở những chi tiết rất nhỏ: PermitRootLogin yes, timeout phiên SSH bỏ trống, hoặc phân quyền thư mục /etc/cron.* quá mở. Nhiều người nghĩ dựng firewall đóng bớt port là an tâm. Thực ra, 70% rủi ro leo thang đặc quyền lại xuất phát từ các thiết lập sai sót ngay trong OS.
Nếu bạn chỉ duy trì một VPS chạy blog cá nhân, Lynis là đủ nhanh gọn. Nhưng nếu bạn quản lý hạ tầng production, cần vượt qua kỳ đánh giá ISO 27001, PCI-DSS, hoặc muốn hardening chuẩn chỉ mà không phải đọc hết 800 trang PDF của CIS, OpenSCAP là giải pháp chuẩn mực nhất.
Các bước quét và áp dụng bản vá CIS Benchmark với OpenSCAP
Dưới đây là quy trình thực tế trên Ubuntu 22.04 LTS và RHEL/Rocky Linux 9.
Bước 1: Cài đặt công cụ và bộ dữ liệu SCAP Security Guide
OpenSCAP gồm công cụ quét (oscap) và thư viện quy tắc bảo mật (SSG).
Trên Ubuntu / Debian:
sudo apt update
sudo apt install -y libopenscap8 scap-security-guideTrên RHEL / Rocky Linux / AlmaLinux:
sudo dnf install -y openscap-scanner scap-security-guideBước 2: Liệt kê các profile bảo mật có sẵn
Mỗi bản phân phối Linux có một tệp DataStream riêng. Chạy lệnh sau để xem danh sách profile hỗ trợ trên Ubuntu 22.04:
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xmlMàn hình sẽ hiển thị các chuẩn như cis_level1_server, cis_level2_server, hay pci-dss. Với hệ thống đang chạy dịch vụ, CIS Level 1 Server là lựa chọn cân bằng nhất. Mức này siết chặt bảo mật nhưng không làm gián đoạn các phần mềm thông thường.
Bước 3: Quét hệ thống và xuất báo cáo HTML
Chạy lệnh đánh giá theo profile CIS Level 1:
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--results-arf /tmp/cis-results.xml \
--report /tmp/cis-report.html \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xmlQuá trình quét mất khoảng 1 đến 3 phút cho hơn 200 bài kiểm tra. Mỗi tiêu chí sẽ trả về kết quả pass, fail, hoặc notapplicable.
Bước 4: Đọc kết quả trên báo cáo trực quan
Tải file /tmp/cis-report.html về máy cá nhân bằng SCP:
scp user@server-ip:/tmp/cis-report.html .Mở file bằng trình duyệt. Bạn sẽ thấy điểm số tuân thủ tổng thể (Compliance Score). Bên dưới là danh sách chi tiết: quy tắc nào vi phạm, mức độ nguy hiểm, lý do lỗi và đoạn mã hướng dẫn sửa tay.
Bước 5: Khắc phục lỗi tự động (Remediation) an toàn
Đừng bao giờ chạy tham số tự sửa lỗi trực tiếp trên máy chủ production. Cách tiếp cận an toàn nhất là trích xuất lệnh sửa lỗi ra một file script Bash để kiểm tra trước:
# Xuất script sửa lỗi dựa trên kết quả quét
sudo oscap xccdf generate fix \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--fix-type bash \
--output /tmp/remediate-cis.sh \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xmlMở /tmp/remediate-cis.sh bằng less hoặc vim. Script này chứa các thiết lập cụ thể: khóa đăng nhập root qua SSH, đặt umask 027, hạn chế coredump, phân quyền lại /etc/shadow về 0000. Khi đã rà soát kỹ và xác nhận không xung đột phần mềm, hãy chạy script:
sudo bash /tmp/remediate-cis.shNếu đang thiết lập một server mới tinh (chưa chạy ứng dụng), bạn có thể quét và tự sửa cùng lúc bằng cờ --remediate:
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--remediate \
--report /tmp/cis-report-after-fix.html \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xmlSau bước này, mở lại báo cáo mới. Điểm tuân thủ thường nhảy từ mức 40–50% lên trên 85%, đa số cảnh báo đỏ đã chuyển thành xanh.
2 lưu ý sống còn để không bị khóa quyền truy cập
Hardening hệ thống rất dễ phản tác dụng nếu bạn chủ quan. Hãy ghi nhớ hai nguyên tắc:
- Luôn giữ ít nhất một phiên SSH đang hoạt động: CIS Benchmark thường tắt xác thực mật khẩu (chỉ cho phép SSH key) và vô hiệu hóa root login. Sau khi chạy script sửa lỗi, tuyệt đối không ngắt terminal hiện tại. Hãy mở một tab terminal mới và thử kết nối SSH vào máy chủ. Nếu đăng nhập bình thường, bạn mới được đóng phiên cũ.
- Thử nghiệm trên Staging trước 48 tiếng: Các thiết lập như siết umask hay tắt kernel module (như cramfs, tipc) có thể khiến Nginx, Docker hoặc cơ sở dữ liệu không khởi động được. Hãy để dịch vụ chạy thử trên Staging ít nhất hai ngày trước khi áp dụng lên Production.
