Đây là Câu hỏi Canonical về bảo mật trình phân giải DNS công cộng

Các máy chủ DNS mở có vẻ khá gọn gàng và tiện lợi, vì chúng cung cấp các địa chỉ IP mà chúng tôi có thể sử dụng một cách nhất quán trên toàn công ty của chúng tôi bất kể chúng nằm ở đâu. Google và OpenDNS cung cấp chức năng này, nhưng tôi không chắc rằng tôi muốn các công ty này có quyền truy cập vào các truy vấn DNS của chúng tôi.

Tôi muốn thiết lập một cái gì đó như thế này để sử dụng bởi công ty chúng tôi, nhưng tôi nghe nhiều về việc đây là hành vi nguy hiểm (đặc biệt là liên quan đến các cuộc tấn công khuếch đại ) và tôi muốn chắc chắn rằng chúng tôi làm đúng. Những điều tôi cần lưu ý khi xây dựng loại môi trường này?

Có một vài điều bạn cần hiểu đi sâu vào vấn đề này:

Đây là một vấn đề kỹ thuật mạng.

Hầu hết những người đang tìm cách thiết lập loại môi trường này là quản trị viên hệ thống. Thật tuyệt, tôi cũng là một quản trị viên hệ thống! Một phần của công việc là hiểu được trách nhiệm của bạn kết thúc ở đâu và người khác bắt đầu, và tin tôi đi, đây không phải là vấn đề mà các quản trị viên hệ thống có thể tự giải quyết. Đây là lý do tại sao:

• UDP là một giao thức phi trạng thái. Không có bắt tay khách hàng.
• Các truy vấn đối với máy chủ DNS là một giao dịch hai bước chưa được xác thực (truy vấn, trả lời). Không có cách nào để máy chủ biết liệu IP nguồn có bị giả mạo hay không trước khi trả lời.
• Vào thời điểm một truy vấn đã đến máy chủ, đã quá muộn để ngăn chặn gói UDP giả mạo. Việc giả mạo chỉ có thể được ngăn chặn bằng cách thực hành được gọi là lọc xâm nhập , một chủ đề được đề cập trong các tài liệu BCP 38 và BCP 84 . Chúng được thực hiện bởi các thiết bị mạng ngồi trước máy chủ DNS của bạn.
• Chúng tôi không thể cung cấp cho bạn hướng dẫn về cách thiết lập trung tâm dữ liệu của bạn từ đầu đến cuối hoặc cách triển khai các thực tiễn tốt nhất này. Những điều này rất cụ thể cho nhu cầu của riêng bạn. Định dạng Q & A không hoạt động cho việc này và trang web này không nhằm thay thế việc thuê người chuyên nghiệp để làm công việc chuyên nghiệp.
• Đừng cho rằng công ty tỷ đô quá lớn của bạn thất bại trong việc thực hiện lọc chính xác.

Đây không phải là một thực hành tốt nhất. Thực hành tốt nhất là không làm điều này.

Rất dễ dàng để thiết lập trình phân giải DNS đối mặt với internet. Phải mất ít nghiên cứu để thiết lập một hơn là để hiểu những rủi ro liên quan đến việc đó. Đây là một trong những trường hợp mà ý định tốt vô tình kích hoạt những hành vi sai trái (và đau khổ) của người khác.

• Nếu máy chủ DNS của bạn sẽ phản hồi bất kỳ địa chỉ IP nguồn nào mà nó nhìn thấy, bạn đang chạy một bộ giải quyết mở. Chúng liên tục được tận dụng trong các cuộc tấn công khuếch đại chống lại các bên vô tội. Các quản trị viên hệ thống mới đang đứng lên giải quyết mở mỗi ngày , làm cho nó trở nên sinh lợi cho các cá nhân độc hại để quét chúng liên tục. Thực sự không có câu hỏi nào về việc liệu trình giải quyết mở của bạn có được sử dụng trong một cuộc tấn công hay không: kể từ năm 2015, nó đã được đưa ra khá nhiều. Nó có thể không phải là ngay lập tức, nhưng nó sẽ xảy ra chắc chắn.
• Ngay cả khi bạn áp dụng ACL bằng phần mềm DNS (ví dụ BIND), tất cả những điều này là giới hạn các gói DNS giả mạo mà máy chủ của bạn sẽ trả lời. Điều quan trọng là phải hiểu rằng cơ sở hạ tầng DNS của bạn không chỉ được sử dụng để tấn công các thiết bị trong ACL, mà bất kỳ thiết bị mạng nào giữa máy chủ DNS của bạn và các thiết bị mà nó sẽ phản hồi. Nếu bạn không sở hữu trung tâm dữ liệu, đó không chỉ là vấn đề với bạn.

Google và OpenDNS làm điều này, vậy tại sao tôi không thể?

Đôi khi cần phải cân nhắc nhiệt tình với thực tế. Dưới đây là một số câu hỏi khó để tự hỏi:

• Đây có phải là thứ bạn muốn thiết lập theo ý thích, hay đây là thứ bạn có vài triệu đô la để đầu tư để làm đúng?

• Bạn có một đội bảo mật chuyên dụng? Đội lạm dụng chuyên dụng? Cả hai đều có chu kỳ để đối phó với việc lạm dụng cơ sở hạ tầng mới của bạn và những khiếu nại mà bạn sẽ nhận được từ các bên ngoài?

• Bạn có một đội ngũ pháp lý ?

• Khi tất cả những điều này được nói và thực hiện, liệu tất cả những nỗ lực này thậm chí sẽ bắt đầu tự trả tiền từ xa, mang lại lợi nhuận cho công ty hay vượt quá giá trị tiền tệ để xử lý sự bất tiện dẫn bạn theo hướng này?

Cuối cùng, tôi biết chủ đề này là Q & A là một sự thất vọng đối với hầu hết các bạn đang được liên kết với nó. Serverfault ở đây để cung cấp câu trả lời và câu trả lời "đây là một ý tưởng tồi, đừng làm điều đó" thường không được coi là rất hữu ích. Một số vấn đề phức tạp hơn nhiều so với lúc ban đầu, và đây là một trong số đó.

Nếu bạn muốn thử làm cho công việc này, bạn vẫn có thể yêu cầu chúng tôi giúp đỡ khi bạn cố gắng thực hiện loại giải pháp này. Điều chính để nhận ra là vấn đề quá lớn đối với câu trả lời được cung cấp ở định dạng Hỏi và Đáp thuận tiện. Bạn cần đầu tư một lượng thời gian đáng kể để nghiên cứu chủ đề này và tiếp cận chúng tôi với các vấn đề logic cụ thể mà bạn gặp phải trong quá trình thực hiện. Mục đích của câu hỏi và trả lời này là để bạn hiểu rõ hơn về bức tranh lớn hơn và giúp bạn hiểu lý do tại sao chúng ta không thể trả lời một câu hỏi rộng như câu hỏi này.

Hãy giúp chúng tôi giữ cho internet an toàn! :)

Cho dù bạn đang chạy một người truy cập DNS mở hoặc máy chủ DNS có thẩm quyền, vấn đề là như nhau và hầu hết các giải pháp có thể cũng giống nhau.

Giải pháp tốt nhất

Cookie DNS là một tiêu chuẩn được đề xuất cung cấp cho các máy chủ DNS một cách để yêu cầu khách hàng gửi cookie để chứng minh rằng địa chỉ IP của máy khách không bị giả mạo. Điều này sẽ tốn thêm một vòng cho lần tra cứu đầu tiên, đây là chi phí thấp nhất mà bất kỳ giải pháp nào có thể cung cấp.

Dự phòng cho khách hàng lớn tuổi

Vì cookie DNS chưa được chuẩn hóa nên tất nhiên sẽ cần thiết để hỗ trợ các khách hàng cũ bây giờ và trong nhiều năm tới.

Bạn có thể xếp hạng yêu cầu giới hạn từ khách hàng mà không cần hỗ trợ cookie DNS. Nhưng giới hạn tốc độ giúp kẻ tấn công DoS máy chủ DNS của bạn dễ dàng hơn. Xin lưu ý rằng một số máy chủ DNS có tính năng giới hạn tốc độ chỉ được thiết kế cho các máy chủ DNS có thẩm quyền. Vì bạn đang hỏi về một trình giải quyết đệ quy, nên việc triển khai giới hạn tỷ lệ như vậy có thể không áp dụng cho bạn. Giới hạn tốc độ theo thiết kế sẽ trở thành nút cổ chai cho máy chủ của bạn và do đó, kẻ tấn công sẽ cần gửi cho bạn ít lưu lượng truy cập hơn để khiến các yêu cầu hợp pháp bị hủy bỏ nếu không có giới hạn tốc độ.

Một lợi thế của giới hạn tốc độ là trong trường hợp kẻ tấn công làm ngập máy chủ DNS của bạn với các yêu cầu DNS, bạn có nhiều khả năng còn dư sẽ cho phép bạn ssh đến máy chủ và điều tra tình huống. Ngoài ra, giới hạn tốc độ có thể được thiết kế để chủ yếu loại bỏ các yêu cầu từ các IP của khách hàng gửi nhiều yêu cầu, có thể đủ để bảo vệ bạn khỏi DoS khỏi những kẻ tấn công không có quyền truy cập vào IP của khách hàng giả mạo.

Vì những lý do đó, giới hạn tốc độ một chút dưới khả năng thực tế của bạn có thể là một ý tưởng tốt, ngay cả khi nó không thực sự bảo vệ chống lại sự khuếch đại.

Sử dụng TCP

Có thể buộc khách hàng sử dụng TCP bằng cách gửi mã lỗi cho biết câu trả lời quá lớn đối với UDP. Điều này có một vài nhược điểm. Nó có giá hai vòng tròn bổ sung. Và một số khách hàng bị lỗi không hỗ trợ nó.

Chi phí của hai vòng tròn bổ sung có thể được giới hạn chỉ cho yêu cầu đầu tiên sử dụng phương pháp này:

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 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.

Tôi không biết có máy chủ DNS nào đã thực hiện phương pháp này không.

Nó cũng đã được báo cáo rằng một số ngăn xếp TCP có thể được khai thác trong các cuộc tấn công khuếch đại. Tuy nhiên, điều đó áp dụng cho bất kỳ dịch vụ dựa trên TCP nào và không chỉ DNS. Các lỗ hổng như vậy nên được giảm thiểu bằng cách nâng cấp lên phiên bản kernel, nơi ngăn xếp TCP đã được sửa để không gửi nhiều hơn một gói để đáp ứng với gói SYN.