Hallo, Fabian hier. Der zweite Tag war recht vollgepackt mit Vorträgen, alle Sessions waren sehr interessant.

How Windows Storage Is Changing: Everything's Going VHD!

Sprecher war Mark Minasi: http://www.minasi.com/

Um es Vorweg zu sagen: Mark Minasi ist der aus meiner Perspektive bisher beste Sprecher auf der TechEd dieses Jahr. Das heißt nicht, daß die anderen Speaker nicht auch super waren / sind; aber wer einmal das Glück hat in einen Vortrag / ein Training von ihm zu kommen, sollte das wahrnehmen. Fachlich absolut sattelfest und vom Vortragsstil her genial und witzig. Es mangelt weder an Rollenspielen (etwa Router vs. Client) noch an vollem Körpereinsatz. ;-)

Die gute Performance von ihm hat mich dann am Dienstag dazu bewogen, zwei weitere Sessions von ihm anzuschauen (siehe unten), obwohl ich eigentlich andere Vorträge besuchen wollte.

PB100013[1]

Im Zentrum der Session standen die Änderungen bei “Windows Speichern” seit Vista, insbesondere jedoch Windows 7. Seit Vista wurde der Bootmanager (Stichwort boot.ini) durch die “Boot Configuration Database (BCD)” abgelöst, die mittels BCDEDIT bearbeitet werden kann. Nähere Informationen dazu finden sich etwa hier (kostenfreier Download): click here to download chapter 1

Seit Windows 7 liegt die Datenbank auf einer separaten (standardmäßig) 100MB großen Partition und nicht mehr auf “C:”. Auf diesem Volume können nun auch Bitlocker Daten oder etwa Recovery Environment Daten abgelegt werden, das 1,5GB Volume ist für Bitlocker seit Windows 7 also nicht mehr notwendig. Das Volume ohne Laufwerkszuordnung ist dementsprechend ein “Multitalent”. Durch diese Trennung der Datenbank vom System ist nun theoretisch auch der Bootvorgang direkt von einer VHD möglich, was jedoch derzeit nicht supported ist. Hier gab es aber eine ausführliche DEMO, wie man eine VHD a) als zusätzlichen Datenträger einbinden kann (Multiboot-Environment) oder b) auch als primäres Boot-Device einrichten kann (derzeit nicht supported, siehe oben). Hierzu muß zur Einrichtung DISKPART verwendet werden.

Möchte man ein OS in eine neu erstellte VHD übertragen, so kann dafür etwa “ImageX” der Winndows Deployment Tools genutzt werden, wenn man zuvor das System mittels SYSPREP vorbereitet hat. Die Vorgang der Übertragung in eine VHD ist eigentlich erst seit Windows 7 vorgesehen, unter Vista sollte es jedoch auch funktionieren. Testen macht schlau. ;-)

Das Windows Complete Backup erzeugt ebenfalls VHDs, die jedoch nicht dafür gedacht sind, sie in eine VM einzubinden – eher dient die VHD als Containerformat. Mit dem Complete Backup Fetaure ist sogar ein “Bare Metal Restore” möglich, wenn etwa auf der Kommandozeile mittels “wbadmin” die Option “-allcritical” verwendet wird.

Stichwort “Containerformat”: Die VHDs lassen sich nicht nur als HDD-Container nutzen, sondern können auch zur Datenübertragung genutzt werden. Im Gegensatz zu ISOs oder ZIP-Dateien werden darin natürlich auch die NTFS-ACLs übertragen, so daß man theoretisch diese ACLs auf dem Zielsystem nutzen kann und diese beim “Transport” nicht verloren gehen. Das Einbinden der VHD ist seit Windows 7 so einfach wie irgend möglich (über die Datenträgerverwaltung beispielsweise), so daß das Vorgehen kein Problem mehr darstellen sollte.

Wen das Thema insgesamt interessiert, der schaut einfach direkt bei Mark Minasi vorbei, dort stehen einige Newsletter zu den Themen bereit, etwa: http://www.minasi.com/newsletters/nws0701.htm und http://www.minasi.com/newsletters/nws0702.htm .

Windows BitLocker in the Enterprise

Speaker: Paul Cooke

PB100017[1] PB100019[1]

Diese Bitlocker Session war sehr interessant, technisch als auch von den Überlegungen zum Deployment. Auch wurde mit Themen aufgeräumt wie: Bitlocker ist nicht so sicher wie Produkt XY, weil a) als Boot-Loader ein unverschlüsselter Bereich vorliegt (das ist nämlich zwangsweise bei jedem Produkt so, nur verstecken es andere Anbieter vor neugierigen Blicken) und b) im Schlafmodus oder Hybernate der Bitlocker Schlüssel im Speicher bleibt – Bitlocker ist nicht designed, Schutz in einer solchen Konstellation zu liefern, es stehen andere Szenarien im Vordergrund. Wer das verhindern möchte, deaktiviert im Notfall den Schlafmodus seiner Geräte.

Die Bitlocker Daten werden (siehe letzte Session oben) seit Windows 7 in einer 100MB Partition untergebracht – dies sollte beim Deployment bedacht werden – denn nur bei “from scratch” Installationen wird die Partition automatisch eingerichtet. Nutzt man etwa WDS zur Verteilung von Windows 7, muß man die Partitionierung selbst vornehmen. Macht man es nicht, kann es beim Ausrollen von Bitlocker im Unternehmen diverse Probleme geben oder mindestens die Benutzer zu mehrmaligen Neustarts des Rechners nötigen – nicht gut für die IT-Akzeptanz im Unternehmen.

Seit Windows 7 gibt es nun ähnlich wie bei EFS einen “Data Recovery Agent”, den man optional einrichten kann. So müssen nicht mehr alle Recovery Schlüssel in das AD-Computerobjekt geschrieben werden (und sind auch nicht verloren, wenn man das Computerkonto einmal löscht), sondern man kann mit dem privaten Schlüssel wieder an “verlorene” Daten herankommen.

Bitlocker to go macht es möglich, auch USB-Sticks und ähnliche Wechseldatenträger zu verschlüsseln. Diese können dann unter Windows 7 oder mit einem “builtin” Tool “read only” von XP und Vista gelesen werden. Für letzteres ist eine FAT Formatierung des Datenträgers notwendig. Man kann per Gruppenrichtlinie erzwingen, daß keine Daten auf unverschlüsselte Datenträger übertragen werden und es kann verhindert werden, daß Daten auf Datenträger fremder Organisationen kopiert werden.

Best Practice Empfehlungen für Bitlocker:

  • Einsatz standardisierter Hardware (etwa TPM Chip vorhanden u.ä.)
  • Pre-Build Hardware Konfiguration (HDD Partitionierung, BIOS Einstellungen und Kennwort, TPM aktiviert, etc.), also im Prinzip eigene OEM Systeme
  • Rollout der Systeme, bevor die Benutzer damit in Berührung kommen, so daß ggf. maximal nur ein Reboot bei Bitlocker Einrichtung notwendig wird und nicht 4 oder 5.
  • getestete (!) Recovery Strategie (!)
  • Die meisten GPO-Einstellungen müssen vor der Aktivierung von Bitlocker aktiv sein, so zum Beispiel Verschlüsselungsalgorithmus u.v.m.

Seit Schema Version 2008 bzw. später (2008 R2) sind alle Attribute / Schema Änderungen mit dabei – somit entfällt ein Schema-Upgrade bzw. eine Änderung für Bitlocker, die noch unter Windows Server 2003 SP1 notwendig war. Zusätzlich unterstützt nun Windows PE (auf W7 Basis) und das Recovery Environment auch nativ Bitlocker.

Die Windows 7 integrierte “BDE.exe” ermöglicht es viele Schritte des Rollouts zu automatisieren, ansonsten gibt es ein Beispielscript namens “Manage-BDE.wsf”. SCCM 2007 ist übrigens ebenfalls “Bitlocker aware”.

IPv6 for the Reluctant: What to Know Before You Turn It Off

Dies war eine der Session, die ich “nur” wegen dem Sprecher Mark Minasi besucht habe. Da die Session streckenweise sehr spezifische IPv6 Themen behandelt hat, ist eine Zusammenfassung recht schwierig. Wen das Thema IPv6 interessiert (und die Quintessenz des Beitrags war: Es sollte jeden “interessieren”), der findet im Netz dazu als auch in diversen Büchern wertvolle Informationen zum Einstieg.

PB100021[1]

Nach einem kurzen Ausflug in die Geschichte war klar: 1994 hatte sich kaum jemand über den verfügbaren Adressraum von IPv4 Gedanken gemacht. Doch dann brach das Internet über die Massen an Benutzern herein, so daß schon 1995 der Adressraum knapp wurde. Da aus diversen Gründen nicht so schnell auf IPv6 umgestellt werden konnte, wurde die “Krücke” Network Address Translation (NAT) per RFC definiert – eine Technik, die so manchem Netzwerkadmin heute die Tränen in die Augen treibt.

Mark Minasi stellte die Vermutung auf, daß so ein “Knall” wieder bevorsteht und dann in kürzester Zeit auf IPv6 umgestellt werden muß und wird. Den Zeitrahmen dafür vermutet er bis 2011 / 2012, was durch folgende Webseite auch eindrucksvoll hochgerechnet wird: http://www.potaroo.net/tools/ipv4/index.html

Sein Fazit: Sichert Eure Jobs, indem Ihr den Migrationsplan in der Tasche habt bzw. die Planung langfristig angeht…

China wurde außerdem als Beispiel genannt, da hier das Chinese “New Generation Network (NGN)” direkt auf IPv6 laufen wird. Nicht ohne Grund, wenn man sich den (nachvollziehbar) wachsenden Adressbedarf in China anschaut. Auch europäische Autobauer (und sicher auch die Autobauer anderer Länder, wie z.B. Japan) setzen zunehmend auf IPv6 für die internen Netzwerke in den Autos – ein prominentes Beispiel, warum diese Anforderung existiert, ist die kabellose car-to-car  bzw. car-to-x communication, bei dem sich beispielsweise gegenseitig über Staus und Gefahrenstellen informiert wird. Hier ist der Einsatz von IPv6 sinnvoll (wenn nicht zwingend notwendig, sollte das Internet Protocol “IP” verwendet werden).

Seit Windows Vista ist nun der TCP/IP Stack komplett auf IPv6 umgestellt – selbst wenn man das Protokoll “deaktiviert”, wird intern immer noch die Umsetzung stattfinden. Dies ist eine fundamentale Änderung.

Dann ging es direkt zum technischen Teil über: Die Vorteile von IPv6 wurden zusammengefasst, etwa daß keine Broadcasts mehr eingesetzt werden (wohl aber Multicasts), das Routing unproblematischer werden wird (kein NAT mehr notwendig), theoretisch kein DHCP mehr notwendig sein wird (mehr dazu weiter unten) usw.

Nachdem dann noch ein wenig IPv6 Theorie besprochen wurde (ganz grob zusammengefaßt):

  • was ist unter “link” zu verstehen; im Prinzip ein Subnetz in IPv4
  • wie sehen IPv6 Adressen aus; also 8x hex quads (8x hexadezimale Vierergruppen, die durch Doppelpunkte getrennt sind)
  • wie kann man die Schreibweise von IPv6 Adressen verkürzen, indem man aufeinander folgende “Nullen” verkürzt: 21FB:540A:0000:0000:0000:0000:0000:0000 wird zu 21FB:540A::
  • “Subnetze” werden nicht mehr in der Schreibweise 255.0.0.0 eingesetzt, sondern über “Prefixe” abgebildet; zum Beispiel 21FB:540A:0000::/48 bedeutet, daß die ersten 48-Bit den “Netzwerkanteil” ausmachen, jedes Zeichen hat 4 Bit (0-15 dezimal, also 0-F hexadezimal), daher gibt es 48/4 = 12 Zeichen, wobei die 4 Nullen im Beispiel natürlich auch gekürzt werden könnten und nur zur besseren Verständlichkeit stehen blieben
  • FE80::/64 Adressen sind im Prinzip gleich den IPv4 APIPA Adressen
  • was sind Unicast, Multicast und Anycast Adressen usw.

kam man schnell zu dem Punkt zu verstehen, daß das “Wegwerfen” und “Verschwenden” von ungenutzten IP-Adressen unter IPv6 “by design” ist und mit dem aktuellen maximal möglichen Adressraum überhaupt kein Problem darstellt. Dabei werden mehrere IP-Adressen pro Interface betrieben – ganz normal und nicht so “ungewöhnlich” / problembehaftet wie bei IPv4.

Zusätzlich gab es auch einen Ausflug zum Thema Datenschutz: In den ersten Entwürfen der IPv6 Implementierung wurde der Host-Anteil (besser: 32-Bit davon) aus der MAC-Adresse der NIC gebildet und der Rest “aufgefüllt” – wenn jedoch die Adresse im Internet (ohne NAT) geroutet wird, wäre dies ein eindeutiger Bezeichner und ein Tracking von Clients wäre möglich geworden. Keine schöne Vorstellung. Daher wurde dieser RFC-Standard geändert / verworfen und der Host-Anteil (bzw. die Global Unicast Adresse des Interfaces) zufällig gebildet. Bei der Gelegenheit wurde auch eingeworfen, daß die 32-Bit MAC sowieso nicht ausgereicht hätte (für den zu füllenden 64-Bit Anteil der IPv6-Adresse) und daher so oder so auf MAC-64-Bit umgestellt werden soll. Derzeit geschätzt reichen diese eindeutigen 32-Bit Adressen geschätzt nämlich “nur noch” bis ins Jahr 2100…

Wie angesprochen ändert sich die Rolle von DHCP ein wenig, denn rein theoretisch reichen die automatisch bezogenen IPv6-Adressen der Clients link-local als auch site-local bzw. global aus. Doch DHCP hat natürlich trotzdem seine Daseinsberechtigung, denn neben “festen” (also an bestimmte Systeme gebundenen) IP-Adressen können darüber ja auch andere Informationen verteilt werden, so etwa DNS-Suffixe, Router-Informationen etc.

NetBIOS bzw. WINS existiert in der Form unter IPv6 nicht mehr und DNS-Einträge für IPv6 Adressen werden als Quad-A Records “AAAA” registriert. Teredo (6to4) paßte nicht mehr ins Programm, da es ein “abendfüllendes” Thema wäre.

Yes SIR! Understanding the Microsoft Security Intelligence Report (SIR) v7

Als nächstes landete ich im Vortrag von Vinny Gullotto zum Security Intelligence Report (SIR), der sich als interessanter herausstellte, als mich der Titel zuerst vermuten ließ. Der Report ist sehr umfangreich, daher konnten in der Session nur einige Kernpunkte angesprochen werden.

PB100022[1]

Was mich stark beeindruckte war, wie viele Daten anonymisiert akkumuliert werden, um Trends und Statistiken zu erarbeiten. An vielen Stellen unserer Produkte macht eine solche Auswertung auf Malware / Attacken etc. Sinn, denn so lassen sich recht früh Ausbrüche neuartiger Schädlinge feststellen und bekämpfen. Außerdem erleichtert es (neben dem Engineering) die Heuristik natürlich ungemein, wenn man einen Pool von Daten hat, wie sich ein Schädling verhalten kann. Daten, die zur Auswertung herangezogen werden, sind zum Beispiel

  • direkte Meldungen durch Kunden
  • Analyse der in Hotmail gefilterten Malware
  • Live One Care
  • Forefront Client Security
  • Windows Defender
  • IE Phishing Filter
  • MSRT
  • Bing (Analyse von Schädlingen, die über Webseiten verbreitet werden)
  • Zusammenarbeit mit anderen Anti-Malware Software Herstellern

Wenn man diese Daten von meheren Millionen Systemen weltweit zusammenfaßt wird schnell klar, welches mächtige Werkzeug zur Malware-Bekämpfung man damit an der Hand hat.

Um gleich Verschwörungstheorien entgegenzuwirken: Die Auswertung der Daten erfolgt erstens Anonym, zweitens müssen unsere Kunden der Auswertung zustimmen, d.h. die Datenübertragung findet nicht automatisch statt.

In Enterprise Umgebungen finden sich laut Report eher Würmer, auf Privatrechnern eher Trojaner. Hier zeigt sich also, wie zielgenau die Schadsoftware verbreitet wird, um maximale “Erfolge” zu erzielen. So werden privat natürlich eher Bankdaten etc. abgezogen, während in Unternehmen schlichtweg “Rechenkapazitäten” und Bandbreite für Massenversendungen von SPAM etc. zur Verfügung steht.

Leider ist einmal mehr der Mensch selbst in vielerlei Hinsicht ein entscheidender Faktor für den Erfolg von Malware: So ist das Bewußtsein für das massive Vorhandensein von Malware noch immer sehr gering (stündlich werden 15 neue Viren, Würmer, Trojaner etc. inkl. neuer Varianten entdeckt), außerdem finden leider Updates viel zu selten statt. Hier spielt nicht nur die Microsoft Update Seite eine große Rolle, vielmehr müssen alle Applikationen auf den Systemen aktuell gehalten werden. Und genau das passiert in den seltensten Fällen ausreichend – die Verteilung von ausgenutzten Browser-basierten Schwachstellen auf Microsoft Produkte und Third-Party Software in Windows XP und insbesondere Vista veranschaulicht dies in beeindruckender Art und Weise (man beachte dabei auch den Unterschied zwischen XP und Vista):

ITS206_Gullotto[1]

Wenn dann auch noch Security Hotfixes über Jahre zur Verfügung stehen und trotzdem noch ausgenutzt werden (weil nicht installiert), muß einen das bedenklich stimmen. Ein gutes Beispiel war “Conficker”, der eine Lücke nutzte, gegen die der entsprechende Hotfix vor Erscheinen des Wurmes schon 3 Monate (!) zur Verfügung stand…

Im Vortrag wurde daher mehr als einmal der Kernsatz der Session ausgesprochen: Update, update, update! Und das gilt explizit eben nicht nur für Microsoft Produkte.

Ein Blick in den Report lohnt sich auf alle Fälle, wenn man neben den angesprochenen Themen auch einmal sehen möchte, wie Malware länderspezifisch aufzuschlüsseln ist o.ä.: http://www.microsoft.com/sir

Cracking Open Kerberos: Understanding How Active Directory Knows Who You Are

Die letzte Session meines zweiten Tages gehörte dann wieder Mark Minasi.

PB100029[1]

Zu Beginn merkte Mark Minasi an, daß die Session Level 400 hat – und das stimmte auch. Daher auch hier wieder der Hinweis, daß nur Auszüge der geballten technischen Ladung wiedergegeben werden können.

Gleich zu Beginn unterschied er zwischen Authentifizierung und Autorisierung – was auch unserer Erfahrung nach allzu oft in Vergessenheit gerät. Kerberos stellt als zentraler Bestandteil der Active Directory die Authentifizierung bereit, nicht die Autorisierung. Es folgte die Erklärung von User Principal Names (UPN) und Service Principal Names (SPN). Kerberos sorgt (ein wenig verallgemeinert) dafür, daß ein Service Ticket für einen konkreten Service auf einem Server (SPN) an einen Benutzer (UPN) ausgestellt wird. Hierbei spielen der Authentication Service (AS) und Ticket Granting Service (TGS) die entscheidende Rolle – beides realisiert durch das Key Distribution Center (KDC), also einem Domaincontroller, im Kontext des LSASS Prozesses.

Es gibt zwei Sorten von Tickets: Ein Ticket Granting Ticket (TGT) und ein Service Ticket (ST). Um in den Genuß eines Service Tickets zu kommen, muß man ein entsprechendes TGT besitzen, welches zum Erhalt dieses ST “berechtigt”. Hier spielen dann Faktoren wie Computer und Benutzerkennwörter eine Rolle, die zum Verschlüsseln von “Secrets” (der aktuellen Systemzeit) genutzt werden, um den gegenüber auch korrekt zu identifizieren bzw. sicherzustellen, daß es wirklich der richtige Partner ist, der er vorgibt zu sein. An dieser Stelle kommt dann auch die “berühmte” 5 Minuten maximale Zeitdifferenz auf Kerberos Systemen ins Spiel, denn das ist standardmäßig die maximale Zeitdifferenz, die die verschlüsselte Systemzeit auf DC und Client haben darf. Hier gab es ausführliche Erläuterungen zur Funktionsweise.

Wer das ganze besser verstehen möchte, dem sei folgender Artikel ans Herz gelegt: http://technet.microsoft.com/en-us/library/bb742516.aspx

Diese Trennung von TGT und ST stellt sicher, daß das verschlüsselte Kennwort nur sehr selten (standardmäßig 10 Stunden) über die Leitung geht, da das TGT diese Zeit über gültig bleibt und nicht neu ausgestellt werden muß. Damit weist sich dann ein Benutzer beim DC aus, sobald er ein Service Ticket beantragt – und beweist damit, daß er schon korrekt authentifiziert wurde. Außerdem muß das Kennwort nicht an die Server gesendet werden, auf die zugegriffen wird (mittels Service Ticket). Der KDC / DC ist hier also unter anderem die zentrale Instanz einer AD-Umgebung, die Client und Server miteinander “verbindet”. Daher auch der Name “Kerberos”, der in der griechischen Mythologie ein dreiköpfiges Wesen ist.

An dieser Stelle gab es dann auch noch Hinweise zur Verschlüsselung von Kerberos Paketen, insbesondere zu den Änderungen in Windows Server 2008 und später.

In der verbleibenden Zeit wurde dann einges angesprochen, was beim Kerberos Troubleshooting von Bedeutung ist. Alle angesprochenen Punkte muß man an dieser Stelle gesondert hervorheben, denn die Punkte stellen einen Großteil der Themen dar, die wir hier mit unseren Kunden bei Kerberos Problemen verschiedener Art immer wieder behandeln.

Untersucht man Kerberos Probleme, macht ein Netzwerktrace immer Sinn. So kann man darin etwa nach Kerberos Fehlern suchen (NetMon Filter “KRBERROR”) oder auch komplette Kerberos Vorgänge zwischen Client, Zielserver und DC tracen. Hauptsächlich sind die folgenden Punkte dabei als Fehlerursache zu finden:

  • DNS
  • DNS
  • DNS
  • Time Service Probleme, also nicht übereinstimmende Zeiten auf Client und DC
  • 3 Tier Authentication Probleme – also etwa Client zu IIS zu SQL Server – hier muß nämlich eine Delegierung eingerichtet sein und die SPNs korrekt gesetzt sein
  • UDP Pakete kommen nicht an, läßt sich durch Aktivieren von Kerberos über TCP beheben, was seit Vista / 2008 auch Standardeinstellung ist

Der erste Blick bei Kerberos Problemen sollte neben Netzwerktraces immer auch ins Eventlog gehen – hier läßt sich das “Debug Level” auch hochdrehen – obwohl man dann natürlich genau wissen sollte, wonach man sucht… Zu diesem Thema gibt es auch ein Whitepaper von uns.

Es sollte zusätzlich sichergestellt sein, daß tatsächlich Kerberos genutzt wird und nicht NTLM – auch ein nicht zu unterschätzendes Problem bei fehlerhafter Konfiguration oder Umgebungen mit “Legacy Systemen”. Beispiele für mögliche Ursachen dafür sind:

  • NET USE auf IP-Adressen anstatt DNS-Servernamen
  • Workgroup Systeme, nicht eben nicht Teil der AD sind
  • Pre-Windows 2000 Systeme bzw. nicht Kerberos-fähige Third-Party Dienste
  • failover von ausgelasteten DCs
  • “schlecht programmierte” eigene Applikationen
  • die eigene Intranet Seite wurde nicht der “local intranet” Zone des Internet Explorers zugewiesen und per DNS-Namen auf den IIS zugegriffen
  • fehlende, doppelte oder fehlerhafte SPNs

Ab Windows Server 2008 R2 / Windows 7 kann man NTLM auch komplett blocken, was man jedoch immer erst im “Audit” Modus prüfen sollte!

Weitere Probleme sind etwa die MaxTokenSize, fehlerhaft konfigurierte constrained delegation oder die schon angesprochenen fehlerhaften SPNs. Hier kann das Script spn_query.vbs wertvolle Hinweise geben.

Die Managed Service Accounts ab Windows 7 / Windows Server 2008 R2 können hier Hilfestellung geben, da die SPNs etwa beim Umbenennen eines Servers automatisch angepaßt werden.

Alles in allem eine der “technischsten” Session des Tages, die mir persönlich sehr gut gefallen hat.

Viele Grüße
Fabian