Kiểm toán và Tinh chỉnh Tham số Sysctl cho Database
Phân tích các tham số Sysctl quan trọng
Các tham số trong /proc/sys (sysctl) điều khiển hành vi của Kernel Linux, ảnh hưởng trực tiếp đến hiệu năng I/O, bộ nhớ và khả năng chống tấn công của Database.
Đối với Database, chúng ta cần tập trung vào 3 nhóm tham số: Network (tối ưu TCP), Memory (quản lý Swap và Transparent Huge Pages), và Security (giảm bề mặt tấn công).
Thiết lập file cấu hình /etc/sysctl.conf
Thao tác này sẽ ghi đè hoặc bổ sung các tham số an toàn và hiệu năng vào file cấu hình chính của hệ thống. Chúng ta sẽ tắt các tính năng không cần thiết để giảm Attack Surface và điều chỉnh bộ đệm mạng.
Tạo hoặc chỉnh sửa file /etc/sysctl.d/99-db-hardening.conf (sử dụng thư mục sysctl.d để không làm rối file sysctl.conf gốc).
cat > /etc/sysctl.d/99-db-hardening.conf
Kết quả mong đợi: File /etc/sysctl.d/99-db-hardening.conf được tạo thành công với nội dung chính xác.
Áp dụng và Kiểm tra Sysctl
Sau khi tạo file cấu hình, cần tải các tham số vào Kernel ngay lập tức và kiểm tra xem chúng có hiệu lực không.
sysctl --system
Kết quả mong đợi: Xuất hiện dòng Reading configuration from /etc/sysctl.d/99-db-hardening.conf và không có lỗi error: "setting key ... failed".
Để verify từng tham số quan trọng:
sysctl vm.swappiness fs.file-max net.ipv4.ip_forward net.ipv4.tcp_tw_reuse
Kết quả mong đợi:
vm.swappiness trả về 10
fs.file-max trả về 2097152
net.ipv4.ip_forward trả về 0
net.ipv4.tcp_tw_reuse trả về 1
Cấu hình Giới hạn Tài nguyên (Limits) cho User Database
Hiểu về Limits.conf và các chỉ số quan trọng
File /etc/security/limits.conf cho phép đặt giới hạn tài nguyên cho từng user hoặc group. Đối với Database, 2 chỉ số quan trọng nhất là nofile (số lượng file descriptors mở) và nproc (số lượng tiến trình).
Nếu không cấu hình, Database sẽ bị giới hạn mặc định của hệ thống (thường là 1024), dẫn đến lỗi Too many open files khi load cao.
Chỉnh sửa file /etc/security/limits.conf
Thao tác này bổ sung các giới hạn cao cho user chạy Database (giả sử user là postgres hoặc mysql). Chúng ta cần đặt giới hạn cho cả soft (có thể vượt qua tạm thời) và hard (giới hạn tuyệt đối).
Sử dụng echo để append nội dung vào file, tránh ghi đè các cấu hình khác.
cat >> /etc/security/limits.conf
Kết quả mong đợi: File /etc/security/limits.conf được cập nhật thêm các dòng cấu hình mới ở cuối file.
Đảm bảo PAM Module hoạt động
Các giới hạn trong limits.conf chỉ có hiệu lực nếu module pam_limits.so được kích hoạt trong /etc/pam.d/system-auth (RHEL/CentOS) hoặc /etc/pam.d/common-session (Debian/Ubuntu).
Kiểm tra xem dòng module này có tồn tại không:
grep "pam_limits.so" /etc/pam.d/system-auth /etc/pam.d/common-session 2>/dev/null
Kết quả mong đợi: Tìm thấy dòng chứa session required pam_limits.so. Nếu không tìm thấy, cần thêm dòng này vào file tương ứng.
Để thêm (ví dụ cho RHEL/CentOS):
sed -i '/session.*pam_loginuid.so/a session required pam_limits.so' /etc/pam.d/system-auth
Kết quả mong đợi: Module pam_limits được thêm vào, đảm bảo limits được áp dụng khi login.
Verify Kết quả và Xử lý sự cố
Kiểm tra Limits đang áp dụng
Cấu hình limits.conf chỉ có hiệu lực cho các session đăng nhập mới. Do đó, phải đăng xuất và đăng nhập lại, hoặc khởi động lại service Database.
Khởi động lại service Database (ví dụ PostgreSQL):
systemctl restart postgresql
Sau khi restart, kiểm tra giới hạn của tiến trình Database đang chạy:
ulimit -Hn
ulimit -Sn
Hoặc kiểm tra trực tiếp trên PID của tiến trình master:
cat /proc/$(pgrep -f "postgres: main process")/limits | grep "Max open files"
Kết quả mong đợi: Giá trị Max open files phải là 65535 (hoặc giá trị bạn đã set). Nếu vẫn là 1024 hoặc 4096, nghĩa là cấu hình chưa áp dụng.
Xác nhận các thay đổi Sysctl
Thực hiện lại lệnh kiểm tra để đảm bảo các tham số bảo mật đã được áp dụng đúng sau khi reboot (nếu cần).
sysctl -a | grep -E "rp_filter|ip_forward|swappiness|transparent_hugepages"
Kết quả mong đợi: Tất cả các giá trị trả về phải khớp với nội dung trong file 99-db-hardening.conf.
Chạy Test Load để xác minh hiệu năng
Sử dụng công cụ benchmark đơn giản để đảm bảo việc hardening không gây lỗi Too many open files hoặc Out of memory ngay lập tức.
Với PostgreSQL, sử dụng pgbench:
pgbench -i -s 100 -U postgres
pgbench -c 20 -j 4 -T 60 -U postgres
Kiểm tra log lỗi của Database trong quá trình chạy:
grep -i "error" /var/log/postgresql/postgresql-*.log | tail -20
Kết quả mong đợi: Không xuất hiện lỗi liên quan đến Too many open files, cannot fork process, hoặc kernel: Out of memory.
Điều hướng series:
Mục lục: Series: Triển khai Database an toàn với Linux Kernel Hardening và eBPF
« Phần 1: Chuẩn bị môi trường và kiến trúc cơ bản cho Database an toàn
Phần 3: Cấu hình AppArmor và SELinux để cô lập Database »