Tăng cường bảo mật Kernel và Network trên Linux VPS – sysctl, AppArmor và SELinux

Phần lớn hướng dẫn bảo mật VPS dừng lại ở firewall, SSH key, fail2ban. Những thứ đó quan trọng, nhưng chưa đủ. Bên dưới tầng application, Linux kernel có hàng trăm tham số ảnh hưởng trực tiếp đến cách hệ thống xử lý network traffic, memory, và process. Nếu bạn không chủ động cấu hình chúng, VPS của bạn đang chạy với thiết lập mặc định, vốn ưu tiên tương thích hơn là bảo mật.

Bài này mình sẽ đi qua 3 mảng chính: dùng sysctl để tăng cường bảo mật network stack ở tầng kernel, sau đó là AppArmor trên Ubuntu và SELinux trên AlmaLinux để kiểm soát quyền truy cập của từng process.

Kernel tăng cường bảo mật là gì?

Nói đơn giản, kernel tăng cường bảo mật là việc tinh chỉnh các tham số ở tầng OS để giảm bề mặt tấn công. Thay vì chỉ chặn traffic ở firewall, bạn dạy cho kernel cách xử lý traffic thông minh hơn: từ chối packet bất thường, bật bảo vệ chống SYN flood, randomize memory layout để exploit khó hoạt động hơn.

Ít người làm bước này vì nó không “nhìn thấy được” như firewall rules hay fail2ban logs. Nhưng thực tế, đây là lớp phòng thủ rất hiệu quả vì nó hoạt động ở tầng thấp nhất, trước khi traffic đến được application.

Network tăng cường bảo mật với sysctl

Cả Ubuntu và AlmaLinux đều dùng sysctl để quản lý kernel parameters. Các tham số network tăng cường bảo mật dưới đây áp dụng giống nhau cho cả hai distro.

Tạo file cấu hình tăng cường bảo mật

Thay vì sửa trực tiếp /etc/sysctl.conf, mình khuyên bạn tạo file riêng trong /etc/sysctl.d/ để dễ quản lý và không bị ghi đè khi update hệ thống:

sudo nano /etc/sysctl.d/99-hardening.conf

Thêm nội dung sau:

# — Reverse path filtering — chặn packet có source IP giả mạo
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# — Block ICMP redirects — ngăn attacker redirect traffic
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
# — SYN flood protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
# — Ignore broadcast ICMP — chống Smurf attack
net.ipv4.icmp_echo_ignore_broadcasts = 1
# — Log martian packets — ghi log packet có source IP bất thường
net.ipv4.conf.all.log_martians = 1
# — ASLR — randomize memory layout, khiến buffer overflow exploit khó hơn
kernel.randomize_va_space = 2

Giải thích từng tham số

rp_filter = 1 (Reverse Path Filtering): Kernel sẽ kiểm tra mỗi packet đến, nếu source IP không match với routing table thì drop. Điều này ngăn chặn IP spoofing, một kỹ thuật phổ biến trong DDoS và các cuộc tấn công man-in-the-middle.

accept_redirects = 0 và send_redirects = 0: ICMP redirect cho phép router thông báo cho host biết đường đi tốt hơn. Nghe thì tiện, nhưng attacker có thể lợi dụng để chuyển hướng traffic qua máy của họ. Trên VPS, bạn không cần tính năng này.

tcp_syncookies = 1: Khi server nhận quá nhiều SYN request (SYN flood), thay vì allocate memory cho mỗi half-open connection, kernel sẽ dùng SYN cookies để verify client mà không tốn tài nguyên. Đây là tuyến phòng thủ quan trọng chống DDoS.

tcp_max_syn_backlog = 2048: Tăng queue size cho half-open connections. Kết hợp với syncookies, giúp server chịu được lượng SYN request lớn hơn trước khi bắt đầu drop connection hợp lệ.

icmp_echo_ignore_broadcasts = 1: Chặn phản hồi broadcast ICMP. Nếu không bật, VPS của bạn có thể bị lợi dụng trong Smurf attack, nơi attacker gửi broadcast ping với source IP giả mạo để amplify traffic.

log_martians = 1: Ghi log các packet có source address bất thường (ví dụ 192.168.x.x đến từ interface public). Giúp bạn phát hiện sớm các nỗ lực tấn công hoặc misconfiguration trong network.

kernel.randomize_va_space = 2 (ASLR): Address Space Layout Randomization ở mức cao nhất. Kernel sẽ randomize vị trí của stack, heap, libraries trong memory mỗi lần process khởi chạy. Điều này khiến các exploit dựa vào buffer overflow khó thành công hơn nhiều, vì attacker không đoán được địa chỉ memory cần ghi đè.

Apply cấu hình

Sau khi lưu file, apply ngay mà không cần reboot:

sudo sysctl --system

Hoặc load riêng file vừa tạo:

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Kiểm tra xem giá trị đã apply chưa:

sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.conf.all.rp_filter
sysctl kernel.randomize_va_space

Nếu output trả về đúng giá trị bạn set, tức là đã hoạt động. Cấu hình trong /etc/sysctl.d/ sẽ tự động load lại sau mỗi lần reboot.

AppArmor trên Ubuntu

Ubuntu mặc định đã bật AppArmor. Đây là hệ thống Mandatory Access Control (MAC) hoạt động theo mô hình profile: mỗi application có một profile định nghĩa nó được phép truy cập những file, network port, capability nào.

Kiểm tra trạng thái AppArmor

sudo aa-status

Output sẽ cho bạn thấy số lượng profile đang loaded, bao nhiêu ở enforce mode, bao nhiêu ở complain mode, và danh sách process đang bị giới hạn.

Enforce vs Complain mode

AppArmor có 2 chế độ chính cho mỗi profile:

• Enforce: Chặn thật. Nếu process vi phạm profile, hành động bị block và ghi log.
• Complain: Chỉ ghi log, không chặn. Dùng để test profile mới trước khi enforce.

Workflow đúng là: tạo profile mới ở complain mode, chạy vài ngày xem log, confirm không có false positive, rồi mới chuyển sang enforce.

Cài thêm công cụ quản lý

sudo apt install apparmor-utils -y

Package này cung cấp các lệnh aa-enforce, aa-complain, aa-genprof để quản lý profile.

Profile cho Nginx và MySQL

Một số service phổ biến đã có sẵn profile. Kiểm tra profile cho nginx:

# Xem profile nginx (nếu có)
ls /etc/apparmor.d/ | grep nginx
# Cài profile từ extras
sudo apt install apparmor-profiles apparmor-profiles-extra -y

Với MySQL/MariaDB, profile thường được cài sẵn cùng package:

# Kiểm tra profile MySQL
cat /etc/apparmor.d/usr.sbin.mysqld

Chuyển đổi mode

Chuyển một profile sang enforce:

sudo aa-enforce /etc/apparmor.d/usr.sbin.mysqld

Chuyển sang complain để debug:

sudo aa-complain /etc/apparmor.d/usr.sbin.mysqld

Nếu service bị lỗi sau khi enforce profile, chuyển về complain mode trước, kiểm tra log tại /var/log/syslog hoặc journalctl để xem AppArmor đang block gì, rồi điều chỉnh profile cho phù hợp.

SELinux trên AlmaLinux

AlmaLinux (và các distro RHEL-based) dùng SELinux thay vì AppArmor. SELinux mạnh hơn nhưng cũng phức tạp hơn. Nó hoạt động theo mô hình label: mọi file, process, port đều có security context, và policy quyết định context nào được tương tác với context nào.

Kiểm tra trạng thái SELinux

# Xem nhanh mode hiện tại
getenforce
# Xem chi tiết
sestatus

SELinux có 3 mode:

• Enforcing: Chặn và ghi log mọi vi phạm policy. Đây là mode bạn muốn dùng trên production.
• Permissive: Chỉ ghi log, không chặn. Dùng để troubleshoot.
• Disabled: Tắt hoàn toàn. Không nên dùng.

Security context là gì?

Dùng ls -Z để xem context của file:

ls -Z /var/www/html/
# Output ví dụ:
# unconfined_u:object_r:httpd_sys_content_t:s0 index.html

Context có format user:role:type:level. Phần quan trọng nhất là type (ở đây là httpd_sys_content_t). SELinux policy quy định process nào (ví dụ httpd_t) được đọc file type nào (ví dụ httpd_sys_content_t).

Fix context với restorecon

Khi bạn copy hoặc move file, context có thể bị sai. Ví dụ, copy file vào /var/www/html/ nhưng nó vẫn giữ context của thư mục gốc. Kết quả: Nginx/Apache không đọc được file dù permission 644 đúng.

# Fix context cho một file
sudo restorecon -v /var/www/html/index.html
# Fix recursive cho cả thư mục
sudo restorecon -Rv /var/www/html/

Gặp lỗi “Permission denied” mà file permission đúng? 90% là do SELinux context sai. Chạy restorecon -Rv trên thư mục liên quan là bước đầu tiên nên thử.

SELinux Booleans

Booleans là các “công tắc” on/off cho từng tính năng trong SELinux policy. Ví dụ, mặc định httpd không được kết nối ra ngoài. Nếu web app của bạn cần gọi API external:

# Xem boolean hiện tại
getsebool httpd_can_network_connect
# Bật (persistent qua reboot)
sudo setsebool -P httpd_can_network_connect on
# Xem tất cả boolean liên quan đến httpd
getsebool -a | grep httpd

Một số boolean hay dùng:

• httpd_can_network_connect: cho phép httpd kết nối TCP ra ngoài
• httpd_can_network_connect_db: cho phép httpd kết nối database
• httpd_can_sendmail: cho phép httpd gửi mail

Troubleshoot SELinux

Khi SELinux chặn một hành động, nó ghi AVC (Access Vector Cache) denial vào audit log. Đọc log bằng:

# Xem các AVC denial gần nhất
sudo ausearch -m AVC -ts recent
# Xem denial trong 10 phút qua
sudo ausearch -m AVC -ts recent | head -50

Nếu bạn confirm rằng hành động bị chặn là hợp lệ, dùng audit2allow để tạo policy module cho phép nó:

# Tạo module từ AVC denial
sudo ausearch -m AVC -ts recent | audit2allow -M my_custom_policy
# Apply module
sudo semodule -i my_custom_policy.pp

Cẩn thận với audit2allow. Đọc kỹ output trước khi apply, vì nó có thể tạo policy quá rộng nếu bạn feed tất cả AVC denial vào mà không lọc. Chỉ allow đúng những gì cần thiết.

Tại sao không nên disable SELinux

Mình biết nhiều người gặp lỗi là disable SELinux cho nhanh. Xin đừng làm vậy. Lý do:

• SELinux là lớp bảo vệ cuối cùng. Nếu attacker exploit được web app và có shell, SELinux vẫn giới hạn những gì process đó được làm. Tắt SELinux nghĩa là mất luôn lớp phòng thủ này.
• Hầu hết lỗi liên quan SELinux là do context sai hoặc cần bật boolean. Hai thứ này fix trong 1 phút, không cần disable cả hệ thống.
• Sau khi disable và chạy một thời gian, bật lại SELinux sẽ cần relabel toàn bộ filesystem, tốn thời gian và có thể gây downtime.

Nếu cần debug, chuyển sang Permissive mode thay vì Disabled:

# Chuyển tạm sang Permissive (không cần reboot)
sudo setenforce 0
# Chuyển lại Enforcing sau khi debug xong
sudo setenforce 1

So sánh AppArmor và SELinux

Tiêu chí	AppArmor (Ubuntu)	SELinux (AlmaLinux)
Mô hình	Path-based (dựa trên đường dẫn file)	Label-based (dựa trên security context)
Độ phức tạp	Đơn giản hơn, dễ viết profile	Phức tạp hơn, nhưng kiểm soát chi tiết hơn
Mặc định trên	Ubuntu, Debian, SUSE	RHEL, AlmaLinux, Rocky, Fedora
Profile/Policy	Mỗi app một profile text file	Policy module biên dịch, áp dụng toàn hệ thống
Debug	aa-status, syslog	ausearch, audit2allow, sealert
Rename/move file	Profile vẫn áp dụng (theo path)	Context có thể thay đổi, cần restorecon
Phù hợp khi	Cần bảo vệ nhanh, team nhỏ	Cần compliance cao, enterprise, multi-tenant

Không có cái nào “tốt hơn” tuyệt đối. AppArmor dễ tiếp cận hơn cho người mới. SELinux mạnh hơn cho môi trường đòi hỏi kiểm soát chặt chẽ. Quan trọng là bạn dùng cái có sẵn trên distro của mình, đừng tắt nó đi.

Kiểm tra tăng cường bảo mật đã hoạt động

Sau khi apply sysctl, bạn có thể verify bằng cách đọc trực tiếp từ /proc:

# SYN cookies
cat /proc/sys/net/ipv4/tcp_syncookies
# Mong đợi: 1
# Reverse path filtering
cat /proc/sys/net/ipv4/conf/all/rp_filter
# Mong đợi: 1
# ASLR
cat /proc/sys/kernel/randomize_va_space
# Mong đợi: 2
# ICMP redirects
cat /proc/sys/net/ipv4/conf/all/accept_redirects
# Mong đợi: 0

Kiểm tra AppArmor (Ubuntu):

sudo aa-status | head -10

Kiểm tra SELinux (AlmaLinux):

getenforce
# Mong đợi: Enforcing
sestatus

Checkpoint

Đến đây bạn đã hoàn thành kernel và network tăng cường bảo mật. Trước khi qua bài tiếp, hãy confirm:

1. File /etc/sysctl.d/99-tăng cường bảo mật.conf đã tạo với đầy đủ tham số
2. Đã chạy sysctl --system hoặc sysctl -p để apply
3. Verify bằng cat /proc/sys/net/ipv4/tcp_syncookies trả về 1
4. Ubuntu: aa-status cho thấy AppArmor đang enforce
5. AlmaLinux: getenforce trả về Enforcing

Nếu tất cả check đều pass, VPS của bạn đã có thêm một lớp bảo vệ ở tầng kernel. Lớp này hoạt động âm thầm nhưng rất hiệu quả trong việc ngăn chặn các cuộc tấn công phổ biến như IP spoofing, SYN flood, và privilege escalation.