Re: Danke fuer die Antworten! (SSH-Absicherung ...)

["Raphael H. Becker" <Raphael.Becker@xxxxxx>]

On Tue, Jul 05, 2005 at 11:28:37PM +0200, Stephan Gromer wrote:

>  PermitRootLogin no
Das sollte auf jeder von extern erreichbaren Kiste so sein. Und es ist
auch wohl default bei OpenSSH.
 
> Das hat schon mal wunderbar geklappt (eintragen, sshd neustart, NICHT
> von Remote!). 

Warum nicht? 
Den "Mutterprozess" kann man mit "kill -HUP <pid>" dazu bringen, sich
die neue Config zu laden, die eingeloggte (aktive) SSH-Verbindung wird
dabei nicht abgeschossen.

Unter FreeBSD 5.x einfach "/etc/rc.d/sshd reload"


> Der SSH-Client fragt jetzt zwar noch nach einem Passwort
> fuer einen nicht in dieser Liste eingetragenen User, bricht dann aber
> ab (was eigentlich gar nicht schlecht ist. So hat der Angreifer
> weniger die Moeglichkeit sich zielgerichet auf einen "gefundenen" User
> bei der Passwortsuche "einzuschiessen")

Da gibt es ein ganz nettes Feature, mit dem der sshd nach mehreren
Fehleingaben auch korrekte Passwoerter mit einer gewissen
wahrscheinlichkeit ablehnt:

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 
       expires 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).


Der Angreifer merkt also nicht, wenn er zufaellig das richtige Passwort
geraten hat.

 
> b) SSH-Port nicht auf dem Standardport lassen
> Dieser Vorschlag vermindert sicher einen Teil der Angriffe. Allerdings
> muss ich feststellen das die Ports inzwischen auch im hohen Bereich
> abgesucht werden.

Ja und? Dann muss man einfach nur mal schauen, welche Ports bei Dir
offen sind und mal kurz reinschauen, wo sich ein sshd meldet. Der
Aufwand hierfuer liegt um mehrere 10er potenzen niedriger als zufaellig
das richtige PW zu raten.
 
> e) SSH-Zugriff ueber IP-Tables nur von vertrauten Subnetzen zulassen.
> evtl. in Kombi mit dem von mir ja schon angesprochenen Zugriffsverbot
> nach 43-4 Versuchen fuer 1 Stunde
> Fuer mich in Kombination mit einem Zugriff ueber SSH auf Uniserver und
> damit indirekt eine Moeglichkeit die auch urlaubsfaehig waere.

sshd verarbeitet auch /etc/hosts.allow
--> kein Firewall noetig. 

> f) Meine Frage nach Verschlueselung
> Der Geschwindigkeitsverlust von 15-20% wurde bestaetigt. Fuer mein
> Problem aber wohl keine gute Idee, da der Angreifer wenn ja bereits
> Zugriff hat (home muss frei sein fuer User nach Passwort). Die
> Sicherheit des Backups wurde zudem fuer problematisch erachtet.

Ich verstehe nicht, vor was das schuetzen soll. Wodurch unterscheidet
sich der Zugriff von einem Eindringling (der fuer das System eigentlich
der authentifizierte User ist) und einem berechtigten User?

Vor was soll diese Verschluesselung schuetzen?
 
MfG
-- 
Raphael Becker                                    http://rabe.uugrn.org/
                      http://schnitzelmitkartoffelsalat.und.rahmspin.at/
.........|.........|.........|.........|.........|.........|.........|..