Zugang zum Backup-Server absichern

[Stephan Richter]

Aus gegebenem Anlass: ​https://www.heise.de/news/Cybterattacken-auf-sieben-Schulen-in-Karlsruhe-7494896.html

Der ssh-Zugang zum Backup-Server sollte ein separater, möglichst starker Schlüssel sein mit einem PW, das ausschließlich hier genutzt wird (kein automatischer Zugang zu backup von einem kompromittierten System darf möglich sein).

Der Backup-Prozess selbst wird bereits von backup aus initiiert und nicht von den anderen Servern aus.

[Rüdiger Kupper]

Die weitestgehende Maßnahme wäre, den Zugang von außen komplett abzuschotten. Dann müsste man, um ein Backup wiederherzustellen, jedesmal physisch in den Bücherkeller und sich direkt am Rechner einloggen.
Unkomfortabel, aber sicher.

[Rüdiger Kupper]

Zweite Option: Ssh-Zugang nur mit einem speziellen Schlüssel mit starker Passphrase, den nur die Administratoren besitzen.

Der Schlüssel sollte nicht auf anderen Rechnern unseres Netzwerks hinterlegt sein, sondern nur auf unseren privaten Geräten, von denen aus wir uns einloggen (zweiter Faktor). Für den Fall, dass wir unser Gerät nicht dabei haben, könnte der Schlüssel auf einem USB-Stick im Sekretariatstresor liegen.

[Stephan Richter]

Dritte Option: Wie 2., aber der Schlüssel liegt auf einem Rechner im Netzwerk (z.B. paedml).

Allein das würde bereits ein erhebliches Plus an Sicherheit bringen, wenn man nicht mit ssh-forwarding oder anderen, bereits erbeuteten Passwörtern weiter kommt.

[bau]

Ich tendiere zu Option 3:

• Schlüssel mit extrem langer Passphrase liegt auf paedml im .ssh von root
• Passphrase liegt verschlüsselt auf unseren persönlichen Rechnern (jeder verschlüsselt das selbst mit seinem selbstgewählten Passwort)

Vorgehensweise, wenn man auf den backup kommen möchte:

• login auf den paedml
• ssh backup
• Passphrase durch Eingabe eines Passworts auf eigenem Rechner entschlüsseln
• Copy&Paste zum Entsperren des Schlüssels für den backup auf paedml

[Rüdiger Kupper]

Dann werd ich mal einen starken Schlüssel mit starker Passphrase erstellen und euch dann informieren.

[Rüdiger Kupper]

Replying to rich:

Dritte Option: Wie 2., aber der Schlüssel liegt auf einem Rechner im Netzwerk (z.B. paedml).

Allein das würde bereits ein erhebliches Plus an Sicherheit bringen, wenn man nicht mit ssh-forwarding oder anderen, bereits erbeuteten Passwörtern weiter kommt.

Es wäre dann halt nur noch ein Faktor („something you know“), ohne „something you have“, denn ein Eindringling hat dann die Schlüsseldatei. Wenn uns das reicht ist es natürlich etwas komfortabler.

[Rüdiger Kupper]

Weiß jemand, was der derzeit eäpfohlene Schlüsselalhorithmus ist? RSA und DSA sind ja jetzt beide „dwpricated“. Und die empfohlene Schlüssellänge?

[Stephan Richter]

Soweit ich es verstanden habe ist nicht RSA, sondern der sha-1 hash deprecated: ​https://ikarus.sg/rsa-is-not-dead/.
Somit sollte ein 4096bit RSA key mit SHA-2 vollkommen sicher sein.

Als Alternative gäbe es eigentlich nur Ed25519.

[bau]

Letztens machte mein Ubuntu mir einen ECDSA-Key

[Stephan Richter]

aus ​der Wikipedia:

Some concerns expressed about ECDSA:

Political concerns: the trustworthiness of NIST-produced curves being questioned after revelations that the NSA willingly inserts backdoors into software, hardware components and published standards were made; well-known cryptographers[13] have expressed[14][15] doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past.[16][17] (See also the libssh curve25519 introduction.[18]) Nevertheless, a proof that the named NIST curves exploit a rare weakness, is missing yet.