OPNsense mit Caddy, VLans für 3CX, Nextcloud, Rustdesk, usw. sinnvoll und sicher

[spooner.arthur]

Hallo Zusammen,
bisher ist nur die 3CX direkt von außen, übers Internet, erreichbar.
Alle anderen Dienste sind nur über VPN zugänglich.
Jetzt stehen aber ein paar Umstellungen an und es gibt Überlegungen verschiedene Dienste direkt online verfügbar zu machen.
Es gibt eine öffentliche externe IP-Adresse.

Jetzt zum möglichen Szenario:
Auf der OPNsense den Caddy installieren, als reverse Proxy für den Zugriff auf die Nextcloud und eventuell weitere Dienste einrichten.
Für jeden Dienst ein eigenes Vlan anlegen, eins für die Telefonie (bereits vorhanden), eins für die Nextcloud, Mailcow, usw.

Macht das Sinn?
Und noch viel wichtiger, ist es dann überhaupt sicherer?
Was meint ihr?

Viele Grüße
Arthur

[spooner.arthur]

Ach so, noch ein Hinweis:
alle Server / Dienste laufen auf einem Proxmox Host

[ATL]

Macht das Sinn?

Wenn die Dienste von außen erreichbar sein sollen, dann sicherlich. Ich nutze den HAProxy in der OPNsense dafür. Der regelt den Zugriff auf die intern definierten Dienste.

Und noch viel wichtiger, ist es dann überhaupt sicherer?

"Sicherer" als was? VPN? Nein.

[viragomann]

Jetzt stehen aber ein paar Umstellungen an und es gibt Überlegungen verschiedene Dienste direkt online verfügbar zu machen.

Überlegungen?
Die Frage sollte sein, ob es eine Notwendigkeit dafür gibt.

Falls ja, ist Segmentieren ein guter Weg, um das Angriffspotential zu verringern, weil es die VMs von anderen eventuell kompromittierten je nach FW-Regeln schützen kann.
Also Nextcloud und Mailcow in eigene Netzwerksegmente zu setzen, halte ich schon für sinnvoll.

Aber inwiefern dir hierbei Caddy oder ein anderer Reverse-Proxy helfen kann, ist mit nicht klar.
Caddy kann eine externe IP:Port-Kombination auf unterschiedliche interne weiterleiten, entweder auf Basis von HTTP-Analysen oder SNI, und ggf. kann er Zugriffe auch einschränken. Aber bei dir nutzt anscheinend ohnehin jeder Service eine anderen interne IP.
Einzig die Anzahl der Verbindungen auf die Backends kann er einschränken, um sie vor DDoS-Angriffen zu schützen.

[ATL]

Aber inwiefern dir hierbei Caddy oder ein anderer Reverse-Proxy helfen kann, ist mit nicht klar.

Nun ja, der sorgt dafür, dass die internen Dienste (unabhängig von deren IP / Port) über die externe IP basierend auf dem DNS-Namen erreichbar sind. Das ist bei mir die Aufgabe des HA-Proxy. Intern werden die Dienste über den DNS-Server der OPNSense mit ihren privaten IPs aufgelöst und extern zeigen deren DNS-Namen auf die WAN-IP, wo der HA-Proxy dann das weiterleiten an die interne Adresse übernimmt.

[viragomann]

Nun ja, der sorgt dafür, dass die internen Dienste (unabhängig von deren IP / Port) über die externe IP basierend auf dem DNS-Namen erreichbar sind.

Und eben die Sinnhaftigkeit dessen habe ich hinterfragt.

Sämtliche oben aufgezählten Dienste verwenden standardmäßig verschiedene und eindeutige Ports. Je nach Client braucht der nicht angegeben zu werden oder doch.
Wird er nicht angegeben könnte der konkrete Service über SNI oder HTTP-Header ermittelt werden. Hab ich auch oben geschrieben, damit der TO selbst beurteilen kann, ob das für ihn Sinn macht.
Für nur einen Webserver, einen Mailserver und 3CX sehe ich aber keine unbedingte Notwendigkeit.

Intern werden die Dienste über den DNS-Server der OPNSense mit ihren privaten IPs aufgelöst und extern zeigen deren DNS-Namen auf die WAN-IP, wo der HA-Proxy dann das weiterleiten an die interne Adresse übernimmt.

Pakete weiterleiten kann OPNsense auch nativ, und für mehr verwendest du HAproxy offenbar nicht, weil interne Verbindungen umgehen ihn ja. So hat er nur für externe Verbindungen Nutzen.
Ich vermute aber, du hast mehrere Webserver auf verschiedenen internen Hosts. Dann macht ist ein Reverse-Proxy natürlich eine Lösung.

Du könntest in Erwägung ziehen, die betroffenen Hosts aus dem internen DNS raus zu schmeißen und HAproxy auch für interne Verbindungen zu nutzen. So kommst du bspw. in den Genuss der öffentlichen SSL Zertifikate, ohne sie auf das Backend kopieren zu müssen.
Auch weitere Funktionen (bspw. URL-Rewrites) könnte HAproxy dann übernehmen, die gleichermaßen für externe und interne Verbindungen gelten. Auch Filter kann man einbauen, die bspw. Zugriff auf bestimmte Zielpfade nur internen Quellen erlauben.
Aber das sollte in diesem Thread eigentlich nicht behandelt werden.

[spooner.arthur]

Vielen Dank für die Rückmeldungen.

Also es ist außer Frage, das der Zugriff über VPN der sicherste Weg ist.

Mir ging es darum ob die verschiedenen VLans das ganze Konstrukt sicherer macht.

Also, es gibt zwei Proxmox Hosts im Cluster und darauf laufen mehrere Server, Docker Container.

Der Reverse Proxy soll einfach auch noch eine zusätzliche Sicherheit bieten und er könnte auf Grund der nur einen vorhanden externen IP-Adresse eventuell auch noch das Routing übernehmen.

Ist der HAProxy besser als der Caddy?
Sollte ich mir diesen mal anschauen?

Klar, am besten wäre es, wenn der Zugriff von intern und extern vollständig identisch ist, also gleiche externe URL und Port.

[ATL]

Du könntest in Erwägung ziehen, die betroffenen Hosts aus dem internen DNS raus zu schmeißen und HAproxy auch für interne Verbindungen zu nutzen. So kommst du bspw. in den Genuss der öffentlichen SSL Zertifikate, ohne sie auf das Backend kopieren zu müssen.

Das ist nicht nötig, da ich eine interne CA habe, die Zertifikate á la LetsEncrypt ausliefert. Dadurch ist intern alles per SSL abgesichert, auch wenn es nicht von außen erreichbar ist. Und interne Dateitransfers (z.B. Nextcloud) gehen dann nicht über die Firewall, sondern direkt zum Server.

Ist der HAProxy besser als der Caddy?

Keine Ahnung. Der HA-Poxy ist ein OPNsense-Plugin und daher besser integriert. Beim Caddy weiß ich das nicht. Aber wenn du dich mit Caddy auskennst, kommst du ggf. besser zurecht.

Der Reverse Proxy soll einfach auch noch eine zusätzliche Sicherheit bieten

Nein, mehr Sicherheit bietet tatsächlich eher das VPN, da das den Zugriff nur für dessen Benutzer auf die Services begrenzt. Wenn du die Services von außen per Reverse-proxy erreichbar machst, musst du für jeden Service sicherstellen, dass nur authorisierte Benutzer Zugriff bekommen und es keine Sicherheitsprobleme gibt. Beim VPN ist das Risiko geringer, da nur das VPN der Allgemeinheit ausgesetzt ist.

[viragomann]

Also es ist außer Frage, das der Zugriff über VPN der sicherste Weg ist.

Nicht der ganzen Welt Zugang zu gewähren ist natürlich sicherer, aber wenn Dienste von außen od. von Leuten, denen man keine VPN zumutet, erreichbar sein sollen, muss eben ein Kompromiss eingegangen werden. Netzwerksegmentierung nach Sicherheitsbereichen ist dann schon zu empfehlen. Wenn das Netzwerk ohnehin virtualisiert ist, ist das kein großer Aufwand.

Du kannst aber auch VPN und Reverse-Proxy kombinieren. Hab ich auch so im Einsatz. Zu gewissen Backends bzw. gewissen URL wird nur Zugriff via VPN oder von internen Quellen erlaubt.

Der Reverse Proxy soll einfach auch noch eine zusätzliche Sicherheit bieten

Das kann er gewiss, allerdings braucht es eine tiefer gehende Konfiguration.
In der Grundkonfiguration leitet der Reverse-Proxy sämtliche Anfragen and das Backend weiter, ohne irgendetwas zu filtern. Caddy hat nicht einmal ein Verbindungslimit. So bietet das keinen tatsächlichen Sicherheitsgewinn.

Es kommt also darauf an, wieweit du bereit bist, dich in die Sache zu vertiefen.
Du kannst den Reverse-Proxy bspw. auch mit Crodsec verbinden, so dass es die Logs bekommt und Angriffe erkennen und blocken kann.

Ist der HAProxy besser als der Caddy?

HAproxy bietet umfangreichere Funktionen. Ob das ein Segen oder Fluch ist, hängt vom beabsichtigten Einsatzzweck ab. Es bereitet auch deutlich mehr Aufwand, HAproxy zu konfigurieren.

Caddy ist da rascher eingerichtet. Er bringt bspw. auch gleich einen integrierten ACME Client mit, der SSL-Zertifikate für die definierten Domönen von LE zieht, wenn man das möchte.
Die nötigsten Funktionen eines Reverse-Proxy bietet Caddy auch wie ACL, Authentifizierung, HTTP Header-Manipulation, URL-Umleitung.

Ich verwende beide, HAproxy in einer komplexeren Umgebung, Caddy zuhause.

[Patrick M. Hausen]

Caddy ist ebenfalls ein OPNsense Plugin, das mit sinnvollen Defaults daher kommt und Ingress mit TLS und Letsencrypt/ACME mit sehr wenig Konfigurationsaufwand realisiert.

[spooner.arthur]

Ich hab in einer Umgebung mal den Caddy als Plugin in der OPNsensen gesehen und mir kurz gezeigt wie einfach er eingerichtet werden kann.
Und das mit den Zertfikaten ist ja super und macht die Sache auch einfacher.
Wenn man jetzt noch bestimmte URLs sperren kann, dann denke ich sollte er auch das machen was ein HAProxy kann, hoffe ich zumindest.
Damit meine ich z.B. wie bei Wordpress, dasn /wp-admin nicht von außen aufrufbar ist.

Aber wenn der HAProxy sich Sache sicherer macht, dann muss ich mich damit mal beschäftigen.

Was ich noch nicht weiß, ist wie ich in der OPNsense einstelle, dass der Zugriff auf interne Ressourcen den selben Weg geht, als wenn der Zugriff von Außen kommt.
Also zumindest, wenn ich z.B. andere Ports verwende, z.B. statt 443 dann 1443.

[viragomann]

Wenn man jetzt noch bestimmte URLs sperren kann, dann denke ich sollte er auch das machen was ein HAProxy kann, hoffe ich zumindest.
Damit meine ich z.B. wie bei Wordpress, dasn /wp-admin nicht von außen aufrufbar ist.

Ja, habe ich auch konfiguriert.
Du kannst ACLs anlegen mit erlaubten IPs od. Subnetzen und dann einen Handler für den Pfad /wp-admin, der diese ACL anwendet.

Aber wenn der HAProxy sich Sache sicherer macht, dann muss ich mich damit mal beschäftigen.

Ich denke nicht bis auf das Verbindungslimit, was eine Überlastung des Webservers durch DDoS Angriffe verhindern kann.

Was ich noch nicht weiß, ist wie ich in der OPNsense einstelle, dass der Zugriff auf interne Ressourcen den selben Weg geht, als wenn der Zugriff von Außen kommt.

In dem du am besten die betroffenen Domänen nicht im internen DNS überschreibst, wie schon oben geschrieben.
Dann wird die Domäne entsprechend dem öffentlichen DNS aufgelöst und das Paket wird zur WAN IP geschickt. Wenn es der Reverse-Proxy laut seiner Konfiguration auf einen bestimmten internen Port weiterleitet, macht er das natürlich auch für Zugriffe von intern.

Es scheint da eine gewisse Abneigung zu bestehen, von intern auf die WAN IP zuzugreifen.. Besonderheiten hier gibt es aber nur normalem Port Forwarding. Bei Einsatz eines Reverse-Proxy funktioniert das völlig normal. Lediglich die FW Regeln müssen den Zugriff auf die WAN IP erlauben.
Und ja, die Firewall kann grundsätzlich von allen Interfaces aus mit all ihren IPs angesprochen werden, wie jeder andere Rechner auch.