Bẫy “Chạy được là tốt rồi”: Tại sao cấu hình mặc định lại là rủi ro bảo mật
Cài đặt xong một máy chủ Linux mới và thấy các dịch vụ báo đèn xanh là một cảm giác rất tuyệt vời. Web server hoạt động, firewall cho phép lưu thông qua cổng 443, mọi thứ trông thật hoàn hảo. Nhưng có một vấn đề: “mặc định” hiếm khi đi đôi với “bảo mật”. Hầu hết các bản phân phối Linux ưu tiên tính tương thích hơn là việc thắt chặt an ninh. Chúng thường đi kèm với các giao thức cũ được bật sẵn và các thiết lập nới lỏng để đảm bảo phần cứng của bạn hoạt động không gặp lỗi.
Tôi đã rút ra bài học này một cách xương máu khi một máy chủ VPS mới của mình hứng chịu 8.500 lần thử đăng nhập SSH thất bại từ 140 địa chỉ IP khác nhau chỉ trong vòng chưa đầy sáu tiếng. File log của tôi trở nên hỗn loạn. Nếu tôi không đổi cổng SSH và chỉ cho phép xác thực bằng public key, câu chuyện có lẽ đã kết thúc bằng một cơ sở dữ liệu bị xâm nhập thay vì chỉ là một file log phình to. Một hệ thống hoạt động tốt không có nghĩa là nó an toàn.
Việc tăng cường bảo mật (hardening) máy chủ một cách thủ công là một công việc cực nhọc. Bạn phải kiểm tra hơn 200 thiết lập riêng biệt, từ các tham số kernel cho đến quyền truy cập file. Chỉ cần bỏ sót một chi tiết nhỏ—như một file cấu hình có quyền ghi cho tất cả mọi người hoặc một biến sysctl không an toàn—là đủ để kẻ tấn công leo thang đặc quyền.
Khoảng cách giữa “Chạy được” và “Được bảo mật”
Sự phức tạp là lý do chính khiến chúng ta thường để máy chủ ở trạng thái dễ bị tổn thương. Khi bạn cài đặt một gói phần mềm mới, người duy trì gói đó sẽ cung cấp một cấu hình được thiết kế để chạy trên nhiều môi trường nhất có thể. Họ sẽ không tắt một tính năng mà 5% người dùng có thể cần, ngay cả khi tính năng đó tạo ra một lỗ hổng bảo mật lớn.
Bảo mật cũng trở nên mang tính chủ quan một cách nguy hiểm nếu thiếu đi một khung chuẩn chính thức. Một quản trị viên có thể nghĩ việc tắt đăng nhập root là “đủ tốt rồi”. Một người khác lại khăng khăng yêu cầu các hạn chế trong fstab như nosuid và nodev. Nếu không có một tiêu chuẩn khắt khe được ngành công nhận, vị thế bảo mật của bạn chỉ phụ thuộc vào trí nhớ và sự kiên nhẫn của người dựng máy.
Hardening thủ công so với Kiểm định tự động
Thông thường bạn có ba cách để thu hẹp khoảng cách bảo mật này:
- Checklist thủ công: Bạn làm theo một file PDF dài 300 trang và chạy từng lệnh một. Cách này chậm và dễ sai sót. Sớm muộn gì bạn cũng sẽ bỏ lỡ một bước hoặc gõ sai lệnh.
- Shell Script tự viết: Bạn tạo ra một công cụ
hardening.sh. Cách này hiệu quả cho đến khi hệ điều hành cập nhật. Việc duy trì script tương thích khi nâng cấp từ Ubuntu 22.04 lên 24.04 sẽ trở thành một gánh nặng bảo trì. - Các công cụ chuẩn SCAP: Security Content Automation Protocol (SCAP) là tiêu chuẩn chuyên nghiệp cho việc quét lỗ hổng. OpenSCAP cho phép bạn kiểm định hệ thống dựa trên CIS Benchmarks—tiêu chuẩn vàng cho bảo mật hệ điều hành.
Đối với các môi trường production, OpenSCAP là lựa chọn hợp lý nhất. Nó cung cấp một cách thức chính quy, có thể lặp lại để xác định các chính sách bảo mật và tạo ra các báo cáo sẵn sàng cho việc kiểm tra tuân thủ.
Từng bước: Tự động hóa tuân thủ với OpenSCAP
OpenSCAP đóng vai trò như một kiểm toán viên tự động. Nó quét cấu hình của bạn dựa trên các profile đã thiết lập, xác định chính xác lỗi ở đâu và cung cấp mã cần thiết để khắc phục vấn đề.
1. Cài đặt Engine và Security Guides
Bạn cần engine quét và ‘Security Guide’ (chứa các quy tắc thực tế). Trên Debian hoặc Ubuntu, hãy cài đặt qua apt:
sudo apt update
sudo apt install -y libopenscap8 scap-security-guideĐối với RHEL, AlmaLinux hoặc Rocky Linux, tên gói có thay đổi một chút:
sudo dnf install -y openscap-scanner scap-security-guide2. Chọn Security Profile
Các quy tắc được lưu trữ trong các file ‘DataStream’ bên trong thư mục /usr/share/xml/scap/ssg/content/. Những file này chứa các profile khác nhau như PCI-DSS, STIG và CIS. Để xem các profile khả dụng cho hệ thống Ubuntu 22.04, hãy chạy lệnh:
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xmlHãy tìm ID có nhãn xccdf_org.ssgproject.content_profile_cis. Đây là profile chúng ta sẽ sử dụng để đo lường máy chủ dựa trên các tiêu chuẩn của Center for Internet Security (CIS).
3. Chạy kiểm định bảo mật
Bây giờ, hãy thực hiện việc quét. Lệnh này sẽ đánh giá hệ thống và tạo ra một báo cáo HTML chi tiết. Bước này an sau; nó chỉ quan sát và không thay đổi bất kỳ thiết lập nào của bạn.
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis \
--report cis_report.html \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xmlTerminal của bạn sẽ hiển thị một danh sách các kết quả Pass và Fail. Sau khi hoàn tất, hãy mở file cis_report.html trong trình duyệt để xem phân loại chi tiết điểm số bảo mật của bạn.
4. Khắc phục các lỗi
Đừng hoảng loạn nếu một máy chủ mới cài đặt có điểm số dưới 40%. Bạn có thể sẽ thấy các lỗi nghiêm trọng ở ba khu vực chính:
- Phân vùng (Partitioning): Thiếu các cờ
nodev,nosuid, hoặcnoexectrên các phân vùng/tmphoặc/dev/shm. - Kiểm toán (Auditing): Dịch vụ auditd không theo dõi việc xóa file hoặc các thay đổi của quản trị viên.
- Mạng (Networking): Chế độ IP forwarding đang bật, hoặc hệ thống vẫn chấp nhận các gói ICMP redirect.
OpenSCAP cung cấp hai phương pháp khắc phục. Báo cáo HTML bao gồm phần ‘Remediation’ (Khắc phục) cho mọi quy tắc, hiển thị chính xác lệnh hoặc dòng cấu hình cần thiết để sửa lỗi thủ công.
Ngoài ra, bạn có thể sử dụng tính năng tự động khắc phục để áp dụng các bản sửa lỗi ngay lập tức:
# CẨN TRỌNG: Lệnh này sẽ chỉnh sửa trực tiếp các file hệ thống
sudo oscap xccdf eval \
--remediate \
--profile xccdf_org.ssgproject.content_profile_cis \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xmlTránh chạy --remediate một cách mù quáng trên các máy chủ đang hoạt động (production). Một số quy tắc, như thắt chặt quyền hạn trên các file thực thi hệ thống, có thể làm hỏng các ứng dụng cũ nhất định. Thay vào đó, hãy sử dụng kết quả từ báo cáo để cập nhật các Ansible playbook của bạn. Điều này đảm bảo hạ tầng của bạn được bảo mật ngay từ khâu thiết kế.
Bảo mật là một quy trình, không phải là một đầu việc
Hardening không phải là một dự án làm một lần là xong. Sự tuân thủ sẽ bị giảm sút mỗi khi lập trình viên cài đặt một công cụ mới hoặc tinh chỉnh một file cấu hình. Để luôn chủ động, hãy tích hợp OpenSCAP vào một cron job hàng tuần hoặc vào pipeline CI/CD của bạn. Bằng cách tự động hóa các lần quét này và xem xét báo cáo hàng tuần, bạn sẽ ngăn chặn tình trạng “lệch cấu hình” (configuration drift) biến máy chủ của mình thành mục tiêu dễ dàng cho cuộc tấn công brute-force tiếp theo.
