Kleine "private" Cloud mit pfSense als Firewall

[JeGr]

Aloha,

nach einem Gespräch mit meinem Studenten, der sich eine kleine Cloud zu Hause bauen wollte und den letzten Themen mit @Bob-Dig und @mike69 hatte ich eine verspukte Idee im Kopf, wusste aber nicht ob die realisierbar ist.

Was: Webserver in der Hetzner Cloud (KVM Container Server zu günstigem Preis #noad) mit vorgeschalteter "echter" Firewall

Warum: Normalerweise bekommt man keine ordentliche Firewall vor seinen Webserver und muss so die potentielle Angriffsfläche auf der VM direkt versuchen zu mitigieren. Da sich einige nicht ganz so doll mit Linux, Kernel, IPtables/NFtables und Co auskennen (plus Fail2Ban und Co) ist bei "nur VPS mit Webserver" natürlich die Angriffsfläche größer. SSH muss da sein, Webserver auch, etc. etc. IPtables für Firewall, ggf. noch nen Frontend dafür (UFW, Shorewall, whatever) und dann noch fail2ban, damit man SSH ordentlich absichert. Und so weiter, und so weiter.
Wäre mit Firewall davor und ordentlichem VPN alles viel einfacher? Jau!

Wie: (alt) Konnte man bislang natürlich alles auch schon machen, Stichwort eigener Server mieten. Dann mietet man eben die Hardware und kann darauf virtualisieren. Dann gehts aber schon in Runde 2: Virtualisierung aufbauen, KnowHow benötigt, dann ordentlich Netzwerken in der Virt Umgebung, Firewall VM vorschalten, und wieder - usw. usw. usw.
Zusätzlich ist man für Backup selbst verantwortlich, kann den Server nicht mal eben wechseln und ein eigener Server schlägt dann schonmal mit 20-30€ im Monat zu Buche. Die kleinsten VPS Instanzen gerade mal mit ~3,30 mit integriertem Backup.

Also: Wie also dann?

1. Setup:
   • Man braucht mind. 2 (ZWEI) kleine Hetzner Cloud Instanzen. Witzigerweise müssen sie durch das (etwas gewöhnungsbedürftige) Netzwerksetup von Hetzner nicht im gleichen RZ Standort sein (Nürnberg, Falkenstein oder Helsinki sind alle möglich).
   • (1) Eine davon wird mit einem Random OS gebucht
   • (2) Die andere installiert ihr mit dem System und Kram den ihr schützen wollt
   • Via Cloud Dashboard erstellt ihr ein zusätzliches Netzwerk. Beispielhaft "xconnect" mit IP Range 172.16.16.0/24 (wird bei 2 Instanzen dann auf /29 runtergerechnet, einfach ignorieren :))
   • In diesem Netz was erscheint, könnt ihr den beiden Instanzen jetzt jeweils eine IP zuweisen (.2 und .3). Somit haben die VMs jetzt ein Interface mit ihrer Public IP4/IP6 und ein "internes". Das Interne (xconnect) muss am Einfachsten via DHCP bezogen werden, ihr bekommt dann aber definitiv die IP die ihr im Dashboard eingestellt habt. Wichtig ist DHCP deshalb, weil eure Instanzen eine /32 IP und P2P konfiguriert werden, damit jeder Traffic über die .1 des angelegten Netzes geht (Hetzner interner VirtRouter). Das ist notwendig, damit die den Traffic auch mit den anderen Instanzstandorten vernetzen können. Darum nicht wundern über das etwas "schräge" Setup :)
2. Installation:
   • (1) Die erste VM wird ausgeschaltet und über das Dashboard konfiguriert. Bei Networking kann man nochmal checken, ob die private IP auch drauf gemappt ist (xconnect mit der .2 sollte hier auftauchen). Dann unter ISO-Images einfach das pfSense Image auswählen (2.4.5) und einhängen. Danach die VM starten.
   • (1) Nach Start von VM1 jetzt die HTML Konsole (Symbol rechts oben) aktivieren und die pfSense via eingehängtem ISO einfach installieren. Sollte nicht schwer sein :) Nach Installation und DHCP auf WAN sowie DHCP auf LAN, solltet ihr die im Dashboard angezeigte IP4 auf dem WAN anliegen haben. Dann könnt ihr auf der HTML Konsole nach fertiger Installation und Boot mit (12) in die PHP-Shell und einmal playback enableallowallwan ausführen. Damit wird eine flotte allow any Rule auf dem WAN erzeugt, damit ihr von außen via eurer externen IP zugreifen könnt. Das sollte man natürlich nur kurzfristig machen und sich dann flotti galoppi einloggen, admin User ändern und am Besten den Zugriff nur auf seine IP freischalten (via DynDNS Alias oder statischer IP).
   • (1) Hat man VM1 soweit im Griff dass man nur noch selbst via GUI auf die Kiste kommt (und dann HTTPS und SSH Port noch umverlagert auf Alternativen wie 4422 und 4443 bspw.) und zudem noch SSH nur via Key erlaubt (oder key+pw), sollte man erstmal annehmbar safe sein und kann in Ruhe die Sense konfigurieren.
   • (1) Hier kann man sich jetzt wie mans kennt austoben. VPN Einrichten, Zugriff einrichten, Advanced Setup etc. für AES-NI usw.
   • (1) HAProxy installieren und einrichten
   • (2) Auf der zweiten Kiste kann man jetzt bspw. sein Lieblings-Linux installieren und setzt sich seine Umgebung auf. Webserver, PHP, Python, etc.
   • (2) Natürlich sollte man das angelegte interne Interface (xconnect) nicht vergessen noch einzurichten, wenn nicht schon erledigt. Das sollte als zweites Netzwerk auftauchen und die beiden VMs sollten sich da schon gegenseitig pingen können (bzw. die pfSense nach Freigabe der Regeln)
   • (2) ist das soweit fertig und man käme jetzt über die andere Public IP des Webservers auf den Server drauf und bekommt seinen Webserver, klemmt man die externe IP bzw. das Interface vom Hetzner-WAN ab :) (HTML Konsole via Dashboard hilft)
   • (2) Die zweite Kiste ist jetzt nicht mehr erreichbar von außen weil ihr WAN down ist. Oh my... ;)
   • (2) Mittels HAproxy auf der ersten VM (1) legen wir jetzt einfach die (2) als Backend für den HAproxy an und erstellen ein passendes Frontend. Da wir 80/443 auf der Sense freigemacht haben von der UI (und den Redirect auf die UI abgeschaltet haben!) kann jetzt auch dort unser Webserver antworten, der dann einfach intern über das xconnect Netz verbunden ist und so antworten kann.

Das ist jetzt natprlich nur in gröberen Zügen beschrieben, aber "you get the drift", ihr versteht wo es hingeht. Im Notfall, sollte die 2. VM down gehen, kann man mit etwas Vorbereitung und Absicherung die 2. VM auch wieder direkt ans Netz hängen, muss dann natürlich aber die DNS Einträge anpassen. Oder man nutzt gleich noch zusätzlich das Feature der Floating IP (für nen Euro im Monat) und bucht sich eine IP die man flexibel von A nach B switchen kann im Dashboard dazu. Dann kann man sogar hergehen und sich eine zweite Firewall als Redundanz bspw. in anderer Location beschaffen wenn man Ausfallsicherheit will ;)

Natürlich kann man statt HAproxy auch weiter NATten aber das läuft dann wegen fehlendem Rückweg bzw. multiplen Routen nicht ganz so schön und braucht dann auf Seite (2) noch ein paar Zusatztweaks. Zudem hat man dann wieder häßlich NAT/PortForwarding, da läuft HAproxy besser :)

Alternativ kann man natürlich auch einen VPN Tunnel zur Sense aufbauen und dort damit dann quasi sein "LAN" bauen und routen. Das wird der nächste Test werden, die externe IP (bis auf SSH/GUI) quasi komplett durchzurouten per VPN :)

Cheers
\jens

[m0nji]

@jegr sehr interessant. Danke für den Gedankenanstoss zu einem neuen Bastelprojekt! Werde ich am Wochenende gleich mal vertiefen und meine pfSense zu Hause per ipsec anbinden. Das durchrouten der externen IP finde ich sehr spannend.

Für mich ist noch nicht ganz klar wie das Routing des LAN Interfaces funktioniert. Standardmäßig wird ja auf dem LAN Interface eine Regel angelegt, die alles aus dem "LAN Net" to "Any" über jedes Protokoll erlaubt. Allerdings kann ich nicht von der 2. Hetzner Maschine die pfSense anpingen. Erst wenn ich eine zusätzliche Firewall Regel anlege und als source das Hetzner LAN netz angebe und als ziel die LAN address nehme, funktioniert auch ein ping.

Von der pfSense zum 2. Hetzner Server, kann ich ohne Probleme pingen, auch ohne diese Zusatz Regel. Es scheint als wenn "LAN NET" nicht das ist, wofür ich es halte ;)

Hast du auch ipv6 eingerichtet auf der pfSense? Zumindest holt er sich via dhcp6 auf dem WAN Interface keine Adresse. Das liegt aber wohl daran, dass dem Hetzner Server ja nur ein 64er Präfix zugewiesen wird und die pfSense wahrscheinlich versucht ebenfalls ein 64er Präfix abzurufen.

[m0nji]

Ich versuche mir mal die Antwort bzgl. Firewall Rule selber zu geben.
Durch das DHCP auf dem LAN Interface ist ja das Netz 10.38.10.2/32 und nicht /24. Demzufolge ist wohl "LAN net" ebenfalls nur /32, was erklären würde warum der zweite Hetzner Server mit der 10.38.10.3 die 10.38.10.2 nicht anpingen kann. Liege ich mit der Vermutung richtig @JeGr ?
Was mir aber noch nicht ganz schlüssig ist: Wenn ich die public IP vom zweiten Server wegnehmen würde, hätte dieser ja nur noch die 10.38.10.3 und als Gateway die 10.38.10.1 (Hetzner Gateway). Müsste ich da dem zweiten Hetzner Server nicht manuell den Gateway pfsense (10.38.10.2) eintragen? Dieses Konstrukt ist mir noch nicht ganz klar.

[JeGr]

@m0nji said in Kleine "private" Cloud mit pfSense als Firewall:

Ich versuche mir mal die Antwort bzgl. Firewall Rule selber zu geben.
Durch das DHCP auf dem LAN Interface ist ja das Netz 10.38.10.2/32 und nicht /24. Demzufolge ist wohl "LAN net" ebenfalls nur /32, was erklären würde warum der zweite Hetzner Server mit der 10.38.10.3 die 10.38.10.2 nicht anpingen kann. Liege ich mit der Vermutung richtig @JeGr ?

Jup. Das "Netz" ist nur die einzelne IP wegen Routing durch die .1 damit die unterschiedlichen Standorte machbar sind.

Was mir aber noch nicht ganz schlüssig ist: Wenn ich die public IP vom zweiten Server wegnehmen würde, hätte dieser ja nur noch die 10.38.10.3 und als Gateway die 10.38.10.1 (Hetzner Gateway). Müsste ich da dem zweiten Hetzner Server nicht manuell den Gateway pfsense (10.38.10.2) eintragen? Dieses Konstrukt ist mir noch nicht ganz klar.

Inwiefern was eintragen? Soferns nicht schon gemacht ist/wurde, muss das interne Netz (10.38.10.2) natürlich auf das LAN GW (.1) eingetragen/geroutet werden. Das ist klar. Sonst kommen die Pakete ja nicht beim anderen Server an ohne übers GW zu gehen. :)

[m0nji]

@jegr ich teste heute oder morgen Abend noch etwas und geb dann noch mal Feedback. Das Routing innerhalb des privaten Netzes klappt schon, dass ist nicht das Problem. Muss aber erstmal noch eine weitere virtuelle Server Instanz erstellen weil die jetzige zweite produktiv ist und er will ich nicht einfach die Public IP entziehen. Wie hast du diese überhaupt entzogen. Über die Cloud Console ist das ja scheinbar nicht möglich. Hast du einfach den Adapter auf der virtuellen Maschine deaktiviert?

[m0nji]

Ok meine Tests waren soweit erfolgreich. Hatte jetzt zum Test noch eine zweite virtuelle Maschine installiert und habe auch noch mal das private Netz neu erstellt. Laut zweier Anleitungen sollte man das Netz gleich größer spannen /16 oder /8 und dann ein Subnetz erstellen mit den virtuellen Servern. Warum....hm das weiß wohl nur hetzner, denn in FAQ steht auch: "Im Moment ist die Funktion Subnets nicht sehr nützlich. Dies wird sich jedoch in Zukunft ändern, wenn wir weitere Funktionen hinzufügen." ;)
Anyways mein Ziel war es, den neuen virtuellen Server über die virtuelle pfSense ins Internet gehen zu lassen.

1. Netzwerk 10.38.0.0/16 angelegt und Subnet 10.38.10.0/24
2. virtuelle pfSense und Test Maschine in das 10.38.10.0/24 Netz gepackt
3. Route in Cloud Console erstellt 0.0.0.0/0 via 10.38.10.1 (pfSense)
4. dhcp für die Public IP auf der virtuellen Test Maschine deaktiviert und default route hinzugefügt via 10.38.0.1 (Hetzner Gateway für das virtuelle Netzwerk)
5. /etc/resolv.conf angepasst "nameserver=10.38.10.1"
6. in pfSense Outbound NAT angelegt, DNS Resolver Access für das 10.38.10.0 Netz und Standard LAN to ANY Firewall Rule geändet von LAN Net auf Network 10.38.10.0, da LAN Net in diesem Fall nur bedeutet 10.38.10.1/32

Als nächstes würde ich dann mal einen VPN Tunnel zwischen der virtuellen pfSense und meiner pfSense daheim probieren. Da werde ich aber wohl noch 2 Wochen warten und es dann gleich mit wireguard testen.

Alles in allem ein klein wenig anderer Use Case als den du beschrieben hast Jens aber ich fand das Thema durchaus spannend und es ergeben sich dadurch gleich ein paar neue Anwendungsfälle :D

[JeGr]

@m0nji Ist doch schön wenn es auch für was anderes gut ist :)