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

Series

Quản trị Linux VPS

Bạn đang xem1/39

Xem trang series·Tất cả series

Cơ bản

• 1. VPS Linux là gì và đăng nhập SSH lần đầu
• 2. Cấu trúc thư mục Linux – Mọi thứ nằm ở đâu trên VPS
• 3. Quản lý file và thư mục trên Linux – Lệnh cơ bản cho VPS
• 4. Hướng dẫn sử dụng lệnh cp sao chép trong Linux
• 5. Quyền file và thư mục trên Linux – chmod, chown và rwx
• 6. Hướng dẫn sử dụng lệnh chattr trong Linux
• 7. User, Group và Sudo trên Linux – Quản lý tài khoản VPS
• 8. Hướng dẫn tạo và sử dụng SSH Key
• 9. Quản lý package trên Linux – apt và dnf cho VPS
• 10. Quản lý process trên Linux – ps, kill, htop cho VPS
• 11. Hướng dẫn phân tích, giải thích lệnh TOP trong Linux
• 12. Systemd và quản lý service trên Linux VPS
• 13. Networking cơ bản trên Linux VPS – IP, DNS, curl và wget
• 14. 20 lệnh Netstat để quản lý mạng Linux
• 15. 12 lệnh ss trên Linux hữu ích
• 16. Hướng dẫn sử dụng Ping và Tracert
• 17. Hướng dẫn cấu hình Static IP trên Ubuntu và AlmaLinux
• 18. Firewall trên Linux VPS – UFW và firewalld từ cơ bản đến thực tế

Nâng cao

• 19. Đọc log hệ thống trên Linux VPS – journalctl và /var/log
• 20. Grep, Pipe và Redirect trên Linux – Xử lý text như pro
• 21. Quản lý disk trên Linux VPS – kiểm tra dung lượng, mount, lsblk, fdisk và mở rộng ổ đĩa
• 22. Backup VPS Linux – rsync, tar và chiến lược sao lưu toàn diện
• 23. Hướng dẫn rsync dữ liệu giữa hai máy chủ không cần mật khẩu
• 24. Lệnh backup/import database MySQL/PostgreSQL trên máy chủ Linux
• 25. Shell Scripting cơ bản trên Linux – Tự động hóa tác vụ VPS
• 26. Tạo Bot cảnh báo đăng nhập SSH qua Telegram
• 27. Tạo script Monitor tài nguyên VPS và thông báo qua Telegram
• 28. Tạo Script khởi động lại MySQL khi bị stop trên máy chủ Linux
• 30. Troubleshooting VPS Linux – Cách xủ lý sự cố VPS phổ biến

Bảo mật

• 29. Checklist bảo mật VPS Linux – 15 bước thiết yếu
• 31. Tổng quan bảo mật VPS Linux – Hiểu rõ mối nguy trước khi phòng thủ
• 32. Bảo vệ SSH toàn diện trên Linux VPS
• 33. User và Permission nâng cao trên Linux VPS – Least Privilege
• 34. Firewall nâng cao trên Linux VPS – UFW và firewalld cho production
• 35. CrowdSec trên Linux VPS – IDS thế hệ mới thay thế Fail2ban
• 36. Cập nhật hệ thống tự động trên Linux VPS – unattended-upgrades và dnf-automatic
• 37. Logging, Monitoring và IDS trên Linux VPS – auditd, AIDE và Wazuh
• 38. Lynis – Tự kiểm tra bảo mật Linux VPS
• 39. Backup và phục hồi sự cố cho VPS Linux – Kế hoạch toàn diện

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

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.