Tấn công phản xạ khuếch đại trên các máy chủ DNS


11

Thuật ngữ Amplified reflected attacknày là mới đối với tôi, và tôi có một vài câu hỏi về nó.

Tôi đã nghe nói điều đó chủ yếu xảy ra với các máy chủ DNS - điều đó có đúng không?
Làm thế nào để bạn bảo vệ chống lại nó?
Làm thế nào để bạn biết nếu máy chủ của bạn có thể được sử dụng trong một cuộc tấn công như vậy - Đây có phải là một vấn đề cấu hình?

Câu trả lời:


22

Đầu tiên, kiểu tấn công này không (chủ yếu) nhắm mục tiêu DNS như tiêu đề của bạn đề xuất. Tất nhiên nó sẽ tạo ra một số tải bổ sung trên các máy chủ DNS nhưng mục đích chính là để DDoS người khác. Cấu hình máy chủ xấu có thể làm cho nó tồi tệ hơn nhưng cuối cùng, vấn đề này là cố hữu trong thiết kế DNS và UDP và trên thực tế, bất kỳ giao thức truyền thông không trạng thái nào.

Về cơ bản nó hoạt động như thế này: Kẻ tấn công gửi các truy vấn (DNS) thông thường đến máy chủ (DNS). Các truy vấn đó được giả mạo để xuất hiện như thể chúng có nguồn gốc từ hệ thống mục tiêu. Máy chủ DNS hiện trả lời truy vấn, gửi câu trả lời về nguồn gốc bị cáo buộc của nó - nạn nhân. Đây là lý do tại sao nó được gọi là tấn công phản chiếu .

Điều này là có thể bởi vì bạn có thể xác minh nguồn liên lạc không trạng thái (như DNS qua UDP) tốt như bạn có thể tin tưởng địa chỉ người gửi trên bưu thiếp. Máy chủ không có cách nào để quyết định xem một truy vấn là hợp pháp hay là một phần của cuộc tấn công như vậy. DNS chỉ là giao thức phổ biến nhất ở đây vì có rất nhiều máy chủ cho nó và bạn không cần nhiều kiến ​​thức kỹ thuật hoặc thiết bị đặc biệt để sử dụng nó.

Để làm cho mọi thứ tồi tệ hơn (và hoàn toàn có hiệu quả tấn công), hãy nhìn vào phần khuếch đại . Sẽ không có hại gì nhiều nếu lưu lượng của kẻ tấn công có kích thước tương đương với lưu lượng kết quả. Lợi ích duy nhất cho kẻ tấn công là địa chỉ của anh ta bị ẩn đằng sau máy chủ DNS. Anh ta có thể giả mạo địa chỉ người gửi trực tiếp, hoàn toàn không cần phải định tuyến lại qua DNS. Nhưng DNS câu trả lời, và đó là một điểm lý do tại sao DNS là rất phổ biến ở đây, có thể là rất nhiều lớn hơn câu hỏi. Bạn có thể tìm thấy các số khác nhau trên số này tùy thuộc vào các truy vấn chính xác được sử dụng, nhưng nó có thể lên tới 1:60 nếu máy chủ đủ thân thiện để thực hiện các truy vấn đệ quycho bạn. Vì vậy, kẻ tấn công không cần nhiều máy móc dưới sự kiểm soát của mình để tạo ra nhiều lưu lượng độc hại.

Vì bạn có thể dễ dàng tìm thấy hàng trăm và hàng ngàn máy chủ DNS "mở" trên internet công cộng, bạn có thể thực hiện phép toán nhanh chóng về việc kẻ tấn công phải làm gì nếu mỗi máy chủ DNS mở mà anh ta biết sẽ phản ánh các truy vấn của anh ta được khuếch đại sáu mươi lần đến mục tiêu. Như tôi đã nói lúc đầu, không có cách nào thực sự tốt để đối phó với điều này. Đương nhiên, nhiều máy chủ DNS được mở cho tất cả mọi người trong khi họ không nên, do cấu hình sai. Nhưng có nhiều máy chủ mở phải được mở, vì đó chính xác là mục đích của chúng.

Mặc dù bạn không thể biết liệu yêu cầu có phải là một phần của cuộc tấn công hay không, tùy chọn duy nhất của bạn là không chạy máy chủ nữa. Bạn có thể nghịch ngợm với giới hạn tỷ lệ và các đồ chơi khác nhưng bạn không thể loại bỏ hoàn toàn điều này. Nếu bạn đang cung cấp DNS cho vui, bạn có thể đưa vào danh sách đen IP nguồn của các yêu cầu. Nhưng nếu bạn ở quy mô lớn hơn, điều này sẽ gây thiệt hại cho nạn nhân nhiều hơn. Hãy nhớ rằng, tất cả những gì bạn có thể thấy trên máy chủ DNS là địa chỉ của nạn nhân. Hãy tưởng tượng công ty của bạn đang bị tấn công thông qua DNS của nhà cung cấp của bạn và nhà cung cấp của bạn quyết định cắt dịch vụ DNS cho công ty của bạn. Kẻ tấn công có thể ghi điểm này như một điểm thưởng trị giá hàng tỷ đồng liên quan đến việc từ chối dịch vụ .

Nhưng dù sao, những cuộc tấn công đó xảy ra cả ngày lẫn đêm và chúng được coi là "tiếng ồn nền" của internet. Nếu bạn thiết lập máy chủ DNS công cộng (đệ quy), sẽ không mất nhiều thời gian trước khi bạn tham gia vào các cuộc tấn công ngẫu nhiên. Tất nhiên đôi khi mọi thứ trở nên tồi tệ khi cơ sở hạ tầng lớn (như ngay cả các máy chủ gốc dns) bị lạm dụng để khuếch đại nhưng trong những trường hợp đó, các biện pháp đối phó chủ động được thực hiện bởi personell cho đến khi cuộc tấn công xuống mức "bình thường".


Cho đến nay về việc giảng dạy. Để trả lời câu hỏi của bạn, cuối cùng:

Bạn biết máy chủ của bạn dễ bị tổn thương nếu nó trả lời các truy vấn mà không hạn chế. Giai đoạn = Stage. Nếu bạn đang phục vụ các truy vấn đệ quy, máy chủ của bạn có thể tạo tỷ lệ 1:60 được đề cập cho kẻ tấn công. Nếu nó chỉ phục vụ không đệ quy thì nó không tệ, nhưng vẫn ...

Vì thế...

  • đảm bảo rằng bạn thực sự cần chạy máy chủ DNS công cộng
  • nếu bạn phải, hãy xem BIND's allow-recursionallow-querychỉ thị
  • nếu máy chủ DNS của bạn sẽ có thẩm quyền cho vùng riêng của bạn , thì không cần đệ quy, hãy đặt allow-recursionthành "không;"
  • nếu bạn muốn chạy trình phân giải cho các miền khác , hãy hạn chế người dùng được phép cho truy vấn và truy vấn đệ quy. Bạn có thể xác định địa chỉ IP, mạng hoặc danh sách truy cập trong các chỉ thị được đề cập
  • nghĩ về tốc độ giới hạn lưu lượng DNS không chỉ ở BIND mà còn ở cấp hệ thống. Một ví dụ rất đơn giản, các quy tắc iptables này sẽ không cho phép quá 10 truy vấn mỗi phút từ mỗi địa chỉ IP:

.

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

Bây giờ, với những điểm này trong tâm trí bạn nên đi. Hiện tại vẫn có thể có lưu lượng truy cập độc hại trên máy chủ của bạn nhưng không phải là số tiền khiến bạn ngủ ngon.


3
Đây là một câu trả lời thực sự tốt. Cảm ơn đã dành thời gian để viết nó.
jamieb

1
@mikejanson serverfault.com/questions/450099 - hãy xem câu hỏi này để xem bạn có thể có những lựa chọn nào khác (đặc biệt là bản vá BIND của Vixie & Schryver )
the-wmus

RRL hiện là một tính năng tiêu chuẩn của liên kết và các máy chủ tên khác: kb.isc.org/article/AA-01000/189/ mẹo
Patrick Mevzek

Nói chung là sai khi có cùng một máy chủ có thẩm quyền và đệ quy. Thực hành tốt nhất khuyên nên chia nó thành hai quá trình riêng biệt.
Patrick Mevzek
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.