Osi-Layer7 on Roduygo | Blog

IDS/IPS với Suricata & Cân bằng tải

Thu, 21 May 2026 23:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài viết trước, chúng ta đã xây dựng thành công Vành đai Tường lửa (Firewall) vững chắc, nhưng Firewall truyền thống chỉ kiểm tra được lớp vỏ bên ngoài của gói tin. Để phát hiện được những mã độc nằm sâu bên trong “thùng hàng” dữ liệu và điều phối lưu lượng mạng khổng lồ, hệ thống cần được trang bị thêm “con mắt ma thuật” và “bộ não” thông minh. Hôm nay, chúng ta sẽ đi sâu vào phân tích hệ thống phát hiện/ngăn chặn xâm nhập (IDS/IPS) với Suricata, đồng thời làm rõ nghệ thuật Cân bằng tải (Load Balancing) ở Layer 4 và Layer 7.

1. Ranh giới giữa “Quan sát” và “Hành động”: IDS vs IPS

IDS (Intrusion Detection System) và IPS (Intrusion Prevention System) đều là các công nghệ bảo mật giúp phát hiện và cảnh báo hoạt động trái phép dựa trên chữ ký, trí tuệ nhân tạo hoặc các hành vi bất thường. Tuy nhiên, vị trí đứng và quyền sinh sát của chúng trong mạng lưới lại hoàn toàn khác nhau.

1.1 Giám sát thụ động với IDS (Passive Monitoring)

IDS hoạt động theo cơ chế Promiscuous Mode (Chế độ hỗn tạp). Điều này có nghĩa là nó chỉ copy một bản sao dữ liệu từ Switch (thông qua cổng SPAN/Mirror) để phân tích mà không hề can thiệp vào luồng đi của gói tin gốc.

Ví dụ, khi bạn đang tải một file qua FTP không bảo mật, IDS sẽ soi gói tin và phát hiện nội dung Clear-text truyền đi. Lúc này, nó sẽ kích hoạt Signature-based Detection và bắn một Alert lên màn hình SOC: “Cảnh báo: Phát hiện truyền tin Clear-text trên cổng 21!”. Tuy nhiên, vì nó chỉ quan sát, tệp tin của bạn vẫn sẽ được tải về bình thường.

1.2 Kiểm tra trực diện với IPS (In-line Inspection)

Trái ngược với sự thụ động của IDS, IPS đứng ngay giữa đường truyền mạng giống như một trạm thu phí (In-line Inspection). Mọi gói tin bắt buộc phải đi xuyên qua thân xác nó. Nếu gói tin sạch thì được đi tiếp, còn gói tin “bẩn” chứa mã độc sẽ bị Drop (Hủy) ngay lập tức.

Trong thực tế, nếu kẻ xấu thực hiện Brute Force SSH với hàng trăm gói tin từ một IP lạ, IPS sẽ dùng Statistical Anomaly-based Detection để nhận diện bất thường. Nó không chỉ báo cáo mà còn tự động tạo một Rule trên tường lửa để Block/Deny IP đó ngay tức khắc, khiến kẻ tấn công chỉ nhận được thông báo Connection timed out.

Cảnh báo SOC: Việc triển khai IPS tuy an toàn tuyệt đối nhưng lại mang rủi ro “nghẽn cổ chai” mạng hoặc chặn nhầm (False Positive) lưu lượng hợp lệ. Trong thực tiễn vận hành SOC, các hệ thống giám sát mới sẽ luôn được chạy ở chế độ IDS (chỉ nhận cảnh báo) một thời gian dài để “học” hành vi mạng, trước khi được chuyển sang bật chế độ IPS (chặn cắt tự động).

2. Thực chiến cấu hình IPS Suricata chặn Ping

Để biến Suricata từ một “kẻ quan sát” thành một “vệ sĩ” thực thụ mang tính chất IPS, chúng ta phải dùng iptables để tóm các gói tin ICMP (Ping) và đẩy chúng vào một hàng chờ (Queue) để Suricata trực tiếp duyệt và ra lệnh hủy.

# Đẩy gói tin Ping (ICMP) chiều vào (INPUT) sang hàng chờ NFQUEUE số 0
sudo iptables -I INPUT -p icmp -j NFQUEUE --queue-num 0

# Đẩy gói tin Ping (ICMP) chiều ra (OUTPUT) sang hàng chờ NFQUEUE số 0
sudo iptables -I OUTPUT -p icmp -j NFQUEUE --queue-num 0

# Mở file rule của Suricata để thêm luật Drop ICMP
sudo nano /var/lib/suricata/rules/local.rules

# Khởi chạy Suricata trỏ vào file luật vừa tạo và lắng nghe trên card mạng enp7s0
sudo suricata -S /var/lib/suricata/rules/local.rules -i enp7s0

# Theo dõi log cảnh báo và hành động chặn (Drop) theo thời gian thực
sudo tail -f /var/log/suricata/fast.log

Sau khi cấu hình, nếu bạn thực hiện lệnh ping 8.8.8.8, gói tin sẽ bị tóm vào NFQUEUE. Thay vì nhận được phản hồi Ping thành công, màn hình của bạn sẽ báo Request Timeout, và trong file fast.log sẽ liên tục xuất hiện nhãn [wDrop] chứng tỏ IPS đã ra tay chặn đứng thành công.

3. Nghệ thuật Cân bằng tải (Load Balancer)

Bên cạnh bảo mật, Cân bằng tải (Load Balancing) là kỹ thuật sống còn để điều phối lưu lượng giao thông mạng, đảm bảo các máy chủ không bao giờ bị “nghẽn cổ chai” khi có lượng lớn người truy cập cùng lúc.

3.1 Cân bằng tải Lớp 4 (L4 Load Balancing)

Kiểu cân bằng này điều phối giao thông dựa trên giao thức TCP/UDP ở Tầng 4. Nó chỉ nhìn vào Địa chỉ IP Đích và Số cổng (Port) để ra quyết định — không cần quan tâm nội dung bên trong gói tin chứa cái gì. Nhờ việc không phải giải mã nội dung (Decapsulation), cách này có tốc độ xử lý cực kỳ nhanh (ví dụ: IPVS trên Linux, F5 Big-IP).

3.2 Cân bằng tải Lớp 7 (L7 Load Balancing)

Đây là kiểu cân bằng tải “thông minh” hoạt động ở Tầng Ứng dụng, thường dựa trên giao thức HTTP/HTTPS. L7 Load Balancer có khả năng “soi” sâu vào nội dung của URL, Header hoặc Cookie.

Nó cực kỳ linh hoạt và phù hợp cho kiến trúc Microservices. Ví dụ, nếu người dùng truy cập ezlearn.com/api/v1/chat, nó sẽ đẩy sang cụm máy ảo xử lý Chat; còn nếu truy cập ezlearn.com/static/images, nó lại đẩy sang cụm lưu trữ hình ảnh (ví dụ: Nginx, HAProxy).

3.3 Cân bằng tải mức DNS (DNS Load Balancing)

Đây là kiểu cân bằng nằm ở “vòng ngoài cùng” trước khi gói tin chạm tới hệ thống của bạn. Khi bạn gõ google.com, máy chủ DNS sẽ tự động xoay vòng (Round Robin) và trả về các địa chỉ IP khác nhau cho những người dùng khác nhau.

4. Demo thực chiến Nginx Load Balancer (Round Robin)

Để thấy rõ cách một L7 Load Balancer chia việc, chúng ta dùng Nginx thiết lập thuật toán Round Robin (Chia đều) cho 2 máy chủ Python.

# Bật máy chủ backend số 1 chạy nền ở cổng 8001
python3 -m http.server 8001 &

# Bật máy chủ backend số 2 chạy nền ở cổng 8002
python3 -m http.server 8002 &

# Sửa file cấu hình của Nginx để điều hướng tải giữa 2 máy chủ trên
sudo nano /etc/nginx/conf.d/lb.conf

# Kiểm tra xem file cấu hình Nginx có bị lỗi cú pháp không
sudo nginx -t

# Khởi động lại dịch vụ Nginx để áp dụng cấu hình Load Balancer
sudo systemctl restart nginx

# Gửi request kiểm tra đến Nginx ở cổng 8080
curl -I http://127.0.0.1:8080

Với cơ chế Round Robin, mỗi request curl mới sẽ được Nginx luân phiên gửi sang backend kế tiếp trong danh sách (gói thứ nhất vào 8001, gói thứ hai vào 8002). Nếu bạn dùng Wireshark với bộ lọc http && (tcp.port == 8001 || tcp.port == 8002), bạn sẽ thấy rõ sự phân tán luồng cực kỳ nhịp nhàng này.

Việc kết hợp IDS/IPS để thanh lọc mã độc và Load Balancer để điều phối luồng truy cập giúp hệ thống mạng doanh nghiệp đạt được cả hai yếu tố: Bảo mật vững chắc và Hiệu năng tối đa. Tuy nhiên, hacker luôn tìm cách lẩn trốn, và chúng có thể dùng Proxy hoặc VPN để mã hóa toàn bộ dữ liệu, khiến cả IDS lẫn IPS đều bị “mù”. Trong Bài 13 tiếp theo, chúng ta sẽ phân tích cách VPN hoạt động ở Tầng 3 và nghệ thuật Vượt rào & Ẩn danh (Proxy vs VPN). Hãy cùng đón đọc nhé!

Quản trị từ xa (SSH) & Lỗ hổng Terrapin (CVE-2023-48795)

Thu, 21 May 2026 22:57:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài trước, chúng ta đã thấy SFTP tận dụng sự kiên cố của kiến trúc đường hầm SSH để bảo vệ việc truyền tải dữ liệu. Tuy nhiên, vỏ bọc nào cũng có điểm yếu chí mạng nếu quá trình “đàm phán” ban đầu bị thao túng. Hôm nay, chúng ta sẽ đi sâu vào kỹ thuật quản trị từ xa bằng SSH, giải phẫu cơ chế nhận diện Fingerprint và mổ xẻ lỗ hổng Terrapin (CVE-2023-48795) — đòn tấn công tinh vi đánh thẳng vào tính toàn vẹn của quá trình bắt tay.

1. SSH (Secure Shell) - “Vua” của dòng lệnh từ xa

SSH (hoạt động ở Cổng 22) ra đời để thay thế cho giao thức Telnet lỗi thời, được sử dụng chủ yếu để đăng nhập và điều khiển các máy chủ Linux từ xa với độ bảo mật cực cao.

Bản chất của SSH là tạo ra một đường hầm mã hóa để bạn truyền các lệnh văn bản (Text-based). Nó sử dụng cơ chế bảo mật dựa trên cặp khóa Public/Private Key hoặc mật khẩu đã được băm. Đứng ở góc độ một SOC Analyst soi gói tin bằng Wireshark, toàn bộ dữ liệu giao tiếp bên trong SSH chỉ hiện ra dưới dạng các khối Encrypted Packet — kẻ tấn công không thể đọc được bạn đang gõ lệnh quản trị gì.

2. Ranh giới chống MitM: Dấu vân tay (Fingerprint) và known_hosts

Vậy làm sao máy tính của bạn biết nó đang kết nối đúng đến Server thật chứ không phải một máy chủ giả mạo do hacker dựng lên (Man-in-the-Middle)? Bí quyết nằm ở cơ chế Dấu vân tay (Fingerprint).

Khi bạn thực hiện kết nối SSH lần đầu tiên, máy khách chưa biết gì về Server. Lúc này, Server sẽ gửi “chứng minh thư” của nó dưới dạng một mã Fingerprint (thường dùng thuật toán băm ED25519 từ Khóa công khai).

# Lệnh kết nối SSH vào máy chủ Linux
# Hệ thống sẽ hỏi xác nhận Fingerprint trong lần kết nối đầu tiên
ssh admin@10.10.50.20

# The authenticity of host '10.10.50.20 (10.10.50.20)' can't be established.
# ED25519 key fingerprint is SHA256:bafc947d6e921971472e82f52462129e.
# Are you sure you want to continue connecting (yes/no/[fingerprint])?

Khi bạn gõ yes, máy của bạn sẽ lưu vĩnh viễn khóa này vào file known_hosts. Kể từ những lần đăng nhập sau, nếu dấu vân tay này bị thay đổi (do hacker can thiệp và ép dùng khóa giả), SSH sẽ lập tức hiển thị cảnh báo đỏ và ngắt kết nối để bảo vệ bạn.

3. Lỗ hổng Terrapin (CVE-2023-48795) - Thao túng gói tin bắt tay

Mặc dù khóa phiên được trao đổi và lưu an toàn trong RAM ngay từ đầu, SSH vẫn tồn tại một lỗ hổng chí mạng mang tên Terrapin Attack (CVE-2023-48795). Điểm đáng sợ của Terrapin là nó không thèm bẻ khóa thuật toán mã hóa, mà đánh trực tiếp vào tính toàn vẹn của quá trình “bắt tay” (Handshake).

Trong giao thức SSH, mỗi gói tin được gửi đi đều đi kèm với một số thứ tự (Sequence Number) ngẫu nhiên và tăng dần ngầm định. Cả Client và Server đều kiểm tra gắt gao số này để đảm bảo không một gói tin nào bị rơi rớt hay bị kẻ xấu chèn thêm vào.

Cách thức tấn công của Terrapin (kỹ thuật “Cắt dán” số thứ tự) diễn ra như sau:

Hacker chiếm vị trí Man-in-the-Middle (MitM) giữa máy bạn và Server.
Trong giai đoạn đầu của quá trình bắt tay (khi mã hóa toàn phần chưa được thiết lập), hacker chủ động xóa bỏ một số gói tin cụ thể — ví dụ: gói tin báo hiệu việc hỗ trợ các thuật toán bảo mật cao.
Để hai bên Client và Server không phát hiện ra sự thiếu hụt này, hacker điều chỉnh lại số thứ tự của các gói tin kế tiếp sao cho chúng khớp hoàn hảo với mong đợi của hai bên — như thể gói tin bị xóa chưa từng tồn tại.

4. Hậu quả: Hạ cấp bảo mật và Vô hiệu hóa Keystroke Obfuscation

Mục đích cuối cùng của việc “xóa dấu vết” khéo léo này là để thực hiện đòn Hạ cấp bảo mật (Downgrade Attack). Bằng cách xóa các gói tin mở rộng (Extension Info), hacker đánh lừa cả hai bên về khả năng bảo mật của nhau.

Hậu quả mang lại cực kỳ tàn khốc:

Ép dùng thuật toán yếu: SSH sẽ bị lừa và tự động lùi về sử dụng các bộ thuật toán mã hóa cũ hơn, yếu hơn, dễ bị hacker dùng kỹ thuật tấn công kênh kề để khai thác.
Vô hiệu hóa Keystroke Obfuscation: Đây là tính năng quan trọng của SSH dùng để làm nhiễu “nhịp gõ phím” khi truyền qua mạng. Khi Terrapin vô hiệu hóa thành công tính năng này, hacker đứng giữa có thể dễ dàng đoán được độ dài mật khẩu và thực hiện tấn công Sniffing.

Cảnh báo SOC: Lỗ hổng Terrapin cho thấy tầm quan trọng của việc cập nhật phần mềm. Để chống lại đòn tấn công này, quản trị viên mạng phải đảm bảo cả SSH Client (như PuTTY, OpenSSH) và SSH Server đều được cập nhật lên phiên bản mới nhất có hỗ trợ cờ “Strict KEX” (Bắt tay nghiêm ngặt) nhằm chặn đứng hành vi thao túng gói tin.

Khép lại Bài 10, chúng ta đã hoàn tất việc mổ xẻ những giao thức quan trọng nhất ở Tầng Ứng dụng (Lớp 7) như DNS, DHCP, HTTP, FTP và SSH. Bức tranh về cách dữ liệu truyền tải trên mạng đã hoàn thiện. Giờ là lúc chúng ta chuyển sang thế chủ động: Làm thế nào để xây dựng các công sự bảo vệ mạng lưới này? Trong Bài 11 tiếp theo, chúng ta sẽ bắt đầu Phần 4 của Series với chủ đề Vành đai Tường lửa (Firewall) & Cơ chế NAT. Hãy cùng chờ đón nhé!