Bắt bệnh Mạng bằng Wireshark & Tấn công DDoS

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 đã hiểu được “trái tim” TCP và nghệ thuật bắt tay 3 bước ở Tầng 4. Hôm nay, chúng ta sẽ thực sự ứng dụng Wireshark để “bắt bệnh” các lỗi đường truyền kinh điển, đồng thời phân tích cách hacker lợi dụng chính cơ chế của TCP/UDP để phát động các đòn tấn công từ chối dịch vụ (DDoS) tàn khốc.

1. “Bắt bệnh” Mạng chậm và Rớt gói tin bằng Wireshark

Giao thức TCP được thiết kế để đảm bảo không một byte dữ liệu nào bị mất trên đường truyền. Do đó, khi mạng gặp sự cố (như đứt cáp, quá tải, nhiễu sóng), TCP sẽ “la hét” và để lại những dấu vết cực kỳ rõ ràng. Dưới góc độ SOC Analyst, bạn có thể dùng các bộ lọc sau đây trên Wireshark để chẩn đoán nguyên nhân.

1.1 Mất gói và Gửi lại (Retransmission)

Khi máy gửi đã đẩy gói tin đi nhưng đợi mãi (hết thời gian RTO - Retransmission Timeout) mà không nhận được gói ACK xác nhận từ máy nhận, nó bắt buộc phải gửi lại gói tin đó.

Cú pháp lọc: tcp.analysis.retransmission
Dấu hiệu: Wireshark sẽ tô màu đen chữ đỏ rực rỡ cho các dòng này. Nếu bộ lọc này trả về hàng ngàn kết quả, đường truyền vật lý đang cực kỳ bất ổn và hệ thống đang lãng phí băng thông để gửi lại dữ liệu cũ, làm tốc độ mạng chậm đi rõ rệt.

Gói tin mà máy tính gửi đi để yêu cầu kết nối tcp

1.2 Thiếu mảnh dữ liệu (Duplicate ACK)

Đây là cảnh tượng máy nhận đang “gào thét” đòi một mảnh dữ liệu bị mất ở giữa luồng truyền.

Cú pháp lọc: tcp.analysis.duplicate_ack
Dấu hiệu: Bạn sẽ thấy máy nhận gửi liên tiếp các gói ACK có cùng một số hiệu xác nhận (ví dụ: 3-4 gói đều mang Ack=4680). Điều này có nghĩa là: “Tôi đã nhận được các gói 4681, 4682 rồi, nhưng cái gói 4680 vẫn chưa tới, hãy gửi lại ngay!”. Khi nhận được 3 gói Dup ACK liên tiếp, máy gửi sẽ kích hoạt cơ chế Fast Retransmit để gửi bù ngay lập tức.

Gói tin mà máy tính gửi đi để yêu cầu gói tin bị mất

1.3 Hệ thống bị ngộp (Zero Window)

Sự cố này không do đường truyền, mà do năng lực xử lý của máy tính (hoặc Server) đã chạm đáy.

Cú pháp lọc: tcp.analysis.zero_window
Dấu hiệu: Máy nhận sẽ ném ra một gói tin với tham số Win=0. Đây là cơ chế Kiểm soát luồng (Flow Control) của TCP, mang thông điệp: “Dừng lại ngay! Bộ nhớ đệm (Buffer) của tôi đã đầy cứng rồi, không còn chỗ chứa thêm dữ liệu nào nữa đâu!”.

2. SYN Flood: Đòn đánh vào sự “Kỹ tính” của TCP

Hacker luôn biết cách biến “tính năng” thành “vũ khí”. Việc TCP yêu cầu phải Bắt tay 3 bước khắt khe vô tình tạo ra một lỗ hổng chí mạng cho các cuộc tấn công DDoS dạng SYN Flood.

Kịch bản tấn công diễn ra như sau:

Kẻ tấn công gửi hàng vạn gói ngỏ lời SYN đến máy chủ đích.
Máy chủ ngây thơ phân bổ tài nguyên bộ nhớ, tạo một “nửa kết nối” (Half-open connection) và gửi lại gói SYN-ACK.
Máy chủ chờ đợi gói ACK cuối cùng để hoàn tất — nhưng kẻ tấn công tuyệt đối không bao giờ trả lời. Máy chủ cứ thế chờ đợi cho đến khi cạn kiệt tài nguyên (CPU, RAM) và bị treo cứng, từ chối phục vụ người dùng hợp lệ.

Đây là output Wireshark ghi lại khi kẻ tấn công 10.10.53.248 liên tục bắn gói SYN vào Server 192.168.1.10:

# Lọc để phát hiện SYN Flood: tcp.flags.syn == 1 && tcp.flags.ack == 0
# Dấu hiệu: hàng ngàn gói SYN từ cùng một IP, không có gói ACK phản hồi

No.  Time    Source         Destination   Protocol  Info
1    0.0000  10.10.53.248 -> 192.168.1.10  TCP       45892 -> 443 [SYN] Seq=0 Win=64240 Len=0
2    0.0001  10.10.53.248 -> 192.168.1.10  TCP       45893 -> 443 [SYN] Seq=0 Win=64240 Len=0
3    0.0002  10.10.53.248 -> 192.168.1.10  TCP       45894 -> 443 [SYN] Seq=0 Win=64240 Len=0
4    0.0003  10.10.53.248 -> 192.168.1.10  TCP       45895 -> 443 [SYN] Seq=0 Win=64240 Len=0
[...]

Cảnh báo SOC: Kẻ tấn công thường sử dụng địa chỉ IP nguồn giả mạo (Spoofed IP) trong các cuộc tấn công SYN Flood. Do đó, việc dùng Firewall để chặn IP nguồn đơn lẻ là không hiệu quả. SOC cần cấu hình các cơ chế phòng thủ chuyên sâu như SYN Cookies trên Tường lửa/Load Balancer.

3. UDP Flood: Đòn đánh “Lấy thịt đè người”

Trái ngược với sự kỹ tính của TCP, giao thức UDP lại đại diện cho sự “tự do”: Không bắt tay, không cần số thứ tự, cứ có dữ liệu là ném đi. Giao thức này thường dùng cho Game hoặc Livestream, nhưng cũng là công cụ tàn phá ưa thích của Hacker.

Trong tấn công UDP Flood, hacker không cần lừa máy chủ bắt tay. Chúng chỉ đơn giản là huy động một mạng lưới máy tính ma (Botnet) để bắn hàng triệu gói tin UDP rác vào các cổng ngẫu nhiên trên Server.

Hậu quả: Khi Server nhận được gói tin UDP ở một cổng, nó bắt buộc phải dùng CPU để kiểm tra xem có ứng dụng nào đang chờ ở cổng đó không. Khi phát hiện không có, nó phải tốn thêm công sức để tạo và gửi lại một gói lỗi ICMP Destination Unreachable (Port Unreachable). Khi phải xử lý hàng triệu thao tác vô bổ này trong một giây, máy chủ sẽ sụp đổ hoàn toàn vì quá tải.

# Lệnh minh họa tấn công UDP Flood bằng hping3
# CHỈ thực hiện trong môi trường Lab, tuyệt đối KHÔNG dùng trên hệ thống thật

# -2: chế độ UDP | --flood: xả gói liên tục | --rand-source: IP nguồn ngẫu nhiên
sudo hping3 -2 --flood --rand-source 192.168.1.10

Cảnh báo: Lệnh trên có thể gây tê liệt hệ thống mục tiêu. Chỉ sử dụng trong môi trường thực hành (Lab) hoàn toàn cô lập, không kết nối Internet.

Qua bài viết này, chúng ta đã biết cách dùng Wireshark để đọc các tín hiệu “kêu cứu” của hệ thống (Retransmission, Zero Window) và hiểu rõ bản chất tàn khốc của các đòn tấn công DDoS ở Tầng 4. Sau khi đã nắm vững quá trình vận chuyển gói tin, ở Bài 5 tiếp theo, chúng ta sẽ bước lên Lớp 5 (Session Layer) để khám phá ranh giới của các phiên làm việc và kỹ thuật Cướp phiên (Session Hijacking) tinh vi của Hacker. Hẹn gặp lại các bạn!