Beiträge von mlohr

  • Auseinandersetzungen im Forum schlichten

    Wenn man Auseinandersetzungen schlichten muss, ist vorher schon viel falsch gelaufen. Besser sind die Auseinandersetzungen, die es nicht gibt (ich rede hier von persönlichen Auseinandersetzungen, fachliche Auseinandersetzungen, auch Diskussionen genannt, begrüße ich!). Von daher gilt es, denke ich, solche Auseinandersetzungen, die geschlichtet werden müssten, einfach zu vermeiden.

    Ich würde das etwa so sehen: Jeder von uns hat mal "klein" angefangen, unabhängig vom aktuellen Start. Und die meisten von uns werden irgendwann auch mal gedacht haben "wohoo, cool ein eigener Server!". Man spielt rum, macht Fehler, lernt daraus, sammelt Erfahrung. Jeder hat (mMn.) das Recht darauf, Fehler zu machen. Wenn jemand ein System mit offenen Scheunentoren in die Welt setzt, ist das auch sein gutes Recht. Keiner von uns wird gezwungen, das zu nutzen. Deswegen jemanden bösartig zu beschimpfen, halte ich für falsch. Auch ein Mathelehrer verlang nicht von Erstklässlern, dass sie bereits Integralrechnung können. Und beschimpft werden sie deswegen auch nicht. Wenn jemand Frust ablassen möchte, dann bitte im Fittnessstudio o. Ä. oder Sexualpartner, aber nicht hier. Dafür ist ein Forum generell die falsche Adresse. Umgekehrt kann ein Anfänger auch nicht verlangen, dass man ihm alles erklärt, oder sogar umsetzt. Von daher wäre vielleicht eine Sammlung guter Tutorials ganz gut (irgendwo festgepinnt, "wie starte ich mit einem eigenen Server. Schritt 1: Firewall.").

    Wenn sich jemand hier von dem, was Anfänger tun (und ja, NetCup ist ein Prima Spielplatz für Anfänger, da einfach und kostengünstig), bedroht fühlt, sollte er überlegen, ob seine Systeme so schlecht konfiguriert sind, dass es wirklich ne Bedrohung ist. Oder zu einem anderen Hoster o. Ä. gehen, bei dem ausschließlich die Profis sind.

    Zusammengefasst:

    • Keine verbalen Angriffe. Lieber mal nicht auf einen (fragwürdigen) Post antworten, als unsachlich zu sein.
    • Konstruktive Kritik statt destruktiver: Zeigt demjenigen auf, wie er sich verbessern kann (Linksammlung?)
    • Eigene Systeme absichern: Es ist wurscht, ob ein infiziertes, unsicheres System weit weg oder direkt "nebenan" steht: Die Profi-Server hier sollten das ohnehin abkönnen ;)
    • Wir sind alle Menschen. Jeder hat mal klein angefangen. Jeder hat schon Fehler gemacht.

  • Froxlor ohne Klartext-Passwörter

    Moin,

    ich versuche gerade, Froxlor so sicher wie möglich zu bekommen. Dazu gehört m. E. auch das Entfernen von Klartext-Passwörtern aus der Datenbank, die Froxlor für Dinge wie z. B. SMTP/IMAP/POP3-Authentifizierung haben möchte. In der Tabelle mail_users gibt es ein Feld für Klartext-Passwörter. Welche Möglichkeiten gibt es, eine sichere Mail-Authentifizierung auch ohne diese Klartextpasswörter zu realisieren?

    Für mich ergibt sich da auch die Frage: Was ist sicherer: Klartext-Passwörter in einer Datenbank oder Klartextpasswörter auf dem Übertragungsweg? Gibt es eine Möglichkeit, beides loszuwerden?

    Viele Grüße

    Matthias

    P.S.: Ja, ich kenne die Sicherheitseinstellung, keine Klartextpassworte zu speichern. Das ist aber nicht das, worauf ich hinaus möchte.

  • "Virtuelles" Intranet

    Zitat von Gunah

    Komfort steht ja immer im Konflikt mit Sicherheit :)

    Das "immer" würde ich vorsichtig zu einem "oft" ändern, aber ansonsten: Die Frage ist halt, was man schützen will, und wie lohnenswert das Ziel ist. Ich glaube schon (sry Hecke29), dass ein großer deutscher Luftfahrtkonzern das lohnendere Angriffsziel ist und demnach gewisse Maßnahmen dort sinnvoller sind als in einer Firma, die gerade darüber nachdenkt, eine ähnliche Infrastruktur hochzuziehen damit sie den 2. Mitarbeiter einstellen kann ;)

  • "Virtuelles" Intranet

    Zitat von Gunah

    bezüglich "Updates und VLAN", du kannst doch nen Proxy welcher im Netz is installieren und die Updates über diesen ziehen?

    Richtig, so wirds ja auch (bei Konzern-Intranets) gemacht. Irgendwie beschleicht mich das Gefühl, dass das für das Anliegen von Hecke29 ein klein wenig overkill sein könnte...

  • "Virtuelles" Intranet

    Zitat von Hecke29

    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.

  • "Virtuelles" Intranet

    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-tells-s…r-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.com/articles/2017/…nprotected.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.

  • "Virtuelles" Intranet

    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

  • Eigener DynDNS Dienst

    Zitat von felix.kretschmer

    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).

  • Eigener DynDNS Dienst

    Zitat von ocin4

    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.

  • Einrichtung Server, SSH

    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?" ;)