Máy chủ DNS đệ quy công khai - quy tắc iptables

Chúng tôi chạy các máy chủ DNS đệ quy đối diện công khai trên các máy Linux. Chúng tôi đã được sử dụng cho các cuộc tấn công khuếch đại DNS. Có bất kỳ iptablesquy tắc được đề nghị nào sẽ giúp giảm thiểu các cuộc tấn công này?

Giải pháp rõ ràng là chỉ giới hạn các gói DNS gửi đi ở một mức lưu lượng nhất định. Nhưng tôi đã hy vọng tìm thấy thứ gì đó thông minh hơn một chút để một cuộc tấn công chỉ chặn lưu lượng truy cập đến địa chỉ IP của nạn nhân.

Tôi đã tìm kiếm lời khuyên và đề xuất, nhưng tất cả đều có vẻ là "không chạy các máy chủ tên đệ quy đối mặt công khai". Thật không may, chúng ta bị rơi vào tình huống mà những thứ không dễ thay đổi sẽ bị phá vỡ nếu chúng ta không làm như vậy và điều này là do các quyết định được đưa ra hơn một thập kỷ trước khi các cuộc tấn công này là một vấn đề.

Toàn bộ những điều kỳ quặc của kịch bản "không phải vấn đề của tôi" không thực sự là lỗi của bạn và nên / có thể được giải quyết 100% bằng cách thực hiện hành động thích hợp, bất kể nó "khó" hay "khó" và điều đó chấm dứt mở máy chủ đệ quy .

Loại bỏ dần: thông báo cho khách hàng rằng máy chủ này sẽ biến mất kể từ ngày X. Sau thời gian đó, họ cần cài đặt một bản vá (giả sử bạn có) để ngăn không cho sử dụng máy chủ DNS của bạn. Điều này được thực hiện tất cả các thời gian. Sysadmin, quản trị viên mạng, người trợ giúp, lập trình viên? Chúng tôi nhận được nó; điều cuối cùng này xảy ra mọi lúc, bởi vì quy trình vận hành tiêu chuẩn của nó cho một nhà cung cấp / nhà cung cấp dịch vụ / đối tác để bảo chúng tôi ngừng sử dụng thứ gì đó sau ngày X. Chúng tôi không phải lúc nào cũng thích nó, nhưng đó là thực tế của cuộc sống trong CNTT.

Bạn nói rằng bạn không gặp phải vấn đề này trên các thiết bị hiện tại, vì vậy tôi cho rằng bạn đã giải quyết vấn đề này bằng bản cập nhật firmware hoặc bản vá. Tôi biết bạn nói rằng bạn không thể chạm vào thiết bị, nhưng chắc chắn họ có thể? Ý tôi là, nếu họ cho phép những chiếc hộp này về cơ bản gọi điện thoại cho bạn, họ thực sự không thể là người hậu môn về việc ai đang làm gì với thiết bị của họ; bạn có thể có một thiết lập proxy ngược cho tất cả những gì họ biết, vậy tại sao họ không cài đặt một bản vá sửa lỗi này hoặc bảo họ sử dụng máy chủ DNS của riêng họ . Chắc chắn thiết bị của bạn hỗ trợ DHCP; Tôi không thể nghĩ về một thiết bị mạng (không quan trọng bao nhiêu tuổi / yếu / lẻ) mà không .

Nếu bạn không thể làm điều đó, điều tiếp theo cần làm là kiểm soát ai có thể truy cập máy chủ đệ quy của bạn : bạn nói rằng "thật khó để nói" ai đang sử dụng nó và làm thế nào, nhưng đã đến lúc tìm hiểu và bắt đầu giảm lưu lượng không hợp pháp

Đây là những tổ chức "bán quân sự / chính phủ", phải không? Chà, họ có khả năng là một phần của một netblock hợp pháp mà họ sở hữu; những thiết bị này không phải là bộ định tuyến gia đình đằng sau IP động. Tìm ra. Liên hệ với họ, giải thích vấn đề và cách bạn tiết kiệm cho họ rất nhiều tiền bằng cách không buộc phần sụn hoặc thay thế sản phẩm nếu chỉ họ có thể xác nhận địa chỉ netblock / IP mà thiết bị sẽ sử dụng để truy cập máy chủ DNS của bạn.

Điều này được thực hiện mọi lúc: Tôi có một số khách hàng hạn chế quyền truy cập extranet hoặc người nghe HL7 cho các đối tác chăm sóc sức khỏe theo cách này; nó không khó lắmđể yêu cầu họ điền vào biểu mẫu và cung cấp IP và / hoặc netblock tôi nên mong đợi lưu lượng truy cập từ: nếu họ muốn truy cập vào extranet, họ phải cung cấp cho tôi IP hoặc mạng con. Và điều này hiếm khi là một mục tiêu di động, vì vậy, không giống như bạn sẽ bị ngập trong hàng trăm yêu cầu thay đổi IP mỗi ngày: mạng lưới bệnh viện trong khuôn viên lớn sở hữu các mạng lưới riêng của họ với hàng trăm mạng con và hàng ngàn và hàng ngàn IP máy chủ thường xuyên cung cấp cho tôi một số ít địa chỉ IP hoặc mạng con tôi nên mong đợi; một lần nữa, những người dùng máy tính xách tay này không phải đi lang thang khắp trường, vậy tại sao tôi lại mong đợi thấy các gói nguồn UDP từ một địa chỉ IP luôn thay đổi? Rõ ràng tôi đang đặt ra một giả định ở đây, nhưng tôi cá là nó không nhiều như bạn nghĩ cho <100 thiết bị. Vâng, nó sẽ là một ACL dài, và vâng,

Nếu vì một lý do nào đó, các kênh liên lạc không mở (hoặc ai đó quá sợ hoặc không thể bận tâm liên hệ với các chủ sở hữu thiết bị cũ này và thực hiện đúng cách), bạn cần thiết lập đường cơ sở của việc sử dụng / hoạt động bình thường để bạn có thể hình thành một số chiến lược khác sẽ giúp (nhưng không ngăn chặn) sự tham gia của bạn vào các cuộc tấn công khuếch đại DNS.

Một hoạt động lâu dài tcpdumpsẽ hoạt động lọc trên UDP 53 đến và ghi nhật ký chi tiết trên ứng dụng máy chủ DNS. Tôi cũng muốn bắt đầu thu thập thông tin địa chỉ IP / netblocks / GeoIP (tất cả khách hàng của bạn ở Mỹ? Chặn mọi thứ khác) bởi vì, như bạn nói, bạn không thêm bất kỳ thiết bị mới nào, bạn chỉ đang cung cấp một di sản dịch vụ cài đặt hiện có.

Điều này cũng sẽ giúp bạn hiểu loại bản ghi nào đang được yêu cầu và đối với tên miền nào, bởi ai và tần suất : để khuếch đại DNS hoạt động như dự định, kẻ tấn công cần có thể yêu cầu loại bản ghi lớn (1) cho miền hoạt động (2).

1. "loại bản ghi lớn": các thiết bị của bạn thậm chí có cần các bản ghi TXT hoặc SOA để có thể được giải quyết bởi máy chủ DNS đệ quy của bạn không? Bạn có thể chỉ định loại bản ghi nào hợp lệ trên máy chủ DNS của mình; Tôi tin rằng điều đó là có thể với BIND và có lẽ là Windows DNS, nhưng bạn phải thực hiện một số thao tác đào. Nếu máy chủ DNS của bạn phản hồi với SERVFAILbất kỳ bản ghi TXT hoặc SOA nào, và ít nhất phản hồi đó là một thứ tự cường độ (hoặc hai) nhỏ hơn tải trọng dự định. Rõ ràng bạn vẫn là "một phần của vấn đề" bởi vì nạn nhân bị giả mạo vẫn sẽ nhận được những SERVFAILphản hồi đó từ máy chủ của bạn, nhưng ít nhất bạn không làm phiền họ và có lẽ máy chủ DNS của bạn bị "hủy bỏ" khỏi danh sách bị thu hoạch các bot sử dụng theo thời gian để không "hợp tác".

2. "Miền hoạt động": bạn chỉ có thể liệt kê danh sách trắng các tên miền hợp lệ. Tôi thực hiện điều này trên các thiết lập trung tâm dữ liệu cứng của mình trong đó máy chủ chỉ cần Windows Update, Symantec, v.v. để hoạt động. Tuy nhiên, bạn chỉ đang giảm thiểu thiệt hại mà bạn gây ra vào thời điểm này: nạn nhân vẫn sẽ bị bắn phá NXDOMAINhoặc SERVFAILphản hồi từ máy chủ của bạn vì máy chủ của bạn vẫn phản hồi IP nguồn giả mạo. Một lần nữa, tập lệnh Bot cũng có thể tự động cập nhật danh sách máy chủ mở dựa trên kết quả, do đó, điều này có thể khiến máy chủ của bạn bị xóa.

Tôi cũng sẽ sử dụng một số hình thức giới hạn tỷ lệ, như những người khác đã đề xuất, ở cấp độ ứng dụng (nghĩa là kích thước tin nhắn, yêu cầu cho mỗi giới hạn khách hàng) hoặc mức tường lửa (xem các câu trả lời khác), nhưng một lần nữa, bạn sẽ phải thực hiện một số phân tích để đảm bảo bạn không giết chết lưu lượng truy cập hợp pháp.

Hệ thống phát hiện xâm nhập đã được điều chỉnh và / hoặc được đào tạo (một lần nữa, cần có đường cơ sở ở đây) sẽ có thể phát hiện lưu lượng truy cập bất thường theo thời gian theo nguồn hoặc âm lượng, nhưng có thể sẽ giữ trẻ / điều chỉnh / giám sát thường xuyên để ngăn ngừa dương tính giả và / hoặc xem nếu nó thực sự ngăn chặn các cuộc tấn công.

Vào cuối ngày, bạn phải tự hỏi liệu tất cả nỗ lực này có xứng đáng hay không, nếu bạn chỉ nên nhấn mạnh rằng điều đúng đắn đã được thực hiện và điều đó sẽ loại bỏ vấn đề ngay từ đầu.

Nó phụ thuộc vào loại tỷ lệ giới hạn bạn muốn làm.

Giới hạn tốc độ iptablesthực sự được dự định nhiều hơn cho việc giới hạn các gói đến, vì các gói đến giới hạn sẽ khớp với bộ lọc và áp dụng mục tiêu đã chỉ định (ví dụ ACCEPT:). Bạn có thể có một mục tiêu tiếp theo cho các DROPgói không khớp với bộ lọc. Và mặc dù iptablescó một QUEUEmục tiêu, nó chỉ chuyển gói đến không gian người dùng nơi bạn cần cung cấp ứng dụng xếp hàng của riêng mình. Bạn cũng có thể xếp hạng các gói gửi đi giới hạn, nhưng ít người thực sự muốn bắt đầu giảm lưu lượng đi.

iptables giới hạn tỷ lệ giảm:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

Sử dụng hashlimitthay vì limitsẽ cung cấp cho bạn giới hạn tỷ lệ trên mỗi IP đích. Tức là, năm gói đến 8.8.8.8 đạt đến giới hạn sẽ ngăn các gói được gửi đến 8.8.4.4 trong khi với mức hashlimittối đa là 8.8.8.8, bạn vẫn có thể đạt đến mức 8.8.4.4, nghe có vẻ giống như những gì bạn muốn.

Nếu bạn không muốn các gói vượt quá giới hạn bị bỏ thì điều bạn thực sự muốn là tc. tcsẽ điều chỉnh lưu lượng để có được một luồng ổn định tốt hơn là nhiều lưu lượng truy cập bùng nổ. Trên các gói bên đến được gửi đến ứng dụng chậm hơn nhưng tất cả sẽ đến theo thứ tự. Trên các gói gửi đi sẽ để lại ứng dụng của bạn nhanh nhất có thể nhưng được đặt trên dây trong một luồng nhất quán.

Tôi chưa sử dụng tcnhiều, nhưng đây là một ví dụ về giới hạn tốc độ ICMP mà bạn có thể dễ dàng điều chỉnh cho DNS.

Đây là một điều bạn có thể làm để giảm thiểu các câu trả lời cho các truy vấn giả mạo, nhưng phải mất một số công việc:

Trước tiên, hãy xem nhật ký của bạn về kênh bảo mật và tìm địa chỉ IP đang bị giả mạo.

Sau đó chạy một tcpdump bằng IP nguồn đó (10.11.12.13) như thế này:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

Bạn sẽ nhận được một cái gì đó như thế này:

18: 37: 25.969485 IP (to 0 0 ? . (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w ..
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

Bây giờ là phần thú vị! Mở rfc1035 tại http://tools.ietf.org/html/rfc1035 và chuyển sang phần 4.1.1.

Đã đến lúc dịch kết quả của tcpdump và tìm ra một mẫu chúng ta có thể sử dụng để tạo bộ lọc mức gói.

ID của tiêu đề bắt đầu ở 0x1C, vì vậy chúng tôi đã nhận được một số cờ ở 0x1E, QDCOUNT ở 0x20, ANCOUNT ở 0x22, NSCOUNT ở 0x24 và ARCOUNT ở 0x26.

Điều đó để lại câu hỏi thực tế ở 0x28, trong trường hợp này là null (ROOT) cho NAME, 0xFF cho QTYPE = ANY và 0x01 cho QCLASS = IN.

Để làm cho một câu chuyện dài trở nên ngắn gọn, tôi đã thấy rằng việc thêm các quy tắc iptables sau sẽ chặn hơn 95% các truy vấn giả mạo đang yêu cầu BẤT K records hồ sơ nào trong ROOT:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

Số dặm của bạn có thể thay đổi ... hy vọng điều này sẽ giúp.

Sử dụng tcvà xếp hàng các nguyên tắc trong linux cho cổng ra 53 UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

Sẽ thiết lập cho bạn discgiới hạn ở mức 10mbit cho bất kỳ gói tin nào có dấu tường lửa '1'. Đánh dấu tường lửa chỉ là nội bộ của tường lửa và không sửa đổi gói. Chỉ cần xử lý các gói theo kỷ luật xếp hàng. Đây là cách bạn sử dụng iptablesđể tạo các dấu hiệu tường lửa:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

Sửa đổi theo ý thích của bạn để loại trừ các mạng con và / hoặc đích đáng tin cậy. Các -o eth0giới hạn định hình chỉ các gói đi. Hi vọng điêu nay co ich.

Tôi sẽ cố gắng lập một danh sách tất cả các khách hàng dựa trên các bộ giải quyết đệ quy đối diện bên ngoài của bạn. Bắt đầu với một ngày hoặc lâu hơn các dấu vết gói trên các hộp DNS. Từ đó, bắt đầu tạo quy tắc iptables để cho phép lưu lượng truy cập mà bạn nhận ra và ủy quyền. Mặc định cuối cùng sẽ là giảm lưu lượng xuống 53 / tcp và 53 / udp. Nếu điều đó phá vỡ một cái gì đó, tinh chỉnh các quy tắc của bạn.

tùy thuộc vào 'vị trí' của mạng bạn [có nhiều nguồn cấp dữ liệu bgp hoặc ở cuối 'mạng' - như một mạng sơ khai], bạn có thể thử một cái gì đó như uRPF để ngăn chặn giả mạo địa chỉ nguồn.

khác nguồn gốc của thông tin.

Các thiết bị này vẫn còn theo hợp đồng hỗ trợ? Nếu vậy, tiếp cận với khách hàng của bạn. Hãy cho họ biết rằng internet đã phát triển một chút trong thập kỷ qua và để tiếp tục cung cấp độ phân giải tên cho các thiết bị này, bạn sẽ cần biết IP SRC để mong đợi các truy vấn. Đặt ngày ~ 6 tháng trong tương lai tại thời điểm đó bạn sẽ không còn có thể phục vụ các khách hàng không xác định và gắn bó với nó. Đây là một khá phổ biến trong ngành công nghiệp. Nếu các thiết bị này không còn trong hợp đồng hỗ trợ ... nghe có vẻ như là một quyết định kinh doanh. Bao lâu công ty của bạn có ý định dành tài nguyên cho sản phẩm cổ không còn tạo ra doanh thu?

Những âm thanh này giống như các thiết bị chuyên dụng, chúng có chuyên dụng đến mức bạn có thể dự đoán hợp lý những miền nào để mong đợi các truy vấn hợp pháp không? liên kết hỗ trợ các khung nhìn, tạo ra một khung nhìn công khai chỉ thực hiện đệ quy cho các miền đó.

Sử dụng điều này như một cơ hội học tập, nếu bạn chưa làm như vậy, hãy ngừng phát hành các sản phẩm mà bạn không có khả năng sửa lỗi. Đây là cái gì, một lỗi. Một trong đó chắc chắn sẽ EOL thiết bị này sớm, sớm hay muộn.

Từ nanog ở đâu đó, cái này:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

Điều này không lý tưởng. Có thể tốt hơn khi cho phép ít gói hơn mỗi giây và có tốc độ cao hơn.

Đây là một giải pháp mà tôi đã sử dụng một vài lần để chống lại các cuộc tấn công DDOS, nó không hoàn hảo nhưng đã giúp tôi thoát ra. Giải pháp bao gồm một tập lệnh được gọi là mỗi N phút (như 1,2,3, v.v.) bởi cron và chặn IP đang tạo ra một số kết nối lớn hơn một kết nối được đưa ra trong tập lệnh:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp