Die ursprüngliche Motivation…
Beim Aufsetzen eines Pi-Hole DNS Servers bzw. beim Blick auf dessen Statistiken ist mir aufgefallen, dass Windows den DNS-Server mit hunderten DNS-Anfragen flutet.
Abgefragt wird der Hostname wpad in Verbindung mit dem lokalen DNS-Suffix, als z.B. wpad.fritz.box
Offenbar sucht hier etwas nach einer automatischen Proxy-Konfiguration. Das möchte ich zumindest auf dem Notebook abschalten.
Der erste Schritt war, die üblichen Verdächtigen manuell auf „Keinen Proxy verwenden“ zu konfigurieren.
Das waren bei mir z.B.
- Die Internetoptionen in der Systemsteuerung
- Firefox
- Thunderbird
- Alles, was unten rechts im Tray erscheint oder direkt nach dem Windows-Start Updates anbietet (nVidia GeForce Experience, Owncloud Client, ein Verschlüsselungsprogramm usw. usf.)
- „Herr der Ringe Online“ und dessen Launcher (was ca. 75% des Verwendungszweckes darstellt).
Leider Gottes: Die Abfragen sind nicht gerade weniger geworden. Wir müssen also suchen statt raten 🙂
Protokollierung aller DNS-Abfragen
Unter https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon laden wir uns den Sysmon herunter. Das ZIP-Archiv wird entpackt, das zu unserer Architektur passende Binary wird in einer administrativen Eingabeaufforderung / Powershell mit dem Parameter -i installiert:
![](https://www.altmetaller.de/wp-content/uploads/2021/01/01_install_sysmon.png)
Wie die Ausgabe vermuten lässt, wird ein Windows-Service installiert. Dieser macht letztendlich nichts Anderes, als unsere Ereignisanzeige vollzuschreiben.
Das Ergebnis finden wir dort unter Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> Sysmon -> Operational
![](https://www.altmetaller.de/wp-content/uploads/2021/01/02_sysmonereignisse-1024x602.png)
Ein erster Blick offenbart, dass wir mit den Daten noch nicht viel anfangen können – die DNS-Abfragen fehlen (…sinnvollerweise, ansonsten würden wirklich zahlreiche Ereignisse protokolliert werden).
Wir müssen dem Sysmon also beipulen, dass er auch die DNS-Abfragen protokollieren soll.
Dafür erstellen wir in unserem vorhin entpackten Verzeichnis eine XML-Datei. In meinem Beispiel heißt die dnsabfragen.xml und hat folgenden Inhalt:
<Sysmon schemaversion="4.21"> <EventFiltering> <DnsQuery onmatch="exclude" /> </EventFiltering> </Sysmon>
Wir gehen noch einmal in die administrative Eingabeaufforderung in den entsprechenden Ordner und und übergeben dem Dienst die Konfigurationsdatei mit dem Parameter -c:
![](https://www.altmetaller.de/wp-content/uploads/2021/01/03_sysmonconfig.png)
Ein erneuter Blick in die Ereignisanzeige beweist, dass der Sysmon jetzt auch Ereignisse vom Typ 22 protokolliert.
Wir setzen einen Filter auf die ID, indem wir mit der rechten Maustaste auf das Protkoll klicken…
![](https://www.altmetaller.de/wp-content/uploads/2021/01/04_protokollfiltern-1024x602.png)
…im Kontextmenü „Aktuelles Protokoll filtern…“ auswählen…
![](https://www.altmetaller.de/wp-content/uploads/2021/01/05_event22.png)
…und die ID 22 in das Feld für die Ereignis-ID eingeben.
Nun heißt es „Abwarten und Tee trinken“. Irgendwann(!) wird unser Windows wieder einmal eine entsprechende DNS-Abfrage stellen.
Wir drücken also regelmäßig F5, schauen „immer wieder mal“ alle Ereignisse durch und werden irgendwann über kurz oder lang ein Ereignis finden, bei dem nach dem ominösen wpad-Host gefragt wird.
![](https://www.altmetaller.de/wp-content/uploads/2021/01/06_wpadereignis-1024x602.png)
Hier ist es ja schon! 🙂
Interessant ist hier die „ProcessID“. In diesem Screenshot also der Prozess 2884.
Und der Übeltäter?
„Schuldiger“ im Sinne der Anklage ist laut der Ereignisbeschreibung das Programm svchost.exe
Dieses Programm ist aber letztendlich aber „nur“ eine Art Starter für Windows-Dienste. Mit anderen Worten: svchost.exe wird gestartet, lädt Programmcode aus einer DLL-Datei und etabliert diesen als laufenden Prozess.
Das macht Windows letztendlich mit diversen Diensten, so dass uns diese Angabe nicht weiterhilft. Ein Blick in den Task-Manager offenbart diverse Prozesse mit dieser Bezeichnung…
Unter https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer finden wir den „Process Explorer“. Das ZIP-Archiv wird entpackt und das entsprechende Binary wird mit administrativen Rechten gestartet.
Das bedeutet: Wir klicken das Programmsymbol mit der rechten Maustaste an und wählen im Kontextmenü „Als Administrator ausführen“.
Tun wir das nicht, würden wir „nur“ die Prozesse des jeweiligen Benutzers sehen. Wir suchen aber nach einem Systemprozess, der in einem Kontext läuft, an den wir als Otto-Normaluser (hoffentlich) nicht drankommen.
Die Prozesse sind freundlicherweise schon nach der Prozess-ID sortiert (Spalte PID).
Kleine Anmerkung: Zu meiner Schande muss ich gestehen, dass die Screenshots auf unterschiedlichen Computern angefertigt habe. Wir nehmen einfach mal an, dass wir eben die Prozess-ID 2980 anstatt der 2884 ermittelt haben 🙂
Wir suchen uns also die Zeile mit dem ermittelten Prozess…
![](https://www.altmetaller.de/wp-content/uploads/2021/01/07_prozess.png)
…und klicken doppelt auf die entsprechende Zeile:
![](https://www.altmetaller.de/wp-content/uploads/2021/01/08_winhttpautoproxysvc.png)
Voilà – wir haben unseren Verdächtigen ermittelt.
Auf unserem System läuft ein Dienst mit der Bezeichnung WinHttpAutoProxySvc, der letztendlich verantwortlich für die Abfragen ist.
Hier in diesem Artikel geht es ja ausschließlich um die Ermittlung des verursachenden Prozesses. Auf die Funktion und den Sinn und Zweck werde ich hier jetzt nicht weiter eingehen. Auch gibt es keine Empfehlung, diesen Dienst zu deaktivieren.
Aufräumen
Wie schon erwähnt, werden auf diese Art und Weise eine ganze Menge Ereignisse protokolliert.
Auch wenn es sich ressourcentechnisch sicher nur um einen Tropfen auf dem heißen Stein handelt – brauchen tun wir das jetzt nicht mehr.
Es bietet sich an, den Service wieder zu deinstallieren, was letztendlich mit dem Parameter -u erfolgt:
![](https://www.altmetaller.de/wp-content/uploads/2021/01/10_uninstall_sysmon.png)
Bleibt eigentlich nur noch, „viel Erfolg“ bei der Suche zu wünschen 🙂
5 Antworten auf „Ursache für wpad DNS Abfragen ermitteln“
Endlich komme ich diesem Ärgernis näher. Vielen Dank!
Ich lerne also, dass die DNS-Abfrage an wpad.fritz.box von dem Dienst WinHttpAutoProxySvc verursacht wird.
Ich nehme an, das der Dienst nicht wirklich benötigt wird, weil ich ja keinen Proxy verwende.
Was muss ich machen, um den Dienst zu verhindern?
Hallo,
wenn Du Windows-R drückst, services.msc eingibst und die Eingabetaste drückst, gelangst Du in die Diensteverwaltung von Windows.
Dort kannst die Startart von dem Dienst auf „Deaktiviert“ setzen und den Dienst im Anschluss beenden. Die Deaktivierung des Dienstes ist wie gesagt umstritten, wobei ich aber nichts Konkretes gelesen habe, was dagegen spräche.
Mir persönlich reicht es, die Ursache zu kennen 🙂
Gruß und schönen Restsonntag,
Jörg
Leider lässt sich der Dienst nicht beenden. Damit kann ich auch nichts ausprobieren …. hilft nix, muss wohl mit dieser verzerrten Statistik in Pi-Hole leben.
Danke nochmal!
Hallo,
Quelle: Completely remove WPAD (Microsoft Technet)
Wenn es „nur“ um die störenden Abfragen im Pi-hole geht: Unter Settings -> API/Webinterfaces kannst Du unter „Top Domains / Top Advertisers“ eine Liste mit Domaineinträgen festlegen, die nicht in der Hitliste auftauchen. Mit Deaktivierung des Hakens bei „Show permitted domain entries“ erreicht man vermutlich(?), dass die Einträge auch nicht in den Log-Dateien auftauchen.
Vielleicht hilft es auch schon, für wpad.fritz.box einen Eintrag in der c:\windows\system32\drivers\etc\hosts zu setzen und dort für diesen Hostnamen 0.0.0.0 als IP anzugeben. Anzumerken ist jedoch, dass neuere Versionen des Windows-Defender das wieder rückgängig machen. In dem Fall muss man die Hosts-Datei also in die Ausnahmeliste packen. Quelle: Windows Defender zensiert hosts-Datei (heise.de)
Gruß,
Jörg
Statt 0.0.0.0 bitte 255.255.255.255.
In einigen Fällen könnte 0.0.0.0 so interpretiert werden, dass Anfragen an „jede IP-Adresse überhaupt“ gesendet werden, was nicht das gewünschte Ergebnis wäre, wenn man versucht, die Autoproxyerkennung zu deaktivieren. Daher ist es sicherer und vorhersehbarer, 255.255.255.255 zu verwenden.
In einer CVE bezüglich der wpad.dat schlägt Microsoft dies auch vor:
https://learn.microsoft.com/de-de/security-updates/securitybulletins/2016/ms16-077
——–
Web Proxy Automatic Discovery (WPAD) protocol
Das WPAD-Protokoll (Web Proxy Automatic Discovery) ermöglicht die automatische Erkennung von Web-Proxy-Servern. WPAD bietet einen Mechanismus, mit dem Clients einen WPAD-Eintrag finden können, der eine URL enthält, die auf einen Server verweist, auf dem die Dateien Wpad.dat und Wspad.dat erzeugt werden. Bei der Datei Wpad.dat handelt es sich um eine JavaScript-Datei, die eine Standard-URL-Vorlage enthält, die vom Internet Explorer erstellt wird. Die Datei Wpad.dat wird von Web-Proxy-Clients für automatische Erkennungsinformationen verwendet.