Ich bin derzeit dabei mir mal wieder die aktuell auf dem Markt vorhandenen Lösungen zum Thema Netzwerk und Security Scanner anzuschauen. Als erstes Produkt steht dabei das Produkt GFI LANguard von GFI Software auf meiner Liste.

Kurzer Steckbrief:

• Architektur: “all in one client” basierend auf Windows
• Zielsysteme: Windows und Linux
• Lizenz: Kosten pro IP wobei fünf IPs kostenfrei erhätlich sind
• Webseite: http://www.gfi.com/lannetscan (en) http://www.gfisoftware.de/de/lannetscan/ (de)

Als erstes Szenario habe ich einen Scan auf zwei in virtuelle Maschinen installierten Server durchgeführt. Das erste System besteht aus einem Windows 2003 R2 SP1 System (ohne weitere Patches) welches bewußt einige Fehlkonfigurationen aufweisst. Ich habe u. a. everyone Vollzugriff auf das $ADMIN share gegeben und kein Admin Passwort gesetzt uvm. Das zweite System besteht aus einem mindestens genau so schlecht konfigurierten Debian (etch Kernel 2.6.18) System.

Bei dem ersten scan habe ich dem GFI LANguard scanner keine Anmeldeinformationen mitgegeben und folgendes Ergebnis erhalten:

Ergebnisübersicht

Detailübersicht

Windows High Security Vulnerabilities

Windows Potential Vulnerabilities

Linux Low Security Vulnerabilities

Wie man sehr gut sehen kann ist das Ergebnis nur eingeschränkt hilfreich. Auch das aktivieren der Option das Null Session Share des Windows Servers zu verwenden läßt das Ergebnis nicht besser aussehen.

Die wirklichen Stärken spielt LANguard erst dann aus, wenn man ihm Anmeldeinformationen mit gibt. Mit diesen Informationen ist der Scanner auch in der Lage den Patchlevel des Servers zu prüfen.

Windows High Security Vulnerabilities

Windows Patchlevel

Linux High Security Vulnerabilities

Linux Low Security Vulnerabilities

Linux Potential Security Vulnerabilities

… insbesondere die Linux Ergebnisse sollten jedoch sehr genau geprüft werden.

Im aktuellen Newsletter (der sehr zu empfehlen ist) von ERNW wird das Thema over-the-air-Erzeugung von Master Encryption keys zwischen Blackberry Server und Handheld analysiert. Der Artikel geht dabei sehr detailiert auf die Funktionsweise und die verwendeten Mechanismen zum sicheren Austausch des Schlüsselmaterials ein. Das Fazit der Bewertung fällt dabei “pro” RIM aus:

(…) Die Erzeugung von Master Encryption Keys zur Inbetriebnahme von BlackBerry-Geräten und für das automatische Update von Master Encryption Keys zwischen BlackBerry-Geräten und dem BlackBerry Enterprise Server (BES) wird aufgrund der vorliegenden Untersuchung als sicher im Sinne aktueller Sicherheitsstandards bewertet. (…)

Neben dem reinen Austausch des Schlüsselmaterials gibt der Artikel auch weitere Hinweise wie die Policy des BES zu konfigurieren ist um einen sicheren Betrieb sicherstellen  zu können:

• aktivieren der “Content Protection” um die auf dem BlackBerry gespeicherten Daten (Schlüssel) zu schützen
• setzen der Policy “Content Protection Strength IT-Policy” auf “stronger” um einen 283-bit langen ECC-Schlüssel zu erzwingen
• aktivieren des Passwortschutzes mit der Policy “Password Required IT-Policy” (sonst macht die Content Protection wenig Sinn )
• setzen der “Minimum Password Length IT-Policy” auf einen sicheren Wert – der Artikel empfiehlt hier zwölf Zeichen – dies dürfte jedoch in wenigen Umgebungen bei den Benutzern Zuspruch finden

Zusätzlich zu dem Artikel des ERNW lege ich jedem auch noch die Untersuchungen des Frauenhofer Institutes ans Herz. Diese Untersuchung deckt alle Teile mit Ausnahme der Over-the-air-aktivierung ab und sollte daher als Basis jeder guten BES Konfiguration verwendet werden.

Frauenhofer SIT 2006

Frauenhofer SIT 2008 (deutlich hilfreicher als das 2006er Dokument)

Remote-exploit.org hat heute die neuste Version von Backtrack veröffentlicht. Neben vielen Aktualisierungen bestehender Module sind auch ein paar neue dazu gekommen die z. B. das testen von WLAN (WEP) key vereinfachen sollen. Zudem gibt auch eine BT3 Version speziel für USB Sticks!

Downloadseite

Demovideo

Mit Windows Server 2008 hat Microsoft eine neue Installationsvariante eingeführt – die Core-Installation. Wie der Namen schon vermuten lässt werden hier nur die wichtigsten Teile des Servers installiert. Auf die Installation von einer GUI oder z. B. dem .Net Framework wird dabei verzichtet. Als Folge dessen kann der Server nur für eine eingeschränkte menge an rollen verwendet werden:

• Active Directory Domain Services (AD DS)
• Active Directory Lightweight Directory Services (AD LDS)
• DHCP Server
• DNS Server
• File Services
• Print Services
• Streaming Media Services
• Web Server (IIS)

Rollen wie z. B. der ISA Server oder Exchange Edge Transport Server, die durch Ihre Positionierung in der DMZ einem erhöten Risiko ausgesetzt sind, werden leider nicht als Rollen für den Core Server unterstützt.

Da der Core Server keine GUI mitbringt gestaltet sich die Administration für den normalen Windows Admin etwas ungewohnt (Linux bzw. Unix Admins dagegen werden sich sofort zuhause fühlen ).

Computer Name ändern

Den aktuellen Computernamen findet man heraus indem man einfach den Befehl hostname an der Konsole eingibt. Ändern kann man diesen dann mit folgendem Befehl:

netdom renamecomputer <ComputerName> /NewName:<NewComputerName>

IP Adresse ändern

Zuerst benötigt man die ID seiner NIC. Dazu gibt man folgenden Befehl ein:

netsh interface ipv4 show interfaces

Mit der ID kann man dan via netsh alle notwendigen Daten eingeben:

netsh interface ipv4 set address name="<ID>" source=static address=<StaticIP> mask=<SubnetMask> gateway=<DefaultGateway>

Die DNS Einstellungen ändeert man wie folgt:

netsh interface ipv4 add dnsserver name="<ID>" address=<DNSIP> index=1

(wobei man den Index für jeden weiteren DNS Server um eins erhöht)

Man kann seine NIC mit folgendem Befehl überzeugen DHCP zu verwenden:

netsh interface ipv4 set address name="<ID>" source=dhcp

Einer Domäne beitreten

netdom join <ComputerName> /domain:<DomainName> /userd:<UserName> /passwordd:*

(Ja, das Sternchen für das Passwort gehört da hin. Es kommt eine sep. Abfrage für das Passwort.)

Benutzer zu lokalen Gruppen hinzufügen

Um einen Benuzter zur lokalen Gruppe der Administratoren hinzu zu fügen benötigt man nur folgenden Befehl:

net localgroup administrators /add <DomainName>\<UserName>

Server aktivieren

Auch ein Server Core muß aktiviert werden. Direkt an dem Server kann man dies mit folgendem Befehl durchführen:

slmgr.vbs -ato

Der Befehl war / ist erfolgreich wenn keine Meldung erscheint. Ist eine automatische Aktivierung nicht möglich, so kann man eine telefonsiche aktivierung vornehmen. Dazu benötigt man jedoch einen Vista oder Windows 2008 Server der folgenden Befehl ausführt:

cscript windows\system32\slmgr.vbs <ServerName> <UserName> <password>:-ato

Firewall konfigurieren

Da die Firewall seit Windows 2008 per default aktiviert ist, muß man diese für Dienste die man nutzen möchte aktiveren. Will man z. B. remote via MMC’s auf den Server zugreifen (was wohl fast immer der Fall sein wird) dann kann man die Firewall dafür mit folgendem Befehl öffnen:

netsh advfirewall firewall set rule group="Remote Administration" new enable=yes

Will man die Firewall remote verwalten (Vista oder win2k8) dann muß man diese Funktion zuerst auf dem Server core aktivieren:

netsh advfirewall set currentprofile settings remotemanagement enable

… und nein, ich veröffentliche hier nicht wie man die Firewall einfach aus schaltet. Das lässt meine Ãœberzeugung nicht zu

Rechner neu starten

Server Core ist noch immer ein Windows daher wird man diesen Befehl sehr gut brauchen können…

shutdown /r /t 0

Auf den Technet Seiten gibt es eine Ãœbersicht über alle Command-line Befehle für Windows Server. Die o. g. Befehle ebenso wie alle Befehle auf der vorgenannten Technet Seite können natürlich auch auf “normalen” Servern verwendet werden.

Anleitungen wie man einzelne Rollen installiert folgen in den nächsten Stunden und Tagen.

Nachdem ich in meinem letzten Artikel gezeigt habe wie man den Security Configuration Wizard (SCW) installiert möchte ich nun am Beispiel eines Windows Exchange Server (Edge Transport) zeigen wie man diesen verwendet.

Als erster Schritt ist es notwendig die bei der Installation mitgelieferten Konfigurationsdateien im SCW zu registrieren. Der Exchange liefert hierfür in dem Unterordner “Scripts” seines Installationsverzeichnisses zwei XML Dateien mit. Die Datei Exchange2007.xml ist dabei für einen “normalen” Exchange Server und die Datei Exchange2007Edge.xml für einen Edge Transport Server. Für Windows 2008 Server gibt es jeweils noch Dateien mit der Endung _WinSrv2008.

Da wir im aktuellen Beispiel einen Edge Transport Server härten möchten kopieren wir die für diesen relevante XML Datei nach %windir%\Security\msscw\kbs. Das Tatsächliche registrieren der Rolle erfolgt mit folgendem Konsolenbefehl:

scwcmd register /kbfile:%windir%\security\msscw\kbs\Exchange2007Edge_WinSrv2008.xml /kbname:MSExchangeEdge

Nun Können wir den SCW an sich starten (Start – Suchen – SCW). Da wir noch keine Security Policy erstellt haben wählen wir im ersten Fenster “Create new security policy” aus.

Da man den SCM auch remote verwenden kann wird man aufgefordert ein Zielsystem zu wählen:

Abhängig von der Leistung seines Systems kann man nun eine gewisse Zeit auf einen solchen Balken starren .

Das folgende Fenster kann, nach genauem Studium der Warnung mit Weiter bestätigt werden. Im darauf folgenden Fenster werden die von Windows erkannten installierten Rollen für das System erkannt und vorausgewählt. Wenn wir bei der Registrierung der Exchange Edge Server Rolle alles richtig gemacht haben, dann sollte diese hier aufgeführt und ausgewählt sein.

Dem neuen Rollen bzw. Features Ansatz von Microsoft folgend wird man im nächsten Schritt nach den installierten Features gefragt wobei auch hier bereits eine Vorauswahl erfolgt ist (das warten oben hat sich gelohnt ). Allerdings sollte man den DNS Client in aller Regel nach nominieren.

Nun folgen noch die Options – wobei ich hier den Remote Desktop noch nominiert habe. Auch wenn die Maschine in der DMZ steht hätte ich gerne die Möglichkeit diese zu steuern. Leider reicht mein Budget in meinem privaten Testlab nicht für ein RemoteControlBoard (entsprechende Spenden werden jedoch jederzeit gerne angenommen…). Die Services “Microsoft Fibre Channel Platform Registration Service” und “Smart Card” sind dahingegen für mich nicht notwendig (obwohl vorausgewählt) und wurden daher von mir deaktiviert.

Nun kommen noch die zusätzlichen Dienste die auf der Maschine laufen. Da es sich bei meiner Maschine um eine Testmaschine handelt die auf einem Hyper-V läuft sind bei mir auch noch die damit verbundenen Dienste notwendig.

Langsam aber sicher geht es dem Ende entgegen. Im nachfolgenden Fenster erhalten wir nun die Wahl was mit Services geschehen soll, die nicht in den vorgenannten Dialogen an bzw. aus geschaltet wurden. Der sicherste Weg ist natürlich diese zu deaktivieren – und da wir diesen Wizard ausführen um ein System für die DMZ zu härten würde ich auch empfehlen diesen Weg zu gehen.

Nun bekommen wir noch eine Zusammenfassung (bitte genau Prüfen!)

Die Nachfolgenden Dialoge zeigen nun noch ein Mal die genauen Regeln, die definiert werden:

Da wir Mails über den Port 25 entgegen nehmen wollen müssen wir hier noch eine Regel hinzufügen. Das erledigen wir mit einem Klick auf Add.

Unter dem Reiter Protokolls and Ports müssen wir nun den Typ sowie die Portnummer festlegen, die wir freigeben möchten. Da man In- und Outbound nicht zusammen anwählen kann müssen wir diesen Schritt anschließend noch mal wiederholen um auch noch eine Outbound Regel zu erstellen.

Da wir hier einen Edge Transport Server installieren wird hier keine der Optionen ausgewählt:

Beim Auditing bin ich Mal wieder nicht der Meinung des Wizards. Hier würde ich nicht nur erfolgreiche Events aufzeichnen sondern auch fehlgeschlagene. Nur so kann man Angriffsversuche erkennen und entsprechende Gegenmaßnahmen veranlassen.

Jetzt wird es ernst:

Wenn Ihr System nun nach einem Reboot noch alle Funktionen erfüllt die es erfüllen soll dann sollten Sie dem Ziel ein sicheres System zu erhalten ein gutes Stück näher gekommen sein! Sie sollten allerdings nicht vergessen regelmäßig Sicherheitpatches zu installieren, in die Logs zu schauen und gegebenenfalls den Wizard erneut zu starten um evtl. durch Updates aktivierte Services wieder los zu werden! Sollte der Server seinen Dienst nicht wie vorgesehen verrichten können Sie den Wizard einfach neu starten und die Rollback Option wählen.

Testen kann man die Funktion des Edge Transport Servers am besten indem man zum einen via telnet auf Port 25 herzustellen versucht und zum anderen indem man auf dem Mailbox Server folgenden Befehl in der Exchange Management Shell absetzt:

Test-EdgeSyncronization