Bei einer Abteilungsfeier zu der ich eingeladen war hat mir ein Arbeitskollege von einem neuen großen DNS-Resolver für Europa „aus Europa“ erzählt. Das hat sich alles sehr Interessant angehört, und mir sind da gleich allerhand Schandtaten dazu eingefallen.
Zuhause angekommen habe ich mich dann direkt mit DNS4EU beschäftigt. Details gibt es auf deren Website.

Für mich waren folgende Eckpunkte wichtig:

• Unabhängig von Google, Cloudflare usw.
• Verschiedene Filtertypen
  • TYP 1: Unfiltered Resolution
  • TYP 2: Protective Resolution
  • TYP 3: Protective Resolution with Child Protection
  • TYP 4: Protective Resolution with Ad blocking
  • TYP 5: Protective Resolution with Child Protection & Ad blocking

Das hat sich prima mit drei laufenden Aktivitäten ergänzt. Zum einen war ich dabei meine Infrastruktur für den kommenden Glasfaserausbau zu optimieren/erweitern. Zum anderen wollte ich meinen Raspberry-Pi mit Home Assistant rauswerfen und durch eine DIY Plattform ersetzen, da dieser mir schon 4 SD-Karten ruiniert hat. In diese Plattform wollte ich die Informationen meiner Homematic Zentrale mit einfließen lassen wo wir beim Punkt drei sind. Die CCU2 durch Raspberrymatic ersetzen.
Also habe ich zuerst zwei Gehäuse für die PI’s gedruckt.

Diese einbebaut und in Betrieb genommen.

Der erste ist für Raspberrymatic zuständig.

Hier werden alle Homematic Komponenten gesteuert, und über eine API zur Verfügung gestellt. Das neu Anlernen, Verknüpfen und Einstellen der 2 Millionen Aktoren und Sensoren war nervig und zeitraubend aber ist kein Hexenwerk.

Als nächstes habe ich Debian auf den zweiten Pi installiert. Dazu kamen dann einige Pakete, welche ich zur Verfügung haben wollte. Standard sozusagen ist SSH und Samba. Dazu wollte ich einen Apache2 Webserver inklusive php Lib, mySQL und phpMyAdmin zum lokalen Testen von Code. Als MQTT Broker läuft nun Mosquitto um den bereits überlasteten Broker auf meinem ESP32 zu ersetzen, und Node Red um die fertige Schnittstelle zur Raspberrymatic API zu nutzen.

Das war bis dahin nicht der Rede Wert und auch keinen Beitrag wert da im Prinzip alles fertiges Zeug war oder nur Polygone schupsen im Node Red.
Nun wollte ich die neuen Infos zu DNS4EU für mich nutzen und meine Ideen umsetzen.
Also habe ich zunächst die config meiner alten iptables Firewall aus ISDN Zeiten rausgesucht die Basti damals mit mir erstellt hat. Danach habe ich mir IP-Bereiche (Subnets) überlegt:

Bekannte Geräte Zone
Dürfen ins LAN und ins Internet und erhalten den DNS4EU: TYP 4
Bekannte Geräte Kinder Zone
Dürfen ins LAN und ins Internet und erhalten den DNS4EU: TYP 5
Bekannte Geräte Proxy Zone
Bspl. Onion Routing gegen Geoblocking und zum Anonymisieren
Bekannte Geräte IoT Geräte Zone
Dürfen nur ins IoT Zonen LAN
Unbekannte Gast Geräte
Dürfen nur ins Internet und erhalten den DNS4EU: TYP 2

Zunächst habe ich also die Zonen und alle MAC Adressen meiner Geräte in die dhcpd.conf eingetragen. In erster Linie wollte ich dafür sorgen das erstens die IoT Geräte in einer eigenen Zone sind, in der ich bestimme wer nach draußen darf. Zum anderen wollte ich für die Zukunft vorsorgen und eingrenzen, wo später die Kinder rumsurfen können. Dann habe ich mir überlegt was ich so als Jüngling getrieben habe, und dem wollte ich dann auch einen Riegel vorschieben. So bekommen Beispielsweise nur IP-Adressen die vom DHCP Server vergeben wurden einen accept-Flag. Das nennt sich Dynamic IP Hook.
Dann ging es ans Eingemachte. Die Konfiguration von nftables welches iptables ablöst. Hier muss man zuallererst beachten, das die Ports 67 und 68 zum Linux Router frei sind und der Loopback (localhost) auf accept steht, sonst kommen die Clients beim connect nicht zum DHCP und somit bekommen sie keine IP und kein Lease. Es müssen die erlaubten (dynamic hook) DHCP-Clients eingebunden werden. Dann erst kommt der Forward-Chain (Packete von einer in eine andere Zone Leiten) und folgend die NAT-Tabelle (Network Address Translation) zum WAN. Hier ist an mancher Stelle einiges an Ausprobieren nötig bis alles funktioniert. Als Tüpfelchen auf dem i kommt noch ein Logging hinzu welches alle gedroppten Packete aufführt. Das geht nicht direkt. Die logs landen im Syslog (var/log/kern.log) und müssen mit rsyslog abgefangen und in die gewünschte Datei umgeleitet werden. Es ist erstaunlich wie viele ungewünschte Pakete an der Firewall verbrennen. Das war damals schon so, und ist heute nicht besser.

Anders als jetzt wäre ich mit meinem damaligen Wissen nicht an meiner heutigen Absicherung vorbei und mit eigenem DNS Server ins Internet gekommen, um nicht vom Jugendschutz ausgebremst zu werden. Wer mir Face2Face eine Möglichkeit aufzeigt, bekommt von mir ein Bier bezahlt 😉

Ein paar Anmerkungen noch:

• By Default ist das syslog bei dem von mir gewählten Raspbeery OS (Debian) ausgeschaltet um nicht auf der SD-Karte rumzuschreiben wenn es nicht nötig ist. Beim Einschalten sollte man dafür sorgen das die Logs über eine Harte Verknüpfung auf einem USB-Stick landen.
• Alle Files sind anonymisiert und nicht meine IP-Bereiche.
• Alle Messwerte laufen nun über den neuen MQTT Broker und werden in meine IONOS SQL Datenbank geschrieben. Nun kann ich an meinem Backend mit Dashboards arbeiten.
• der Datendurchsatz vom Pi und der Firewall liegt bei 260Mbit
• die Stromaufnahme beider Pi`s zusammen liegt in Schnitt bei 5,6W
• Von Fragen zu TOR, Mullvad oder redsocks ist Abstand zu nehmen!