allsky-rodgau.de

Seit meine Allsky-Kamera über eine eigene Subdomain öffentlich erreichbar ist, sehe ich regelmäßig Zugriffsversuche aus bestimmten Ländern. Vor allem IPs aus Russland (RU) und China (CN) tauchen überproportional häufig in den Logfiles auf – meistens automatisierte Scanner, Bots oder Credential-Stuffing-Versuche.

Natürlich schützt ein gehärtetes System (Firewall, Fail2Ban, Rate-Limits, HTTPS) bereits recht gut. Aber: Viele dieser Anfragen müsste ich mir gar nicht erst ins System ziehen. Deshalb setze ich zusätzlich auf Geo-Blocking: Der Raspberry Pi wirft TCP-Verbindungen aus bestimmten Ländern einfach ab, und zwar bevor der Webserver sie erreicht.

Ich nutze seit einiger Zeit den Brave Browser, aber bei der Einrichtung des SSL-Zertifikats für meine Allsky-Kamera (zur Anleitung) war der Browser echt zickig. Während Chrome und Safari mein Let’s-Encrypt-Zertifikat sofort akzeptiert haben, zeigte Brave weiterhin „Broken HTTPS“ an – obwohl der Server korrekt konfiguriert war und openssl eine saubere TLS-Kette bestätigte. Und so löst man das Problem!

*** Anmerkung: Ein freundlicher Leser wies mich darauf hin, dass manchmal ein Neustart von Brave ausreicht. Das konnte ich allerdings nicht verifizieren. Aber vielleicht erstmal probieren, bevor man die folgenden Schritte durchführt! ***

Wer eine indi-allsky-Installation auf einem Raspberry Pi betreibt und diese über eine eigene Domain öffentlich erreichbar machen möchte, stößt schnell auf zwei typische Herausforderungen:

• Der Raspberry steckt hinter einer Fritz!Box mit dynamischer IP.
• indi-allsky bringt einen eigenen, selbstsignierten Webserver mit, der standardmäßig kein gültiges TLS-Zertifikat ausliefert.

In diesem Beitrag zeige ich die vollständige, funktionierende Lösung: Ein Let’s-Encrypt-Zertifikat für eine Subdomain wie access.allsky-rodgau.de, ausgeliefert über Apache als Reverse Proxy, inklusive funktionierender Auto-Renewal-Routine per HTTP-01-Challenge.

***Diese Anleitung wurde im Dezember 2025 aktualisiert und funktioniert bei mir einwandfrei***

Während IPv4 durch NAT strukturell geschützt ist, ist IPv6 ohne Firewall immer global erreichbar – ganz ohne Portfreigaben. Genau deshalb ist eine IPv6-Firewall kein „nice to have“, sondern Pflicht.

IPv6: globale Reichweite absichern und ICMPv6 erlauben

Überraschend war für mich, dass mein Raspberry Pi sofort eine globale IPv6-Adresse erhalten hat. Das bedeutet: er ist ohne NAT von außen erreichbar. Ohne ip6tables sind damit alle IPv6-Dienste offen – oft ohne dass man es bemerkt.

Die Lösung ist eine IPv6-Firewall analog zur IPv4-Konfiguration, aber mit einem wichtigen Unterschied: ICMPv6 sollte eher nicht blockiert werden, da sonst Funktionen wie Neighbor Discovery, Router Advertisements oder MTU-Erkennung nicht mehr zuverlässig funktionieren.

Nachdem meine Allsky-Kamera über Apache, abgesichert mit Let’s Encrypt und einer eigenen Subdomain öffentlich verfügbar ist, wollte ich den Raspberry Pi auch auf Netzwerkebene etwas härten – ohne riskante Experimente oder unnötige Komplexität. NAT schützt bei IPv4 zwar grundsätzlich, aber gerade die Ports 80 und 443 sind öffentlich erreichbar. Zusätzlich erzeugen Bots, Scanner und automatisierte Anfragen unnötigen Traffic.

Mein Ziel: eine pragmatische Firewall, die echte Zugriffe zulässt, Bot-Lärm reduziert und Let’s Encrypt nicht beeinträchtigt. Hier ist zunächst der IPv4-Teil – einen zusätzlichen Post zum Thema IPv6 findet ihr hier!