[mit r1855 erledigt] Brute-Force-Attack auf dropbear begrenzen

[xsapling]

ich habe eine Nachfrage zu dem dropbear-Patch.
Anbei einmal die Grafik zur Auslastung meiner Box. Zu dem Zeitraum, in dem die Auslastung andauernd sehr hoch ist, finden sich im syslog folgende Informationen en masse:

Jun 27 03:17:01 fritz cron.err crond[1004]: USER root pid 24347 cmd telnet localhost:25
Jun 27 03:17:05 fritz authpriv.warn dropbear[24349]: login attempt for nonexistent user from 125.69.132.104:59134
Jun 27 03:17:06 fritz authpriv.info dropbear[24349]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:59134
Jun 27 03:17:09 fritz authpriv.warn dropbear[24350]: login attempt for nonexistent user from 125.69.132.104:60812
Jun 27 03:17:10 fritz authpriv.info dropbear[24350]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:60812
Jun 27 03:17:14 fritz authpriv.warn dropbear[24351]: login attempt for nonexistent user from 125.69.132.104:33996
Jun 27 03:17:14 fritz authpriv.info dropbear[24351]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:33996
Jun 27 03:17:18 fritz authpriv.warn dropbear[24366]: login attempt for nonexistent user from 125.69.132.104:35813
Jun 27 03:17:19 fritz authpriv.info dropbear[24366]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:35813
Jun 27 03:17:22 fritz authpriv.warn dropbear[24368]: login attempt for nonexistent user from 125.69.132.104:38033
Jun 27 03:17:23 fritz authpriv.info dropbear[24368]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:38033
Jun 27 03:17:27 fritz authpriv.warn dropbear[24369]: login attempt for nonexistent user from 125.69.132.104:40101
Jun 27 03:17:27 fritz authpriv.info dropbear[24369]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:40101
Jun 27 03:17:33 fritz authpriv.warn dropbear[24370]: login attempt for nonexistent user from 125.69.132.104:42306
Jun 27 03:17:33 fritz authpriv.info dropbear[24370]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:42306
Jun 27 03:17:37 fritz authpriv.warn dropbear[24371]: login attempt for nonexistent user from 125.69.132.104:44904
Jun 27 03:17:38 fritz authpriv.info dropbear[24371]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:44904
Jun 27 03:17:41 fritz authpriv.warn dropbear[24372]: login attempt for nonexistent user from 125.69.132.104:46914
Jun 27 03:17:42 fritz authpriv.info dropbear[24372]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:46914
Jun 27 03:17:46 fritz authpriv.warn dropbear[24373]: login attempt for nonexistent user from 125.69.132.104:49063
Jun 27 03:17:46 fritz authpriv.info dropbear[24373]: exit before auth: Max auth tries reached - user 'is invalid' from 125.69.132.104:49063

.

Meine Frage dazu ist, ob der Patch eine solche Auslastung während eines Angriffs auf dropbear nicht verhindern sollte?

 

[hermann72pb]

Wenn du oben unsere Diskussion aufmerksam ließt, wirst du feststellen, dass dieser Patch es nicht komplett verhindern kann. Ich hab dasselbe in meinem LOG stehen, weil ich aus unterschiedlichen Gründen mich nicht vom Port 22 verabschieden kann (hauptsächlich faul). Das blebt mit busybox die einzige effektive Methode.

Der oben genannte Patch ist meine Art der "tuning" von dropbear-Parameter in Richtung Einschränkung der Wartezeiten und Wiederholversuche auf Minimum.

Übrigens "Max auth tries reached" spricht eigentlich dafür, dass die besagten Einschränkungen eingreifen. Der Angreifer wird also vom dropbear aus "rausgeschmießen" und muss sich neu anmelden.

Wenn du es ausprobieren willst, versuch dich per PUTTY selbst anzumelden. Du wirst sehr schnell feststellen, dass du relativ schnell "rausgeschmießen" wirst, wenn du dich vertippst (weniger Versuche zugelassen), wenn du zu lange Verbindung offen hältst und keinen Usernamen oder Pass antippst (30 sek. gegen 5 min früher) oder wenn du mehrere Verbindungen parallel aufbaust (deutlich weniger als früher). Mehr kann man durch die dropbear-Parameter nicht erreichen. Bei 7050 hat es meiner subjektiven Meinung nach dazu geführt, dass die Box die Attacken wenigstens überleben konnte und sich nicht mehr aufhing.

MfG

 

[cuma]

xsapling, das hängt auch von deinen verwendeten Paketen ab, was man ohne SIgnatir so aber nicht erkennen kann. Wie bist du es denn fast 500 Beiträge ohne ausgekommen?

 

[Silent-Tears]

Wie bist du es denn fast 500 Beiträge ohne ausgekommen?

Nur mit Verwarnungen

Ansonsten liegt die CPU-Auslastung bei"horrenden" 20%, wenn ich deine Grafik richtig deute. Die Abwehr verschieder Login-Versuche belastet das System wohl eher max 20%, und der Wert ist in Ordnung. Was denn die Gesamtauslastung des Systems angeht: Bedenke bitte, an welch System du die Werte ausliest. Es ist und bleibt eine Fritz, und kein Quadcore Dualcpu-System oder ähnliche Dingr.

 

[cuma]

Also ich vermute den internet super-daemon...

 

[full2000]

Wo steht eigentlich diese LOG-Datei? Ich dachte eigentlich immer, das man sowas unter /var/log findet, aber da steht leider (oder zum Glück?) nichts. Muss man dropbear mit einem anderen Parameter starten, um diese LOG-Datei zu bekommen?

 

[hermann72pb]

Du solltest schon syslog-Paket installiert haben, damit du es bequem per GUI usw. anschauen kannst. Ich weiß es nicht, ob es auch irgendwie ohne syslogd ginge. Es könnte gut möglich sein, dass man dropbear mit einem speziellen Parameter starten könnte, dass es extra irgendwo gelogt wird. Es könnte auch sein, dass man dropbear dafür extra umkonfigurieren und neu kompilieren muss.

MfG

 

[ao]

Gibt es eigentlich eine Möglichkeit, den Output des syslogd im WebGUI nach den verursachenden Prozessen zu filtern? So könnte man z.B. nur den Output von dropbear anzeigen lassen, was zu mehr Übersicht führt. Klar, es geht auch im Terminal mittels grep, tail & Co.

 

[Silent-Tears]

Nein, gibt es (aktuell) nicht. Es sei denn, du mienst du rudi-shell, dann nämlich kannst du beinahe alles tun, was die Konsole so hergibt

 

[hermann72pb]

Wo wir hier sowieso beim Thema sind. Es wäre sinnvoll in Freetz generell eine einheitliche logging-Strategie zu überlegen. Ich wäre dafür, dass alle Pakete (soweit möglich) erstmal in eigene Logdateien loggen. Ich hatte sowas z.B. mit downloader gemacht. Somit könnte man das schon mal ausspalten.
Der Rest wird sowieso in der standard-Logdatei landen. Dafür könnte man im syslog-Paket eine Filterfunktion einführen.

MfG

 

[ao]

Das würde ich auch sehr begrüßen, da es das Fehlerauffinden leichter macht.
Oder spricht evtl. etwas dagegen, was mir bisher noch nicht klar geworden ist?