Mỗi gói tin IPv4 lưu thông trên Internet đều mang một trường Identification 16-bit (IP ID) trong tiêu đề nhị phân. Được định nghĩa từ năm 1981 trong RFC 791, trường này sinh ra nhằm giúp hệ điều hành nhận diện và ghép lại các phân mảnh (fragments) khi gói tin vượt quá kích thước MTU trên đường truyền. Trong nhiều thập kỷ, các nhà phát triển nhân hệ điều hành đã triển khai trường này bằng một biến số nguyên tăng dần toàn cục: mỗi khi thiết bị phát đi một gói tin IP, bộ đếm nội bộ tăng thêm một đơn vị.

Cơ chế tưởng chừng vô hại đó đã tạo ra một trong những lỗ hổng kênh phụ (side-channel) kinh điển nhất lịch sử mạng máy tính. Bằng cách theo dõi sự thay đổi tuần tự của bộ đếm IP ID trên một máy chủ trung gian, kẻ tấn công có thể quét bản đồ cổng dịch vụ sau tường lửa của mục tiêu mà không cần gửi bất kỳ gói tin nào từ địa chỉ IP thật của mình, đồng thời suy đoán các mối quan hệ giao tiếp nội bộ và đo đạc lưu lượng truyền tải.

Các tiêu chuẩn hiện đại, đặc biệt là RFC 6864 và giao thức đường hầm bảo mật WireGuard, đã tái cấu trúc căn bản cách hệ điều hành xử lý định danh gói tin. Phân tích kênh phụ IP ID mang lại hiểu biết sâu sắc về an toàn tầng vận chuyển, nguyên lý cách ly trạng thái nhân và kiến trúc phòng thủ qua đường hầm mã hóa.

+-------------------------------------------------------------------------+
|                 MÔ HÌNH TAM GIÁC TẤN CÔNG IDLE SCAN KINH ĐIỂN           |
+-------------------------------------------------------------------------+
|                                                                         |
|      1. Thăm dò IP ID (SYN/ACK)        2. Gửi SYN giả mạo (Nguồn=Zombie)|
|         Zombie IP ID = 31337              Đích: Cổng 443 Mục tiêu       |
|      ┌─────────────────────────┐       ┌─────────────────────────┐      |
|      │                         ▼       │                         ▼      |
|  [Kẻ tấn công]              [Máy Zombie]                   [Máy mục tiêu]|
|      ▲                         │       ▲                         │      |
|      │                         └───────┼─────────────────────────┘      |
|      3. Thăm dò lại (SYN/ACK)          │ Mục tiêu gửi SYN/ACK cho Zombie|
|         Zombie IP ID = 31339           │ Zombie gửi RST (Tăng IP ID +1!)|
|         Độ lệch Delta = 2 -> CỔNG MỞ!  └─────────────────────────┘      |
+-------------------------------------------------------------------------+

Nguồn gốc của trường Identification trong IPv4 (RFC 791)

Theo đặc tả RFC 791, các bộ định tuyến trung gian khi gặp gói tin có kích thước vượt ngưỡng MTU của chặng tiếp theo bắt buộc phải phân mảnh gói tin. Để bên nhận có thể phân biệt chính xác mảnh nào thuộc về gói tin nào, bên gửi gán một giá trị định danh 16-bit cho từng datagram ban đầu.

Bên nhận sử dụng bộ tứ thông tin để tái hợp phân mảnh:

  • Địa chỉ IP nguồn (Source IP)
  • Địa chỉ IP đích (Destination IP)
  • Mã giao thức (Protocol ID) (như TCP, UDP, ICMP)
  • Giá trị định danh (IP ID)

Vì 16-bit chỉ tạo ra 65.536 giá trị khả dĩ, các hệ điều hành sơ khai (như Windows, BSD và các phiên bản Linux nhân cũ) duy trì một biến toàn cục đơn giản:

// Cách cài đặt truyền thống: tăng dần đơn điệu toàn cục
static unsigned short global_ip_id = 0;

void build_ip_header(struct iphdr *iph) {
    iph->id = htons(++global_ip_id);
}

Kiểu thiết kế này vô tình tạo ra một kênh phát tín hiệu công khai: bất kỳ ai từ Internet cũng có thể tính toán được máy chủ đã gửi đi bao nhiêu gói tin trong một khoảng thời gian nhất định.

Bản chất của Idle Scan: Quét cổng gián tiếp qua máy Zombie

Năm 1998, chuyên gia bảo mật Salvatore Sanfilippo (antirez) phát hiện ra rằng tính chất tăng dần toàn cục của IP ID có thể bị lợi dụng để quét cổng một cách gián tiếp. Kỹ thuật này mang tên Idle Scan (được tích hợp trong Nmap qua tham số -sI), cho phép khảo sát hệ thống mục tiêu mà không để lộ địa chỉ IP thật của người quét trong nhật ký tường lửa mục tiêu.

Cuộc tấn công bao gồm ba bên tham gia:

  1. Kẻ tấn công (Attacker): Hệ thống khởi xướng và đo đạc thông số.
  2. Máy Zombie: Một máy chủ nhàn rỗi trên Internet có bộ đếm IP ID tăng dần toàn cục và phát sinh rất ít lưu lượng nền.
  3. Máy mục tiêu (Target): Hệ thống cần thăm dò danh sách cổng mở và quy tắc lọc gói tin.

Toàn bộ quá trình do thám dựa vào việc điều khiển máy mục tiêu gửi phản hồi tới máy Zombie, sau đó đo lường độ lệch của bộ đếm IP ID trên Zombie.

Các bước thực thi kỹ thuật của kỹ thuật Idle Scan

Quá trình quét mỗi cổng mục tiêu diễn ra qua ba bước đồng bộ:

  1. Bước 1 - Lấy mốc cơ sở của Zombie: Kẻ tấn công gửi một gói SYN/ACK bất ngờ tới máy Zombie. Do không có kết nối TCP nào mở trước đó, Zombie phản hồi bằng gói RST mang giá trị định danh hiện tại ($IPID_1 = 1000$).
  2. Bước 2 - Gửi gói tin giả mạo tới mục tiêu: Kẻ tấn công tạo một gói SYN hướng tới cổng cần kiểm tra trên mục tiêu (ví dụ cổng 443), nhưng giả mạo địa chỉ IP nguồn thành địa chỉ của máy Zombie.
  3. Bước 3 - Kiểm tra độ lệch của Zombie: Kẻ tấn công gửi tiếp gói SYN/ACK thứ hai tới Zombie để kích hoạt gói RST mới, ghi nhận giá trị định danh kế tiếp ($IPID_2$).

Phân tích trạng thái cổng: Mở, Đóng và Lọc

Sự chênh lệch giữa hai lần đo ($\Delta = IPID_2 - IPID_1$) phản ánh chính xác trạng thái của cổng mục tiêu:

+-------------------------------------------------------------------------+
|                  BẢNG XÁC ĐỊNH TRẠNG THÁI CỔNG QUA ĐỘ LỆCH              |
+-------------------------------------------------------------------------+
| Trạng thái cổng   | Phản ứng của mục tiêu với SYN giả mạo | Độ lệch Zombie (Δ)|
| :---              | :---                                  | :---              |
| MỞ (OPEN)         | Gửi SYN/ACK về máy Zombie             | Δ = 2 (Cổng Mở)   |
|                   | Zombie gửi RST đáp trả (tiêu thụ ID)  |                   |
| ĐÓNG (CLOSED)     | Gửi RST về máy Zombie                 | Δ = 1 (Cổng Đóng) |
|                   | Zombie hủy RST không trả lời          |                   |
| LỌC (FILTERED)    | Tường lửa âm thầm bỏ qua              | Δ = 1 (Không phản |
|                   | Zombie không nhận được gì             |        hồi)       |
+-------------------------------------------------------------------------+
  • Cổng Mở ($\Delta = 2$): Mục tiêu chấp nhận kết nối và gửi SYN/ACK về máy Zombie. Zombie nhận được gói tin ngoài ý muốn nên lập tức gửi trả gói RST, khiến bộ đếm IP ID của nó tăng thêm một đơn vị. Khi kẻ tấn công thăm dò ở Bước 3, giá trị ghi nhận được tăng thêm 2 đơn vị so với ban đầu.
  • Cổng Đóng hoặc Bị lọc ($\Delta = 1$): Nếu cổng đóng, mục tiêu gửi RST tới Zombie (Zombie bỏ qua). Nếu bị tường lửa lọc, mục tiêu không phản hồi. Ở cả hai trường hợp, Zombie không phát gói tin nào ra ngoài, do đó bộ đếm chỉ tăng đúng 1 đơn vị do gói thăm dò thứ hai của kẻ tấn công.

Nhật ký phòng thủ IDS và tường lửa tại mục tiêu chỉ ghi nhận địa chỉ của Zombie, che giấu vị trí thực tế của kẻ tấn công.

Suy luận lưu lượng và theo dõi máy chủ xuyên mạng

Lỗ hổng kênh phụ IP ID không chỉ dừng lại ở việc quét cổng mục tiêu:

  1. Đo đạc lưu lượng máy chủ: Bằng cách thăm dò định kỳ IP ID của một máy chủ sau mỗi khoảng thời gian ngắn, người quan sát bên ngoài có thể ước tính tốc độ phát gói tin, nhận diện thời điểm sao lưu dữ liệu hoặc phiên làm việc của quản trị viên.
  2. Phát hiện liên kết nội bộ: Nếu hai máy chủ trao đổi dữ liệu trong mạng không mã hóa, việc đo lường bước tăng đồng thời trên hai bộ đếm IP ID có thể vạch trần mối liên hệ giữa chúng.
  3. Định danh thiết bị di chuyển: Các thiết bị đầu cuối trước đây duy trì hạt giống sinh số cố định, tạo cơ sở để đối tượng theo dõi nhận diện thiết bị khi chuyển đổi giữa các điểm truy cập Wi-Fi khác nhau.

Chuẩn hóa RFC 6864: Loại bỏ IP ID trên các gói tin nguyên tử

Tổ chức IETF đã chuẩn hóa giải pháp triệt để cho vấn đề này thông qua tài liệu RFC 6864: Updated Specification of the IPv4 ID Field vào đầu năm 2013.

Trên thực tế, hạ tầng mạng hiện đại áp dụng rộng rãi cơ chế khám phá MTU đường truyền (Path MTU Discovery - PMTUD, RFC 1191), thiết lập cờ Don't Fragment (DF = 1) cho đại đa số lưu lượng TCP và UDP. Các gói tin mang cờ DF = 1 và không bị phân mảnh được gọi là gói tin nguyên tử (atomic datagrams).

RFC 6864 đưa ra các nguyên tắc bắt buộc:

  • Gán giá trị 0: Máy gửi được phép và khuyến khích thiết lập trường IP ID bằng 0x0000 đối với mọi gói tin nguyên tử.
  • Miễn trừ bên nhận: Hệ điều hành bên nhận không được yêu cầu tính duy nhất của IP ID khi cờ DF = 1.
  • Hủy bỏ bộ đếm toàn cục: Nhân hệ điều hành tuyệt đối không được dùng chung một bộ đếm tuần tự cho các máy đích khác nhau.
+-------------------------------------------------------------------------+
|                  ĐỊNH DẠNG GÓI TIN NGUYÊN TỬ THEO RFC 6864              |
+-------------------------------------------------------------------------+
|  Tiêu đề IPv4:                                                          |
|  [ Version: 4 ] [ IHL: 5 ] [ DSCP/ECN ] [ Total Length: 1500 ]          |
|  [ Identification: 0x0000 ] <--- RFC 6864: Gán 0 cho gói tin nguyên tử |
|  [ Flags: DF=1, MF=0 ] [ Fragment Offset: 0 ]                           |
|  [ TTL: 64 ] [ Protocol: 6 (TCP) ] [ Header Checksum ]                  |
|  [ Source IP ] [ Destination IP ]                                       |
+-------------------------------------------------------------------------+

Cơ chế phòng thủ trên hệ điều hành hiện đại: Linux và BSD

Các hệ điều hành hiện đại đã loại bỏ hoàn toàn cơ chế tăng biến toàn cục cho trường IP ID.

Bảng băm theo kết nối và bộ sinh số ngẫu nhiên PRNG

Thay vì phụ thuộc vào một biến duy nhất, các hệ điều hành áp dụng kỹ thuật cách ly trạng thái:

  • Nhân Linux: Mặc định gán iph->id = 0 cho toàn bộ gói tin nguyên tử. Với gói tin cần phân mảnh, Linux sử dụng thuật toán băm mật mã (siphash) kết hợp địa chỉ nguồn, đích, giao thức và khóa bí mật của nhân để tra cứu trong bảng băm phân tán, đảm bảo giá trị IP ID chỉ tăng riêng biệt theo từng đối tác giao tiếp.
  • Nhân BSD và macOS: Triển khai bộ tạo số ngẫu nhiên giả an toàn mật mã (PRNG) nhằm tạo ra các chuỗi định danh không thể dự đoán cho từng phiên truyền dẫn.
  • Hệ thống Windows: Kể từ Windows 10 và Windows Server 2016, cơ chế bộ đếm toàn cục đã bị loại bỏ, thay thế bằng phân bổ ngẫu nhiên theo luồng kết nối.

Cách đường hầm VPN Lớp 3 và RiceGuard vô hiệu hóa rò rỉ IP ID

Các đường hầm VPN hoạt động ở Lớp 3 ở chế độ TUN (như WireGuard và OpenVPN) đem lại khả năng miễn nhiễm cấu trúc trước các nguy cơ khai thác kênh phụ IP ID.

Dịch vụ VPNRice xây dựng hạ tầng truyền dẫn dựa trên đóng gói mật mã chặt chẽ. Được vận hành bởi giao thức RiceGuard, toàn bộ gói tin của người dùng được bảo vệ bên trong các gói UDP đã xác thực trước khi truyền qua mạng công cộng.

+-------------------------------------------------------------------------+
|              CƠ CHẾ ĐÓNG GÓI VÀ CÁCH LY IP ID TRONG RICEGUARD           |
+-------------------------------------------------------------------------+
|  Ngăn xếp hệ điều hành máy khách:                                       |
|  [ Gói IP bên trong: TCP SYN gửi tới Mục tiêu | IP ID tạo bởi máy khách]|
|                              │                                          |
|                              ▼                                          |
|  Động cơ đường hầm RiceGuard:                                           |
|  [ Tải trọng mã hóa ChaCha20-Poly1305 (Ẩn hoàn toàn tiêu đề gốc) ]      |
|                              │                                          |
|                              ▼                                          |
|  Đường truyền mạng vật lý:                                              |
|  [ Tiêu đề IPv4 ngoài: UDP 51820 | IP ID ngoài = 0x0000 (RFC 6864) ]    |
+-------------------------------------------------------------------------+

RiceGuard triệt tiêu nguy cơ kênh phụ qua ba lớp bảo vệ:

  1. Đóng gói toàn diện tiêu đề: Tiêu đề IPv4 bên trong—bao gồm giá trị IP ID ban đầu—được mã hóa bên trong gói tin Noise. Đơn vị giám sát mạng bên ngoài không thể trích xuất hay đối chiếu định danh này.
  2. Tuân thủ chuẩn RFC 6864 ở lớp ngoài: Các gói tin UDP của đường hầm luôn thiết lập cờ DF = 1 với trường định danh ngoài mang giá trị 0x0000, không để lại bất kỳ độ lệch có thể đo đạc nào.
  3. Xác thực khóa công khai chống giả mạo: Máy chủ đầu cuối kiểm tra chữ ký mã hóa trước khi xử lý gói tin; các gói tin giả mạo thăm dò sẽ bị loại bỏ tức thì mà không làm thay đổi trạng thái giao vận.

Người dùng cần bảo vệ lưu lượng mạng trước các kỹ thuật do thám kênh phụ có thể tải ứng dụng chính thức tại trang tải VPN.

Kiểm tra thực tế: Phát hiện máy zombie dễ bị khai thác bằng Nmap

Kỹ sư mạng và chuyên viên bảo mật có thể kiểm tra xem máy chủ có tiềm ẩn nguy cơ bị khai thác làm zombie hay không thông qua công cụ Nmap:

# Kiểm tra máy chủ mục tiêu có sinh số IP ID tuần tự hay không
nmap -p 80,443 --script ipidseq 198.51.100.25

# Kết quả khi máy chủ có nguy cơ bị lợi dụng:
# Host script results:
# |_ipidseq: Incremental! (Có nguy cơ làm Zombie trong Idle Scan)

# Kết quả an toàn theo chuẩn RFC 6864:
# Host script results:
# |_ipidseq: All zeros! (An toàn: Tuân thủ chuẩn RFC 6864)

Nếu một máy chủ hiển thị trạng thái Incremental, kiểm thử viên có thể thử nghiệm mô phỏng quy trình quét trong phòng thí nghiệm được ủy quyền:

# Thực hiện Idle Scan sử dụng máy Zombie
nmap -Pn -sI 198.51.100.25:80 203.0.113.50

Nếu máy chủ trung gian đã được cấu hình an toàn với IP ID ngẫu nhiên hoặc gán bằng 0, Nmap sẽ dừng lại với thông báo: Cannot use zombie host: IP ID sequence is not incremental.

So sánh kiến trúc: Bộ đếm toàn cục đối chiếu bộ đếm ngẫu nhiên

Tiêu chí kỹ thuật Bộ đếm tăng tuần tự toàn cục Bảng băm ngẫu nhiên theo kết nối Gán số 0 theo RFC 6864 (RiceGuard)
Nguy cơ bị Idle Scan Rất cao Miễn nhiễm (Cách ly theo đối tác) Miễn nhiễm (Không có định danh)
Ước tính lưu lượng truyền Dễ bị suy đoán Bên thứ ba không thể tính toán Bên thứ ba không thể tính toán
Khả năng theo dõi thiết bị Cao (Tạo dấu vết tuần tự) Không đáng kể Bằng 0 (Trường tĩnh không đổi)
Hỗ trợ phân mảnh gói tin Đầy đủ Đầy đủ qua bảng băm Đầy đủ qua cơ chế PMTUD
Bộ nhớ nhân tiêu thụ 2 bytes (Biến toàn cục) Trung bình (Bảng băm trạng thái) Bằng 0 (Giá trị hằng số)
Tải xử lý CPU Thấp (++counter) Thấp (Tính toán SipHash) Tối thiểu (Cố định 0x0000)

Bước chuyển sang IPv6: Loại bỏ hoàn toàn định danh ở tiêu đề gốc

Giải pháp kiến trúc triệt để nhất cho kênh phụ IP ID được hoàn thiện trong chuẩn IPv6 (RFC 8200).

Nhận thấy hiện tượng phân mảnh chỉ xảy ra trên dưới 0.1% tổng lưu lượng Internet hiện đại, IPv6 đã loại bỏ hoàn toàn trường Identification khỏi tiêu đề cơ sở 40 byte cố định. Trong IPv6, các bộ định tuyến trung gian không bao giờ phân mảnh gói tin; việc phân mảnh chỉ được thực hiện tại máy phát thông qua Tiêu đề mở rộng phân mảnh (Fragment Extension Header) tùy chọn:

+-------------------------------------------------------------------------+
|                  TIÊU ĐỀ IPV6: LOẠI BỎ HOÀN TOÀN ĐỊNH DANH CỐ ĐỊNH      |
+-------------------------------------------------------------------------+
|  Tiêu đề cơ sở IPv6 (40 Bytes cố định):                                 |
|  [ Version: 6 ] [ Traffic Class ] [ Flow Label: 20 bits ]               |
|  [ Payload Length: 16 bits ] [ Next Header: 6 (TCP) ] [ Hop Limit: 64 ] |
|  [ Source IPv6 Address: 128 bits ]                                      |
|  [ Destination IPv6 Address: 128 bits ]                                 |
|                                                                         |
|  * KHÔNG CÓ TRƯỜNG IDENTIFICATION TRONG TIÊU ĐỀ CƠ SỞ! *                |
+-------------------------------------------------------------------------+

Do các gói tin nguyên tử trong IPv6 không mang tiêu đề phân mảnh, kẻ tấn công hoàn toàn không có trường dữ liệu nào để thăm dò độ lệch. Kỹ thuật Idle Scan trở nên bất khả thi về mặt cấu trúc trong mạng IPv6 thuần túy.

Danh mục kiểm tra phòng thủ kênh phụ IP ID cho quản trị viên

Quản trị viên hệ thống có thể triển khai các biện pháp sau để bảo vệ hạ tầng máy chủ:

  1. Áp dụng chuẩn RFC 6864: Triển khai nhân Linux phiên bản từ 4.0 trở lên nhằm đảm bảo các gói tin IPv4 nguyên tử luôn mang IP ID bằng 0.
  2. Duy trì cơ chế PMTUD: Mở lưu lượng ICMP Type 3 Code 4 (Fragmentation Needed) tại tường lửa biên để ngăn ngừa hiện tượng nghẽn phân mảnh.
  3. Kích hoạt lọc chống giả mạo (BCP 38): Thiết lập tính năng Unicast Reverse Path Forwarding (uRPF) trên các bộ định tuyến biên để ngăn chặn việc gửi gói tin giả mạo IP nguồn.
  4. Mã hóa kết nối nội bộ: Định tuyến toàn bộ lưu lượng kết nối giữa các trung tâm dữ liệu qua đường hầm RiceGuard để bảo vệ dữ liệu siêu giao vận.
  5. Đào thải nhân hệ điều hành cũ: Nâng cấp hoặc thay thế các máy chủ cũ và thiết bị nhúng vẫn còn sử dụng cơ chế tăng IP ID toàn cục.

Việc chuẩn hóa các giao thức hiện đại và áp dụng các giải pháp đường hầm mã hóa đã vô hiệu hóa hoàn toàn kênh phụ IP ID, bảo vệ hệ thống trước các kỹ thuật theo dõi lưu lượng ngầm.