Heute habe ich mich im Rahmen eines kleinen Mittagspausenexperiments mit Grub4Dos auseinandergesetzt. (Genauer gesagt mit dem erstellen eines Acronis Backup & Recovery USB-Sticks, aber darum geht es hier nur am Rande). Die Erfahrungen die ich prinzipiell mit Grub4Dos (wenn es auch bei weitem nicht viele sind) gesammelt habe sind allgemeingültig genug um sie auf viele andere Bereiche anzuwenden. Das Thema heute soll also das erstellen eines Bootbaren USB Sticks sein, der optimalerweise von NTFS startet und uns die Mühe erspart für jedes neue Linux Live System mit dem wir spielen wollen den ganzen Stick zu formatieren (also am besten, von ISO Booten kann) - und schon gehts los:

Was wir brauchen

• GrubInst
• Grub4Dos

Nach dem herunterladen dieser beiden Dateien entpacken wir sie in einen Ordner unserer Wahl. Im Ordner in den wird den Grub Installer entpackt haben starten wir die grubinst_gui.exe und wählen die folgenden Einstellungen aus:

• Unter Disk, wählen wir unseren USB Stick und erkennen ihn normalerweise an der Größe
• Unter Part List wählen wir "Whole Drive" - sollte hierbei ein Fehler erscheinen hatte ich erfolg damit, den USB Stick mit dem HP USB Disk Storage Format Tool zu formatieren.
• Bei Options wird "Don't search floppy angehakt"
• Dann ein Klick auf Install und eine Erfolgsmeldung sollte quittieren, dass der MBR korrekt geschrieben wurde.

Wir beenden mit Quit und wechseln in das Verzeichnis in welches wir das Grub4Dos Archiv entpackt haben. Aus diesem Verzeichnis kopieren wir die beiden Dateien "grldr" und "menu.lst". Diese legen wir ins Hauptverzeichnis unseres USB Sticks.
Wenn bis hierher alles glatt gegangen ist sind wir eigentlich bereit für einen kleinen Testlauf. Sinnvoller wird es allerdings, wenn wir zuerst die standardmäßige menu.lst anpassen und etwas verschlanken oder gar gleich um ein eigenes ISO erweitern. Meine Sieht Beispielsweise so aus:

timeout 10
default 0

title Acronis Backup & Recovery Advanced Workstation
map (hd0,0)/backuprecoveryadvws.iso (hd32)
map --hookchainloader (hd32)boot title XMBC (Test) map (hd0,0)/xbmc-10.1-live.iso (hd32)map --hookchainloader (hd32)boottitle CommandLinecommandline title Rebootreboot title Halt

Es gibt Phänomene, für die muss man erstmal eine Erklärung finden, wie dieses. Einer meiner Virtuellen Server, ein Webserver 2008 R2 wird eigentlich wie gewollt überwacht von einem OSSEC Agenten auf Integrität überwacht. Ein zentraler OSSEC Server wertet die Event und Anwendungslogfiles aus, und reagiert automatisch auf Angriffe. Naja, zumindest war genau dass, der Plan. Aber eine ganz allgemeine Gegenmaßnahme gegen Angreifer scheint auf diesem Host nicht wie gewollt zu funktionieren – das Null oder Blackhole Routing.

Also genaugenommen funktioniert es schon, etwa ein Paket lang dann fließen die Pakete auf einmal wieder über das Standard Gateway. Was ist passiert ? Null Routing war bei Windows im Gegensatz zu anderen Betriebssystemen nie wirklich direkt implementiert. Eigentlich musste man sich solange ich denken kann mit einem Umweg behelfen:

route -p add 10.0.0.2 MASK 255.255.255.255 10.99.99.254
             ^ IP die man blockieren will ^ Nicht existierende Adresse

Zusammen mit einem HIDS ist das keine schlechte Gegenmaßnahme. Allerdings ändert Windows auf magische Weise mithilfe der “dead gateway detection” die Metrik meiner künstlich angelegten Route auf

Metrik des Default Gateways + 1

sobald mein Rechner das erste Paket ins Nirvana bewegt. Also Zeit sich eine richtige Lösung zu überlegen und sich ein Wenig mit der Windows Firewall auseinanderzusetzen.

Vorbereitungen

Zuerst benötigen wir eine IP Security Policy, eine Filter Aktion und eine IP Filter Liste, diese legen wir mit den folgenden drei Befehlen an:

$ netsh ipsec static add policy name="KeineVerbindung" description="Zu diesen Hosts wird keine Verbindung aufgebaut"
$ netsh ipsec static add filteraction name="Block" description="Alles blockieren" action=block
$ netsh ipsec static add filterlist name="Angreifer" description="Diese Liste enthält Hosts die Bekannte Angreifer sind"

Verwenden

Wollen wir nun eine IP Blockieren ist es notwendig IP Filter hinzuzufügen und diese der IP Filterliste zuzuordnen:

$ netsh ipsec static add filter filterlist="Angreifer" srcaddr=10.0.0.2 dstaddr=any description="19.08.2011 - Versuchter Einbruch auf FTP Server"

Aktivieren

Nun müssen wir die Filteraktion noch der Filterliste zuweisen:

$ netsh ipsec static add rule policy="KeineVerbindung" filterlist="Angreifer" filteraction="Block" activate=yes

Zuguterletzt müssen wir nun noch den gesammelten Regelsatz zuweisen. An dieser Stelle solltet Ihr überprüfen, dass Ihr nicht einen falschen Host hinzugefügt habt!

Zuweisen des Regelsatzes:

netsh ipsec static set policy name="KeineVerbindung" assign=yes

Zur Dokumentation von Noras neuer Frisur, haben wir heute Abend vor dem Haus noch ein Foto geschossen. Die Rohfassung hat Nora für Ihr Facebook Profil verwendet. Die etwas aufgehellte Variante gebe ich hier zum besten.

Update

Ich konnte es nicht lassen ein wenig mit Schwarzweissfiltern herumzuexperimentieren. Das Ergebnis:

Am 1. Juni 2011 11:27 schrieb Josef <[email removed]>:

Hallo Florian,

die Zertifikate [Anm: auf unserem Exchange 2007 Server]müssen neu erstellt / verlängert werden. Was muss ich dafür tun?

Mit freundlichen Grüßen

Josef

Hallo Josef,

Exchange Zertifikate laufen nach einem Jahr ab mit dem neuen Small Business Server sollte der Schritt aber wegfallen (da die Zertifikate soweit möglich selbsttätig erneuert werden). Nun zu deinen Zertifikaten:

Der erste Schritt ist normalerweise die Erstellung einer Zertifizierungsanfrage (CSR), da Ihr aber wie ich denke in diesem Schritt kein richtiges Zertifikat (beispielsweise von Thawte oder Verisign) einsetzen möchtet können wir uns den Schritt sparen und erstellen gleich ein neues Zertifikat.

Dazu meldet sich ein Admin auf dem Exchange Server an und  startet dort die Exchange Management Shell:

New-ExchangeCertificate
   -SubjectName "c=ME, o=PACEY, cn=srv01.pacey.me"
   -IncludeAcceptedDomains
   -IncludeAutoDiscover
   -privatekeyexportable $true
   -domainName srv01, srv01.pacey.me
   -Services "SMTP, IMAP, POP, UM, IIS"

Unglaublich wichtig dabei ist, dass du den Subjectname anpasst und alle benötigten Domainnamen im -domainName Parameter einträgst. Dies müsstet Ihr mit dem Befehl (ebenfalls in der Management Shell) heraufinden können (um genau zu sein zeigt er die Informationen der bisherigen Zertifikate an):

Get-ExchangeCertificate | fl

Nachdem hoffentlich unser Zertifikat erfolgreich erzeugt wurde müssen wir es aktivieren, dazu müssen wir allerdings den Fingerabdruck des Zertifikats kennen (den kannst du ebenfalls mit dem vorigen Befehl herausfinden) :

Enable-ExchangeCertificate
 -Thumbprint 
 -Services SMTP,IMAP,POP,UM,IIS

Bei -Services sind resp. die Dienste einzutragen für die das neue Zertifikat verwendet werden soll. Ich hoffe ich habe alle erwischt die Ihr braucht. Damit sollte das neue Zertifikat für alle Dienste aktiv sein.

NOCHMAL: Alle Domainnamen inkl. Subdomains müssen im Zertifikat benannt werden für die das Zertifikat Gültigkeit besitzt ansonsten wird das Zertifikat weiterhin als ungültig abgewiesen.

Gruß Florian

Ich habe mir dieses Wochenende die Nächte um die Ohren geschlagen bei dem Versuch E-Mails und Benutzer aus einer bestehenden Microsoft Server 2003 (R2) Domäne (mit Exchange 2007 SP2) auf einen aktuellen Small Business Server 2011 zu migrieren. Besonders der Export der Mails erweist sich als unintuitiver als ich eigentlich von Microsoft gedacht hätte. Im folgenden nun meine aufgearbeiteten Notizen:

Grundlagen

Den einen oder anderen mag es wundern – für mich war es sehr verwunderlich, dass es so komplex ist E-Mails aus Exchange zu exportieren. In einigen Technet Artikeln habe ich die notwendigsten Grundinformationen gesammelt.

Hier meine grundlegenden Erkenntnisse:

• E-Mails können über die das PowerShell Cmdlet Export-Mailbox aus Exchange exportiert werden
• Der den Export ausführende Benutzer braucht Vollzugriff auf das Postfach.
• Export-Mailbox benötigt eine lokale Office Installation.

Vorbereitungen

Wenn ich so über meinen eigenen Ablauf nachdenke bin ich in so ziemlich jedes Fettnäpfchen getreten, dass der Export zu bieten hat. Ich erspare euch jeden meiner Fehler und weise einfach auf die Fallstricke hin. Aufgrund der ganzen Abhängigkeiten würde ich empfehlen eine eigene virtuelle Maschine dafür einzurichten.

Als Betriebssystem für den Rechner auf dem Exportiert wird empfehle ich Windows Server 2003 oder Windows XP (SP3) in jedem Fall wird aber ein 32 Bit OS benötigt. Außerdem benötigen wir Office (> 2003) ebenfalls in 32 Bit und die Exchange Management Tools (wieder in 32 Bit).

Abhängigkeiten

Für die Installation der Exchange Management Tools sind einige Vorbereitungen auf dem Rechner zu treffen:

• Microsoft .NET Framework 2.0 Download
• Microsoft Management Console Download
• Microsoft PowerShell 1.0
• Windows Installer 4.5 Download

Installation

Nachdem wir den ganzen Pakete heruntergeladen und installiert haben können wir mit der Installation der Exchange Management Tools (Download) anfangen. Die Sacher erweist sich als relativ schmerzfrei. Die einzige Besonderheit ist, dass man natürlich (dummer Fehler meinerseits) als Domänenadministrator angemeldet sein muß, da je nach AD Stand noch Schemaänderungen notwendig sind.

Zur Office Installation gibt es weiter auch nichts besonderes zu sagen. Ich habe ausschließlich Outlook und die Gemeinsamen Dateien installiert, das hat ausgereicht. Vergesst nur nicht einmal Outlook zu starten – sonst klappt aus irgendeinem Grund die Verbindung Authorisierung nicht.

Exportieren der Postfachdaten

Starten wir also die PowerShell (um genau zu sein die Exchange Management Shell) und prüfen ob unser Cmdlet Export-Mailbox zur Verfügung steht

[PS] C:\> get-help Export-Mailbox

NAME
    Export-Mailbox

[...]

Wenn alles geklappt hat sollte jetzt die Hlife von Export-Mailbox angezeigt werden (und wer will kann Sie auch lesen). Eigentlich können wir uns jetzt an den Export der Daten machen. Allerdings müssen wir, wie oben bereits erwähnt, erst noch für ausreichende Rechte in den Postfächern sorgen.

Geben wir also unserem Administrator Vollzugriff auf alle Postfächer:

Get-Mailbox | Add-MailboxPermission -User Admin.ADS -AccessRights fullaccess -Inheritance all

Sollten bei diesem Schritt keine Probleme auftauchen können wir uns dem eigentlichen Export zuwenden. Um zu prüfen ob alles korrekt eingerichtet ist exportieren wir zuerst ein einzelnes kleines Postfach:

Export-Mailbox -identity Beisel -PstFolderPath c:\psts\

Nach einer Sicherheitsabfrage die darauf hinweist, dass dieser Vorgang eventuell viel Zeit in Anspruch nimmt beginnt der Export. Im Anschluss an den Vorgang sollten wir im Ordner c:\PSTs\ die Datei “Beisel.pst” (in meinem Beispiel) vorfinden.

Wenn auch hier wieder keine Probleme aufgetreten sind wenden wir uns nun dem Batch Export zu:

Get-Mailbox | Export-Mailbox -PstFolderPath c:\psts\

Auch hier erfolgt eine Sicherheitsabfrage (für jedes Postfach) nach deren Bestätigung der Export startet. Je nach Umfang kann dieser Vorgang allerdings sehr viel Zeit in Anspruch nehmen weshalb ich hier vorschlagen würde erstmal Kaffee zu kochen.

In meinem nächsten Artikel wende ich mich dem Import der Daten unter Exchange 2010 zu. Trotz offensichtlicher Verbesserungen in diesem Bereich gibt es auch neue Probleme für die es Lösungen zu suchen gilt.

Das Bild zeigt eine Unterstützerin der Protestbewegung "Democracia Real Ya - London" während den gestrigen Protesten vor der Spanischen Botschaft in London.

Auf dem Schild sind folgende Zeilen zu lesen:

• Keine Arbeitsstelle
• Keine Wohnung
• Keine Rente
• Keine Angst

/via: Democracia Real Ya Londres

Streaming live video by Ustream