DNS-Query Limits mit iptables und Burstrate

Seit etwas über zwei Monaten betreibe ich einen OpenNIC Nameserver, über den jeder Mensch auf der Welt Hostnamen in IP-Adressen auflösen kann (mehr zum Nameserver gibt es hier). Jeder Mensch, aber leider auch jeder durch Viren befallene Zombie-Computer. Die massiven Anfragen nach Mailservern führten bereits zweimal dazu, dass mein Router die Anzahl von Anfragen nicht mehr bearbeiten konnte und der Internetzugang sich verabschiedete.

Query Flood! Was tun?

Im Blog von Benny Baumann werden Tips vorgestellt, die sehr spezifisch bestimmte Anfragen mit einfachen iptables Regeln verwerfen. Da ich leider nicht Nachfragen nach den Rootservern ablehnen kann (öffentliche Nameserver müssen hier antworten) und auch leider nicht nach einer einzigen Domain gefragt wird, kam nur eine Limitierung in Frage. Dabei wird die Anzahl der maximal in einem Zeitintervall (zum Beispiel eine Sekunde) verarbeiteten Pakete begrenzt.

Durch Nachfragen bei anderen OpenNIC Serveradmins und Analyse anonymisierter Logfiles konnte ich 5 Anfragen pro Sekunde als Durchschnitt pro IP feststellen. Diese Einstellung brachte zwar Besserung, führte aber dazu, dass bei einem Rechnerstart einige Programmer länger brauchten. Klar, die Anfragen pro Sekunde sind zu stark begrenzt. Die Lösung des Problems möchte ich gern mit euch teilen.

Es wird die Anzahl der Pakete pro Sekunde einer Quell-IP nicht über den Zeitraum einer Sekunde gemessen, sondern über einen längeren Zeitraum. Das würde zu einer Reduzierung der Anfragen führen (fünf pro Sekunde ist trivialierweise mehr als 5 pro zehn Sekunden), also wird die Anzahl der Anfragen mit den Sekunden multipliziert. Jetzt ist es natürlich möglich, alle erlaubten Anfragen in der ersten Sekunde zu senden, was wieder zu einer Überlastung der Anbindung führen würde. Dem wird ein Riegel vorgeschoben, indem die Anzahl der Anfragen pro Sekunde auch limitiert wird, aber eben auf einen höheren als den angestrebten Wert.

Ich habe die Anfragen pro Sekunde auf 5 limitiert, was dazu führt, dass in 7 Sekunden 35 Anfragen erlaubt sind.
Um das Erste-Sekunde Problem zu lösen, sind in jeder der sieben Sekunden nur maximal 15 Anfragen erlaubt.

Skript schreiben statt manuell blockieren!

Hier das Skript für Interessierte:

#!/bin/bash
# This script limits the queries per second to 5/s
# with a burst rate of 15/s and does not require
# buffer space changes

# Requests per second
RQS="15"

# Requests per 7 seconds
RQH="35"

iptables --flush
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --set --name DNSQF --rsource
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 1 --hitcount ${RQS} --name DNSQF --rsource -j DROP
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --set --name DNSHF --rsource
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 7 --hitcount ${RQH} --name DNSHF --rsource -j DROP

rsync,ssh,tar und socat – Große Datenbestände kopieren

Manchmal muss es etwas schneller sein als sonst. Gerade wenn man mit einem zehn Jahre alten Datenbestand von einem Computer auf einen anderen umziehen möchte.

Wie ist dabei der Maximaldurchsatz zu erreichen?

Am Transfer großer Datenbestände sind in erster Linie zwei Komponenten zwangsweise beteiligt. Das Festplatten-Subsystem und das Netzwerk-Subsystem der zu synchronisierenden Computer.

Standardlösung

Da das Problem nicht neu ist und sich selbst in Lehrbüchern wiederfindet gibt es eine Standardlösung: rsync.

rsync -ar --stats --progress /home/meinBenutzer/*Ü meinBenutzer@neuerComputer:~/

Soll es mit rsync, dass auf SSH für den Transfer setzt, schneller gehen, passt man die Chiffre an. Das funktioniert durch die Option -e "ssh -c arcfour", die den RC4 Stromchiffre verwendet. Der Durchsatz steigt, aber erreicht aufgrund des Overheads der Verschlüsselung und der Integritätsprüfungen, die rsync bietet nicht Netzwerk- oder Festplatten-Maximaldurchsatz.

Mehr Power!

Der Maximaldurchsatz der Festplatte lässt sich erreichen, indem die lesenden und schreibenden Operationen sequentiell durchgeführt werden. Ein Programm, dass die Daten sequentiell liest ist tar. Indem man tar anweist, das erzeugte Archiv auf die Standardausgabe zu senden, kann es über das LAN transportiert werden. Um hierbei den Prozessor nicht einzuspannen, erfolgt die Übertragung unverschlüsselt und unkomprimiert mit socat.

Das geht wie folgt:

Auf dem Server (Empfänger)

socat tcp-listen:31337,rcvbuf=67108864,dontroute stdout | tar xvf - -C ./

Auf dem Client (Sender)

tar cvf - ./* | socat stdin tcp:192.168.my.ip:31337,sndbuf=67108864,dontroute

Erwähnenswert ist besonders die Option dontroute, durch die sichergestellt wird, dass der Datenverkehr der sensiblen privaten Daten nicht das lokale Netz verlässt. Mit den Optionen rcbuf und sndbuf werden die TCP-Puffer auf beiden Seiten vergrößert und das Auto-Tuning des Kernels umgangen.

Fazit

Durch die Vermeidung von Verschlüsselung, Komprimierung und der manuellen Vergrößerung der Sende- und Empfangspuffer sollte theoretisch jetzt der Maximaldurchsatz erreicht werden können. Bei einem sehr unwissenschaftlichen Test bestätigte sich die Vermutung, dass socat mit tar schneller ist.

Beim Kopieren von 560 Gigabyte von einem mit 170 MB/sec lokal gemessenen Software-RAID1 zu einem 411 MB/sec lokal gemessenen Software-RAID1 erreichte rsync einen Maximaldurchsatz von 340 MBit/sec, tar mit socat reizte die vollen 988 MBit/sec aus.

Kochen für Geeks Buchrezension

Als eher analytisch orientierter Mensch, hat man eine eigene Herangehensweise an neue Themenfelder die von anderen belächelt wird. Oft sind aber einige mathematische und theoretische Grundlagen von Nöten, um mehr tun zu können, als Vor- und Nachmachen. Ernährung ist so ein praktisches Themengebiet, Ernäherungswissenschaften der theoretische Teil.

Konkret wollte ich meine grundlegenden Fähigkeiten als Koch erweitern. Grundlegende gesunde Ernährung kann ich bereits sicherstellen, bei den genau sieben unterschiedlichen Gerichten dürfte es aber bald langweilig werden.

Unter dieser Vorraussetzung habe ich das Buch „Kochen für Geeks“ vom O’Reilly Verlag gelesen.

Inhalt

Die Lektüre der 432 Seiten geht leicht von der Hand, das Niveau ist auch für Amateure im Kochen so gehalten, dass man den physikalischen und chemischen Vorgängen leicht folgen kann.

Um die Zielgruppe möglichst schnell anzusprechen, wird eine durchaus stimmige Struktur gewählt. Zuerst werden die Voraussetzungen für das nicht nur erfolgreiche, sondern effiziente zubereiten von Nahrung dargestellt. Dabei differenziert das Buch zwischen Minimal- und Standard-Voraussetzungen, gibt Tips zur Kategorisierung die nach Aufgaben geschehen soll. Die ersten Kapitel behandeln ausschließlich die Einrichtung und versuchen durch spritzig gewählte Überschriften dem Leser den Eindruck zu vermitteln, Kochen sei mit Hacken vergleichbar.

Die darauffolgenden drei Kapitel beschäftigen sich mit den Komponenten und Vorgängen, die mit diesen Komponenten durchgeführt werden können. Dazu zählt inesbesondere eine umfangreiche Einführung in die verschiedenen Geschmacksrichtungen und die Aufforderung, durch Permutation zu perfektionieren. Oder kurz: „rumtesten!“ Diese drei Kapitel stellen auch den Kern des Buchs dar. Besonders gut gefallen hat mir hierbei, das explizite hervorheben von Lebensmittelkrankheiten und dem nötigen Schutz. Bei chemischen Vorgängen wird mit kurzen und sehr einfachen Formeln nicht gespart, viel weiter geht es aber nicht.

Das letzte Kapitel versucht ambitionierte Köche anzusprechen, indem fortgeschrittene Techniken kurz angerissen werden.

Kritik

Leider hat mich das Buch nicht angesprochen. Hauptsächlich hatte ich bei einem Buch, dass sich an Geeks richtet, mehr Kontext erwartet. Die fehlenden Hintergrundinformationen zeigen sich insbesondere bei der verwendeten Mathematik. Kleine Formeln werden noch genannt, aber nicht ein einziges mal bewiesen. Mich hätte ein Beweis über den Nährgehalt eines komplexen Gerichts sehr gefreut. Hier wurde gespart, was den Autoren aber nicht vorgehalten werden sollte, schließlich wollen sie praktische Fähigkeiten vermitteln.

Auch der Schreibstil war leider an einigen Stellen etwas zu spritzig. Es ist meiner Ansicht nach durchaus okay, wenn Kochen nichts mit Programmieren zutun hat. Diese Annäherung war an den Haaren herbeigezogen. Komplexe chemische Vorgänge erzeugen einfach immer unterschiedliche Resultate, wenn in einer Küche und nicht in einem Labor gearbeitet wird.

Auch wenn ich nicht viel aus dem Buch mitgenommen habe, war es doch sehr spritzig geschrieben und hat einige Aha!-Momente erzeugen können. Um das Kochen systematisch zu lernen, taugt es leider nicht.

Dank

Mein besonderer Dank geht an getDigital, die mir das Buch zur Rezension freundlicherweise zur Verfügung gestellt haben. Wer getDigital noch nicht kennt und mit Netzwerken und Computern arbeitet, sollte dringend in die Geschenkideen reinschauen.

Lord Felix, ein Sith

2010 habe ich mir vorgenommen, mein Privatleben weitgehend aus diesem Blog heraus zu halten und nur über fachliche Themen zu schreiben. Nach zwei Jahren hadern, gebe ich aber gern zu, dass ich auch ein Privatleben habe.

Um das ganze zu untermauern, hier ein Bild des neusten lebendigen Zugangs in meiner Wohnung. Nach Pflanzen kam vor drei Tagen der nächste Schritt, ein lebendes Tier. Es heisst Felix, ist ein Kater und bereitet mir und meiner potenziellen besten Ehefrau von Allen eine Menge Freude.

Mehr über den Kater gibt es hier.

Bei ssh-copy-id abweichenden Port angeben

Automatismen erleichtern unter Linux das Leben und einer davon ist das Hilfsprogramm ssh-copy-id zur automatischen Schlüssel-Installation auf einem entfernten Computer. Aber wie kann damit ein öffentlicher Schlüssel auf einen Server mit einem veränderten Port kopiert werden? So:

ssh-copy-id "userName@hostName -p 12345"

Das Hilfsprogramm ist nur ein Wrapper um ssh und kann über den kleinen Umweg mit Anführungszeichen auch mit anderen Optionen und Argumenten aufgerufen werden. Bei größeren Schlüsseln und vielen Zielrechnern bietet sich zum Beispiel Kompression über die -C Option an.