Massive Passwortattacken auf Rootserver

[alexander newald]

Jein - Es gibt eine Protokollimplementierung (recht alt). Aber hinbekommen habe ich es nicht

Ist das Board eigendlich nur bei mir so langsam?

[aldee]

Bei mir löppt's ganz normal.

[andreask2]

Somit hat ein Angreiffer immer noch die Möglichkeit alle Möglichkeiten durchzuprobieren - Es dauert nur länger.

Im aktuellen Linux-Magazin wurde mal kurz überschlagen, wie lange es dauert ein gutes 8-stelliges Passwort auf einem Standard 1&1 Server garantiert zu knacken: Ergebnis war knapp 1 Mio Jahre. Natürlich kann man nicht davon ausgehen, dass der Angreifer erst beim letzten Versuch Glück hat, aber auch bei Deinem Script geht es ja nur darum, dass mehr Zeit benötigt wird (und damit die Erfolgswahrscheinlichkeit gesenkt). In meinen Augen kann man das erheblich effizienter erreichen, indem man ein sehr gutes Passwort, oder noch besser einen 2048-Bit RSA-Schlüssel verwendet, denn hierdurch wird die Erfolgswahrscheinlichkeit eines solchen Brute-Force Angriffes deutlich weiter gesenkt, als durch eine temporäre IP-Sperre.

Abgesehen davon lässt sich das Script sehr leicht umgehen wenn man viele IPs zur Verfügung hat. Ich sehe die Gefahr, dass Leute unsichere Passwörter behalten und sich in trügerischer Sicherheit wiegen.

Dazu kommt dann noch das zusätzliche Risiko eines zusätzlichen von außen erreichbaren Programms.

Daher mein Tipp:

Code: Select all

# nano -w /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

Sind halt meine 2 ct zum Thema ;-)

[nyxus]

Steht doch auf der Seite.

stimmt, ich habe aber die Beschreibung so interpretiert, dass das Script die Umleitung erst dann macht, wenn die Sperre abgelaufen ist. Und das hat mir irgendwie nicht eingeleuchtet.

Es dauert nur länger.

Dann könnte man ja auch gleich ein "Teergrubing" machen und die Login-Fehlermeldung verzögern um den Angreifer bzw. den Wurm noch weiter auszubremsen. Aber der positive Effekt für das Internet insgesamt lohnt wohl eher nicht ...

Aber was wäre wenn man dem Angreifer ein erfolgreichen Login vorspielen würde. Dann könnte man noch gleich seine nächsten Aktionen protokollieren.

[alexander newald]

Wobei bei der Lösung mit dem Weiterleiten auf den Port 2222 eben erst dann wieder Verbindungen per SSH möglich sind, wenn lange auf Port 2222 (bzw. ja auf Port 22 SSH) keine Verbindungen gewesen sind. Damit der Angreifer feststellen kann, ob er weitere Logins versuchen kann, muss er sich verbinden und verlängert somit automatisch selbst die eigene Sperre.

Code: Select all

PermitRootLogin no

ist sicher eine sehr gute Idee, aber auch meine normalen Accounts möchte ich nicht mit einem anderen Teilen wollen...

[aldee]

Aber was wäre wenn man dem Angreifer ein erfolgreichen Login vorspielen würde. Dann könnte man noch gleich seine nächsten Aktionen protokollieren.

Antwort darauf: siehe die Antwort auf meine Frage nach einem Perl-SSH-Server-Modul oben ;-).

[nyxus]

Antwort darauf: siehe die Antwort auf meine Frage nach einem Perl-SSH-Server-Modul oben ;-).

Ich sags doch, Ich brauch Urlaub ... ;-)

[chaosad]

klar hilft es auch bei anderen logins, aber hier muß er eben auch erstmal einen passenden User finden und dazu noch das richtige Passwort. Meiner Meinung nach gar nicht so einfach wenn einigermaßen sichere Passwörter verwendet werden.

[andreask2]

Wobei bei der Lösung mit dem Weiterleiten auf den Port 2222 eben erst dann wieder Verbindungen per SSH möglich sind, wenn lange auf Port 2222 (bzw. ja auf Port 22 SSH) keine Verbindungen gewesen sind. Damit der Angreifer feststellen kann, ob er weitere Logins versuchen kann, muss er sich verbinden und verlängert somit automatisch selbst die eigene Sperre.

Wie gesagt, es ist ein einfaches Rechenexempel:

- Wie lange braucht ein Angreifer mit nur einer IP bei verzögernder IP-Sperre bis er mit Wahrscheinlichkeit X ein gültiges Passwort findet?

- Wie lange braucht ein Angreifer mit 10.000den Bots (verschiedene IPs) bei verzögernder IP-Sperre bis er mit Wahrscheinlichkeit X ein gültiges Passwort findet?

- Wie lange braucht ein Angreifer ohne IP-Sperre einen 2048-bit RSA-Schlüssel mit Wahrscheinlichkeit X zu erraten?

Code: Select all

PermitRootLogin no

ist sicher eine sehr gute Idee, aber auch meine normalen Accounts möchte ich nicht mit einem anderen Teilen wollen...

Wieso habt Ihr da solche Sorgen wenn es schon bei guten 8-stelligen Passwörtern bei Kenntnis des Usernamen ca. 1 Mio. Jahre dauert bis es garantiert erraten ist? Man kann sowohl ein gutes Passwort als auch den regelmäßigen Wechsel erzwingen. Und wie gesagt, mit RSA-Schlüssen potenziert sich die benötigte Zeit. Abgesehen davon verlässt sich das Script auf die falsche Annahme, dass ein Angreifer nur eine IP hat. Ein 5 oder 6-stelliges Passwort aus einem Wörterbuch zu erraten ist nicht mehr so schwer - daher die ganzen Versuche - weil es sich halt zu lohnen scheint.

[alexander newald]

Es gibt halt aber auch noch Eltern, Frauen und Computereinsteiger etc, denen man nicht unbedingt klarmachen kann, dass sie kein Passwort wie "Papa", "Arbeit" oder sonstwas nehmen sollen. Dafür ist es dann aber einfach sinnvoll...

[andreask2]

OK, da hast Du Recht, wenn man denn Eltern, Frauen und Computereinsteiger auf dem Server haben will ;-)

[alexander newald]

Ich schätze mal, dass die grösste Anzahl der Benutzer kein sicheres Passwort hat. Und von wem der Account schliesslich geknackt wird ist von dem Schaden hinterher egal. (Wobei dies natürlich kein alleiniges Problem von SSH sondern auch von FTP Zugängen ist)

[andreask2]

Ich schätze mal, dass die grösste Anzahl der Benutzer kein sicheres Passwort hat.

Man braucht ja unsichere Passwörter nicht zuzulassen:

http://www.gentoo.org/doc/en/security/s ... art1_chap7
http://www.kernel.org/pub/linux/libs/pa ... html#ss6.3

Abgesehen davon kann man wie gesagt Passwort-Login abschalten und die User zwingen Public-Keys zu verwenden. So kompliziert ist das auch nicht für die User. IMHO sollte man gerade was solche Logins auf dem Server angeht keine Kompromisse machen. Als Admin hat man die Möglichkeit die User zu zwingen sichere Passwörter oder Public-Key zu verwenden, und die User haben sich da wohl oder übel dran zu halten.

Durch ein IP-Sperrscript erhöht man die Sicherheit des Systems IMHO nicht nennenswert (aus den bereits genannten Gründen), anders als mit sicheren Passwörtern oder noch besser Public-Key.

[nyxus]

Durch ein IP-Sperrscript erhöht man die Sicherheit des Systems IMHO nicht nennenswert (aus den bereits genannten Gründen), anders als mit sicheren Passwörtern oder noch besser Public-Key.

Für einen Rootserver magst Du Recht haben. Aber nicht alle Systeme mit SSH unterstützen Public Key Authentifizierung. Und dort kann natürlich eine verzögernde Komponente sehr sinnvoll sein.

Auch können Passwörter ein Komfort-Gewinn sein wenn man z.B. oft mit unterschiedlichen Rechnern arbeitet (gerade im Business-Bereich wird die Abwägung Komfort <-> Sicherheit ja viel zu oft zu Gunsten des Komforts entschieden).

Und zu dem Script selbst würde ich sagen: Schaden tut es auch nicht. Und besser als nur Passwörter kann es fast nur werden. Vor allem, wenn man über dieses zentrale Sammeln von Angreifer-Daten noch ein paar globale Statistiken erzeugen kann (Alexander: läuft das schon und kann man sich die Statistiken anschauen?)

[alexander newald]

Statistiken kann man anschauen, aber nur von meinen Server und nur auf meinem privaten Bereich. Ich kann ja mal ein MRTG Graphen posten wenn Interesse besteht.

[mausgreck]

Ich schätze mal, dass die grösste Anzahl der Benutzer kein sicheres Passwort hat.

Selber schuld, kein Mitleid (auch nicht mit Leuten die unverschlüsselte Protokolle wie FTP verwenden). Nightly Backup einspielen kostet mindestens ein Bier und einmal ganz demütig dreinsehen. Nicht, dass sich meine User ihre Passwörter aussuchen könnten...

[alexander newald]

An der Uni konnten wir uns unsere Passwörter aussuchen - Manche Arbeitsgruppen hatten alle das Gleiche...

[mr. pink]

Daher mein Tipp:

Code: Select all

# nano -w /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

Sind halt meine 2 ct zum Thema ;-)

Da fehlt dann aber noch:

Code: Select all

PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no