Windows 10 und der Datenschutz

Nachdem Windows 10 jetzt seit kurzem erhältlich ist und Microsoft neue Datenschutzbestimmungen vorgestellt hat (http://www.heise.de/newsticker/meldung/Windows-10-Neue-Datenschutzbestimmungen-Windows-wird-zur-Datensammelstelle-2765536.html) ist eine Diskussion über die weitreichenden Zugriffsrechte auf die Daten der Windows User die Microsoft sich einräumt entbrannt.

Natürlich gibt es die Möglichkeit viele dieser Zugriffe zu deaktivieren, eine recht sinnvolle Auflistung ist unter https://www.reddit.com/r/Windows10/comments/3f38ed/guide_how_to_disable_data_logging_in_w10/ zu finden.

HWiNFO unterstützt jetzt das Aquaero

Kurzmitteilung

Das ohnehin recht leistungsstarke Hardwaremonitoringtool HWiNFO unterstützt in der aktuellen Beta-Version v4.47-2340 jetzt auch das Aquaero von Aquacomputer.

Ausgelesen werden alle Temperatursensoren einschließlich denen der Lüfterendstufen und Aquaero CPU, im Aquaero angelegte virtuelle Temperatursensoren sowie Drehzahl, Spannung und Stromaufnahme der angeschlossenen Lüfter, Durchfluss, die Daten von per Aquabus angeschlossenen Aquastream Pumpen und die Aquaero Leistungsmessung.

Über HWiNFO ist es auch möglich die Daten vom Aquaero ins Rivatuner OSD zu bringen.

2014-11-06 10_18_59-HWiNFO64 v4.47-2340 Sensor Status

WSUS 3.0: „Selbstupdate funktioniert nicht“ in der Ereignisanzeige unter Windows Server 2008 / IIS7

Vor kurzem installierte ich meinen Server neu nachdem ich meine SQL Server Konfiguration dermaßen zerschossen hatte dass sich keine Version mehr richtig installieren aber auch keine mehr richtig deinstallieren ließ.

Schuld war ich natürlich selbst weil ich mir eingebildet hatte von SQL Server 2008 auf SQL Server 2008 R2 updaten zu müssen obwohl keine Not bestand.

Nun aber zum eigentlichen Problem um das es hier gehen soll. Ich finde es so erwähnenswert da zwar viel darüber im Internet zu finden ist, ein Fall wie meiner war in meiner halbtägigen Recherche gestern aber keiner dabei.

Es ist mir letztendlich tatsächlich gelungen das Problem zu lösen, aber ich will am Anfang beginnen:

Das Problem

Der Stein des Anstoßes war im Windows-Anwendungsprotokoll der Ereignisanzeige zu finden. Dort prangte – mehrfach – der Fehler mit der ID 1111 und der Beschreibung „Selbstupdate funktioniert nicht“.

Was macht Selfupdate eigentlich auf dem WSUS?

Selfupdate ist auf dem WSUS ein virtuelles Verzeichnis auf der Standard-IIS-Site auf Port 80 in dem der jeweils aktuelle Windows Update Client für alle WSUS-Clients verfügbar ist. Benötigt ein Windows-PC der sich vom WSUS Updates holen will eine aktuellere Version der Windows Update Software dann bekommt er sie aus dem Verzeichnis /Selfupdate auf dem WSUS und zwar immer auf Port 80.

Die Suche nach der Nadel im Heuhaufen

Nun habe ich gemacht was ich immer mache wenn ich ein Problem habe mit dem ich nichts oder wenig anfangen kann: Google bemüht.

Ich bin dabei auch auf äußerst zahlreiche Lösungsvorschläge gestoßen die sicherlich meistens ins schwarze treffen was die vielen Forenbeiträge auf die ich dabei gestoßen bin letztendlich auch dokumentiert haben, leider nichts für mich passendes. Hier mal ein kleiner Auszug was im groben dabei war:

  • Existiert das virtuelle Verzeichnis /Selfupdate auf Port 80 auf dem WSUS
  • Sind die Berechtigungen im Verzeichnis /Selfupdate (auch im Dateisystem des Servers, der Ordner befindet sich im Installationsverzeichnis von WSUS) korrekt eingestellt?
  • „SSL benötigt“ ist auf dem virtuellen Verzeichnis „/Selfupdate“ deaktiviert?
  • Die IP-Bindung vom IIS ist korrekt
  • Port und SSL-Status sind in der Registry korrekt eingetragen
  • Namen werden im Netzwerk richtig aufgelöst?

Ich gehe jetzt bewusst nicht auf jede einzelne Problemlösung ein, da findet sich bei Google mehr als genug brauchbares und an dieser Stelle möchte ich auch an WSUS.DE verweisen, wo jeder mit beliebigen WSUS-Problemen kompetente Hilfe finden dürfte.

Mir war nach etlichem herumprobieren klar geworden dass ich per Browser von einem Client aus absolut Problemlos auf den Inhalt von „/Selfupdate“ auf dem Server zugreifen konnte, nach etwas längerem Experimentieren fiel mir dabei aber eins auf: Vom Server selbst aus ging es nicht.

Versionskonflikte

Es ging über die IP aber nicht über „server“ und auch nicht über „localhost“. Nslookup bescheinigte mir eine korrekte IPv4 Namensauflösung, mein Ping an „server“ ging an die IPv6 Adresse (IPv6 ist seit Windows Server 2008 obligatorisch) und kam auch an.

Halt! IPv6? Genau! Der IIS war nur dummerweise darüber eben nicht erreichbar, da es hier bei mir eine kleine aber entscheidende Besonderheit gibt:

Mein Server hat 2 Netzwerkkarten (1 GBit/s PCI + 100 Mit/s onboard) und dementsprechend 2 IPs im LAN (192.168.1.2, 192.168.1.3).
Per DNS wird nur die „192.168.1.2“ im LAN mit „Server“ aufgelöst, die „192.168.1.3“ mit meinem auch extern erreichbaren DynDNS-Namen (<Beispiel>.homelinux.net).
Sinn der Sache ist, dass im Prinzip alles über die 192.168.1.2 laufen soll, die per Portforwarding auch von außen erreichbare IIS-Instanz sich von intern genauso verhält wie von extern (eben dass sie über Port 80 und den DynDNS-Namen erreichbar ist wie von außen auch).

Der Hase im Pfeffer

Genau hier liegt das Problem: Ein häufig gegebener (und logischerweise funktionierender) Tip ist, darauf zu achten dass eine Bindung vom Webserver auf Port 80 auf *, also sämtliche IPs des Servers vorhanden ist. Das ist idr. auch kein Problem weil auf den wenigsten Servern die WSUS ausführen eine zweite IP vorhanden sein dürfte auf der auf Port 80 ein zweiter Webserver (oder anderer Dienst) läuft.

Die Lösung bestand letztendlich darin der Standard-IIS-Instanz mit dem Selfupdate-Verzeichnis auch eine Bindung zur IPv6 Adresse zu verpassen.

Die Alternative wäre wohl IPv6 zu deaktivieren, allerdings soll es dabei unter einigen Umständen zu Problemen kommen (insbesonderes bei Exchange, was ich allerdings nicht einsetze). Noch habe ich mich zu diesem drastischen Schritt nicht durchringen können.
Natürlich stelle ich mir die Frage was nun ist wenn ich einen Dienst habe der gar nicht IPv6 fähig ist und vom Server selbst aus über den Hostnamen erreichbar sein soll? Vermutlich ist er dann eben nicht erreichbar und ich muss IPv6 doch abschalten.

Ich lasse das jetzt an dieser Stelle so stehen, mein Fehler in der Ereignisanzeige ist weg und ich bin für’s erste zufrieden.

Letztendlich bestätigt mir das aber meine Einstellung pro Server nur so wenig Dienste wie möglich laufen zu lassen damit sich nichts gegenseitig in die Quere kommen kann. Ohne die zweite IIS-Instanz auf der zweiten IP-Adresse wäre das Problem so nicht aufgetreten da die Bindung der Standardwebseite – wie standardmäßig vorgegeben – schlicht auf allen IPs bestanden hätte.

Es geht auch anders

Nachdem ich mich insbesondere unter http://www.msxfaq.de/konzepte/ipv6.htm noch ein wenig über IPv6 unter Windows Server 2008 / Vista aufwärts belesen habe ist mir noch ein alternativer Lösungsvorschlag eingefallen, ohne IPv6 auf die Holzhammermethode komplett deaktivieren zu müssen:

Setzt man den Registrywert unter

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"DisabledComponents"=dword:0xffffffff

auf den Wert 0x20 wird IPv4 bevorzugt vor IPv6 verwendet.
IPv6 bleibt dann aktiv, kommt einem sofern nicht explizit verwendet jedoch nicht in die Quere.

VMWare vSphere 5 steht zum Download bereit

Die neue Version 5 von VMWare’s Enterprise Virtualisierungssuite ist fertig.

Die kostenlose Version des vSphere Hypervisor 5 bekommt man hier, die Evaluierungsversion der kostenpflichtigen Versionen hier.

Mit Version 5 entfällt der ESX Server endgültig, es gibt jetzt nur noch den vSphere Hypervisor (ESXi).

RADIUS Server zur WLAN-Absicherung unter Windows Server 2003 einrichten

Motiviert durch die Lektüre des Artikels WLAN sichern mit RADIUS bei heise Netze wollte ich das ganze mal unter Windows Server 2003 nachbauen.

Ich möchte das Thema hier bewusst nicht erschöpfend behandeln. Wer gewisse Grundkenntnisse zum Thema RADIUS hat oder es einfach mal so probieren möchte sollte mit meiner Beschreibung aber einigermaßen dazu in der Lage sein ein einfaches Setup aufzubauen.
Jedem der sich für das Thema ernsthaft interessiert möchte ich die Lektüre des verlinkten Artikels bei heise Netze übrigens dringend empfehlen. Dieser schadet übrigens auch als Grundlage für meinen Kurztrip nichts.

Prinzip

Kurz umrissen verwendet man bei der RADIUS Authentifizierung an einem WLAN kein WLAN Passwort das für alle gültig ist sondern individuelle Zugänge. Bei meiner Umsetzung in Verbindung mit Active Directory ist idr. das eine Userkennung oder ein Computerkonto im AD.

Dabei nimmt der AP die Loginanfrage entgegen und authentifiziert diese gegen den RADIUS Server der dann die Freigabe gibt sodass der RADIUS-fähige WLAN AP die Freigabe gibt und den Client ins Netz lässt – oder eben nicht. Wer sich genauer für die Funktionsweise und gebräuchlichen Begrifflichkeiten interessiert kann sich darüber ebenfalls im oben verlinkten Artikel bestens informieren.

Voraussetzung

Voraussetzung für die Umsetzung ist ein WLAN AP der RADIUS kann. Mein Linksys WAP610N kann RADIUS in Verbindung mit WPA2 Enterprise.

Installation & Konfiguration

Auf dem Server der RADIUS-Server werden soll installiert man zuerst (unter Systemsteuerung -> Software -> Windows-Komponenten hinzufügen/entfernen) den „Internetauthentifizierungsdienst“ (unter „Netzwerkdienste“).

Diesen findet man anschließend unter „Systemsteuerung -> Verwaltung“ wieder.

In der MCC-basierten Verwaltung legt man nun im Knoten „RADIUS-Clients“ den AccessPoint an.
Vorsicht: die Bezeichnung „RADIUS-Client“ mag etwas irreführend klingen. Gemeint sind hier nicht die Clients die sich später per RADIUS ins WLAN einklinken sondern die „Authenticators“, also der WLAN AP selbst der Verbindungsanfragen beim RADIUS Server prüft.

Wichtig sind hier die Angaben „Adresse“ (ich verwende in solchen Fällen gern die IP-Adresse weil DNS-Störungen dann keinen Einfluss auf die Funktion haben) und „Gemeinsamer geheimer Schlüssel“. Der gemeinsame geheime Schlüssel ist ein Passwort das im Zusammenhang mit RADIUS auf dem AP ebenfalls eingetragen werden muss damit sich der AP gegenüber dem RADIUS Server Authentifizieren kann.

Der nächste ausschlaggebende Punkt sind die RAS-Richtlinien.
An dieser Stelle werden Regelsätze festgelegt nach denen Verbindungsanforderungen geprüft und erlaubt oder verweigert werden.

Ich habe die Standardrichtlinie gelöscht und mir eine eigene gebaut. Am einfachsten geht das mit der Verwendung des Assistenten die ich im folgenden mit Screenshots dokumentiert habe.

Die Verbindungsanforderungsrichtlinien unter dem Knoten Verbindungsanforderungsverarbeitung sind vor allem dann interessant wenn Verbindungsanfragen unter bestimmten Umständen (oder immer) an andere RADIUS Server weitergegeben werden sollen.

Für Setups im einfacheren Umfang sind diese Regeln nicht wichtig und es ist auch nicht notwendig hier Änderungen vorzunehmen da die Standardrichtlinie für das einfache Szenario dass der eben installierte RADIUS Server alle Verbindungsanfragen bearbeitet bereits korrekt konfiguriert ist.

Fehlerbehandlung

Sämtliche Fehler- und Erfolgsmeldungen auf dem RADIUS-Server tauchen in der Ereignisanzeige auf dem RADIUS-Server im Protokoll System unter der Quelle IAS auf.

VMWare ESXi 4.1 auf Asus P5Q PRO

Ich wollte mal testen wie das so mit dem ESXi auf einem USB-Stick funktioniert.

Es ist nicht mein Ziel hier eine weitere Anleitung zu schreiben wie man den ESXi bootfähig auf einen USB-Stick bringt, alle die in dieser Richtung interessiert sind möchte ich auf die tolle Anleitung im Thomas Krenn Wiki verweisen.

Nachdem ich die Geschichte mit DD unter Windows nicht auf Anhieb hin bekommen hab hab ich’s etwas umständlicher gemacht und eine Linux VM aus VMWare Workstation heraus verwendet um den ESXi auf den USB-Stick zu schreiben.

Nur um später lesen zu dürfen, dass sich der ESXi 4.1 wohl auch direkt vom Installer von der CD gebootet auf dem Stick installieren lässt.

Ich habe auf dem Asus P5Q PRO nur ein paar Tests durchgeführt, sprich eine VM installiert die per iSCSI auf meinem Server lag (unter Verwendung von Solar Winds Free iSCSI Target).

Als Netzwerkkarte diente die Intel Pro/1000 PT Desktop die ich ohnehin in meiner Zockkiste hab, ESXi hat sie erkannt und auch was damit anfangen können.

Die Onboard Netzwerkschnittstelle vom P5Q PRO ist bei mir im BIOS deaktiviert, ausprobiert habe ich sie nicht.

Logdateien per SQL abfragen – mit Microsoft Log Parser

Wer in die Verlegenheit kommt Logdateien, z.B. die Ereignisanzeige (Eventlog) von Windows, IIS Logdateien, die Registry, das Dateisystem oder Active Directory per SQL abzufragen kommt am Microsoft Log Parser nicht vorbei.

Das Tool ermöglicht detaillierte Abfragen über SQL und unterstützt als Ausgabeformat u.a. XML und CSV.

Man lernt nie aus – Bad TCP Checksum in Wireshark richtig deuten

Neulich wurde ich bei Wireshark auf eine sehr hohe Anzahl „Bad Checksums“ – also falscher Prüfsummen – aufmerksam und befürchtete bereits das schlimmste.

Hätte ich sofort gegooglet hätte ich mir auch keine Sorgen gemacht:
Bei genauerem Hinsehen merkt mal rel. schnell, dass es sich dabei idr. um Pakete handelt die vom eigenen Host gesendet wurden.

Die fehlerhafte Prüfsumme ist in solchen Fällen idr. durch aktiviertes „TCP Checksum Offloading“ bedingt, d.h. die Prüfsumme wird erst kurz vor dem endgültigen absenden des Pakets von der Netzwerkkarte erzeugt und ist zu dem Zeitpunkt zu dem Wireshark das Paket zu Gesicht bekommt noch gar nicht berechnet.

Will man sich auf diese Daten also verlassen können hilft nur das Abschalten des Checksum Offloading im Treiber der Netzwerkkarte.