Tcp on Roduygo | Blog

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

Thu, 21 May 2026 22: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 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.

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.

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!

TCP và Nghệ thuật Bắt tay 3 Bước

Thu, 21 May 2026 09: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 trước, chúng ta đã thấy Tầng 2 và 3 chỉ biết tìm đường và “ném” gói tin đi mà không hề quan tâm đến sự sống chết của dữ liệu. Để đảm bảo thông tin không bị thất lạc hay lộn xộn trên môi trường Internet khắc nghiệt, chúng ta cần đến “trái tim” của sự ổn định: Giao thức TCP tại Tầng 4. Hôm nay, hãy cùng mổ xẻ cơ chế Bắt tay 3 bước kinh điển và cách dùng Wireshark để phát hiện các đòn tấn công mạng nguy hiểm.

1. Tầng 4 (Transport) và Sứ mệnh của TCP

Nhiệm vụ cốt lõi của Tầng 4 (Giao vận) là kiểm soát toàn bộ quá trình truyền tải dữ liệu. Khi nhận dữ liệu từ các tầng trên, Tầng 4 sẽ thực hiện phân đoạn (Segmentation) để chia nhỏ dữ liệu cho vừa với đường truyền, đánh số thứ tự (Sequencing) và dùng số Cổng (Port) để định tuyến đến đúng ứng dụng.

Tại đây, hai giao thức thống trị là TCP (Transmission Control Protocol) và UDP (User Datagram Protocol). Việc lựa chọn giao thức nào hoàn toàn phụ thuộc vào ứng dụng ở Tầng 7. Hệ điều hành sẽ dán một cái nhãn vào IP Header ở Tầng 3 (ví dụ nhãn số 6 cho TCP, 17 cho UDP) để Tầng 4 biết phải lôi “bộ máy” nào ra xử lý.

Trong khi UDP đề cao tốc độ bằng cách “cứ có là gửi, mất thì thôi”, thì TCP lại là biểu tượng của sự tin cậy. TCP đảm bảo mọi gói tin đều đến đúng nơi, đúng thứ tự, và nếu có bất kỳ dữ liệu nào bị mất, nó sẽ bắt buộc gửi lại (Retransmission).

2. Nghệ thuật Bắt tay 3 Bước (3-Way Handshake)

Trước khi truyền đi dù chỉ một byte dữ liệu ứng dụng, TCP yêu cầu hai thiết bị phải thiết lập một kết nối vững chắc thông qua quá trình Bắt tay 3 bước. Quá trình này diễn ra như sau:

Bước 1 — Gói SYN: Máy Client gửi một gói tin mang cờ SYN (Synchronize) với số thứ tự Sequence ban đầu để ngỏ lời kết nối. Gói này cũng khai báo Window Size, báo cho Server biết: “Tôi có thể nhận tối đa 64,240 bytes dữ liệu một lúc đấy nhé”.
Bước 2 — Gói SYN-ACK: Server đồng ý và đáp lại bằng gói SYN, ACK. Cờ ACK được bật để Server thông báo: “Tôi đã nhận được gói 0 của ông, tôi đang đợi gói 1 đây”.
Bước 3 — Gói ACK: Client gửi lại gói ACK cuối cùng để chốt hạ. Từ lúc này, “đường ống” đã thông suốt.

Dưới đây là output Wireshark bắt được khi Client 192.168.1.114 kết nối đến Server 72.34.249.208 qua cổng HTTPS (443):

# Lọc theo địa chỉ IP của Client và Server:
# Mẫu luồng gói tin trong Wireshark

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.114 -> 72.34.249.208 TCP 47682 -> 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2 0.474661 72.34.249.208 -> 192.168.1.114 TCP 443 -> 47682 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0
3 0.474780 192.168.1.114 -> 72.34.249.208 TCP 47682 -> 443 [ACK] Seq=1 Ack=1 Win=64512 Len=0
4 0.476483 192.168.1.114 -> 72.34.249.208 TLSv1.3 Client Hello (SNI=apex.go.sonobi.com)

Ghi chú: Gói số 4 cho thấy ngay sau khi bắt tay 3 bước hoàn tất, Client lập tức gửi Client Hello của TLS để khởi động mã hóa. Đây là quy trình chuẩn của HTTPS.

3. Cơ chế Đảm bảo Toàn vẹn (Sequence & Acknowledgment)

Làm sao TCP biết một gói tin đã đến đích an toàn? Bí quyết nằm ở cách nó sử dụng hai con số: Sequence Number (Số thứ tự) và Acknowledgment Number (Số xác nhận).

Khi gửi dữ liệu, Tầng 4 sẽ tính toán dựa trên số lượng byte. Nếu gói tin thứ nhất mang 500 byte dữ liệu và có Seq=1, thì gói tin thứ hai sẽ được đánh số Seq=501.

Khi máy đích nhận được gói thứ nhất, nó sẽ phản hồi bằng một gói có Ack=501, mang hàm ý: “Tôi đã nhận đủ 500 byte, hãy gửi tiếp cho tôi dữ liệu từ byte 501 trở đi”. Nếu Server không gửi Acknowledgment phản hồi sau một khoảng thời gian chờ, máy gửi sẽ tự động thực hiện gửi lại gói tin đó (Fast Retransmit hoặc RTO).

4. Bắt bệnh Mạng và Cảnh báo SOC bằng Wireshark

Với cơ chế khắt khe của TCP, Wireshark cung cấp cho SOC Analyst các bộ lọc cực kỳ mạnh mẽ để “bắt bệnh” hệ thống khi mạng bị chậm hoặc gặp sự cố:

Mất gói (Retransmission): Bộ lọc tcp.analysis.retransmission sẽ hiển thị các dòng chữ màu đỏ cảnh báo gói tin phải gửi lại do không nhận được ACK.
Thiếu mảnh dữ liệu (Duplicate ACK): Dùng bộ lọc tcp.analysis.duplicate_ack. Bạn sẽ thấy máy nhận liên tục gửi các gói ACK có cùng một số hiệu để “gào thét” đòi mảnh dữ liệu bị rớt ở giữa luồng.
Hệ thống bị ngộp (Zero Window): Bộ lọc tcp.analysis.zero_window phát hiện khi thiết bị nhận đã cạn kiệt bộ nhớ đệm. Nó sẽ ném ra gói tin này để ép máy gửi phải dừng truyền ngay lập tức (cơ chế Flow Control).

Cảnh báo SOC — Tấn Công SYN Flood: Hacker rất thích lợi dụng sự “kỹ tính” trong quá trình Bắt tay 3 bước của TCP để thực hiện tấn công từ chối dịch vụ (DDoS). Bằng cách bắn hàng vạn gói SYN giả mạo vào Server nhưng tuyệt đối không bao giờ trả lời bằng gói ACK cuối cùng, Server sẽ bị treo cứng vì cạn kiệt tài nguyên để chờ đợi những cái “bắt tay” không bao giờ hoàn tất. Bộ lọc phát hiện nhanh: tcp.flags.syn == 1 && tcp.flags.ack == 0.

Như vậy, việc thấu hiểu nhịp đập của “Trái tim” TCP giúp chúng ta phân biệt được một sự cố mạng do đường truyền kém với một cuộc tấn công từ chối dịch vụ có chủ đích. Ở Tầng 4, chúng ta mới chỉ quản lý được các cổng (Port), nhưng để duy trì trạng thái đăng nhập liên tục của người dùng, chúng ta cần tiến lên một bậc nữa. Trong Bài 4 tiếp theo, hãy cùng khám phá Lớp 5 (Session) và các kỹ thuật cướp phiên (Session Hijacking) tinh vi của Hacker. Đừng bỏ lỡ nhé!