UPDATE: Und nun fehlen sogar bei VZ eigenen Diensten die Fotos. Alles sehr merkwürdig.

Der Server ist mit hilfe eines Heartbeat-Tunnels über sixxs.net an das Internet angebunden. Mir wurde das Netzwerk 2a01:198:200:7a6::/64 für die Punkt-zu-Punkt Verbindung zum Tunnelbroker zugewiesen. Der Aufbau des Tunnels erfolgt über das “Automatic IPv6 Connectivity Client Utility”, kurz AICCU.

T-Home verwendet 2 getrennte logische Verbindungen auf der DSL-Strecke. Um diese Trennung überhaupt zu ermöglichen, werden die Ethernet-Frames (die wiederum mit LLC Kapselung übertragen werden) mit einer VLAN-ID versehen. Dies ermöglicht dem Router jedes VLAN als getrenntes Netz zu betrachten. Über VLAN 7 wird eine PPPoE Verbindung aufgebaut. Diese Strecke wird auch als Default route verwendet. In VLAN 8 wird über DHCP eine IP-Adresse und einige Routen zu den IPTV Servern der Telekom übergeben. Über dieses VLAN werden auch die Multicast-Pakete des IPTV übertragen. Der Router selbst muss über einen IGMPv3-Proxy verfügen, um die im LAN angeforderten Multicast-Adressen über IGMP auf VLAN 8 anzufordern und lokal zu verteilen.

Wie funktioniert das ganze? Eigentlich recht simpel. Der Mediareceiver registriert sich im LAN als Multicast-Fähiges Gerät und meldet sich per Unicast an den IPTV Servern (xxx.iptv.t-online.de) der Telekom an. Von diesen Servern erhält das Gerät auch eine Liste mit Multicast-Adressen der einzelnen Kanäle. Schaltet man nun auf einen dieser Kanäle, meldet sich der Receiver per IGMP am DSL-Router für die Multicast-Adresse des Kanals an. Der Router sendet ebenfalls eine Anfrage per IGMP über VLAN8 und tritt so der Gruppe bei. Der Datenstrom wird zum Router übertragen (UDP, Port 10000) und dieser leitet die Multicast-Pakete auf dem Ethernet-Port weiter, von dem die Adresse angefordert wurde.

Um keine Verzögerungen durch Multicast-Joins beim Umschalten zu verursachen, wird der Kanal für ca. 10 Sekunden per Unicast (UDP, Port 2297)übertragen.

Alle aktiven Inhalte, wie beispielweise der EPG werden ebenfalls über VLan 8 übertragen.

Hier einige Tests mit nslookup. Zwischen den tests lagen ca. 5 Minuten.
1. Versuch mit resolv-F (gescheitert)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an resolv-F.DTAG.DE

2. Versuch mit resolv-F (gescheitert)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an resolv-F.DTAG.DE

3. Versuch mit resolv-L (gescheitert)

> firestats.anb-networkz.net
Server: resolv-L.DTAG.DE
Address: 194.25.0.52
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an resolv-L.DTAG.DE

4. Versuch mit resolv-L (erfolgreich)

> firestats.anb-networkz.net
Server: resolv-L.DTAG.DE
Address: 194.25.0.52
Nicht autorisierte Antwort:
Name: firestats.anb-networkz.net
Address: 85.13.134.22

5. Versuch mit resolv-F (gescheitert)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
*** firestats.anb-networkz.net wurde von resolv-F.DTAG.DE nicht gefunden: Server
failed

6. Versuch erneut mit resolv-F (erfolgreich)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
Nicht autorisierte Antwort:
Name: firestats.anb-networkz.net
Address: 85.13.134.22

Wenn ein Nameserver eine Anfrage erst nach 3 Versuchen und 15 Minuten beantworten kann, liegt definitiv ein Problem vor. Bleibt abzuwarten ob wir jemals die Ursachen erfahren.

Folge man nun dem Link zur Überprüfung des Filters oder auch “Diagnoseseite zum sicheren Durchsuchen von Google”, verabschiedet sich der Safebrowsing Dienst komplett mit einem “Internal Server Error”.

Mal sehen wann es wieder funktioniert. Aber etwas peinlich finde ich die ganze Sache schon. Gerade bei einem Giganten wie google.

In einer Domänenstruktur oder einem Forrest, beziehen die PDC-Emulatoren der einzelnen Domänen die Uhrzeit vom PDC-Emulator der ersten, übergeordneten Domäne. Normalerweise ist das die Domäne, die auch den Server der die Funktion des Domain Naming Masters enthält.

Möchte man einen DCF Empfänger verwenden, muss per regedit im Schlüssel “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config” der DWORD-Wert “AnnounceFlags” auf “A” gesetzt werden. Bei verwendung eines NTP-Servers, welcher natürlich auch auf einem Netzwerkfähigem DCF Empfänger oder einem Linux-Server laufen kann, muss der NTP-Server in der Registry wie folgt konfiguriert werden:

1. Schlüssel “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters” Attribut “Type” auf den Wert “NTP” ändern
2. Schlüssel “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config” Attribut “AnnounceFlags” auf den Wert “5″ ändern
3. Schlüssel “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters” Attribut “NtpServer” auf den DNS-Namen des NTP-Servers plus 0×1 ändern. (Der Wert für den Server ptbtime1.ptb.de währe also “ptbtime1.ptb.de,0×1″
4. Schlüssel “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer” Attribut “enabled” auf den Wert “1″ ändern
5. Schlüssel “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient” Attribut “SpecialPollInterval” auf den Dezimalwert “1800″ ändern.

Diese Konfiguration sorgt dafür, das der Server den NTP-Server aktiviert, dem NTP-Client den angegebenen Zeitserver als Quelle übergibt und alle 30 Minuten mit dem externem Zeitserver Synchronisiert. Anschließend können alle weiteren Server und Clients Netzwerk die Uhrzeit von diesem PDC synchronisieren. Da wir zudem den NTP-Server auf diesem Server aktiviert haben, kann dieser als Zeitquelle für Drucker oder andere Geräte angegeben werden. Ist dies nicht erforderlich, kann Schritt 4 entfallen.

Ich bin der Meinung, ein solches Netzwerk lässt sich heute relativ einfach umsetzen. Alles zusammen, leben 2.0. Allerdings sollte man sich für den Fall eines Stromausfalls ein paar Kerzen und ein gutes Buch, zb über Multimedianetzwerke, bereitlegen.

Viele reden über IPSec ohne genau zu Wissen wie es eigentlich funktioniert. Im Grunde genommen ist es eine symetrische Verschlüsselung, die asymetrische Schlüssel zum austausch des eigentlichen, symetrischen Schlüssels für die Daten verwendet. Dieser Austauschvorgang wird IKE genannt und arbeitet mit dem ISAKMP Protokoll. Anschließend wird mit diesem Schlüssel die eigentliche Datenverschlüsselung oder Signierung durchgeführt. Das ganze funktioniert so:

• Einmalige Ausstellung eines Zertifikates durch die PKI

1. Erstellen eines geheimen Schlüssels in einer sicheren Umgebung. Bei einer sauber implementierten PKI sollte der geheime Schlüssen den Speicher des Gerätes, auf dem er erstellt wurde, nie verlassen. Beispiele hierfür sind zb. eine SmartCard oder ein TPM.
2. Anschließend wird aus dem geheimen Schlüssel ein öffentlicher Schlüssel errechnet. Aus diesem kann der geheime Schlüssel nicht mehr zurückgerechnet werden (Stand der Technik 2008, Schlüssellänge mind. 2048Bit)
3. Damit dem Inhaber des geheimen Schlüssels vertraut werden kann, wird der öffentliche Schlüssel zusammen mit Daten zum Inhaber an eine Zertifizierungsstelle gesendet. Diese signiert den Schlüssel mit ihrem geheimen Schlüssel. Eine Prüfung der Signatur ist mit dem öffentlichen Schlüssel der Zertifizierungsstelle jederzeit möglich. Dieser ist übrigens im CA-Zertifikat enthalten.
4. Ein von der CA signierter Schlüssel wird meistens in Form eines Zertifikats ausgestellt und an den Antragsteller zurückgesandt. Dieser verfügt nun über seinen privaten Schlüssen und eine Signatur (Zertifikat), die bestätigt das die person die ist, für die sie sich ausgibt.

• Der eigentliche Schlüsseltausch (Verbindungsinitialisierung)

1. Während des Schlüsseltausches verschlüsselt der Client alle Informationen mit dem öffentlichen Schlüssel des IPSec-Servers. Zusätzlich Authentifiziert er sich mit seinem öffentlichem Schlüssel und signiert die Daten mit seinem privatem Schlüssel. Da den privaten Schlüssel nur der Antragsteller des Zertifikates besitzt, ist die Idendität somit bestätigt.
2. Der IPSec-Server entschlüsselt die Daten mit seinem privatem Schlüssel. Zusätzlich prüft er bei der CA, ob das Zertifikat, mit welchem die Daten signiert wurden, gültig ist. Dies geschiet durch abfrage der Zertifikatssperrliste. Ist die Signatur der CA gültig und das Zertifikat weder abgelaufen noch gesperrt, ist der Client erfolgreich authentifiziert.
3. Über diese initiale Verbindung generieren beide Partnr bestimmte zufallszahlen und errechnen nach einem bestimmtem Schema einen gemeinsamen Schlüssel (SA). Für dieses Verfahren wird meistens nach dem Diffie-Hellman (DH) prinzip durchgeführt. Zusätzlich einigen sich beide Partner, welcher Algorithmus und welche Prüfsummenmethode (MD5, SHA1), für die Datenpakete der eigentlichen Übertragung verwendet werden sollen.

• IPSec Modus Authentication Header Modus (AH)

In diesem Modus werden die Datenpakete nur signiert und nicht verschlüsselt. Dies schützt die Daten gegen veränderung während der Übertragung oder Relay Angriffe (Sniffen und erneutes Aussenden der Pakete). Zur Signierung wird der vorher ausgehandelte Schlüssel der private Schlüssel des Clients direkt verwendet. Die so signierten Daten werden über das IP-Prokokoll Nummer 51 versendet.

• IPSec Encapsulating Security Payload Modus (ESP)

In desem Modus werden die Daten verschlüsselt. Dazu gibt es 2 Verfahren:

1. Im Tunnel-Modus werden die Daten inklusive IP-Header verschlüsselt und mit einem neuem IP-Header versehen. Dieser Modus eignet sich für Site-to-Site (Verbindung zweier Standorte) Verbindungen.
2. Im Transport-Modus werden die Daten des verwendeten Transportprotolls (TCP, UDP) verschlüsselt.

Die eigentliche Verschlüsselung erfolgt mit dem vorher über IKE ausgehandeltem Privatem Schlüssel und Protokoll. Die daten werden bei ESP über das IP-Protokoll nummer 50 übertragen.

Ich hoffe mit diesem Beitrag IPSec einfach erklärt zu haben. Auf tiefere Details, wie die verschiedenen Authentifizierungsmethoden, DH-Gruppen oder Algorithmen werde ich hier nicht eingehen. Fragen, Anregungen und Kritik bin ich jederzeit offen. Dafür gibt es ja die Komentarfunktion .

Weitere Informationen:

http://www.google.de/search?q=ipsec+funktionsweise

http://de.wikipedia.org/wiki/IPsec

Problembeschreibung:
Das Problem wurde wie folgt nachgestellt:
Windows Server 2003R2 wurde auf einem DL360G4P neu installiert, anschließend das aktuelle ProLiant SupportPack im ExpressModus installiert. Nach dem anschließendem Neustart wurde Teaming für die beiden OnBoard NICs im 802.3ad Modus aktiviert, eine statische IP konfiguration erstellt und das System mit dem Netzwerk verbunden. Anschließend wurde die Netzwerkkonfiguration sowie die LACP aushandlung erfolgreich geprüft und Windows aktiviert. Nun wurden die aktuellen Hotfixes über WindowsUpdate eingespielt. Nach dem Neustart tritt das Problem auf. In den Reiter “Status” des “HP Network team” Interfaces ist keine IP-Konfiguration vorhanden (IP: 0.0.0.0) und das System versucht über DHCP eine Konfiguration zu erhalten. Wenn man allerdings Eingenschaften von TCP/IP aufruft um eine statische Konfiguration zu hinterlegen, ist diese noch vorhanden. Der Befehl ipconfig /all zeigt das selbe Ergebnis. Löst man das NetzworkTeam auf und konfiguriert eines der Interfaces statisch, wird die Konfiguration übernommen.

Ursache:
Nach der Installation des Hotfixes KB941644 werden komponenten der TCP/IP Protokolltreiber ausgetausch. Diese neuere Version funktioniert warscheinlich nicht richtig mit dem HP NicTeaming Treiber und verursacht das Problem.

Auswirkungen:
Der Server ist nicht mehr über seine statische IP erreichbar. Es scheint als ob das Interface auf DHCP konfiguriert wurde und keine IP erhält. Selbst wenn ein DHCP-Server im Netzsegment vorhanden ist, bekommt das Interface keine IP. Auch die LACP Aushandlung am Switch schlägt nach einspielen des Patches fehl.

Umgebung:
Windows Server 2003R2 ServicePack 2 inkl. aller Hotfixes bis 01.01.2008 sowie aller zusätzlichen Updates (IE7, XML Services usw.). Die aktuelle Version des ProLiant SupportPacks ist installiert. Eine neuere Version des Netzwerktreibers ist nicht verfügbar.

Lösung:
Nach der Deinstallation des HotFixes KB941644 ist das Problem vorerst behoben wurden. Allerdings ist die Sicherheitsanfälligkeit die mit diesem Hotfix behoben wurde wieder vorhanden. Der Workarround des Bulletins funktioniert und schließt die Lücke ohne die Konfiguration des Interfaces zu beschädigen.

Bulletin: Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution (941644)