Missbrauch für DDOS verhindern?

R

rootieX4

New Member
Hallo,
mir ist aufgefallen, das mein Server vermehrt anfragen von ripe.net und isc.org bekommt ~30/sec nach kurzem Googlen hat sich ergeben, das nicht nr ich das Problem habe, ich habe viele Scripts gefunden, die die Rate limitieren aber keines, das clienten komplett blockt, wenn sie zu viele anfragen versenden. Kennt jmd da ein Script oder ein Fail2Ban modul?
 
Wenn die Anfragen per Request beim Webserver einschlagen, kannst du Fail2Ban nutzten, einfach eine Datei aus /etc/fail2ban/filter.d/xxx.conf kopieren nach z.B. "myddos.conf", anpassen.
Dann in der jail.conf einen neuen Jail-Eintrag, wo du dann die Logs angibst und als Filter "myddos".

Im Regex, kannst du dann auf "ripe.net", "isc.org" usw. prüfen.
 
Wie wäre es denn einfach die Ursache zu beheben, statt die Symptome zu verstecken?
Dein Nameserver ist für World rekursiv konfiguriert und das wird gemäss Deinem Willen auch ordnungsgemäss genutzt.
 
In jedem fünften Thread wird den Leuten mittlerweile fail2ban als _die_ Allzweckwaffe vorgeschlagen. Find' ich toll.

Und bitte nicht die Abusemeldung vergessen. Kann ja nicht sein, dass diese bösen Spammer (RIPE & Co.) irgend wann das ganze Internet mit ihren Anfragen zuspammen. Scriptkiddies dieser Welt vereinigt euch! ;)
 
Hallo? Erde an Mitposter: Rekursive Auflösung für World deaktivieren ist die einzig richtige Lösung.
IPTables ist hier die dümmste und kontraproduktivste Lösung.

Wann begreift Ihr endlich, dass IPTables nicht zum Vertuschen falscher Konfigurationen gedacht ist?
 
Wenn der Server aber genau dafür da ist ist das keine Option ...
 
Das wird er im vorliegenden Fall wohl kaum sein, da sich der TE ja explizit über die erzeugte Last wundert.
 
cosimo said:
Wenn der Server aber genau dafür da ist ist das keine Option ...
Click to expand...

Wenn er das wäre, dann wüsste der Admin zum Einen (wie Marentis schon schrieb) welche Last zu erwarten gewesen wäre und zum Anderen wie er diese Art der Nutzung bei Bedarf unterbindet beziehungsweise limitiert.
Da er aber weder das Eine noch das Andere wusste und weiss, kann man bedenkenlos ein Jahresgehalt darauf verwetten, dass er einfach blind irgendein HowTo im Netz gefolgt ist oder ein unscheinbares Häkchen in seinem Adminpanel gesetzt hat.

Als Dienstleister für DNS solltest Du die entsprechende Erfahrung haben und mindestens genauso gut wissen wie Marentis oder ich wo der Fehler beim OP liegt.
 
Recursion ist aus:
Code: 
allow-transfer {"none";};
recursion no;
allow-recursion {"none";};
Aber trozdem Antwortet Bind9 auf Anfragen, die er ignorieren sollte.
Code: 
dig @server google.com A


; <<>> DiG 9.8.1-P1 <<>> @server google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10289
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.			IN	A

;; Query time: 35 msec
;; SERVER: server#53(server)
;; WHEN: Mon Jan 28 19:59:17 2013
;; MSG SIZE  rcvd: 2

Wie erreiche ich, das der Server Anfragen für die er nicht zuständig ist Ignoriert?
 
Warum läuft auf dem Server überhaupt ein DNS? Hat das einen spezifischen Grund bzw. brauchst du den überhaupt? Falls nein, dann deinstall den bitte einfach und dein Problem ist somit gelöst.

Falls du ihn brauchst, dann sag' uns bitte konkret wofür, dann können wir bei der Config ansetzen.
 
rootieX4 said:
Aber trozdem Antwortet Bind9 auf Anfragen, die er ignorieren sollte.
Code: 
status: REFUSED
Wie erreiche ich, das der Server Anfragen für die er nicht zuständig ist Ignoriert?
Click to expand...
Er hat die Anfrage doch ignoriert, also ist jetzt Alles OK.
 
rootieX4 said:
Code: 
;; WARNING: recursion requested but not available
Click to expand...
Ist doch alles bestens. Wenn auf einem Port keine Anwendung lauscht, wird auch nicht einfach ignoriert - man erhält ein "Connection refused". Es sei denn, man macht gemäß üblicher "Absicherungstutorials" einfach mal alles mit iptables komplett dicht. Und da gilt:

Joe User said:
Wann begreift Ihr endlich, dass IPTables nicht zum Vertuschen falscher Konfigurationen gedacht ist?
Click to expand...
;)
 
Das einzige Restrisiko des DNS ist nun Amplification oder zumindest Proxying; also dass ein Angreifer mit gefälschtem (spoofed) Absender, nämlich dem Angriffsziel, Anfragen an jede Menge DNS-Server schickt welche wiederum deren Antwort an das eigentliche Ziel leiten.

Wirklich blockierbar ist dies nicht, allerdings versuchen fast alle Angreifer generische DNS-Auflösungen welche durch Rekursionsverbot nicht klappen, somit kann da fail2ban greifen um das Ziel per iptables zu sperren und somit den Relay zu verhindern.
(Ja, für solche Sachen ist iptables tatsächlich geeignet =D )
 
Zwei Zeilen in der named.conf sind da erheblich sinnvoller:
Code: 
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };

Wer öffentliche Nameserver betreiben will, der muss ganz genau wissen, was er tut! DNS ist kein Spielzeug!


Mir schweben gerade noch deutlichere Worte durch den Kopf, welche aber gegen die Nutzungsbedingungen und gegen die gute Erziehung verstossen, daher etwas harmloser formuliert:
Wer nicht-Experten direkt oder indirekt empfiehlt einen öffentlichen Nameserver zu betreiben, der gehört auf Lebenszeit aus dem Netz geworfen...


So, und nun geh ich mich abregen -- EOD, bitte, danke.
 
Wer öffentliche Nameserver betreiben will, der muss ganz genau wissen, was er tut! DNS ist kein Spielzeug!
Click to expand...

Rekursion ist und war aus, desweiteren wird jeder der zuviel fragt per IPtables gesperrt.Was gibt es sonst noch zu beachten?
 
rootieX4 said:
Rekursion ist und war aus
Click to expand...
Wenn es deaktiviert war, dann wurden die Anfragen bereits ignoriert und somit bestand auch kein Problem (zumindest nicht beim Nameserver, sondern lediglich vor Deinem Monitor und da kommt dann wieder "Denn sie wissen nicht, was sie tun" ins Spiel).
Warum betreibst Du überhaupt einen öffentlichen Nameserver, wenn Du keine Ahnung davon hast?
 
You must log in or register to reply here.
Back
Top