Linux baseline hardening: checklist production cho sysadmin từ SSH, sudo đến logging

Linux baseline hardening là bước gia cố nền tảng mà mọi đội vận hành nên hoàn thành trước khi đưa máy chủ vào production. Nhiều sự cố bảo mật không bắt đầu từ zero-day quá phức tạp, mà đến từ những lỗ hổng rất cơ bản: tài khoản dùng chung, SSH mở quá rộng, sudo thiếu kiểm soát, dịch vụ thừa, log không đủ để điều tra, hoặc bản vá bị trì hoãn vì không có quy trình. Bài viết này đi theo góc nhìn thực chiến: xây một checklist hardening chuẩn để áp dụng cho VPS, máy ảo on-prem, cloud instance và cả lab nội bộ.

Thay vì cố biến server thành “bất khả xâm phạm”, mục tiêu đúng hơn là giảm bề mặt tấn công, tăng khả năng quan sát, và giúp đội sysadmin phản ứng nhanh khi có dấu hiệu bất thường. Nếu bạn đang vận hành Ubuntu, Debian, Rocky Linux, AlmaLinux hoặc RHEL, phần lớn checklist dưới đây đều áp dụng được với một vài điều chỉnh nhỏ.

Linux baseline hardening là gì và vì sao cần chuẩn hóa?

Linux baseline hardening là bộ cấu hình tối thiểu để một máy chủ đáp ứng yêu cầu bảo mật và vận hành trước khi chạy workload thật. “Baseline” nghĩa là mức nền bắt buộc: mọi máy đều phải đạt, bất kể chạy web server, database, CI runner hay jump host.

Khi có baseline chuẩn, đội vận hành nhận được ba lợi ích lớn:

Giảm sai sót cấu hình thủ công: mỗi máy được dựng theo cùng một tiêu chuẩn.
Dễ audit và troubleshooting: biết rõ server nào đang lệch chuẩn, lệch ở đâu.
Tăng tốc triển khai production: từ môi trường lab lên staging rồi production ít bị “drift”.

Nếu chưa có checklist hardening, bạn sẽ rất dễ rơi vào tình trạng mỗi admin giữ một “bí kíp riêng”, và đến lúc bàn giao thì không ai chắc máy nào đang bật gì, ai có quyền gì, log đang nằm ở đâu.

Xác định phạm vi trước khi hardening

Trước khi chỉnh cấu hình, cần phân loại máy chủ vì jump box, web server và database server không có cùng mức phơi bày dịch vụ.

Nhóm câu hỏi cần trả lời

Máy chủ này thuộc môi trường nào: lab, staging hay production?
Ai được phép truy cập shell?
Dịch vụ nào buộc phải public ra Internet?
Máy có yêu cầu agent giám sát, backup, EDR hay compliance không?
Đội có dùng Ansible, Puppet, Chef hoặc cloud-init để áp baseline không?

Khi trả lời được các câu hỏi trên, bạn sẽ hardening theo rủi ro thực tế thay vì copy checklist một cách máy móc.

Checklist Linux baseline hardening cho production

1) Chuẩn hóa tài khoản và quyền truy cập

Việc đầu tiên là loại bỏ tài khoản dùng chung và kiểm soát chặt quyền sudo. Mỗi admin nên có tài khoản riêng để audit được ai làm gì.

getent passwd | awk -F: '$3 >= 1000 {print $1":"$7}'
getent group sudo
sudo -l -U ten_nguoi_dung

Giải thích:

Lệnh đầu liệt kê user cục bộ có UID từ 1000 trở lên.
getent group sudo kiểm tra ai đang nằm trong nhóm sudo.
sudo -l -U giúp xem người dùng đang được phép chạy lệnh nào.

Output mẫu:

ops01:/bin/bash
ops02:/bin/bash
deploy:/usr/sbin/nologin
sudo:x:27:ops01,ops02

Khuyến nghị thực tế:

Tắt hoặc khóa tài khoản không còn sử dụng.
Không cho ứng dụng chạy bằng root nếu không thật sự bắt buộc.
Dùng nologin cho service account không cần shell.
Rà lại file /etc/sudoers và thư mục /etc/sudoers.d/ để tránh cấp quyền quá rộng kiểu ALL=(ALL) NOPASSWD:ALL.

2) Hardening SSH để giảm bề mặt tấn công

SSH gần như luôn là cổng đầu tiên bị dò quét. Linux baseline hardening tốt phải bắt đầu từ SSH.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%F)
sudo grep -E '^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|Port|AllowUsers|ClientAliveInterval|MaxAuthTries)' /etc/ssh/sshd_config

Thiết lập khuyến nghị:

PermitRootLogin no
PasswordAuthentication no nếu đã triển khai SSH key an toàn
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300 và ClientAliveCountMax 2
AllowUsers hoặc AllowGroups nếu mô hình vận hành phù hợp

Sau khi sửa cấu hình, luôn kiểm tra syntax trước khi reload:

sudo sshd -t && sudo systemctl reload sshd

Lưu ý production: đừng tắt đăng nhập mật khẩu trên máy từ xa nếu chưa xác nhận SSH key hoạt động ở một phiên khác. Nhiều đội tự khóa chính mình chỉ vì reload quá sớm.

Tham khảo chính thống: tài liệu sshd_config.

3) Bật firewall theo mô hình deny-by-default

Một baseline tốt không giả định rằng security group hoặc firewall biên đã đủ. Trên host vẫn nên có lớp lọc tối thiểu.

Ví dụ với UFW trên Ubuntu/Debian:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Ví dụ với firewalld trên Rocky Linux/AlmaLinux/RHEL:

sudo firewall-cmd --permanent --set-default-zone=public
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Tư duy cần giữ: chỉ mở đúng port cho workload. Nếu ứng dụng chỉ phục vụ qua reverse proxy nội bộ, đừng public port backend ra ngoài.

4) Tắt dịch vụ không cần thiết

Máy chủ cài càng nhiều, bề mặt tấn công càng lớn. Hãy rà lại service đang bật cùng port đang listen.

systemctl list-unit-files --type=service --state=enabled
ss -tulpn

Những gì cần kiểm tra:

Có service demo/test bị quên không?
Có agent cũ của monitoring hoặc backup không còn dùng?
Có database đang listen 0.0.0.0 thay vì bind nội bộ?

Nếu phát hiện dịch vụ thừa:

sudo systemctl disable --now ten-dich-vu

5) Thiết lập cập nhật và patch management an toàn

Linux baseline hardening không thể thiếu chiến lược vá lỗi. Vấn đề không phải chỉ “có update hay không”, mà là update theo cửa sổ bảo trì, có rollback và có kiểm chứng sau cập nhật.

Trên Debian/Ubuntu:

sudo apt update
apt list --upgradable
sudo unattended-upgrade --dry-run --debug

Trên RHEL-family:

sudo dnf check-update
sudo dnf updateinfo list security

Checklist patch production:

Snapshot/backup trước thay đổi lớn.
Xác nhận dependency quan trọng như Docker, Nginx, database driver.
Kiểm tra service health sau reboot.
Ghi lại thay đổi vào changelog hoặc runbook.

Tham khảo thêm: Ubuntu Security Notices và Red Hat Security Advisories.

6) Đồng bộ thời gian và timezone

Khi điều tra sự cố, log sai thời gian gần như phá hỏng toàn bộ timeline. Một baseline vận hành chuẩn phải đảm bảo NTP hoạt động.

timedatectl status
chronyc sources -v

Nếu dùng systemd-timesyncd:

timedatectl show-timesync --all

Mục tiêu là toàn bộ server dùng cùng chuẩn thời gian, nhất quán với monitoring, SIEM và hệ thống ticket.

7) Tăng cường log và audit cơ bản

Linux baseline hardening chỉ thật sự hữu ích nếu sau này bạn còn điều tra được chuyện gì đã xảy ra. Tối thiểu cần chắc rằng journald hoặc rsyslog đang ghi nhận đủ dữ liệu.

journalctl -p err -b
journalctl --disk-usage
sudo systemctl status rsyslog

Với máy nhạy cảm, nên xem xét thêm auditd để theo dõi sự kiện quan trọng như chỉnh sửa file hệ thống, thay đổi quyền hoặc truy cập sudo.

sudo apt install auditd -y
sudo systemctl enable --now auditd
sudo auditctl -l

Ví dụ use case: khi có nghi vấn ai đó sửa /etc/sudoers, log audit giúp xác định thời điểm và tiến trình thực hiện thay đổi.

8) Bảo vệ filesystem và quyền file nhạy cảm

Nhiều máy chủ lâu năm bị “mục” dần vì file permission chồng chéo. Hãy kiểm tra các file và thư mục nhạy cảm:

/etc/passwd
/etc/shadow
/etc/sudoers
private key trong ~/.ssh/
file cấu hình ứng dụng chứa secret

ls -l /etc/passwd /etc/shadow /etc/sudoers
find /home -name authorized_keys -o -name id_rsa -o -name id_ed25519 2>/dev/null | xargs -r ls -l

Khuyến nghị:

Secret không nên nằm trong repo hoặc world-readable.
Mount /tmp hoặc volume dùng chung với tùy chọn phù hợp nếu mô hình ứng dụng cho phép.
Kiểm tra SUID/SGID bất thường bằng lịch audit định kỳ.

9) Kiểm soát kernel parameters ở mức hợp lý

Một số tham số sysctl có thể giảm rủi ro network spoofing hoặc hành vi không mong muốn.

sudo sysctl net.ipv4.conf.all.rp_filter
sudo sysctl net.ipv4.icmp_echo_ignore_broadcasts
sudo sysctl net.ipv4.conf.all.accept_source_route

Ví dụ file baseline trong /etc/sysctl.d/99-hardening.conf:

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

Áp dụng bằng:

sudo sysctl --system

Không nên copy nguyên checklist sysctl từ Internet vào production mà không test. Một số tham số có thể ảnh hưởng network behavior của ứng dụng hoặc overlay network.

10) Bật bảo vệ chống brute-force và hành vi bất thường

Với máy có SSH public, fail2ban vẫn là lớp phòng thủ hữu ích, đặc biệt khi chưa có giải pháp tập trung ở biên.

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Đừng xem fail2ban là thay thế cho SSH key và firewall; nó chỉ là lớp giảm nhiễu và chặn quét tự động.

Mẫu quy trình Linux baseline hardening cho server mới

Dưới đây là flow thực tế mà nhiều đội có thể áp dụng ngay:

Tạo VM hoặc instance từ image chuẩn.
Cập nhật bản vá và cài agent bắt buộc.
Tạo user quản trị cá nhân, nạp SSH key.
Tắt root login qua SSH và khóa password nếu chính sách cho phép.
Cấu hình firewall chỉ mở đúng port cần thiết.
Tắt dịch vụ thừa, kiểm tra process listen.
Bật NTP, logging, audit và backup agent.
Chạy checklist nghiệm thu trước khi giao workload.

Nếu có Ansible, đây là ứng viên rất tốt để biến baseline thành code và giảm khác biệt giữa lab với production.

Lỗi thường gặp khi hardening Linux

Tắt quá tay khiến ứng dụng ngừng hoạt động

Ví dụ đổi cấu hình SSH, firewall hoặc sysctl mà không hiểu dependency của ứng dụng. Cách tránh là luôn test trên lab/staging trước và có phiên console out-of-band khi chỉnh máy production quan trọng.

Chỉ hardening lúc dựng máy, không kiểm tra drift về sau

Baseline không phải việc làm một lần. Sau vài tháng, server thường bị lệch do hotfix, cài package tạm, mở thêm port hoặc trao quyền sudo khẩn cấp rồi quên thu hồi.

Có log nhưng không ai đọc

Log cục bộ không chuyển về nơi tập trung thì lúc máy hỏng hoặc bị xóa dấu vết, bạn gần như mất bằng chứng. Tối thiểu hãy đẩy log quan trọng về syslog server hoặc nền tảng observability tập trung.

Troubleshooting khi áp Linux baseline hardening

Không SSH được sau khi sửa cấu hình

Kiểm tra lại bằng console/serial access.
Chạy sshd -t để xem syntax.
Kiểm tra firewall host và security group cloud.
Xác nhận key nằm đúng trong ~/.ssh/authorized_keys với quyền file chuẩn.

Dịch vụ không khởi động sau khi cập nhật

Xem systemctl status ten-dich-vu
Xem journalctl -u ten-dich-vu -b
Kiểm tra package dependency hoặc thay đổi file config sau merge

Firewall đã mở nhưng ứng dụng vẫn timeout

Kiểm tra ứng dụng có đang listen đúng IP/port bằng ss -tulpn
Đối chiếu firewall host, load balancer, security group và ACL mạng
Dùng curl -v hoặc nc -zv để test từ nguồn truy cập thật

Checklist nghiệm thu trước khi đưa server lên production

SSH root login đã tắt hoặc bị kiểm soát đúng chính sách
Tài khoản admin cá nhân đã tạo, có thể audit
Firewall host chỉ mở đúng port cần dùng
Dịch vụ thừa đã disable
Bản vá bảo mật đã cập nhật theo cửa sổ cho phép
NTP hoạt động, thời gian chính xác
Log hệ thống và audit cơ bản đang ghi nhận
Backup/snapshot đầu tiên đã chạy thành công
Monitoring/alerting agent đã online
Runbook bàn giao đã ghi rõ cấu hình đặc biệt

Bài tập lab: tự dựng checklist Linux baseline hardening

Nếu muốn đội mới vào nghề hiểu sâu hơn, hãy làm lab nhỏ sau:

Dựng 2 VM Ubuntu hoặc Rocky Linux.
Giữ một máy ở trạng thái mặc định, một máy áp baseline hardening.
So sánh bằng các lệnh ss -tulpn, systemctl list-unit-files --state=enabled, sudo -l, journalctl -p err -b.
Mô phỏng brute-force SSH nhẹ trong lab để quan sát log và fail2ban.
Viết lại checklist của riêng đội bạn thành tài liệu nội bộ hoặc playbook Ansible.

Kết luận

Linux baseline hardening không phải “mẹo vặt bảo mật”, mà là nền móng vận hành ổn định cho mọi máy chủ. Khi làm đúng, bạn không chỉ giảm rủi ro bị khai thác mà còn làm cho incident response, audit và bàn giao hệ thống dễ hơn rất nhiều. Nếu đội của bạn đang vận hành server theo kiểu mỗi người nhớ một ít, đây là lúc chuẩn hóa thành checklist, biến checklist thành automation, rồi đo drift định kỳ để baseline luôn còn hiệu lực.

Bắt đầu từ những thứ nhỏ nhưng có tác động lớn: quyền truy cập, SSH, firewall, patching, log và audit. Đó là phần “ít hào nhoáng” của nghề sysadmin, nhưng cũng là phần giữ production sống sót lâu nhất.