Kleines Workaround letsencrypt update

mike69

Hallo.

Da letsencrypt zum erstellen und erneuern der Zertifikate den Port 80 offen haben möchte, einige User es aber nicht wollen, hier ein QuicknDirty Scipt fürs Update:


#!/bin/bash

cd /tmp
wget http://example.com/index.html 

# letsencrypt reload
/usr/bin/certbot renew --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2" --renew-hook "systemctl reload apache2"

rm index.html

echo "Certificate update complete" | mail -s "letsencrypt reload"  root

Durch den Download wird Port 80 geöffnet und fällt nach der Aktualisierung wieder zu. Nicht schön, aber besser als einen unerwünschten Port aufzuhaben.

Was meint Ihr?

Mike

JeGr

Hö? Was genau soll das bringen? Und wo soll das laufen!?

mike69

@JeGr:

Hö? Was genau soll das bringen? Und wo soll das laufen!?

Einige besitzen einen Server zu Hause und lassen sich ihre dynDNS Adresse mit letsencrypt zertifizieren. Dazu muss bei einigen Howtos im Net der Port 80 von draußen offen sein. Ausgeführt wird das Script auf dem Server, öffnet den Port 80 und erneuert das Zertifikat. So der Plan.

Irgendwie beschleicht mich ein Gefühl, Stuss zu erzählen.

Edit:
Es klappt nicht ohne Port 80 auf die Maschine weiterzuleiten. Das Script ist Müll. Warum das vorhin geklappt hat, mal sehen…

Oder einfach mal gefragt: Ist eine Aktualisierung der Zertifikate durch letscrypt ohne Portweiterleitung möglich?

JeGr

OK dann verstehe ich warum ich irritiert war. Ich würde nicht sagen "Müll" aber das Skript verstehe ich so nicht, denn es müsste auf irgendeinem Server laufen. Und du machst im Skript Annahmen die nur in ganz spezifischen Umständen vorliegen. Zudem bringt es dir nichts, da die Firewall "keinen Port aufmacht" nur weil du abgehend irgendeine Verbindung initiierst. Nur States, die auf WAN ankommen erzeugen sowas. Daher ist der WGet völlig unsinnig, denn LE will ja eine Verbindung von Ihnen ZU dir auf Port 80 aufbauen, nicht auf irgendeinen Server im Netz :) Außerdem sind da zu viele spezifische Sachen drin wie systemctl etc. was nicht jedes System hat etc. :)

Es klappt nicht ohne Port 80 auf die Maschine weiterzuleiten.

Das kann es wie gesagt auch gar nicht. Nur wenn von außen auf Port 80 was ankommt wird ein State für die Firewall erzeugt und durch eine Regel ggf. reingelassen. Was du VOM LAN aus nach außen machst ist dabei völlig getrennt davon.

Oder einfach mal gefragt: Ist eine Aktualisierung der Zertifikate durch letscrypt ohne Portweiterleitung möglich?

Eine Aktualisierung WO? Du schreibst in deinem Topic dazu nichts. Für die Firewall selbst gibts das ACME Package was alles abwickelt. Das liest sich aber eher als soll das Zertifikat auf einen anderen Server hinter der Firewall, das hat aber gar nichts mit der pfSense per se zu tun.

Das einfachste wäre einfach eine Aktualisierung via DNS-01 zu machen oder statt dessen dann eben den entsprechenden Acme Client der Wahl (gibt ja genügend) auf einem fremden Port zu starten (81 o.ä.) und in der Firewall einfach eine Portweiterleitung von 80 extern auf 81 intern zu machen. Da dieser Port NUR dann aktiv ist, wenn der Acme Client aktiviert ist, hört da auch sonst nichts drauf und kann irgendwie exploitet werden. Ansonsten sehe ich an Port 80 auf einen leeren Webserver jetzt auch nichts Schlimmes :)

Parsec

um den Router mit einem Zertifikat auszustatten, kann man auch den HAPROXY auf der pfSense nutzen, da gibt es Anleitungen wie dies zu konfigurieren ist ohne dass ein physikalischer Webserver gebraucht wird

JeGr

Welchen Router meinst du da jetzt? :)

mike69

Super, wenn beim tippen durch den Timeout rausgeschmissen wirst und alles neu tippen kannst. :(

Eine Aktualisierung WO? Du schreibst in deinem Topic dazu nichts. Für die Firewall selbst gibts das ACME Package was alles abwickelt. Das liest sich aber eher als soll das Zertifikat auf einen anderen Server hinter der Firewall, das hat aber gar nichts mit der pfSense per se zu tun.

Ja genau. Sorry für die ungenauen Angaben, glaubte, es wäre alles klar. Also der Server (Synology, QNAP, etc…) hinter pfSense soll die Zertifikate aktualisieren. Hat so mit pfSense nichts zu tun, abgesehen diese Portweiterleitungsgeschichte. Das es ein Package für pfSense gibt war mir bis eben nicht bewusst. Schon ist dieser Post nicht sooo OT. :)

Das kann es wie gesagt auch gar nicht. Nur wenn von außen auf Port 80 was ankommt wird ein State für die Firewall erzeugt und durch eine Regel ggf. reingelassen. Was du VOM LAN aus nach außen machst ist dabei völlig getrennt davon.

Hier herrschen wirklich noch paar Defizite zum Thema pfSense und Firewall, war wirklich der Meinung es geht so. :-\

Ansonsten sehe ich an Port 80 auf einen leeren Webserver jetzt auch nichts Schlimmes :)

Vielleicht bin ich da ein bisschen Paranoia.:) ist auch gut so, sonst wäre ich mit einer FB zufrieden. ;D

JeGr

Schon ist dieser Post nicht sooo OT. :)

Nicht schlimm kommt vor :D

Hier herrschen wirklich noch paar Defizite zum Thema pfSense und Firewall, war wirklich der Meinung es geht so. :-\

Uiuiui, dann gleich mal ein wenig in Stateful Firewalling einlesen und wie und warum die Regeln so funktionieren wie sie es tun. Würde das klappen was du gedacht hast, wäre ja allein beim Surfen schon das halbe Haus unsicher weil jeder von außen rein dürfte :)

Vielleicht bin ich da ein bisschen Paranoia.:) ist auch gut so, sonst wäre ich mit einer FB zufrieden. ;D

Paranoia heißt nur, dass du weißt, dass sie hinter der her sind :P
Aber davon abgesehen: Auf etwas, das kein Port gebunden hat / auf das nichts lauscht, gibt es auch keine Antwort. Daher halte ich bspw. die Weiterleitung auf einen uncommon Port wie 81 o.ä. nicht für schlimm, wenn auf dem System sonst nie etwas auf den Port hört. Dann geht der Request ins Leere. Und sobald der Agent hört (acme.sh oder dehydrated sind da ganz angenehm auf der Konsole) klappt es.

Allerdings: Wer die Freiheit hat, das anders zu regeln, dem kann ich bspw. nur die Variante mit Cloudflare o.ä. empfehlen. Dazu braucht es dann keinen externen DynDNS mehr, sondern man nutzt seine eigene Domain, von der man den DNS Part zu Cloudflare ausgelagert hat (was die gratis machen bei wenig Zugriffen, also alles was privat ist etc.). pfSense kann jetzt via Cloudflare API problemlos die Einträge für <hostname>.deinedomain.de auf die IP setzen, die man gerade hat (genau wie DynDNS sonst). Und das acme.sh Paket auf der pfSense (oder alternativ auch auf Routern o.ä.) kann via DNS-01 Check dann die Domaineigentümerschaft via DNS Call prüfen (dazu wird ein TXT Record erzeugt und dann wieder gelöscht). Dadurch kein offener Port mehr, gültiges Zertifikat UND eigenes DynDNS gleich inklusive.

Win-win-win :D</hostname>

mike69

Ja, cloudflare hattest Du mal im anderen Post erwähnt, ist leider ein bisschen in den Hintergrund geraten. Schaue ich mir mal an.

Zum Thema offener Port 80. Unser Server hier leitet den Aufruf von draussen gleich auf https um, und da der Port 443 nicht offen ist, wars das.

Parsec

Welchen Router meinst du da jetzt?

Ich meinte den GUI der pfSense mit einem Zertifikat ausstatten

JeGr

@Parsec wenns nur um das WebUI Cert der Sense geht, das kann das ACME Package ohne zusätzlichen Proxy. Der Service hört selbst auf den Port. Wobei ich auch hier es angenehmer finde, den Port auf 81 umzulenken damit er nicht "daueroffen" ist.