Auch, wenn ich in diesem Forum als Sid (der böse Junge, der sein Spielzeug kaputt macht) nicht sonderlich geliebt bin, finde ich es meine Pflicht, die NAS-User vor einer signifikanten Sicherheitslücke zu warnen:
Ich bin durch Zufall auf eine offensichtlich schwere Sicherheitslücke zumindest der QNAP TS-109/209 gestoßen. Habe mich auf meinem NAS mal per ssh umgeschaut, weil ich partout nicht den public key des NAS meiner known_hosts zufügen konnte. Bin dabei auf einen offensichtlich ganz dicken Hund gestoßen:
Die Schlüssel auf dem NAS unter /etc/ssh sind uralt mit Timestamp 4. Juni 2007.
Das läßt gleich 2 böse Sicherheitslücken vermuten:
a) die Schlüssel sind auf der QNAP-CD und für alle Geräte identisch.
b) die Schlüssel wurden in einer Zeit erzeugt, als Debian's ssh, ssl das Sicherheitsproblem hatten, d.h. sie sind obendrein noch unsicher.
Inzwischen weiß ich von 3 Usern (gusmax, christian und ich selbst), das auf allen Geräten die Keys in /etc/ssh identisch sind! Wer's nicht glauben mag oder selbst prüfen will, hier die md5-Hashes dazu:
76ff0b6cbde6ecbba5e9a31de084774b ./ssh_host_rsa_key.pub
3511672c225acb87bd59457f198cc278 ./ssh_host_dsa_key.pub
cf0f683a740ccb0a226872c8551f89d3 ./ssh_host_dsa_key
88d2a7eace69cf7f084dd8529d170a4f ./ssh_host_rsa_key
Meine erste Idee zur Beseitigung des Sicherheislochs war:
1. mit ssh-keygen neue Schlüssel erzeugen.
Geht aber nicht, auf dem NAS existiert der Befehl nicht
2. also selbst ordentliche Keys auf meinem lokalen Rechner erstellen mit:
ssh-keygen -t rsa -C admin@nas
ssh-keygen -t dsa -C admin@nas
und auf das NAS in /etc/ssh hochladen. Klappt prima, man muß nur auf den Clients die alten 'fake-keys' aus der 'known_hosts' entfernen - es werden aus Sicherheitsgründen keine 2 verschiedenen Keys von einem Server akzeptiert.. Dann die Ernüchterung: 1x Reboot des NAS und alles ist wieder beim Alten.
Das ganze Verzeichnis /etc/ssh wird dabei neu erstellt - die Daten kommen wohl aus dem Flash :shock:
Das ist mein Hinweis, Kommentare dazu und Sclüsse daraus überlasse ich Euch.
Ingo