Page 2 of 2

Re: Bei ablauf der Clientinstallation fehlen updates?

PostPosted: 10.11.2018, 14:19
by josalom
War das denn derselbe Rechner, mit dem die Updates auch heruntergeladen wurden?

ja das war der gleiche Rechner und beide Code-Fenster sind auszüge dessen wsusofflineupdate.log.

Dann konnte dieser Rechner zwischendurch die Root-Zertifikate aktualisieren.


Verstehe ich nicht, da Alle Rechner jederzeit (ausser Provider hat Störung) ins Internet verbinden können.
Ich gehe davon aus, dass der wsusofflineupdater diese Root -Zertifikate doch ebenfalls aktualisiert selbst wenn es nicht der gleiche Rechner ist und der Internetzugang erst später erfolgen würde. Weil wenn nicht dann wäre ja die Sicherheit des Systems potentiell gefährdet durch falsche oder fehlerhafte Zertifikate die nicht ersetzt wurden.


Windows Vista und neuere Windows-Versionen aktualisieren die Root-Zertifikate selber, sobald sie online gehen dürfen. Klingt für mich nach einer plausiblen Erklärung.

Wäre plausibel, aber der wsus soll doch auch ein system das frisch aufgesetzt wird und erstmal ohne Internet läuft auf den aktuellen Stand der Technik bringen um die Sicherheit für den Internetzugang zu gewährleisten, unter anderem. Ohne aktualisierung der Root-Zertifikate schwer vorstellbar, ausserdem prüft der Updater nicht auch diese?

Ansonsten vergleiche doch selber einmal, ob es tatsächlich Unterschiede in den heruntergeladenen Dateien zwischen Windows und Linux gibt. Dazu dienen die beiden Skripte im Verzeichnis wsusoffline/sh/comparison-linux-windows.

Das Skript compare-integrity-database.bash vergleicht die Integrity Database von zwei verschiedenen wsusoffline-Installationen, also jeweils die Ordner wsusoffline/client/md unter Linux und Windows. Diese Ordner enthalten Prüfsummen für alle heruntergeladenen Dateien. Wenn alle Prüfsummen gleich sind, sind auch die Download-Ordner gleich.

Für diesen Vergleich musst Du also nur den Ordner "md" mit den Prüfsummen von Windows auf den Linux-Rechner kopieren.

Die Pfade zu den beiden "md"-Ordnern müssen in das Skript eingetragen werden. Das Skript vergleicht dann die hashdeep-Dateien aus beiden Ordnern. Die meisten Dateien sollten genau gleich sein, wenn man die Zeilen sortiert. Nur die beiden hashdeep-Dateien für die Virusdefinitionen (msse und wddefs) können unterschiedlich sein, weil die Virusdefinitionen alle zwei Stunden aktualisiert werden.


Sehr guter Tip, perfekte Anletung für einen Anfänger und auch durchgeführt von mir mit diesem Ergebnis in der Schlusszeile:
Code: Select all
Files /tmp/md-windows/hashes-win-glb.txt and /tmp/md-linux/hashes-win-glb.txt are identical
Files /tmp/md-windows/hashes-wsus.txt and /tmp/md-linux/hashes-wsus.txt are identical


Das Skript compare-update-tables.bash dient speziell dem Vergleich von Office-Updates.

Ich habe das oft genug gemacht und bin mir ziemlich sicher, dass es keine Unterschiede gibt.


Code: Select all
Files /tmp/ofc-windows/UpdateTable-ofc-deu.csv and /tmp/ofc-linux/UpdateTable-ofc-deu.csv are identical
Files /tmp/ofc-windows/UpdateTable-ofc-enu.csv and /tmp/ofc-linux/UpdateTable-ofc-enu.csv are identical
Files /tmp/ofc-windows/UpdateTable-ofc-glb.csv and /tmp/ofc-linux/UpdateTable-ofc-glb.csv are identical


Also sind beide Identisch - hervorragend.

Als Fazit würde ich derzeit ziehen, dass MS irgendwelche Änderungen nach erstellung der wsusscn2.cab an den Updates durchgeführt hat und dies zu meinen
"not Found" Meldungen im Updater führten, bleibt manchmal tatsächlich nur das Problem auszusitzen.

Vielen Dank für die sehr ausführliche Hilfestellung

gruß
josalom

Re: Bei ablauf der Clientinstallation fehlen updates?

PostPosted: 11.11.2018, 14:05
by hbuhrmester
Verstehe ich nicht, da Alle Rechner jederzeit (ausser Provider hat Störung) ins Internet verbinden können.


Insgesamt halte ich es immer noch am wahrscheinlichsten, dass die Probleme durch fehlende Root-Zertifikate während der Installation verursacht werden. Gerade für die Kombination von Windows 7 und .NET Frameworks gibt es bereits Fehlerberichte, auch in diesem Forum. Diese habe ich weiter oben zusammengefasst: viewtopic.php?f=9&t=8587#p27200

Doch das gilt vor allem, solange die Rechner offline sind, fehlende Zertifikate also nicht selber suchen und installieren können.

Wenn die Rechner online sind, lässt es sich nur schwer nachvollziehen, warum es mal klappt und mal nicht.

Vielleicht hängt es auch vom Zustand des Dienstes "Windows Update" ab. Im Normalzustand sollte er "laufen", also weder deaktiviert noch gestoppt sein. Das gilt auch, wenn "automatische Updates" deaktiviert sind.

Beim Download werden die digitalen Signaturen mit Sigcheck überprüft. Wenn dabei ein Root-Zertifikat fehlt, kann es nachgeladen werden. Der Dienst "Windows Update" wird dabei nicht modifiziert.

Bei der Installation wird der Dienst erst gestartet (falls er noch nicht läuft), um nach fehlenden Updates suchen zu können. Dann wird er gestoppt, um die Updates ungestört installieren zu können. Das geht auch aus den beiden Protokollen hervor, die Du in viewtopic.php?f=9&t=8587#p27201 gepostet hast:

Code: Select all
27.10.2018 19:15:56,88 - Info: Waiting for service 'wuauserv' to reach state 'Running' (timeout: 60s)
27.10.2018 19:15:56,88 - Info: Service 'wuauserv' reached state 'Running'
27.10.2018 19:15:56,73 - Info: Started service 'Windows Update' (wuauserv)
27.10.2018 19:25:47,75 - Info: Listed ids of missing updates
27.10.2018 19:25:54,80 - Info: Listed ids of installed updates
...
09.11.2018 19:20:21,29 - Info: Listed update files
09.11.2018 19:20:36,44 - Info: Stopping service 'Windows Update' (wuauserv)
09.11.2018 19:20:36,66 - Info: Waiting for service 'wuauserv' to reach state 'Stopped' (timeout: 180s)
09.11.2018 19:20:36,67 - Info: Service 'wuauserv' reached state 'Stopped'
09.11.2018 19:20:36,66 - Info: Stopped service 'Windows Update' (wuauserv)


Während der Installation werden die digitalen Signaturen noch einmal überprüft. Vielleicht können fehlende Root-Zertifikate dann aber nicht mehr automatisch installiert werden.

Fehler während der Installation gehen vielleicht auch aus der Logdatei C:\Windows\WindowsUpdate.log hervor, die aber etwas länger und unübersichtlicher ist.

Am Ende der Installation wird der Dienst "Windows Update" wieder in den ursprünglichen Zustand versetzt.

Das sind dann aber wilde Spekulationen. Letztlich müsste man es Schritt für Schritt nachvollziehen und testen.



Ob die Zertifikate eine Rolle spielen, kann man am ehesten an einem Rechner testen, der noch nicht aktualisiert wurde, und der keinen Internet-Zugang hat.

Dann kann man zum Beispiel die digitale Signatur des Installers von .NET Framework 4.7.2 mit chktrust oder signtool überprüfen:

Code: Select all
chktrust NDP472-KB4054530-x86-x64-AllOS-ENU.exe
signtool verify /a NDP472-KB4054530-x86-x64-AllOS-ENU.exe


Entweder ist die digitale Signatur dann einfach "gültig" oder es wird ein Fehler angezeigt: "A certificate chain could not be built to a trusted root authority".



Es werden auch nicht alle Versionen der .NET Frameworks unterstützt: Aus den Microsoft-Support-Seiten geht hervor, dass nur die Versionen 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1 und 4.7.2 unterstützt werden.

Hier fehlen also 3.5, 4.5 und 4.5.1. Diese Versionen müssen erst auf 3.5.1 und 4.5.2 aktualisiert werden.


Ich gehe davon aus, dass der wsusofflineupdater diese Root -Zertifikate doch ebenfalls aktualisiert selbst wenn es nicht der gleiche Rechner ist und der Internetzugang erst später erfolgen würde. Weil wenn nicht dann wäre ja die Sicherheit des Systems potentiell gefährdet durch falsche oder fehlerhafte Zertifikate die nicht ersetzt wurden.


Leider nein. Für Windows XP und Windows Server 2003 gab es die beiden Utilities rootsupd.exe und rvkroots.exe, um die installierten Zertifikate offline aktualisieren zu können. Solange es diese Programme gab, wurden sie von WSUS Offline Update auch auf anderen Windows-Versionen installiert. Doch die letzten Versionen stammen von 2014/2015, und rootsupd.exe ist mittlerweile ganz von den Microsoft-Servern verschwunden.

Man kann rootsupd.exe noch auf archive.org finden, aber optimal ist das natürlich nicht: viewtopic.php?f=3&t=4820&p=25057#p25057

Einen passenden Ersatz für eine Offline-Aktualisierung gibt es aber nicht, jedenfalls nicht, um alle installierten Zertifikate auch von Drittanbietern aktualisieren zu können. Vielleicht kann man aber ein oder zwei fehlende Root-Zertifikate aus dem Microsoft PKI Repository ergänzen.

Ob das wirklich ein Risiko darstellt, weiß ich nicht. Aktuelle Windows-Versionen überprüfen und aktualisieren die verwendeten Zertifikate laufend beim Zugriff. Das geht letztlich schneller, als wenn man auf ein Programm vertraut, das nur alle paar Monate mal aktualisiert wird (oder wurde).


Also sind beide Identisch - hervorragend.


Freut mich, dass die Linux-Skripte diesen Test bestanden haben. :-)

Gruß
hbuhrmester

Re: Bei ablauf der Clientinstallation fehlen updates?

PostPosted: 12.11.2018, 01:03
by josalom
Whow das habe ich bisher nicht so erfasst und verstanden, Vielen Dank für die Geduld und Aufklärung.

Aber letzte Frage in diesem zusammenhang die evtl. uns beide schlauer macht - wohl eher mich :oops:

Beim Download werden die digitalen Signaturen mit Sigcheck überprüft. Wenn dabei ein Root-Zertifikat fehlt, kann es nachgeladen werden. Der Dienst "Windows Update" wird dabei nicht modifiziert.


Diese Sigcheck Prüfung findet diese jedesmal bei wsus Download statt? Eine Information die ich habe besagt dass Sigcheck z.B. bei einem Raspberry nicht läuft.

Stellt das evtl. ein Problem dar und sollte ich evtl doch lieber die Downloads über Windows machen in ermangelung eines alternativen funktionierenden Linux systems bei mir vor Ort? Liegt nicht am fehlenden Linux sondern fehlenden Rechner dafür ;) Raspberry war ein günstiger Versuch zu diesem Zweck und läuft in diesem Sinne bisher zufriedenstellend - aber wenn ich mir nur Probleme einhandle wird es von mir in Frage gestellt.

Nach wie vor bin ich von wsus und seinen Skripten überzeugt aber ein Raspberry ohne Sigcheck?? Macht das Sinn??

Gruß
josalom

Re: Bei ablauf der Clientinstallation fehlen updates?

PostPosted: 12.11.2018, 13:16
by hbuhrmester
Diese Sigcheck Prüfung findet diese jedesmal bei wsus Download statt? Eine Information die ich habe besagt dass Sigcheck z.B. bei einem Raspberry nicht läuft.


Sigcheck wird zurzeit nur unter Windows verwendet.

Sigcheck läuft in wine unter Linux, allerdings mit Einschränkungen.

wine ist eine Kompatibilitätsschicht, um Windows-Anwendungen und Spiele unter Linux laufen zu lassen. Es stellt Bibliotheken und kleinere Hilfsprogramme zur Verfügung, die ähnlich funktionieren wie unter Windows. wine kann aber keine Hardware emulieren, schon gar keine anderen CPUs.

Sigcheck läuft deshalb nur auf gewöhnlichen Intel- und AMD-Prozessoren. Auf einem Raspberry Pi mit ARM-Prozessor wird es nicht laufen.

Wenn man Sigcheck unter wine laufen lässt, kann es zunächst nur feststellen, ob eine Datei digital signiert ist oder nicht. Es kann die digitale Signatur aber nicht überprüfen. Das liegt anscheinend an Einschränkungen der Bibliotheken, die wine zur Verfügung stellt.

Um Sigcheck ohne solche Einschränkungen laufen zu lassen, muss man:

  • die wine-Bibliothek CRYPT32.dll durch eine native Windows-Bibliothek ersetzen,
  • alle benötigten Microsoft-Zertifikate von Windows nach Linux kopieren.

Das allerdings habe ich bis jetzt nicht geschafft. Bis auf weiteres habe ich die Überprüfung mit Sigcheck deshalb deaktiviert. Man kann sie in der preferences-Datei leicht wieder aktivieren, aber dann funktioniert sie nur "halb".



Die meisten Sicherheits-Updates können aber auf einem anderen Weg verifiziert werden: Bei alle dynamischen Updates, die aus der WSUS-Katalogdatei extrahiert werden, ist der SHA1-Hash direkt in den Dateinamen eingesetzt. Wenn der Dateiname zum Beispiel ndp35sp1-kb2604111-x64_01fb9c1c60d9729d07977a7b142aab80ce9cc389.exe ist, dann ist 01fb9c1c60d9729d07977a7b142aab80ce9cc389 der SHA1-Hash. Das lässt sich leicht mit den berechneten Werten vergleichen, zum Beispiel mit sha1sum:

Code: Select all
$ sha1sum ndp35sp1-kb2604111-x64_01fb9c1c60d9729d07977a7b142aab80ce9cc389.exe
01fb9c1c60d9729d07977a7b142aab80ce9cc389  ndp35sp1-kb2604111-x64_01fb9c1c60d9729d07977a7b142aab80ce9cc389.exe


In den hashdeep-Dateien aus dem Verzeichnis client/md tauchen die SHA1-Hashe in den Spalten 3 und 5 auf:

Code: Select all
877680,73a9fca0df37199cb02a449f0336c01e,01fb9c1c60d9729d07977a7b142aab80ce9cc389,9f681208ded512dc8fb3343e78ede9b231bdea99f6c4524f355dd38b81686e95,..\dotnet\x64-glb\ndp35sp1-kb2604111-x64_01fb9c1c60d9729d07977a7b142aab80ce9cc389.exe


Dann kann man sie leicht extrahieren und vergleichen. Das ist ein einfacher Test, der auch unter Linux funktioniert.


Nach wie vor bin ich von wsus und seinen Skripten überzeugt aber ein Raspberry ohne Sigcheck?? Macht das Sinn??


Keine Ahnung – das ist deine Entscheidung.

Gruß
hbuhrmester