Re: [OT] Messe in Dresden
On Monday 12 March 2012 14:28:18 Heiko Schlittermann wrote: die Messegesellschaft fragte mich, ob die LUG wieder an der Comtec teilnehmen möchte. Konditionen kenne ich noch nicht. Bisher ist noch von Geld und Rabatt die Rede, also nicht von kostenlos. Bevor ich aber die Pferde scheu mache, würde ich gerne wissen, ob es prinzipiell Interesse gibt… Prinzipiell ja, die Frage ist was die Konditionen sind und wann die Messe stattfinden soll (bei der Ortec selbst ist noch nichts zu finden). Für uns intern wäre die Frage wie wir uns präsentieren wollen? Seit das letzte Mal Comtec war haben sich durchaus ein paar Dinge geändert. Konrad signature.asc Description: This is a digitally signed message part. ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: [OT] Messe in Dresden
On Monday 12 March 2012 14:36:22 Roman Geber wrote: On 03/12/2012 02:28 PM, Heiko Schlittermann wrote: die Messegesellschaft fragte mich, ob die LUG wieder an der Comtec teilnehmen möchte. kenne die Comtec nicht. Das könnte daran liegen dass es die Comtec seit 10 Jahren nicht mehr gab. Was hat die LUG da bisher gemacht? Wir haben einfach unsere Rechner und Pinguine auf dem Stand aufgebaut und den Besuchern gezeigt was man mit Linux so machen kann. Das war dann immer der Schlipsfreie Stand mit den Leuten die etwas mehr Spaß dabei hatten... Wenn ich mich recht entsinne hatten wir beim letzten Mal auch den Standpreis gegen eine Handvoll Vorträge getauscht. Heiko, evtl. hat die Ortec wieder so einen Deal im Sinn. Konrad signature.asc Description: This is a digitally signed message part. ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Suche Android Testumgebung
Hallo Liste, ich suche eine Testumgebung für ein im Shareordner gefundenen Verzeichnis mit Smartphone Scripten. Ich habe sie ein wenig verändert und wuerde das gerne jetzt gleich mit testen. Froglogic läuft irgendwie nur auf Apple Devices. Ich brauche eine Anwendung, die mit den Applikation Internals spricht. Entweder auf meinem Smartphone Tablett oder div. VM auf meinem Host. Gruesse, Jana -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Clientanfragen auf bind einschränken - welche Vorgehen
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 -- Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Clientanfragen auf bind einschränken - welche Vorgehen
Hallo, Ronny Seffner ro...@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. -- Heiko signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Clientanfragen auf bind einschränken - welche Vorgehen
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 smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Clientanfragen auf bind einschränken - welche Vorgehen
Am 14.03.2012 22:49, schrieb Heiko Schlittermann: Rico Koerner r...@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 smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Clientanfragen auf bind einschränken - welche Vorgehen
Rico Koerner r...@netbreaker.de (Mi 14 Mär 2012 23:24:27 CET): Am 14.03.2012 22:49, schrieb Heiko Schlittermann: Rico Koerner r...@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 -- Heiko signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: Clientanfragen auf bind einschränken - welche Vorgehen
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 -- Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: Clientanfragen auf bind einschränken - welche Vorgehen
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 -- Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
