SSH und Sicherheit

[yuhann]

Hallo,

habe seit knapp 2 Wochen einen V-Server am laufen beschäftige mich aus diesem Grund gerade intensiv mit dem Thema Sicherheit. Da ich einiges hierzu gelesen habe und es durchaus unterschiedliche Ansatzpunkte gibt, wollte ich mir hier mal eure Meinungen zu meiner Konfiguration einholen (in der Hoffnung nicht wieder eine Diskussion über security by obscurity loszutreten...):

(Ziel ist es, den Rechner vorerst so gut wie möglich abzudichten und nur einen SSH-Zugriff zu haben.)


/etc/hosts_allow
sshd : xx.xx.xx.xx : ALLOW
Zugriff ausschließlich auf sshd und nur von einer statischen IP erlaubt.


/etc/hosts_deny
ALL : ALL : spawn
per Default alles verbieten, protokollieren.


/etc/ssh/sshd_config
Port xxxxx
Standard-Port nicht verwenden (auch nicht 22222, etc.).

Protocol 2
schließt SSH-1 explizit aus.

PermitRootLogin without-password
keine Passwort-Authentifizierung für root.
(root-login erlaube ich nur deshalb, weil es mit SFTP anscheinend nicht möglich ist von einem user "xyz" per su auf root zu switchen. Statt root wäre mir hier ein user mit eingeschränkten Rechten allerdings schon lieber.)

PasswordAuthentication no
Keine Passwort-Authentifizierung erlaubt.
(Bin mir hier nicht sicher ob diese Einstellung nicht automatisch "PermitRootLogin without-password" überflüssig macht)

PubkeyAuthentication yes
login mit key authentication (1024 bit RSA-key mit passphrase).


So weit, so gut...



Zum System: SUSE 10, Plesk 8, Virtuozzo Power Panel

Plesk und VPP bieten leider nicht die Möglichkeit einen alternativen user anzulegen oder sich per key authentication einzuloggen. Hier sehe ich Schwachstellen in punkto Sicherheit.


Paketfilter (iptables/netfilter)
In diese Thematik muss ich mich noch einarbeiten.

Plesk und VPP bringen beide jeweils eine Firewall mit (Oberflächen für iptables).
Welche Firewall ist zu empfehlen, bzw wie konfiguriert man im Idealfall iptables?



Merci.

[kase]

Das sieht soweit ganz gut aus.

Du solltest aber unbedingt bedenken, dass der SSHd meistens nicht Ziel von Angreifern ist. Da gibt es viel anfälligere Dienste, über die man wesentlich "einfacher" einbrechen kann.

[adjustman]

Welche Firewall ist zu empfehlen

gar keine.

[r. u. serious]

Außerdem noch Portknocking nutzen, und per cron-job die Zeiten einschränken in denen man sich einloggen kann, am besten imer nur in den ersten 5 Minuten einer vollen Stunde. Einen Shell-Wrapper als Login-shell benutzen, der auch bei erfolgreichem Login die Sitzun in 4 von 5 Fällen zufällig beendet - so denkt der Einbrecher er hätte es nicht geschafft obwohl die Zugangsdaten korrekt waren. Zu Schul-Ferienzeiten und an Wochenenden das Login ganz verbieten. Einen Honeypot in einer VM laufen lassen mit ssh auf port 22, mit oberflächlich interessanten Daten, der ansonsten aber gut abgesichert ist. Alle restlich verfügbare Arbeitszeit in die Ausgestaltung des Honeypots stecken, ggf. noch weitere Honeypots auf anderen Ports hinzunehmen. Wenn du es richtig anstellst, kannst du 3-6 Personenmonate in den ganzen Schmu investieren. Ganz sicher ist an dann natürlich noch nicht. Daher würde ich in Zeiten wo der Server wenig genutzt wird, ihn trotzdem herunterfahren - Sicher ist Sicher.

[lord_pinhead]

Warum fiel noch nicht das der SSH Login nur mit einem Keypair laufen sollte und möglichst den root Account deaktivieren und mit sudo arbeiten?

[daemotron]

<sarkasmus>
Ich würde ja auf SSH ganz verzichten. Danach sucht ein böser Hacker doch als erstes. Nee, lieber Telnet oder rsh verwenden - damit rechnet doch heute keiner mehr *SCNR* #-o
</sarkasmus>

[Joe User]

Ich würde ja auf SSH ganz verzichten.

Bei vorhandener Remote-Console durchaus zu empfehlen ;)