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

[hermann72pb]

Ich glaube nicht, dass es weit OT wird. Daher hier die Vorgehensweise:
1. PUTTY auf einem Port laufen lassen. Unter Einstellungen kann man es verstellen. Wahrscheinlich wäre hier sinnvoll anderes, als 22 zu nehmen. Aber ich bleibe in meinem Besipiel bei 22
2. ar7.cfg editieren (Regel hinfügen)

tcp 0.0.0.0:22 0.0.0.0:22

3. Ein dyndns-Account (oder ähnliches) zulegen und in den AVM-Einstellunge eintragen
4. evtl. die Box neu starten oder irgendwie anders dafür sorgen, dass die ar7.cfg-Regeln wirken und die Box sich bei dyndns registriert hat.

Nun ist die Box von außen erreichbar. Auf jedem beliebigen PC Putty starten (geht auch vom stick und wenn man U3 hat, sind auch die Einstellungen dabei).

5. Putty starten und dort eine neue Verbindung einrichten. Z.B. für meinebox.dyndns.org, abspeichern.
6. In Tunnel-Einstellungen gehen und wie im Bild einrichten. Ich hatte extra da nochmals in die Felder eingetragen, wie man es macht.
7. Wieder zu den Sessions wechseln und auf "save" drücken, damit die Tunnels mitgespeichert werden.
8. Eingerichtete Verbindung öffnen, sich mit PASS anmelden.
9. Einen Browser starten (egal welchen) und localhost:80 oder localhost:81 in die Adressenzeile antippen. Und schon ist man auf der Box per remote.

So ist ungefähr die Vorgehensweise. Wie gesagt, wenn man PUTTY auf dem Stick hat, muss man nur die zuvor eingerichtete Verbindung öffnen, passwort angeben und schon ist die gesicherte Verbindung da.

MfG

 

[RalfFriedl]

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.

Das hat weder mit dropbear noch mit Putty zu tun, sondern nur mit dem Proxy/Firewall, hinter dem sich der Client befindet. Es kommt also auf den Einzelfall an, ob dies notwendig ist.

 

[cuma]

Für knockd ist conntrack nicht notwendig und nur dieses verursacht Abstürze. Als "knockd-client" kannst du auch telnet nutzen, um an ein Port anzuklopfen. Es geht nur um die SYN Pakete

 

[ao]

Super, vielen Dank Euch allen!

Und wieder on-topic...

 

[hermann72pb]

Ich hab mich etwas eingelesen. Angeblich kann dropbear doch die nichtauthorisierte Verbindungen limitieren [1]. Zwar wird bei zitiertem Problem etwas anderes besprochen, nämlich, wie man authorisierte offene Verbindungen limitiert. Und dies scheint etwas problematisch zu sein. Nicht authentifizierte konnte man aber angeblich schon immer limitieren. Ich mache mich nun schlau und schaue, was bei uns in dieser header-Datei steht.

Oder sieht ihr Probleme an dieser Lösung? Hat jemand eine Idee, wie ich eine Attacke simulieren kann?

MfG

Edit: in options.h habe ich Folgendes gefunden:

/* Specify the number of clients we will allow to be connected but
 * not yet authenticated. After this limit, connections are rejected */
/* The first setting is per-IP, to avoid denial of service */
#ifndef MAX_UNAUTH_PER_IP
#define MAX_UNAUTH_PER_IP 5
#endif

/* And then a global limit to avoid chewing memory if connections 
 * come from many IPs */
#ifndef MAX_UNAUTH_CLIENTS
#define MAX_UNAUTH_CLIENTS 30
#endif

/* Maximum number of failed authentication tries (server option) */
#ifndef MAX_AUTH_TRIES
#define MAX_AUTH_TRIES 10
#endif

Es scheinen aber (zumindest für mich) irgendwelche default-Spezifikationen zu sein. Ich suche mal weiter, ob es noch eine Config gibts...
Verstehe ich richtig, dass in dieser Konfiguration 5 Fehlversuche von einer IP zugelassen werden und 30 insgesamt? Wo sollte man diese Werte reduzieren? In dieser header-Datei oder woanders?
Spricht was dagegen, die beiden Werte auf 2 runterzusetzen? Bei der Box braucht man doch nicht Tausende parallele connections.

 

[rdzj]

Ich starte dropbear (per calllog-skript) erst auf Anruf von meinem Handy auf eine bestimmte MSN. Brauche den ssh-Zugang aber auch nur selten.

 

[hermann72pb]

@rdzj: Ist sicherlich interessant, aber für mich und für einige hier zu aufwendig.
@all: Es scheinen tatsächlich 5 Verbindungen von der gleichen IP ohne AUTH zugelassen zu sein. Bei sechster Verbindung von extern bekomme ich:

slightly@StinkyLinux:~$ ssh meine.dyndns.org
ssh_exchange_identification: Connection closed by remote host

Und ps auf der Box zeigt auch brav:

  .....
  .....
  994 root       1144 S   dropbear -p 22
  ......
  ......
 1447 root       1192 S   dropbear -p 22
 1448 root       1192 S   dropbear -p 22
 1449 root       1196 S   dropbear -p 22
 1450 root       1196 S   dropbear -p 22
 1451 root       1196 S   dropbear -p 22
 1452 root       1200 S   dropbear -p 22
 .....
 .....

Also, genau diese 5 Verbindungen (994 scheint Elternprozess zu sein und 1452 war meine Verbindung von der internen IP). Merkwürdig ist noch eine Sache: es gibt kaum Timeout für die Passwortangabe, oder es ist irrelang. Sprich, man kann diese 5 Unterprozesse auf der Box von Extern auslösen und sie sehr lange "für sich" offen halten.
Für fehlerhafte Passwort-Logins gibt es 3 Versuche. Der Angreifer kann somit pro "Schuß" 5x3=15 Passwörter ausprobieren, bevor die Verbindung abgelehnt wird.
Meine Linuxgrundlagen reichen leider nicht dafür aus, um festzustellen, wieviel Speicher für ein dropbear jeweils benötigt wird. "free" hilft hier eher wenig. Für eure Anregungen bin ich offen. Es kann aber schon mal passieren, dass bei RAM-Mangel eine oder andere Box durch solche Attacke "abschmiert".

Ich frage nochmal: Spricht was dagegen, alle oben benannten Werte auf 2 runter zu setzen? Oder will jemand mit dem dropbear auf seiner Box Multiuser-MultiIP-SSH-Sessions veranstalten?

MfG

 

[SeeDyX]

Also die von PerIP würde ich auf 2 oder auf 1 runtersetzen, aber das globale Limit würde ich nicht auf den gelichen Wert, sondenr etwas höher setzen (doppelt bis 3-fach) sonst komst du während eines "angriffs" selber nicht auf die Box. Von verteilten IPs hab ich diese Art von wahllosen "angriffen" aber ncoh nciht gesehen

 

[matze1985]

Es sollte doch ok sein wenn man die Verbindungen von der gleichen IP ohne AUTH auf 2 begrennst, denn man selber wird sich ja wohl ziemlich schnell einloggen und auch nciht 5mal zur gliechen zeit an der PW-ABfrage stehen, oder?

 

[hermann72pb]

ok, gut dass ihr es auch so sieht. Ich hatte in der Nacht das Image bereits mit 2:2:2 für eine 7170 gebaut. Allerdings ist mir diese 7170 beim Remote-Update abgeschmiert. Gegen 3 Uhr Nachts wäre es relativ unhöflich von mir den Besitzer anzurufen und bitten den Stecker rauszuziehen, sodass ich es auf heute verschoben hatte. Die Box ist mittlerweile wieder da (der Besitzer ist wohl selber auf die Idee gekommen den Stecker zu ziehen), sodass ich gleich mein Image teste.

Wenn meine Tests positiv verlaufen, poste ich mein Patch hier und im Track (inkl. Ticket).
Wahrscheinlich hast du Recht, SeeDyX, man sollte sich selbst nicht aussperren. Ich erhöhe den zweiten Wert auf 5 (aber auf jeden Fall nicht auf 30) und dritten lasse ich so wie es ist. Mit diesen "tries" habe ich sowieso nicht verstanden, was dadrunter gemeint ist. Sollen es Fehlversuche sein? Aber sie sind eindeutig auf 3 begrenzt. Vielleicht wird es irgendwo anders überschrieben?

MfG

 

[cuma]

Also die Werte ganz runterzusetzen ist ja nicht die beste Lösung.
Angenommen, ich hab ein paar SSH Sessions auf und dann noch SCP. Dann wird meine Verbindung getrennt (Internet, WLAN, Absturz, Konfiguartion an ip oder route,...). Die Fritzbox hat dann ein paar Minuten timeout bis diese Verbindungen erkannte und gelöscht werden. Und so lange muss ich dann evtl warten bis ich mich an meiner Box wieder anmelden darf.
Vielleicht sollte man die Werte im menuconfig konfigurierbar machen?

 

[hermann72pb]

Darum geht es gar nicht. Die Limits gelten nur für Fehlversuche bei der Anmeldung. Ordnungsgemäß offene (und auch gestorbene) Verbindungen zählen dabei nicht. Ich benutze auch SCP+PUTTY, daher kommt der Wert 2. Keine Sorgen, es wird schon gehen.

Ich werde folgende Werte ersetzen:
Max. Anzahl der gleichzeitig offenen Anmeldungen von einer IP: 2 anstatt 5
Max. Anzahl der gleichzeitig offenen Anmeldungen von unterschiedlichen IPs: 5 anstatt 30
Anzahl der Fehlversuche bei Passworteingabe: 2 anstatt 10
Timeout für Passworteingabe: 30 sec anstatt 5 min

Das ganze poste ich in Beitrag #1 und als Ticket als patch für make/dropbear/patches

Wer will, kann die Werte dort später auch verändern oder den patch komplett deaktivieren. Ich denke aber, dass die neuen Werte mehr dem gesunden Menschenverstand (auf die Fritz!Box bezogen) entsprechen als die alten.

MfG

 

[SeeDyX]

Weißt du jetzt denn was diese Fehlversuche bei Passworteingabe genau bedeuten?

 

[RalfFriedl]

Den Timeout würde ich nicht herunter setzen. Ein automatischer Anmeldeversuch wird vermutlich sowieso schneller seine drei Versuche fertig haben. Und wenn nicht, blockiert er als nicht angemeldete Verbindung andere Versuche. Das trifft eher den normalen Anwender, der langsam sein Paßwort eingibt, es evtl. auch nicht gleich beim erstem Mal richtig eingibt.

Den Wert "tries" würde ich auch stehen lassen. Es könnte sein, daß damit die Zahl der Schlüssel begrenzt wird, die der Client probieren darf.

Interessant wäre, ob bei solchen Versuchen überhaupt mit parallelen Verbindungen gearbeitet wird oder nacheinander. Im letzteren Fall würde das Ganze gar nichts bringen.

 

[hermann72pb]

Ich würde folgendes Vorschlagen:
Ich poste meinen patch mit den oben genannten limitierten Werten und bitte es alle zu testen, auch diejenigen, die mit Schlüsseln anstatt Passwörter arbeiten. Wenn jemand Probleme haben sollte und sich beschwert, schrauben wir die Werte hoch.

Timeout von 5 Minuten auf 30 sec. würde ich auch runtersetzen. Wie gesagt, es geht hier um die Überlastung der Box. Und je schneller die Box diese Last abwerfen kann, desto besser. 30 sec. sollen doch jedem ausreichen, oder?

@SeeDyX: Ja, diese Tries waren die Fehlversuche. Ich konnte es reproduzieren.

MfG

 

[RalfFriedl]

Last gibt es nur, wenn etwas getan wird, in diesem Fall Daten verschlüsselt und übertragen, aber nicht, wenn einfach nur gewartet wird.

Wenn aber automatisch Paßwörter gescannt werden, wird vermutlich nicht gewartet, so daß die Zahl der möglichen Versuche weit vor Ablauf der 30 Sekunden erreicht wird. Diese Begrenzung hat daher für einen Paßwortscan keine Bedeutung.

Ich habe mal das Protokoll vom letzten Paßwortscan bei mir angeschaut. Das wird pro Verbindung nur ein einziger Versuch gemacht. Daher ist auch die Zahl der Paßwort-Versuche nicht von Bedeutung.

Daher würde ich folgendes vorschlagen:
MAX_AUTH_TRIES und Timeout bringen nichts, also unverändert lassen.
MAX_UNAUTH_PER_IP auf 2 setzen, oder auch gleich auf 1.
Nach einem erfolglosen Paßwort-Versuch nicht beenden, auch wenn die Gegenseite die Verbindung schließt, sondern noch eine Pause einbauen, 30 Sekunden, oder 60, evtl. auch mehr. Das benötigt aber vermutlich eine Änderung am Programm. Damit ist dann aber die IP-Adresse solange blockiert, ohne daß irgendeine Last auf der Box erzeugt wird.
Auch MAX_UNAUTH_PER_IP auf 1 allein stellt zumindest sicher, daß nur eine Verbindung auf einmal aufgebaut werden kann und nicht gleich mehrere.

 

[hermann72pb]

Ok, mit der Last habe ich mich falsch ausgedrückt. Eher geht es um die RAM-Belegung. Vor allem bei den "kleineren" Boxen. Und auch ein wartendes Prozess belegt RAM. Ich weiß zwar nicht wieviel und ob es maßgeblich ist.

Den Wert 2 anstatt 1 für parallele Verbindungen würde ich schon mal lassen. Wenn man WinSCP benutzt und drunter PUTTY offen ist, melden sich die beiden gleichzeitig. Es kann dabei zu Problemen kommen.

Mit der Pause hatte ich mir auch gedacht... Ich schaue nochmal die options.h durch, vielleicht finde ich da was. Aber vermutlich hast du Recht und es ist nur durch Programmänderung möglich.

MfG

 

[ao]

Hallo Hermann,

entschuldige bitte meine evtl. blöde Frage: Ist das, was Du als Patch beschrieben hast, in der aktuellen Freetz-Revision drin?
Und wie kann ich das selbst auf meiner 7170 testen?
Ich meine, was stelle ich unter der "knockd config" in Freetz ein, und wie simuliere ich dann "Angriffe von draußen"?
Ich würde gerne mithelfen beim Testen, weiß aber nicht so recht wie.

Danke für Deine Mühe und Hilfe!

PS: iptables habe ich nicht in Freetz aufgenommen, nur dropbear, bftpd, und ein paar andere, weniger relevante Addons.

 

[olistudent]

Der Patch ist ab r1855 drin. Mit knockd hat der nichts zu tun. Und gestestet werden muss der eigentlich auch nicht. Am Einfachsten ist immer noch den Port zu verlegen. Seitdem ist bei mir Ruhe.

MfG Oliver

 

[cuma]

@hermann72pb: Änder doch mal den Thread-Titel. Wie wäre es mit einem vorangestellten [#1855] statt [erledigt]?