Những loại lỗ hổng bảo mật nào cung cấp DNSSEC lộ ra?


28

Tôi đã lên kế hoạch ký khu vực DNS của mình với DNSSEC. Khu vực của tôi, công ty đăng ký và máy chủ DNS của tôi (BIND9) đều hỗ trợ DNSSEC. Người duy nhất không hỗ trợ DNSSEC là nhà cung cấp máy chủ tên thứ cấp của tôi (cụ thể là Buddyns.com ).

Trên trang web của họ , họ nêu điều này liên quan đến DNSSEC:

BuddyNS không hỗ trợ DNSSEC vì nó phơi bày một số lỗ hổng không phù hợp với dịch vụ DNS có khối lượng lớn.

Chà, tôi nghĩ rằng việc sử dụng DNSSEC hiện đang bị nghi ngờ vì phần lớn người giải quyết không kiểm tra xem hồ sơ có được ký chính xác không. Điều mà tôi không biết là - theo tuyên bố của họ - có vẻ như việc cung cấp nó sẽ phơi bày một số lỗ hổng bảo mật.

Những "lỗ hổng" đó là gì?


8
tìm một nhà cung cấp DNS rõ ràng hơn - lý do của họ là giả mạo.
Alnitak

Câu trả lời:


103

DNSSEC có một số rủi ro, nhưng chúng không liên quan trực tiếp đến sự phản xạ hoặc khuếch đại. Việc mở rộng kích thước tin nhắn EDNS0 là một cá trích đỏ trong trường hợp này. Hãy để tôi giải thích.

Bất kỳ trao đổi gói nào không phụ thuộc vào bằng chứng nhận dạng trước đó đều bị lạm dụng bởi những kẻ tấn công DDoS, những người có thể sử dụng trao đổi gói không được xác thực đó làm bộ phản xạ và có lẽ là bộ khuếch đại. Ví dụ, ICMP (giao thức đằng sau "ping") có thể bị lạm dụng theo cách này. Có thể gói TCP SYN, có thể thu hút tới 40 gói SYN-ACK ngay cả khi SYN bị giả mạo đến từ một số nạn nhân không muốn các gói SYN-ACK đó. Và tất nhiên, tất cả các dịch vụ UDP đều dễ bị tấn công này, bao gồm NTP, SSDP, uPNP và như được lưu ý bởi các phản hồi khác ở đây, bao gồm cả DNS.

Hầu hết các thiết bị phát hiện xâm nhập, ngăn chặn xâm nhập và các thiết bị cân bằng tải đều bị nghẽn cổ chai, không thể theo kịp lưu lượng "tốc độ đường truyền". Ngoài ra, nhiều bộ định tuyến không thể chạy ở tốc độ đường truyền và một số thiết bị chuyển mạch. Những nút thắt này, bằng cách là thứ nhỏ nhất "trong đường dẫn" và nhỏ hơn chính các liên kết, là mục tiêu thực sự của các cuộc tấn công DDoS dựa trên tắc nghẽn. Nếu bạn có thể khiến tường lửa của ai đó bận rộn với lưu lượng tấn công, thì lưu lượng truy cập tốt sẽ không vượt qua được, ngay cả khi các liên kết không đầy đủ. Và những gì làm chậm tường lửa không phải là tổng số bit mỗi giây (có thể tăng lên bằng cách sử dụng các tin nhắn lớn hơn, và EDNS0 và DNSSEC sẽ làm), mà là tổng số gói mỗi giây.

Có rất nhiều truyền thuyết đô thị về cách DNSSEC làm cho DDoS trở nên tồi tệ hơn vì kích thước thư lớn hơn của DNSSEC, và trong khi điều này có ý nghĩa trực quan và "nghe có vẻ tốt", thì điều đó chỉ sai. Nhưng nếu có sự thật về truyền thuyết này, câu trả lời thực sự vẫn sẽ nằm ở chỗ khác-- [vì DNSSEC luôn sử dụng EDNS0, nhưng EDNS0 có thể được sử dụng mà không cần DNSSEC], và nhiều phản hồi phi DNSSEC bình thường lớn như một DNSSEC đáp ứng sẽ được. Xem xét các bản ghi TXT được sử dụng để thể hiện các chính sách SPF hoặc khóa DKIM. Hoặc chỉ bất kỳ bộ địa chỉ hoặc bản ghi MX lớn. Nói tóm lại, không có cuộc tấn công nào đòi hỏi DNSSEC, và do đó, bất kỳ sự tập trung nào vào DNSSEC vì rủi ro DDoS là năng lượng sai lầm.

DNSSEC không có rủi ro! Thật khó để sử dụng và khó sử dụng hơn. Thông thường, nó đòi hỏi một luồng công việc mới để thay đổi dữ liệu vùng, quản lý đăng ký, cài đặt các phiên bản máy chủ mới. Tất cả những điều đó phải được kiểm tra và ghi lại, và bất cứ khi nào có sự cố xảy ra liên quan đến DNS, công nghệ DNSSEC phải được điều tra là nguyên nhân có thể. Và kết quả cuối cùng nếu bạn làm mọi thứ đúng sẽ là, với tư cách là người ký khu vực, nội dung và hệ thống trực tuyến của bạn sẽ dễ vỡ hơn đối với khách hàng của bạn. Là một nhà điều hành máy chủ xa, kết quả sẽ là, nội dung và hệ thống của mọi người khác sẽ dễ vỡ hơn đối với bạn. Những rủi ro này thường được xem là vượt trội hơn các lợi ích, vì lợi ích duy nhất là bảo vệ dữ liệu DNS khỏi sự thay đổi hoặc thay thế trên chuyến bay. Cuộc tấn công đó rất hiếm khi không xứng đáng với tất cả nỗ lực này. Tất cả chúng ta đều hy vọng DNSSEC sẽ trở nên phổ biến vào một ngày nào đó, bởi vì các ứng dụng mới mà nó sẽ kích hoạt. Nhưng sự thật là ngày nay, DNSSEC là tất cả chi phí, không có lợi ích và có rủi ro cao.

Vì vậy, nếu bạn không muốn sử dụng DNSSEC, đó là đặc quyền của bạn, nhưng đừng để ai nhầm lẫn rằng vấn đề của DNSSEC là vai trò của bộ khuếch đại DDoS. DNSSEC không có vai trò cần thiết như bộ khuếch đại DDoS; có nhiều cách khác tốt hơn rẻ hơn để sử dụng DNS làm bộ khuếch đại DDoS. Nếu bạn không muốn sử dụng DNSSEC, hãy để nó là vì bạn chưa uống Kool Aid và bạn muốn trở thành người cuối cùng (sau này) không phải là người đầu tiên (bây giờ).

Các máy chủ nội dung DNS, đôi khi được gọi là "máy chủ có thẩm quyền", phải được ngăn chặn khỏi bị lạm dụng làm bộ khuếch đại phản xạ DNS, vì DNS sử dụng UDP và vì UDP có thể bị lạm dụng bởi các gói nguồn giả mạo. Cách để bảo mật máy chủ nội dung DNS của bạn chống lại loại lạm dụng này là không chặn UDP, cũng không bắt buộc TCP (sử dụng thủ thuật TC = 1), cũng không chặn truy vấn BẤT K ,, cũng không chọn từ chối DNSSEC. Không ai trong số những điều đó sẽ giúp bạn. Bạn cần giới hạn tỷ lệ phản hồi DNS(DNS RRL), một công nghệ hoàn toàn miễn phí hiện có trong một số máy chủ tên nguồn mở bao gồm BIND, Knot và NSD. Bạn không thể khắc phục sự cố phản xạ DNS với tường lửa của mình, vì chỉ có hộp trung gian nhận biết nội dung như máy chủ DNS (có thêm RRL) biết đủ về yêu cầu để có thể đoán chính xác cuộc tấn công và điều gì không. Tôi muốn nhấn mạnh một lần nữa: DNS RRL là miễn phí và mọi máy chủ có thẩm quyền nên chạy nó.

Cuối cùng, tôi muốn phơi bày những thành kiến ​​của mình. Tôi đã viết hầu hết BIND8, tôi đã phát minh ra EDNS0 và tôi đồng phát minh ra DNS RRL. Tôi đã làm việc trên DNS từ năm 1988 với tư cách là một thứ gì đó và bây giờ tôi đã cằn nhằn 50 cái gì đó, với sự ít kiên nhẫn hơn đối với các giải pháp nửa vời đối với các vấn đề bị hiểu lầm. Hãy chấp nhận lời xin lỗi của tôi nếu tin nhắn này nghe có vẻ giống như "hey các bạn, hãy ra khỏi bãi cỏ của tôi!"


7
Xác nhận rằng đây là Real Paul ™.
Andrew B

1
@AndrewB không thể là Real Paul ™, có chữ in hoa trong bài viết của anh ấy! ;-)
Alnitak

6
@kasperd xem "nháp-ietf-dnsop-cookies", hiện đang tiến triển thông qua IETF.
Alnitak

4
kasperd: [Máy ​​chủ DNS không giới hạn tốc độ sẽ trở thành mục tiêu dễ dàng hơn cho các cuộc tấn công DDoS.] Tôi biết tôi là một thằng ngốc, nhưng tôi không phải là thằng ngốc đó. dns rrl làm cho bạn kém an toàn không có cách nào. nó không phải là một sự bảo vệ chống lại tất cả các cuộc tấn công đã biết, nhưng nó là người tạo ra không có cuộc tấn công mới nào.
Paul Vixie

2
@kasperd cơ sở được cài đặt luôn là một vấn đề - không có giải pháp nào hoạt động ngay cả trên cơ sở được cài đặt tuân thủ, chứ đừng nói đến các hệ thống không tuân thủ ngoài kia. Tin vui là hỗ trợ cookie EDNS đã có trong cơ sở mã cho BIND 9.11 và (AIUI) sẽ được bật theo mặc định.
Alnitak

7

Tôi biết hai lỗ hổng cụ thể. Có sự phản xạ / khuếch đại được đề cập bởi Håkan. Và có khả năng liệt kê vùng.

Phản xạ / khuếch đại

Phản ánh có nghĩa là các cuộc tấn công trong đó các yêu cầu có IP nguồn giả mạo được gửi đến máy chủ DNS. Máy chủ bị giả mạo là nạn nhân chính của vụ tấn công. Máy chủ DNS sẽ vô tình gửi trả lời đến một máy chủ không bao giờ yêu cầu nó.

Khuếch đại đề cập đến bất kỳ cuộc tấn công phản chiếu nào trong đó phản hồi được phản ánh bao gồm nhiều byte hoặc nhiều gói hơn so với yêu cầu ban đầu. Trước khi khuếch đại DNSSEC + EDNS0 theo cách này sẽ chỉ cho phép gửi tối đa 512 byte. Với DNSSEC + EDNS0, có thể gửi 4096 byte, thường kéo dài 3-4 gói.

Có thể giảm nhẹ cho các cuộc tấn công này, nhưng tôi không biết bất kỳ máy chủ DNS nào thực hiện chúng.

Khi IP máy khách chưa được xác nhận, máy chủ DNS có thể gửi phản hồi cắt ngắn để buộc máy khách chuyển sang TCP. Phản hồi cắt ngắn có thể ngắn như yêu cầu (hoặc ngắn hơn nếu máy khách sử dụng EDNS0 và phản hồi không) giúp loại bỏ khuếch đại.

Bất kỳ IP khách nào hoàn thành bắt tay TCP và gửi yêu cầu DNS trên kết nối đều có thể tạm thời được đưa vào danh sách trắng. Sau khi đưa vào danh sách trắng, IP sẽ gửi các truy vấn UDP và nhận phản hồi UDP lên tới 512 byte (4096 byte nếu sử dụng EDNS0). Nếu phản hồi UDP kích hoạt thông báo lỗi ICMP, IP sẽ bị xóa khỏi danh sách trắng một lần nữa.

Phương thức này cũng có thể được đảo ngược bằng cách sử dụng danh sách đen, điều đó chỉ có nghĩa là IP của máy khách được phép truy vấn trên UDP theo mặc định nhưng bất kỳ thông báo lỗi ICMP nào cũng khiến IP bị liệt vào danh sách đen cần truy vấn TCP để thoát khỏi danh sách đen.

Một bitmap bao gồm tất cả các địa chỉ IPv4 có liên quan có thể được lưu trữ trong bộ nhớ 444 MB. Địa chỉ IPv6 sẽ phải được lưu trữ theo một cách khác.

Bảng liệt kê khu vực

Việc liệt kê vùng là một lỗ hổng ở nơi đầu tiên là chủ đề tranh luận. Nhưng nếu bạn không muốn tất cả các tên trong khu vực của bạn là kiến ​​thức công khai, bạn có thể coi đó là một lỗ hổng. Việc liệt kê vùng chủ yếu có thể được giảm nhẹ thông qua việc sử dụng các hồ sơ NSEC3.

Vấn đề vẫn tồn tại ngay cả khi sử dụng NSEC3 là kẻ tấn công có thể tìm thấy hàm băm của mỗi nhãn bằng cách truy vấn các tên ngẫu nhiên. Một khi kẻ tấn công có tất cả các băm, một cuộc tấn công vũ phu ngoại tuyến có thể được thực hiện trên các băm đó.

Một phòng thủ thích hợp chống lại việc liệt kê vùng sẽ yêu cầu kẻ tấn công thực hiện truy vấn đến máy chủ có thẩm quyền cho mỗi lần đoán. Tuy nhiên, không có sự bảo vệ như vậy tồn tại trong DNSSEC.


2
Việc liệt kê vùng dường như không phải là mối quan tâm đối với nhà cung cấp dịch vụ? (Thay vào đó là mối quan tâm có thể có đối với "chủ sở hữu" của khu vực, tùy thuộc vào quan điểm và sở thích của họ.)
Håkan Lindqvist

@ HåkanLindqvist Đúng vậy. Có lẽ câu hỏi của tôi cụ thể hơn tôi muốn nó được. Tôi đã tìm thấy thông tin này rất thú vị.
Johann Bauer

Ý tưởng về danh sách trắng một khách hàng đã thử TCP đã được xem xét, nhưng rõ ràng đã được cấp bằng sáng chế.
Alnitak

4

Điều xuất hiện trong tâm trí không thực sự là DNSSEC cụ thể mà là về phần mở rộng EDNS0, mà DNSSEC dựa vào.

EDNS0 cho phép tải trọng UDP lớn hơn và tải trọng UDP lớn hơn có thể cho phép các cuộc tấn công khuếch đại / phản xạ giao thông tồi tệ hơn.


Tôi không biết tỷ lệ phần trăm của trình phân giải xác thực là bao nhiêu nhưng phần mềm máy chủ tên phổ biến dường như được cung cấp với xác thực theo mặc định và người ta sẽ dễ dàng tìm thấy một số nhà cung cấp dịch vụ đáng chú ý mở về việc họ thực hiện xác thực, như Comcast và trình phân giải công khai của Google.

Dựa trên điều này, tôi sẽ nghĩ rằng tỷ lệ phần trăm của các trình phân giải hợp lệ có thể ở dạng tốt hơn đáng kể so với tỷ lệ phần trăm của các vùng đã ký.


Vâng, tôi đã nghĩ rằng thịt bò cũng có thể thực sự với EDNS. Mặc dù vậy, thật kỳ lạ khi chọn xương bằng DNSSEC thay vì điều đó.
Andrew B
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.