liên kết: lỗ đen cho truy vấn đệ quy không hợp lệ?


13

Tôi có một máy chủ tên có thể truy cập công khai vì đó là máy chủ tên có thẩm quyền cho một vài tên miền .

Hiện tại máy chủ đang tràn ngập ANYcác yêu cầu giả mạo cho isc.org, ripe.net và tương tự (đó là một cuộc tấn công DoS phân tán đã biết ).

Máy chủ chạy BIND và đã allow-recursionđặt thành mạng LAN của tôi để những yêu cầu này bị từ chối. Trong những trường hợp như vậy, máy chủ chỉ phản hồi với authorityadditionalcác phần giới thiệu máy chủ gốc.

Tôi có thể định cấu hình BIND để nó hoàn toàn bỏ qua các yêu cầu này mà không gửi phản hồi nào không?

Câu trả lời:


5

Đối mặt với cùng một vấn đề, tôi đã chọn bỏ qua tất cả các yêu cầu đệ quy. Tất cả các trình phân giải đều gửi một truy vấn không đệ quy khi họ muốn sử dụng máy chủ của tôi làm máy chủ có thẩm quyền. Chỉ những khách hàng và kẻ tấn công bị định cấu hình sai, trong trường hợp của riêng tôi, mới sử dụng truy vấn đệ quy.

Thật không may, tôi không tìm thấy cách nào để BIND làm điều đó, nhưng trong trường hợp iptables đủ tốt cho bạn, tôi đã sử dụng

iptables -t raw -I PREROUTING -i eth0 -p udp --destination-port 53 \
    -m string --algo kmp --from 30 \
    --hex-string "|01000001000000000000|" -j DROP

Không, khối quy tắc đó cũng yêu cầu loại có thẩm quyền (ít nhất là trên máy của tôi). Rõ ràng nó chặn tất cả các loại yêu cầu DNS.
Udo G

Tôi đã kiểm tra lại và tôi đang sử dụng chính xác quy tắc đó. Đây là một phần cắt và dán từ máy chủ trực tiếp. Lệnh : iptables -t raw -S PREROUTING. Đầu ra : -P PREROUTING ACCEPT, theo sau -A PREROUTING -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|01000001000000000000|" --algo kmp --from 30 --to 65535 -j DROP. Tôi đã kiểm tra rằng nó đang hoạt động chính xác với host -ar exampledomain.com dns-server.example.net. Tất nhiên nó không hoạt động chính xác cho đến khi tôi thêm -rtùy chọn.
pino42

Được rồi, -rtùy chọn làm cho sự khác biệt. Cá nhân tôi không thích hostcác truy vấn đơn giản đó không hoạt động nữa và điều này có thể rất khó hiểu. Tuy nhiên, đây có lẽ là một câu trả lời hợp lệ (tốt nhất) và tôi sẽ cung cấp cho bạn tiền thưởng, vì nó sắp hết hạn, ngay cả khi tôi sẽ tiếp tục sử dụng phương pháp của riêng mình bằng cách lọc OUTPUT.
Udo G

Cảm ơn! Nếu tôi tìm thấy một giải pháp tốt hơn, tôi chắc chắn sẽ đăng nó. Tôi đồng ý với bạn: đây là một hack. Một làm việc, nhưng vẫn là một hack.
pino42

2

Tôi sẽ thử:

zone "." {
  type redirect;
  allow-query "none";
}

Các phản hồi giới thiệu khách hàng đến các máy chủ gốc được kiểm soát bởi vùng "chuyển hướng". Điều này sẽ nói với nó không trả lời cho những người.

Đó là gợi ý trong các tài liệu Bind9: http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#id2592674

Bạn có thể thay thế "none"bằng mạng con cục bộ của bạn.

Nếu bạn đã có một zone "."khai báo, chỉ cần thêm allow-query "none";vào nó.


Tôi có một zone "." { type hint; file "/etc/bind/db.root"; };khai báo với db.root liệt kê các máy chủ gốc. Việc xóa khai báo đó dừng các anwers cho các tên miền nước ngoài nhưng máy chủ vẫn phản hồi với "lỗi máy chủ" và do đó vẫn có thể được sử dụng cho DoS.
Udo G

@UdoG: Bạn đã thử thêm allow-query "none";vào zone "."cấu hình chưa?
freiheit

Có vẻ như điều này chỉ tiết kiệm băng thông ngược dòng mặc dù rất phong phú. Với bản sửa lỗi của bạn, kẻ tấn công đã sử dụng hết băng thông và sức mạnh xử lý của máy chủ của bạn
TheLQ

@TheLQ: Câu hỏi đề cập đến việc đây là một cuộc tấn công DDoS. Cuộc tấn công DDoS dựa trên DNS phổ biến là gửi các truy vấn DNS với IP giả mạo của mục tiêu. Vì gói trả lời DNS lớn hơn truy vấn, nó cung cấp hệ số nhân. Nếu máy chủ của bạn không phản hồi với gói lớn hơn đáng kể, bạn đã loại bỏ lý do họ sử dụng máy chủ của mình trong cuộc tấn công.
freiheit

@UdoG: Gói lỗi máy chủ chỉ từ 31 đến 32, trong khi giới thiệu đến các máy chủ gốc có thể là vài trăm byte. Nếu câu trả lời của máy chủ của bạn có cùng kích thước với truy vấn hoặc chỉ lớn hơn một chút, máy chủ của bạn sẽ vô dụng trong một cuộc tấn công DNS DDoS, vì những kẻ tấn công sẽ tiêu tốn nhiều băng thông khi chúng đưa bạn đến mục tiêu của chúng. Tôi đã thử nghiệm với một số máy chủ tên có thẩm quyền được cấu hình tốt (chẳng hạn như google) và họ đã trả lời "yêu cầu đệ quy nhưng không khả dụng".
freiheit

1

Nói chung, tôi sẽ đề nghị:

Bật nhật ký liên kết và ghi lại ips bị từ chối trả lời. Cài đặt chương trình fail2ban, thêm hành động lỗ đen: http://pastebin.com/k4BxrAeG (đặt quy tắc trong tệp trong /etc/fail2ban/ilities.d)

Tạo tệp bộ lọc liên kết trong /etc/fail2ban/filter.d bằng một cái gì đó như thế này (cần gỡ lỗi!)

[Definition]
failregex = ^.* security: info: client #<HOST>: query \(cache\) .* denied

Chỉnh sửa fail2ban.conf, thêm phần:

[bindban]

enabled  = true
filter   = bind
# "bantime" is the number of seconds that a host is banned.
bantime  = 6000
# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 60
# "maxretry" is the number of failures before a host get banned.
maxretry = 150
action   = blackhole
logpath  = /var/log/named.log

Hy vọng điều này sẽ giúp!


TODO: liên kết ví dụ tệp nhật ký.
Andrei Mikhaltsov

1

Ý tưởng cơ bản cho phép liên kết phân loại phản hồi DNS là Từ chối sau đó sử dụng iptables để chuyển Từ chối thành âm thầm bỏ qua.

Từ chối là phần dễ dàng trong phần tùy chọn có tên:

allow-recursion { none;};

Hoặc tất nhiên là ACL yêu thích của bạn cho các ngoại lệ địa phương ...

Phép thuật iptables điên tiếp theo, điều chỉnh hoặc loại bỏ "-o eth0" nếu cần. Lệnh này giả sử tiêu đề lớp IPv4 20 byte tiêu chuẩn trước UDP.

iptables -A OUTPUT -o eth0 -p udp --sport 53 -m string --from 30 --to 32 --hex-string "|8105|" --algo bm -j DROP

Phím này trên trường cờ phản hồi DNS với các bit sau được đặt

  • Phản hồi DNS
  • Truy vấn đệ quy
  • Trả lời mã từ chối

Thông báo nhật ký thông báo đang chạy liên kết trong gỡ lỗi "phản hồi gửi lỗi: máy chủ không thể truy cập" khi quy tắc khớp với một số phản hồi để kiểm tra.

Phải thừa nhận đây là một bài tập hơi vô nghĩa. Nếu không có sự khuếch đại, kẻ tấn công có thể dễ dàng phản ánh TCP SYN. Cuối cùng, DNS bị phá vỡ đơn giản là không có giải pháp khả thi nào ngoài việc sử dụng TCP hoặc triển khai cookie DNS của Eastlake.


0

Bạn đã thử chặn chuỗi isc.org hay chặn chuỗi hex cho nó chưa?

Điều này làm việc cho tôi:

iptables -A INPUT -p udp -m chuỗi --hex-chuỗi "| 03697363036f726700 |" --algo bm -j DROP


Sẽ không tốt hơn nếu xác định các chuỗi hex cho tất cả các tên miền mà máy chủ sẽ phản hồi, thực hiện các điều trên để cho phép các chuỗi đó và loại bỏ tất cả các udp / 53 khác?
freiheit

Tôi hiện đang chặn các phản hồi UDP đang đề cập đến các máy chủ gốc: iptables -A OUTPUT -p udp -m string -hex-string "|726f6f742d73657276657273|" –algo bm –to 65535 -j DROPnhưng tôi thực sự thích một giải pháp chỉ dựa trên cấu hình BIND, nếu điều đó hoàn toàn có thể.
Udo G

cái này yếu bạn có thể tạo bất cứ thứ gì bạn muốn như tên miền. chúng tôi đang phải đối mặt với vấn đề đó ngay bây giờ và đó không phải là cách để chặn nó thông qua tên tĩnh'bnrexex.www.sf97.net/A/IN' 'whzpkacpxpiuycm.www.tpa.net.cn/A/IN'
3h4x 17/03/2016

0

Cuộc tấn công này được gọi là Từ chối dịch vụ Amplified. Bạn nên định cấu hình liên kết đúng cách nhưng lưu lượng đó không nên truy cập liên kết của bạn ở vị trí đầu tiên. Chặn nó trên thiết bị mạng đầu tiên có khả năng thực hiện trong mạng của bạn. Tôi đã có cùng một vấn đề và giải quyết nó với quy tắc khịt mũi điếc:

cảnh báo udp $ EXTERNAL_NET any -> $ HOME_NET 53 (tin nhắn: "PROTOCOL-DNS truy vấn quá mức loại BẤT K - - DoS tiềm năng"; byte_test: 1 ,! &, 0xF8,2; nội dung: "| 00 00 FF 00 01 |"; Phát hiện_filter: theo dõi by_src, đếm 30, giây 30; siêu dữ liệu: dịch vụ dns; tham chiếu: url, foxpa.ws / 2010/07/21 / thwarting-the-isc-org-dns-ddos /; classtype: đã cố gắng-dos; sid : 21817; vòng quay: 4;)


0

Đầu tiên, tôi biết đây là một câu hỏi cũ nhưng ...

Tôi đã chạy máy chủ DNS có thẩm quyền, không đệ quy của mình trong nhiều thập kỷ, nhưng chưa bao giờ là nạn nhân trong bất kỳ cuộc tấn công DDoS dựa trên DNS nào - cho đến bây giờ, khi tôi chuyển sang ISP mới. Hàng ngàn truy vấn DNS giả mạo tràn ngập nhật ký của tôi và tôi thực sự khó chịu - không ảnh hưởng nhiều đến máy chủ của tôi, thay vào đó, thực tế là nó làm lộn xộn nhật ký của tôi và cảm giác khó chịu khi bị lạm dụng. Có vẻ như kẻ tấn công cố gắng sử dụng DNS của tôi trong một cuộc tấn công Máy chủ tên có thẩm quyền của nhà mạng .

Vì vậy, tôi đã hình dung rằng, mặc dù tôi giới hạn các truy vấn đệ quy vào mạng bên trong của mình (từ chối tất cả các truy vấn khác), tôi thà dành chu kỳ CPU của mình cho khớp chuỗi trong iptables hơn là gửi lại phản hồi tiêu cực cho các địa chỉ IP giả mạo (ít lộn xộn hơn trong nhật ký của tôi lưu lượng truy cập mạng và mức độ hài lòng cao hơn của riêng tôi).

Tôi đã bắt đầu bằng cách làm như mọi người khác dường như làm , tìm ra tên miền nào được truy vấn và tạo một chuỗi khớp trên tên miền đó với DROP mục tiêu. Nhưng tôi sớm nhận ra rằng tôi sẽ kết thúc với một số lượng lớn các quy tắc, mỗi quy tắc đều tiêu tốn chu kỳ CPU. Vậy lam gi? Vì tôi không chạy một máy chủ tên đệ quy, tôi đã hình dung rằng tôi có thể thực hiện việc khớp trên các khu vực thực tế mà tôi có thẩm quyền và bỏ mọi thứ khác.

Chính sách mặc định của tôi trong iptables là CHẤP NHẬN, nếu chính sách của bạn là DROP, có lẽ bạn cần thực hiện một số điều chỉnh nếu bạn muốn sử dụng giải pháp sau.

Tôi giữ cấu hình vùng của mình trong một tệp riêng (/etc/bind/named.conf.local), hãy sử dụng điều này làm ví dụ:

zone "1.168.192.in-addr.arpa" { // Private
        type master;
        allow-query { 192.168.1.0/24; 127.0.0.1; };
        allow-transfer { 127.0.0.1; };
        file "/etc/bind/db.192.168.1";
};

zone "home.example.net" { // Private
        type master;
        allow-query { 192.168.1.0/24; 127.0.0.1; };
        allow-transfer { 127.0.0.1; };
        file "/etc/bind/pri/db.home.example.net";
};

zone "example.net" {
        type master;
        file "/etc/bind/pri/db.example.net";
        allow-transfer { 127.0.0.1; 8.8.8.8; };
};

zone "example.com" {
        type slave;
        masters { 8.8.8.8; };
        file "sec.example.com";
        allow-transfer { 127.0.0.1; };
        notify no;
};

zone "subdomain.of.example.nu" {
        type slave;
        masters { 8.8.8.8; };
        file "sec.subdomain.of.example.nu";
        allow-transfer { 127.0.0.1; };
        notify no;
};

Lưu ý nhận xét của // // riêng tư về hai vùng đầu tiên của tôi, tôi sử dụng đoạn mã này trong đoạn mã sau để loại trừ chúng khỏi danh sách các vùng hợp lệ.

#!/usr/bin/perl
# zone2iptables - Richard Lithvall, april 2014
#
# Since we want to match not only example.net, but also (for example)
# www.example.net we need to set a reasonable maximum value for a domain
# name in our zones - 100 character should be more that enough for most people
# and 255 is the absolute maximum allowed in rfc1034.
# Set it to 0 (zero) if you would like the script to fetch each zone (axfr)
# to get the actual max value.
$maxLengthOfQueryName=255;
$externalInterface="eth1";

print "# first time you run this, you will get error on the 3 first commands.\n";
print "# It's here to make it safe/possible to periodically run this script.\n";
print "/sbin/iptables -D INPUT -i $externalInterface -p udp --dport 53 -j DNSvalidate\n";
print "/sbin/iptables -F DNSvalidate\n";
print "/sbin/iptables -X DNSvalidate\n";
print "#\n";
print "# now, create the chain (again)\n";
print "/sbin/iptables -N DNSvalidate\n";
print "# and populate it with your zones\n";
while(<>){
        if(/^zone\s+"(.+)"\s+\{$/){
                $zone=$1;
                if($maxLengthOfQueryName){
                        $max=$maxLengthOfQueryName;
                } else {
                        open(DIG,"dig -t axfr +nocmd +nostats $zone |");
                        $max=0;
                        while(<DIG>){
                                if(/^(.+?)\.\s/){
                                        $max=(length($1)>$max)?length($1):$max;
                                }
                        }
                        close(DIG);
                }
                printf("iptables -A DNSvalidate -m string --from 40 --to %d --hex-string \"",($max+42));
                foreach $subdomain (split('\.',$zone)){
                        printf("|%02X|%s",length($subdomain),$subdomain);
                }
                print("|00|\" --algo bm -j RETURN -m comment --comment \"$zone\"\n");
        }
}
print "# and end the new chain with a drop\n";
print "/sbin/iptables -A DNSvalidate -j DROP\n";
print "# And, at last, make the new chain active (on UDP/53)\n";
print "/sbin/iptables -A INPUT -i $externalInterface -p udp --dport 53 -j DNSvalidate\n";

Chạy đoạn script trên với tệp cấu hình vùng làm đối số.

root:~/tmp/# ./zone2iptables.pl /etc/bind/named.conf.local 
# first time you run this, you will get error on the 3 first commands.
# It's here to make it safe/possible to periodically run this script.
/sbin/iptables -D INPUT -i eth1 -p udp --dport 53 -j DNSvalidate
/sbin/iptables -F DNSvalidate
/sbin/iptables -X DNSvalidate
#
# now, create the chain (again)
/sbin/iptables -N DNSvalidate
# and populate it with your zones
iptables -A DNSvalidate -m string --from 40 --to 297 --hex-string "|07|example|03|net|00|" --algo bm -j RETURN -m comment --comment "example.net"
iptables -A DNSvalidate -m string --from 40 --to 297 --hex-string "|07|example|03|com|00|" --algo bm -j RETURN -m comment --comment "example.com"
iptables -A DNSvalidate -m string --from 40 --to 297 --hex-string "|09|subdomain|02|of|07|example|02|nu|00|" --algo bm -j RETURN -m comment --comment "subdomain.of.example.nu"
# and end the new chain with a drop
/sbin/iptables -A DNSvalidate -j DROP
# And, at last, make the new chain active (on UDP/53)
/sbin/iptables -A INPUT -i eth1 -p udp --dport 53 -j DNSvalidate

Lưu đầu ra vào một tập lệnh, đặt nó vào một vỏ hoặc sao chép và dán nó vào thiết bị đầu cuối của bạn để tạo chuỗi mới và bắt đầu lọc tất cả các truy vấn DNS không hợp lệ.

run / sbin / iptables -L DNSvalidate -nvx để xem các bộ đếm gói (và byte) trên mỗi quy tắc trong chuỗi mới (bạn có thể muốn di chuyển vùng có hầu hết các gói lên đầu danh sách để làm cho nó hiệu quả hơn).

Hy vọng rằng ai đó có thể tìm thấy điều này hữu ích :)

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.