Persönliches Wiki in meinem Heimnetzwerk - wie sichere ich es?

3

Ich möchte eine Debian / Ubuntu-Box mit geringem Stromverbrauch verwenden, um ein persönliches Wiki (nämlich Instiki) darauf einzurichten. Die Informationen, die ich darin speichern möchte, sind offensichtlich sehr vertraulich. Jeder außer mir, der darauf zugreift, wäre eine Katastrophe. Und meine Netzwerkadministrations- und Sicherheitsfähigkeiten sind ziemlich schwach. Hohe Anforderungen, geringe Fähigkeiten; keine gute kombination.

Ich weiß, dass ich durch das Einrichten einer Listening-App und das Öffnen eines Ports nach außen einer gewissen Gefahr ausgesetzt bin. Aber wie kann ich diese Gefahr minimieren?

  • Ich verstehe, dass der Zugriff auf die Außenwelt standardmäßig nicht möglich ist, solange er hinter meinem Router mit integrierter Firewall ausgeführt wird. richtig?
  • Und wenn ich explizit einen Port für die Maschine öffne (einen "Virtual Server" -Eintrag in der Konfiguration meines Routers einrichte), bin ich im Grunde genommen der Stärke meiner Kombination aus Benutzername und Passwort ausgeliefert, nach der theoretisch jedes Skript sucht, das ein Kiddie sucht offene Ports könnten durch rohe Gewalt erraten werden.

Gibt es einen praktischen Mittelweg zwischen der Deaktivierung des Zugriffs von außen und der Verwendung einer Kombination aus Port, Benutzername und Passwort? Ich könnte damit leben, nur zu Hause auf mein Wiki zuzugreifen, aber das wäre eine Unannehmlichkeit.

Was sind meine anderen Möglichkeiten? SSH-Tunneling? Schlüsselpaar-Authentifizierung? Bitte beraten. Ich würde mich besonders über weitere Ratschläge zum Aufbau eines Tunnels oder VPN über SSH freuen.

ubuntu debian wiki home-server
quelle
4
Nein, tut es nicht. Dies ist so viel wie Serverfrage wie jede andere, die ich gesehen habe.
David Z

Antworten:

4

Hier ist der Ansatz, den ich nehmen würde:

Schritt 1 (lokale Sicherheit)

  • Lesen Sie Instiki und stellen Sie sicher, dass Sie den verwendeten Webserver sichern
  • Wählen Sie gute Passwörter für Root-, Administrator- und persönliche Konten und speichern Sie sie in einem Passwort-Manager , nicht auf Papier!
  • Stellen Sie sicher, dass nur der Webserver-Benutzer (kein anderer Benutzer, z. B. Gast) Daten lokal lesen kann.
  • Erfahren Sie , wie Sie lokale Dateien verschlüsseln (zB truecrypt ).
  • Erfahren Sie, wie Sie verschlüsselte Backups erstellen (kein Backup => keine Daten)

Schritt 2 (Zugangsbeschränkungen)

  • Server nur über https erreichbar machen (niemand liest Ihren Datenverkehr während der Übertragung)
  • Erlaube die Anmeldung bei Ubuntu nur über ssh [Port 22] oder die lokale Konsole
  • Schauen Sie in OpenVpn nach , um über das Internet sicher auf Ihr Heimnetzwerk zuzugreifen
Lexu
quelle
Das ist der Rat, nach dem ich gesucht habe. Dankeschön. Halten Sie SSH-Tunneling wie in instiki.org/show/SSH+Port+Forwarding beschrieben für eine gute Lösung? Ich meine nur die Grundlagen, die Sie erwähnt haben, sowie das Einrichten von SSH mit Schlüsselpaarauthentifizierung; Kein HTTPS, da SSH auch für die Verschlüsselung während der Übertragung sorgt.
Ich würde ssh und Schlüsselpaare nur für die Anmeldung verwenden, keinen SSH-Tunnel zum Wiki (aber ein VPN zum Heimrouter wäre sinnvoll), also habe ich es meiner Antwort hinzugefügt.
Lexu
Warum genau würden Sie nicht empfehlen, direkt in das Wiki zu tunneln? Es wäre zwar ein nützlicher Bonus, den Computer über SSH aus der Ferne zu verwalten, aber es ist nicht wirklich mein Endziel.
1
Eine weitere Möglichkeit, die Sie möglicherweise in Betracht ziehen sollten, ist das Ablegen einer .htaccess-Datei in Ihrem Webstamm, damit Sie sich ZWEIMAL authentifizieren müssen. Auf diese Weise ist es keine sitzende Ente, wenn das Skript / Wiki selbst eine Sicherheitslücke aufweist. Sie können Ihren .htaccess auch so einrichten, dass Verbindungen von anderen Personen als einer bestimmten IP / einem bestimmten Bereich abgelehnt werden.
KPWINC
1

Ich würde die HTTP-Authentifizierung über HTTPS durchführen und jeglichen HTTP-Verkehr an HTTPS umleiten. Beschränken Sie den Zugriff auf bestimmte IP-Adressen oder Netzwerke, wenn Sie nicht von überall Zugriff benötigen. Sie könnten ein HTTPS-Client-Zertifikat verwenden, aber dieses Zertifikat muss auf jedem Computer installiert sein, auf den Sie zugreifen müssen. Sie könnten eine Art USB-Gerät zum Speichern verwenden, aber Sie müssen sicherstellen, dass es entfernt wurde, nachdem Sie fertig sind. Abhängig von Ihrer Paranoia sind Sie möglicherweise nicht in der Lage, einem Computer zu vertrauen, den Sie nicht unter Ihrer Kontrolle haben, und selbst dann, wie sicher sind sie?

Es gibt nur so viel Mühe, die Sie tun können, um Zugang zu erlangen, und nur dann, wenn jemand, der Ihr Display über die Schulter liest, Ihre Sicherheit ruiniert. Die Leute neigen dazu, sowohl den Wert der Informationen als auch die Wahrscheinlichkeit eines Remoteangriffs zu überschätzen und die nichttechnischen Methoden für den Ausfall der Sicherheit zu unterschätzen.

David Pashley
quelle
Danke für deine nachdenkliche Antwort, David. Ich möchte nur von meinem eigenen Laptop auf den Server zugreifen, daher ist das Mitführen eines SSH-Schlüssels oder eines SSL-Zertifikats kein Problem, da ich meiner Fähigkeit, meinen Computer und die darin enthaltenen sensiblen Daten physisch zu schützen, mehr vertraue als meinen Netzwerkadministrations- und Sicherheitskenntnissen . Gibt es einen bestimmten Grund, warum Sie HTTPS dem SSH-Tunneling vorziehen würden?
1

Wenn ich die Kontrolle über die Off-Network-Browser habe, mit denen ich zu Hause auf Ressourcen zugreifen werde, verwende ich die X.509-Client-Zertifikatauthentifizierung über SSL. Selbst wenn jemand meinen Benutzernamen und mein Passwort hatte, wird der Webserver sich weigern, mit ihm zu sprechen, da er nicht über mein Client-Zertifikat verfügt.

Dies ist etwas schwieriger einzurichten, und wenn Sie einen dünnen Webserver verwenden, der in einige Wiki-Produkte integriert ist, ist dies möglicherweise nicht möglich. Ich benutze nginx als Webserver und mein Wiki (WikkaWiki) läuft auf php-fastcgi.

Das Problem ist, dass Sie möglicherweise mehrere Sites haben, auf die Sie zugreifen müssen. Aufgrund der Funktionsweise von SSL können Sie nicht mehrere virtuelle Hosts auf derselben IP- und Portkombination haben. Sie können dies beheben, indem Sie die Websites unter einem Host zusammenfassen und für jeden Host ein Unterverzeichnis ( https://my.domain.com/wiki , https://my.domain.com/blog ) oder separate Domänennamen verwenden verschiedene Ports.

In letzterem Fall können Probleme beim Senden von Datenverkehr aus Unternehmensnetzwerken an beliebige Ports auftreten, auf denen SSL ausgeführt wird (sie blockieren den gesamten bis auf den bekannten Datenverkehr, um zu verhindern, dass Benutzer mithilfe von SSH Tunnel in ihr Netzwerk öffnen.)


quelle