zwei SSH-probleme

Lesenswerte Artikel, Anleitungen und Diskussionen
theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

zwei SSH-probleme

Post by theomega » 2003-01-30 21:04

Hallo Leute
ich habe zwei Fragen zum SSH-Server auf meinem Suse 8.1:

1. Wie kann den Login so verändern, dass nach 3 Passwort-Fehleingaben die IP gesperrt wird? Damit würde man Bruteforce einigermaßen unterbinden können

2. Wie kann ich verhindern, das ich nach ca. 2 Minuten "nichtstun" ausgelogt werde?

Danke

TO

cybernd
Posts: 83
Joined: 2002-08-08 14:39

Re: zwei SSH-probleme

Post by cybernd » 2003-01-30 21:23

zum 2.

falls du dich per putty einlogst findet sich in den einstellungen eine option für ein aufrechterhalten der verbindung .. einfach alle 60 sekunden ein null paket hinschicken lassen

ist halt clientabhängig .. d.h. diese einstellung in deinem wunschclient suchen und bingo es müsste gehen

zum anderen prob hmmm da muß ich leider passen :o)

hth
cybi

jtb
Posts: 599
Joined: 2002-08-18 16:41
Location: Darmstadt

Re: zwei SSH-probleme

Post by jtb » 2003-01-31 22:40

theomega wrote:1. Wie kann den Login so verändern, dass nach 3 Passwort-Fehleingaben die IP gesperrt wird? Damit würde man Bruteforce einigermaßen unterbinden können
verwende max_startups

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: zwei SSH-probleme

Post by theomega » 2003-01-31 23:21

Ich habe MaxStartup mal testweise auf 3 gesetzt, tortzdem werde ich erst nach 10 Fehlversuchen gekickt und kann dann gleich nochmal versuchen, also ist meine IP nicht gesperrt.

Matthias Diehl
Posts: 315
Joined: 2002-09-24 13:26

Re: zwei SSH-probleme

Post by Matthias Diehl » 2003-01-31 23:23

hast Du nach der Umstellung auch ssh neu gestartet ?
Das mit IP sperren geht nur über iptables oder ähnliches. Das geht nicht über die shh config

jtb
Posts: 599
Joined: 2002-08-18 16:41
Location: Darmstadt

Re: zwei SSH-probleme

Post by jtb » 2003-02-01 09:41

theomega wrote:Ich habe MaxStartup mal testweise auf 3 gesetzt, tortzdem werde ich erst nach 10 Fehlversuchen gekickt und kann dann gleich nochmal versuchen, also ist meine IP nicht gesperrt.
MaxStartups
Specifies the maximum number of concurrent unauthenticated con-
nections to the sshd daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime ex-
pires for a connection. The default is 10.

Alternatively, random early drop can be enabled by specifying the
three colon separated values ``start:rate:full'' (e.g.,
"10:30:60"). sshd will refuse connection attempts with a proba-
bility of ``rate/100'' (30%) if there are currently ``start''
(10) unauthenticated connections. The probability increases lin-
early and all connection attempts are refused if the number of
unauthenticated connections reaches ``full'' (60).
Man muss nicht unbedingt die IP sperren um Bruteforce zu verändern (ein DSL-Flat würde sich einfach neu einwählen!), sondern man kann Wartezeiten für Fehlgeschlagene Logins einbauen und das geht mit maxstartups..

Eventl. hast du deinen sshd nicht neugestartet?

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: zwei SSH-probleme

Post by theomega » 2003-02-01 12:20

Ich verstehe diese Angaben nicht ganz, welche wären den sinnvoll?

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: zwei SSH-probleme

Post by dodolin » 2003-02-01 21:54

1. Wie kann den Login so verändern, dass nach 3 Passwort-Fehleingaben die IP gesperrt wird? Damit würde man Bruteforce einigermaßen unterbinden können
MaxStartups ist für was anderes zuständig und hilft hier nicht weiter. Ich würde sowas ja lieber über pam regeln. Ist auch viel eleganter. :-D
Der Linux-PAM System Administrators' Guide (http://www.kernel.org/pub/linux/libs/pa ... l/pam.html) ist wirklich für jeden Admin sehr empfehlenswert. Das für diesen Zweck gesuchte Modul findest du unter http://www.kernel.org/pub/linux/libs/pa ... tml#ss6.24. Die meisten (oder alle?) SSHDs sollten sowieso schon gegen pam gelinkt sein. Einfach mal in /etc/pam.d/ nachgucken, ob es dort ein file sshd oder sowas gibt. Dort dann das tally Modul entsprechend mit den gewünschten Optionen verlinken.
2. Wie kann ich verhindern, das ich nach ca. 2 Minuten "nichtstun" ausgelogt werde?
Auch dass das nur eine Client-Option wäre, ist falsch. In der man-page zu sshd sind hierzu die Optionen ClientAliveInterval, ClientAliveCountMax und KeepAlive von Interesse.

Ich würde das Problem mit der Bruteforce-Attacke allerdings etwas anders angehen:
Entweder Passwort-Login komplett deaktivieren und Login nur noch per PubKeyAuthentication zulassen oder wenn ein Passwort-Login unbedingt nötig ist, hierzu einen separaten User anlegen, der ansonsten keinerlei Rechte hat und per AllowUsers (DenyUsers) ausschliesslich diesem User den Login erlauben. Dann mit su arbeiten. So müssten mindestens 2 Passwörter (die man halt gut (tm) wählen sollte) geknackt werden und mit dem 1. gecrackten Account könnte man (bis auf Local Exploits, die ja bei einem zeitnah gepatchten System eh nicht funktionieren dürften... :-D ) noch nichts anfangen.

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: zwei SSH-probleme

Post by theomega » 2003-02-01 22:11

Ã?hm, das mit den Keys hört sich sehr interessant an, wie funktioniert dass dann? Das jeder User, der Zugriff aus SSh haben will, eine bestimmte Keyfile haben muß? das wäre ideal!

[tom]
RSAC
Posts: 671
Joined: 2003-01-08 20:10
Location: Berlin

Re: zwei SSH-probleme

Post by [tom] » 2003-02-01 22:30

theomega wrote: Damit würde man Bruteforce einigermaßen unterbinden können
Brute Force online gegen einen Account macht eigentlich keiner. Eher Dictonary.

Wenn Du "starke" Passwörter hast, würde es rein rechnerisch lokal auf einem Rechner, der 40.000.000 Vergleiche pro Sekunde schafft, ca. 50 Jahre dauern, bis er alle Kombinationen durch hat (bei Standard DES).

Bei "schwachen" kann man mit einem Dictionary allerdings schon Erfolg haben.

Also - immer starke Passwörter. ;-)

Und noch ein kleiner Tipp: root Login disablen und einen User anlegen, der nicht einfach zu raten ist (also nicht admin, tom usw.). Der Username ist die halbe Miete.

[TOM]

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: zwei SSH-probleme

Post by theomega » 2003-02-01 22:31

Will heißen, die Chance, das ein 10 Stelliges Passwort auf Zahlen und Buchstaben in einer wirren Kombination eher nicht zu knacken sind?

sascha
RSAC
Posts: 1345
Joined: 2002-04-22 23:08

Re: zwei SSH-probleme

Post by sascha » 2003-02-01 22:51

Am besten schaltet man den Passwort Login komplett aus und logt sich nur mit einem RSA Key ein.

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

Re: zwei SSH-probleme

Post by theomega » 2003-02-01 22:52

und wie funktioniert das dann? Was müßen die User auf dem PC haben?

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: zwei SSH-probleme

Post by dodolin » 2003-02-02 06:01

Ã?hm, das mit den Keys hört sich sehr interessant an, wie funktioniert dass dann? Das jeder User, der Zugriff aus SSh haben will, eine bestimmte Keyfile haben muß? das wäre ideal!
Ja.

Blöd wird es halt dann, wenn man sich z.B. von unterwegs einloggen will und man
a) den Key nicht dabei hat oder
b) ihn zwar z.B. auf Diskette mit hat, aber der momentan verfügbare Rechner kein Laufwerk hat.

Ansonsten ist das aber IMHO eindeutig vorzuziehen.

Wie es geht? Hm... die Doku ist da eigentlich ganz gut. Ich bin ja immer nach der Anleitung auf http://atiswww.ira.uka.de/studentisches ... _ohne.html vorgegangen, weil es halt von meiner Uni ist. :wink: Aber ehrlich gesagt, ist die Anleitung in dieser Form nicht zu gebrauchen, da fast alle Pfade und Dateien auf meinem Linux anders hiessen. Naja, mit ein bisschen Eigenintelligenz und den man-pages zu sshd und ssh kriegt man es dann aber hin. Eigentlich sollten auch die man-pages alleine schon ausreichen.

In der Konfig zum SSHD sind folgende Optionen interessant (siehe man-page):
AuthorizedKeysFile (so muss das File heissen, das im $HOME des jeweiligen Users liegen muss)
PasswordAuthentication (sollte dann auf "no" stehen)
PermitRootLogin (sollte sowieso immer auf "no" stehen)
Protocol ("2" genügt, "1" ist unsicher)
PubkeyAuthentication (sollte natürlich dann auf "yes" stehen)
sowie die bereits erwähnten Optionen
AllowUsers und DenyUsers (gibt es auch mit Groups).

Wie der Client konfiguriert wird, wird in der recht ausführlichen man-page zu ssh beschrieben.