Schlagwort-Archive: Security

FHEM Absichern

Nach der Installation von FHEM erhält man auf dessen Standardwebseite ([IP]:8083/fhem) eine Meldung der Sicherheitsprüfung die vermutlich so oder so ähnlich aussieht:

SecurityCheck:
WEB,WEBphone,WEBtablet has no basicAuth attribute.
telnetPort has no password/globalpassword attribute.
Restart FHEM for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.

 

Die hier aufgezeigten Probleme lassen sich recht einfach fixen.

Passwortschutz Einrichten

Um einen Passwortschutz einzurichten öffnen wir zuerst eine SSH Verbindung zu unserem FHEM Server und öffnen zudem in einem Browserfenster die fhem.cfg Konfigurationsdatei:

snaghtml590371c1_thumb-6262909

Die SSH Verbindung benötigen wir nun um unsere Benutzername / Passwortkombination mit base64 maskieren zu können.

Wichtig: base64 ist keine Verschlüsselung. Wenn ihr also wie ich Ausschnitte aus eurer Konfiguration veröffentlicht, dann solltet ihr diese Werte auf jeden Fall raus nehmen (oder dummy Werte verwenden).

Wir maskieren nun also zuerst unsere Benutzername / Passwortkombination. In meinem Beispiel verwende ich den Benutzernamen “Dummy” und das Passwort “Geheim123” und gebe folgende Befehlsfolge in der SSH Konsole ein:

echo -n Dummy:Geheim123|base64

Der Rückgabewert ist der base64 Wert zu Dummy:Geheim123.

RHVtbXk6R2VoZWltMTIz

image_thumb1-2957693

Diesen Rückgabewert benötigen wir nun in unserem Browserfenster. Hier fügen wir die nachfolgenden Linien ein (ggf. habt ihr bereits alles ausser den Teil mit basicAuth):

define WEB FHEMWEB 8083 global
attr WEB basicAuth RHVtbXk6R2VoZWltMTIz
define WEBphone FHEMWEB 8084 global
attr WEBphone basicAuth RHVtbXk6R2VoZWltMTIz
attr WEBphone stylesheetPrefix smallscreen
define WEBtablet FHEMWEB 8085 global
attr WEBtablet basicAuth RHVtbXk6R2VoZWltMTIz
attr WEBtablet stylesheetPrefix touchpad

und speichern diese Konfiguration mit Save fhem.cfg. Um die Konfiguration wirksam werden zu lassen müssen wir in der Kommandozeile (ganz oben auf der Seite) den FHEM Server noch mit folgendem Befehl neu starten:

shutdown restart

Der Server sollte nun neu starten und danach einen Benutzername und ein Passwort für die Anmeldung am Webfrontend verlangen. Nach der Erfolgreichen Anmeldung sollte sich die Fehlermeldung verändert haben – das einzige verbleibende Problem sollte jetzt nur noch telnet sein.

Telnet

Ich bin kein großer Freund von Telnet und habe bei FHEM auch noch keinen Grund gefunden, warum ich es diesem Server erlauben sollte in meinem Netzwerk einen Telnet Server anzubieten. Daher schlage ich vor diesen Service zu deaktivieren. Dies erreicht man durch einfaches auskommentieren (oder löschen) der entsprechenden Zeile aus der fhem.cfg:

image_thumb2-6307360

Update

Auch FHEM benötigt in regelmäßigen Abständen Updates. Bevor man diese durchführt empfehle ich in der fhem.cfg noch ein globales Attribut einzufügen welches FHEM anweist vor jedem Update ein Backup durchzuführen:

attr global backup_before_update 1

Das Update selbst führt man danach über die Befehlszeile mit folgenden Kommandos durch:

Anzeigen ob Updates vorhanden sind:

update check

Die Ausgabe wird danach so oder so ähnlich aussehen und die derzeit anstehenden Änderungen (auf Datei Ebene) ausgeben.

image_thumb3-7754826

Das eigentliche Update startet man danach mit dem Befehl:

update

Die Ausgabe sieht hier in etwas so aus:

image_thumb4-5861778

Test – GFI LANguard Netzwerk und Security Scanner

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:

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:

gfi_scan01-300x225-8234778

Ergebnisübersicht

gfi_scan02-300x182-3000111

Detailübersicht

gfi_scan03-300x27-6951572

Windows High Security Vulnerabilities

gfi_scan04-300x43-2788439

Windows Potential Vulnerabilities

gfi_scan06-300x75-5300472

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.

gfi_scan07-300x182-6097298

Windows High Security Vulnerabilities

gfi_scan08-300x182-3421805

Windows Patchlevel

gfi_scan09-300x86-8703584

Linux High Security Vulnerabilities

gfi_scan10-300x137-8724466

Linux Low Security Vulnerabilities

gfi_scan11-300x227-5070136

Linux Potential Security Vulnerabilities

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

Untersuchung zur Sicherheit der Over-the-air-Erzeugung von Master Encryption Keys zwischen BlackBerry-Geräten und dem BlackBerry Enterprise Server

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)

Windows Server Core Befehle

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.