Seit Tagen juckt es mich wieder mal zu bloggen, also hier bin ich. Letzte Artikel ist ja auch schon wieder länger her, 8ter August wo ich auf Schneespur einging als auch das erste mal über Rastplatz.app (Ich sollte wieder mal bloggen…). Im heutigen Artikel geht es eben über die Rastplatz.app Eskalation, mache ich ja gerne, als auch die Infrastruktur Sicherheit und auch dort teilweise Eskalation.
Schneller Überblick
Zusammenfassung
Der Artikel beschreibt die Weiterentwicklung der Rastplatz.app und geht auf technische und infrastrukturelle Aspekte ein. Besonderes Augenmerk liegt auf eigener Karten- und Datenverarbeitung ohne externe Anbieter sowie LKW-spezifischen Funktionen. Zudem werden Wetterinformationen integriert und automatisiert aktuelle Luftbilder zu Parkplätzen bereitgestellt. Die aktuellen Veränderungen betreffen vorrangig den technischen Aufbau und die Erweiterung der Nutzerfunktionen.
Auf den Punkt
- Eigene OpenStreetMap-Karten speziell für LKW-Anforderungen werden täglich aktualisiert.
- Ein Build-Server erzeugt Kartendaten und spezielle Overlays, etwa für ADR-Beschränkungen.
- Parkplatzseiten erhalten automatisiert aktuelle Luftbilder aus bundeslandspezifischen Quellen.
- Integration von Wetterdaten für Parkplätze mit Vorhersagen über selbstgehostete APIs.
- Geplante Funktionen wie Routing basieren auf eigenen Servern, Navigation ist nicht vorgesehen.
- Das Design ist noch in Entwicklung, technischer Ausbau steht zurzeit im Vordergrund.
Aber kurz zu Schneespur / Wintertrace
Einen Tag nach dem letzten Blogartikel hier, gab es die neue Version. Eben das was beim AI Pentesting rauskam und ein paar weitere Verbesserungen. Darunter auch Vorbereitungen für ein Touren Modul. Ein Winterdienstbetreiber kann sich das Modul installieren, Touren anlegen, die Fahrer werden benachrichtigt und sehen ihre Touren, können offene Touren für sich beanspruchen, Geo Fencing und weiteres. Ist aber für kurze Zeit auf Eisgelegt weil mir eines nicht gefällt. Die Karte. Genutzt wird hier auch OpenStreetMap. Einfach als Embed. Man sieht die Pins aber die Routenberechnung/Anzeige ist eben reine Luftlinie. Klar könnte man hier ausweichen auf Google Maps, für normale Betriebe würde es auch ausreichen ohne an irgendwelche API Limits zu stoßen aber ich bin eben der Typ, deswegen auch NoSign, wieso nicht selber machen?
Eine selber gehostete OpenStreetMap mit Routing auf normalen Webhosting, nicht machbar (sage ich einfach mal aus dem Bauch heraus). Also werde ich das über meine API selber umsetzen. Aber ohne Rastplatz.app würde ich auch das nicht machen aber eines davon habe ich schon gemacht.
Die Rastplatz.app Eskalation
Und da zitiere ich einfach mal aus meinem letzten Blogartikel:
Der Anfangsgedanke war eigentlich nur: ne Karte welche einem Aufzeigt, wo man evtl. noch einen Parkplatz findet. Aber wie bei Schneespur: es ufert aus. Einerseits bei den Ideen als auch im Hintergrund. Ich möchte es einfach geil haben. Es laufen mehrere Hintergrundservices und Worker. OSM (Google Maps, Here etc… Datenschutz, Kosten, Ladezeiten…) selber hosten (da muss ich mich echt noch drosseln nicht heute nen Server dafür anzumieten, wird aber kommen, die Frage ist nur wann – vermutlich bald, hab Urlaub…). Und da möchte ich auch mit anderen Zusammenarbeiten. Bzw. Angebote für LKW Fahrer mit einbringen / darstellen / darüber informieren und berichten.
Kurz danach kam er auch, ein extra dafür angemieteter Server, welcher täglich Nachts für Rastplatz.app eine neue OpenStreetMap Karte baut. Grob gesagt kann man es so erklären: der Server zieht sich täglich die neuesten Rohdateien, gleicht ab ob es die selbe Karte ist wie gestern oder ob es sich was geändert hat, daraus baut er dann die .pmtiles Datei welche wiederum Rastplatz.app ausliefert. Weiterhin wird ein eigener Truck Layer daraus geniert sowie ADR (Gefahrtgut) Beschränkungen eingezeichnet. Sprichwort Höhen, Gewichts, Längenbegrenzungen. Darf ein LKW die Straße befahren. Welche Autobahnen / Tunnel haben gewisse ADR Beschränkungen.
Eben ne Karte, die nen LKW Fahrer gebrauchen kann, unabhängig von den Parkplätzen. Aktuell ist die Karte noch recht basic. Beschriftungen sind noch auf denglisch, viele Markierungen, die keiner braucht auf der Karte und vom Layout auch noch nicht da, wo es sein wird in einigen Wochen.
Aber die Basis ist da: Rastplatz.app verwendet seine eigene Karte. Keine API Abrufe oder externe Dienste die zum Einsatz kommen.
Braucht mans? Nein. Wie andere Apps und Dienste könnte ich es rein auf Google Maps oder dergleichen aufbauen. Habe aber dann eben keine eigene Karte mit LKW Spezifikationen. Ein eigener Build Server aus dem Grund, der Kartenbau ist Ressourcen hungrig. Könnte ich auch hier auf dem Server machen, weil der Build dauert nicht lange, hier einfach mal ein Screenshot aus meinem Grafana Dashboard dazu.
Das würde dieser Server, hat immerhin 256gb Arbeitsspeicher, 12 Kerne und alles packen. Deutschland ist aber erst der Anfang. Später soll auch Österreich, die Schweiz und co kommen. Auch diese Karten müssen dann gebaut werden. Später soll es auch eine Routingfunktion geben – wichtig: keine Navigation. Sondern mehr eine „Ich bin in Passau, es ist 16 Uhr, ich kann noch 4 Stunden fahren und muss nach Berlin – wo krieg ich nen Parkplatz?“ Funktion. Hier kommt dann Valhalla ins Spiel, was wiederum nen eigenen Routingserver bekommen soll, aber der Tiles Building Prozess bleibt dann auch auf dem Build Server. Deswegen ist es gerade nicht schlimm, dass der 23 Stunden am Tag nichts zu tun hat. Das wird sich noch ändern.
Der Build Prozess funktioniert. Täglich wird die Karte, wenn es eine neue gibt, neu generiert, neues Truck Overlay, ADR Beschränkungen, die fertige .pmtiles Datei geht in nen Hetzner Object Storage und wird an Rastplatz.app ausgeliefert. Aktuell ist es aber eben mehr das Technische Aufbauen. Jetzige Phase ist das Wetter. Einerseits auch als Overlay auf der Karte als auch ne einfache Darstellung auf den Parkplatz Detailseiten. Aus LKW Fahrer hat man zwar nicht die Wahl wo man parkt aufgrund des Wetters aber die reine Information schadet ja nicht.
Wenn ich heute früh in Passau starte und weiß, Abends bin ich irgendwo bei Berlin, dann schaue ich mir an welche Parkplätze es gibt und weiß auch, wie dort das Wetter ist. Aktuelles Wetter inkl. ner kleinen Vorhersage von 48 Stunden. Selbst das ein wenig Overkill wieder. Zum Einsatz wird Bright Sky zum Einsatz kommen, welches selber gehostet wird als eigene API zum Deutschen Wetterdienst – grob gesagt. Jeder Parkplatz bekommt also eine Zuweisung zur nächst passenden Wetterstation und die Informationen werden zentral ausgeliefert. Statt pro Parkplatz per API nen externen Wetterdienst anzusprechen eben auf diese Art.
Aktuell sieht eine Parkplatzseite so aus, als Beispiel Donautal West an der A3 bei Passau:
Auch hier sage ich direkt, dass ganze hat noch kein Design. Die ersten Arbeiten am richtigen Design werden wohl kommende Woche beginnen. Zurzeit ist es eben mehr, wie gesagt, der technische Grundaufbau. Und allgemein eben auch hier: was ohne externe Dienste geht, wird auch ohne gemacht. Luftbilder als Beispiel. Erst überlegt, ja okay, als LKW Fahrer möchte ich auch wissen, wie nen Parkplatz ausschaut. Google Maps. Auf jeder Seite aber Google Maps einbinden ist aber auch Quatsch. Andere nutzen dann Apple Karten. Oder sonst was. Also recherchiert und siehe da, jedes Bundesland stellt Luftbilder parat.
Also Claude Code basteln lassen und zu jedem Parkplatz den es geben wird, wird automatisch das passende Luftbild genommen. Das auch bei kommenden Parkplätzen und Autohöfen. Die Quellen sind da und das Konstrukt funktioniert. Darunter sollen noch Buttons kommen, die eben dann direkt zur bevorzugten Navi App verweisen. Weil Rastplatz.app soll keine Navigationsapp werden.
Bei den Luftbildern bin ich erstmal Happy auch wenn noch viel Feintuning nötig ist. Es gibt einen eigenen Algorithmus, der die Bildgröße / Zoom bestimmt von der Aufnahme her. Bei normalen Parkplätzen funktioniert das aber wenn ein Parkplatz oder Raststätte länger, größer, breiter, komisch gebaut ist haut das nicht unbedingt hin. Bzw. jetzt schon besser, z.B. bei Kraichgau Süd war das mehr Arbeit.
Einfach weil es von der Bauform her anders ist als normale Parkplätze oder Raststätten. Grob gesagt nehmen wir nun den Punkt von der Autobahnzufahrt, nehmen den Punkt mit dazu wo eine Servicestation ist, die Anzahl der Parkplätze und haben daraus eben eine Formel gebastelt, womit ich aktuell zu 95% glücklich damit bin.
Der Nachteil an dem ganzen ist, man muss es aktualisieren. Wann es neue Luftbilder gibt, ist pro Bundesland anders. Also wird es einmal jährlich nen Durchlauf geben, wo die Luftbilder neu generiert werden. Ob sich was geändert hat oder nicht. Auch schon überlegt, ob man dann nicht nen Art Zeitverlauf macht. Kraichgau Süd 2023 vs Kraichgau Süd 2026. Aber das steht noch in den Sternen.
Unterm Luftbild kann dann jeder selber Melden ob noch Parkplätze vorhanden sind oder nicht. Weil offiziell gemeldete Parkplätze auf einer Fläche vs LKW Fahrer werden erfinderisch ist ein Thema für sich. Kraichgau Süd habe ich auch nie auf den normalen LKW Parkplätzen geparkt. Somit ist eine Meldefunktion nicht nur interessant sondern auch nötig. Auch für Parkplätze wo es keine Live Belegung gibt.
Darunter soll dann auch die kommende Wetterfunktion ihren Platz haben und darunter dann erst die Ausstattung / Tarife / Parkplätze in der Nähe. Kann aber auch wieder alles anders werden, weil es nicht das finale Design und Umsetzung. Auch werden noch zahlreiche Dinge kommen, wie Parkplatz Prognosen.
Rastplatz.app soll auch nicht nur eine Karte bleiben aber dazu später irgendwann mal mehr.
Themenwechsel: Infrastruktur Sicherheit
Und mit Infrastruktur meine ich meine Server. Aktuell gibt es 6 Stück. Auslieferungsserver (diesen hier), Mailserver, Downloadserver, Devserver, OSM Build Server und nen Monitoring / Security Server. Geplant ist dann noch ein Valhalla (Routing) Server und mehr muss ich aus meinem Kopf verdrängen, sonst habe ich irgendwann 10.
Und auch da gehe ich viel in Richtung, mache ich mit Claude Code. Aber nicht in der Form „Hey Claude, hier nen neuer Server, da haste die Root Zugangsdaten, pflaster mir mal nen OSM Build Server drauf“. Sondern mehr Planung und Recherche. Wobei die Vorarbeit mache ich auch selber. Mailserver z.B., habe ich mittels Claude Code umgesetzt auf Basis von Mailcow, nicht weil ichs nicht selber kann sondern mehr weil das alles hier für mich ein Dauer Experiment ist. Deswegen gibt es mifupa.com oder donau2space.de.
Beim Mailserver habe ich mir rund 2-3 Monate Gedanken gemacht – brauche ich es überhaupt? Bis dato nutzte ich ein Hetzner Webhosting Paket und habe darauf meine Domains geleitet als Mailserver. Funktioniert aber auch eingeschränkt in der Anzahl von Domains. Und war nicht ganz happy mit dem Spamfilter, deswegen eben der Umstieg auf nen eigenen. Mailserver heißt aber auch: beliebtes Angriffsziel.
Ich habe mich also selber hingesetzt und geschaut, 2026 Mailserver – was gibt es? Was ist Open Source? Was entspricht meinen Bedürfnissen? Wie sichere ich einen Mailserver richtig ab? Mailserver lieber auf einem eigenen Server oder hier auf diesem?
Daraus habe ich für mich einen Plan gemacht und diesen Claude Code vorgelegt. Weiter geplant, diskutiert und umsetzen lassen. Und es funktioniert, klar. Es hätte auch gereicht „Hier Claude, setz mal Mailcow auf“. Aber ich wollte es eben besser? Ja nicht besser aber eben kein offener Mailserver letztendlich wo die Hälfte fehlt.
In meinem Umfeld gelte ich komischerweise als KI Experte, ich kenn mich damit aus aber Experte? KI ist ein nützliches Werkzeug, mehr als das eigentlich, aber man muss sich trotzdem seine Gedanken machen und auch selber dahinter bleiben.
Ne Session arbeitet aktuell an einem Backup Ablauf für all meine Server. Claude sagt zu einem selber: Backups sind wichtig. Aber das ist dann eben Projektspezifisch. Bei mir geht es um 6 Server. Die meisten Websites wie schneespur.de, wintertrace.com sind statische Seiten in privaten GitHub Repos = Coolify neu aufsetzen, Deployen und fertig. Dev Server, hier läuft die ganze Entwicklung von Schneespur, Rastplatz.app, den Modulen für Schneespur und allem was ich mit KI mache. Also die Entwicklungsumgebung, Pläne, Phasen, Milestones. Der Server weg = Houston we have a Problem.
Auch habe ich für mich selber gesagt, ich will mehr Sicherheit. Nicht nur Backups und ne Standard Firewall, sondern auch größer. Deshalb gibt es den Monitoring / Security Server und ein WireGuard VPN Netzwerk zwischen den Servern. Darauf ist z.B. CrowdSec installiert. Er erkennt automatisch Angriffe auf meine Systeme und blockt diese. Sei es SSH, Bruteforce, Mail, WordPress, .env Dateien aufrufen oder irgendwelche bekannte CVEs. CrowdSec läuft erst seit wenigen Tagen, es gab aber schon über 5.200 Alarme.
Großteil davon ist normales Rauschen. Server kommt ins Internet, irgendwelche Bots grasen die IP Netze von Hetzner und co ab, landen auf meiner Maschine und versuchen sich mit dem Benutzernamen „ubuntu“ auf Debian einzuloggen. Oder Bots versuchen auf .env Dateien zuzugreifen, viele landen ja auch im Internet mit API Keys für AWS, OpenAI und co.
Ein anderes Tool ist Wazuh. CrowdSec schaut ja mehr, was macht der Besucher / Angreifer. Wazuh ist mehr, was passiert auf dem Server? Als Beispiel welche Sicherheitsschwachstellen gibt es, was ist nicht Up-do-Date, welche Dateien wurden geändert / geöffnet die den Server selber betreffen? Also nicht ein neues / gelöschtes Bild in der WordPress Mediathek sondern versuchte Angriffe aufs Systrem innere – grob gesagt.
Dazu wurde auch ein WireGuard VPN Netzwerk eingerichtet, der Monitor Server kommuniziert nur darüber mit den anderen Servern. Um mich auf dem Dev Server per SSH einzuloggen können, muss ich mich ebenfalls mit dem VPN zuerst verbinden. Und der Monitor Server überwacht eben auch die anderen Server. Das alles wiederum landet in die einzelnen Dashboards von CrowdSec, Wazuh als auch in Grafana. Denn natürlich kommt auch Prometheus mit Node Exporter und Alert Manager zum Einsatz und als visuelle Darstellung Grafana. Worauf ich dann auch sehen kann, wie es dem Build Server geht.
Auch die Dashboards hat Claude Code gemacht und entsprechenden Metrik Messpunkte verbaut.
Der Artikel soll aber auch aufzeigen, nicht nur auf Claude Code oder KI blind verlassen. Nicht nur sagen „Hey, sicher mir mal den Server technisch ab“ sondern auch andere Sicherheitsmaßnahmen umsetzen. Braucht es dafür nen Monitoring / Security Server? Bei 5 Servern + den Monitoring Server + weitere geplante, macht es meiner Meinung schon Sinn. Auch weil der Monitor Server von außen nicht offen ist und dort auch nur das läuft, was wirklich gebraucht wird. Das selbe beim Mailserver. Umso weniger Angriffsfläche für einen Server umso besser?!?
Sind meine Systeme sicher? Für den, der es drauf anlegt, sicherlich nicht aber für den Großteil der Automatischen Bot Angriffe, dürfte ich gut dastehen. Und man muss ja auch so am Ball bleiben, seine Systeme pflegen und Streicheleinheiten verpassen. Vibe gecodete Sachen prüfen, nachmessen, nachbessern, mit anderen KIs überprüfen, Härtetests aussetzen.
Da musste ich grade lachen. Die Dashboards auf dem Monitor Server gehen ja auch nur, wenn ich per VPN verbunden bin mit dem Netzwerk. Beim aufsetzen aus dem VPN ausgewählt, Seiten geprüft ob es auch überhaupt funktioniert – zack all meine Systeme weg – auch nachdem ich wieder mitm VPN verbunden war. Ich schon gedacht, scheiße jetzt hab ich nen Problem. Über die Hetzner Konsole kam ich noch rauf, selber geforscht was denn überhaupt Sache ist und dann darauf gekommen, CrowdSec hielt mich für einen Angreifer. Wurde blockiert und das eben Systemweit. Entblockt, ein wenig Feintuning aber es funktioniert.
Das war der erste Livetest, weitere folgten danach noch. Eben durch den Aufruf auf angebliche .env Dateien. SSH Logins. Ich hab paar angebliche Zugangsdaten / Credentials auf den Servern verteilt, welche wiederum überwacht werden von Wazuh, falls ein Angreifer ins System kommt und scharf ist auf nen OpenAI API Key (als Beispiel). CrowdSec meldet aktuell auch an Wazuh. Als nächstes kommt dann auch das Wazuh an CrowdSec meldet. Weitere Abhärtung vom Devserver als auch von den anderen. Vieles auch wiederum übertrieben und Overkill aber mir machts Spaß und man lernt ja auch vieles daraus.
So das solls wieder mal gewesen sein, bis zum nächsten mal 🙂
