Was man mit dem Pi-hole noch so machen kann

Zusammenfassung des Pi-hole Dashboards
Zusammenfassung des Pi-hole Dashboards

Den Pi-hole habe ja nun schon länger im Einsatz und er verrichtet hier zuverlässig seinen Dienst. Im Schnitt habe ich dabei aktuell eine Blockquote von 30-40%. Das ist irgendwie schon eine ganze Menge und daher schaut man dann doch mal ab und zu in die Logfiles, um zu sehen was da genau geblockt wird und von welchen Devices die DNS-Requests kommen.

Pi-hole Dashboard mit den Top-ListsNatürlich sind da in erster Linie die üblichen Verdächtigen dabei, also die ganzen AdServer und Tracking-Domains. Aber auch eine ganze Reihe von Requests, die man in die Kategorie „Nach-Hause-Telefonieren“ einsortieren könnte. Insbesondere diese sorgen aber vermutlich auch für eine erhöhte Blockquote, denn wenn der Request nicht durchgeht, also ge-Pi-holed wird, dann wird es halt immer wieder probiert. Und vermutlich etwas häufiger, als wenn der Request ungefiltert durch ginge. Nun gut, aber dafür ist der Pi-hole ja auch da.

WPAD – Web Proxy Autodiscovery Protocol

Ein sehr häufiger Request fiel mir aber zuletzt etwas mehr ins Auge. Denn einige Rechner im Netz versuchten quasi ununterbrochen die Domain „wpad.localdomain“ aufzulösen. Innerhalb von 24h kam da schon mal locker eine 5-stellige Zahl zusammen. Wie sich schnell herausstellte, handelte es sich dabei um die automatische Proxy-Konfiguration von Windows. Und die abgefragte Domain „.localdomain“ stammt aus der Konfiguration eines meiner VLANs, die ich in meinem UniFi-System eingerichtet habe. Hier war ein Standardwert hinterlegt. Häufig findet man in Routern auch einfach nur „.local“ oder recht bekannt dürfte auch „fritz.box“ sein, wenn man eine FritzBox verwendet.

Und die Subdomain „wpad“ ist der Standard für das Web Proxy Autodiscovery Protocol (WPAD), das Web-Clients also insbesondere Web-Browsern helfen soll, automatisch die gültige Proxy-Konfiguration im lokalen Netz zu finden. Ich habe keinen Proxy im Einsatz, die Clients sollen die Webserver also immer direkt kontaktieren. Aber die große Anzahl der Requests erschien mir dann doch etwas unnötig und irgendwie unkoordiniert.

WPAD als mögliches Sicherheitsrisiko

In der Tat kann das WPAD-Protokoll zu einer Schwachstelle werden. Die Idee hinter der automatischen Proxy-Konfiguration ist im Prinzip die zentrale Einrichtung und zwar ohne beim Client etwas konfigurieren zu müssen. Ein Client verwendet dazu einfach den Hostnamen seiner Organisation oder des Routers, also in meinem Fall z.B. „.localdomain“ oder eben bei einer FritzBox „fritz.box“, setzt die Sudomain „wpad“ davor und versucht dann dort die Proxy-Konfigurationsdatei „wpad.dat“ (oder „proxy.pac“) zu finden. Wenn diese nicht gefunden wird, dann wird die Domain-Hierarchie durchgegangen, bis etwas gefunden wird:

http://wpad.localdomain/wpad.dat
http://wpad/wpad.dat
http://wpad.fritz.box/wpad.dat
http://wpad.box/wpad.dat
http://wpad/wpad.dat

Auf den ersten Blick fällt auf, dass z.B. bei der FritzBox die vermeintliche Domain „wpad.box“ auftaucht. Die neue Top-Level-Domain „.box“ ist seit November 2016 verfügbar, allerdings sind die kritischen Domains „fritz.box“ und „wpad.box“ bisher noch nicht vergeben. Dennoch kann theoretisch die Verfügbarkeit der TLD schon problematisch werden. Manche Clients versuchen auch die Domain „wpad.com“ aufzulösen. Hierbei wird noch deutlicher, welche mögliche Gefahrenquelle besteht, denn diese Domain existiert sogar.

Die Lösung: Eine eigene wpad.dat ausliefern

Die Lösung ist aber so einfach wie naheliegend: Man muss einfach nur sicherstellen, dass die Clients eine eigene, also vertrauenswürdige „wpad.dat“ finden. Und dazu ist der Pi-hole natürlich bestens geeignet.

1. WPAD-Domains auf den Pi-hole umleiten

Zunächst muss man dem Pi-hole beibringen, dass er selber für alle möglichen wpad-Domains zuständig ist. Dazu trägt man diese zunächst in die „/etc/hosts“ ein und am besten auch zusätzlich auch noch in die „/etc/pihole/lan.list“. Folgende Zeile sollte eingefügt werden:

192.168.0.53 wapd.local wpad.localdomain wpad.com wpad.de wpad

Oder bei der FritzBox:

192.168.0.53 wpad.fritz.box wpad.box wpad.com wpad.de wpad

Die IP-Adresse „192.168.0.53“ müsst Ihr natürlich durch die IP-Adresse Eures Pi-hole ersetzen. Ebenso die Liste der möglichen lokalen Domains. Ein Blick ins Query-Log des Pi-hole kann helfen, die entsprechenden Domains zu finden. Wichtig ist, dass insbesondere auch „wpad.com“ und „wpad“ angegeben werden, diese also automatisch im lokalen Netz bleiben.

Damit ist im ersten Schritt sichergestellt, dass die wpad-Domains alle lokal aufgelöst werden und auf die IP-Adresse des Pi-hole verweisen. Nun muss der Pi-hole nur noch dafür sorgen, dass er antwortet und eine „wpad.dat“ ausliefert.

2. Weiteren VirtualHost im Webserver einrichten

Auf dem Pi-hole läuft ja der Webserver lighttpd, der bereits für das Webinterface des Pi-hole zuständig ist. Diesen muss man nun so einrichten, dass dieser auch auf die wpad-Domain antwortet. Dazu muss man in der Datei „/etc/lighttpd/external.conf“ folgende Zeilen ergänzen:

$HTTP["host"] =~ "wpad" {
server.document-root = "/var/www/wpad/"
mimetype.assign = (
".dat" => "application/x-ns-proxy-autoconfig",
".pac" => "application/x-ns-proxy-autoconfig"
)
}

Diese sorgen dafür, dass alle Requests für Domains, die „wpad“ enthalten, ein anderes Stammverzeichnis (Document-Root) verwenden sollen. Standardmäßig liegt das Stammverzeichnis in „/var/www/html/“. Ich habe nun ein Verzeichnis „/var/www/wpad/“ angelegt und dieses als Stammverzeichnis für die wpad-Domains definiert. Die Angabe „mimetype.assign“ sorgt dafür, dass außerdem der korrekte MIME-Type für die Ausgabe von .dat- und .pac-Dateien verwendet wird.

3. Eigene WPAD-Konfigurationsdatei anlegen

Nun fehlt nur noch die WPAD-Konfigurationsdatei „wpad.dat“, die einfach im Verzeichnis „/var/www/wpad/“ angelegt werden muss. Der Inhalt ist sehr übersichtlich und gibt lediglich an, dass es keine Proxy-Server gibt und alle Verbindungen direkt erfolgen sollen:

function FindProxyForURL(url, host) {
return "DIRECT";
}

Die Datei kann man dann auch zusätzlich auch noch als „proxy.pac“ speichern. Zuletzt muss nur noch der Webserver neu gestartet werden:

sudo service lighttpd restart

Zum Testen braucht man im Browser lediglich die Adresse http://wpad.local/wpad.dat oder http://wpad/wpad.dat (bzw. die entsprechende lokale Domain) aufzurufen und der Browser sollte die „wpad.dat“ herunterladen. Das wars. Die automatische Proxy-Konfiguration im lokalen Netz sollte nun sicher sein.

Synology External IP Checker

Synology DDNS-EinstellungenEin weiterer häufiger und regelmäßiger DNS-Request stammt von meiner Synology-NAS. Obwohl ich kein DynDNS (DDNS) nutze (ich habe eine feste IP) und dieses daher im DiskStation Manager (DSM) abgeschaltet habe, ruft die Synology alle paar Minuten die Adresse „checkip.synology.com“ auf. Diese wird laut Synology nur dazu genutzt um die aktuelle externe IP-Adresse zu erfahren. Was in meinem Fall natürlich absolut unnötig ist.

Theoretisch gibt die Adresse http://checkip.synology.com nur die aktuelle externe IP-Adresse aus. Ich glaube zwar nicht, dass Synology da weitere Daten abgreift oder irgendetwas trackt, aber um es wie Horst Schlämmers Gisela zu sagen: „Isch möschte das nischt“.

Aber diesen Request kann man natürlich ebenso prima auf den Pi-hole umleiten. Also wieder in der die „/etc/hosts“ und der „/etc/pihole/lan.list“ folgende Zeile einfügen:

192.168.0.53 checkip.synology.com

Die IP-Adresse „192.168.0.53“ müsst Ihr natürlich wieder durch die IP-Adresse Eures Pi-hole ersetzen. Dann wird ein weiterer VirtualHost in der lighttpd-Konfiguration „/etc/lighttpd/external.conf“ eingefügt:

$HTTP["host"] == "checkip.synology.com" {
server.document-root = "/var/www/checkip/"
}

Ich habe also ein weiteres Stammverzeichnis „/var/www/checkip/“ definiert. Dort muss jetzt nur eine HTML-Datei „index.html“ abgelegt werden, die das Gleiche ausgibt wie der IP-Checker von Synology:

<html>
<head><title>Current IP Check</title></head>
<body>Current IP Address: ###.###.###.###</body>
</html>

Das „###.###.###.###“ müsst Ihr natürlich durch die statische IP-Adresse Eures Providers ersetzen.

Optional kann man das natürlich auch über ein PHP-Skript „index.php“ lösen, falls Ihr Eurer statischen IP-Adresse einen Hostname zugewiesen habt. Ich habe z.B. eine Subdomain eingerichtet und deren A-Record auf meine statische IP-Adresse gesetzt. Diese wiederum kann ich mit der php-Funktion „gethostbyname()“ auflösen und bekomme wieder meine IP-Adresse:

<html>
<head><title>Current IP Check</title></head>
<body>Current IP Address: <?php echo gethostbyname("subdomain.domain.tld"); ?></body>
</html>

Der Eintrag „subdomain.domain.tld“ muss dann natürlich durch Eure eigene Subdomain ersetzt werden. Somit bekommt die Synology immer die aktuelle IP-Adresse geliefert, ohne dass diese auf einen externen Dienst von Synology zugreifen muss.

Das Ganze macht natürlich nur Sinn, wenn man eine statische IP-Adresse hat. Bei DHCP bietet sich weiterhin an, einen DynDNS-Dienst zu verwenden und dann ist der IP-Checker von Synology schon irgendwie sinnvoll. Insbesondere, wenn man die Synology-NAS auf von extern erreichen will.

Teredo IPv6-Tunnel

Und noch weiterer Request ist mir im Query-Log recht häufig untergekommen. Mein Windows-Server versuchte regelmäßig die Domain „teredo.ipv6.microsoft.com“ aufzulösen. Bei Teredo handelt es sich um ein Übergangsprotokoll von Microsoft Windows für den Zugriff auf das IPv6-Netzwerk hinter dem NAT, also dem Router.

Allerdings läuft mein lokales Netz und auch mein Internetzugang komplett auf IPv4. Warum Windows trotzdem versucht, einen IPv6-Tunnel aufzubauen, bleibt mir daher mehr als unklar. Der Request verpuffte zwar ohnehin dank des Pi-hole im Nichts, aber ich wollte dann doch lieber die Ursache abschalten. In den Netzwerk-Einstellungen war IPv6 wie erwartet natürlich bereits überall deaktiviert.

In der Windows-Eingabeaufforderung (als Administrator starten) wurde mir allerdings Teredo noch als aktiv angezeigt:

ipconfig /all

Aber das lässt sich mit folgendem Befehl recht einfach abschalten:

netsh interface ipv6 set teredo disable

Damit wird Teredo komplett deaktiviert. In der Tat ist seitdem Ruhe und der Pi-hole wird nicht weiter mit unnötigen Requests belästigt. Auch wenn hier keine neue Aufgabe für den Pi-hole hinzugekommen ist, hat dieser zumindest geholfen, unnötige DNS-Requests zu finden.

Fazit

Ein regelmäßiger Blick in die Query-Logs macht also durchaus Sinn. Die Transparenz im lokalen Netzwerk ist mit dem Pi-hole deutlich größer geworden und eine theoretische Schwachstelle konnte beseitigt werden. Ich werde also auch weiterhin die Logs im Auge behalten und wenn nötig entsprechende Maßnahmen ergreifen.

Pi-hole Dashboard mit den Top-Lists
Pi-hole Dashboard mit den Top-Lists
Synology DDNS-Einstellungen
Synology DDNS-Einstellungen
Bisher 6 Kommentare
  1. Andreas K.

    Andreas K.

     

    18. November 2018, 16:29 Uhr

    Hallo und Danke für die Anleitung zum Thema wpad. Mit dem Eintrag habe ich die iphones meiner Kinder wieder ins WLAN bekommen. Mit Safari konnte ich bis dato keine Webseite aufrufen, oder nur zufällig oder stark verzögert.
    Was aber nicht klappt, ist die Anzeige einer wpad.dat
    Es kommt die Fehlermeldung im Firefox: "Die Verbindung mit dem Server www.wpad.local schlug fehl."
    Müssen den erstellten Verzeichnissen (sudo mkdir /var/www/wpad) oder Dateien (sudo touch /var/www/wpad/wpad.dat) irgendwelche Rechte zugewiesen werden?

  2. Thomas Mielke

    18. November 2018, 17:49 Uhr

    @Andreas: Der Fehler hört sich weniger nach einem Problem mit den Dateirechten an, denn dann würdest Du eine entsprechende Fehlermeldung vom Webserver bekommen (Error 403, Error 500 oder ähnliches).

    Ich vermute eher, dass Du in der „/etc/hosts“ oder „/etc/pihole/lan.list“ einen Fehler hast, sodass die Namensauflösung nicht wie gewünscht funktioniert.

  3. Andreas K.

    Andreas K.

     

    20. November 2018, 07:41 Uhr

    @Thomas: Danke, ich werde das nochmal prüfen, doch vorher rüste ich den Pi noch mit Unbound auf.

  4. Andreas K.

    Andreas K.

     

    21. November 2018, 09:50 Uhr

    So, nun habe ich das nochmal probiert und ich bekommen beim Aufruf von wpad.local "403 - Forbidden" und beim Aufruf von http://wpad/wpad.dat tatsächlich die Datei zum Donwload angeboten. Ich hatte glaube ich, den Neustart des Dienstes vergessen.
    Was aber mit den Einstellungen nach wie vor nicht klappt, ist die Kindersicherung der Fritzbox. Da müßte ja in den DNS-Einstellungen des Pihole die Fritzbox-IP rein.
    Gibt es denn die Möglichkeit zu beobachten, welchen Weg die Anfrage eines Clients zu einer Webadresse nimmt? Tracert (Win) zeigt mir nur die Fritzbox und dann alles ausßerhalb meines Netzes (was eben so sichtbar ist) bis zum Ziel. Aber ob die Anfrage über den pihole geht und dann die Fritzbox oder umgedreht? Kann man sowas "sichtbar machen"?

  5. Thomas Mielke

    21. November 2018, 09:54 Uhr

    @Andreas: Der 403 beim direkten Aufruf von http://wpad.local ist ja soweit richtig, denn es existiert ja keine "index.html" oder Ähnliches. Das ist ja auch nicht nötig.

    Bei der Kindersicherung hast Du aber vermutlich einen Denkfehler. In den DNS-Einstellungen des Pi-hole hat die IP-Adresse der FritzBox allerdings nichts zu suchen. In den Pi-hole gehören nur externe DNS-Server für Google oder Cloudflare. In der FritzBox muss die IP-Adresse des Pi-hole hinterlegt werden.

    Ein Traceroute hilft Die hier im übrigen nicht weiter. Der Pi-hole ist ein Nameserver, das bedeutet, er teilt dem dem Client nur IP-Adresse der angefragten Domain mit. Nicht mehr und nicht weniger.

  6. De. Gathmann

    De. Gathmann

     

    5. Dezember 2018, 12:08 Uhr

    Hallo und vielen Dank für die Anleitung zur Lösung der wpad-Anfragen. Hat mir sehr geholfen. Als alter Unix-Fan bin ich von dem Raspberry-Pi zusammen mit PI-Hole begeistert.

Dein Kommentar?

Menschlich? Dann gib bitte die 5 Zeichen genau so ein, wie Du sie in der Grafik lesen kannst. Keine 5 Zeichen? Erzeuge einfach einen neuen Code.

Gravatar:

Wenn Du möchtest, dass Dein Bild neben Deinem Kommentar erscheint, dann melde Dich einfach bei Gravatar an.

Nutzungshinweise:

Dein Kommentar erscheint nicht automatisch, sondern wird erst nach einer Prüfung manuell freigeschaltet. Ich behalte mir vor alle Kommentare zu löschen, die

  • rassistische, sexistische oder gewaltverherrlichende Inhalte haben,
  • zu kriminellen Aktionen aufrufen oder diese verteidigen,
  • beleidigende Inhalte besitzen,
  • Werbung für Dritte darstellen oder deren Inhalte einem Link auf fremde Angebote gleichkommt.