Ddos on Roduygo | Blog

Hạ tầng Mạng (DNS & DHCP)

Thu, 21 May 2026 22:53: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! Sau khi đã thiết lập xong “đường hầm” mã hóa vững chắc ở Tầng 6, chúng ta chính thức bước chân vào Lớp 7 (Application). Đây là nơi chứa đựng những giao thức nền tảng nhất giúp Internet vận hành, nhưng cũng là những “góc khuất ngây thơ” nhất vì mặc định chúng thiếu đi các cơ chế bảo mật cốt lõi. Hôm nay, chúng ta sẽ cùng bóc tách hệ thống phân giải tên miền (DNS) và quá trình xin cấp phát IP tự động (DHCP), đồng thời phân tích các đòn đánh hiểm hóc nhắm vào chúng.

1. DNS (Domain Name System) - Bản danh bạ của Internet

Hệ thống phân giải tên miền (DNS) là một giao thức cốt lõi thuộc Tầng 7 (Application Layer) hoạt động chủ yếu qua cổng UDP 53. Nhiệm vụ của nó là “dịch” các tên miền dễ nhớ đối với con người (như google.com) thành địa chỉ IP thực tế để máy tính có thể giao tiếp với nhau trên mạng.

Ví dụ, trước khi bạn thực sự truy cập vào trang Facebook, máy tính của bạn sẽ bắn một gói tin truy vấn DNS đến máy chủ phân giải (như 8.8.8.8) để hỏi IP của Facebook là gì. Sau khi DNS trả về địa chỉ IP và lưu nó vào bộ nhớ đệm (cache), trình duyệt của bạn mới bắt đầu thực hiện kết nối TCP 3 bước để trao đổi dữ liệu web.

2. Bắt tại trận các đòn tấn công nhắm vào DNS

DNS được thiết kế từ thời kỳ sơ khai của Internet nên nó rất “ngây thơ”: mặc định các truy vấn không được mã hóa và không có cơ chế xác thực danh tính mạnh mẽ. Hacker hiểu rất rõ điểm yếu này và thường xuyên tung ra các đòn tấn công sau:

DNS Spoofing / Poisoning (Lừa đảo/Đầu độc): Kẻ tấn công gửi một gói tin trả lời (Response) giả mạo chứa địa chỉ IP của máy hacker, cố gắng đến máy bạn nhanh hơn cả DNS Server thật. Nếu số định danh Transaction ID trong gói tin trùng khớp, máy tính của bạn sẽ tin tưởng tuyệt đối và truy cập thẳng vào trang web lừa đảo do hacker dựng sẵn.
DNS Tunneling (Đường hầm dữ liệu): Tường lửa của các doanh nghiệp thường luôn cho phép cổng 53 đi qua một cách tự do. Biết được kẽ hở này, hacker có thể nhồi nhét dữ liệu nhạy cảm (như mã nguồn dự án hoặc thông tin thẻ tín dụng) vào bên trong các truy vấn DNS thông thường để âm thầm tuồn dữ liệu ra ngoài (Data Exfiltration) mà không bị hệ thống IDS/IPS chặn lại.
DNS Hijacking (Chiếm quyền điều khiển): Kẻ gian trực tiếp thay đổi cài đặt máy chủ DNS trên hệ điều hành máy nạn nhân hoặc trên Router để trỏ mọi truy vấn phân giải về một DNS Server do chúng kiểm soát hoàn toàn.

Dưới đây là output Wireshark ghi lại một truy vấn DNS bình thường. Nếu bị DNS Spoofing, IP trả về ở gói số 2 sẽ là IP của kẻ tấn công thay vì IP thật:

# Máy khách 192.168.1.156 hỏi DNS Server 203.113.188.6 địa chỉ của google.com
# Bộ lọc Wireshark: dns && ip.addr == 192.168.1.156

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.156 -> 203.113.188.6 DNS Standard query 0x24b7 A google.com
2 0.084123 203.113.188.6 -> 192.168.1.156 DNS Standard query response 0x24b7 A google.com A 142.250.198.46

3. DHCP (Dynamic Host Configuration Protocol) và Quy trình DORA

Trước khi máy tính có thể “hỏi đường” bằng DNS, nó phải làm thủ tục “xin hộ khẩu” để có một địa chỉ IP nội bộ hợp lệ nhằm gia nhập mạng. Quá trình tự động hóa này do giao thức DHCP đảm nhận, hoạt động ở Tầng 7 và sử dụng cổng UDP 67 cho Server, UDP 68 cho Client.

Khi bạn vừa cắm dây cáp mạng hoặc bật Wi-Fi, một quy trình 4 bước mang tên DORA sẽ lập tức diễn ra:

D — Discover (Khám phá): Máy tính của bạn lúc này chưa có IP, nó dùng địa chỉ 0.0.0.0 để “hét” lên toàn mạng bằng gói tin Broadcast: “Có ai là DHCP Server ở đây không? Tôi cần một địa chỉ IP!”.
O — Offer (Đề nghị): Router (đóng vai trò DHCP Server) nghe thấy và đáp lại: “Tôi đây! Tôi đang có sẵn địa chỉ 192.168.1.14 trống, cậu có muốn dùng không?”.
R — Request (Yêu cầu): Máy của bạn phản hồi lại toàn mạng: “Tuyệt quá! Tôi đồng ý dùng địa chỉ .14 đó. Làm ơn khóa địa chỉ đó lại cho tôi nhé!”.
A — Acknowledge (Xác nhận): Router chốt sổ và thông báo: “Ok, địa chỉ .14 là của cậu trong vòng 24 giờ tới. Đây là thông số DNS và Default Gateway để cậu vào mạng”.

4. DHCP Starvation và Rogue Server - Sự nguy hiểm của Broadcast

Điểm yếu chí mạng của DHCP là nó hoạt động hoàn toàn dựa trên niềm tin vào bất kỳ thiết bị nào phản hồi lại gói tin Broadcast (255.255.255.255). Kẻ tấn công đứng trong cùng một mạng LAN có thể dễ dàng khai thác niềm tin này:

DHCP Starvation (Tấn công làm cạn kiệt): Hacker sử dụng công cụ tự động để tạo ra hàng vạn gói tin Discover với các địa chỉ MAC giả mạo liên tục. Router sẽ ngây thơ cấp phát toàn bộ dải IP trống trong kho của nó (ví dụ từ .2 đến .254) cho các MAC ảo này. Hậu quả là khi một nhân viên thật kết nối vào mạng, Router sẽ báo “hết số” và họ không thể nhận được IP để vào mạng.
Rogue DHCP Server (Server giả mạo): Hacker chủ động dựng lên một DHCP Server giả ngay trong mạng công ty. Khi máy của nhân viên gửi gói tin Discover xin IP, Server giả này sẽ phản hồi nhanh hơn cả Router thật để cấp IP — nhưng nó sẽ cấp cho nạn nhân một Default Gateway giả mạo trỏ thẳng về máy của hacker. Lúc này, toàn bộ dữ liệu nạn nhân gửi ra Internet đều chảy xuyên qua máy kẻ tấn công, tạo nên một đòn Man-in-the-Middle (MitM) hoàn hảo.

Cảnh báo SOC: Để chống lại các cuộc tấn công hạ tầng này, quản trị viên mạng cần cấu hình tính năng DHCP Snooping trên các Switch vật lý. Tính năng này sẽ chỉ cho phép các cổng (Port) kết nối với Router thật mới được quyền gửi gói tin Offer và Acknowledge, chặn đứng mọi DHCP Server giả mạo.

Thấu hiểu cách DNS và DHCP vận hành giúp SOC Analyst phát hiện sớm các chiến dịch đánh cắp dữ liệu hoặc nghe lén mạng nội bộ trước khi chúng gây ra hậu quả. Sau khi gói tin của chúng ta đã có IP và tìm được đích đến, nó sẽ được chuyển giao cho các giao thức truyền tải văn bản và tệp tin. Trong Bài 9 tiếp theo, chúng ta sẽ phân tích sâu hơn về HTTP/HTTPS, cách FTP làm lộ mật khẩu trần trụi và kiến trúc đường hầm an toàn của SFTP. Hẹn gặp lại các bạn!

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!