Giảm thiểu rủi ro khi sử dụng DNS-over-TLS (DoT) và DNS-over-HTTPS (DoH)

Giảm thiểu rủi ro khi sử dụng DNS-over-TLS (DoT) và DNS-over-HTTPS (DoH)Giảm thiểu rủi ro khi sử dụng DoH và DoT

Bảo vệ DoH và DoT

Bạn có kiểm soát lưu lượng DNS của mình không? Các tổ chức đầu tư rất nhiều thời gian, tiền bạc và công sức vào việc bảo mật mạng của họ. Tuy nhiên, một lĩnh vực thường không được quan tâm đúng mức là DNS.

Một cái nhìn tổng quan tốt về những rủi ro mà DNS mang lại là Bài thuyết trình của Verisign tại hội nghị An toàn thông tin.

Giảm thiểu rủi ro khi sử dụng DNS-over-TLS (DoT) và DNS-over-HTTPS (DoH)31% loại ransomware được khảo sát đã sử dụng DNS để trao đổi khóa.

31% các loại ransomware được khảo sát đã sử dụng DNS để trao đổi khóa.

Vấn đề là nghiêm trọng. Theo phòng thí nghiệm nghiên cứu Palo Alto Networks Unit 42, khoảng 85% phần mềm độc hại sử dụng DNS để thiết lập kênh chỉ huy và kiểm soát, cho phép kẻ tấn công dễ dàng đưa phần mềm độc hại vào mạng của bạn cũng như đánh cắp dữ liệu. Kể từ khi thành lập, lưu lượng DNS phần lớn không được mã hóa và có thể dễ dàng phân tích bằng cơ chế bảo mật NGFW. 

Các giao thức mới cho DNS đã xuất hiện nhằm mục đích tăng tính bảo mật của các kết nối DNS. Chúng được hỗ trợ tích cực bởi các nhà cung cấp trình duyệt hàng đầu và các nhà cung cấp phần mềm khác. Lưu lượng DNS được mã hóa sẽ sớm bắt đầu phát triển trong các mạng công ty. Lưu lượng DNS được mã hóa không được phân tích và giải quyết chính xác bằng các công cụ sẽ gây ra rủi ro bảo mật cho công ty. Ví dụ: mối đe dọa như vậy là những kẻ khóa mật mã sử dụng DNS để trao đổi khóa mã hóa. Những kẻ tấn công hiện đang yêu cầu khoản tiền chuộc vài triệu đô la để khôi phục quyền truy cập vào dữ liệu của bạn. Ví dụ, Garmin đã trả 10 triệu USD.

Khi được định cấu hình đúng, NGFW có thể từ chối hoặc bảo vệ việc sử dụng DNS-over-TLS (DoT) và có thể được sử dụng để từ chối việc sử dụng DNS-over-HTTPS (DoH), cho phép phân tích tất cả lưu lượng DNS trên mạng của bạn.

DNS được mã hóa là gì?

DNS là gì

Hệ thống tên miền (DNS) phân giải các tên miền mà con người có thể đọc được (ví dụ: địa chỉ www.paloaltonetworks.com ) thành địa chỉ IP (ví dụ: 34.107.151.202). Khi người dùng nhập tên miền vào trình duyệt web, trình duyệt sẽ gửi truy vấn DNS đến máy chủ DNS, yêu cầu địa chỉ IP được liên kết với tên miền đó. Đáp lại, máy chủ DNS trả về địa chỉ IP mà trình duyệt này sẽ sử dụng.

Các truy vấn và phản hồi DNS được gửi qua mạng ở dạng văn bản thuần túy, không được mã hóa, khiến mạng dễ bị theo dõi hoặc thay đổi phản hồi và chuyển hướng trình duyệt đến các máy chủ độc hại. Mã hóa DNS khiến các yêu cầu DNS khó được theo dõi hoặc thay đổi trong quá trình truyền. Mã hóa các yêu cầu và phản hồi DNS bảo vệ bạn khỏi các cuộc tấn công trung gian trong khi thực hiện chức năng tương tự như giao thức DNS (Hệ thống tên miền) văn bản gốc truyền thống. 

Trong vài năm qua, hai giao thức mã hóa DNS đã được giới thiệu:

  1. DNS qua HTTPS (DoH)

  2. DNS qua TLS (DoT)

Các giao thức này có một điểm chung: chúng cố tình che giấu các yêu cầu DNS khỏi bất kỳ hoạt động chặn nào... và cả với các nhân viên bảo vệ của tổ chức. Các giao thức chủ yếu sử dụng TLS (Transport Layer Security) để thiết lập kết nối được mã hóa giữa máy khách thực hiện truy vấn và máy chủ giải quyết các truy vấn DNS qua một cổng thường không được sử dụng cho lưu lượng DNS.

Tính bảo mật của các truy vấn DNS là một điểm cộng lớn của các giao thức này. Tuy nhiên, chúng gây ra vấn đề cho nhân viên bảo vệ, những người phải giám sát lưu lượng mạng cũng như phát hiện và chặn các kết nối độc hại. Bởi vì các giao thức khác nhau trong cách triển khai nên các phương pháp phân tích sẽ khác nhau giữa DoH và DoT.

DNS qua HTTPS (DoH)

Giảm thiểu rủi ro khi sử dụng DNS-over-TLS (DoT) và DNS-over-HTTPS (DoH)DNS bên trong HTTPS

DoH sử dụng cổng 443 nổi tiếng cho HTTPS, trong đó RFC tuyên bố cụ thể rằng mục đích là "trộn lưu lượng DoH với lưu lượng HTTPS khác trên cùng một kết nối", "gây khó khăn cho việc phân tích lưu lượng DNS" và do đó phá vỡ các biện pháp kiểm soát của công ty ( RFC 8484 DoH Mục 8.1 ). Giao thức DoH sử dụng mã hóa TLS và cú pháp yêu cầu được cung cấp bởi các tiêu chuẩn HTTPS và HTTP/2 phổ biến, thêm các yêu cầu và phản hồi DNS lên trên các yêu cầu HTTP tiêu chuẩn.

Rủi ro liên quan đến DoH

Nếu bạn không thể phân biệt lưu lượng HTTPS thông thường với yêu cầu DoH thì các ứng dụng trong tổ chức của bạn có thể (và sẽ) bỏ qua cài đặt DNS cục bộ bằng cách chuyển hướng yêu cầu đến máy chủ bên thứ ba phản hồi yêu cầu DoH, bỏ qua mọi giám sát, nghĩa là phá hủy khả năng kiểm soát lưu lượng DNS. Tốt nhất, bạn nên kiểm soát DoH bằng chức năng giải mã HTTPS. 

И Google và Mozilla đã triển khai khả năng DoH trong phiên bản trình duyệt mới nhất của họ và cả hai công ty đều đang nỗ lực sử dụng DoH theo mặc định cho tất cả các yêu cầu DNS. Microsoft cũng đang phát triển kế hoạch về việc tích hợp DoH vào hệ điều hành của họ. Nhược điểm là không chỉ các công ty phần mềm uy tín mà cả những kẻ tấn công cũng bắt đầu sử dụng DoH như một phương tiện để vượt qua các biện pháp tường lửa truyền thống của công ty. (Ví dụ: xem lại các bài viết sau: PsiXBot hiện sử dụng Google DoH , PsiXBot tiếp tục phát triển với cơ sở hạ tầng DNS được cập nhật и Phân tích cửa sau Godlua .) Trong cả hai trường hợp, cả lưu lượng truy cập DoH tốt và độc hại sẽ không bị phát hiện, khiến tổ chức không nhận ra việc sử dụng DoH có mục đích xấu làm đường dẫn để kiểm soát phần mềm độc hại (C2) và đánh cắp dữ liệu nhạy cảm.

Đảm bảo khả năng hiển thị và kiểm soát lưu lượng DoH

Là giải pháp tốt nhất để kiểm soát DoH, chúng tôi khuyên bạn nên định cấu hình NGFW để giải mã lưu lượng HTTPS và chặn lưu lượng DoH (tên ứng dụng: dns-over-https). 

Trước tiên, hãy đảm bảo NGFW được định cấu hình để giải mã HTTPS, theo hướng dẫn về kỹ thuật giải mã tốt nhất.

Thứ hai, tạo quy tắc cho lưu lượng truy cập ứng dụng "dns-over-https" như hiển thị bên dưới:

Giảm thiểu rủi ro khi sử dụng DNS-over-TLS (DoT) và DNS-over-HTTPS (DoH)Quy tắc NGFW của Palo Alto Networks để chặn DNS-over-HTTPS

Là một giải pháp thay thế tạm thời (nếu tổ chức của bạn chưa triển khai đầy đủ giải mã HTTPS), NGFW có thể được định cấu hình để áp dụng hành động "từ chối" đối với ID ứng dụng "dns-over-https", nhưng hiệu quả sẽ bị giới hạn ở việc chặn một số các máy chủ DoH đã biết theo tên miền của chúng, vậy làm sao nếu không giải mã HTTPS, lưu lượng DoH không thể được kiểm tra đầy đủ (xem  Applipedia từ Palo Alto Networks   và tìm kiếm "dns-over-https").

DNS qua TLS (DoT)

Giảm thiểu rủi ro khi sử dụng DNS-over-TLS (DoT) và DNS-over-HTTPS (DoH)DNS bên trong TLS

Mặc dù giao thức DoH có xu hướng trộn lẫn với lưu lượng truy cập khác trên cùng một cổng, nhưng thay vào đó, DoT lại mặc định sử dụng một cổng đặc biệt dành riêng cho mục đích duy nhất đó, thậm chí đặc biệt không cho phép lưu lượng truy cập DNS không được mã hóa truyền thống sử dụng cùng một cổng đó ( RFC 7858, Mục 3.1 ).

Giao thức DoT sử dụng TLS để cung cấp mã hóa gói gọn các truy vấn giao thức DNS tiêu chuẩn, với lưu lượng truy cập sử dụng cổng nổi tiếng 853 ( RFC 7858 phần 6 ). Giao thức DoT được thiết kế để giúp các tổ chức chặn lưu lượng truy cập trên một cổng dễ dàng hơn hoặc chấp nhận lưu lượng truy cập nhưng cho phép giải mã trên cổng đó.

Rủi ro liên quan đến DoT

Google đã triển khai DoT trong ứng dụng khách của mình Android 9 Pie trở lên , với cài đặt mặc định là tự động sử dụng DoT nếu có. Nếu bạn đã đánh giá rủi ro và sẵn sàng sử dụng DoT ở cấp tổ chức thì bạn cần yêu cầu quản trị viên mạng cho phép rõ ràng lưu lượng truy cập ra ngoài trên cổng 853 thông qua chu vi của họ đối với giao thức mới này.

Đảm bảo khả năng hiển thị và kiểm soát lưu lượng DoT

Là phương pháp tốt nhất để kiểm soát DoT, chúng tôi khuyên bạn nên áp dụng bất kỳ phương pháp nào ở trên, dựa trên yêu cầu của tổ chức bạn:

  • Định cấu hình NGFW để giải mã tất cả lưu lượng truy cập cho cổng đích 853. Bằng cách giải mã lưu lượng, DoT sẽ xuất hiện dưới dạng ứng dụng DNS mà bạn có thể áp dụng bất kỳ hành động nào, chẳng hạn như bật đăng ký Bảo mật DNS của Mạng Palo Alto để kiểm soát các miền DGA hoặc một miền hiện có Lỗ chìm DNS và chống phần mềm gián điệp.

  • Một giải pháp thay thế là yêu cầu công cụ App-ID chặn hoàn toàn lưu lượng truy cập 'dns-over-tls' trên cổng 853. Điều này thường bị chặn theo mặc định, không cần thực hiện hành động nào (trừ khi bạn đặc biệt cho phép lưu lượng truy cập cổng hoặc ứng dụng 'dns-over-tls' 853).

Nguồn: www.habr.com

Thêm một lời nhận xét