TC Blog » Konfiguration

Serie Cloud Security: Sind shared-images sicher?

Simon Bieber — Thu, 10 Nov 2011 10:48:24 +0000

Im Juni haben Darmstädter Forscher veröffentlicht, dass rund 30% von den 1100 untersuchten Images kritische Informationen beinhalten.

Dies haben Forscher aus Frankreich tiefgehender untersucht und dabei festgestellt, dass mehr als die Hälfte ihrer Untersuchungsgegenstände Informationen preisgaben, die besser vor Image-Freigabe hätten entfernt werden sollen.

Warum Image-Sharing?

Das Prinzip des Image-Sharings ist dafür gedacht, dass Entwickler für andere Entwickler bereits vorbereitete Systemumgebungen breitstellen (MI = Machine Image). Aber natürlich kann man es auch als Template verwenden. So kann mit relativ wenig zeitlichem Aufwand eine virtuelle Maschine gestartet werden (ohne Installation des Betriebssystems).

Was ist nun das Problem?

Untersucht wurden die auf allen Kontinenten frei verfügbaren AMIs (Amazon MIs). Dabei wurden diese auf Folgende Aspekte hin untersucht:

sensible Restinformationen (private Schlüssel,Zugangsdaten in Konfigurationsdateien, Backup-Dateien oder der Command-History)
Schwachstellen durch veraltete Software
Installierte Backdoors und andere Malware
Gelöschte Daten wiederherstellen

Gibt es eine Lösung?

Es gibt keine standardisierte Lösung. Sicherheit basiert auf Vertrauen. Offenbar vertrauen viele der Image-Ersteller auf den gutmütigen Nutzer und umgekehrt der Nutzer darauf, dass der Image-Ersteller keine bösen Absichten hat, wenn Images erstellt oder zur Verfügung gestellt werden und diese durch Andere genutzt werden. Für den Fall dass ein Nutzer dem Image nicht vertraut, dann wird er es auch nicht verwenden und sich dann (hoffentlich) die Mühe machen ein eigenes Image zu erstellen.

Wenn jetzt ein Image-Ersteller sein Image unbedingt anderen Nutzern (es muss ja nicht öffentlich sein, es kann ja auch nur unter bestimmten Nutzergruppen geteilt werden) zur Verfügung stellen will, sollte unbedingt beachten, dass keine sensiblen Restinformationen wie zum Beispiel:

Zertifikate oder Schlüssel
Backupdateien
Befehle (Command-History)
Passworte wechseln (oder ganz entfernen) bzw. im Deployment-Prozess auf Zufallspasswörter zurückgreifen

hinterlassen werden. Die gelöschten Dateien sollten zudem sicher gelöscht bzw. überschrieben werden.

Viele Anbieter (hier als Beispiel Amazon) geben darüber hinaus auch Tipps zur Image-Erstellung und vorheriger Vorbereitung.

/sb

P.s.: Anlass gab der heutige Artikel bei Heise

Sicheres Windows – Remotedesktop

ssupper — Tue, 01 Feb 2011 16:50:39 +0000

In dieser Ausgabe der Serie “Sicheres Windows” wird ein Auszug des Produkts “Admin-Klick-Tabelle” (welche die Einstellungen zur Absicherung eines Windows Clients bzw. Server enthält) erläutert, der sich mit den Remoteeinstellungen von Windows (in erster Linie M 2.327 Sicherheit beim Fernzugriff unter Windows XP und Windows Vista) beschäftigt.

Da heutzutage in vielen Firmen Windows Bordmittel (um die Kosten für teure Software von Drittanbietern zu sparen) eingesetzt werden, ist es unerlässlich zum Schutz der IT-Umgebung, diese abzusichern.

Im Folgenden ist ein Screenshot angefügt um einen Auschnitt der Umsetzungen zur Absicherung von Remotedesktop unter Windows zu zeigen.

(Zum Vergrößern bitte Bild anklicken)

Die erste Einstellung konfiguriert die Verschlüsselungsstufe für die Client-Verbindung fest. Sofern beide Partner der Verbindung aktueller sind als Windows 2000 SP4 ist die Einstellung Höchste Stufe auszuwählen, sodass mittels dem Sniffer-Tool “Wireshark” keine Kommunikationsdaten ausgespäht werden können.

Die zweite Einstellung legt fest, dass es nicht möglich ist mittels gespeicherten RDP-Verbindungen sich automatisch auf das entferne System aufzuschalten. Dies ist nun erst nach Eingabe eines gültigen Passworts möglich. Durch das Setzen dieser Einstellung wird es Angreifern erschwert, nachdem Sie ein System kompromittiert haben, sich direkt auf einem weiteren System einzuloggen.

Falls noch weitere Fragen bzw. mehr Informationen über diese Admin-Klick-Tabelle für Windows gewünscht werden, können Sie sich gerne auf unserer Homepage informieren.

/ssu

SSL-Konfiguration des Webservers testen

tglemser — Wed, 26 May 2010 09:37:45 +0000

Wie unter anderem hieran, daran oder auch daran deutlich wird, kann man bei der Konfiguration eines Webservers mit SSL viel falsch machen. SSL Labs war so freundlich und hat einen Online-Check veröffentlicht, mit dem man im Internet erreichbare Webserver auf SSL-Konfigurationsschwächen testen kann.
Ein Hinweis: Man landet automatisch bei einer Prüfung in der SSL-Datenbank des Betreibers.

Update 03.12.2010
Man kann die Schwachstelle auch ohne spezielle Tools testen. Eine Prüfung ist von einem Linux-Client auf dem Openssl-Client installiert aus wie folgt überprüfbar. Hierzu muss das System di-rekt (also ohne Proxies) auf das Zielsystem zugreifen können:
openssl s_client -connect www.ihrsystem.de:443

Wenn Folgendes angezeigt wird, ist der Server nicht verwund-bar: Secure Renegotiation IS supported. Im Falle, dass ein sicherer Verbindungswiederaufbau nicht un-terstützt wird, ist es dennoch möglich, dass der Server nicht verwundbar ist, falls der Verbindungswiederaufbau durch die Konfiguration vollständig verhindert wird. Hierzu im Anschluss Folgendes eingeben:
HEAD / HTTP/1.0 R
Im Anschluss versucht der Openssl-Client einen Verbindungs-wiederaufbau. Erhält man die Meldung einer handshake failure, ist der Server ebenfalls nicht verwundbar. Erhält man diese nicht, sondern eine HTTP-Ausgabe, ist der Server verwundbar.

/gt