Portforwarding 80

[greeno]

hi zusammen,

ich muss für einen Webserver ein lets encrypt Zertifikat per http-01 abholen also beide Ports 443 und 80 dafür per NAT...
opnsense ist 444 und redirect Port is aus für GUI

Port 80 wird nicht weitergereicht, ich check nicht wieso wenn ich das WAN interface und Port 80 logge kommt nichts im log.
logge ich  WAN interface und Port 443 kommt alles schön sichtbar...

proxy hab ich keinen ... wieso kommt das nicht auf der Firewall an?

thanks

[meyergru]

System: Settings: Administration -> HTTP Redirect ausgeschaltet? Ach ja, schriebst Du ja schon.
Filtert eventuell Dein ISP?

Am Rande: Wildcards mit DNS-01 sind komfortabler und sicherer, weil die wirklichen Servernamen verborgen bleiben, siehe https://crt.sh.

[Patrick M. Hausen]

Am Rande: Wildcards mit DNS-01 sind komfortabler und sicherer, weil die wirklichen Servernamen verborgen bleiben, siehe https://crt.sh.

Was nimmst du als DNS-Server? Einen Provider per API? Ich komm einfach nicht dazu (lies: hab kein' Bock) mich mit dem ACME-DNS auseinanderzusetzen, hätte es aber gerne self-hosted.

[meyergru]

Ich nutze dazu zunächst mal den "DNS Alias Mode", der es erlaubt, alle meine Domains über eine einzige dynamische Zone zu bedienen. Dazu muss man in den verwendeten Domains nur einen Alias _acme-challenge.domain.de auf die eine Ziel-Zone challenge.dynamic.de richten. Damit brauche ich für das jeweilige DNS-API eben auch nur ein Ziel.

Das dann zu nutzen, ist super einfach, weil acme.sh für viele DNS-Anbieter API-Unterstützung anbietet, siehe hier. Da sind die üblichen Verdächtigen wie Hetzner usw. nativ dabei und man kann die jeweils im ACME plugin per Dropdown auswählen.

Für mein eigenes Hosting nutze ich einfach BIND mit nsupdate per Key. Erzeugen kann man den Key sowohl für das Credential-Feld als auch zur Aufnahme in die BIND-Konfiguration mit "rndc-confgen -k key-name".

In BIND sieht das dann so aus:

Code Select Expand

##############################################################################
key "key-name" {
        algorithm hmac-sha256;
        secret "OrOi+2pZ5vKP6ggukc/fu3LFn4xJuTBMASj7FPljit8=";
};


zone "challenge.dynamic.de" IN {
        type master;
        file "dyn/challenge.dynamic.de.zone";
        allow-update { key key-name; };
        # update-policy local;
        allow-transfer { trusted-servers; };
        allow-query { any; };
        check-names ignore;
        notify explicit;
        also-notify { 1.2.3.4; };
        forwarders { };
};
##############################################################################

Und man legt eine Stub-Zone in "dyn/challenge.dynamic.de.zone" an. Somit kann ich die "normalen" Zonen statisch (also ohne freeze und thaw) editieren und die Zone challenge.dynamic.de.zone ist die einzige, die voll dynamisch aktualisiert wird. Wie man sieht, gibt es (natürlich) einen DNS Slave (1.2.3.4).

Im Challenge-Teil des ACME Plugins muss man dann nur noch seinen BIND-Server, den Key und die Zone angeben. Ich empfehle eine DNS Sleep Time > 0.

Im Zertifikat dann "DNS Alias Mode" = "Automatic Mode (uses DNS Alias Lookups)" und als Namen "domain.de" und "*.domain.de".

[meyergru]

Noch ein Hinweis zu "sicherer":

Wie ich neulich feststellen musste, ist eine meiner Domains inzwischen komplett verbrannt, weil ich früher einmal mit HTTP-01 Multi-Domain-Zertifikate eingerichtet hatte. Unter https://crt.sh sind die "immer noch" verfügbar.

Gemerkt habe ich das, als ich in meinem Firewall-Log Zugriffe per IPv6 bemerkte, was mich doch stark wunderte, weil eigentlich IPv6-Scans nicht sinnvoll erscheinen.

Von diesen Zugriffen gab es drei Typen:

1. Zugriffe von vielen IPv6 mit Quell-Port 433 auf echte IPv6 in meinem Netz (verschiedene Ziel-Ports). Das waren nur beendete SSL-Sessions, die wegen Out-Of-State abgelehnt wurden. Haken dran.

2. Zugriffe von drei IPv6 mit unterschiedlichen Quellports auf eine einzige IPv6 Port 5182x, deren EUI-64 ich gar nicht belegt habe. Eine Rückrechnung der EUI-64 ergab eine OUI von AVM. Hier hatte der "Vorbesitzer" meines Präfix offenbar ein Wireguard-VPN-Netz mit Gegenstellen aufgebaut, die immer noch versuchten, auf seine Fritzbox zuzugreifen. O.K., Zufälle.

3. Zugriffe von einem bekannten Port-Scanner-Netzwerk auf die verschiedensten Zielports auf die korrekte WAN-Interface-IPv6 meiner OpnSense. Die kann man nicht erraten, also wurde dazu DNS verwendet - nur: die DNS-Namen sind nicht weithin bekannt. Leider hatte ich dafür aber einstmals per HTTP-01 Multi-Domain-Zertifikate ausstellen lassen und das war's.

Man muss unabhängig vom "Verstecken per IPv6" auch bedenken, dass man, auch wenn man per IPv4 Reverse Proxies verwendet, eben SSL nutzen, aber trotzdem nicht verraten will, welche Services sich dahinter verbergen. Das geht nur mit Wildcards und dazu braucht man eben zwingend DNS-01.

Warum will man das? Weil diese Scanner die Ergebnisse samt Fingerprinting der gefundenen Services in Datenbanken ablegen, aus denen man im Fall von gefundenen Vulnerabilities der gehosteten Services sofort Angriffsversuche starten kann. Dann ist also kein mühsames Suchen mehr notwendig.

[Patrick M. Hausen]

Für mein eigenes Hosting nutze ich einfach BIND mit nsupdate per Key.

BIND auf OPNsense?

[meyergru]

Nein, ursprünglich war das mal ein Linux-Server, der jetzt als VM unter Proxmox läuft. Auf dem läuft u.a. auch eine OpnSense, aber meine BIND-Konfiguration ist historisch recht komplex und ich wollte das nicht portieren.

Offen gesagt habe ich mir BIND unter OpnSense noch gar nicht angesehen und weiß daher nicht, ob/wie sich das per GUI konfigurieren ließe.

[Patrick M. Hausen]

Dann guck ich wohl selbst mal und schlag mich doch mit dem acme-dns, wenn's nicht klappt. Ich bin dann ja doch der Port Maintainer für das Teil 😬

[Patrick M. Hausen]

@meyergru, @monviech

So, hab jetzt ein acme-dns auf einem VPC bei Vultr auf FreeBSD, IPv6 only, API per Firewall eingeschränkt auf meine OPNsense - und das geht mit dem Caddy wie's Brezelbacken. Echt nice.

[meyergru]

Wildcards rule!

Schick, also ein maßgeschneiderter DNS-Service, kannte ich gar nicht. Es ist aber beeindruckend, wie viele APIs ACME.sh unterstützt. Und entscheidend ist eben der Trick mit der delegierten _acme-challenge Zone. Damit muss man die Updates auch nur einer einzigen Domain anbieten und kann es überall verwenden.

acme-dns ist ja sogar noch cooler - da kann man ggf. sogar per API Clients registrieren.

Eins verstehe ich allerdings nicht: Die Möglichkeit, die Updates auf IP-Ranges zu beschränken, ist eigentlich doppelt gemoppelt, der zugewiesene API-Key sollte ja hinreichend sicher sein. Aber die Registrierung macht man ja ganz ohne Authentifizierung, also könnte jemand die API mit Anfragen überhäufen. In der Konfiguration kann man die Registrierung nur ganz abschalten - eine selektive Freischaltung scheint aber nicht vorgesehen?

Ich nehme an, das war der Grund für die Einschränkung per Firewall? Schicker wäre, wenn der /register Endpunkt auch per Key oder per Client-Zertifikat geschützt werden könnte. Wenn man Updates "von überall" erlauben will, wird es de facto schwierig, neue Registrierungen durchzuführen. Das passt vom Scaling her nicht so ganz zu einer echten Datenbank - die ja suggeriert, man habe ganz viele Einträge da drin, z.B. im Rahmen eines Hostings.

[Patrick M. Hausen]

Eins verstehe ich allerdings nicht: Die Möglichkeit, die Updates auf IP-Ranges zu beschränken, ist eigentlich doppelt gemoppelt, der zugewiesene API-Key sollte ja hinreichend sicher sein. Aber die Registrierung macht man ja ganz ohne Authentifizierung, also könnte jemand die API mit Anfragen überhäufen. In der Konfiguration kann man die Registrierung nur ganz abschalten - eine selektive Freischaltung scheint aber nicht vorgesehen?

Ja ... das ist so ein wenig "gebastelt". Die Idee ist, dass man die Registrierung nur kurz einschaltet, evtl. das Teil auch nur über 127.0.0.1 erreichbar macht, dann einen/den Client registriert, und dann die Registrierung wieder abschaltet.

Ich kann da von der Port-Seite ja auch nichts am Ausgangsprodukt ändern. Sinnvollerweise gäbe es eine Access-Liste für bereits registrierte Clients und eine Access-Liste für Registrierungen.

Kannst du natürlich machen, indem du einen Reverse-Proxy davor klebst ;-)

Ich hab für mich selbst einfach den Zugriff aufs gesamte API auf meine Sense beschränkt, ich hab ja im Moment keinen anderen Client. Sicher ist sicher ... und eine Handvoll Zeilen pf sind jetzt auch nicht wirklich wild.

Mal gucken, hab gerade auf Github einen Issue aufgemacht, um erst mal zu klären, was denn überhaupt das amtliche Upstream-Repo ist. Da gibts nämlich zwei ...

Grüße

P.S. Das wäre natürlich auch ein nettes OPNsense-Plugin. Registrierung nur über 127.0.0.1 und sinnvolle Defaults. Aber ich muss jetzt als erstes was am Port tun und upstream einkippen. Das Teil (der FreeBSD-Port) muss noch lernen, nach SIGHUP die Logfiles zu und wieder auf zu machen ...

[meyergru]

Falls Du schon issues am Ursprung öffnest: SQLite als drittes Backend wäre auch eine Idee, um das etwas mehr lightweight zu machen... mehr braucht kein Mensch.

Ja, klar, ein Reverse Proxy kann das. Ist aber ansonsten unnötig angesichts der direkten Unterstützung von TLS.

Tatsächlich bräuchte es ein einmaliges "/register-register" mit der selben Struktur wie das jetzige "/register" für das Update, dann könnte man den register-Endpunkt auf 127.0.0.1 einschränken... ;-)

[Patrick M. Hausen]

Falls Du schon issues am Ursprung öffnest: SQLite als drittes Backend wäre auch eine Idee, um das etwas mehr lightweight zu machen... mehr braucht kein Mensch.

SQLite ist das Default-Backend und auch der Default im FreeBSD-Port.

Code Select Expand

[database]
engine = "sqlite3"
connection = "/var/db/acme-dns/acme-dns.db"


[Patrick M. Hausen]

Wildcards rule!

Meine DNS-Einträge für die einzelnen Dienste hab ich trotzdem noch separat mit CNAME auf den Caddy. Das landet dann ja nirgends in irgendeiner Registry, oder? Die führen nur eine Liste der aktiven Zertifikate ...?

Danke,
Patrick

[meyergru]

Ach, ich hatte nur MySQL und PostreSQL gelesen...

Und ja: Siehe https://crt.sh, es sind einfach die Zertifikate. In Deinen DNS kann keiner reinsehen, wenn Du keinen Zonentransfer erlaubst...