Zum Gehäuse:
Das sehr gut gelungene massive Gehäuse ist sehr schnell zu öffnen. Die 4 HDD Einschübe befinden sich hinter einer abschließbaren Fronttür, das passende Werkzeug zum Einbau der Festplatten in die Rahmen fehlt leider genau wie die nötigen Schrauben zum befestigen der Festplatten. Standard Sekkopf-Kreuzschlitzschrauben für Festplatten passen glücklicherweise in die vorgesehenen Bohrungen. Um den Speicher zu erweitern muss das Mainboard aus dem Gehäuse herausgenommen werden. Das unter den Festplatteneinschüben liegende Board befindet sich auf einem Schlitten. Zum Herausziehen sind lediglich 2 Schrauben und einige Stecker zu lösen. Nicht gerade der Komfort eines DL380, aber bei diesen Gehäuseabmessungen immer noch relativ komfortabel gelöst. Das System kommt ohne optisches Laufwerk. Über den Festplatten und der Frontklappe befindet sich ein 5 1/4″ Laufwerksschacht mit vorbereiteter S-ATA Verkabelung.Ein Band oder optisches Laufwerk ist hier durch öffnen der oberen Abdeckung schnell eingebaut. Um unerwünschtes Öffnen dieser Abdeckung zu verhindern, kann ein Schloss an der Rückseite angebracht werden. Ausgestattet mit 2x 2TB Enterprise HDD´s wiegt der Server ohne optisches Laufwerk knapp 5 Kg.

Leistung unter Windows Server 2008R2
Direkt nach der Installation können alle Komponenten mit Standardtreibern angesprochen werden. Es empfiehlt sich aber unbedingt den Grafik-/ Netzwerk-karten Treiber zu installieren. Um Datenredundanz zu schaffen sollte auf Windows Bordmittel zurückgegriffen werden. Der interne Controller realisiert das RAID auch nur über die CPU, allerdings ohne Wissen des Betriebssystems. Bei solchen “Soft-RAID” Treibern sollte immer auf die Betriebssystem Funktionen zurückgegriffen werden. Nach Abschluss der Erstsynchronisierung schreibt das System durchschnittlich 80MB/s auf die Datenträger. Das integrierte Gigabit LAN kann damit zwar nicht gesättigt aber immerhin sehr gut Ausgelastet werden.

Serverrollen/Konfiguration
Um einen Server an einem unsicherem Standort aufzustellen, sollte in jedem Fall ein getrenntes Subnet der Größe /24 oder /25 in einer neuen ActiveDirectory Site angelegt werden. Alle Kommunikation von und zu diesem Standort sollten dann IPSec verschlüsselt werden. Um den Standort an den Firmensitz anzubinden, empfiehlt sich ein getrennter L2 VPN-Router. Damit wird eine 2-Faktor Verbindungsverschlüsselung erreicht. Über diese Verbindung dürfen dann ausschließlich IKE und ESP Pakete der IPSec Verbindungen zugelassen werden. Um die Inhalte der Festplatten zu schützen sollte unbedingt EFS aktiviert werden. Somit sind alle nicht Domänenmitglieder aus dem Netzwerk und dem Dateizugriff ausgeschlossen. Der Server selbst wird als RODC konfiguriert. Ein lokaler DNS Server sowie globaler Katalog stellen die Anmeldefunktionen bei fehlender Netzwerkverbindung sicher. Allerdings sollten auf gar keinen Fall Kennwörter Administrativer Konten an den Standort repliziert werden. Eine Anmeldung am Server mit Administrativen Rechten ist so nur möglich wenn die IPSec Verbindung zum Hauptsitz steht. Um Druckfunktionen zur Verfügung zu stellen, empfiehlt sich zusätzlich die Rolle “Druck und Dokumentendienste”. Auch die Rolle “DHCP-Server” ist nützlich. Zum sichern und abgleichen der Daten kann eine DFS-Replikationsgruppe eingerichtet werden. Somit sind immer alle Daten an mindestens 2 Standorten verfügbar.

Fazit:
Der kleine Server bietet neue Möglichkeiten um kleine Firmenstandorte, Baustellen oder ähnliches mit Servern auszustatten. In Verbindung mit einem L2 VPN-Router (z.B. Cisco oder Astaro) lässt sich der komplette Netzwerkverkehr so absichern, dass selbst ein Sniffer an einem Monitor-Port kein Risiko darstellt. Dank RODC und EFS sind auch die Daten und Benutzerkonten relativ sicher. Der Nutzen eines solchen Servers übersteigt auf jeden Fall das Restrisiko. Alternativ müssten alle Anwender ihre Daten lokal verwalten, fällt eine Festplatte aus ist alles weg. Truecrypt usw. bringen auch nicht viel wenn die Daten per SMB Freigabe zwischen den Systemen kopiert werden. Dank des Server kann die Kommunikation mit IPSec und Kerberos abgesichert werden und Mitarbeitern an Remote Standorten eine sichere Zusammenarbeit im Netzwerk ermöglicht werden.

Mehr zum Server auf der HP Produktwebsite.

Apropos Netzwerk, die Netzwerk-Hardware wird von einer regionalen Firma, der EPC Engineering Consulting GmbH gestellt. Ich selbst werde das Netzwerkteam mit Tipps und Hinweisen zur Konfiguration unterstützen und zur Veranstaltung einige Fotos knipsen.

Es gibt noch viele Plätze, doch wer sicher am Getümmel teilhaben möchte, sollte sich bereits vorab registrieren. Es gibt übrigens auch ein Gamer-Taxi, das euch nach Absprache kostengünstig zur Veranstaltung bringt.

Wer einen PC hat und gelegentlich oder öfter gern Spielt sollte sich das nicht entgehen lassen. Weitere Informationen zur Cyber-Night findet ihr auf der offiziellen Website.

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