Mitm on Roduygo | Blog

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é!

Giao thức Truyền tải (HTTP/HTTPS & FTP/SFTP)

Thu, 21 May 2026 22:55: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! Ở phần trước, chúng ta đã đi sâu vào hạ tầng mạng với DNS và DHCP. Khi gói tin đã có IP và tìm được đích đến, hệ thống sẽ chuyển giao nhiệm vụ cho các giao thức truyền tải văn bản và tệp tin ở Lớp Ứng dụng (Tầng 7). Hôm nay, chúng ta sẽ đặt HTTP/HTTPS và FTP/SFTP lên bàn mổ Wireshark để thấy rõ ranh giới sinh tử giữa dữ liệu trần trụi và kiến trúc đường hầm mã hóa.

1. HTTP và HTTPS: Ranh giới giữa “Trần trụi” và “Kín đáo”

HTTP (Cổng 80) là giao thức nền tảng để duyệt web, nhưng bản chất của nó là truyền văn bản thuần (Clear-text) hoàn toàn không được mã hóa. Đứng ở góc độ bảo mật, nếu bạn sử dụng mạng Wi-Fi công cộng để truy cập một trang web HTTP, bất kỳ ai có kiến thức cơ bản về mạng đang dùng Wireshark cũng có thể “nghe lén”. Họ sẽ thấy toàn bộ nội dung bạn chat, tài khoản, mật khẩu và thậm chí có thể can thiệp sửa đổi dữ liệu trên đường đi.

Để khắc phục điều này, HTTPS (Cổng 443) ra đời. Nó thực chất là giao thức HTTP được chạy trên nền của SSL/TLS ở Tầng 6 (Presentation).

Khi bạn truy cập facebook.com qua HTTPS, sau khi hoàn tất quá trình Bắt tay TCP ở Tầng 4, quy trình mã hóa sẽ diễn ra như sau:

Chuẩn bị (TLS Handshake): Trình duyệt (Client Hello) và máy chủ (Server Hello) đàm phán để chọn ra một bộ công cụ mật mã (Cipher Suite) chung.
Mã hóa (Application Data): Chỉ sau khi “đường hầm” TLS được thiết lập xong, dữ liệu web thực sự (phương thức GET/POST, mật khẩu, hình ảnh) mới bắt đầu được đẩy đi dưới dạng các khối Encrypted Application Data. Lúc này, hacker đứng giữa mạng sẽ hoàn toàn mù tịt.

2. FTP và Thảm họa Lộ Mật khẩu (Clear-text)

Tương tự như câu chuyện của HTTP, giao thức truyền tải tệp tin FTP (File Transfer Protocol) hoạt động ở Cổng 20 và 21 cũng là một giao thức cực kỳ yếu kém về bảo mật.

Hãy tưởng tượng một kịch bản thực chiến: Một nhân viên dùng FTP để upload báo cáo nội bộ qua mạng Wi-Fi ở quán cà phê. Hacker ngồi góc phòng, bật Wireshark (hoặc Ettercap) để thực hiện tấn công Man-in-the-Middle (MitM). Vì FTP không hề có lớp bảo vệ mã hóa nào, hacker sẽ bắt được toàn bộ gói tin giao tiếp trần trụi giữa máy trạm và Server.

Dưới đây là bằng chứng kết xuất từ Wireshark khi hacker bắt thành công gói tin FTP:

# Gói tin FTP cho thấy thông tin đăng nhập bị lộ hoàn toàn
# IP Nạn nhân: 192.168.1.15 | IP Máy chủ FTP: 10.10.50.20

No. Time Source Destination Protocol Info
34 100.646 192.168.1.15 -> 10.10.50.20 FTP Request: USER roduygo
36 100.646 10.10.50.20 -> 192.168.1.15 FTP Response: 331 Please specify the password.
38 102.659 192.168.1.15 -> 10.10.50.20 FTP Request: PASS 7905
40 102.756 10.10.50.20 -> 192.168.1.15 FTP Response: 230 Login successful.
42 102.756 192.168.1.15 -> 10.10.50.20 FTP Request: SYST
[...]

Chỉ với vài giây phân tích, hacker đã lấy được chính xác tài khoản (USER roduygo) và mật khẩu (PASS 7905). Từ đây, chúng có thể đăng nhập thẳng vào Server để trích xuất dữ liệu mật hoặc xóa sạch mọi tài liệu quan trọng.

Cảnh báo SOC: FTP mặc định là một lỗ hổng chí mạng. SOC Analyst cần đưa ra cảnh báo khẩn cấp (Alert) trên hệ thống IDS/IPS nếu phát hiện bất kỳ lưu lượng FTP nào (Port 21) truyền tải dữ liệu mà không đi qua các đường hầm VPN hoặc chưa được bọc TLS (FTPS).

3. SFTP: Kiến trúc Đường hầm Bảo mật tuyệt đối

Để giải quyết vấn đề của FTP, giải pháp an toàn và phổ biến nhất hiện nay trong giới quản trị hệ thống là SFTP (SSH File Transfer Protocol).

Một sai lầm rất thường gặp là mọi người nghĩ SFTP là “FTP cộng thêm bảo mật”. Thực chất không phải vậy! SFTP là một giao thức hoàn toàn mới được xây dựng từ đầu ngay bên trong không gian của SSH (Cổng 22). Trong khi SSH cung cấp cho bạn quyền gõ lệnh Terminal từ xa, thì SFTP tận dụng chính “đường hầm” an toàn đó để truyền tải tệp tin.

Khi bạn kết nối SFTP lần đầu, hệ thống sẽ sử dụng cơ chế bảo mật cực mạnh:

Kiểm tra Fingerprint: Máy bạn sẽ hỏi “dấu vân tay” (thường là mã ED25519) của Server và lưu vào file known_hosts. Từ lần sau, nếu dấu vân tay này bị thay đổi (do hacker cố tình dựng Server giả mạo), SSH sẽ báo động đỏ ngay lập tức.
Mã hóa hoàn toàn: Toàn bộ lệnh gõ, tên file, và nội dung file đều bị băm và xáo trộn.

Nếu hacker tiếp tục dùng Wireshark để nghe lén luồng SFTP, thứ duy nhất chúng thấy chỉ là vô vọng:

# Gói tin SFTP (chạy qua SSH) hoàn toàn bị mã hóa, che giấu mọi hoạt động
# IP Nạn nhân: 192.168.1.15 | IP Máy chủ SFTP: 10.10.50.20

No. Time Source Destination Protocol Info
14 13.1338 192.168.1.15 -> 10.10.50.20 SSHv2 Client: PQ/T Hybrid Key Exchange Init
15 13.1383 10.10.50.20 -> 192.168.1.15 SSHv2 Server: PQ/T Hybrid Key Exchange Reply, New Keys
17 18.3181 192.168.1.15 -> 10.10.50.20 SSHv2 Client: New Keys, Encrypted packet (len=68)
19 18.3509 10.10.50.20 -> 192.168.1.15 SSHv2 Client: Encrypted packet (len=52)
34 21.8629 192.168.1.15 -> 10.10.50.20 SSHv2 Client: Encrypted packet (len=128)
36 21.9083 10.10.50.20 -> 192.168.1.15 SSHv2 Server: Encrypted packet (len=628)
[...]

Thay vì thấy lệnh USER hay PASS, tất cả những gì hiển thị trên màn hình của hacker giờ đây chỉ là các khối Encrypted packet khô khan.

Hiểu rõ sự khác biệt giữa giao thức truyền văn bản thuần (HTTP, FTP) và các giao thức bọc giáp (HTTPS, SFTP) giúp SOC Analyst biết phải cấu hình giám sát ở đâu để không bị lọt lưới thông tin nhạy cảm. Dù SSH/SFTP rất kiên cố, nhưng 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. Trong Bài tiếp theo, chúng ta sẽ đi sâu vào kỹ thuật quản trị từ xa (SSH) 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 SSH. Hãy cùng chờ đón nhé!

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!

Lớp 6 (Presentation) & Lớp vỏ Mã hóa - Từ SSL đến TLS và Lỗ hổng POODLE

Thu, 21 May 2026 22:50: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 đã tìm hiểu cách Tầng 5 duy trì các phiên làm việc, nhưng nếu dữ liệu (như mật khẩu, cookie) cứ thế truyền đi trần trụi thì hacker đứng giữa mạng sẽ dễ dàng tóm gọn. Đó là lúc Tầng 6 (Presentation Layer) xuất hiện như một “lớp vỏ bọc thép” để thông dịch, nén và xáo trộn mọi thông tin trước khi đẩy ra mạng. Hôm nay, chúng ta sẽ cùng mổ xẻ cơ chế hoạt động của Tầng 6, phân tích sự tiến hóa từ SSL lên TLS và bóc trần đòn đánh POODLE khét tiếng đã định hình lại tiêu chuẩn bảo mật toàn cầu.

1. Tầng 6 (Presentation) làm nhiệm vụ gì?

Trong khi các tầng dưới chỉ lo việc “vận chuyển”, Tầng 6 đóng vai trò là một “người phiên dịch và đóng gói” dữ liệu chuẩn mực để đảm bảo hai thiết bị có hệ điều hành khác nhau vẫn có thể hiểu nhau. Ở tầng này, ranh giới giữa giao thức và định dạng tệp (như JPEG, MP4, JSON, XML) trở nên rất mong manh.

Tầng 6 đảm nhiệm 3 trọng trách cốt lõi:

Thông dịch (Translation): Chuyển đổi giữa các bảng mã (như ASCII sang UTF-8). Điều này đảm bảo khi bạn gõ tiếng Việt trên ứng dụng, máy chủ ở Mỹ vẫn hiển thị đúng chữ “Học” chứ không bị lỗi font ô vuông.
Nén dữ liệu (Compression): Giảm dung lượng dữ liệu (như luồng stream video MP4) trước khi truyền đi để tiết kiệm băng thông.
Mã hóa (Encryption): Đây là phần quan trọng nhất đối với Blue Team. Toàn bộ quá trình mã hóa dữ liệu để biến văn bản thuần thành một chuỗi ký tự rác (Encrypted Application Data) được xử lý tại đây. Đại diện tiêu biểu nhất chính là giao thức SSL/TLS.

2. Kỷ nguyên của SSL và Lỗ hổng chí mạng POODLE

Secure Sockets Layer (SSL) là thế hệ giao thức mã hóa đầu tiên bảo vệ Internet. Nó hoạt động dựa trên cơ chế bắt tay bằng Khóa công khai (Public Key) và Khóa bí mật (Private Key). Máy khách sẽ kiểm tra “Chứng chỉ số” của Server, tự tạo ra một Khóa phiên (Session Key) ngẫu nhiên, dùng Khóa công khai của Server bọc lại rồi gửi đi. Chỉ Server cầm Khóa bí mật mới mở được hộp để lấy Khóa phiên dùng cho việc liên lạc sau đó.

Tuy nhiên, SSL 3.0 đã bị khai tử hoàn toàn bởi một lỗ hổng có tên gọi thú vị: POODLE (Padding Oracle On Downgraded Legacy Encryption).

Đòn tấn công này đánh trực diện vào cách SSL 3.0 xử lý các “dữ liệu đệm” (padding). Hacker đứng ở giữa mạng (MitM) sẽ chủ động can thiệp làm nhiễu kết nối để ép Server và Client phải hạ cấp (Downgrade) bảo mật từ TLS xịn xuống dùng SSL 3.0 cũ. Sau đó, chúng liên tục gửi các gói tin chỉnh sửa nhẹ đến Server. Chỉ bằng việc quan sát Server trả lời là “Lỗi rồi” hay “OK”, hacker có thể đoán ngược lại từng byte dữ liệu. Sau vài trăm lần thử, chúng lấy được toàn bộ Cookie phiên đăng nhập của bạn mà không cần phải tốn công bẻ khóa.

Cảnh báo SOC: POODLE chứng minh rằng thuật toán mã hóa mạnh đến đâu cũng vô dụng nếu giao thức đàm phán bị lỗi. SOC Analyst cần cấu hình Firewall và Web Server (Nginx, HAProxy) tắt hoàn toàn việc hỗ trợ SSL v2/v3, chỉ chấp nhận TLS 1.2 trở lên để chống lại đòn Downgrade Attack.

3. Sự tiến hóa lên TLS (Transport Layer Security)

Để khắc phục yếu điểm của SSL, TLS ra đời. Thay vì chỉ mã hóa thụ động, TLS đóng vai trò như một hệ thống an ninh chủ động với các nâng cấp vượt bậc:

Xác thực mạnh mẽ: Bỏ hẳn MD5 và SHA-1 để chuyển sang các hàm băm hiện đại như SHA-256.
Chống sửa đổi (Integrity): TLS sử dụng thuật toán HMAC (Hash-based Message Authentication Code). Kẻ tấn công không thể thay đổi dù chỉ 1 bit dữ liệu trên đường đi mà không bị hệ thống phát hiện.
Bảo mật chuyển tiếp (Perfect Forward Secrecy): Nhờ thuật toán trao đổi khóa ECDHE, mỗi phiên làm việc có một khóa riêng. Ngay cả khi hacker đánh cắp được Khóa bí mật tĩnh của máy chủ vào ngày mai, chúng cũng không thể dùng nó để giải mã các gói tin Wireshark mà chúng đã nghe lén từ hôm nay.

4. Giải phẫu Cipher Suite trên Wireshark

Khi bạn truy cập một trang web HTTPS, trong gói tin Server Hello trên Wireshark, máy chủ sẽ chốt lại một “Bộ công cụ mật mã” (Cipher Suite) duy nhất để hai bên sử dụng. Dưới đây là cách SOC Analyst đọc hiểu bộ mã TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:

# Log Wireshark soi gói tin Server Hello chốt thuật toán mã hóa
# Bộ lọc: tls.handshake.type == 2

Handshake Protocol: Server Hello
 Version: TLS 1.2 (0x0303)
 Session ID Length: 32
 Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)

Cách đọc chuỗi Cipher Suite trên từ trái sang phải: ví dụ trong ảnh là TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

ECDHE: Thuật toán trao đổi khóa (đảm bảo Perfect Forward Secrecy).
RSA: Thuật toán xác thực danh tính (chứng minh máy chủ qua Certificate).
CHACHA20_POLY1305: Thuật toán mã hóa đối xứng thực hiện xáo trộn dữ liệu (tốc độ cực nhanh trên thiết bị hiện đại).
SHA256: Thuật toán băm dùng cho HMAC để kiểm tra tính toàn vẹn của gói tin.

Dưới góc độ phân tích sự cố, nếu muốn “giải mã” các gói tin TLS để xem dữ liệu thô (HTTP) trên Wireshark, bạn có thể buộc trình duyệt xuất file lưu trữ Khóa phiên (Session Key) ra ổ cứng:

# Thiết lập biến môi trường để Firefox/Chrome nhả Khóa phiên ra file log
# Chỉ dùng trên máy Lab/máy phân tích, KHÔNG dùng trên máy người dùng thực tế

export SSLKEYLOGFILE=~/tls_keys.log
firefox &

5. Mã hóa TLS có an toàn tuyệt đối?

Dù TLS rất thông minh, nó vẫn có những “gót chân Achilles” mà Blue Team cần dè chừng:

Tấn công vào Chứng chỉ (Certificate Attacks): TLS dựa vào niềm tin của Certificate. Nếu hacker lừa người dùng cài một “Root Certificate” giả vào máy, chúng có thể thực hiện Man-in-the-Middle (MitM) để giải mã mọi thứ trơn tru.
Lỗ hổng thực thi (Implementation Bugs): Lỗi không nằm ở lý thuyết TLS mà nằm ở người code thư viện — điển hình là vụ Heartbleed trên OpenSSL cho phép đọc trộm bộ nhớ RAM của máy chủ.
Tấn công kênh kề (Side-channel): Hacker không thèm bẻ khóa, chúng chỉ ngồi đếm kích thước gói tin và thời gian phản hồi để đoán người dùng đang xem trang web gì.

Như vậy, đi qua Tầng 6, dữ liệu của chúng ta đã được đóng gói định dạng và khoác lên mình lớp áo giáp mã hóa bất khả xâm phạm. Giờ đây, “thùng hàng” này đã sẵn sàng để được giao cho Tầng cuối cùng: Tầng 7 (Application). Ở bài viết tiếp theo — Bài 7, chúng ta sẽ khám phá thế giới của Tầng Ứng dụng, nơi diễn ra các cuộc tấn công dữ dội nhất nhắm vào các giao thức DNS ngây thơ, quá trình xin cấp IP của DHCP và sự nguy hiểm của FTP truyền thống. Đừng bỏ lỡ nhé!

Lớp 5 (Session) & Ranh giới của Phiên làm việc

Thu, 21 May 2026 22:30: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 ống” vật lý vững chắc bằng giao thức TCP ở Tầng 4, hệ thống phải đối mặt với một bài toán mới: Làm sao để “nhớ mặt” người dùng mà không bắt họ phải đăng nhập lại sau mỗi cú click chuột? Đó chính là nhiệm vụ của Tầng 5 (Session Layer) — nơi ranh giới của các phiên làm việc được thiết lập và cũng là nơi hacker tung ra những đòn cướp quyền vô cùng hiểm độc.

1. Tầng 5 (Session) và Sự cần thiết của Phiên làm việc

Khi bạn mở trình duyệt web và thực hiện nhiều yêu cầu cùng lúc (như mở nhiều tab, tải nhiều ảnh), dữ liệu có nguy cơ bị lẫn lộn vào nhau. Tầng 5 (Lớp Phiên) sinh ra để giải quyết vấn đề này bằng cách thiết lập, quản lý và kết thúc các phiên kết nối. Nó đóng vai trò tạo ra một ranh giới độc nhất cho từng cuộc liên lạc.

Ở mức độ truyền tải, Tầng 5 quản lý “luồng” nói chuyện thông qua 3 chế độ:

Đơn công (Simplex): Dữ liệu chỉ đi một chiều (như bạn nghe radio).
Bán song công (Half-duplex): Hai bên nói chuyện luân phiên (như bộ đàm — người này nói xong người kia mới được nói).
Song công toàn phần (Full-duplex): Cả hai cùng nói và nghe cùng lúc (như gọi điện thoại di động).

Tuy nhiên, bài toán lớn nhất ở đây là hiệu năng. Việc bắt tay (Handshake) ở Tầng 4 (TCP) và Tầng 6 (TLS) cực kỳ tốn thời gian và làm “mệt” CPU của máy chủ. Để tối ưu hóa, Tầng 5 không bắt hai thiết bị phải chào hỏi lại từ đầu cho mỗi gói tin, mà sử dụng các cơ chế định danh đặc biệt.

2. Giải phẫu Session ID và Session Ticket trên Wireshark

Để duy trì trạng thái kết nối, Tầng 5 sử dụng hai công cụ chính là Session ID và Session Ticket. Bằng cách dùng Wireshark, chúng ta có thể dễ dàng bắt được những “tấm vé” này bay trên không gian mạng.

2.1 Định danh cuộc trò chuyện bằng Session ID

Sau lần bắt tay đầu tiên thành công, máy chủ sẽ cấp cho bạn một “mã số định danh” gọi là Session ID. Khi máy bạn gửi hàng nghìn khung dữ liệu tiếp theo, nó chỉ cần đính kèm ID này. Server nhìn vào ID sẽ biết ngay: “Đây là khách quen, đã kiểm tra an ninh xong rồi, cho dữ liệu đi thẳng lên Tầng 6 để xử lý!”.

# Lọc gói tin Server Hello để tìm Session ID do máy chủ cấp phát
# Cú pháp bộ lọc trên Wireshark: tls.handshake.type == 2

Handshake Protocol: Server Hello
 Handshake Type: Server Hello (2)
 Length: 118
 Version: TLS 1.2 (0x0303)
 Random: dc3aa089a0c8825e54cc0106c17a0cb90305776b2d49f405fe30dc0f2bfad484
 Session ID Length: 32
 Session ID: d451a3116057f79488abdba0e27371ef79b25a156fcd8afaf011b9aa5bdb900b
 Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)

Cái dãy số Hex dài đó (d451a311…) dùng để: Định danh cuộc trò chuyện: Khi máy Lenovo của bạn gửi hàng nghìn Frame dữ liệu tiếp theo (như các gói DATA của HTTP/2), nó không cần phải gửi lại toàn bộ thông tin chào hỏi. Nó chỉ cần gắn cái ID này vào (hoặc dùng trạng thái đã thiết lập từ ID này). Nhận diện người quen: Server nhìn vào ID này sẽ biết: “À, đây là gói tin tiếp theo của ông bạn ở IP 192.168.1.156, đã kiểm tra xong xuôi rồi, cho dữ liệu đi thẳng lên Tầng 6 để dịch luôn!”.

2.2 Vé phục hồi nhanh (Session Ticket)

Để đẩy nhanh tốc độ kết nối lại (0-RTT), máy chủ cung cấp một Session Ticket. Đây thực chất là một cái “vé” lưu trữ trạng thái bảo mật của phiên trước đó. Thay vì phải tính toán lại các thuật toán mã hóa nặng nề, máy khách chỉ cần trình chiếc vé này ra để nối lại phiên làm việc ngay lập tức.

# Lọc gói tin New Session Ticket để xem vé bảo mật được mã hóa
# Cú pháp bộ lọc trên Wireshark: tls.handshake.type == 4

TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
 Content Type: Application Data (23)
 Version: TLS 1.2 (0x0303)
 Handshake Protocol: New Session Ticket
 Handshake Type: New Session Ticket (4)
 Length: 53
 TLS Session Ticket
 Session Ticket Lifetime Hint: 600 seconds (10 minutes)
 Session Ticket Age Add: 3185912667
 Session Ticket Nonce Length: 8
 Session Ticket: af23cc7378d7440f6a6447726da2062b7d2198d9b8c7aaad6a71213fba0cbb97

3. Các đòn tấn công tử huyệt nhắm vào Phiên làm việc

Hacker hiểu rất rõ giá trị của những mã Session ID này. Vì Server hoàn toàn tin tưởng vào cái vé, nên kẻ nào cầm vé, kẻ đó có quyền. Dưới đây là 3 đòn tấn công kinh điển ở Tầng 5.

3.1 Cướp Phiên (Session Hijacking)

Đây là đòn đánh trực diện nhất. Kẻ địch hoàn toàn không cần biết mật khẩu của bạn.

Chúng chỉ cần “đánh cắp” được Session ID đang nằm trong Cookie hoặc bộ nhớ đệm trình duyệt thông qua các kỹ thuật như Sniffing (nghe lén mạng Wi-Fi không an toàn) hoặc tấn công Cross-Site Scripting (XSS). Khi có được ID này, chúng dùng nó để gửi gói tin lên Server. Server sẽ lầm tưởng hacker chính là bạn và cho phép truy cập thẳng vào tài khoản.

Cảnh báo SOC: Để chống lại Session Hijacking, hệ thống mạng bắt buộc phải mã hóa toàn bộ dữ liệu truyền tải bằng HTTPS/TLS và các Cookie phải được gắn cờ Secure cùng HttpOnly để ngăn mã độc JavaScript trích xuất Session ID.

3.2 Tấn công Phản hồi (Replay Attack)

Lỗ hổng này đánh thẳng vào cơ chế “vé phục hồi nhanh” (New Session Ticket / 0-RTT) mà chúng ta vừa soi trên Wireshark.

Vì cái vé này được thiết kế để kết nối nhanh mà không cần bắt tay lại, hacker có thể can thiệp ở giữa mạng (MitM), bắt lấy bản sao gói tin chứa Ticket của bạn và gửi lại cho Server nhiều lần. Nếu hệ thống ứng dụng không có cơ chế chống trùng lặp (ví dụ: dùng timestamp hoặc nonce), hacker có thể ép Server thực hiện lại một giao dịch nhạy cảm (như chuyển tiền) nhiều lần chỉ bằng cách “phát lại” cái vé cũ đó.

3.3 Cố định Phiên (Session Fixation)

Ngược lại với việc đi ăn cắp, trong kỹ thuật này hacker lại chủ động “tặng” cho bạn một cái ID.

Kẻ tấn công sẽ tạo ra một Session ID hợp lệ từ trước, sau đó lừa bạn click vào một đường link chứa sẵn ID đó để đăng nhập. Sau khi bạn đăng nhập thành công, hệ thống vô tình “đóng dấu xác thực” cho cái ID do hacker cung cấp. Lúc này, hacker chỉ cần ung dung nhập cái ID mà chúng đã biết trước đó vào trình duyệt — phiên làm việc lúc này trở thành “dùng chung” giữa bạn và hacker.

Việc thấu hiểu Tầng 5 giúp SOC Analyst nhận ra rằng: Không phải cứ đăng nhập xong là an toàn tuyệt đối, bởi nếu kẻ gian cướp được “tấm vé” Session, chúng nghiễm nhiên trở thành người chủ hợp pháp. Tuy nhiên, cái vé đó và toàn bộ dữ liệu ứng dụng thực chất được xáo trộn như thế nào để không ai đọc lén được trên mạng? Trong Bài 6 tiếp theo, chúng ta sẽ bước lên Tầng 6 (Presentation) để bóc tách lớp vỏ mã hóa SSL/TLS, giải phẫu thuật toán CHACHA20 và tìm hiểu lỗ hổng POODLE khét tiếng. Hãy cùng chờ đón nhé!