Hallo Gruppe,
ich habe einen bind9, der auch zwei in etwa gleich interessante Zonen öffentlich publiziert. Heute fiel mir beim restart des bind nach einer nötigen Konfigurationsänderung auf, dass er zum beenden seiner childs ewig braucht, eine Analyse der Logs ergab eine Unmengen von Anfragen.
Während die eine Zone in einem Zeitraum ca. 300x befragt wird, sind die Anfragen an die andere Zone im selben Zeitraum zwischen Faktor 50 und 100 größer. Wie gesagt ich glaube, dass die Zonen ungefähr gleich häufig gefragt werden sollten/könnten. Ich ging weiter in die Tiefe, so eine Zone wird in oben genanntem Zeitraum natürlich von beliebigen Clients angefragt, je aber ca. 4x. Die Zone mit dem Anfragenberg, hat auch solche Clients was normal schein allerdings auch welche, die je ca. 300 Anfragen auf immer wieder denselben record und das unmittelbar nacheinander/parallel von verschiedensten clientports aus.
Normal ist das doch nicht, dass ein Client gleich auf mehreren Dutzend Ports ein und denselben Nameserver nach ein und demselben A record fragt. Ich vermute Böses, auch wenn mich das zur Zeit "nur" ressourcen kostet.
Wie aber dämme ich das nun ein, ohne legitime Clients zu beeinflussen? Gehe ich das von Seiten netfilter/iptables irgendwie mit "limit" an oder gibt es da "Schrauben" im bind9, die ich mir anschauen sollte? Würdet ihr überhaupt etwas machen oder abwarten? Es geht schon ein paar Tage so.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo,
Ronny Seffner ronny@seffner.de (Mi 14 Mär 2012 21:33:00 CET):
nötigen Konfigurationsänderung auf, dass er zum beenden seiner childs ewig braucht, eine Analyse der Logs ergab eine Unmengen von Anfragen.
Du loggst die Anfragen? Ohne Logging wird es vielleicht etwas entspannter?
Ich ging weiter in die Tiefe, so eine Zone wird in oben genanntem Zeitraum natürlich von beliebigen Clients angefragt, je aber ca. 4x.
4x die selbe Frage vom selben Client? Das ist nicht normal. Du beantwortest ja sicher schon die erste Frage. Der Client wird wohl ungeduldig, bevor Deine Antwort dort eingetroffen ist.
Die Zone mit dem Anfragenberg, hat auch solche Clients was normal schein allerdings auch welche, die je ca. 300 Anfragen auf immer wieder denselben record und das unmittelbar nacheinander/parallel von verschiedensten clientports aus.
Ein guter Resolver verwendet für jede Anfrage einen neuen Port. Und das schön zufällig. Ebenso die Query-IDs.
Normal ist das doch nicht, dass ein Client gleich auf mehreren Dutzend Ports ein und denselben Nameserver nach ein und demselben A record fragt. Ich vermute Böses, auch wenn mich das zur Zeit "nur" ressourcen kostet.
Nein, normal ist die Häufigkeit nicht. Wobei natürlich hinter dem „Client“ ein gesamtes Netz stecken kann mit schlechtem DNS-Caching und und 1000 Clients hinter dem NAT-Router machen dann ihre Anfragen.
Wie aber dämme ich das nun ein, ohne legitime Clients zu beeinflussen? Gehe ich das von Seiten netfilter/iptables irgendwie mit "limit" an oder gibt es da "Schrauben" im bind9, die ich mir anschauen sollte? Würdet ihr überhaupt etwas machen oder abwarten? Es geht schon ein paar Tage so.
hashlimit in den IPTables könnte Dein Freund werden.
'n Abend Heiko,
Du loggst die Anfragen? Ohne Logging wird es vielleicht etwas entspannter?
Mit Sicherheit, ich wollte aber mal wissen was los ist. Für munin sollte ja die stats genügen ;-)
4x die selbe Frage vom selben Client? Das ist nicht normal. Du beantwortest ja sicher schon die erste Frage. Der Client wird wohl ungeduldig, bevor Deine Antwort dort eingetroffen ist.
Nein, nicht die selbe. Mal A mal MX mal SPF, verteilt über den Tag manches ein zweites Mal obwohl, die TTL mehr hergäbe. Bis zu 4x hätte ich schreiben sollen, 1 und 2 ist häufger anzutreffen, über 4 nix und dann wieder ab 256 und dann immer A und alles in äußerst kurzer Zeit.
Ein guter Resolver verwendet für jede Anfrage einen neuen Port. Und das schön zufällig. Ebenso die Query-IDs.
Warum will dieser Resolver ein und denselben A record aber innerhalb von 10 Sekunden über 200x wissen - ich liefere ja sogar die Antwort.
Nein, normal ist die Häufigkeit nicht. Wobei natürlich hinter dem „Client“ ein gesamtes Netz stecken kann mit schlechtem DNS-Caching und und 1000 Clients hinter dem NAT-Router machen dann ihre Anfragen.
Möglich ist viel, aber 2xx Clients wollen im selben Augenblick kaum das gleiche wissen. Und das alle zwei Minuten später wieder 2xx solche Clients kommen, nur aus einem völlig andern IP-Bereich und das den ganzen Tag lang wird echt obscur - oder?
hashlimit in den IPTables könnte Dein Freund werden.
Das schaue ich mir mal an.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Moin,
Ronny Seffner ronny@seffner.de (Mi 14 Mär 2012 22:46:10 CET):
4x die selbe Frage vom selben Client? Das ist nicht normal. Du beantwortest ja sicher schon die erste Frage. Der Client wird wohl ungeduldig, bevor Deine Antwort dort eingetroffen ist.
Nein, nicht die selbe. Mal A mal MX mal SPF, verteilt über den Tag manches ein zweites Mal obwohl, die TTL mehr hergäbe. Bis zu 4x hätte ich schreiben sollen, 1 und 2 ist häufger anzutreffen, über 4 nix und dann wieder ab 256 und dann immer A und alles in äußerst kurzer Zeit.
Wie groß ist bei den 1..2 mal die Zeitspanne zwischen Anfragen?
Ein guter Resolver verwendet für jede Anfrage einen neuen Port. Und das schön zufällig. Ebenso die Query-IDs.
Warum will dieser Resolver ein und denselben A record aber innerhalb von 10 Sekunden über 200x wissen - ich liefere ja sogar die Antwort.
Ja. 200+ in 10 Sekunden ist etwas häufig. Vielleicht cacht er nicht. Und vielleicht macht er etwas Böses, wofür er die A-Auflösung benötigt. Du bist also nur kolaterales Opfer.
Nein, normal ist die Häufigkeit nicht. Wobei natürlich hinter dem „Client“ ein gesamtes Netz stecken kann mit schlechtem DNS-Caching und und 1000 Clients hinter dem NAT-Router machen dann ihre Anfragen.
Möglich ist viel, aber 2xx Clients wollen im selben Augenblick kaum das gleiche wissen. Und das alle zwei Minuten später wieder 2xx solche Clients kommen, nur aus einem völlig andern IP-Bereich und das den ganzen Tag lang wird echt obscur - oder?
Allerdings. In welche Regionen gehören die Quell-IPs? Gibt es da Beziehungen zu der Domain?
hashlimit in den IPTables könnte Dein Freund werden.
Das schaue ich mir mal an.
Wenn sich die IPs ändern, ist das aber auch etwas sportlich…
Ich grüße nun nicht noch mal ;-)
Nein, nicht dieselbe. Mal A mal MX mal SPF, verteilt über den Tag
manches ein zweites Mal obwohl, die TTL mehr hergäbe. Bis zu 4x hätte ich schreiben sollen, 1 und 2 ist häufiger anzutreffen, über 4 nix und dann wieder ab 256 und dann immer A und alles in äußerst kurzer Zeit.
Wie groß ist bei den 1..2 mal die Zeitspanne zwischen Anfragen?
0 bis zwei Sekunden, der "normale" Client mit mehr als einer Anfrage fragt im Querschnitt immer A, MX und SPF ab. Wenn er eins nochmal fragt, dann quasi immer in einer ganz anderen Minute. Ich denke diese Anfragen sind alle ok.
Ja. 200+ in 10 Sekunden ist etwas häufig. Vielleicht cacht er nicht. Und vielleicht macht er etwas Böses, wofür er die A-Auflösung benötigt. Du bist also nur kollaterales Opfer.
Klar, ich hab ja nur den NS. Und so richtig tut dem Server das nicht weh (noch nicht).
Allerdings. In welche Regionen gehören die Quell-IPs? Gibt es da Beziehungen zu der Domain?
Hier eine Auswahl von IP und Anzahl der Queries:
112.90.21.68 : 275 112.91.169.174 : 303 112.91.173.65 : 239 113.105.157.160 : 307 113.107.174.68 : 291 113.107.95.21 : 215 115.239.226.215 : 283 115.239.229.222 : 299 117.25.149.233 : 222 117.41.243.247 : 250 119.147.138.174 : 283 119.147.139.191 : 303 119.147.154.144 : 270 121.10.107.104 : 220 121.10.112.225 : 1449 121.10.127.146 : 297 121.10.172.60 : 300 121.1.121.200 : 215 121.12.104.150 : 281 121.12.109.129 : 675 121.12.109.234 : 836 121.12.110.71 : 3104 121.12.122.76 : 573 121.12.123.230 : 260 121.14.151.52 : 289 121.14.151.75 : 264 121.14.153.77 : 248 121.9.226.7 : 305 ... 221.4.162.237 : 289 221.4.162.246 : 610 221.4.162.251 : 283 59.34.197.135 : 886 59.34.197.137 : 277 59.34.197.151 : 1075 59.39.69.216 : 304 59.39.69.223 : 306 59.53.68.22 : 266 60.190.216.137 : 760
Stichproben (dig -x, traceroute) führen alle nach China. Konkurrenzmarkt für den Inhaber der betreffenden Domain, stärker als in anderen Teilen der Welt.
hashlimit in den Iptables könnte Dein Freund werden.
Das schaue ich mir mal an.
Wenn sich die IPs ändern, ist das aber auch etwas sportlich…
Meinst Du, das geht doch für mich als Regelschreiber ganz ohne die Quell-IP:
$FW -A INPUT -i $OUT_IF -s 0.0.0.0/0 -d $OUT_IP -p tcp -m state --state NEW --sport 1024:65535 --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT $FW -A INPUT -i $OUT_IF -s 0.0.0.0/0 -d $OUT_IP -p udp -m state --state NEW --sport 1024:65535 --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT
Und es funktioniert sogar, wie ich in /proc/net/ip_hashlimit/dns und mit einem Testclient herausfand ;-)
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Am 14.03.2012 23:59, schrieb Ronny Seffner:
Meinst Du, das geht doch für mich als Regelschreiber ganz ohne die Quell-IP:
$FW -A INPUT -i $OUT_IF -s 0.0.0.0/0 -d $OUT_IP -p tcp -m state --state NEW --sport 1024:65535 --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT $FW -A INPUT -i $OUT_IF -s 0.0.0.0/0 -d $OUT_IP -p udp -m state --state NEW --sport 1024:65535 --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT
Ich würde das Limit vielleicht nicht ganz so knapp setzen, wenn eine normale Anfrage schon aus 3 Querys besteht. Vielleicht fragt derselbe Client kurz darauf noch nach einem anderen Eintrag. Die "Angriffe" haben ja wahrscheinlich deutlich höhere Werte.
Gruß Rico
$FW -A INPUT -i $OUT_IF -s 0.0.0.0/0 -d $OUT_IP -p tcp -m state --state
NEW --sport 1024:65535 --dport 53 -m hashlimit --hashlimit 3/second -- hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT
$FW -A INPUT -i $OUT_IF -s 0.0.0.0/0 -d $OUT_IP -p udp -m state --state
NEW --sport 1024:65535 --dport 53 -m hashlimit --hashlimit 3/second -- hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT
Ich würde das Limit vielleicht nicht ganz so knapp setzen, wenn eine normale Anfrage schon aus 3 Querys besteht. Vielleicht fragt derselbe Client kurz darauf noch nach einem anderen Eintrag. Die "Angriffe" haben ja wahrscheinlich deutlich höhere Werte.
Ich stelle gerade verwundert fest, dass meine Regeln nicht für "den Angreifer" funktionieren sondern offenbar "nur" für meinen Test. Ich habe von einem zweiten Rechner aus den bind durch 10 verkettete 'dig A domain.tld' befeuert und dabei mittels 'tailf /var/log/named/named.log' die queries beobachtet. 5 kommen sofort durch und dann - nach einer kurzen Verzögerung von vllt. 3 Sekunden - immer drei. Ich denke diese "Verzögerung ist in "--haslimit-htable-expire" definiert, was ich noch nicht gesetzt habe und wo ich auch den default noch nicht herausgefunden habe. Grundsätzlich schaffen die obigen Regeln aber das Verhalten, welches ich dachte. Nun kommen die "Chinesen" wieder und deren queries laufen einfach durchs Log, ganz ohne bei 5 zu stoppen. Was machen die anders als ich? Ich habe mich mal vom state NEW getrennt, das hilft aber auch nicht.
Hier meine neuen Regeln:
iptables -A INPUT -i $EXT_IF -s 0.0.0.0/0 -d $EXT_IP -m tcp -p tcp --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT iptables -A INPUT -i $EXT_IF -s 0.0.0.0/0 -d $EXT_IP -m udp -p udp --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT
Und dazu ein Auszug der queries:
15-Mar-2012 14:27:52.686 queries: info: client 121.12.104.150#47472: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.398 queries: info: client 121.12.104.150#20757: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.508 queries: info: client 121.12.104.150#44659: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.971 queries: info: client 121.12.104.150#30994: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.987 queries: info: client 121.12.104.150#36569: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:54.113 queries: info: client 121.12.104.150#56850: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:54.603 queries: info: client 121.12.104.150#28559: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:55.011 queries: info: client 121.12.104.150#13413: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:55.159 queries: info: client 121.12.104.150#11990: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:55.479 queries: info: client 121.12.104.150#55084: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:55.791 queries: info: client 121.12.104.150#16305: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:56.093 queries: info: client 121.12.104.150#30599: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:56.567 queries: info: client 121.12.104.150#58345: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:57.077 queries: info: client 121.12.104.150#23230: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:57.365 queries: info: client 121.12.104.150#53775: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:57.543 queries: info: client 121.12.104.150#51001: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:57.755 queries: info: client 121.12.104.150#28006: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:58.278 queries: info: client 121.12.104.150#30505: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:58.457 queries: info: client 121.12.104.150#25222: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:58.927 queries: info: client 121.12.104.150#8773: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:59.092 queries: info: client 121.12.104.150#61119: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:59.582 queries: info: client 121.12.104.150#20307: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:59.822 queries: info: client 121.12.104.150#8706: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:00.678 queries: info: client 121.12.104.150#32522: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:00.985 queries: info: client 121.12.104.150#21451: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:01.562 queries: info: client 121.12.104.150#23000: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:01.658 queries: info: client 121.12.104.150#7686: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:01.740 queries: info: client 121.12.104.150#39873: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:01.871 queries: info: client 121.12.104.150#49251: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:02.168 queries: info: client 121.12.104.150#42001: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:02.678 queries: info: client 121.12.104.150#1174: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:02.993 queries: info: client 121.12.104.150#64340: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:03.663 queries: info: client 121.12.104.150#20407: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:03.748 queries: info: client 121.12.104.150#1107: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:03.913 queries: info: client 121.12.104.150#53520: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:04.214 queries: info: client 121.12.104.150#39886: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:04.599 queries: info: client 121.12.104.150#31762: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:04.823 queries: info: client 121.12.104.150#63690: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:05.679 queries: info: client 121.12.104.150#28204: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:05.792 queries: info: client 121.12.104.150#22906: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:06.313 queries: info: client 121.12.104.150#57963: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:06.464 queries: info: client 121.12.104.150#59050: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:06.771 queries: info: client 121.12.104.150#56741: query: domain.tld IN ANY + (7x.4y.zz.zz)
Genau genommen sind das nicht mehr als 4 queries pro Sekunde. Diese "Welle" begann 14:27:37.749 und endete 14:28:37.570 mit insgesamt 184 queries.
Aber ob ich wirklich mit sowas wie "--hashlimit 10/minute" arbeiten möchte, weiß ich noch nicht. Wahrscheinlich macht "hashlimit" den Rechner langsamer als die queries, wenn ich das bind logging wieder deaktiviere ...
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Ronny Seffner ronny@seffner.de (Do 15 Mär 2012 14:46:50 CET):
Ich stelle gerade verwundert fest, dass meine Regeln nicht für "den Angreifer" funktionieren sondern offenbar "nur" für meinen Test. Ich habe von einem zweiten Rechner aus den bind durch 10 verkettete 'dig A domain.tld' befeuert und dabei mittels 'tailf /var/log/named/named.log' die queries beobachtet. 5 kommen sofort durch und dann - nach einer kurzen Verzögerung von vllt. 3 Sekunden - immer drei. Ich denke diese "Verzögerung ist in "--haslimit-htable-expire" definiert, was ich noch nicht gesetzt habe und wo ich auch den default noch nicht herausgefunden habe. Grundsätzlich schaffen die obigen Regeln aber das Verhalten, welches ich dachte. Nun kommen die "Chinesen" wieder und deren queries laufen einfach durchs Log, ganz ohne bei 5 zu stoppen. Was machen die anders als ich? Ich habe mich mal vom state NEW getrennt, das hilft aber auch nicht.
Hier meine neuen Regeln:
iptables -A INPUT -i $EXT_IF -s 0.0.0.0/0 -d $EXT_IP -m tcp -p tcp --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT iptables -A INPUT -i $EXT_IF -s 0.0.0.0/0 -d $EXT_IP -m udp -p udp --dport 53 -m hashlimit --hashlimit 3/second --hashlimit-mode srcip,dstport --hashlimit-name dns -j ACCEPT
Und dazu ein Auszug der queries:
15-Mar-2012 14:27:52.686 queries: info: client 121.12.104.150#47472: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.398 queries: info: client 121.12.104.150#20757: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.508 queries: info: client 121.12.104.150#44659: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.971 queries: info: client 121.12.104.150#30994: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:53.987 queries: info: client 121.12.104.150#36569: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:27:54.113 queries: info: client 121.12.104.150#56850: query: domain.tld IN ANY + (7x.4y.zz.zz)
…
15-Mar-2012 14:28:04.599 queries: info: client 121.12.104.150#31762: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:04.823 queries: info: client 121.12.104.150#63690: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:05.679 queries: info: client 121.12.104.150#28204: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:05.792 queries: info: client 121.12.104.150#22906: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:06.313 queries: info: client 121.12.104.150#57963: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:06.464 queries: info: client 121.12.104.150#59050: query: domain.tld IN ANY + (7x.4y.zz.zz) 15-Mar-2012 14:28:06.771 queries: info: client 121.12.104.150#56741: query: domain.tld IN ANY + (7x.4y.zz.zz)
Ich meine, Du müsstest mal nach Hashlimit-Burst gucken. Da sind per default 5 drin, und damit passen die Chinesen durch Deinen Maschendrahtzaun.
Am 14.03.2012 21:33, schrieb Ronny Seffner:
Hallo Gruppe,
ich habe einen bind9, der auch zwei in etwa gleich interessante Zonen
...
Wie aber dämme ich das nun ein, ohne legitime Clients zu beeinflussen? Gehe ich das von Seiten netfilter/iptables irgendwie mit "limit" an oder gibt es da "Schrauben" im bind9, die ich mir anschauen sollte? Würdet ihr überhaupt etwas machen oder abwarten? Es geht schon ein paar Tage so.
man named.conf
options || view clients-per-query number; max-clients-per-query number;
Könnte das eine Lösung sein? Ansonsten würde ich das entweder mit iptables/limit lösen oder einen Filter in fail2ban integrieren.
Gruß Rico
Rico Koerner rico@netbreaker.de (Mi 14 Mär 2012 22:40:01 CET):
Am 14.03.2012 21:33, schrieb Ronny Seffner:
Hallo Gruppe,
ich habe einen bind9, der auch zwei in etwa gleich interessante Zonen
...
Wie aber dämme ich das nun ein, ohne legitime Clients zu beeinflussen? Gehe ich das von Seiten netfilter/iptables irgendwie mit "limit" an oder gibt es da "Schrauben" im bind9, die ich mir anschauen sollte? Würdet ihr überhaupt etwas machen oder abwarten? Es geht schon ein paar Tage so.
man named.conf
options || view clients-per-query number; max-clients-per-query number;
Ich denke, das hilft nur, wenn der Bind die Anfragen der Clients umständlich auflösen muß, was aber hier, da er selbst authoritativ ist, wohl nicht so ist.
Wenn ich die Beschreibung zu den Options richtig verstehe.
Am 14.03.2012 22:49, schrieb Heiko Schlittermann:
Rico Koerner rico@netbreaker.de (Mi 14 Mär 2012 22:40:01 CET):
man named.conf
options || view clients-per-query number; max-clients-per-query number;
Ich denke, das hilft nur, wenn der Bind die Anfragen der Clients umständlich auflösen muß, was aber hier, da er selbst authoritativ ist, wohl nicht so ist.
Wenn ich die Beschreibung zu den Options richtig verstehe.
Wo steht die Beschreibung denn? Bei mir (squeeze) stehen in der manpage nur die Parameter aufgelistet, aber keine Beschreibung dazu,
Rico
Rico Koerner rico@netbreaker.de (Mi 14 Mär 2012 23:24:27 CET):
Am 14.03.2012 22:49, schrieb Heiko Schlittermann:
Rico Koerner rico@netbreaker.de (Mi 14 Mär 2012 22:40:01 CET):
man named.conf
options || view clients-per-query number; max-clients-per-query number;
Ich denke, das hilft nur, wenn der Bind die Anfragen der Clients umständlich auflösen muß, was aber hier, da er selbst authoritativ ist, wohl nicht so ist.
Wenn ich die Beschreibung zu den Options richtig verstehe.
Wo steht die Beschreibung denn? Bei mir (squeeze) stehen in der manpage nur die Parameter aufgelistet, aber keine Beschreibung dazu,
@google: bog clients-per-query site:isc.org
Hallo Rico,
die Doku beim ISC sagt:
clients-per-query, max-clients-per-query
These set the initial value (minimum) and maximum number of recursive simultanious clients for any given query (<qname,qtype,qclass>) that the server will accept before dropping additional clients. named will attempt to self tune this value and changes will be logged. The default values are 10 and 100.
This value should reflect how many queries come in for a given name in the time it takes to resolve that name. If the number of queries exceed this value, named will assume that it is dealing with a non-responsive zone and will drop additional queries. If it gets a response after dropping queries, it will raise the estimate. The estimate will then be lowered in 20 minutes if it has remained unchanged.
"time it takes to resolve" könnte man im Sinne von forwarder interpretieren, muss man aber nicht. Interessant ist, dass ich auf 3 NS zugreifen kann, die vergleichbar sind und nur einer hat das "Problem", dieser logt dann auch fleißig sein Autotuning:
14-Mar-2012 07:48:00.911 resolver: notice: clients-per-query increased to 15 14-Mar-2012 08:08:00.911 resolver: notice: clients-per-query decreased to 14 14-Mar-2012 08:13:00.858 resolver: notice: clients-per-query increased to 19 14-Mar-2012 08:33:00.858 resolver: notice: clients-per-query decreased to 18 14-Mar-2012 08:53:00.858 resolver: notice: clients-per-query decreased to 17 14-Mar-2012 09:13:00.858 resolver: notice: clients-per-query decreased to 16 14-Mar-2012 09:23:00.664 resolver: notice: clients-per-query increased to 15 14-Mar-2012 09:38:00.768 resolver: notice: clients-per-query increased to 15 14-Mar-2012 09:58:00.768 resolver: notice: clients-per-query decreased to 14 14-Mar-2012 10:18:00.768 resolver: notice: clients-per-query decreased to 13 14-Mar-2012 11:43:00.745 resolver: notice: clients-per-query increased to 15 14-Mar-2012 11:48:01.788 resolver: notice: clients-per-query increased to 20 14-Mar-2012 12:08:01.788 resolver: notice: clients-per-query decreased to 19 14-Mar-2012 12:28:01.788 resolver: notice: clients-per-query decreased to 18
Da die Doku in den defaults aber von 10 und 100(bei max*) spricht, sind das hier ja noch keine Panikwerte ...
Mit freundlichen Grüßen / Kind regards Ronny Seffner
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Rico Koerner -
Ronny Seffner