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

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,724
Punkte für Reaktionen
16
Punkte
38
Hallo zusammen,

vor einiger Zeit hat einer hier über Brute-Force-Attacken auf seine Box berichtet. Ich hatte zunächst daran nicht geglaubt, bis ich die Tage in die Logdateien meiner vielen Fritz!Boxen reingeschaut hatte. Und ... richtig gestaunt. Der arme Dropbear hat viel zu kämpfen!

Ich weiß nicht, wie die Angreifer auf die dynamischen IP-s kommen. Ob da dyndns geknackt wurde und die Namen bekannt sind, oder ob die IPs einfach Reihe nach getestet werden, egal wie, aber ES WIRD BRUTAL attakiert und man muss was dagegen unternehmen, eher es zu spät wird.

Warum sollte man es machen? Es wurde hier berichtet, und ich vermute es inzwischen auch, dass die "kleinen" Boxen (wie z.B. 7050) bei solchen Attacken sich aufhängen, weil sie solchen "Lasten" nicht gewachsen sind. Also es genügt nicht, einfach sichere Passwörter zu wählen. Die Box wird zwar nicht geknackt, aber sicher zum Aufhängen getrieben.

Was könnte man dagegen machen?
1. Port 22 verlegen. Ist nur eine temporäre Lösung.
2. Dropbear modifizieren.
3. Irgendein anderes Tool auf die Box zu bringen, welches Attacken erkennt und abblockt.

Da ich mich mit 2 und 3 noch nicht auskenne, eröffne ich hiermit die Diskussion hier und bitte um machbare Vorschläge.

Ich spekuliere ein bisschen:

a) Man könnte versuche loggen und die gleiche IP nach 3 Versuchen für 30 Minuten sperren
b) Man könnte parallele Anmeldungen per see verbieten oder begrenzen (normalerweise reicht ja eine oder höchstens zwei)

Die Frage ist, wie kann man es machen.

------------------------------------------------------------------------------

Edit vom 10.02.2008: Nun bin ich etwas schlauer geworden und poste hier den patch für dropbear. Dieser patch gehört in make/dropbear/patches und wird beim "make" an dropbear automatisch angewandt. Nicht vergessen dropbear vorher "cleanen", falls schon kompiliert.

Es bewirkt Veränderung folgender Werte:
Offene Anmeldungen von gleicher IP: 2 anstatt 5
Offene Anmeldungen von unterschiedlichen IPs: 5 anstatt 30
Fehlversuche bei Passwort-Eingabe: 2 anstatt 10
Timeout für die Anmeldung: 30 sec. anstatt 5 min

Bevor jeder hier anfängt sich zu äußern, wie man die Variable X noch mal erhöhen / verkleinern kann, bitte erstmal diese Einstellungen testen. Für 99% der Fälle werden sie ausreichen. Es werden keine weiteren Umkonfigurationen notwendig sein. Nur wenn jemand mit diesen Einstellungen reelle (und keine virtuellen) Probleme bekommen hat, sollte er sich hier melden. Weitere Vorschläge werden auch angenommen.

MfG
 

Anhänge

  • 250-login-limits.patch.bz2
    606 Bytes · Aufrufe: 17
Zuletzt bearbeitet:
1. Port 22 verlegen. Ist nur eine temporäre Lösung.

Warum nur temporäre Lösung?
mach ich grundsätzlich so.... ist das einfachste und sehr effektiv

Deinen Ansatz a) gibts zumindest für "Große" Server und nennt sich da fail2ban http://www.fail2ban.org
Allerdings setzt sowas ne funktionierende Firewall voraus, denn wie will man das sonst machen? irgendwie müssen IPs ja gesperrt werden...
 
Die Anschlußnummer von 22 auf einen anderen Wert zu legen, halte ich auch für eine gute Maßnahme. Allerdings dürfte das nicht ausreichen.

Ich finde, man sollte eigentlich alle Serverdienste, besonders im Zusammenhang mit der Übermittlung und Auswertung von Anmeldedaten, mit der Möglichkeit einer regelmäßigen zeitlichen Verzögerung auszustatten.

Der Administrator kann dann einstellen, daß bei jedem Anmeldeversuch (z.B. über Ssh) eine zeitliche Verzögerung von, sagen wir, zwei Sekunden eingebaut wird. Das macht im Einzelfall wenig aus, vereitelt aber jede Brechstangenattacke erfolgreich. Im genannten Fall könnte jemand pro Minute allerhöchtstens dreißig Anmeldedatensätze durchprobieren lassen. Ein aussichtloses Unterfangen!
 
Meine Vorschläge:
1) Anderer Port
2) Per IP-Tables mit dem "limit" modul die Anzahl von zugriffen per Zeitraum begrenzen
3) Knock-Daemon
Ich selbst benutze 3 (nicht nur für ssh)
 
ich selber habe kein dropbear, aber ein Kumpel von mir nützt es immer (wieso fragt mich BITTE BITTE nicht!!!)

Und er erlebt sowas auch tagtäglich... da kann ich mir vorstellen bei einer 7170 wenn filesharing (torrent), Voip, Samba, FTP und noch so zeugs laufen das die schonmal richtig an die grenze genommen wird... bei älteren boxen will ich garnicht erst denken was für ein Ausmas das hätte... eine Sicherheitslücke, die brandheiß ist, muss gestopft werden.

Eine temporöre portweiterleitung ggf mit zeitverzögerung würde der fritz nicht viel bringen. Es gibt zu viele noobies die einfache passwörter nehmen! :rolleyes:

Ich denke mal es müsste irgendwie möglich sein, das mann einen ip bann wegen "login errors" ausgeben kann!

Also das ist echt zum verzweifeln!

Und als zusätzliche anmerkung ist, das er auch kein dyndns benützt!!! Es muss also Bruten der IPs paralell mit logins sein. Es reicht schon die loginerrors zu begrenzen.
 
Ich würde auch einen anderen Port empfehlen. Eine anderen Port ein einzige Maßnahme zur Sicherheit würde ich nicht empfehlen. Aber ein anderer Port, um nicht bei wahllosen Scans gefunden zu werden, ist doch sinnvoll. Es gibt insgesamt 4 Milliarden IP-Adressen, da ist es schon mühsam, die alle zu durchsuchen. Da wird so schnell keiner noch alle Ports versuchen, das würde noch viel länger dauern und wenig Erfolg bringen. Ziel sind doch vermutlich irgendwelche Rechner mit Standard-Paßwörtern. Und wer macht sich die Mühe, einen anderen Port zu nehmen und läßt dan Standard-Paßwörter drin?

Vermutlich hat es nichts mit dyndns zu tun, sondern es werden einfach IP-Adressen durchgescannt. Ich habe kein DynDNS, und trotzdem kommen Verbindungs-Versuche auf Port 22 herein.
 
Ich habe kein DynDNS, und trotzdem kommen Verbindungsversuche auf Port 22 herein.
Ja, das bin ich ... :mrgreen: 8) :mrgreen:

Es gibt zu viele Noobies, die einfache Paßwörter nehmen!
Das gilt es auch zu unterbinden (schwierig, ich weiß), denn sonst kann man die Türe gleich offen lassen ... ;)
 
Hallo,

Port 22 zu verschieben ist ein extrem effizientes Mittel, vor allem auf der Fritzbox. Denn die hat den einen Schutzmechanismus gegen Portscans drin, versucht es mal mit NMAP (oder so einem Online Port Scanner). Sobald von einer IP eine gewisse Anzahl Ports innerhalb kurzer Zeit angeknockt werden, meldet die Box grundsätzlich "BLOCKED" - auch, wenn der Port definitiv freigegeben ist (und ein Server dahinter lauscht). Ein Portscan über einen größeren Bereich bringt auf der Box also nichts, nur das anknocken einiger dedizierter Well Known Ports ist möglich. Dazu scheint SSH zu gehören, wie die Attacken zeigen. Ich habe Ruhe im Log, seit ich den Port verlegt habe.

Übrigens scheinen solche Attacken tatsächlich ganze IP-Bereiche abzuscannen. Im Rahmen der 15-Minuten-Idle-Timeout Diskussion im T-Home Backbone hab ich Paketmitschnitte von diversen Anschlüssen gesehen. In Subnetzen, die erst seit kurzem von der Bogus Liste der IANA weg an Provider verteilt worden sind (77er IPs von 1&1, 79er und 91er IPs der T-Com), ist diesbezüglich relativ wenig los. In Subnetzen, die schon lange aktiv sind (80er, 84er und 217er IPs der T-Com) trifft im Mittel alle 90 Sekunden (!) ein unerwünschtes Paket auf den WAN Port - wohlgemerkt eines, das kein Resultat einer aktiven Verbindung der Box-Clients ist, also Viren/Trojaner, SPAM für den MSN Messenger oder auch Port-Scans. Auch bei Anschlüssen ohne aktiven dyndns Account.
 
Diese Angriffe auf SSH-Ports sind schon seit Jahren weit verbreitet. Daß dabei innerhalb kurzer Zeit riesigie IP-Bereiche abgescannt werden können, ist klar - wenn der Port geschlossen ist, sucht man ja einfach weiter. Richtige 'Brute-Force'-Angriffe sind das allerdings meiner Erfahrung nach nicht - meist wird nur ein ganzer Haufen von (meist englischen) Standardaccounts mit Standardpasswörtern durchprobiert.

'Unerwünschte' Pakete sind aber natürlich (gerade in dynamisch vergebenen IP-Bereichen) meist keine Angriffe, sondern Pakete, die eigentlich den Rechner erreichen sollten, der zuvor (irgendwann einmal) die Adresse inne hatte (z.B. von Filesharingclients).
 
warum deaktiviert ihr nicht die Passwort-authentifizierung und lasst die Autorization auschließlich über einen schön langen Schlüssel laufen?
 
Weil es hier nicht primär um die Sicherheit geht, sondern darum, dass solche Angriffe eine hohe Last auf der Box verursachen.

MfG Oliver
 
Was xsampling schreibt ist der beste Weg. Man sollte sowieso immer mit keys arbeiten.
Aber das Lastproblem ist natürlich ein Thema.
 
Wie wäre es in die Box (ssh) ein Mechanismus einzubauen sobald mehre Protscanns auf ein bestimmten Port passiert und versucht gewisse Attacken geschehen bzw. mehre Anmelde versuche per root die Box sich aus den Internet trennt für so etwa 1-3 min und sich dann wieder mit eine neue IP im Netz anmeldet. So hat man ein kleine Schutz vor scanns und so. Ich kann mir nicht vorstellen das der Angreifer jede Dyn IP weis beziehungsweise den Namen.

Knock wäre auch noch eine alternative.
 
@oli

wieso wird wegen brutforce bei dropbear erhebliche Last erzeugt, sofern die Passwort-Methode deaktiviert ist?
Bei mir verhält sich dropbear bei ausgeschalteter Passwort-Methode so, dass dieser gleich meldet keine unterstütze Authentifizierungsmethode anzubieten, wenn nicht gleich ein Schlüssel mitgeliefert wird. Und sofort ist Verbindung beendet und ein Passwortvergleich findet auch nicht statt. Sollte das den dropbear nicht erheblich minder belasten, als bei aktivierter Passwort-Methode, bei welchem dropbear das Spiel bei brutoforce erstmal mitspielt?
 
Die hohe Last wird duch Aufbau einer verschlüsselten Verbindung erzeugt. Dies geschieht _bevor_ Passwort/Key ausgetauscht wird.
Ich empfehle Post #4 dieses Treads, Dann hat braucht man keine kopfschmerzen zu haben
 
ich habe von Minderlast gesprochen und nicht von einer Nichtlast ...
 
Meine Vorschläge:
1) Anderer Port
2) Per IP-Tables mit dem "limit" modul die Anzahl von zugriffen per Zeitraum begrenzen
3) Knock-Daemon
Ich selbst benutze 3 (nicht nur für ssh)
Interessant, auch dieser Thread hier.
Ist denn die manuelle Änderung der daemons mit der aktuellen Freetz-FW noch nötig

@cuma: Hast Du das denn schon am Laufen? Hast Du damit das Brute Force Attacken-Problem gelöst?
 
Für knockd hatte ich eine gute Anleitung gefunden [1]. Zufälligerweise gerade für SSH-Port.
Allerdings sehe ich diese Methode als etwas aufwendig, denn
1. IPTABLES läuft auf der Box noch nicht 100% und keiner nimmt sich es sich vor (ja, ich weiß, ohne contrac usw. läuft es halbwegs...)
2. IPTABLES+KNOCKD für kleine Boxen ist keine gute Idee
3. Ich hab mich zwar in knock nicht detailiert eingelesen, ich verstehe es aber so, dass man dafür einen speziellen Client braucht. Also wiederum kompliziert auf der Clientseite...

Ich nutze nämlich momentan PUTTY, damit ich von überall (auch von fremden Rechnern) einen Zugriff auf die Boxen bekomme. Das Gute an PUTTY: Es läuft auf dem Stick und unterstützt Porttunneling. Also, Verbindung aufgebaut, "localhost" angetippt und schon ist man auf der Box.

Mit Port verlegen ist so eine Sache. Wohin denn? Dann versperre ich mich selbst, denn einige Firewalls von denen ich rausgehe haben eine sehr begrenzte Anzahl der nach Außen geöffneten Ports. Man kannn natürlich SMTP, POP und co. nehmen, aber ob es gut ist.

Zur Antwort "das ist von großen Linuxsystemen bekannt": Ja darauf will ich hinaus. Es ist bei den Servern üblich, die Ports zu sperren oder Loginversuche zu begrenzen. Mir ging es beim Eröffnung dieses Threads darum eine relativ einfache (außer Port verlegen) Möglichkeit zu finden, die Box zu schützen.

Was ist z.B. mit dropbear? Gibt es da nicht irgendeine Funktion, die mein reinkompilieren / reinkonfigurieren kann? Ich kenne mich damit nicht aus, deswegen frage ich so blöd. Oder muss es auf einer früheren Ebene gescheen, bevor dropbear überhaupt eine zusätzliche Instanz startet?

MfG
 
Musst Du Deinen SSH-Port nicht sowieso von 22 auf 443 ändern, wenn Du Putty verwendest? Es gibt doch etliche Proxies/Firewalls, die nur 443 (für https) offen haben, nicht aber 22.
Vielleicht muss man das Ganze auch tatsächlich unterschiedlich angehen, je nachdem, welche HW man hat. Auf einer 7170 sollten iptables (so sie denn laufen) und knockd wohl keine Probleme machen. Auf der 7050 wohl auch nicht, so dass man auf diesen Boxen das so einrichten könnte.
Auf "kleineren" Geräten müsste man es halt etwas anders machen.

OT:
Kannst Du hier (oder da OT evtl. per PN) mir mitteilen, wie Du Putty genau einstellst, um einen verschlüsselten und gesicherten Zugang von extern auf Deine Box zu bekommen, wie Du das testest und welches Ports etc. einzustellen sind (inkl. evtl. Portforwarding bzw. VirtualIP auf der Box)?
Vielen Dank!
 

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.