Điểm:0

Trình giải quyết DNS và lọc cổng yêu cầu

lá cờ gd

Trong các cuộc tấn công khuếch đại DNS trên máy chủ DNS, tôi đã quan sát thấy rằng một số yêu cầu DNS dành cho vài IP/cổng giống như 104.49.96.196:80. Tôi hiểu đây là IP giả mạo, nhưng bạn có thể cân nhắc việc lọc cổng của yêu cầu DNS không? Tôi tin rằng chúng ta không nên mong đợi một cổng> 1023. Đó có phải là một giả định an toàn không? Trong trường hợp đó, tôi tin rằng đây là một chiến thắng dễ dàng để phát hiện và không đáp lại cuộc tấn công khuếch đại DNS (nếu gói đến máy chủ DNS và không bị WAF loại bỏ).

Điểm:1
lá cờ cn

Không, nó không phải là một giả định an toàn.Đừng cố lọc trên các cổng, điều này sẽ không mang lại kết quả hữu ích. Cách máy khách xử lý các cổng cục bộ của nó, đó là công việc kinh doanh của chính nó và do đó, với tư cách là một máy chủ, bạn có thể mong đợi nhận được lưu lượng truy cập từ tất cả các cổng. Sự phân chia Unix tại 1024 là một di sản cổ xưa của quá khứ, về cơ bản ngày nay không còn ý nghĩa gì nữa.

Nếu bạn muốn chống khuếch đại DNS, bên cạnh các biện pháp "tiêu chuẩn" (như đảm bảo rằng bạn thực sự cần xử lý tất cả lưu lượng truy cập mà bạn nhận được, nghĩa là bạn không mở rộng), một trong những cách thường được sử dụng nhất hiện nay là RRL hoặc về cơ bản giới hạn tỷ lệ.

Nhìn vào https://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/ để giới thiệu về chủ đề này và tại https://www.isc.org/docs/DNS-RRL-LISA14.pdf để trình bày kỹ thuật hơn.

lá cờ in
Bạn có tham chiếu đến bất kỳ RFC nào đưa ra tuyên bố trong RFC6056 "một di sản cổ xưa của quá khứ không còn ý nghĩa gì về cơ bản ngày nay" không?
Michael Hampton avatar
lá cờ cz
Chẳng hạn, "di sản cổ xưa của quá khứ" đã được hệ thống hóa rõ ràng trong RFC 6335.
Patrick Mevzek avatar
lá cờ cn
@NiKiZe Không có gì trong RFC bắt buộc bất cứ điều gì. Câu là "Tuy nhiên, các thuật toán lựa chọn cổng phù du nên sử dụng toàn bộ phạm vi 1024-65535." Lưu ý rằng "nên" chứ không phải "NÊN" (hoặc thậm chí "PHẢI") tạo ra sự khác biệt LỚN trong thế giới IETF, xem RFC2119 để biết giải thích về điều đó.
Patrick Mevzek avatar
lá cờ cn
@MichaelHampton Không bắt buộc, xem bình luận ở trên. Đó là một trường hợp nhỏ "nên". Đó không phải là một đặc điểm kỹ thuật IETF bắt buộc bất cứ điều gì, chỉ là một thông lệ tốt nhất hiện tại về những gì xảy ra ngày nay.
Patrick Mevzek avatar
lá cờ cn
Và cổng nguồn ngày nay không còn ý nghĩa gì nữa. Trước đây, các lệnh "r" (rlogin, rtelnet, v.v.) chỉ dựa trên xác thực của chúng, tin rằng nếu cổng nguồn thấp hơn 1024 thì cổng đó là "đặc quyền" và do đó không sao. Điều này đã được chứng minh là thiết kế sai, do đó ngày nay không còn ai làm điều đó nữa, không có gì bảo mật khôn ngoan có thể được lấy chỉ từ cổng nguồn được sử dụng.
Michael Hampton avatar
lá cờ cz
@PatrickMevzek IANA rõ ràng không thấy như vậy.
Patrick Mevzek avatar
lá cờ cn
@MichaelHampton IANA không phải là người quyết định cổng **nguồn** nào mà hệ điều hành sử dụng. Điều này rõ ràng là khác với các cổng đích. Chuyển nhượng (những gì IANA giải quyết) chỉ là một cơ chế đồng bộ hóa cho các mục tiêu. Và điều này cũng đã cũ, nếu mọi ứng dụng đều sử dụng bản ghi `SRV`, thì chúng tôi thậm chí sẽ không phải đăng ký số cổng vì bất kỳ số nào trong số chúng sẽ hỗ trợ bất kỳ giao thức nào.
lá cờ in
Bạn nói đúng, không có gì ngăn cản
Patrick Mevzek avatar
lá cờ cn
@NiKiZe "Bạn nói đúng, không có gì ngăn cản
lá cờ in
Tôi muốn nói đó là thống kê, nhưng sẽ thu thập dữ liệu, cảm ơn. Cho đến nay không có mối liên hệ hoặc tài liệu nào đi ngược lại điều đó, sẽ rất vui khi tìm hiểu về bất kỳ trường hợp nào thực sự làm như vậy.
Patrick Mevzek avatar
lá cờ cn
@NiKiZe (và @MichaelHampton) có thể không rõ ràng, nhưng về lý thuyết thì tôi đồng ý với bạn. Quan điểm của tôi là tôi muốn truyền đạt tới OP rằng việc chống lại các sự cố khuếch đại DNS/DDOS không nên dựa vào việc lọc các cổng nguồn, vì điều đó sẽ dễ bị tổn thương và hạn chế.
Điểm:1
lá cờ in

Máy khách DNS phải có cổng nguồn > 1023.

Nếu nó < 1024 thì nó chỉ nên là cổng nguồn 53 nếu nó đến từ một số máy chủ DNS khác - nhưng điều đó khó xảy ra.

xác minh với cổng tcpdump 53

Bằng cách nhìn vào RFC6056đơn giản hóa với một số mẫu chúng tôi có thể đi xa hơn và nói rằng bất kỳ ngăn xếp IP hoạt động tốt nào cũng không được có (có) cổng nguồn thấp hơn 49152 (cổng tạm thời đầu tiên). Tuy nhiên, phần 3.2 mâu thuẫn với điều này và các mẫu cũng vậy.

Nhưng cho đến khi bất kỳ ai có thể cung cấp tham chiếu đến RFC xác định lại RFC6056, thì có thể nói rằng môn thể thao <= 1023 là không hợp lệ.

Nếu vì lý do nào đó mà yêu cầu không thành công, khách hàng nên thử lại và hy vọng nhận được yêu cầu thành công. (Ngay cả khi điều này không thành công, tôi sẽ bỏ qua những triển khai đó)

vinz avatar
lá cờ gd
Tôi hoàn toàn đồng ý với bạn. Mối quan tâm của tôi nhiều hơn về việc triển khai bộ lọc đó trên cổng? nó có thể có một nhược điểm tôi bỏ lỡ? Có bất kỳ trình phân giải DNS nổi tiếng nào (tôi không tìm thấy bất kỳ thông tin nào về điều đó) thực hiện bộ lọc này không?
lá cờ in
Theo quy định, không có gì nên có cổng nguồn
Patrick Mevzek avatar
lá cờ cn
"Theo quy định, không có gì nên có cổng nguồn
lá cờ in
Đã thêm tham chiếu đến RFC.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.