SSH absichern

[warl0ck]

Moin,

ich habe zuhause ein kleines Heimnetzwerk und versuche von Windows weg zu kommen.
Auf meinem kleinen server läuft schon Debian. Nun Habe ich SSH installiert und ich hoffe
es ist mir gelungen SSH so zu konfigurieren das vorerst keiner drauf kommt
schon garnicht als root

Ich habe gelesen das es nur einen richtigen Weg gibt SSH abzusichern und zwar durch die
AuthorizedKeyFile

Wie genau Funktioniert das? Was muss ich beachten? oder gehts evtl auch einfacher (besser)?


MfG
Warl0ck

P.S nutze Debian seit 2 Monaten ... bitte drauf achten das ich es verstehe

[peyote]

Ich denke mal ein gutes Passwort (z.b. nicht zu kurz, nix was im Wöterbuch steht) sollte hinreichend Sicherheit für Dein privates Netzwerk bieten. Root login kannst du direkt in der sshd.conf deaktivieren (ist glaube ich auch default?).
Um 99% der Brute Force Attacken aus dem Internet zu unterbinden (die nebenbei bei gutem Passwort extrem geringe Erfolgsaussichten haben) reicht es auch schon aus den Standardport zu wechseln (z.b. durch Portforwarding am Router, falls Du nicht direkt ans Intrenet angeschlossen bist)

[I.C.Wiener]

Moin,

ich denke auch, dass man sehr gut fährt, wenn man den Port z. B. irgendwo nach 65122 legt und ein Passwort mit 10 Zeichen (Groß- und Kleinshreibung, Zahlen, Sonderzeichen, ...) verwendet.
Ich mache das ohne Portforwarding und gebe dann beim Login immer den Port mit an (bzw. erstelle eine Konfiguration für den Zugang). Sonst gehen die Angriffe ja doch wieder auf den neuen Port.

MfG

[warl0ck]

Ich habe einen LinkSyS rounter davor aber derzeit will ich mit SSH nicht von draußen rein!
Den Port habe ich schon geändert aber so ne Key Datei kann nicht schaden ;D

Die Frage ist muss da nen bestimmter Code rein? oder einfach nur das PW?

Auf dem Server ist der Pfard auf dem dieser Key zu finden ist ja Variable!
Aber auf dem Client bin ich mir nicht sicher wo die Datei hin muss.

MfG
Warl0ck

[DynaBlaster]

Unter Linux kommen die Keys clientseitig nach $HOME/.ssh. Unter Windows (Putty) kann man das Keyfile irgendwo in den Optionen auswählen.

Siehe auch: http://debianhowto.de/doku.php/de:howtos:woody:ssh

[comes]

an dieser stelle erwähn ich gern das tool fail2ban...
erzeugt nach einer definierbaren anzahl von fehllogins eine firewall regel und block die gesamte IP für eine gewisse zeit...

[peyote]

Ich mache das ohne Portforwarding und gebe dann beim Login immer den Port mit an (bzw. erstelle eine Konfiguration für den Zugang). Sonst gehen die Angriffe ja doch wieder auf den neuen Port.

MfG

Ne, ich meinte das schon anders mit dem Portforwarding. Der shhd läuft bei mir auf dem Standardport, aber der Router leitet Port X dann auf den sshd Port um Also verbinde ich mich von aussen über Port x zum sshd...

[I.C.Wiener]

Erm, ja. So hätte man das auch lesen können.
Sorum funktioniert's sogar.

MfG

[ckoepp]

an dieser stelle erwähn ich gern das tool fail2ban...

würde davon abraten. Mit schlichten manipulierten Nutzernamen, lassen sich ganze Netze aussperren...

Solche Tools sind eher kontraproduktiv finde ich. Wenn dann lieber nen knockd - da gibts nichts zu manipulieren.

[chilichef]

an dieser stelle erwähn ich gern das tool fail2ban...

würde davon abraten. Mit schlichten manipulierten Nutzernamen, lassen sich ganze Netze aussperren...

Solche Tools sind eher kontraproduktiv finde ich. Wenn dann lieber nen knockd - da gibts nichts zu manipulieren.

Da stellt sich wohl eher die Frage des Einsatzgebietes. Für einen Dienst der von möglichst vielen Benutzern gleichzeitg erreichbar sein soll (Webseite mit viel Traffic, etc.) ist fail2ban sicher nicht geeignet weil eine gesperrte IP eine vielzahl von gesperrten Nutzern zur Folge haben kann. Ist ein Dienst allerdings so präsent im Internet muss man sich natürlich anders schützen als wenn es nur um die Absicherung eines einfachen Heimservers vor Bruteforce Attacken durch Scriptkiddies geht. Wenn ich mir Gedanken darüber mache ob meine Webseite für 10 Minuten nicht vn einer bestimmten IP erreichbar ist und ich dadurch Geldeinbußen o.ä. befürchte habe ich sicher noch andere Probleme um die ich mich kümmern sollte....

Fail2ban ist sicher leichter und schneller zu installieren als ein knockd und sorgt erst mal für ein wenig Ruhe und lesbare Logs.

Gruss
Lars

[ckoepp]

Wenn ich mir Gedanken darüber mache ob meine Webseite für 10 Minuten nicht vn einer bestimmten IP erreichbar ist und ich dadurch Geldeinbußen o.ä. befürchte habe ich sicher noch andere Probleme um die ich mich kümmern sollte....

Du wirst durch ein kleines minimales Script permanent vom Server ausgeschlossen
Nix mit 10 Minuten. Geschickte Ausnutzung der regulären Ausdrücke bringt sogar ganz andere iptables-Befehle hervor. Mit den "normalen" SQL-Injections bist du vertraut, oder? Das Prinzip ist hier genau dasselbe...

Und das ist für alle Betreiber von Servern im Internet nicht wünschenswert. Wobei wir als Linux-Menschen ja nochmal einen gewissen Grad an Professionalität voraussetzen - und dies erfüllen Tools dieser Art sicher nicht: http://www.ossec.net/en/attacking-loganalysis.html

Fail2ban ist sicher leichter und schneller zu installieren als ein knockd und sorgt erst mal für ein wenig Ruhe und lesbare Logs.

Na da solltest du schnell an deinen Vorurteilen arbeiten. Der (Standard) knockd ist idiotensicher zu konfigurieren. Und installiert ist er auch noch schneller, da schlicht kleiner als fail2ban :p
http://www.ckoepp.de/knockd/index.html

Wobei natürlich kein knockd zwingend irgendwas ersetzen muss. Ist nur eine Altertative von vielen. Aber fail2ban & Co haben eben erheblich Nachteile - und da kommts nicht drauf an ob ich einen Serverpark oder einen einzigen habe. Das Potenzial ist enorm. Wenn ich's mit dem Nichtnutzen von Software dieser Art schlicht wegfallen lassen kann, sollte ich es weglassen...

[goecke]

... ( von fail2ban wegen prinzipiellen Problemen abgeraten ) ...

Ich verwende einfach iptables dafür wie u.a. in
http://www.ende-der-vernunft.org/2005/0 ... -attacken/
beschrieben.

Dort verwendet man keine Logs die interpretiert werden müssen, und hat dementsprechend auch kein log-injection Problem - höchstens noch ein ip-spoofing (wenn jemand eine ihm bekannte ip absichtlich blockieren will).

Soweit ich das verstehe wird der 4. Verbindungsaufbau innerhalb einer Minute geblockt.
Das sorgt bei mir auch schon für etwas Ruhe.

Code: Alles auswählen

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Ist diese Lösung auch so leicht Angreifbar?

Johannes

[ckoepp]

Ist diese Lösung auch so leicht Angreifbar?

Nein.

Obwohl ich nicht ganz sicher bin ob NEW bei einem unbekannten SYN geschaltet wird. Dann wäre das Ganze "verletzlich", da keine Verbindung zustande kommen müsste um eine IP zu sperren. 4 Pakete mit falscher Source und SYN-Flag würden dann reichen. Damit wäre es dann auch möglich IP's auszusperren.
Versuchs mal, bin mir da jetzt auch nicht so sicher...

Könntest auch statt NEW einfach ESTABLISHED ersetzen. Da ist eine einfache Fälschung dann nicht mehrso einfach möglich - muss ja ein kompletter Hand-Shake zustande kommen. Und um sshd zu "brute-forcen", muss ja zwingend eine Verbindung aufgebaut werden.

[warl0ck]

Update
Also die Datein habe ich erstellt aber im in dem von DynaBlaster geposteten Howto steht:

Code: Alles auswählen

mkdir $HOME/.ssh 
touch $HOME/.ssh/authorized_keys 
cat $HOME/id_dsa.pub >> $HOME/.ssh/authorized_keys

Wenn ich das bei mir mache also:

Code: Alles auswählen

mkdir $HOME/.ssh/authorized_keys
touch /home/warl0ck-server/Desktop/id_rsa.pub
cat /home/warl0ck-server/Desktop/id_rsa.pub >> $HOME/.ssh/authorized_keys

dann habe ich im Ordner $HOME/.ssh/
nur die Datei id_rsa.pub
was mache ich da Falsch?

MfG
Warl0ck

[DynaBlaster]

Der von dir beschriebene Vorgang macht folgendes (das sind die Schritte, die auf dem Server, auf den sich später eingeloggt werden soll, durchgeführt werden müssen):

Code: Alles auswählen

mkdir $HOME/.ssh

Das versteckte Verzeichnis ".ssh" wird im HOME-Verzeichnis des Users, der sich später einloggen soll, angelegt.

Code: Alles auswählen

touch $HOME/.ssh/authorized_keys

"touch" legt eine leere Datei mit Namen authorized_keys im gerade erstellten Verzeichnis an

Code: Alles auswählen

cat /home/warl0ck-server/Desktop/id_rsa.pub >> $HOME/.ssh/authorized_keys

Diese Zeile liest den Inhalt von id_rsa.pub aus und speichert diesen Inhalt in die erstellte Datei authorized_keys.

Demnach sollte nach der Prozedur eigentlich nur die Datei authorized_keys im Ordner .ssh vorhanden sein.

EDIT: Rechtschreibfehler korrigiert

[warl0ck]

Ok soweit habe ich das bin bekommen!

Code: Alles auswählen

$HOME/.ssh/authorized_keys

ist nun auf dem Server vorhanden! (auch genau so, wie auf dem Client!

Problem! Ich kann mich immer noch von meiner Windows Kiste drauf einloggen!
Aber den Key habe ich hier nicht! Ist evtl noch was in der SSHD_config falsch?

sshd_config auf dem Server:

Code: Alles auswählen

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      $HOME/.ssh/authorized_keys

evtl da was falsch?

MfG
Warl0ck

[DynaBlaster]

Code: Alles auswählen

# disable password authentication 
PasswordAuthentication no

# disable all other authentications 
RSAAuthentication no 
IgnoreRhosts yes 
RhostsRSAAuthentication no 
HostbasedAuthentication no 
IgnoreUserKnownHosts yes 
ChallengeResponseAuthentication no

# PAM abschalten
UsePAM no

Hast du in der /etc/ssh/sshd_config alle Optionen so gesetzt, wie im bereits geposteten Howto beschrieben? Hast due den SSH-Daemon neu gestartet? --> /etc/iniit.d/ssh restart.

Wenn du keinen lokalen Zugriff auf den Server hast, musst du aber sicherstellen, dass die PubKey-Variante auch funktioniert, sonst sperrst du dich unter Umständen selbst aus. Genau aus dem Grund bleiben laufende SSH-Sitzungen auch beim Neustart des SSHD aktiv - du solltest dich also aus dieser laufenden Session erst ausloggen, wenn der Login bei einer 2. Session erfolgreich ist.

[striker2150]

Normalerweise kann man Bruth-Force-Attacken auch ganz gut mit dem PAM-Modul pam-abl abblocken. Dieses zählt die falschen Logins mit und gibt nachdem ein Schwellwert überschritten worden ist eine Zeit lang jedesmal ein false zurück. Das heist, auch wenn das richtige Passwort gepobed wird gibt es keinen Login. Das schöne an diesem Modul ist, dass der Angreifer gar nicht bemerkt, dass seine Anfragen beblockt werden, da er ja auch weiterhin Bruth-Forcen kann, nur die Angriffe ins leere laufen.

Aber ACHTUNG: Der bei Debian mitgelieferte sshd ruft die Funktion pam_end() nicht auf! Das heißt unter Debian funktioniert pam-abl nicht zusammen mit dem sshd!!!

Einige mögliche Alternativen wurden schon genannt. Was ich noch für ganz brauchbar halte ist pam-shield von Walter de Jong. Das macht quasi das selbe wie pam-abl, aber gibt nicht false bei der Anmeldung zurück, sondern ändert die Routing-Tabelle so, dass die Anfragen ins leere laufen. Der Rechner ist von der Angreifer IP aus nicht mehr erreichbar. Vorteil dieses Verfahrens ist, dass nicht an den iptables Regeln rumgepfuscht wird (da sollte man ja etwas aufpassen). Das Modul gibts aber nicht als deb-Package, aber die Installation ist trotzdem nicht schwer.

[Duff]

Ich erlaube zusätzlich in der sshd_conf den Login nur bestimmten Usern. (AllowUser user...)

Finde dies als Sicherheit auch sehr wichtig. Nur auf Key-Authentifizierung habe ich nicht umgestellt, da ich nich sonst nicht von "überall" auf den Server einwählen könnte (es sei denn, ich hätte einen USB-Stick mit entsprechendem Key dabei).

[uname]

Ich nutze für unterwegs OPIE (One-time Passwords in Everything). Das ist sehr praktisch gegen Keylogger usw. Und vor allem macht es einen coolen Eindruck wenn man seine entsprechende Einmal-Passwort-Liste nimmt. Obwohl gibt auch ein iPhone- und ein Android-App zur Generierung.

[Duff]

Kannst du dies ein wenig genauer beschreiben?

[uname]

Klar. Siehe meine Beschreibung unter http://forum.euserv.de/index.php?topic=5511.0

[Duff]

Danke, dann werde ich mich wohl mal dort anmelden bzw. registrieren müssen...

[uname]

Oh, das Forum darf man nur als Benutzer lesen. Wie ärgerlich.

Hier der Beitrag:

Um meinen Betatest-V-Server besser abzusichern habe ich mir gedacht wenn man mal von unsicheren Rechnern (z.B. Keylogger, virenverseucht, Internetcafe) zugreift, könnte man ja mal Einmalpasswörter nutzen. Das kann man im übrigen ohne Probleme parallel nutzen. Alternativ könnte man SSH-Keys einsetzen, aber manchmal vor allem bei webbasierten SSH-Clients wie Ajaxterm geht das nicht. Ich habe im Prinzip alles einmal durchlaufen und mir für den Notfall 20 Einmalpasswörter ausgedruckt. Vielleicht brauche ich sie ja nie.

Achtung:
Bei der Installation immer sicherheitshalber in einem anderen Fenster angemeldet bleiben. Fehler bei der SSH-Konfiguration können zu einem nicht mehr erreichbaren System führen. Backup sollte man immer vorrätig haben.

Gelesen habe ich zur Einstimmung:

http://www.heise.de/security/artikel/Ei ... 70884.html

Unter Debian installiert man:

Code: Alles auswählen

apt-get install opie-client
apt-get install opie-server

In der SSH-Server-Konfiguration (/etc/ssh/sshd_config) ändert man:

Code: Alles auswählen

ChallengeResponseAuthentication yes

In /etc/pam.d/sshd ändert man die Zugriffe in der Form, dass nach dem normalen UNIX-Passwort (falsch bzw. leer) das Einmalpasswort abgefragt wird:

Code: Alles auswählen

#@include common-auth    (dieser Eintragwird auskommentiert)

auth sufficient pam_unix.so
auth sufficient pam_opie.so
auth required pam_deny.so

Nun staret man den SSH-Server neu und erst mal ist nicht viel anders:

Code: Alles auswählen

/etc/init.d/ssh reload

Achtung: Hier mal testen ob SSH per Passwort/Key noch läuft, wenn nicht Aktionen rückgängig machen bzw. kontrollieren.



Nun braucht man noch ein paar Einmalpasswörter, die man wie folgt am besten als normaler Benutzer erzeugt. In dem Zusammenhang sollte man von diesem Benutzer auch "sudo" ohne root-Passwort erlauben bzw. es auch auf Einmalpasswörter umstellen.

Erzeugung Einmalpasswörter für den aktuellen Benutzer:

Code: Alles auswählen

opiepasswd -c
opiepasswd -c -f    (wenn das System meckert, da man Remote die Keys erzeugt)

Die zu vergebene Passphrase ist wichtig um wieder an die generierten Keys zu kommen. Wird bei der SSH-Anmeldung jedoch nicht gebraucht.

Wichtig ist die laufende Nummer (abwärts von 499 bis 0) und der sogenannte "Seed". Das System nennt diesen bei der Erstellung, im Zweifel kann man ihn mit "opiepasswd" wieder rausfinden. Er ist hier im Beispiel "kb7051" (geändert). Auch wird er bei jeder SSH-Anmeldung per Einmalpasswort genannt.

Code: Alles auswählen

opiepasswd 
Updating uname:
You need the response from an OTP generator.
Old secret pass phrase:
        otp-md5 499 kb7051 

Nun gibt man noch entsprechend z.B. 20 Werte aus (für unterwegs):

Code: Alles auswählen

opiekey -n 20 499 kb7051  (Seed entsprechend anpassen, System fragt nach Passphrase von oben)

Die Ausgabe sieht so aus:

Code: Alles auswählen

480: ....
...
498: MILT DUE FIT ELK GREY SLOW
499: EDDY DOLL FLAW BALL BUSS OBOE

Wenn man sich nun per SSH anmeldet und bei der Anmeldung "Enter" bzw. ein falsches Passwort eingibt, so fragt das System nach dem höchsten noch nicht verbrauchten Einmalpasswort:

Code: Alles auswählen

otp-md5 499 kb7051 ext, Response:

In diesem Fall würde man die Nummer "499" und somit "eddy doll flaw ball buss oboe" eingeben. Groß/Kleinschrift wird scheinbar nicht überprüft.