Giao thức điều khiển truyền vận (TCP), được chuẩn hóa tại tài liệu RFC 793 năm 1981, giữ vai trò nền tảng trong việc truyền tải dữ liệu trên mạng internet toàn cầu. Khi xảy ra sự cố socket hoặc khi một đầu cuối ngắt kết nối đột ngột, TCP sử dụng cờ Reset (RST) để hủy bỏ phiên kết nối và giải phóng tài nguyên bộ nhớ hệ điều hành. Tuy nhiên, do phần mào đầu (header) của TCP nguyên bản không có cơ chế ký xác thực mật mã, bất kỳ thiết bị trung gian nào quan sát hoặc dự đoán được tham số phiên đều có thể tạo ra các gói tin RST giả mạo.

Kỹ thuật này được gọi là chèn gói TCP RST (TCP RST Injection). Các thiết bị kiểm soát gói tin chuyên sâu (DPI), thiết bị trung gian định tuyến hoặc kẻ tấn công trên đường truyền thường khai thác kỹ thuật này để ngắt quãng quá trình tải tập tin lớn, làm đứt gãy kết nối cơ sở dữ liệu dài hạn, ngắt phiên vỏ bảo mật (SSH) và ngăn chặn lưu lượng truy cập web.

Để hiểu rõ nguyên nhân khiến TCP dễ tổn thương trước các cuộc tấn công mù trong cửa sổ nhận (blind in-window attacks), chúng ta cần phân tích số học cửa sổ nhận của TCP, giải pháp chuẩn hóa RFC 5961 và cơ chế bao bọc mật mã tầng mạng.

[Tiếp nhận trong cửa sổ nhận theo chuẩn RFC 793 nguyên bản]
Dải cửa sổ nhận: [RCV.NXT = 10,000] <──────── 1,048,576 byte ────────> [1,058,576]
                                                  ▲
                               Gói RST giả mạo: SEQ = 450,000
                               (Được chấp thuận! Socket lập tức bị đóng)

─────────────────────────────────────────────────────────────────────────────────────────────

[Xác thực ngắt kết nối nghiêm ngặt theo chuẩn RFC 5961]
Dải cửa sổ nhận: [RCV.NXT = 10,000] <──────── 1,048,576 byte ────────> [1,058,576]
                 ▲                              ▲
Chỉ chấp thuận SEQ == 10,000!   Gói RST trong cửa sổ kích hoạt Challenge ACK;
                                Kết nối được duy trì an toàn và ổn định.

Bản chất kỹ thuật của việc chèn gói TCP RST và lỗ hổng cửa sổ nhận

Theo đặc tả gốc RFC 793, một nút mạng TCP ở trạng thái đã thiết lập kết nối (ESTABLISHED) khi nhận được một gói tin có bật cờ RST sẽ tiến hành kiểm tra biên cửa sổ nhận. Gói tin được xem là hợp lệ nếu:

$$\text{RCV.NXT} \le \text{SEG.SEQ} < \text{RCV.NXT} + \text{RCV.WND}$$

Trong đó $\text{RCV.NXT}$ là số thứ tự kế tiếp mà bên nhận đang chờ đợi và $\text{RCV.WND}$ là độ rộng cửa sổ nhận được thông báo.

Vào thập niên 1980, bộ đệm mạng và độ rộng cửa sổ còn khá khiêm tốn (thường dưới 64 KB). Tuy nhiên, các mạng băng thông rộng ngày nay đều kích hoạt tùy chọn mở rộng cửa sổ TCP Window Scale (RFC 7323), đẩy độ rộng cửa sổ nhận lên tới mức hàng megabyte (phổ biến từ 256 KB đến 4 MB).

Sự mở rộng này làm suy giảm đáng kể khả năng phòng ngự trước việc đoán số thứ tự:

  1. Thu hẹp không gian tìm kiếm: Trong không gian số thứ tự 32-bit ($2^{32} \approx 4,29 \times 10^9$ giá trị), việc đoán chính xác một số thứ tự duy nhất đòi hỏi hàng triệu lần thử. Nhưng để rơi trúng một cửa sổ nhận 2 MB, kẻ tấn công chỉ cần đoán trúng một dải gồm $2.097.152$ số liên tiếp.
  2. Xác suất thành công cao: Xác suất để một số thứ tự ngẫu nhiên rơi vào cửa sổ hợp lệ là $\frac{\text{RCV.WND}}{2^{32}}$. Với cửa sổ 2 MB, kẻ tấn công chỉ cần phát đi vài nghìn gói tin giả mạo là có thể khiến phiên kết nối bị đóng ngay lập tức.
  3. Tiêu hao tài nguyên bất đối xứng: Bên tấn công chỉ cần gửi đi các khung tin nhỏ (khoảng 40 đến 54 byte) với chi phí băng thông tối thiểu, trong khi bên nhận lập tức giải phóng toàn bộ bộ đệm socket và báo lỗi ngắt kết nối lên tầng ứng dụng.

Đối với các thiết bị nằm trực tiếp trên luồng truyền dẫn (in-path middlebox), việc chèn gói tin thậm chí không cần phải đoán. Thiết bị chỉ cần đọc bộ 5 tham số (địa chỉ IP nguồn, cổng nguồn, địa chỉ IP đích, cổng đích, giao thức) và giá trị $\text{SEG.SEQ}$ trong phần mào đầu TCP dạng văn bản rõ, sau đó phát ngay hai gói tin RST về cả hai phía máy khách và máy chủ.

Giải pháp chuẩn hóa RFC 5961 và rủi ro kênh phụ Challenge ACK

Tháng 8 năm 2010, IETF ban hành chuẩn RFC 5961 nhằm tăng cường độ vững chắc của TCP trước các cuộc tấn công chèn cờ RST, SYN và dữ liệu mù. Chuẩn này đưa ra các cải tiến kỹ thuật trọng tâm:

1. Kiểm tra số thứ tự chính xác đối với gói RST

Theo mục 3.2 của RFC 5961, một gói RST đến chỉ được chấp thuận để hủy kết nối ngay lập tức khi và chỉ khi số thứ tự trùng khớp tuyệt đối với số thứ tự kế tiếp mong đợi:

$$\text{SEG.SEQ} == \text{RCV.NXT}$$

Nếu số thứ tự nằm trong cửa sổ nhận nhưng không trùng khớp chính xác ($\text{RCV.NXT} < \text{SEG.SEQ} < \text{RCV.NXT} + \text{RCV.WND}$), ngăn xếp TCP không được phép đóng socket. Thay vào đó, nó phải tạo và gửi ngược lại một gói tin Challenge ACK về phía đầu cuối đối tác:

Máy khách                                                    Máy chủ
    |                                                           |
    | ------- Gói RST giả mạo (Trong cửa sổ, SEQ != RCV.NXT) --->|
    |                                                           |
    | <------ Challenge ACK (SEQ = SND.NXT, ACK = RCV.NXT) ----- |
    |                                                           |
    | (Bên tấn công ngoài luồng không thể phản hồi; luồng dữ liệu vẫn tiếp tục)

Gói Challenge ACK mang giá trị $\text{RCV.NXT}$ thực tế. Nếu gói RST xuất phát từ đối tác thực sự (ví dụ máy chủ khởi động lại), đối tác sẽ nhận được Challenge ACK và phản hồi lại một gói RST có số thứ tự khớp chuẩn với trường ACK, kết thúc phiên một cách minh bạch. Nếu gói RST do kẻ giả mạo phát tán, đối tác hợp lệ sẽ bỏ qua gói Challenge ACK và luồng truyền tải tiếp tục hoạt động mà không bị gián đoạn.

2. Giới hạn tần suất Challenge ACK và lỗ hổng CVE-2016-5696

Việc gửi gói tin xác thực Challenge ACK cho mọi gói tin rác có thể dẫn đến nguy cơ tấn công từ chối dịch vụ làm nghẽn đường truyền. Do đó, RFC 5961 quy định cơ chế giới hạn tần suất phát Challenge ACK.

Trên nhân hệ điều hành Linux, tham số này được cấu hình qua biến sysctl net.ipv4.tcp_challenge_ack_limit, ban đầu mặc định là 100 hoặc 250 gói mỗi giây trên toàn bộ hệ thống.

Năm 2016, nhóm nghiên cứu bảo mật do Zhiyun Qian dẫn đầu đã phát hiện ra lỗ hổng nghiêm trọng từ bộ đếm toàn cục này (mã định danh CVE-2016-5696). Do bộ đếm tần suất được dùng chung cho toàn bộ hệ thống thay vì phân lập theo từng socket, kẻ tấn công ngoài luồng có thể mở một kết nối TCP bình thường tới máy chủ nạn nhân. Bằng cách gửi các gói thăm dò tới socket của chính mình và quan sát số lượng phản hồi Challenge ACK nhận được, kẻ tấn công có thể suy đoán xem bộ đếm toàn cục đã bị trừ đi bởi gói tin thử nghiệm gửi tới kết nối của nạn nhân hay chưa.

Kênh phụ này cho phép kẻ tấn công ngoài luồng:

  • Xác định chính xác số cổng tạm thời (ephemeral port) của máy khách trong vài giây.
  • Dò tìm phạm vi số thứ tự chính xác của phiên kết nối đang hoạt động giữa hai máy chủ độc lập.
  • Chèn dữ liệu độc hại hoặc ép buộc ngắt phiên kết nối bất chấp sự hiện diện của RFC 5961.

Các bản vá nhân Linux sau đó đã triển khai cơ chế làm nhiễu ngẫu nhiên ngưỡng đếm và áp dụng bộ hẹn giờ phân tán theo từng luồng, làm tăng đáng kể độ phức tạp của phương thức tấn công này.

Nhận diện gói tin RST bị chèn qua phân tích lưu lượng

Quản trị viên mạng và kỹ sư an toàn thông tin có thể phát hiện hành vi chèn gói RST bằng cách trích xuất gói tin bằng công cụ tcpdump hoặc Wireshark. Các gói tin giả mạo từ thiết bị trung gian thường bộc lộ những dấu hiệu dị thường về mặt vật lý và cấu trúc mào đầu:

# Bắt các gói tin RST khả nghi trên giao diện mạng eth0
sudo tcpdump -ni eth0 'tcp[tcpflags] & tcp-rst != 0' -vvv -c 20

Bốn tiêu chí phân biệt giữa gói tin hợp lệ và gói tin chèn giả mạo:

Thuộc tính mào đầu Nút mạng đích thực sự Thiết bị trung gian chèn gói
Giá trị IP Time-to-Live (TTL) Suy giảm tự nhiên theo số bước nhảy (ví dụ 53 từ gốc 64) TTL bất thường (ví dụ 64 hoặc 255 từ router sát cạnh)
Độ rộng cửa sổ TCP Phản ánh đúng bộ đệm khả dụng Thường cố định ở mức 0, 512 hoặc 16384
Tùy chọn TCP Options Đầy đủ SACK-Permitted, Timestamps Bị cắt gọn (chỉ còn mào đầu cơ bản 20 byte)
Định danh gói tin (IPID) Tăng tuần tự hoặc phân bố ngẫu nhiên Bằng 0 hoặc sai lệch hoàn toàn quy luật đếm

Dấu hiệu giá trị TTL đột ngột tăng từ 52 lên 62 trên một gói tin RST gửi đến là bằng chứng cho thấy gói tin đó được phát sinh từ thiết bị định tuyến trung gian chứ không phải từ máy chủ gốc.

Tinh chỉnh tham số nhân hệ điều hành phòng ngừa tấn công

Quản trị viên hệ thống có thể kiểm tra và thiết lập các tham số hạt nhân liên quan đến RFC 5961 nhằm tăng cường khả năng chịu đựng của hệ thống:

# Kiểm tra giới hạn tần suất Challenge ACK hiện tại trên Linux
sysctl net.ipv4.tcp_challenge_ack_limit

# Nâng cao ngưỡng và kích hoạt cơ chế ngẫu nhiên hóa tần suất
sudo sysctl -w net.ipv4.tcp_challenge_ack_limit=2000

# Đảm bảo bật tính năng mở rộng cửa sổ và xác nhận chọn lọc
sudo sysctl -w net.ipv4.tcp_window_scaling=1
sudo sysctl -w net.ipv4.tcp_sack=1

Mặc dù việc tinh chỉnh tham số hạt nhân giúp giảm thiểu rủi ro dò đoán ngoài luồng, biện pháp này không thể ngăn chặn hoàn toàn các thiết bị trung gian có khả năng đọc trực tiếp mào đầu gói tin không mã hóa.

Bao bọc mật mã tầng mạng với giải pháp VPNRice RiceGuard

Gốc rễ của vấn đề chèn gói RST bắt nguồn từ việc mào đầu giao thức IPv4 và IPv6 không tích hợp cơ chế xác thực toàn vẹn bằng mật mã. Khi các cờ điều khiển giao vận được truyền ở dạng văn bản rõ qua các mạng công cộng, các thiết bị trung gian có thể can thiệp và chèn gói tin bất kỳ lúc nào.

Các giao thức mã hóa tầng ứng dụng như TLS 1.3 hoặc SSH bảo vệ nội dung dữ liệu bên trong, nhưng vẫn để lộ hoàn toàn lớp vỏ ngoài IP và TCP. Một thiết bị phân tích lưu lượng khi phát hiện trường Tên máy chủ (SNI) hoặc địa chỉ IP đích nhạy cảm có thể lập tức phát gói tin RST để phá vỡ socket giao vận bên dưới, ngay cả khi thiết bị đó không thể giải mã dữ liệu TLS.

[Truyền tải không mã hóa tầng mạng: Dễ bị thiết bị DPI chèn gói RST]
Mào đầu IP | Mào đầu TCP (Cờ RST, Số SEQ) | Dữ liệu ứng dụng TLS
                 ▲
                 Thiết bị trung gian chèn RST giả mạo -> Phiên kết nối bị ngắt!

─────────────────────────────────────────────────────────────────────────────────────────────

[Đóng gói an toàn bằng VPNRice RiceGuard: Bảo vệ toàn diện bằng mật mã]
Mào đầu IP ngoài | UDP ngoài (WireGuard) | Mã xác thực ChaCha20-Poly1305 | [IP trong | TCP trong | Dữ liệu]
                                                     ▲
                                Toàn bộ mào đầu bên trong được bảo vệ mật mã!
                Gói tin giả mạo không có khóa hợp lệ lập tức bị hệ thống loại bỏ.

Hệ thống VPNRice giải quyết triệt để rủi ro kiến trúc này thông qua việc đóng gói toàn bộ lưu lượng dữ liệu vào trong đường hầm mã hóa Lớp 3 ứng dụng động cơ RiceGuard:

  • Mã hóa xác thực với dữ liệu liên kết (AEAD): Từng gói tin truyền qua đường hầm đều được mã hóa bằng thuật toán ChaCha20 và xác thực bằng mã xác thực thông điệp Poly1305 128-bit.
  • Che giấu toàn bộ mào đầu giao vận: Các trường cờ điều khiển TCP, số thứ tự, số xác nhận và độ rộng cửa sổ của ứng dụng đều nằm trọn vẹn trong phần thân mã hóa của gói UDP bên ngoài. Đối với thiết bị giám sát mạng, lưu lượng chỉ hiển thị dưới dạng chuỗi byte ngẫu nhiên không thể phân tích.
  • Loại bỏ gói tin giả mạo ngay lập tức: Khi kẻ tấn công hoặc nhà mạng trung gian cố ý chèn một gói tin RST vào luồng truyền dẫn, gói tin đó sẽ không có mã xác thực Poly1305 hợp lệ và bị hệ thống mạng loại bỏ trực tiếp ở tầng nhân hệ thống với tốc độ dây, hoàn toàn không chạm tới ngăn xếp TCP bên trong.
  • Bảo vệ luồng phân giải DNS: Toàn bộ yêu cầu phân giải tên miền được dẫn truyền an toàn qua cụm máy chủ Anycast vận hành trên bộ nhớ tạm (RAM-only), ngăn ngừa nguy cơ lộ siêu dữ liệu kích hoạt việc chèn gói ngắt kết nối.

Nhờ việc đưa cơ chế xác thực mật mã xuống nền tảng của giao diện mạng, giải pháp đóng gói đường hầm bảo đảm các phiên truyền tải dữ liệu luôn duy trì tính liên tục, ổn định và miễn nhiễm trước các hành vi can thiệp trái phép trên hạ tầng mạng trung gian.