Öffentlich zugängliche rekursive DNS-Server - iptables-Regeln

Wir betreiben öffentlich zugängliche rekursive DNS-Server auf Linux-Rechnern. Wir wurden für DNS-Verstärkungsangriffe verwendet. Gibt es empfohlene iptablesRegeln, um diese Angriffe abzuschwächen?

Die naheliegende Lösung besteht darin, ausgehende DNS-Pakete auf ein bestimmtes Verkehrsniveau zu beschränken. Aber ich hatte gehofft, etwas Klügeres zu finden, damit ein Angriff nur den Verkehr zur IP-Adresse des Opfers blockiert.

Ich habe nach Ratschlägen und Vorschlägen gesucht, aber alle scheinen "keine öffentlich zugänglichen rekursiven Nameserver zu betreiben". Leider befinden wir uns in einer Situation, in der Dinge, die nicht leicht zu ändern sind, brechen, wenn wir dies nicht tun, und dies ist auf Entscheidungen zurückzuführen, die vor mehr als einem Jahrzehnt getroffen wurden, bevor diese Angriffe ein Problem darstellten.

Das Ganze stinkt nach einem "Nicht mein Problem" -Szenario, das nicht wirklich deine Schuld ist und das zu 100% durch Ergreifen der entsprechenden Maßnahmen gelöst werden sollte / könnte, unabhängig davon, wie "schwierig" oder "schwer" es ist, und das beendet dein Szenario rekursiven Server öffnen .

Ausstieg: Teilen Sie den Kunden mit, dass dieser Server ab dem X-Datum nicht mehr verfügbar ist. Nach dieser Zeit müssen sie einen Patch installieren (vorausgesetzt, Sie haben einen), um die Verwendung Ihres DNS-Servers zu verhindern. Dies geschieht die ganze Zeit. Sysadmins, Netzwerkadministratoren, Helpdesk-Mitarbeiter, Programmierer? Wir verstehen es; Dieses Ende der Lebensdauer tritt immer wieder auf, da ein Anbieter / Dienstleister / Partner uns standardmäßig auffordert, die Verwendung von etwas nach dem X-Datum einzustellen. Wir mögen es nicht immer, aber es ist eine Tatsache in der IT.

Sie sagen, dass Sie dieses Problem auf den aktuellen Geräten nicht haben. Daher gehe ich davon aus, dass Sie dieses Problem mit einem Firmware-Update oder -Patch behoben haben. Ich weiß, dass Sie gesagt haben, dass Sie das Gerät nicht berühren können, aber das können sie doch? Ich meine, wenn sie es diesen Boxen erlauben, im Wesentlichen zu Ihnen nach Hause zu telefonieren, können sie nicht wirklich so anal sein , wer was mit ihren Geräten macht; Möglicherweise haben Sie ein Reverse-Proxy-Setup, wenn Sie wissen, warum installieren Sie nicht einen Patch, der dies behebt, oder weisen Sie sie an, ihre eigenen DNS-Server zu verwenden . Sicherlich unterstützt Ihr Gerät DHCP. Ich kann mir kein Netzwerkgerät vorstellen (egal wie alt / gebrechlich / seltsam), das dies nicht tut .

Wenn Sie dies nicht tun können, müssen Sie als Nächstes steuern, wer auf Ihren rekursiven Server zugreifen kann : Sie sagen, dass es "schwer zu sagen" ist, wer ihn verwendet und wie, aber es ist an der Zeit, dies sicher herauszufinden und den Datenverkehr zu reduzieren nicht legitim.

Das sind "Quasi-Militär / Regierungs" -Organisationen, oder? Nun, sie sind wahrscheinlich Teil eines legitimen Netzwerkblocks, den sie besitzen. Diese Geräte sind keine Heimrouter hinter dynamischen IPs. Rausfinden. Kontaktieren Sie sie, erklären Sie das Problem und wie Sie ihnen viel Geld sparen, indem Sie keinen Firmware- oder Produktaustausch erzwingen, wenn sie nur die Netblock- / IP-Adresse bestätigen können, die das Gerät für den Zugriff auf Ihren DNS-Server verwendet.

Dies geschieht ständig: Ich habe mehrere Kunden, die auf diese Weise den Extranet-Zugang oder HL7-Listener auf Gesundheitspartner beschränken. es ist nicht so schwerDamit sie ein Formular ausfüllen und die IP und / oder den Netzwerkblock angeben können, von denen ich Datenverkehr erwarten sollte: Wenn sie Zugriff auf das Extranet erhalten möchten, müssen sie mir eine IP oder ein Subnetz geben. Und dies ist selten ein sich bewegendes Ziel. Es ist also nicht so, dass Sie jeden Tag mit Hunderten von IP-Änderungsanforderungen überschwemmt werden: große Campus-Krankenhausnetzwerke, die ihre eigenen Netblocks mit Hunderten von Subnetzen und Tausenden und Abertausenden von Host-IPs besitzen, geben mir routinemäßig eine Handvoll IP-Adressen oder ein Subnetz, das ich erwarten sollte; Auch hier handelt es sich nicht um Laptop-Benutzer, die ständig auf dem Campus unterwegs sind. Warum sollte ich dann damit rechnen, UDP-Quellpakete von einer sich ständig ändernden IP-Adresse zu sehen? Klar, ich gehe davon aus, dass es sich um eine Vermutung handelt, aber ich wette, es ist nicht so viel, wie Sie für <100s Geräte denken. Ja, es wird eine lange ACL sein, und ja,

Wenn die Kommunikationskanäle aus irgendeinem Grund nicht offen sind (oder wenn jemand zu ängstlich ist oder nicht die Mühe hat, diese alten Gerätebesitzer zu kontaktieren und dies ordnungsgemäß zu tun), müssen Sie eine Baseline für die normale Nutzung / Aktivität erstellen, damit Sie formulieren können eine andere Strategie, die Ihre Teilnahme an DNS-Verstärkungsangriffen unterstützt (aber nicht verhindert).

Ein Langzeitbetrieb tcpdumpsollte das Filtern von eingehendem UDP 53 und das ausführliche Protokollieren in der DNS-Serveranwendung funktionieren. Ich möchte auch anfangen, Quell-IP-Adressen / Netblocks / GeoIP-Informationen zu sammeln (sind alle Ihre Kunden in den USA? Blockieren Sie alles andere), da Sie, wie Sie sagen, keine neuen Geräte hinzufügen , sondern lediglich ein Vermächtnis bereitstellen Service für bestehende Anlagen.

Dies hilft Ihnen auch zu verstehen, welche Datensatztypen angefordert werden und für welche Domänen, von wem und wie oft : Damit die DNS-Verstärkung wie beabsichtigt funktioniert, muss der Angreifer in der Lage sein, einen großen Datensatztyp (1) an a anzufordern funktionierende Domäne (2).

1. "Large Record Type": Brauchen Ihre Geräte überhaupt TXT- oder SOA-Einträge, um von Ihrem rekursiven DNS-Server aufgelöst zu werden? Möglicherweise können Sie angeben, welche Datensatztypen auf Ihrem DNS-Server gültig sind. Ich glaube, dass es mit BIND und vielleicht Windows DNS möglich ist, aber Sie müssten etwas graben. Wenn Ihr DNS-Server auf SERVFAILTXT- oder SOA-Einträge antwortet , ist diese Antwort mindestens eine Größenordnung (oder zwei) kleiner als die beabsichtigte Nutzlast. Offensichtlich sind Sie immer noch "Teil des Problems", weil das gefälschte Opfer immer noch diese SERVFAILAntworten von Ihrem Server erhält, aber zumindest hämmern Sie sie nicht, und vielleicht wird Ihr DNS-Server von der (den) geernteten Liste (n) "gelöscht". Die Bots nutzen im Laufe der Zeit, um nicht "zusammenzuarbeiten".

2. "funktionierende Domain": Möglicherweise können Sie nur gültige Domains auf die Whitelist setzen. Ich mache dies auf meinen gehärteten Rechenzentrums-Setups, auf denen die Server nur Windows Update, Symantec usw. benötigen, um zu funktionieren. Sie verringern jedoch nur den Schaden, den Sie zu diesem Zeitpunkt anrichten: Das Opfer würde weiterhin mit Ihrem Server bombardiert NXDOMAINoder SERVFAILvon diesem geantwortet, da Ihr Server weiterhin auf die gefälschte Quell-IP reagiert. Auch hier kann das Bot-Skript die Liste der geöffneten Server basierend auf den Ergebnissen automatisch aktualisieren, sodass der Server möglicherweise entfernt wird.

Ich würde auch eine Form der Ratenbeschränkung verwenden, wie andere vorgeschlagen haben, entweder auf Anwendungsebene (dh Nachrichtengröße, Anforderungen pro Clientbeschränkungen) oder auf Firewall-Ebene (siehe die anderen Antworten), aber Sie werden es wieder tun Sie müssen einige Analysen durchführen, um sicherzustellen, dass Sie keinen legitimen Datenverkehr beenden.

Ein Intrusion Detection System, das optimiert und / oder geschult wurde (hier ist wiederum eine Basis erforderlich), sollte in der Lage sein, abnormalen Datenverkehr im Zeitverlauf auch nach Quelle oder Volumen zu erkennen, würde jedoch wahrscheinlich regelmäßig Babysitting / Optimierung / Überwachung durchführen, um Fehlalarme zu vermeiden / oder sehen, ob es tatsächlich Angriffe verhindert.

Letztendlich muss man sich fragen, ob sich all dieser Aufwand lohnt oder ob man nur darauf bestehen sollte, dass das Richtige getan wird und das Problem dadurch überhaupt beseitigt wird.

Dies hängt von der Art der Ratenbeschränkung ab, die Sie durchführen möchten.

Ratenbegrenzung mit iptablesist eigentlich eher für die Begrenzung eingehender Pakete gedacht, da Pakete bis zum Grenzwert dem Filter entsprechen und das angegebene Ziel angewendet haben (z ACCEPT. B. ). Vermutlich haben Sie ein nachfolgendes Ziel für DROPPakete, die vom Filter nicht gefunden wurden. Und obwohl iptableses ein QUEUEZiel hat, leitet es das Paket lediglich an den Benutzerbereich weiter, in dem Sie Ihre eigene Warteschlangenanwendung bereitstellen müssen. Sie können auch die Rate für ausgehende Pakete begrenzen, aber nur wenige Personen möchten wirklich anfangen, ausgehenden Datenverkehr zu löschen.

iptables Senkung des Ratenlimits:

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

Wenn Sie hashlimitanstatt verwenden limit, erhalten Sie eine Begrenzung der Rate pro Ziel-IP. Dh fünf Pakete bis 8.8.8.8, die das Limit erreicht haben, verhindern, dass Pakete bis 8.8.4.4 gesendet werden. hashlimitWenn 8.8.8.8 jedoch maximal ist, können Sie immer noch 8.8.4.4 erreichen, was eher so klingt, wie Sie es möchten.

Wenn Sie nicht möchten, dass Pakete über das Limit hinaus verworfen werden, ist das, was Sie wirklich wollen tc. tcreguliert die Strömung, um einen schönen gleichmäßigen Strom zu erhalten, anstatt viel Verkehr zu haben. Auf der eingehenden Seite werden Pakete langsamer an die Anwendung übermittelt, aber alle kommen in der richtigen Reihenfolge an. Bei ausgehenden Paketen wird Ihre Anwendung so schnell wie möglich verlassen, aber in einem konsistenten Datenstrom auf die Leitung gelegt.

Ich habe nicht tcviel verwendet, aber hier ist ein Beispiel für ICMP zur Geschwindigkeitsbegrenzung, das Sie wahrscheinlich problemlos für DNS anpassen können.

Hier ist eine Sache, die Sie tun können, um Antworten auf gefälschte Abfragen potenziell zu mildern, die jedoch einige Arbeit erfordert:

Sehen Sie sich zunächst Ihr Protokoll des Sicherheitskanals an und suchen Sie eine IP-Adresse, die gefälscht wird.

Führen Sie dann einen tcpdump mit dieser Quell-IP (10.11.12.13) wie folgt aus:

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

Sie werden so etwas bekommen:

18: 37: 25.969485 IP (tos 0x0, ttl 52, id 46403, Offset 0, Flags [none], Proto: UDP (17), Länge: 45) 10.11.12.13.51169> 01.02.03.04.domain: 4215+ ANY ? . (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 ..............

Nun der lustige Teil! Öffnen Sie rfc1035 unter http://tools.ietf.org/html/rfc1035 und fahren Sie mit Abschnitt 4.1.1 fort.

Es ist Zeit, die Ergebnisse des tcpdump zu übersetzen und ein Muster zu finden, mit dem wir einen Filter auf Paketebene erstellen können.

Die ID des Headers beginnt bei 0x1C. Wir haben also einige Flags bei 0x1E, den QDCOUNT bei 0x20, den ANCOUNT bei 0x22, den NSCOUNT bei 0x24 und den ARCOUNT bei 0x26.

Damit bleibt die eigentliche Frage bei 0x28, in diesem Fall null (ROOT) für den NAME, 0xFF für QTYPE = ANY und 0x01 für QCLASS = IN.

Um es kurz zu machen, ich habe festgestellt, dass das Hinzufügen der folgenden iptables-Regelblöcke über 95% der gefälschten Abfragen blockiert, die ANY Records IN ROOT anfordern:

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

Ihre Laufleistung kann variieren ... hoffe, das hilft.

Verwenden tcund Disziplinen in Linux für Outbound - Port 53 UDP Warteschlangen:

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

discRichten Sie für jedes Paket mit der Firewall-Markierung "1" eine Beschränkung auf 10 MBit ein. Firewall-Markierungen sind nur firewallintern und ändern das Paket nicht. Nur die Handhabung des Pakets durch die Warteschlangendisziplin. So erstellen Sie iptablesdie Firewall-Markierungen:

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

Ändern Sie nach Ihren Wünschen, um vertrauenswürdige Subnetze und / oder Ziele auszuschließen. Das -o eth0beschränkt die Formgebung nur auf ausgehende Pakete. Hoffe das hilft.

Ich würde versuchen, eine Liste aller Clients zu erstellen, die auf Ihren externen rekursiven Resolvern basieren. Beginnen Sie mit einem Tag oder so mit Paketverfolgungen auf den DNS-Boxen. Beginnen Sie von dort aus mit der Erstellung von iptables-Regeln, um den von Ihnen erkannten und autorisierten Datenverkehr zuzulassen. Die Standardeinstellung wird schließlich darin bestehen, den Datenverkehr auf 53 / tcp und 53 / udp zu reduzieren. Wenn dies gegen etwas verstößt, passen Sie Ihre Regeln genau an.

Abhängig von der Netzwerkposition, in der Sie sich befinden (mit mehreren BGP-Feeds oder am Ende des Internets - als Stub-Netzwerk), können Sie so etwas wie URPF ausprobieren , um das Spoofing von Quelladressen zu verhindern.

andere Informationsquelle.

Stehen diese Geräte noch unter einem Supportvertrag? Wenn ja, wenden Sie sich an Ihre Kunden. Lassen Sie sie wissen, dass sich das Internet in den letzten zehn Jahren ein wenig weiterentwickelt hat. Um für diese Geräte weiterhin eine Namensauflösung bereitzustellen, müssen Sie die SRC-IP kennen, von der Abfragen zu erwarten sind. Legen Sie ein Datum von ~ 6 Monaten in der Zukunft fest, an dem Sie unbekannte Kunden nicht mehr bedienen können, und halten Sie sich daran. Dies ist in der Branche ziemlich verbreitet. Wenn diese Geräte nicht mehr unter einem Supportvertrag stehen ... klingt das nach einer Geschäftsentscheidung. Wie lange beabsichtigt Ihr Unternehmen, Ressourcen für alte Produkte aufzuwenden, die keine Einnahmen mehr generieren?

Sind diese Geräte so spezialisiert, dass Sie vernünftigerweise vorhersagen können, für welche Domänen legitime Abfragen zu erwarten sind? bind unterstützt Ansichten, erstellen Sie eine öffentliche Ansicht, die nur für diese Domänen eine Rekursion ausführt.

Nutzen Sie diese Gelegenheit zum Lernen, wenn Sie dies noch nicht getan haben, und stellen Sie die Veröffentlichung von Produkten ein, bei denen Sie keine Möglichkeit haben, Fehler zu beheben. Das ist was das ist, ein Bug. Eines, das dieses Gerät sicherlich früher oder später vorzeitig EOL wird.

Von Nanog irgendwo, dies:

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 

Das ist nicht ideal. Es ist möglicherweise besser, weniger Pakete pro Sekunde zuzulassen und einen höheren Burst zu haben.

Hier ist eine Lösung, die ich einige Male gegen DDOS-Angriffe verwendet habe. Sie ist nicht perfekt, hat mir aber geholfen. Die Lösung besteht aus einem Skript, das alle N Minuten (wie 1,2,3 usw. Minuten) vom Cron aufgerufen wird und IP-Adressen blockiert, die eine größere Anzahl von Verbindungen als die im Skript angegebene herstellen:

#!/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