Re: Sinnvoll fail2ban und SSH-pubkey Authentifizierung kombinieren?
Am Freitag, 1. Juni 2012 schrieb Stephan Brauer:
> Hallo Michael, hallo Liste,
>
> On Fri, Jun 01, 2012 at 09:38:24AM +0200, Michael Stummvoll wrote:
> > Nun zum SSH-Login: Persönlich empfehle ich hier folgendes Setup:
> > - Nur publickey erlauben
> > - SSH-Root-Zugriff sperren.
> > - Einen zusätzlichen Amdin-User anlegen, der bekommt den zugang per
> > key. - Root hat ein gutes, einmalig verwendetes Passwort.
>
> Ich persoenlich verwende derzeit auch diese Methode, inkl. sudo.
>
> Allerdings habe ich zu Key-Authentifizierung einen Einwand gehoert,
> den ich sehr interessant finde:
>
> Ein Kollege verwendet zur Authentifizierung an seinem Server bewusst
> keine Key-Authentifizierung, weil er Angst hat, dass er den Key
> verlieren koennte, und der "Finder" des Keys dann in Ruhe das Passwort
> des Private-Keys "Bruteforcen" kann.
>
> Er verwenden daher auch lieber Passwort-Authentifizierung mit Fail2Ban
> um die Anzahl der Angriffe zu reduzieren.
>
> Ich finde den Einwand derzeit schluessig. Habe ich mich zu leicht
> ueberreden lassen, oder ist an der Argumentation tatsaechlich etwas
> dran?
Ich finde den Einwand nicht schlüssig.
Bis der Anwender den privaten Key ge-bruteforct hat, hab ich den auf
meinem Server dreidutzendmal ausgetauscht. SSH verschlüsselt den Key mit
der Passphrase und ich gehe jetzt einfach mal davon aus, dass diese
Verschlüsselung in etwa so schwer oder noch schwerer zu knacken ist, als
die von LUKS, ecryptfs oder encfs. Und bei einem solchermaßen
verschlüsselten Datenbestand würde ich mir auch keine großen Gedanken
machen.
Mit Schlüssel muss der Angreifer den Schlüssel erstmal haben, um überhaupt
eine Brute Force-Attacke starten zu können. Ansonsten kann er, solange SSH
selbst keine Lücke hat, solange gegen den Server ballern, wie er möchte,
ohne auch nur einen Schritt weiterzukommen. Bei Passwort kann er auch so
schon loslegen.
Wer natürlich das ganze noch sicherer haben möchte, legt den Schlüssel in
einem verschlüsselten Dateisystem oder Blockgerät wie LUKS, ecryptfs oder
encfs ab. Dann darf der Angreifer zwei Brute Force-Attacken durchführen.
Oder in einer nochmals mit PIN geschützten Smartcard oder so.
Das Ganze steht und fällt natürlich mit der Qualität der Passphrase für
den Key.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: