Docker auf RootServer

    Moin,


    ich habe mir einen RootServer geholt.

    Aktuell sitze ich an einem Problem, bei dem ich eine Lösung habe, aber nicht weiß, ob diese so in Ordnung ist.


    Problem:

    Meinen Server steuere ich mit ufw, damit alle unwichtigen Ports zu sind. Ich habe einen Wireguard laufen, um interne Dinge auf dem Server zu tun.

    Ich habe Docker auf dem Server installiert. Mit Docker Compose habe ich einen Nginx Proxy Manager (NPM) am Laufen. Nun das Problem, dadurch dass keine weitere Firewall vor dem Server geschalten ist, wird jeder Port den man in der Compose-Datei angibt über die IPTables aufgemacht. Bei einem NPM sind die Standardports 80,443 und 81. Den Port 81 würde ich gerne schützen und diese soll nur über den Wireguard erreichbar sein.


    Wireguard ist wie folgt auf dem Server konfiguriert:


    Der Client ist wie folgt konfiguriert:


    Code
    [Interface]
Address = 10.8.0.3/32
DNS = 1.1.1.1
PrivateKey = KEY

[Peer]
PublicKey = KEY
AllowedIPs = 0.0.0.0/0
Endpoint = SERVER:64000
PersistentKeepalive = 25

    Damit ich nun den Port 81 über Wireguard erreich kann. Habe ich in der Compose-Datei von NPM die folgende Zeile hinzugefügt

    ...

    Ports:

    - '10.8.0.1:81:81'


    Das funktioniert, aber irgendwie finde ich das Falsch.


    Ich würde die Portfreigabe gerne über ufw steuern. Docker kann gerne die Ports öffnen, aber ich würde die gerne mit, z.B. sudo ufw deny 81/tcp sperren.

    Kann mir einer sagen, ob das eine gute Lösung ist oder gibt es eine bessere?


    Ich würde gerne einen Mailserver mit Mailcow installieren, aber aktuell kann ich mir das nicht vorstellen, da ich nicht die komplette Kontrolle habe.


    Für Tipps und Tricks bin ich gerne offen.

    Falls es Fragen zu meinem Problem gibt, bitte sofort raus damit.


    Danke im Voraus,

    Robert

    Also entweder hast du uns nicht alles verraten, oder die Konfiguration macht so keinen Sinn.


    Einige Fragen: Warum macht der Server NAT, und warum wird im Client der ganze Internetverkehr über VPN geleitet, wenn es nur darum geht, Port 81 auf dem Docker zu erreichen? Wofür IPv6 Regeln, wenn es gar keine IPv6 Adressen im Tunnel gibt? Waum ist die Allowed IP im Server 10.8.0.2/32, während die Adresse des Clients 10.8.0.3/32 ist? Es wird nie ein Paket den Client erreichen.

    Zitat von h725rk

    Damit ich nun den Port 81 über Wireguard erreich kann. Habe ich in der Compose-Datei von NPM die folgende Zeile hinzugefügt

    ...

    Ports:

    - '10.8.0.1:81:81'

    Das ist gefährlich. Existiert der VPN Tunnel nicht, scheitert der Docker Aufruf. Das ist besonders nach einem Reboot gerne der Fall. Öffne Port 81 einfach nur lokal und erlaube den Zugriff aufs Docker Interface über die Allowed IPs des Tunnels.


    Zitat von h725rk

    Ich würde die Portfreigabe gerne über ufw steuern. Docker kann gerne die Ports öffnen, aber ich würde die gerne mit, z.B. sudo ufw deny 81/tcp sperren.

    Kann mir einer sagen, ob das eine gute Lösung ist oder gibt es eine bessere?

    Ja. Öffne den Port gar nicht erst auf dem WAN Interface. Mach eine Weiterleitung, falls nötig. Aber das sollte bei einem Zugriff über den Tunnel nicht nötig sein.

    Gute Fragen, kann ich dir wirklich nicht beantworten. Ich habe für wireguard eine Anleitung verwendet. Diese ist wohl falsch. Ich habe sonst scripte für wireguard verwendet, aber auf diesen Server wollte ich alles selber konfigurieren.


    Ich denke, ich muss wohl das ganze Konzept nochmal überarbeiten.

    Zitat von h725rk

    Gute Fragen, kann ich dir wirklich nicht beantworten. Ich habe für wireguard eine Anleitung verwendet.

    Deshalb sage ich immer, nie eine Anleitung blind abtippen. Lesen, verstehen, auf die eigene Situation adaptieren, umsetzen.



    Zitat von h725rk

    Ich denke, ich muss wohl das ganze Konzept nochmal überarbeiten.

    Das Konzept ist ok, die Umsetzung ist schlecht. In erster Linie solltest du den VPN Tunnel umbauen.

    Zitat von frank_m

    Deshalb sage ich immer, nie eine Anleitung blind abtippen. Lesen, verstehen, auf die eigene Situation adaptieren, umsetzen.



    Das Konzept ist ok, die Umsetzung ist schlecht. In erster Linie solltest du den VPN Tunnel umbauen.

    Kannst du mir sagen, auf was ich achten sollte?

    Du solltest nur die Funktionen aktivieren und nur den Datenverkehr durchs VPN leiten, den du wirklich brauchst. Also wenn es nur um den Zugriff auf Docker geht, dann weg mit den NAT Regeln und der Defaultroute, dafür das Docker Netz in die Allowed IPs aufnehmen.

    Ja, aber nur der Server. Der VPN Client soll ja nicht über den Tunnel ins Internet gehen. Was du auf dem Server erreichen kannst, kannst du ja sehr einfach über die Allowed IPs und Firewallregeln beeinflussen.

    Ich habe die Config von Wireguard mal angepasst. Ich kann eine Verbindung aufbauen, aber ich komme nicht mehr mit SSH drauf:

    Am Client habe ich nicht verändert. Bei der SSH Config habe ich noch folgendes aktiviert:

    Code
    ...
ListenAddress ÖffentlicheIP
ListenAddress 10.8.0.1
...


    An der Config vom Client habe ich nichts verändert


    Ich habe es mit der öffentliche Adresse und mit der internen Adresse von Wireguard.

    Muss ich in den IPTables noch was freigeben?

    Du solltest deine Configs vor dem Abspeichern immer auf Konsistenz prüfen. Zum Beispiel sieht man hier auf den ersten Blick, dass die "Address" in der Server Konfig ein Subnetz ist und keine Adresse. Das darf natürlich nicht sein und wird in der Folge auch nicht funktionieren. In der SSH Konfig hast du es hingegen richtig gemacht, womit auch direkt deutlich wird, dass die beiden nicht zusammen passen.


    Und dann sind da immer noch NAT Regeln in der Server Konfig und die Default Route im Client. Beides ist Unsinn für deinen Anwendungsfall.


    Wenn du SSH auf der öffentlichen Adresse lauschen lässt, solltest du einige Sicherheitsmaßnahmen ergreifen: Anderer Port (nicht 22), keine Anmeldung via Passwort, nur per Zertifikat, und fail2ban sollte sauber laufen. Dann musst du natürlich den Port in der Firewall freigeben.

    OK, also folgendes muss ich machen:

    - eine feste IP vergeben

    - Das mit dem NAT verstehe ich nicht, sind das die PostUp und PostDown Regeln und diese sollte ich löschen?

    - Was meinst du mit Default Routes im Client. Sind das die AllowedIPs?


    Zum Thema SSH.

    Das ist abgesichert.
    - Anderer Port

    - root deaktiviert

    - ssh gehärtet mit ssh audit

    - Public-Key-Verfahren integriert

    - TOTP ist auch aktiv

    - Und zu guter Letzt, crowdsec ist eingerichtet und läuft


    Dafür habe ich einige Zeit benötigt, aber ich denke es ist ordentlich abgesichert.

    Zitat von h725rk

    - Das mit dem NAT verstehe ich nicht, sind das die PostUp und PostDown Regeln und diese sollte ich löschen?

    - Was meinst du mit Default Routes im Client. Sind das die AllowedIPs?

    Du administrierst einen vServer, der öffentlich aus dem Netz erreichbar ist. Wenn du das nicht weißt, dann ist das hier:

    Zitat von h725rk

    Zum Thema SSH.

    Das ist abgesichert.

    garantiert gelogen. Es nützt nichts, SSH abzusichern, wenn du dann hintenrum wieder haufenweise Lücken einbaust.



    Zitat von h725rk

    - Das mit dem NAT verstehe ich nicht, sind das die PostUp und PostDown Regeln und diese sollte ich löschen?

    Ob du da alles löschen darfst, weiß ich nicht. Die NAT Regeln auf jeden Fall, aber dafür brauchst du vielleicht andere, die jetzt noch nicht drin sind. Anleitung lesen, verstehen, auf die eigene Situation adaptieren, umsetzen.


    Zitat von h725rk

    - Was meinst du mit Default Routes im Client. Sind das die AllowedIPs?

    Momentan steht die Default Route in deinen Allowed IPs. Das sollte für deinen Anwendungsfall aber nicht so sein. Grundlagen IP Routing.

    OK, das kann hier geschlossen werden.

    Ich lasse mich nicht als Lügner bezeichnen, nur weil ich von einer Software (Wireguard) mal keine Ahnung habe und Hilfe benötige.


    Danke für die Antworten, aber ich bin erstmal raus.

    Zitat von h725rk

    Ich lasse mich nicht als Lügner bezeichnen, nur weil ich von einer Software (Wireguard) mal keine Ahnung habe und Hilfe benötige.

    Wenn du nur von Wireguard keine Ahnung hättest, dann wäre es ja nicht so schlimm. Aber es ist ja offensichtlich, dass du von IP, Routing und Firewalls keine Ahnung hast. Wie willst du dein System schützen, wenn du nicht weißt, welchen Weg die Datenpakete in dein System nehmen? Wie soll das gehen?


    Du musst hier nicht antworten. Beantworte dir einfach nur ehrlich diese Frage abends vorm Spiegel, und dann beurteile selber, ob es eine gute Idee ist, einen vServer öffentlich am Netz zu betreiben, oder ob du nicht besser noch einige Monate mit einer VM zu Hause übst.

    Ich klinke mich hier ein, da uns in der Moderation eine Beschwerde über den Umgangston erreicht hat.
    Während man hier auf der einen Seite direkt ausgedrückte Besorgtheit herauslesen kann, ist nach Prüfung und Abstimmung auch nachvollziehbar, dass sich die Formulierungen teils unfreundlich lesen lassen.

    Wir befinden uns hier in einem Online-Forum ohne Tonalität und Mimik, was das Interpretieren vom Geschriebenen oft schwieriger macht, als es in persönlichen Gesprächen bereits der Fall ist.

    Das Einzige, das wir hier als allgemeinen Tipp geben können ist: Sollte sich jemand mal im Ton vergreifen zu versuchen nicht vom Schlimmsten auszugehen und weiters, wenn möglich, nur auf den Inhalt, nicht aber auf die (vermeintliche) Tonalität zu reagieren.

    In diesem Sinne versucht einander gerne erneut anzunähern. Wenn das nicht gelingt, gibt es für jedes Mitglied im Worst Case auch die Möglichkeit bestimmte andere Mitglieder zu blockieren, um die Nachrichten des anderen nicht mehr angezeigt zu bekommen.

    Zitat von h725rk

    Vielen Dank, das hat mir geholfen.

    Wireguard ist erstmal kein Thema mehr für mich.

    Das WireGuard kein Thema mehr für Dich ist, ist schade. WireGuard hat einige Eigenheiten über die man auch stolpern kann wenn man Ahnung von Firewalls, Routing und Co hat. Ich wollte gerne etwas konstruktives beitragen daher:


    WireGuard erstellt die Routen anhand der AllowedIPs Einstellung eines Peers, steht dort 0.0.0.0/0 wird alles über das wg-Interface geleitet. Ob die Gegenstelle also in dem Fall der Server das auch akzeptiert steht dort in der [Peer] Konfiguration ebenfalls in den AllowedIPs.


    In Deinem Fall wäre wichtig, das in der Interface-Konfiguration immer eine IP und kein Subnet stehen sollte wie frank_m zuvor bereits geschrieben hat.

    Hat dein Server in der Interfacekonfiguration z.B. die IP 10.8.0.1/24 eingetragen und dein Client die 10.8.0.2/24, könnte in den AllowedIPs des Clients die 10.8.0.0/24 stehen sodass der Traffic für dieses Subnet über den Tunnel geleitet wird. In der [Peer] Konfiguration des Servers könnte dann als AllowedIP die 10.8.0.2/32 stehen. Somit kann dein Client den Server und ggf. andere Peers im selben Subnet erreichen. :)


    PS: Ich finde der Lernaufwand für WireGuard lohnt sich, das Cryptokey-Routing ist faszinierend und ich hoffe das funktioniert so für Dich!

    PPS (Edit): Ich hatte irgendwann mal mit dieser Anleitung begonnen, die fand ich ganz hilfreich am Anfang.