Lợi ích bảo mật

Giới thiệu: Các mối đe doạ và giảm thiểu bảo mật DNS

Do thiết kế mở, được phân phối của Hệ thống tên miền và việc sử dụng Giao thức dữ liệu người dùng (UDP), DNS dễ bị tấn công theo nhiều hình thức tấn công. Các trình phân giải DNS công khai hoặc "mở" định kỳ đang gặp rủi ro đặc biệt vì các trình phân giải này không hạn chế các gói đến cho một tập hợp các địa chỉ IP nguồn được phép. Chúng tôi chủ yếu quan tâm đến hai loại hình tấn công phổ biến:

  • Các cuộc tấn công giả mạo dẫn đến nhiễm độc bộ nhớ đệm DNS. Các loại hành vi giả mạo và giả mạo DNS khác nhau nhằm mục đích chuyển hướng người dùng từ các trang web hợp pháp đến các trang web độc hại. Những trường hợp này bao gồm gọi là cuộc tấn công Kaminsky, trong đó kẻ tấn công giành quyền kiểm soát toàn bộ khu vực DNS.
  • Các cuộc tấn công từ chối dịch vụ (DoS). Những kẻ tấn công có thể tự tiến hành các cuộc tấn công DDoS đối với những trình phân giải, hoặc các trình phân giải bị xâm nhập để chạy các cuộc tấn công DoS trên các hệ thống khác. Các cuộc tấn công sử dụng máy chủ DNS để khởi chạy các cuộc tấn công DoS vào các hệ thống khác bằng cách khai thác kích thước bản ghi/phản hồi lớn của DNS được gọi là tấn công bộ khuếch đại.

Từng lớp tấn công sẽ được thảo luận kỹ hơn dưới đây.

Cuộc tấn công đầu độc bộ nhớ đệm

Có một số biến thể của các cuộc tấn công giả mạo DNS có thể dẫn đến việc đầu độc bộ nhớ đệm, nhưng trường hợp chung như sau:

  1. Kẻ tấn công gửi nhiều trình phân giải DNS mục tiêu cho một tên miền mà họ biết rằng máy chủ không có thẩm quyền, và rất có thể tệp đó không nằm trong bộ nhớ đệm của máy chủ.
  2. Trình phân giải sẽ gửi yêu cầu đến các máy chủ định danh khác (mà địa chỉ IP mà kẻ tấn công cũng có thể dự đoán).
  3. Trong thời gian chờ đợi, kẻ tấn công tràn vào máy chủ nạn nhân bằng các phản hồi giả mạo có vẻ bắt nguồn từ máy chủ định danh được uỷ quyền. Phản hồi chứa bản ghi cuối cùng sẽ phân giải miền được yêu cầu đến các địa chỉ IP do kẻ tấn công kiểm soát. Các trường này có thể chứa bản ghi câu trả lời cho tên đã giải quyết hoặc tệ hơn là có thể ủy quyền thêm cho máy chủ định danh do kẻ tấn công sở hữu để có thể kiểm soát toàn bộ khu vực.
  4. Nếu một trong các phản hồi giả mạo khớp với yêu cầu của trình phân giải (ví dụ: theo tên truy vấn, loại, mã nhận dạng và cổng nguồn phân giải) và được nhận trước khi có phản hồi từ máy chủ định danh chính hãng, thì trình phân giải sẽ chấp nhận phản hồi giả mạo và lưu vào bộ nhớ đệm, đồng thời loại bỏ phản hồi chân thực.
  5. Các truy vấn trong tương lai cho miền hoặc vùng bị xâm phạm được trả lời bằng cách phân giải DNS giả mạo từ bộ nhớ đệm. Nếu kẻ tấn công đã chỉ định một thời gian tồn tại rất dài trên phản hồi giả mạo, thì các bản ghi giả mạo sẽ nằm trong bộ nhớ đệm trong thời gian dài nhất có thể mà không được làm mới.

Để được hướng dẫn tuyệt vời về các cuộc tấn công tại Kaminsky, hãy xem Hướng dẫn minh hoạ về lỗ hổng DNS Kaminsky.

Các cuộc tấn công DoS và khuếch đại

Trình phân giải DNS phải chịu các mối đe dọa DoS thông thường làm cản trở mọi hệ thống nối mạng. Tuy nhiên, các cuộc tấn công khuếch đại là mối quan tâm đặc biệt vì trình phân giải DNS là các mục tiêu hấp dẫn đối với những kẻ tấn công khai thác trình phân giải\39; tỷ lệ kích thước phản hồi lớn cho yêu cầu để có thêm băng thông miễn phí. Các trình phân giải hỗ trợ EDNS0 (tiện ích cơ chế cho DNS) đặc biệt dễ bị tấn công do kích thước gói lớn hơn đáng kể và có thể trả về.

Trong tình huống khuếch đại, cuộc tấn công sẽ diễn ra như sau:

  1. Kẻ tấn công gửi truy vấn máy chủ DNS của nạn nhân bằng cách sử dụng địa chỉ IP nguồn giả mạo. Các truy vấn có thể được gửi từ một hệ thống hoặc một mạng hệ thống, tất cả đều sử dụng cùng một địa chỉ IP giả mạo. Các truy vấn này là dành cho những bản ghi mà kẻ tấn công biết rằng sẽ dẫn đến những phản hồi lớn hơn, lên tới vài chục lần1 kích thước của các truy vấn ban đầu (do đó có tên "ampify" tấn công).
  2. Máy chủ nạn nhân gửi các phản hồi lớn đến địa chỉ IP nguồn được truyền trong các yêu cầu giả mạo, khiến hệ thống bị quá tải và gây ra tình huống DoS.

Giảm thiểu sự cố

Giải pháp chuẩn cho toàn bộ hệ thống đối với lỗ hổng DNS là DNSSEC. Tuy nhiên, cho đến khi được triển khai rộng rãi, các trình phân giải DNS mở cần độc lập thực hiện một số biện pháp để giảm thiểu các mối đe doạ đã biết. Chúng tôi đã đề xuất nhiều kỹ thuật. Hãy xem bài viết IETF RFC 5452: Các biện pháp giúp DNS có khả năng hồi phục hơn trước các câu trả lời giả mạo để biết thông tin tổng quan về hầu hết những kỹ thuật đó. Trong DNS Google Public, chúng tôi đã triển khai và khuyến nghị các phương pháp sau:

  • Bảo vệ mã của bạn trước lỗi tràn bộ đệm, đặc biệt là mã chịu trách nhiệm phân tích cú pháp và tuần tự hoá thông báo DNS.
  • Cung cấp quá mức tài nguyên của máy để bảo vệ bản thân trước các cuộc tấn công trực tiếp từ DoS vào các trình phân giải. Vì địa chỉ IP là rất nhỏ để kẻ tấn công giả mạo, nên không thể chặn các truy vấn dựa trên địa chỉ IP hoặc mạng con; cách duy nhất hiệu quả để xử lý những cuộc tấn công đó là chỉ cần hấp thụ tải.
  • Triển khai quy trình kiểm tra cơ bản tính hợp lệ của các gói phản hồi và độ tin cậy của máy chủ định danh để tránh bị nhiễm bộ nhớ đệm đơn giản. Đây là các cơ chế tiêu chuẩn và quy trình kiểm tra tính hợp lý mà mọi trình phân giải bộ nhớ đệm tuân thủ các tiêu chuẩn cần thực hiện.
  • Thêm entropy để yêu cầu thông báo, để giảm khả năng xảy ra các cuộc tấn công đầu độc giả mạo/bộ nhớ đệm phức tạp hơn, chẳng hạn như các cuộc tấn công Kaiminsky. Có nhiều kỹ thuật được khuyến nghị để thêm entropy. Dưới đây, chúng tôi cung cấp thông tin tổng quan về các lợi ích, giới hạn và thách thức của từng kỹ thuật này, cũng như thảo luận về cách chúng tôi triển khai các công nghệ này trong DNS công khai của Google.
  • Xóa các truy vấn trùng lặp để chống lại xác suất tấn công sinh nhật &&tt;
  • Yêu cầu giới hạn tốc độ để ngăn chặn các cuộc tấn công DoS và khuếch đại.
  • Theo dõi dịch vụ cho IP ứng dụng bằng cách sử dụng nhiều băng thông nhất và trải nghiệm tỷ lệ kích thước phản hồi cho yêu cầu cao nhất.

DNSSEC

Tiêu chuẩn của Tiện ích bảo mật tên miền (DNSSEC) được chỉ định trong một số RFC IETF: 4033, 4034, 4035 và 5155.

Các trình phân giải triển khai các cuộc tấn công đầu độc bộ nhớ đệm của DNSSEC bằng cách xác minh tính xác thực của phản hồi nhận được từ máy chủ định danh. Mỗi vùng DNS duy trì một tập hợp các cặp khoá riêng tư/công khai và đối với mỗi bản ghi DNS, một chữ ký số duy nhất sẽ được tạo và mã hoá bằng khoá riêng tư. Sau đó, khoá công khai tương ứng được xác thực qua một chuỗi tin cậy bằng các khoá thuộc vùng mẹ. Trình phân giải tuân thủ DNSSEC từ chối những phản hồi không chứa chữ ký chính xác. DNSSEC ngăn chặn hành vi can thiệp vào nội dung phản hồi một cách hiệu quả, vì trong thực tế, chữ ký gần như không thể giả mạo nếu không có quyền truy cập vào các khoá riêng tư.

Từ tháng 1 năm 2013, DNS Google Public sẽ hỗ trợ đầy đủ DNSSEC. Chúng tôi chấp nhận và chuyển tiếp thư được định dạng DNSSEC và xác thực phản hồi để xác thực chính xác. Chúng tôi rất khuyến khích các trình phân giải khác làm như vậy.

Chúng tôi cũng lưu các phản hồi NSEC vào bộ nhớ đệm như được chỉ định trong IETF RFC 8198: Mục đích sử dụng linh hoạt bộ nhớ đệm đã xác thực DNSSEC. Điều này có thể làm giảm truy vấn NXDOMAIN sang các máy chủ định danh triển khai DNSSEC và sử dụng NSEC để có câu trả lời phủ định.

Hoạt động truyền tải được mã hóa phía máy khách

DNS Google Public cung cấp dịch vụ hỗ trợ cho các giao thức truyền tải được mã hoá, DNS qua HTTPS và DNS qua TLS. Các giao thức này giúp ngăn chặn hành vi can thiệp, nghe trộm và giả mạo, từ đó giúp tăng cường đáng kể quyền riêng tư và tính bảo mật giữa máy khách và DNS Google Public. Chúng bổ sung DNSSEC để cung cấp hoạt động tra cứu DNS được xác thực hai đầu.

Triển khai kiểm tra tính hợp lệ cơ bản

Một số lỗi bộ nhớ đệm DNS có thể do vô tình và không nhất thiết là sự độc hại, không khớp giữa các yêu cầu và phản hồi (ví dụ: có thể do máy chủ định danh bị định cấu hình sai, lỗi trong phần mềm DNS, v.v.). Ở mức tối thiểu, trình phân giải DNS phải kiểm tra để xác minh độ tin cậy và mức độ liên quan của máy chủ định danh\39; phản hồi. Bạn nên (và triển khai) tất cả các biện pháp bảo vệ sau đây:

  • Không đặt bit đệ quy trong các yêu cầu đi và luôn tuân theo các chuỗi uỷ quyền một cách rõ ràng. Việc vô hiệu hoá bit định kỳ đảm bảo rằng trình phân giải của bạn hoạt động ở chế độ "iterative" để bạn truy vấn từng máy chủ định danh trong chuỗi ủy quyền một cách rõ ràng, thay vì cho phép một máy chủ định danh khác thực hiện các truy vấn này thay mặt bạn.
  • Từ chối tin nhắn trả lời đáng ngờ. Hãy xem bên dưới để biết chi tiết về những gì chúng tôi coi là "đáng ngờ"
  • Không trả về bản ghi A cho ứng dụng khách dựa trên bản ghi keo được lưu vào bộ nhớ đệm từ các yêu cầu trước đó. Ví dụ: nếu nhận được một truy vấn ứng dụng cho ns1.example.com, bạn nên phân giải lại địa chỉ thay vì gửi một bản ghi A dựa trên bản ghi keo đã lưu vào bộ nhớ đệm, được trả về từ máy chủ định danh .com.

Từ chối câu trả lời không đáp ứng các tiêu chí bắt buộc

DNS Google Public từ chối tất cả các mục sau:

  • Phản hồi không thể phân tích cú pháp hoặc không thể phân tích.
  • Phản hồi mà trong đó các trường chính không khớp với các trường tương ứng trong yêu cầu. Danh sách này bao gồm mã truy vấn, IP nguồn, cổng nguồn, IP đích hoặc tên truy vấn. Xem RFC 5452, Mục 3 để biết mô tả đầy đủ về hành vi giả mạo DNS.
  • Bản ghi không liên quan đến yêu cầu.
  • Các bản ghi câu trả lời mà chúng tôi không thể tạo lại chuỗi CNAME.
  • Các bản ghi (trong câu trả lời, quyền hạn hoặc các mục khác) mà máy chủ định danh tương ứng không đáng tin cậy. Chúng tôi xác định "credability" của máy chủ định danh theo vị trí trong chuỗi uỷ quyền cho một miền nhất định. Bộ nhớ đệm Google Public DNS sẽ lưu vào bộ nhớ đệm thông tin về chuỗi ủy quyền và chúng tôi xác minh từng phản hồi sắp tới dựa trên thông tin được lưu vào bộ nhớ đệm để xác định độ tin cậy của máy chủ định danh phản hồi cho việc phản hồi một yêu cầu cụ thể.

Thêm entropy vào yêu cầu

Khi trình phân giải thực thi các bước kiểm tra cơ bản về tình trạng, kẻ tấn công phải tràn trình phân giải nạn nhân để phản hồi mã truy vấn, cổng UDP (của yêu cầu), địa chỉ IP (của phản hồi) và tên truy vấn của yêu cầu ban đầu trước khi máy chủ định danh hợp lệ thực hiện.

Thật không may, điều này không khó đạt được, vì trường xác định duy nhất, ID truy vấn, chỉ dài 16 bit (tức là đối với cơ hội 1/65.536 nếu đúng). Các trường khác cũng bị giới hạn về phạm vi, khiến tổng số kiểu kết hợp riêng biệt trở thành một con số tương đối thấp. Xem RFC 5452, Mục 7 để tính toán các tổ hợp liên quan.

Do đó, thách thức là phải thêm nhiều entropy vào gói yêu cầu nhất có thể, trong định dạng chuẩn của thông báo DNS, để khiến những kẻ tấn công gặp khó khăn hơn trong việc khớp thành công một tổ hợp các trường hợp lệ trong cửa sổ cơ hội. Bạn nên và đã triển khai tất cả các kỹ thuật được thảo luận trong các phần sau đây.

Chúng tôi đã trình bày bài đánh giá mới về các kỹ thuật được đề cập ở đây tại hội nghị DNS OARC 38 vào tháng 7 năm 2022. Bản trình bày này cũng bao gồm các đề xuất cho toán tử máy chủ định danh.

Sắp xếp ngẫu nhiên các cổng nguồn

Ở bước cơ bản, không bao giờ cho phép các gói yêu cầu đi sử dụng cổng UDP 53 mặc định hoặc sử dụng thuật toán có thể dự đoán để gán nhiều cổng (ví dụ: tăng dần đơn giản). Sử dụng số lượng cổng lớn nhất từ 1024 đến 65535 cho phép trong hệ thống và sử dụng trình tạo số ngẫu nhiên đáng tin cậy để chỉ định cổng. Ví dụ: DNS Google Public sử dụng ~15 bit để cho phép khoảng 32.000 số cổng khác nhau.

Xin lưu ý rằng nếu các máy chủ của bạn được triển khai sau tường lửa, trình cân bằng tải hoặc các thiết bị khác thực hiện việc dịch địa chỉ mạng (NAT), thì những thiết bị đó có thể loại bỏ ngẫu nhiên các cổng trên gói gửi đi. Đảm bảo bạn định cấu hình thiết bị NAT để tắt cổng sắp xếp ngẫu nhiên.

Lựa chọn ngẫu nhiên máy chủ định danh

Một số trình phân giải, khi gửi yêu cầu đến thư mục gốc, TLD hoặc các máy chủ định danh khác, hãy chọn địa chỉ IP của máy chủ định danh dựa trên khoảng cách ngắn nhất (độ trễ). Bạn nên sắp xếp ngẫu nhiên các địa chỉ IP đích để thêm entropy vào các yêu cầu đi. Trong DNS Google Public, chúng tôi chỉ chọn ngẫu nhiên một máy chủ định danh trong số các máy chủ định danh đã định cấu hình cho mỗi vùng, có phần ưu tiên các máy chủ định danh nhanh và đáng tin cậy.

Nếu lo ngại về độ trễ, bạn có thể sử dụng tính năng thời gian trọn vòng (RTT), bao gồm việc sắp xếp ngẫu nhiên trong một phạm vi các địa chỉ có ngưỡng dưới một độ trễ nhất định (ví dụ: 30 mili giây, 300 mili giây, v.v.).

Cookie DNS

RFC 7873 xác định tùy chọn EDNS0 để thêm cookie 64 bit vào thông báo DNS. Một máy khách hỗ trợ cookie DNS bao gồm một cookie 64 bit ngẫu nhiên và một cookie tuỳ chọn (nếu biết) của máy chủ trong một yêu cầu. Nếu một máy chủ hỗ trợ tìm thấy tuỳ chọn cookie hợp lệ trong một yêu cầu, thì phản ánh cookie máy khách và cookie máy chủ chính xác trong phản hồi. Sau đó, ứng dụng hỗ trợ có thể xác minh phản hồi đến từ máy chủ dự kiến bằng cách xác minh cookie ứng dụng trong phản hồi.

Nếu máy chủ định danh không hỗ trợ cookie DNS, bạn có thể dùng hai tuỳ chọn sau để thêm entropy.

Sắp xếp ngẫu nhiên trường hợp trong tên truy vấn

Các tiêu chuẩn DNS yêu cầu máy chủ định danh phải phân biệt chữ hoa chữ thường. Ví dụ: tên example.com và EXAMPLE.COM phải phân giải thành cùng một địa chỉ IP2. Ngoài ra, tất cả trừ một số ít máy chủ định danh lặp lại tên trong phản hồi, như thể hiện trong yêu cầu, giữ nguyên trường hợp ban đầu.

Do đó, một cách khác để thêm entropy vào yêu cầu là thay đổi ngẫu nhiên trường hợp chữ cái trong các tên miền được truy vấn. Kỹ thuật này, còn được gọi là "0x20" vì bit 0x20 được dùng để đặt trường hợp chữ cái US-ASCII, trước tiên được đề xuất trong bản nháp Internet của IETF Sử dụng Bit 0x20 trong nhãn DNS để cải thiện nhận dạng giao dịch. Với kỹ thuật này, phản hồi của máy chủ định danh không chỉ phải khớp với tên truy vấn mà còn phải khớp với mọi chữ cái trong chuỗi tên; ví dụ: wWw.eXaMpLe.CoM hoặc WwW.ExamPLe.COm. Điều này có thể thêm ít hoặc không có giá trị entropy cho các truy vấn đối với miền cấp cao nhất và miền gốc, nhưng hiệu quả đối với hầu hết tên máy chủ.

Chúng tôi phát hiện ra một khó khăn lớn khi triển khai kỹ thuật này là một số máy chủ định danh không tuân theo hành vi phản hồi dự kiến:

  • Một số máy chủ định danh phản hồi hoàn toàn không phân biệt chữ hoa chữ thường: phản hồi chính xác cùng một kết quả bất kể yêu cầu là gì, nhưng phản hồi không khớp với trường hợp chính xác của tên trong yêu cầu.
  • Các máy chủ định danh khác phản hồi bằng phân biệt chữ hoa chữ thường, hoàn toàn phân biệt chữ hoa chữ thường (vi phạm các tiêu chuẩn DNS): chúng xử lý tên tương đương khác nhau tuỳ theo yêu cầu trong yêu cầu, hoặc không thể phản hồi hoặc trả về phản hồi NXDOMAIN không chính xác khớp với trường hợp chính xác của tên trong yêu cầu.
  • Một số máy chủ định danh hoạt động chính xác ngoại trừ các truy vấn PTR trong vùng arpa.

Đối với cả hai loại máy chủ định danh này, việc thay đổi trường hợp tên truy vấn sẽ dẫn đến kết quả không mong muốn: đối với nhóm đầu tiên, phản hồi sẽ không thể phân biệt được với phản hồi giả mạo; đối với nhóm thứ hai, phản hồi có thể hoàn toàn không chính xác.

Giải pháp hiện tại của chúng tôi cho vấn đề này là chỉ sử dụng ngẫu nhiên các trường hợp cho những máy chủ định danh mà chúng tôi biết là áp dụng chính xác các tiêu chuẩn. Chúng tôi cũng liệt kê các miền con ngoại lệ thích hợp cho từng miền con đó, dựa trên việc phân tích nhật ký của chúng tôi. Nếu một phản hồi có vẻ như đến từ các máy chủ đó không chứa đúng trường hợp, thì chúng tôi sẽ từ chối phản hồi. Các máy chủ định danh được bật sẽ xử lý hơn 70% lưu lượng truy cập vào trang của chúng tôi.

Đặt trước nhãn số chỉ dùng một lần để truy vấn tên

Nếu trình phân giải không thể phân giải trực tiếp tên từ bộ nhớ đệm hoặc không thể truy vấn trực tiếp máy chủ định danh có thẩm quyền, thì trình phân giải đó phải tuân theo các lượt giới thiệu từ máy chủ định danh gốc hoặc TLD. Trong hầu hết các trường hợp, yêu cầu đến máy chủ định danh gốc hoặc TLD sẽ dẫn đến việc giới thiệu đến một máy chủ định danh khác, thay vì cố gắng phân giải tên thành một địa chỉ IP. Do đó, đối với những yêu cầu như vậy, bạn nên đính kèm một nhãn ngẫu nhiên vào tên truy vấn để tăng hiệu quả của yêu cầu, trong khi không có nguy cơ không phân giải được một tên không tồn tại. Tức là, việc gửi yêu cầu đến máy chủ định danh giới thiệu cho một tên có tiền tố là nhãn một lần, chẳng hạn như entriih-f10r3.www.google.com, sẽ trả về kết quả giống như yêu cầu cho www.google.com.

Mặc dù trong thực tế, các yêu cầu như vậy chỉ chiếm chưa đến 3% số yêu cầu đi, giả sử lưu lượng truy cập thông thường (vì hầu hết truy vấn có thể được trả lời trực tiếp từ bộ nhớ đệm hoặc chỉ bằng một truy vấn), đây chính xác là những loại yêu cầu mà tấn công cố gắng buộc trình phân giải đưa ra. Do đó, kỹ thuật này có thể rất hiệu quả trong việc ngăn chặn các vụ khai thác kiểu Kaminsky.

Việc triển khai kỹ thuật này đòi hỏi nhãn chỉ dùng một lần chỉ được sử dụng cho các yêu cầu được đảm bảo sẽ dẫn đến lượt giới thiệu; nghĩa là các phản hồi không chứa bản ghi trong phần câu trả lời. Tuy nhiên, chúng tôi đã gặp một số thách thức khi cố gắng xác định tập hợp các yêu cầu như vậy:

  • Một số máy chủ định danh TLD của mã quốc gia (ccTLD) thực sự có thẩm quyền đối với TLD cấp 2 (2LD) khác. Mặc dù có hai nhãn, nhưng 2LD hoạt động giống như TLD, vì vậy, máy chủ định danh ccTLD thường xử lý những nhãn này. Ví dụ: máy chủ định danh .uk cũng có thẩm quyền đối với các vùng mod.uk và nic.uk, do đó, các tên máy chủ có trong các vùng đó, chẳng hạn như www.nic.uk, www.mod.uk, v.v. Nói cách khác, yêu cầu gửi đến máy chủ định danh ccTLD để phân giải những tên máy chủ như vậy sẽ không dẫn đến lượt giới thiệu, nhưng trong những câu trả lời có thẩm quyền; việc thêm nhãn số chỉ dùng một lần vào tên máy chủ như vậy sẽ khiến các tên không thể phân giải được.
  • Đôi khi, máy chủ định danh TLD (gTLD) chung sẽ trả về phản hồi không có căn cứ cho máy chủ định danh. Điều này có nghĩa là có một số tên máy chủ định danh xảy ra trong một vùng gTLD thay vì trong vùng cho miền của chúng. gTLD sẽ trả về câu trả lời không đáng tin cậy cho các tên máy chủ này, bằng cách sử dụng bất kỳ bản ghi keo nào có trong cơ sở dữ liệu của bạn, thay vì trả về một đường liên kết giới thiệu. Ví dụ: máy chủ định danh ns3.indexonlineserver.com trước đây nằm trong múi giờ gTLD .COM thay vì trong vùng indexonlineserver.com. Khi phát hành yêu cầu đến máy chủ gTLD cho n3.indexonlineserver.com, chúng tôi đã nhận được địa chỉ IP cho máy chủ đó, thay vì lượt giới thiệu. Tuy nhiên, nếu thêm một nhãn số chỉ dùng một lần, chúng tôi sẽ nhận được đường liên kết giới thiệu đến indexonlineserver.com. Sau đó, tên máy chủ không thể phân giải tên máy chủ. Do đó, chúng tôi không thể thêm nhãn số chỉ dùng một lần cho các máy chủ định danh yêu cầu độ phân giải từ máy chủ gTLD.
  • Cơ quan có thẩm quyền cho các vùng và tên máy chủ thay đổi theo thời gian. Điều này có thể khiến một tên máy chủ được thêm vào trước đó mà trước đây có thể giải quyết được để không thể phân giải được nếu chuỗi ủy quyền thay đổi.

Để giải quyết những thách thức này, chúng tôi đã định cấu hình ngoại lệ cho các tên máy chủ mà chúng tôi không thể thêm nhãn số chỉ dùng một lần. Đây là những tên máy chủ mà các máy chủ định danh của TLD trả về các phản hồi không giới thiệu, theo nhật ký máy chủ của chúng tôi. Chúng tôi liên tục xem xét danh sách ngoại lệ để đảm bảo rằng danh sách này luôn hợp lệ theo thời gian.

Xoá các cụm từ tìm kiếm trùng lặp

Các trình phân giải DNS dễ bị tấn công bằng "quot;birthday Birthday", được gọi vì các khai báo này khai thác nghịch lý "birthday miendox" trong đó khả năng trùng khớp không yêu cầu một số lượng lớn dữ liệu đầu vào. Các cuộc tấn công sinh nhật bao gồm việc tràn máy chủ của nạn nhân không chỉ bằng các phản hồi giả mạo mà còn kèm theo các truy vấn ban đầu, tính vào trình phân giải để tạo nhiều yêu cầu cho một độ phân giải tên duy nhất. Số lượng yêu cầu gửi đi càng lớn thì xác suất kẻ tấn công sẽ khớp một trong các yêu cầu đó với một phản hồi giả mạo: kẻ tấn công chỉ cần sắp xếp 300 yêu cầu đang tiến hành để có thành công 50% khi khớp một phản hồi giả mạo và 700 yêu cầu cho gần như thành công 100%.

Để chống lại chiến lược tấn công này, bạn nên loại bỏ tất cả các truy vấn trùng lặp khỏi hàng đợi gửi đi. Ví dụ: DNS Google Public không bao giờ cho phép có nhiều yêu cầu chưa xử lý cho cùng một tên truy vấn, loại truy vấn và địa chỉ IP đích.

Truy vấn giới hạn tốc độ

Việc ngăn chặn các cuộc tấn công từ chối dịch vụ đặt ra một số thách thức cụ thể đối với các trình phân giải DNS định kỳ mở:

  • Các trình phân giải định kỳ mở là các mục tiêu hấp dẫn để khởi chạy các cuộc tấn công khuếch đại. Đây là các máy chủ có dung lượng cao, độ tin cậy cao và có thể tạo ra phản hồi lớn hơn so với máy chủ định danh thông thường, đặc biệt là khi kẻ tấn công có thể chèn phản hồi lớn vào bộ nhớ đệm. Đối với mọi nhà phát triển dịch vụ DNS đang mở, các máy chủ của họ không được phép sử dụng để chạy các cuộc tấn công trên các hệ thống khác.
  • Các cuộc tấn công khuếch đại có thể khó phát hiện khi đang diễn ra. Các kẻ tấn công có thể khởi chạy một cuộc tấn công thông qua hàng nghìn trình phân giải mở, để mỗi trình phân giải chỉ nhìn thấy một phần nhỏ trong tổng khối lượng truy vấn và không thể trích xuất tín hiệu rõ ràng rằng nó đã bị xâm phạm.
  • Bạn phải chặn lưu lượng truy cập độc hại mà không gây gián đoạn hoặc làm giảm chất lượng dịch vụ DNS cho người dùng thông thường. DNS là một dịch vụ mạng thiết yếu, do đó, việc tắt máy chủ để cắt giảm sự tấn công không phải là một lựa chọn cũng như không từ chối dịch vụ đối với bất kỳ IP ứng dụng nào cụ thể quá lâu. Trình phân giải phải có khả năng chặn nhanh cuộc tấn công ngay khi bắt đầu, và khôi phục hoàn toàn dịch vụ hoạt động ngay khi cuộc tấn công kết thúc.

Phương pháp hay nhất để chống lại các cuộc tấn công DoS là áp dụng cơ chế giới hạn tốc độ hoặc "throttling". DNS Google Public triển khai hai loại kiểm soát giá:

  • Đánh giá khả năng kiểm soát yêu cầu đi tới máy chủ định danh khác. Để bảo vệ các máy chủ định danh DNS khác khỏi những cuộc tấn công DoS có thể khởi chạy từ các máy chủ phân giải của chúng tôi, DNS Công khai của Google sẽ thực thi các giới hạn QPS về các yêu cầu đi từ từng cụm máy chủ cho mỗi địa chỉ IP của máy chủ định danh.

  • Đánh giá mức độ kiểm soát của các phản hồi đi cho khách hàng. Để bảo vệ bất kỳ hệ thống nào khác khỏi các cuộc tấn công khuếch đại và truyền thống phân phối (DoS) truyền thống có thể bị khởi chạy từ các máy chủ phân giải của chúng tôi, DNS công khai của Google sẽ thực hiện hai loại giới hạn tốc độ đối với truy vấn máy khách:

    • Để bảo vệ khỏi các cuộc tấn công dựa trên lưu lượng truyền thống, mỗi máy chủ sẽ áp dụng QPS của mỗi máy khách và giới hạn băng thông trung bình.
    • Để phòng chống các cuộc tấn công khuếch đại, trong đó các phản hồi lớn cho các truy vấn nhỏ bị khai thác, mỗi máy chủ thực thi một hệ số khuếch đại trung bình tối đa trên mỗi máy khách IP. Hệ số khuếch đại trung bình là tỷ lệ có thể định cấu hình của kích thước phản hồi với truy vấn, được xác định từ các mẫu lưu lượng truy cập trong quá khứ được quan sát trong nhật ký máy chủ của chúng tôi.

    Nếu các truy vấn DNS từ một địa chỉ IP nguồn vượt quá tốc độ QPS tối đa, thì các truy vấn thừa sẽ bị loại bỏ. Nếu các truy vấn DNS qua UDP từ một địa chỉ IP nguồn vượt quá giới hạn trung bình hoặc băng thông khuếch đại một cách nhất quán (phản hồi không thường xuyên sẽ xảy ra), thì các truy vấn có thể bị bỏ qua hoặc chỉ có thể gửi một phản hồi nhỏ. Các phản hồi nhỏ có thể là phản hồi lỗi hoặc phản hồi trống với tập bit cắt ngắn (để hầu hết các truy vấn hợp lệ sẽ được thử lại qua TCP và thành công). Không phải tất cả hệ thống hoặc chương trình sẽ thử lại qua TCP và DNS có thể bị chặn bởi tường lửa phía máy khách, vì vậy, một số ứng dụng có thể không hoạt động chính xác khi câu trả lời bị cắt ngắn. Tuy nhiên, việc cắt bớt cho phép các ứng dụng tuân thủ RFC hoạt động đúng cách trong hầu hết các trường hợp.

  1. Hãy xem bài viết Các cuộc tấn công khuếch đại DNS bằng giấy để tìm hiểu ví dụ và một nội dung thảo luận hữu ích về vấn đề nói chung.↩

  2. RFC 1034, Mục 3.5 cho biết: ↩

    Xin lưu ý rằng mặc dù các chữ cái viết hoa và viết thường được cho phép trong tên miền, nhưng không có nghĩa quan trọng nào được đính kèm. Nghĩa là, hai tên có cùng một cách viết chính tả nhưng trường hợp khác nhau sẽ được coi là giống hệt nhau.