Hallo!
Ich habe ein laufendes System mit einem internen Netz (192.168.0.0)
Nun würde ich gerne einen Server der von aussen erreichbar ist mit ins System bringen.
was ich schon gehört habe:
nur per Portweiterleitung
per Vlan
per DMZ
per eigenem Netz
per extra netzport an der OPNSense
und kombinationen aus diesen.
kann mir jemand helfen ?
es soll sicher sein ich aber vom bisherigen netz (192.168.0.0) administrieren kann
ach ja es sind 2 (zwei) feste Ip´s vorhanden.
Hallo,
Quote from: magicas on July 22, 2025, 05:30:12 PMwas ich schon gehört habe:
nur per Portweiterleitung
Ist unvermeidbar, falls der Server hinter der Firewall eine private IP haben soll, was empfehlenswert ist.
Quote from: magicas on July 22, 2025, 05:30:12 PMper Vlan
Falls du auf der OPNsense keinen Netzwerkport frei hast, empfiehlt sich das.
Quote from: magicas on July 22, 2025, 05:30:12 PMper DMZ
per eigenem Netz
per extra netzport an der OPNSense
Eigenes Subnetz? Das kann eine DMZ auch sein.
Quote from: magicas on July 22, 2025, 05:30:12 PMkann mir jemand helfen ?
Beim Einrichten des Netzwerks?
Das sind schon arge Basics, die eigentlich nicht Thema in diesem Forum sein sollen.
Und es hängt von deinen Möglichkeiten ab, wie oben angedeutet.
Ist der Server eine Hardwarekiste?
Hast du noch einen Netzwerkport frei, an dem du ihn anschließen kannst?
Hast du einen Switch, der VLAN unterstützt?
Quote from: magicas on July 22, 2025, 05:30:12 PMach ja es sind 2 (zwei) feste Ip´s vorhanden.
Fixe öffentliche IPs, nehme ich an.
Sind die schon auf OPNsense eingerichtet?
Helfen in form von Überlegung was am besten ist.
Der freie Port ist vorhanden und switche die Vlan können ebenfalls, die feste Ips´s sind auch eingerichtet.
mir geht es haupsächlich darum es vernünftig und so sicher wie möglich (nötig) zu machen.
Und natürlich sollte der "webserver" dann ach noch intern administrierbar sein.
Sicherheit liegt im Auge des Betrachters, was sind denn die Anforderungen?
Theoretisch ist das nur ein Port Forward, am besten wenn der Webserver in einem getrennten Netzwerksegment steht.
Für interne requests benötigt man dann entweder eine Split DNS Zone oder Hairpin NAT:
https://docs.opnsense.org/manual/how-tos/nat_reflection.html
Wenn man keine Lust auf NAT Tricksereien hat, kann man auch einen reverse proxy nehmen, gibt ein paar plugins auf der OPNsense. Ich empfehle entweder OPNWAF (Business edition) oder Caddy (Community Edition).
https://docs.opnsense.org/vendor/deciso/opnwaf.html
https://docs.opnsense.org/manual/how-tos/caddy.html
Ich mache das immer so:
Webserver in der DMZ (separater Port oder VLAN im Fall von VMs). Zugriff vom LAN in die DMZ für Administration ist erlaubt, umgekehrt nicht.
Zugriff von außen über Port 443 (Web UI der OpnSense kommt auf einen anderen Port), dahinter ein Reverse Proxy (HAproxy, Caddy oder Nginx). Dort wird auch die TLS-Terminierung durchgeführt, Wildcard-Zertifikat per DNS-01 ebenfalls auf der OpnSense.
Warum? Na, wenn der Webserver gehackt wird, ist er in einer DMZ, von der aus kein Zugriff in andere lokale Netze möglich ist, d.h. keine einfache Propagation.
Durch den Reverse Proxy kann ich (neben der Vermeidung von NAT Tricks) das Wildcard-Zertifikat zentral für mehrere Services nutzen, die ggf. auf verschiedende DMZ-VMs oder Services verteilt werden. Außerdem ist Introspektion mit Crowdsec und Suricata möglich, was nicht ginge, wenn der TLS-Traffic einfach durchgetunnelt wird. Ganz abgesehen davon, dass manche Services selbst schwieriger mit TLS zu versorgen sind, z.B. wenn diese unter Docker laufen.
Und schließlich DNS-01 und Wildcards, weil ich so Services ggf. "verstecken" kann: wenn man den Namen nicht kennt, wird er auch nicht verraten, kann aber trotzdem von außen erreicht werden (Achtung: wenn man jemals ein "named" Zertifikat dafür ausgestellt hat, ist der Name verbrannt, siehe https://crt.sh/).
So wie meyergru das hier beschreibt finde ich sehr gut.
So stelle ich mir das in etwa vor.
aber ich hab da noch Wissenslücken,
wie z.B. wie sieht die Textdatei für DNS-01 aus und wo gehört Sie hin?
wie meinst du das mit den Wildcards?
DNS-01 ist eine der drei möglichen Verifikationsmethoden (Challenge Types) für ACME-Zertifikate (https://letsencrypt.org/de/docs/challenge-types/), beispielsweise für LetsEncrypt oder ZeroSSL. Es ist die einzige Methode, die zur Ausstellung von Wildcard-Zertifikaten berechtigt. Mit HTTP-01 geht das nicht, weil letztere nicht beweist, man die ganze Domain "besitzt", sondern nur, dass man einen bestimmten Namen (oder eine Liste von Namen) in der Domain kontrolliert.
Ein Wildcard-Zertifikat wird ausgestellt für *.domain.tld, und kann dann für beliebige Namen verwendet werden, also abc.domain.tld, genauso wie für xyz.domain.tld. Darin besteht der Trick: Man sieht dem Zertifikat nicht direkt an, welche Namen wirklich benutzt werden. Das ist wichtig, weil aufgrund der Transparenzrichtlinien jedes ausgestellte Zertifikat veröffentlicht wird (https://crt.sh) und somit die Namen abgefragt werden können.
Nimmt man also *.domain.tld anstelle von abc.domain.tld für das Zertifikat, weiß niemand, dass es abc.domain.tld überhaupt gibt. Somit könnte man z.B. das Web UI von OpnSense von außen erreichbar machen - aber nur derjenige, der den vollen DNS-Namen kennt, bekommt das zu sehen.
Das ACME.SH Plugin in OpnSense (os-acme-client) kann bei verschiedenen Anbietern Schnittstellen für DNS-01-Verifikation bedienen. Einfach im Plugin den Challenge-Type DNS-01 anstelle von HTTP-01 auswählen und dann die Liste der möglichen DNS-Anbieter ansehen. Darunter sind Hetzner, IPv64.net, FreeDNS usw., es sind zig Dienste. Logischerweise braucht man dazu eine eigene Domain.
Es gibt für die Konfiguration von HAproxy und Caddy in der Tutorial-Sektion des Forums sher gute HowTos, um dann den Reverse-Proxy mit diesen Zertifikaten zu nutzen.
Hallo,
jetzt habe ich auch einmal kurz eine Frage zu den Wildcardzertfikaten.
Ich hatte mir ein Wildcard-Zertifikat erstellt für eine Sub-Domäne bei IPV64.net.
Das hat auch alles sehr gut funktioniert. Nun habe ich Deinen Tipp befolgt und bei CRT.sh nachgeschaut und siehe da, dort waren jede Menge Zertifikatseinträge vorhanden. Das hatte ich darauf zurückgeführt, dass ich ganz zu beginn mittels http-01 Challenge ein Zertifikat erstellt hatte und das deshalb die Einträge zu sehen waren.
Nun habe ich vorsichtshalber eine neue SUB-Domain mit anderem Namen erstellt und nur ein Widcard-Zertifikat mittels DNS-Challenge erstellt. Das Ganze sorgte nun dafür, dass ich wirklich 3 Tage lang nichts bei crt.sh gefunden habe. Heute sind jedoch wieder 7 Einträge für die neue Subdomain vorhanden.
Es war eine Menge Arbeit alles auf die neue SUb-Domain umzustellen (Caddy und DynDNS etc.)
Bevor ich mir nochmals die Arbeit mache. Geht das nicht mit Sub-Domains oder mache ich etwas falsch?
Bei einem Zertifikat habe ich einmal die Sub-Domäne als Namen angegeben und als Alternativnamen dann *Name. Ist das okay? Ich hatte das irgendwo gelesen. Oder muss ich als Namen nur *Name eingeben ohne Alternativname?
Nur *.name.xyz und name.xyz, weil "volle" Alternativnamen ja im Zertifikat vorkommen. Bei Subdomains also *.sub.name.xyz und sub.name.xyz.
"Geheim" bleiben dabei immer nur die echten Namen, wie "abc.name.xyz" oder "abc.sub.name.xyz", da sie nicht im Zertifikat vorkommen, aber trotzdem davon erfasst sind und somit genutzt werden können.
Wenn die Namen für die Subdomän auftauchen, dann entweder, weil Du sie als Alternativnamen angegeben hast oder weil eine andere Instanz selbst Ausstellungen macht (z.B. weil man noch einen anderen Webserver hat, der sich selbst Zertifikate per ACME holt).
Also so habe ich es doch gemacht, denke ich.
Name also z.B: subdomain.ipv64.net und Alternativname *Subdomainname Name.ipv64.net.
Ich habe sonst definitiv nichts was ein Zertifikat anfordert.
Die angezeigten Zertifikate sind jetzt auch immer auf *subdomain.ipv64.net und Subdomain.ipv64.net. Sonst sehe ich keine Zertifikate, das stimmt.
Aber wieso sind die Zertifikate mit dem kompletten Namen des Servers so ein Problem aber wenn man nur den Namen des "Stammzertifikats" dann nicht?
Wählt man dann so einen komplizierten Namen für den Server, dass man nicht darauf kommen kann, oder wie ist die Idee?
Sorry für die dumme Frage, habe leider nicht das entsprechende Wissen, aber ich würde das trotzdem sehr gerne verstehen.🤔☺️
Wenn man noch geheimer sein will, in Caddy kann man ECH machen (z.b. mit Cloudflare) da wird dann der echte SNI durch einen fake SNI verschleiert. Sozusagen wildcard zertifikat +++.
https://github.com/opnsense/plugins/blob/d752990dfa3543ce57231c1eae181e5afe76c2de/www/caddy/src/opnsense/mvc/app/controllers/OPNsense/Caddy/forms/general.xml#L193-L198
Das hört sich sehr gut an. Befürchte aber,dass das mein Dienst nicht unterstützt. 😥
Solange man nicht ausgerechnet opnsense.name.xyz wählt: Wer soll denn darauf kommen? Und sowohl Caddy als auch HAproxy können ein Fake-Zertifikat zeigen, wenn der Name nicht stimmt.
Ich habe schon Portscans gesehen, aber noch nie Namens-Scans.
Um genau zu sein: was ich schon gesehen habe, sind Scans, die ich mir nur durch Absuchen der ACME Transparenzdatenbank erklären kann.
Haha,
sehr gut, dass wir drüber gesprochen haben. Genau das hatte ich genommen, einfallslos wie ich bin, OPNSense.subdomain.name.
War halt so schön plausibel.
Wie schön, dass man hier immer etwas lernen kann. Das passiert mir nicht mehr. 😁