Beiträge von mlohr

    Das verstehe ich nicht ganz. Der Sinn des VPNs wäre aus meiner Sicht, dass man Credentials und/oder ein Zertifikat benötigt, um überhaupt Zugriff auf die Anwendung an sich zu erlangen.

    Soweit richtig. Aber in jedem Netzwerk (auch einem VPN-Netzwerk) können infizierte Geräte rumlaufen. Du verhinderst halt, dass erstmal nicht jeder überhaupt netzwerktechnisch in die Nähe der Kiste kommt (und dann Exploits der Platformen etc. ausnutzen kann). Das brint ohne Frage schon mehr als einfach nix tun. Aber ich gehe halt immer vom schwächsten Punkt aus. Und der ist selten das, was man direkt beleuchtet (Login-Bereich einer Anwendung), sondern meiner Erfahrung und auch der oben genannten Beispiele nach meistens da, wo keiner dran denkt (Storage, infizierte Clients, ...).


    Ich glaube eine perfekte Lösung gibt es - abgesehen von durchgeschnittenen Netzwerkkabeln - nicht. Letztendlich Kosten (finanziell wie zeitlich) und Nutzen abwägen.


    P.S.: Ich darf/durfte schon mit Firmen zusammenarbeiten, die, sagen wir, gegen sich selbst arbeiten: Um ja nicht aus Versehen Daten auf externen Cloudservern zu hosten wird alles mit "files" in der URL oder Domain gesperrt (ja, transparenter, SSL-aufbrechender Proxy...). Lösung: Entwickler macht sein eigenes, nicht weiter gesichertes VPN, damit er auf das Packagerepository von Python kommt (https://files.pythonhosted.org/). Man kann es also auch zu gut meinen und nen Schuss nach hinten setzen.

    Zugangsdaten würde ich grundsätzlich(!) nie in einem Wiki speichern. Erst recht nichts, was versioniert wird. Das ist schon oft genug erfolgreich schiefgegangen (z. B. https://gizmodo.com/github-tel…tored-their-pa-1825702783). Für Passwörter empfehle ich Dienste wie LastPass (die bieten auch ein Team-Sharing an), ansonsten mal das hier anschauen: https://www.vaultproject.io/, oder YubiKey verwenden.


    Ich hab zu Hause eine Anbindung mit 50Mbit Down/10Mb Up. Das GitLab ist über HTTPS mit der Welt verbunden. Die Geschwindigkeit reicht, auch von unterwegs, locker aus. Du redest ja auch nicht von 100 Mitarbeitern sondern erstmal von einer einstelligen Anzahl, die dazukommt, würde ich vermuten. Da sollte eine halbwegs zeitgemäße Leitung immernoch reichen.


    Aus meiner Sicht spricht ja auch eigentlich nichts dagegen, das bei NetCup zu hosten. Nur den Stunt mit VPN würde ich mir sparen. Die Frage ist immer, was das schwächste Glied in der Kette ist. Bei einem extern gehosteten Server würde ich erstmal auf den Server wetten und nicht den Übertragungsweg. SSH (ohne VPN) wirst du eh offen haben müssen, falls das VPN mal abschmiert. Ob du dann nun einen VPN aufmachst oder einfach nur noch HTTPS freigibst ist glaube ich von der Sicherheit recht ähnlich zu bewerten, Aufwand bei VPN aber um einiges größer. Dann kannst du bei VPN noch überlegen, ob du Layer2 oder Layer3 VPN haben möchtest.


    * Layer 2: Vorteil: Jeder kann jeden ganz einfach erreichen. Nachteil: Jeder kann jeden ganz einfach erreichen. Dann hast du den Schuh mit Firewalls in jedem Fall im Boot.

    * Layer 3: Zentralisiert(er) als Layer 2. Der Traffic, der durch das VPN geht ist ein bisschen besser kontrollierbar. Zentrale Endstelle (Server) für die Verschlüsselung. Ist bei HTTPS aber genauso.


    Also kurz zusammengefasst:

    Zugangsdaten einfach gar nicht speichern. Und wenn doch, dann verschlüsselt, unversioniert, nicht zentral. User based Accounts (dann brauch man keinen zentralen Passwort-Speicher). 2FA verwenden.

    Dienste (GitLab, Bitbucket, Confluence, ...) hinter ner schicken Firewall, natürlich nur HTTPS. Und bitte auch die Backups irgendwo sicher ablegen (https://virtualizationreview.c…rmy-data-unprotected.aspx).


    VPN kann man machen, macht etwas Arbeit, aber auch innerhalb VPN sollten die Dienste rocksolid laufen. Stell dir einfach vor, du hast nen befallenen Windows-Rechner im Netz, weil deine Buchhaltung natürlich auch im VPN sein muss mit Zugriff aufs Confluence. Sprich: Nur wegen VPN die übrigen Sicherheitsanforderungen nicht absenken.

    Die grundsätzliche Frage, die ich hierbei noch aufwerfen würde ist: Wenn die Daten so vertraulich sind, dass sie durch ein VPN (anstelle/zusätzlich von HTTPS) geschützt werden müssen - möchte man solche Dienste dann nicht lieber intern betreiben? Ich selbst hab mir derweil ein Synology NAS gekauft und über Docker einige Dienste wie z. B. GitLab lokal installiert. Klappt absolut problemfrei, sogar mit HTTPS etc. Vorteil: Ich weiß, wo die Daten liegen. Und dass mir der Speicherplatz absehbar nicht ausgeht :D

    Hier wäre vielleicht AVM gefragt, um die Fritzbox als DNS-Server nach extern auf zu machen. Dann könnte man einen NS Record aktualisieren und der Rest läuft über die Fritzbox.

    Oder geht das heute schon?

    Sowas Ähnliches geht tatsächlich schon, das ist wie gesagt dieses MyFritz. Registriert man sich bei diesem Dienst, erhält die FritzBox einen DynDNS-Namen (z. B. xyz.myfritz.net.). Über die Freigabe-Einstellungen der FritzBox kann man nun für einzelne Geräte eine sog. MyFritz-Freigabe einrichten. Dabei wird ein neuer DNS-Name registriert mit dem Namen des Gerätes im Heimnetzwerk. Nehmen wir an, wir reden über das Gerät mit dem Namen nas. Dann ist dieses intern über nas.fritz.box erreichbar (oder einfach über nas dank Search Domain), mit MyFritz-Freigabe erreicht man das Gerät aber auch von außen über nas.xyz.myfritz.net. Dabei löst nas.xyz.myfritz.net sowohl IPv4 als auch IPv6 auf (einstellbar).

    Oder man nutzt MyFritz, wie ich es mache: Einen CNAME-Record mit Host zB auf zuhause.example.de und als Destination qr*******tox.myfritz.net

    Ist der einfachste Weg und funktioniert einwandfrei

    Der m. E. größte Vorteil von MyFritz: Man hat (wenn man möchte) DDNS für _alle_ seine Geräte im Netzwerk. Das ist vor allem dann relevant, wenn man aktiv IPv6 nutzen möchte. DDNS-Updates für Geräte innerhalb des Netzwerks (also nicht der FritzBox selbst) werden mit der IPv4 der FritzBox, aber der IPv6-Adresse des jeweiligen Geräts vorgenommen. Ich kenne aktuell keine einzige weitere Lösung, die diesen Weg anbietet.

    Noch eine Anmerkung: Da du offensichtlich komplett neu in dem Umfeld bist solltest du, bevor du Dinge auf einer ggf. produktiven Maschine machst, eventuell lokal ein bisschen üben oder im Internet mal nach Shell-Kursen suchen (gibt es wie Sand am Meer). Da wird das von dir Gefragte und viele andere, wichtige Basics erklärt. Das beschützt dich dann vor einem zukünftigen Forenpost wie "Ich hab alles gelöscht. Und jetzt?" ;)

    Aber es schadet sicher nicht sein Interesse hier zu bekunden.

    Mit Sicherheit nicht. Das ist auch der Grund, warum nicht nicht einfach warte und lese, sondern ebenfalls hier reingeschrieben habe ;)


    Naja, schauen wir mal was passiert. Bin sehr gespannt.

    Mh. Du erlaubst root-Zugriff per SSH? Ist zum Beispiel eine Sache, die ich auch grundsätzlich nicht mache. Man brauch etwas, was nur ich besitze (meinen private key (in Form des YubiKey) für den normalen SSH-Login) und dann etwas was nur ich kenne (mein Passwort) für ein sudo. Also root nur über so etwas wie 2FA. SSH für root offen ist - egal wie per Firewall eingeschränkt - m. E. mutig.


    Ich hab bei mir grundsätzlich root-Login per SSH deaktiviert, außerdem gibts bei mir auch für SSH kein PW-Auth, nur PublicKeyAuth...

    Hallo,


    ich wollte mich hier mal für die Möglichkeit bedanken, beim CCP 2FA aktivieren zu können. Aus Einfacheitsgründen wäre es aber sehr praktisch, wenn man, nach erfolger Einrichtung des Code-Generators (wie z. B. Google Authenticator) auch ein U2F-Token registrieren könnte. Damit wäre der Login-Vorgang noch komfortabler.


    Viele Grüße

    Matthias

    Ganz knapp wie es bei mir ist:

    • SSH läuft bei mir über den gpg-Agent, damit ich meinen YubiKey benutzen kann; sprich mein PrivateKey ist am Schlüsselbund -> 3 Passwort-Versuche (bzw. 6) dann für immer unbrauchbar. Dieser Key gilt als "personengebunden" ist also überall der selbe.
      • Dann habe ich Backups-Keys je Kunde auf einer verschlüsselten Festplatte zu Hause (gelten für mich also nicht als personengebunden; deshalb je Kunde unterschiedlich)
    • Bastion-Host (das man sich über einen zentralen Server auf die anderen tunnelt) - Grund dafür ist übrigens, dass ich dort ansible benutze - der personengebundene Key ist sowieso auf jedem Server
    • backups werden "gepullt"; also vom Backup-Server "abgeholt" / angefertigt

    Was ich noch möchte ist, dass meine Server auch per VPN verbunden sind (tinc hatte ich da mehrmals gelesen), damit interne Wartungsdienste wie SSH nur noch auf das entsprechende Interface lauschen und so die Angriffsfläche weiter verringert wird.

    Ich hab das Ganze sehr ähnlich gemacht - nur sind meine Backup-Keys auch wieder YubiKeys. Einen davon trage ich am Schlüsslebund, und der ist immer in meiner Nähe. die anderen beiden YubiKeys sind ohne besondere Kennzeichnung in einem Briefumschlag in Safes gelegt. Alle YubiKeys haben verschiedene PINs/PUKs. Gleichzeitig verwende ich auf allen Servern sowohl SSH Agent Forwarding als auch GPG Agent Forwarding (https://mlohr.com/gpg-agent-forwarding/). Das ermöglich mir, selbst auf Remote-Systemen z. B. Git Commits zu signieren oder Daten zu entschlüsseln, ohne, dass der Private Key jemals übers Netz gehen müsste (bzw. gehen kann, der YubiKey spuckt den nämlich nie wieder aus).