DNS Cache Snooping: Kỹ thuật dò bộ nhớ đệm và lá chắn phân giải riêng tư

Ngay cả khi các luồng dữ liệu mạng đã được bọc trong các lớp truyền tải mã hóa hiện đại như TLS 1.3 và HTTPS, bước phân giải tên miền vẫn thường xuyên làm lộ hoạt động duyệt web của người dùng. Các tổ chức doanh nghiệp và mạng gia đình thường có thói quen sử dụng chung máy chủ phân giải đệ quy DNS do nhà cung cấp dịch vụ Internet (ISP), các dịch vụ DNS công cộng hoặc bộ định tuyến mạng nội bộ cung cấp. Mặc dù cơ chế lưu đệm dùng chung này giúp tăng tốc độ tải trang bằng cách lưu tạm các địa chỉ IP đã phân giải, trạng thái bên trong vùng nhớ đệm lại tạo ra một kênh kề giám sát nguy hiểm: tấn công rà soát bộ nhớ đệm DNS (DNS Cache Snooping).

Bằng cách gửi các truy vấn không đệ quy tới máy chủ phân giải dùng chung hoặc đo đạc sự biến thiên của thời gian phản hồi, kẻ tấn công ở cả bên trong lẫn bên ngoài có thể xác định chính xác những tên miền nào vừa được các thiết bị khác truy cập. Kỹ thuật này không đòi hỏi vị trí tấn công đứng giữa (Man-in-the-Middle), không cần cài mã độc lên thiết bị nạn nhân và không cần giải mã các gói tin dữ liệu.

Hiểu rõ cơ chế hoạt động của DNS Cache Snooping là điều cốt lõi đối với các kỹ sư mạng khi thiết lập phòng tuyến cho doanh nghiệp cũng như những người dùng muốn bảo đảm tính biệt lập tuyệt đối cho dữ liệu. Khi kết hợp máy chủ phân giải chuyên dụng với đường hầm VPN Lớp 3 có xác thực mã hóa, nguy cơ rò rỉ này sẽ được triệt tiêu hoàn toàn.

Nghịch lý quyền riêng tư DNS: Tại sao mã hóa đường truyền vẫn khiến máy chủ phân giải bị lộ

Các tiêu chuẩn bảo mật hiện nay tập trung rất nhiều vào việc mã hóa dữ liệu trên đường truyền. HTTPS bảo vệ tiêu đề và nội dung trang web, trong khi DNS qua HTTPS (DoH, RFC 8484) và DNS qua TLS (DoT, RFC 7858) mã hóa truy vấn giữa thiết bị người dùng và máy chủ phân giải. Tuy nhiên, mã hóa đường truyền không hề làm thay đổi cách thức máy chủ đệ quy lưu trữ các bản ghi trong bộ nhớ RAM.

Máy chủ phân giải đệ quy luôn duy trì một bộ nhớ đệm nội bộ chứa các bản ghi tài nguyên (A, AAAA, CNAME, TXT) nhằm giảm tải truy vấn lên hệ thống máy chủ có thẩm quyền ở thượng nguồn và rút ngắn độ trễ cho người dùng tiếp theo. Khi một người dùng gửi truy vấn cho tên miền portal-noi-bo.example.org, máy chủ sẽ liên hệ với các máy chủ tên miền thượng nguồn, trả kết quả về cho máy khách, đồng thời lưu giữ bản ghi đó cho tới khi bộ đếm thời gian tồn tại (Time-to-Live - TTL) kết thúc:

[ Thiết bị người dùng ] ----> Truy vấn: example.org -----> [ Máy chủ phân giải ]
                                                                   |
                                                      (Chưa có cache: Tải thượng nguồn)
                                                                   |
                                                                   v
                                                        [ Máy chủ DNS thẩm quyền ]
                                                                   |
[ Thiết bị người dùng ] <---- Kết quả (TTL = 300s) <------ [ Máy chủ phân giải ]
                                                         (Lưu trong RAM: 300 giây)

Nếu một đối tượng theo dõi chia sẻ quyền truy cập vào cùng máy chủ đệ quy này, họ chỉ cần gửi một truy vấn cho cùng tên miền đó ngay sau đó. Nếu máy chủ trả về kết quả lập tức kèm theo giá trị TTL bị giảm xuống (chẳng hạn còn 242 giây), đối tượng này biết chắc chắn rằng ai đó trong mạng đã truy cập example.org vào khoảng 58 giây trước.

Bạn có thể tự kiểm tra cổng mạng công cộng và máy chủ định tuyến của mình qua công cụ kiểm tra địa chỉ IP và rò rỉ mạng để nhận diện đường đi của các gói tin.

Bản chất của tấn công DNS Cache Snooping: Thăm dò không đệ quy và đếm ngược TTL

Kỹ thuật rà soát bộ nhớ đệm DNS dựa trên hai phương pháp chính: thăm dò trực tiếp bằng truy vấn không đệ quy và phân tích thời gian phản hồi. Cả hai cách thức này đều khai thác dữ liệu từ vùng nhớ RAM tạm thời của máy chủ.

Cơ chế truy vấn không đệ quy: Cờ RD và kỹ thuật tra cứu bộ nhớ đệm

Trong tiêu đề của gói tin DNS có một trường bit quan trọng là Recursion Desired (RD) theo chuẩn RFC 1034 và RFC 1035. Khi bit này được gán giá trị 1, máy khách yêu cầu máy chủ phân giải đầy đủ nếu bản ghi chưa có trong bộ nhớ đệm. Ngược lại, khi bit này đặt bằng 0, máy khách chỉ yêu cầu máy chủ trả về dữ liệu nếu nó đã có sẵn trong bộ nhớ đệm cục bộ:

+-------------------------------------------------------------------------+
|                              Tiêu đề gói tin DNS                        |
+------------------+------------------+-----------------+-----------------+
|      ID (16)     | QR | Opcode (4)  | AA | TC | RD(0) | RA | Z | RCODE(4)|
+------------------+------------------+-----------------+-----------------+

Khi kẻ tấn công gửi một gói tin truy vấn với cờ RD = 0:

Trường hợp trúng cache (Cache Hit): Nếu có người vừa truy cập tên miền, máy chủ lập tức trả về phần Answer chứa bản ghi kèm theo thời gian tồn tại TTL còn lại.
Trường hợp trượt cache (Cache Miss): Nếu chưa có ai truy cập, máy chủ sẽ không tiến hành tìm kiếm thượng nguồn mà chỉ trả về danh sách các máy chủ gốc trong phần Authority, hoặc phản hồi bằng mã lỗi SERVFAIL hay REFUSED.

Sự khác biệt rõ ràng này giúp kẻ tấn công xác nhận lịch sử truy cập tên miền mà không để lại bất kỳ nghi ngờ nào.

Phân tích độ trễ: Đo lường biến thiên thời gian phản hồi để phát hiện tên miền trong cache

Một số quản trị viên đã cấu hình máy chủ từ chối các truy vấn có cờ RD = 0 từ các dải mạng lạ. Để ứng phó với hạn chế này, kẻ tấn công chuyển sang gửi truy vấn đệ quy thông thường (RD = 1) và bấm giờ đo lường thời gian khứ hồi (RTT):

+-----------------------+------------------------+------------------------+
| Trạng thái bản ghi    | Thời gian phản hồi RTT | Nguyên nhân vật lý     |
+-----------------------+------------------------+------------------------+
| Đã có trong Cache     | 1 ms - 5 ms            | Đọc trực tiếp từ RAM   |
| Chưa có trong Cache   | 45 ms - 250 ms         | Truy vấn qua Internet  |
+-----------------------+------------------------+------------------------+

Bởi vì một truy vấn chưa có trong bộ nhớ đòi hỏi quá trình liên lạc nhiều chặng qua các máy chủ gốc, máy chủ tên miền cấp cao nhất (TLD) và máy chủ thẩm quyền, khoảng cách thời gian giữa trúng cache và trượt cache chênh lệch tới hàng chục lần. Quét danh sách hàng nghìn tên miền mục tiêu cho phép kẻ tấn công lập biểu đồ hoạt động của các thiết bị trong mạng nạn nhân một cách âm thầm.

Giám sát và trinh sát mạng: Những thông tin bị rò rỉ cho kẻ tấn công

Tấn công dò bộ nhớ đệm DNS làm lộ nhiều thông tin nhạy cảm của tổ chức và người dùng:

Trinh sát phục vụ tấn công lừa đảo có chủ đích (Spear-Phishing): Kẻ tấn công quét các tên miền dịch vụ nội bộ, nền tảng điện toán đám mây như Jira, Okta hoặc cổng ngân hàng. Biết được tổ chức đang sử dụng giải pháp nào giúp chúng tạo ra các trang giả mạo và email lừa đảo tinh vi, đánh trúng thói quen của nhân viên.
Phát hiện hoạt động điều tra của đội ngũ bảo mật: Khi các chuyên gia bảo mật điều tra một máy chủ điều khiển mã độc (C2), các công cụ phân tích sẽ truy vấn tên miền nghi vấn. Kẻ tấn công theo dõi bộ nhớ đệm của máy chủ DNS doanh nghiệp sẽ lập tức phát hiện tên miền của mình vừa được tra cứu, từ đó kích hoạt cơ chế xóa dấu vết trước khi bị phát hiện toàn diện.
Lập hồ sơ hành vi người dùng: Trên các mạng Wi-Fi công cộng hoặc khu dân cư, việc rà soát các dịch vụ tài chính, y tế hoặc trang web nhạy cảm giúp đối tượng xấu nắm bắt được thói quen sinh hoạt và lịch trình của người dùng.
Xác định mốc thời gian chính xác qua TTL: Do các bản ghi DNS từ máy chủ thẩm quyền luôn có mức TTL ban đầu cố định (chẳng hạn 3600 giây), lấy mức TTL ban đầu trừ đi số TTL trả về sẽ cho ra chính xác số giây đã trôi qua kể từ lúc người dùng gửi yêu cầu:

$$ ext{Thời gian đã trôi qua} = ext{TTL gốc} - ext{TTL phản hồi}$$

So sánh các véc-tơ tấn công: Cache Snooping, nghe lén thụ động và đầu độc Kaminsky

Các mối đe dọa liên quan tới DNS hoạt động trên các tầng khác nhau với mức độ can thiệp khác biệt:

Véc-tơ tấn công	Cơ chế hoạt động	Mức độ nguy hiểm	Vị trí yêu cầu	Mục tiêu chính
Nghe lén thụ động	Bắt gói tin UDP 53 không mã hóa	Cao	Đứng trên đường truyền mạng	Đọc trộm nội dung truy vấn
Đầu độc bộ nhớ đệm	Giả mạo Transaction ID và cổng UDP	Nghiêm trọng	Ngoài luồng hoặc trên luồng	Đổi hướng người dùng sang IP độc
DNS Cache Snooping	Truy vấn không đệ quy hoặc đo trễ RTT	Cao	Cùng dùng máy chủ phân giải	Rà soát lịch sử duyệt web

Khác với các kỹ thuật tấn công thay đổi nội dung dữ liệu như phân tích trong bài viết về tấn công đầu độc bộ nhớ đệm DNS và giải pháp phòng thủ, Cache Snooping không hề can thiệp hay sửa đổi dữ liệu mà biến chính tính năng hợp lệ của máy chủ thành công cụ do thám.

Hiểm họa từ cấu hình máy chủ: Mở đệ quy tự do và sai sót danh sách kiểm soát truy cập

Nguyên nhân căn bản khiến việc rà quét bộ nhớ đệm trở nên phổ biến trên Internet là do các máy chủ phân giải mở (Open Resolvers). Đây là những hệ thống chấp nhận xử lý truy vấn cho bất kỳ địa chỉ IP nào trên không gian mạng toàn cầu mà không áp dụng bộ lọc nguồn.

Các nghiên cứu đo lường cho thấy hàng triệu thiết bị định tuyến người dùng và máy chủ đệ quy doanh nghiệp vẫn đang mở cổng 53 ra mạng diện rộng (WAN). Khi kết hợp với cấu hình mặc định cho phép phản hồi các yêu cầu không đệ quy, bất kỳ ai từ bên ngoài cũng có thể lục lọi lịch sử duyệt web của toàn bộ các máy trạm bên trong mạng.

Ngay cả khi đệ quy công cộng đã được tắt, mọi thiết bị cùng kết nối vào một mạng nội bộ doanh nghiệp hoặc điểm phát Wi-Fi công cộng vẫn có thể thăm dò bộ nhớ đệm của nhau một cách dễ dàng.

Gia cố máy chủ phân giải: Chiến lược phân vùng bộ nhớ đệm trên BIND và Unbound

Để hạn chế tình trạng rà soát bộ nhớ đệm, người quản trị cần giới hạn phạm vi truy vấn, chặn phản hồi không đệ quy cho các máy khách lạ và phân chia vùng phân giải.

Kiểm soát truy cập và tách vùng trên BIND 9: Trên máy chủ BIND 9, cần giới hạn quyền truy vấn đệ quy chỉ dành riêng cho các dải mạng nội bộ tin cậy:

acl "trusted_lan" {
    127.0.0.1;
    10.0.0.0/8;
    192.168.1.0/24;
};

options {
    recursion yes;
    allow-recursion { trusted_lan; };
    allow-query { trusted_lan; };
    allow-query-cache { trusted_lan; };
    version none;
    hostname none;
};

Thiết lập thuộc tính allow-query-cache chặt chẽ sẽ ngăn chặn hoàn toàn các máy chủ bên ngoài trích xuất bản ghi đệm.

Gia cố bảo mật và tối thiểu hóa truy vấn trên Unbound: Unbound cung cấp các tùy chọn tinh tế nhằm khóa chặt kênh kề này:

server:
    access-control: 127.0.0.1/32 allow
    access-control: 10.200.0.0/16 allow
    access-control: 0.0.0.0/0 refuse
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes
    minimal-responses: yes

Kích hoạt qname-minimisation (RFC 7816) giúp giảm thiểu lượng dữ liệu tên miền gửi lên các máy chủ trung gian, trong khi access-control sẽ chặn các gói tin thăm dò từ những dải IP không được cấp quyền.

Máy chủ phân giải cô lập RiceGuard: Loại bỏ nguy cơ từ bộ nhớ đệm dùng chung qua VPN

Mặc dù việc thiết lập máy chủ riêng giúp bảo vệ các văn phòng cố định, người dùng di động và làm việc từ xa khi ra ngoài vẫn phải kết nối qua các điểm truy cập Wi-Fi công cộng hay mạng nhà mạng không đáng tin cậy. VPNRice xử lý rủi ro này tận gốc thông qua kiến trúc giao thức RiceGuard:

[ Ứng dụng trên thiết bị ]
             |
             v
[ Trình phân giải cục bộ (127.0.0.1:53) ]
             | (Bắt chặn trên giao diện loopback)
             v
+-------------------------------------------------------+
| Đường hầm RiceGuard Lớp 3 có xác thực (Lõi WireGuard) |
+-------------------------------------------------------+
             |
             | (Gói tin mã hóa qua mạng công cộng)
             v
+-------------------------------------------------------+
| Máy chủ đệ quy cô lập theo phiên (Không chia sẻ RAM)  |
+-------------------------------------------------------+
             |
             v (Truy vấn đệ quy với QNAME tối thiểu)
[ Máy chủ DNS có thẩm quyền trên Internet ]

Không gian bộ nhớ đệm phân vùng theo phiên đường hầm: Thay vì dồn dữ liệu của tất cả người dùng vào một vùng nhớ đệm khổng lồ, RiceGuard khởi tạo các vùng nhớ đệm cô lập cho từng phiên mã hóa. Người dùng này hoàn toàn không thể chạm tới vùng nhớ đệm của người dùng khác, triệt tiêu khả năng thăm dò chéo.
Mã hóa cưỡng bức lên máy chủ chuyên dụng: Mọi gói tin DNS đều được dẫn truyền an toàn qua đường hầm Lớp 3 tới hệ thống phân giải đã được tôi luyện. Những kẻ theo dõi trên cùng mạng Wi-Fi chỉ thấy các gói tin UDP được bọc kín bởi mật mã hiện đại.
Cơ chế phân giải không lưu định danh: Tận dụng các nguyên lý bảo mật tương tự như kiến trúc phân giải ẩn danh Oblivious DNS qua HTTPS, máy chủ xử lý đệ quy không thể ghép nối danh tính địa chỉ IP của thiết bị với tên miền được yêu cầu.

Để bảo vệ thiết bị và ngăn chặn hoàn toàn nguy cơ bị lập hồ sơ qua máy chủ DNS dùng chung, bạn có thể Tải VPNRice.

Thử nghiệm thực tế: Độ trễ phản hồi, tỷ lệ phát hiện cache và nguy cơ rò rỉ dữ liệu

Trong môi trường thử nghiệm kiểm chuẩn, các chuyên gia đã tiến hành đánh giá khả năng trinh sát bộ nhớ đệm trên các mô hình máy chủ khác nhau:

Mô hình máy chủ	Thăm dò không đệ quy (`RD = 0`)	Độ tin cậy đo độ trễ RTT	Độ trễ khi trúng cache	Độ trễ khi trượt cache	Tỷ lệ trinh sát thành công
Máy chủ mở mặc định	Được phép (Trả lời trực tiếp)	100% Chính xác	1.8 ms	114.2 ms	100%
Máy chủ ISP có chặn RD	Bị từ chối (`REFUSED`)	94.6% Chính xác theo RTT	3.4 ms	88.5 ms	94.6% (Dựa trên thời gian)
Đường hầm RiceGuard	Chặn ngoài dải cho phép	0.0% (Không thể đối sánh)	12.1 ms (Có mã hóa)	48.6 ms	0.0% (Bộ nhớ cô lập)

Kết quả đo đạc khẳng định rằng việc chỉ chặn cờ RD = 0 là chưa đủ nếu sự chênh lệch thời gian phản hồi vẫn tồn tại. Giải pháp an toàn thực sự là phải cô lập triệt để vùng nhớ đệm theo từng đường hầm kết nối.

Hướng dẫn triển khai thực tế: Thiết lập bảo mật máy chủ đệ quy và rà soát bộ nhớ đệm

Các quản trị viên hệ thống có thể chủ động kiểm tra mức độ an toàn của hệ thống phân giải trong nội bộ bằng các công cụ mạng tiêu chuẩn.

Cấu hình giới hạn truy cập và tối thiểu hóa QNAME trên Unbound

Đoạn cấu hình mẫu sau đây có thể triển khai trực tiếp vào tệp unbound.conf để ngăn chặn hành vi rà quét bộ nhớ:

server:
    interface: 10.200.0.1
    port: 53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # Kiểm soát truy cập: chỉ cho phép máy khách trong đường hầm
    access-control: 10.200.0.0/24 allow
    access-control: 0.0.0.0/0 refuse

    # Các tùy chọn bảo vệ quyền riêng tư
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    qname-minimisation: yes

Kiểm tra lỗ hổng DNS Cache Snooping bằng công cụ chẩn đoán Dig

Để kiểm tra xem một máy chủ có đang phản hồi các yêu cầu không đệ quy hay không, hãy sử dụng lệnh dig:

# Thử nghiệm 1: Gửi truy vấn không đệ quy đối với tên miền mục tiêu
dig +norecurse @10.200.0.1 example.org A

# Đánh giá kết quả:
# - Nếu nhận được phần Answer kèm TTL: Máy chủ CÓ LỖ HỔNG
# - Nếu trạng thái là REFUSED hoặc phần Answer trống: Đã chặn thăm dò không đệ quy

# Thử nghiệm 2: Đo lường thời gian phản hồi giữa bản ghi có sẵn và chưa có
dig +noall +stats @10.200.0.1 example.org
dig +noall +stats @10.200.0.1 ten-mien-ngau-nhien-chua-truy-cap-93821.org

Việc rà soát định kỳ giúp phát hiện sớm các sơ hở trong cấu hình máy chủ, bảo vệ lịch sử duyệt web của người dùng trước các kỹ thuật thám thính âm thầm.