Unsere spannendsten pfSense® Projekte aus der letzten Zeit

…und warum das keine Liste ist, die euch überraschen wird!

Wir kennen diese Überschriften inzwischen zuhauf: 10 Dinge, die man (wahrscheinlich) noch nicht kennt und beim 7. Punkt wird man völlig überrascht! Und was danach kommt, ist meistens Clickbait mit Standardtext. Genau das möchten wir nicht! Bei qwertiko arbeiten Menschen und genau die kommen hier zu Wort und kein LLM-generierter SEO-Text.

Darum gibt es hier keine totale Überraschung, aber vielleicht genügt auch eine zündende Idee oder ein Denkanstoß für ein zukünftiges Projekt! Wir haben darum ein paar Beispiele zusammengetragen, die dieses Jahr außergewöhnlich waren. Was konnten wir also mit unseren Kunden dieses Jahr so alles zusammen anstellen?

Der VPN WAN-Beschleuniger

Die Älteren von euch kennen es vielleicht noch aus den Urzeiten des Internets: Kanalbündelung bei Modem oder ISDN. Unser Kunde hatte leider als Ausgangslage, dass nur mehrere kleine VDSL-Leitungen zur Verfügung stehen, mehr wollte man von ISP-Seite aber aus Rentabilitätsgründen vor Ort nicht anbieten. Diese Leitungen aber einfach über eine Art Load-Balancing ausgehend zusammen zu schalten, war aber keine Option. Denn dann würde sich beim Wechsel der Leitung auch ständig die externe IP-Adresse ändern, was viele Dienste im Internet so gar nicht begeistert hinnehmen.

Nun gibt es solche Angebote schon! WAN Accelerator nennt sich das zum Beispiel oder auch Multi-WAN Bündelung, Namen sind hier Schall und Rauch. Aber was haben die meisten davon gemeinsam? Sie benötigen ein Abo-Modell, denn für einen sinnvollen Betrieb braucht es eine kompatible Gegenstelle. Die Frage war nun: können wir das mit weniger Aufwand und Standardmittel vielleicht nachbauen? Und Bob sprach: „Ja wir schaffen das!“ 😉

Mit einer im Rechenzentrum gehosteten virtuellen Maschine, auf der wir pfSense® installierten, sowie der pfSense® beim Kunden vor Ort, wurde der Versuch gestartet. Mehrere VDSL-Anschlüsse wurden mit jeweils darauf laufenden OpenVPN Instanzen bestückt, die alle auf der RZ-pfSense® zusammenliefen. Mit ein wenig ausgetüftelten Regeln, einem Load-Balancing Gateway Setup und ein wenig leidiger NAT-Konfiguration konnte die Arme-Leute-Version des WAN-Accelerators erstmals online gehen. Erstaunlicherweise funktionierte das für den Hauptzweck (ausgehende Verbindungen) besser als erwartet. Natürlich benötigt man zum sinnvollen Ausnutzen von mehreren Leitungen auch eine entsprechende Anzahl an Clients, die diese Leitungen nutzen. Insgesamt konnten wir aber durch Optimieren der Einstellungen und Kompression sogar etwas mehr als die eigentliche Summe aller Leitungen aus diesem Konstrukt herausholen. Natürlich gibt es auch Schattenseiten: einige Dienste blocken IPs aus Adressbereichen von Rechenzentren, so dass wir im Nachgang noch einige Listen auf der Kunden-pfSense® pflegen mussten, die dann nicht über unser VPN-Konstrukt, sondern direkt über die Leitungen ins Netz gingen, aber der Hauptteil der Anfragen konnte so über die Multi-VPN-Strecke geschickt werden.

→ pfSense®, OpenVPN, Load-Balancing, Multi-WAN und Aliase bzw. pfBlockerNG konnten hier einmal richtig aufdrehen!

Der VPN-Multiserver

Wenn wir schon über VPN sprechen: den üblichen OpenVPN Einwahlservice kennt man inzwischen schon fast als Standard. Aber dann kommen die typischen Fragen: „Warum nicht IPsec? Das kann ja immerhin jeder Client nativ! Und dann gibt es da ja auch noch Wireguard, was inzwischen ja in aller Munde ist!“ Ja nun, warum also gerade OpenVPN?

Auftritt unseres OVPN-Multiservers: Wir hatten bei einem Kunden das Problem, dass uns immer wieder mal vereinzelte Probleme gemeldet wurden. Langsame Verbindung, gar keine Verbindung aus dem Café, Hotel, AirBNB oder der Workshop Location. Das wurde einmal aufgesetzt, aber irgendwie läuft das nicht so gut. Können wir da nicht was verbessern?

Nachdem wir uns den Ist-Zustand angeschaut haben, wurden einige Punkte klar: Das VPN lief nicht über die bekannten Standardports. Für OpenVPN wäre das UDP 1194, aber auch TCP 443 (normalerweise HTTPS) wird da gern genutzt. Nichts davon war aber hier im Spiel. Zudem wurden noch alte Settings und Cipher genutzt. Also: Runderneuerung. Da das VPN dazu auch noch an zentrale Stelle in ein Rechenzentrum verlagert werden sollte, gab uns dazu zwei tolle Vorteile: Wir konnten mehrere WANs für redundante Anbindung nutzen und gleich das VPN renovieren.

Mittels frischer Konfiguration, die OpenVPN in der jüngsten Version 2.6.x auch vollends zur Geltung bringt und bspw. das neu hinzugekommene Data-Channel Offloading nutzt, wurde das VPN stark beschleunigt. OpenVPN mit DCO muss sich vor Werten wie bei IPsec oder Wireguard nicht mehr verstecken und im Gegensatz zu den anderen beiden Varianten kann OpenVPN hier auch noch wesentlich flexibler arbeiten. Unserem neuen MultiServer haben wir also insgesamt 4 Instanzen spendiert: zwei mit UDP und zwei mit TCP, die auf der RZ-pfSense® dann über diverse Einstellungen nicht nur einen, sondern gleich mehrere Ports aufs VPN geleitet haben. Dadurch konnten wir die Clientkonfiguration so anpassen, wie das bspw. auch große VPN-Provider wie Proton oder NordVPN tun: Die Clients dort haben mitunter bis zu 50 verschiedene Verbindungswege konfiguriert, die zufällig ausgewählt und durchgegangen werden. Alle nur dazu da, um alle möglichen und unmöglichen Wege zu versuchen, dass der Client sich ins VPN verbinden kann. Und durch diese Umstellung auf wesentlich mehr „Vielfalt“ der Verbindungen, haben wir inzwischen einen glücklichen Kunden, der seither keine Probleme mehr meldet! Selbst wenn sich mal jemand aus einer schwierigen Location anmeldet.

→ pfSense®, Multi-WAN, OpenVPN und OpenVPN Client Export wurden hier ordentlich gefordert.

Mit dem Tunnel durch den Proxy ins LAN

Reden wir doch über den Elefanten im Raum: es geht hier gerade um viel VPN 😉 Zugegeben! Allerdings betrifft es das nächste Setup nur begrenzt. Hier hatten wir die Kundenanfrage, ob wir es hinbekommen, dem Kunden doch bitte eine statische IPv4/v6 zu kredenzen, da er leider am Anschluß dazu nichts bekommt. Zusätzlich muss er aber leider Dienste intern hosten, auf die vom Internet aus zugegriffen werden muss. Der geneigte Mitlesende denkt jetzt sicher: nicht schwer, dafür gibt es ja DynDNS Dienste. Und damit läge man auch nicht falsch, gäbe es nicht noch ein Problem: Der Kunde hat keine IPv4, sondern nur IPv6 und CGNAT. Somit die denkbar ungünstigste Variante.

Was war also zu tun? Nun, der Kunde hatte allerdings auch eine VM bei einem Hoster zu anderen Zwecken am Start. Dort also eine zweite IPv4 und IPv6 zu bekommen, war kein großes Problem. Damit ausstaffiert wurde dann eilig ein Tunnel gebaut, der vom Kunden selbst per IPv6 zum Hoster auf die VM verbindet. pfSense® war dort schon installiert, das war also ein Leichtes. Anschließend wurden die neue IPv4 und IPv6 so gemappt, dass diese durch den IPv6 Tunnel direkt zur Kunden-pfSense® durchgestellt wurden. Da intern kein IPv6 konfiguriert war und das den Rahmen gesprengt hätte, wurde dann zusätzlich noch HAproxy als Reverse Proxy aktiviert. Dieser lauschte dann auf die vom Hoster durchgereichten IPv4/6 Adressen und nahm das alles dankbar entgegen und reichte es intern an die entsprechenden Geräte weiter.

Im Grundprinzip also eine self-hosted Variante von Produkten wie dem Cloudflare Tunnel. Trotz dynamischer Adresse und „fehlender“ IPv4 bekommen wir damit trotzdem einen Dual-Stack IPv4/v6 Service für den Kunden realisiert.

→ pfSense®, OpenVPN & HAproxy greifen hier alle ineinander und bringen interne Projekte ordentlich ins Netz!

Auf der Jagd nach Bots

Schon gut, schon gut! Ich habe die Rufe vernommen: kein VPN mehr für heute! 🙂

Dafür aber eine kurze Story aus eigenem Anbau, die uns und unsere Kunden selbst betrifft. Und um welche Art von Bots geht es dabei? LLMs! Richtig, ich schreibe hierbei von LLM und nicht KI, was sonst in aller Munde ist. Denn was wir in den meisten Fällen tatsächlich bekommen, sind lediglich ausgefeilte Sprachmodelle aber keine wirkliche Intelligenz. Aber um diese Modelle zu füttern, braucht es natürlich auch jede Menge Rohdaten und die werden inzwischen gerne auch mal – mehr oder weniger legal – einfach durch häufiges und intensives Web-Crawling von allen möglichen und unmöglichen Quellen gewonnen. Nicht so neu, denn einige der etwas „schattigeren“ Suchmaschinen oder SEO-Tools, bedienen sich gern der gleichen Methoden: Wo offizielle Suchmaschinen-Bots oder -Agents beim Crawling der Webseiten sich noch an Standards oder Bot-Konfigurationen der Webseite halten, kennen inzwischen diverse LLM Bots keine Gnade mehr. Bot Konfigurationen werden ignoriert, Einschränkungen von URLs „vergessen“ und wo sich Google, Bing und Co noch an Rate-Limits halten, schlagen solche Crawler und LLM-Bots auch gerne in solchen Wellen auf Webseiten ein, dass man hier schon fast von einem (D)DoS Angriff reden kann.

Was aber bei bisherigen Bots noch ganz gut greifbar war, wird inzwischen leider immer mehr zu einem Hütchenspiel oder Whack-a-Mole Duell zwischen Hostern und den Bots. Konnte man das bislang noch über diverse IP-Bereiche, User Agents oder anderen Merkmalen filtern, hatten wir dieses Jahr mehrfach Besuch von besonderen Bot-Freunden. Diese haben sich insbesondere dadurch ausgezeichnet, dass ihre User-Agents kompletter Mumpitz sind. Hier war wohl ein Zufallsgenerator am Werk und lieferte solche Stilblüten wie „Opera 7.83 unter Linux“ oder „iPod Touch unter iOS/2.1.4“. Warum das lustig ist? Nun ja, der alte Opera Original-Browser mit einstelligen Versionsnummern ist über 20! Jahre alt. Dass jemand den heute noch absichtlich unter Linux benutzen würde, ist schon keine Frage mehr. Und wer wirklich heute einen iPod Touch hat, würde sich zum einen über das OS wundern (iPod Touch mit SO alter Version wären heute 15+ Jahre alt) und dann müsste man wirklich hinterfragen, wer allen Ernstes auf so einem Gerät dann einen B2B-Shop besucht, der sich konkret nur an Distributoren richtet. Wir treffen ja oftmals auf viel ältere Hardware, aber 15-20 Jahre alte Clients? Ah, ich glaube nicht.

Darauf aufmerksam geworden suchten wir also aus den Logs diese eindeutig seltsamen Besucher heraus, um dann aber festzustellen, dass diese nur einen Abruf hatten. Kein typischer Bot, der dann mehrere URLs abgreift oder sogar 10x pro Sekunde auf die Seite hämmert. Nein, die IP des Bots kam dann erst Stunden später – dann aber mit komplett anderem User-Agent und Headern wieder vorbei. Jetzt kann das auch andere legitime Gründe haben (bspw. eine Firmenanbindung mit mehreren Clients dahinter), aber der Fakt, dass dann wieder ein seltsamer User-Agent im Spiel war, legte schon deutlich den Schluss nahe, dass es hier um einen frechen Bot geht, der versucht, undercover zu bleiben. In Zusammenarbeit mit dem Kunden und auch einigem Scripting unsererseits, haben wir dann diese Zugriffe begonnen aus den Webserver-Logs zu fischen. Nach einem Tag waren das dann schon gut und gern 500.000 IPs. Da wird man stutzig. So schnell so viel? Aber gut, als Blockliste in die pfSense® füttern, rausblocken, gut!

Oder doch nicht? Tage später dann wieder solche Wellen im Log. Immer mehr und mehr Adressen werden von den Skripten gefunden und auf Blocklisten gepackt. Also recherchiert: Wie machen die das?
Tatsächlich scheint sich hier ein neuer Trend zu bilden, sogenannte „residential Proxys oder VPNs“, bei denen entweder absichtlich Endkunden Anschlüsse in aller Welt angemietet werden, oder Botnetze, die sich aus IoT Geräten bei Usern zu Hause gebildet haben genutzt werden. Und um diese Netze nicht „zu verbrennen“, in dem sie zu stark Traffic erzeugen, bleibt man lieber bei sehr wenig Zugriffen, bedient sich aber einer riesigen Masse an IPs, weshalb man trotzdem auf eine hohe Schlagzahl kommt – nur dass diese alle von unterschiedlichen IPs rund um den Globus verteilt waren. In unserem Fall hatten wir eine größere Ballung aus der südlichen Hemisphäre: Südamerika und Afrika sowie mittlerer Osten waren hier viel vertreten. Und dass es sich um Endkunden Anschlüsse handelt, tarnt in diesem Fall die Nutzung oder „Vermietung“ an solche LLM-Bots, Rogue Crawler und andere shady Dienste. Das konnten wir auch bestätigen, als wir im Austausch mit einem Blocklist-Anbieter dann ein Sample seiner „residential proxy“ Liste gegen unsere eigene Liste prüfen konnten. Sehr viele unserer beobachteten seltsamen IPs tauchten dort auf.

Wie konnten wir dann das Problem mitigieren? Wie gesagt, aktuell ist das ein Katz- und Maus Spiel aber wir haben einen Vorteil! Mit dem Zusatzpaket pfBlockerNG von pfSense® konnten wir nicht nur stündlich aktualisierte Blocklisten auf der Firewall einspielen, sondern auch zusätzlich unsere eigenen Listen, die wir erstellt hatten, mit einbinden und diese on-demand dann bei diversen Kunden mit zum Tragen bringen. pfBlockerNG ist dabei ein ziemlich umfangreicher Baukasten, der uns schon häufig geholfen hat, komplexe Block- oder Allowlisting-Szenarien einzusetzen. Gerade auch dann, wenn man sehr schnelle Refresh-Zeiten wie bspw. stündliche Updates benötigt.

→ pfSense® & pfBlockerNG: bei Jobs mit IP-Liste, GeoIP, ASN-Blocking und Scripting ein absolutes Schweizer Taschenmesser!

Wir freuen uns schon auf die nächsten spannenden Projekte und Ideen, die unsere Kunden für uns haben!