Re: Danke für die Antworten! (SSH-Absicherung ...)

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
> für einen nicht in dieser Liste eingetragenen User, bricht dann aber
> ab (was eigentlich gar nicht schlecht ist. So hat der Angreifer
> weniger die Möglichkeit 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 Passwörter 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 zufällig 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 hierfür liegt um mehrere 10er potenzen niedriger als zufällig
das richtige PW zu raten.
 
> e) SSH-Zugriff über IP-Tables nur von vertrauten Subnetzen zulassen.
> evtl. in Kombi mit dem von mir ja schon angesprochenen Zugriffsverbot
> nach 43-4 Versuchen für 1 Stunde
> Für mich in Kombination mit einem Zugriff über SSH auf Uniserver und
> damit indirekt eine Möglichkeit die auch urlaubsfähig wäre.

sshd verarbeitet auch /etc/hosts.allow
--> kein Firewall nötig. 

> f) Meine Frage nach Verschlüselung
> Der Geschwindigkeitsverlust von 15-20% wurde bestätigt. Für mein
> Problem aber wohl keine gute Idee, da der Angreifer wenn ja bereits
> Zugriff hat (home muss frei sein für User nach Passwort). Die
> Sicherheit des Backups wurde zudem für problematisch erachtet.

Ich verstehe nicht, vor was das schützen soll. Wodurch unterscheidet
sich der Zugriff von einem Eindringling (der für das System eigentlich
der authentifizierte User ist) und einem berechtigten User?

Vor was soll diese Verschlüsselung schützen?
 
MfG
-- 
Raphael Becker                                    http://rabe.uugrn.org/
                      http://schnitzelmitkartoffelsalat.und.rahmspin.at/
.........|.........|.........|.........|.........|.........|.........|..