"Virtuelles" Intranet

  • Hecke29 und mlohr


    naja Overkill würde ich nicht sagen, das vorhaben kann ich an sich schon verstehen.

    Es wird einfacher die Fehler / Sicherheitsrisiko durch die Restriktion verkleinert.


    Sprich Sicherheitslücken Patchen etc.

    klar geht durch Docker und co vieles einfacher als vorher, aber man kann so für extra Sicherheit sorgen.


    Komfort steht ja immer im Konflikt mit Sicherheit :)

  • 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 ;)

  • Hay,

    Wir stehen bei netcup kurz vor der Veröffentlichung von kostenlosen VLANs.

    Huch, das kam überraschend. Und positiv.

    Wobei VLAN ja erstmal nicht unbedingt gleich VPN istund es auf die Ausgestaltung ankommt.

    Ich bin gespannt. Weil mir da spontan eine Menge einfällt, was ich tun könnte und bislang anders (intern) realisiere.


    CU, Peter

  • Vor allem wenn es ein kostenloses internes VLAN gibt, besteht ja vielleicht die Möglichkeit das es irgendwann günstige (<1€) Server gibt ohne öffentliche IPv4 (und IPv6?), die nur im internen VLAN erreichbar sind :/ Sowas wie die VPS10/20/50 Reihe 8) Bin ich mal gespannt, aber das geht jetzt zu weit Off-Topic.


    Davon ab dürfte ein internes VLAN doch enorm helfen ein "komplettes VPN" aufzubauen, weil du dich "nur noch" um die Verbindung VLAN <-> Heimnetz/PC/Endgerät kümmern musst. Außerdem würde ich Ausfallrate/Performance eines VLANs als besser einschätzen im Vergleich zu einer Lösung mit tinc/openVPN.

  • Um das jetzt nicht unerwähnt zu lassen:

    Im Kern ging es mir ja um den Schutz der Anwendungen.


    Ein VLAN (bzw. bisher tinc) war ja von Anfang an eigentlich nur dazu da, dass die Anwendungen auf verschiedenen Systemen laufen können. Also war die Ausgangsfrage wie ein autorisierter Benutzer in das Netz kommt. Meine Lösung ist jetzt vorerst: Gar nicht. Seine Anfragen kommen über einen zentralen Entry-Point in das Netz.


    Das habe ich jetzt so erreicht, dass diese Anwendungen hinter einem nginx-Reverse-Proxy liegen, der Client-Zertifikate erzwingt.

    So ein Client-Zertifikat ist schnell auf einem zu autorisierenden Gerät einspielbar (und auch kompatibel mit git) und schützt die Anwendungen trotzdem in einem Maße vor "zufälligen" Angriffen, das mir zusagt und mein Sicherheitsbedürfnis befriedigt.

    Die Anwendungen selbst sehen dann ja noch das übliche personenzegogenen Username & Passwort-Gelöt zur Authentifizierung vor.

  • Ich werfe eben auch nochmal mit meinem Senf um mich.


    Ich regel das so. Auf meinem Hypervisor @ Office / Home läuft tinc. Genauso auf jedem anderen Server auch.

    Dementsprechend gibt es immer eine Verbindung zu den lebenden Hosts und ich kann mich aufgrund der "Verteilung" von tinc nicht aussperren, wenn ich einen Host abschieße. Routen auf meinen Standard-Gateways und ein "lokaler" DNS Resolver für das Netz. Fertig. :)


    lg.

  • Da bin ich aber mal gespannt. Auch ob man noch zusätzliche NICs braucht dafür.

    Benötigt eine zweite NIC. Die kann man aber über das SCP auf die entsprechenden Server buchen nachdem man das Paket bestellt hat und es eingerichtet wurde. Erfordert aber auch das man nach einhängen der zusätzlichen NIC den Server per ACPI herunterfährt und dann über selbiges wieder hochfährt.

    Bin gerade selbst bei der Konfiguration.

  • Benötigt eine zweite NIC. Die kann man aber über das SCP auf die entsprechenden Server buchen nachdem man das Paket bestellt hat und es eingerichtet wurde. Erfordert aber auch das man nach einhängen der zusätzlichen NIC den Server per ACPI herunterfährt und dann über selbiges wieder hochfährt.

    Bin gerade selbst bei der Konfiguration.

    Ah ACPI nimmt man da am Besten. Ich hatte zuletzt immer per SSH den shutdown gemacht und dann erzwungen abgeschaltet. Dann spare ich mir das das nächste Mal doch.


    Ich habe auch schon angefangen zu konfigurieren, wegen St. Martinsumzug bin ich aber noch nicht dazu gekommen einen weiteren Server neu zu starten um das VLAN Interface zu kriegen.

  • "Aftermath" zu meiner eigentlichen Anfrage :D


    Es wird jetzt folgendes betrieben:

    • Confluence
    • JIRA
    • Bitbucket
    • Nextcloud

    All das läuft jeweils in einem docker-Container hinter einem nginx-reverse-Proxy.

    Dieser nginx-reverse-Proxy erfordert für alle Applikationen außer Confluence ein Client-Zertifikat einer eigenen CA.


    Probleme:

    • Die Kopplung der Atlassian-Produkte schlägt fehl, weil sie untereinander mangels Möglichkeit Client-Certs mitzuschicken nicht kommunizieren können
      1. Lösungsversuch: Als API-Target (z.B. für Bitbucket in JIRA) den internen Namen des Docker-Containers eintragen (beide Client-Cert-pflichtig). Scheiterte. JIRA kann zwar mit der Bitbucket-API reden, aber im Kopplungsprozess wird man auch automatisch auf Bitbucket geleitet, um den "Rückkanal" zu autorisieren. Dort kann man aber die API-Url nicht ändern; sie wird vorausgefüllt mit der "öffentlichen" URL. Selbiges mit Docker-Network-Interner IP statt DNS-Name.
      2. Lösungsversuch: Im nginx für die IPs des Docker-Containers kein Client-Cert erfordern. War schwieriger als gedacht, weil die ssl_client_verify-Direktive im server-Block ohne if stehen muss. Lösung: ssl_client_verify auf optional und danach per if prüfen, ob Zugriff erlaubt (siehe unten: Spoiler 1)
    • Bitbucket: HTTP-Zugriff auf die git-Repos mangels Client-Cert nicht möglich.
      1. Client-Cert für git konfigurieren. Klappt auch recht einfach. Man muss sich auf dem Client-Rechner das Zertifikat irgendwo hinlegen und kann dann in die .gitconfig sowas eintragen wie unten in Spoiler 2 zu sehen. Dann wird das Client-Cert mitgeschickt.
      2. Letztendlich war die meiner Meinung nach bessere (weil weniger aufwendig bei den Anwendern) Lösung aber Repository-Zugriff per HTTP(S) abzuschalten und nur per SSH mit Key zu erlauben.
    • Nextcloud: Endpunkte für Desktop-Client, calDAV etc. nicht aufrufbar mangels Möglichkeit Client-Certs mitzuschicken
      1. Hier fiel mir nichts anderes ein als die entsprechenden Pfade aus dem Client-Cert-Schutz rauszunehmen und per interner Policy auf Anwendungsspezifische Passwörter zu bestehen (also nicht die Original-Credentials in die Anwendungen einzutragen). Ist ein bisschen messy in der nginx-Config, deshalb möchte ich an der Stelle auf config-Code verzichten.

    Mit diesem Aufbau bin ich so zufrieden :)

    Vielen Dank an alle Beiträge hier im Thread.