Skip to content

SSL/TLS BEAST Lücke

Im September 2011 haben die Sicherheitsforscher Duong und Rizzo nachgewiesen, dass eine - seit 2002 bekannte und in TLS 1.1 behobene - Schwachstelle in den SSL 3.0 und TLS 1.0 Verschlüsselungsprotokollen nicht nur theoretisch ist, sonder wirklich ausgenutzt werden können. Unter bestimmten Bedingungen erlaubt diese Schwachstelle einem Angreifer Teile aus einer SSL/TLS geschützten Übertragung zu ermitteln.

Gezeigt wurde dies am Beispiel eines abgefangenen paypal http Session Cookies, was erlaubte eine Browser Sitzung zu übernehmen. Das Problem ist unter dem Namen „BEAST“ (Browser Exploit Against SSL/TLS) bekannt, und wird unter der Common Vulnerability ID  CVE-2011-3389 geführt. Bei der Demonstration wurde ein Java Applet verwendet um die notwendigen Daten einzuschleusen, nach Duong/Rizzo es soll aber auch mit WebSockets oder JavaScript XHR Aufrufen möglich sein.

Dies zugrundeliegende kryptografische Schwäche ist ein generelles Problem vom SSL 3.0/TLS 1.0. Es wurde aber als 2002 nur als theoretischer Angriff gesehen, jetzt sind Angriffe mit Hilfe der erweiterten Funktionen des WebBrowsers bekannt geworden. Da es für einen erfolgreichen Angriff nicht nur notwendig ist, dass die verschlüsselte Verbindung abgehört werden kann, sondern auch, dass der Angreifer in den Klartext eigene Stück einfügen kann (Chosen Plaintext). Dies ist durch die Verwendung von JavaScript auf Webseiten relativ einfach möglich.

Wird bei SSL/TLS eine Blockchiffre im CBC (Cipher Block Chaining) Modus verwendet, so benutzt SSL 3.0 und TLS 1.0 einen vom Vorgängerblock abgeleiteten Initialisierungsvektor. Da sich dieser ermitteln lässt ist hier ein Problem gegeben, das durch geschicktes einfügen von Füllzeichen in den Klartext erlaubt Inhalte zeichenweise an den Blockgrenzen zu ermitteln.

Dies zu behaben bedarf es einer neuen Protokollversion: TLS  1.1. Aber in TLS 1.0 und SSL 3.0 kann es nicht so einfach verhindert werden. Somit hilft mittelfristig nur ein Update auf diese „neuen“ Protokolle, die zwar schon Jahrelang verfügbar sind, sich aber in der Praxis in den meisten WebServern und WebBrowsern noch nicht durchgesetzt haben (vor allem nicht per default aktiviert sind).

Mögliche Gegenmaßnahmen zu BEAST (und deren Probleme) sind:

  1. SSL/TLS Ciphers nicht im CBC Modus verwenden. Diese können in den gängigen Browsern und Servern abgeschalten werden. Die Gefahr dass dann Gegenstellen keine gemeinsame Verschlüsselung aushandeln können ist allerdings groß. Sollte also nur bei einer kleinen Anzahl von bekannten Kommunikationsgegenstellen benutzt werden.
  2. Statt die CBC Chiffren abzuschalten kann auf jedenfall die Stromchiffre RC4 (TLS_RSA_WITH_RC4_128_SHA) bevorzugt werden. Diese verwendet kein CBC und ist damit nicht betroffen. Dies macht Google z.B. schon seit einiger Zeit. RC4 ist nicht unumstritten, es gibt Angriffe gegen das Verfahren, die aber in SSL nicht auftreten.
  3. Oracle Java (JSSE) ab Version 1.6.0_29 und 7.0.0_1 implementiert einen CBC Schutz (der mit dem System Property jsse.enableCBCProtection aus kompatibilitätsgründen wieder abgeschalten werden kann) bei dem der erste Block in zwei mit der Länge 1 und (n-1) gesplittet wird. Erst mit Java 7 wird TLS 1.1 und 1.2 unterstützt.
  4. Der gleiche Fix wird gerade in Chrome Beta 15 getestet, es gab schon Kompatiblitätsprobleme.
  5. Für Opera 10.51 war der Fix geplant, ist aktuell noch nicht vorhanden (Opera benutzt keine WebSockets).
  6. Dieser Schutz wird auch in Mozilla Firefox (via NSS library) eingebaut, wartet dort aber noch auf eine Lösung der Kompatibilitätsprobleme und ist somit nicht Bestandteil von Firefox 7 (Mozilla sagt die WebSockets sind nicht verwundbar).
  7. Es ist zu erwarten dass Microsoft für den Internet Explorer nachzieht, bisher empfehlen sie nur die RC4 Chiffre zu bevorzugen (Windows XP scheint dies zu tun), Vorsicht bei dem Umgang mit http Seiten walten zu lassen und ggf. TLS 1.1 auf Client und Server zu aktivieren (immerhin unterstützen Microsoft Produkte dies schon, wird nur aus Kompatibilitätsgründen nicht aktiviert).
  8. Die Option TLS 1.1 (oder neuer) zu verwenden wird leider noch einige Zeit auf sich warten lassen. Besonders da SSL 3.0 und TLS 1.0 abgeschalten werden müssten, um zu verhindern das Angreifer diese erzwingen. Leider hängt openssl der TLS 1.1 Entwicklung nach, so dass auch Apache hier nur mit der RC4 Cipher gerettet werden kann (alternativ kann man mod_gnutls oder mod_nss verwenden, die sind aber beide weniger stark in der Nutzung).

Rechner im AD LDAP mit Powershell auflisten

Ich hab ein wenig mit Powershell herumgespielt (weil ich das Script das auch in de.Hackin9.org 08/2011 abgebildet war nicht verstanden habe). Dabei kam dann folgendes funktionierendes Script heraus, es sortiert mit alle Rechner des AD LDAPs und zeigt diese in einem grafischen Viewer mit Betriebsystemversion und Servicepack Level an:
$ldapSearcher = new-object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
$pcs = @();
foreach ($c in $computers) {
  $pc = "" | Select-Object Name,OS,SP,SPN;
  $pc.Name=$c.properties["cn"];
  $pc.OS=$c.properties["operatingsystem"];
  $pc.SP=$c.properties["operatingsystemservicepack"];
  $pc.SPN=$c.properties["serviceprincipalname"];
  $pcs += $pc;
}
$pcs | sort-object OS,SP,Name | Out-GridView;
Ich habe aber keine Ahnung wie man einfacher aus den Dictionary Entries des $c.Properties Member direkte Properties machen kann ohne diese mit einer foreach Schleife und direktem Assignment aufwändig zu kopieren. Ich hoffe ein mitlesender Powershell Guru kann mir das kurz sagen? :) Update: Max Trinidad (@MaxTrinidad) hat mich auf die Idee mit New-Object gebracht, damit lässt sich das Script etwas vereinfachen und die Attribute in Strings konvertieren:
$ldapSearcher = new-object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
[Array] $pcs = $null;
foreach($c in $computers) {    
    $pcs += New-Object PSobject -property @{
        Name = [string]$c.properties["cn"];
        OS = [string]$c.properties["operatingsystem"];
        SP = [string]$c.properties["operatingsystemservicepack"];
        SPN = [string]$c.properties["serviceprincipalname"]; }
}
Und darauf aufbauend (aber ohne String Konvertierung) dann die Lösung mit der Automatischen Übernahme aller Dictionary Einträge aus dem AD Objekt:
$ldapSearcher = New-Object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
[Array] $pcs = $null;
$computers | ForEach-Object { $pcs += New-Object PSobject -property $_.Properties; }
$pcs | Out-GridView;

STRIDE vs. CIA

Microsoft hat mit Ihrem Security Development Lifecycle für eine deutliche Steigerung der Sicherheit Ihrer Produkte gesorgt. Zudem ist die Methodik offen zugänglich und verbessert somit die Software Entwicklung auch in anderen Firmen. Ein Konzept das bei der Analyse und Modellierung von Risiken und Bedrohungen im Ramen von SDL eingesetzt wird ist die STRIDE-Klassifizierung von Bedrohungen:
ThreatDefinition
SpoofingImpersonating something or someone else.
TamperingModifying data or code
RepudiationClaiming to have not performed an action.
Information DisclosureExposing information to someone not authorized to see it
Denial of ServiceDeny or degrade service to users
Elevation of PriviledgeGain capabilities without proper authorization
Diese Klassifizierung finde ich nicht sonderlich nützlich. Die Klassen der Bedrohungen überlappen sich. Es ist eine Mischung aus Angriffen auf primäre und sekundäre Schutzziele. Viel besser finde ich es daher, bei der Betrachtung von Bedrohungen deren Auswirkungen auf die Primären Schutzziele der Informationssicherheit (CIA) zu betrachten:
Confidentiality (Vertraulichkeit)
Integrity (Integrität)
Availability (Verfügbarkeit)
Wenn alle drei Schutzziele erfüllt sind so stellt ein Informationssystem sicher, dass die richtige Person unverfälschte Daten jederzeit nutzen kann. Das CIA Trippel steht auch in der Kritik nicht alle Fälle abzudecken, so wird z.B. immer wieder angeführt dass Zurechnungsfähigkeit oder Nicht-Abstreitbarkeit (Accountability, Non-Repudiation) damit nicht abgedeckt werden. Das sehe ich allerdings nicht so, denn wenn eine Anforderung an ein IT System ist, dass man nachvollziehen kann wer etwas gemacht hat, so werden dazu eigene Daten erfasst, und deren Integrität (kann nicht verändert werden) und Verfügbarkeit (kann nicht unterdrückt werden) stellen sicher, dass authorisierte Nutzer diese Daten einsehen können. Die STRIDE Eigenschaften lassen sich mit CIA gut ausdrücken:
SpoofingBenutzer die sich als andere Nutzer ausgeben können sind nur ein Problem wenn daraufhin Daten unerlaubterweise weitergegeben werden (Vetraulichkeit) oder wenn andere Benutzer sich auf die Urheberschaft von Informationen verlassen (Integrität).
TamperingUnerwünschtes ändern von Daten oder Code ist ein Angriff auf die Integrität des Systems
RepudiationEin System das Nachvollziehbarkeit benötigt kann darüber unverfälschte (Integrität) Aufzeichnung führen sie sich nicht unterdrücken (Availability) lassen.
Information DisclosureEin Verstoss gegen die Vertraulichkeit
Denial of ServiceEin Angriff auf die Verfügbarkeit des Systems
Elevation of PriveledgeAngreifer erlangt mehr Rechte als Ihm zustehen. Dies ist ein Problem wenn damit Angriff auf Integrität oder Vertraulichkeit erfolgt
Anhand der Gegenüberstellung wird klar, dass mit den 3 Schutzzielen die meisten Bedrohungen besser klassifizieren lassen. David LeBlanc, einer der Väter der STRIDE Methode gibt dies in einem Blogpost auch offen zu. Er sieht trotzdem einen Anwendungsfall für die Methode in der Praxis. Ich persönlich würde mir wünschen, wenn SDL hier angepasst wird. Nützlicher sind hier eher Checklisten mit typischen Bedrohungen (und deren Auswirkungen auf die Primären Schutzziele).

IPv6 default address selection in Java

Da bei IPv6 Nodes (also Rechner und andere Teilnehmer an einem Netzwerk) schon konzeptionell mehrere Adressen haben ist die Auswahl welche Quell- und Zieladresse verwendet werden soll eine wichtige Funktion. Insbesondere dann wenn ein Rechner im Dual-Stack Betrieb sowohl IPv4 als auch IPv6 Adressen erreichen kann. Bei IPv6 kann jedes Netzwerkinterface mehrere IPv6 Adressen haben, die dann entweder in unterschiedlichen Bereichen (Scopes) genutzt werden können (localhost, link, site, global) oder die unterschiedliche Bevorzugt (valid, prefered) sind. Durch die Unterstützung von Renumbering (stateless autoconfiguration) haben Adressen unterschiedliche Lebenszeiten. Zudem gibt es Adressen die über eine Migrations-/Tunnel Technologie wie Toredo, ISATAP oder 6to4 bereitgestellt werden, und nicht immer benutzt werden sollen. Idealerweise würde eine Anwendung oder das Betriebssystem alle möglichen Quell/Ziel-Adresskombinationen ermitteln, und alle (aussichtsreichsten zuerst) durchprobieren. RFC 3484 beschreibt ein Verfahren für die Default Address Selection für IPv6. Der von Microsoft Research verfasste Entwurf gibt Regeln vor wie die Auswahl von Ziel- und Quelladressen zu geschehen hat, und definiert auch eine Möglichkeit dass der Administrator eines Systems eigene Gewichtungen definieren kann. Ideal wäre eine Laufzeit Funktion, der man einen Hostnamen übergibt, und die dann die Verbindung zur Gegenstelle herstellt und dabei alle Regeln des RFC 3484 (und dringend notwendiger zukünftiger Verbesserungen) beachtet. Durch die Trennung zwischen Kernel und Usermode, und aus Gründen der Kompatibilität mit existierendem Netzwerkcode verwenden die meisten* Systeme allerdings ein anderes Verfahren. Bestehende Funktionen wie z.B. getaddrinfo(3) wurden erweitert: die Auflösung von Hostnamen in Adressen liefert jetzt eine nach Präferenzen sortierte Liste der Zieladressen zurück. Dabei greift die Bibliotheksfunktion auf Adress- und Routinginformationen des Kernels zurück. Denn es müssen für jede zurückgelieferte Zieladresse auch die potentiellen Quelladressen bestimmt und bewertet werden. Unter Windows kann die Sortierung mit der prefixpolicy (netsh.exe interface ipv6 show prefixpolicies) angezeigt werden. Linux Systeme speichern die Konfiguration in /etc/gai.conf, aktuelle Einstellungen können mit dem iproute2 Paket angesehen werden (ip addrlabel). Das ganze ist im Kernel und der glibc implementiert. Auch bei Java wurde kein komplett neues Verfahren für den Verbindungsaufbau für IPv6 definiert**. Die Anwendung selbst ist dafür zuständig alle möglichen Zieladressen der Reihe nach durchzuprobieren. Wenn die Anwendung keine Quelladresse angibt (was sie vermeiden sollte) so wird dann der Kernel für jeden der Zieladressen eine Quelladresse auswählen. Wenn eine Adresse nicht erreichbar ist, so muss die nächste Adresse verwendet werden. Wenn alle Adressen nicht erreichbar sind, so sollte eine Fehlermeldung zurückgegeben werden die alle probierten Zieladressen benennt und den ersten (oder alle) Fehlermeldungen benennt. Beispielhaft kann dies so aussehen:
Socket connectToHost(String host, int port)
	throws UnknownHostException, SocketException
{
	IOException firstException = null;

	InetAddress[] addressArray = InetAddress.getAllByName(host);
	for(InetAddress addr : addressArray)
	{
		try {
			return new Socket(addr, port);
		} catch (IOException ex) {
			if (firstException == null)
				firstException = ex;
		}
	}

        // build informative error message
	StringBuilder msg = new StringBuilder("Unable to connect to host=");
	msg.append(host); msg.append(" port="); 
        msg.append(String.valueOf(port)); msg.append(" [");
	
	for(int i=0;i < addressArray.length;i++)
	{
		if (i != 0)
			msg.append(',');
		msg.append(addressArray[i]);
	}
	msg.append("]: "); msg.append(firstException.getMessage());
	SocketException se = new SocketException(msg.toString());
	se.initCause(firstException);
	throw se;
}
Dieser Code überlässt die Auswahl einer Quelle dem Kernel (es werden also nicht alle möglichen Kombinationen durchprobiert). Ebenso ist kein Handling für Timeouts enthalten, und ein Cache der Verbindungszustände erinnert oder gar ein paralleler Aufbau zu mehreren Zielen ist noch nicht enthalten. Trotzdem ist der Code schon recht komplex, sollte also nicht mehrfach implementiert werden müssen. Von InetAddress.getByName(String host) würde ich auf jeden Fall Abstand nehmen. Diese Methode gibt nur die bevorzugte Addresse zurück, und führt bei DualStack Anwendungen dazu, dass nicht IPv6 und IPv4 Adressen durchprobiert werden. * Microsoft ist typischerweise Entwicklerfreundlicher und muss weniger Rücksicht nehmen auf etablierte APIs, deswegen gibt es die Funktion WSAConnectByName() die alle Addressen selbst durchprobiert. ** Java kennt Socket(String name, int port), dieser Konstruktor verwendet aber keine Schleife um alle möglichen Adressen zu kontaktieren.

Windows 7 hosts-file ignoriert IP Addressen mit 0 prefix

Mir ist gerade zufällig aufgefallen (als ich diesen Bugreport nachgestellt habe) dass Windows 7 IPv4 Address-Einträge die eine führende 0 haben im hosts file ignoriert:
C:\Windows\system32>echo 9.20.187.06 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96

C:\Windows\system32>echo 9.20.187.6 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96
    (Host-)A-Eintrag  . . : 9.20.187.6

jarsigner mit Tokens

jarsigner mit ASEKey Token Dialog unter Windows 7Um Java Applets und JAR Files zu signieren nutzt man den jarsigner, der normalerweise ein Java-Keystore (.jks) file nutzt. Es ist allerdings ungünstig Codesigning Zertifikate einfach so in Files herumliegen zu haben (auch wenn man diese gesondert sichert). Es ist anzuraten ein Zertifikat besser in einer SmartCard oder einem Token zu speichern. Der Oracle jarsigner.exe verwendet die Java Security Provider der JCE API. Um damit ein Hardware Token anzusprechen gibt es im wesentlichen 2 Methoden. Entweder den PKCS#11 Provider (benötigt eine PKCS#11 library (.dll oder .so) des Hardwareherstellers) oder unter Windows den Microsoft CryptoAPI (MSCAPI) treiber. Letzteres hat den Vorteil dass die meisten Smartcards unter Windows 7 oder 2008 bereits Treiber beim einstecken installieren. Diese Minitreiber sind nur begrenzt nutzbar, aber für das signieren reicht es aus. Bei meinen Versuchen habe ich aber einige Einschränkungen gefunden:
  • Es wird Java 5,6 oder 7(>b144) benötigt.
  • Ich habe nur die Java Distribution von Sun/Oracle getestet
  • In der 64bit Variante wird der Provider aktuell nur von Java 7 ausgeliefert
  • Über MSCAPI wird immer in getrenntem Dialog nach PIN gefragt
Anbei Beispielbefehle zum auslesen des Keystores (in dem auch das Codesigning Zertifikat das auf dem USB Token gespeichert ist sichtbar ist) sowie dem Signaturvorgang:
c:\Program Files (x86)\Java\jdk1.6.0_24\bin>keytool -list -storetype Windows-MY

Keystore-Typ: Windows-MY
Keystore-Provider: SunMSCAPI

Ihr Keystore enthält 4 Einträge.
...
FIRMA AG, PrivateKeyEntry,
Zertifikatsfingerabdruck (MD5): 57:EF:97:04:EA:91:EE:FF:CF:BF:7F:75:AE:E1:A2:7D
...
c:\Program Files (x86)\Java\jdk1.6.0_24\bin>jarsigner.exe -storetype Windows-MY
%TEMP%\test.jar "FIRMA AG"
Als Speicher für die Zertifikate verwende ich ein Athena ASEKey Crypto Token in das ich mit den Athena IDProtect Tools auf einem anderen Computer das Codesigning Zertifikat von Verisign (Promo:WINQUAL99) importiert habe. Das Zertifikat ist übrigens ein Authenticode Class 3 Zertifikat das es aktuell für Teilnehmer am Microsoft WinQual Programm für ein Jahr günstig ($99) gibt. Entgegen den Angaben von Verisign lässt sich dieses auch problemlos für Java Signig verwenden. Einziges Problem bei der Sache, mit -storepass oder -keypass lässt sich die PIN für die SmartCard nicht angeben, diese fragt immer mit einem Popup nach entsprechender Freigabe. Ich habe in den Athena Tools keine Möglichkeit gefunden diese abzuschalten (allerdings geht es mit der PKCS#11 API, wie ich im nächsten Beitrag berichten werde).
c:\Program Files (x86)\Java\jdk1.6.0_24\bin>jarsigner -verify -certs -verbose %T
EMP%\test.jar

         134 Thu Jun 02 23:27:48 CEST 2011 META-INF/MANIFEST.MF
         258 Fri Jun 03 00:04:02 CEST 2011 META-INF/FIRMA_AG.SF
        4764 Fri Jun 03 00:04:02 CEST 2011 META-INF/FIRMA_AG.RSA
           0 Thu Jun 02 23:23:38 CEST 2011 META-INF/
sm     15104 Sun Mar 06 04:56:06 CET 2011 jarsigner.exe

      X.509, CN=FIRMA AG, OU=Software Development, 
                OU=Digital ID Class 3 - Microsoft Software Validation v2,
                  O=FIRMA AG, ST=Baden-Wuerttemberg, C=DE
      [certificate is valid from 21.12.10 01:00 to 22.12.11 00:59]
      X.509, CN=VeriSign Class 3 Code Signing 2010 CA
      [certificate is valid from 08.02.10 01:00 to 08.02.20 00:59]
      [KeyUsage extension does not support code signing]
      X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5
      [certificate is valid from 08.11.06 01:00 to 17.07.36 01:59]
      [KeyUsage extension does not support code signing]


  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.
Update: Ich habe das ganze gerade mit der b144 von Java 7 getestet, und damit lassen sich sowohl mit 32bit als auch mit der 64bit Version der MSCAPI Provider für die Signatur von JAR Files via Smart Token nutzen.

Hardware Security

Kris weißt in einem Tweet auf eine Diskussion zum Thema Sicherheit von Management-Adaptern hin. Im konkreten Fall wurde vermutet dass ein BMC (Der Mikro-Controller der die IPMI Schnittstelle bereitstellt) Spam Mails versendet hatte (nachdem er kompromittiert wurde). In dem Forum wird nicht klar, ob es wirklich der Fall ist und welche Schwachstelle dabei verwendet wurde. Aber in den Kommentaren sind einige sehr bedenkliche Meinungen und Vorgehensweisen zu entdecken: Management Adressen (SSH, HTTP, Remote-IPMI) werden von einzelnen Admins absichtlich im öffentlichen Netz zugänglich betrieben - oder aus Versehen aus Unkenntnis. Hersteller der BMCs installieren keine oder unsichere Default-Passwörter. Generell waren die Admins der Meinung dass BMCs gar nicht die Ressourcen haben um Spam zu versenden, und es wird unterstellt die Firmware auf den Controllern sei unbedingt sicher. Das ist natürlich eine naive Annahme. Auf den BMC Mikro-Controllern läuft ein Betriebssystem mit vollem IP-Stack und Anwendungsprozesse (Web Server, SSH Daemon, IPMI Agent, Shell/Menu) und diese können natürlich falsch konfiguriert werden oder verwundbar sein. Die IPMI Firmware wird oft von Administratoren vernachlässigt, weil es nicht in den normalen Update Prozessen des Betriebssystems integriert ist. Ich sehe folgende Punkte für den Betrieb von Servern mit Management Adaptern (oder Lights-Out Karten) als wichtig an:
  • Firmware des BMC in den Update/Patch Prozess aufnehmen
  • Mittels physischer Ports oder VLANs BMC in getrenntem Management LAN betreiben
  • Zugriff auf Management LAN beschränken, nur über sichere Hops zugreifen lassen
  • Server provisioning Prozedur muss sichere Konfiguration der BMC Adapter beinhalten (Zertifikate, Passwörter, User, evtl. SSO, WoL Secret....)
  • Verzicht auf Produkte die keine Netzwerksicherheit (Verschlüsselung) bieten
Generell kann man sagen, der Remote-Zugriff auf BMC Funktionen ist vergleichbar mit physikalischem Konsolen-Access (besonders dann wenn hier auch Consolas und Laufwerke gemapped werden können).

Amazon Web Services als PaaS Anbieter

Mit dem neuen (Beta) Dienst Beanstalk steigt Amazon in das Platform-as-a-Service Geschäft ein. Vergleichbar mit dem Google AppEngine for Java Dienst können Java Entwickler einfach Web Anwendungen in WAR Files verpacken und in die Cloud hochladen. Amazon kümmert sich um die Skalierung aller Komponenten. Man könnte fast annehmen ursprünglich war das WAR Deployment Modell genau so gedacht. Amazon rechnet die unterliegenden Infrastrukturdienste ab. Das ergibt sich aus den Freiheitsgraden die man hat, macht die Rechnung aber komplex - und vor allem für Low-Traffic Anwendungen eventuell nicht gerade preiswert. Die Amazon Beispielrechnung kommt z.B. auf $30/Month. Immerhin können die sehr günstigen EC2 Micro Instanzen ($0.02/h) genutzt werden.

Database Administration for Diaspora pods (mongo shell)

One advantage of running your own Diaspora pod is the fact, that you have access to the MongoDB which is used to store your Seed. This allows you to do some functions which do not yet have a UI (for example canging the E-Mail address of a user) or which is required to work around alpha hickups (deleting duplicate requests). The mongo shell is a client to the mongodb, which can evaluate JavaScript expressions. It has some macros ("use", "show" and "help"), the other commands are typically JavaScript methods. First you assign a Database Object to the variable "db", you can use that with "use". In the case of Diaspora, the database is named "diaspora-ENVIRONMENT". If you start mongo shell, it will start with the database "test", but you can list all existing databases, and pick one:
$ mongo
connecting to: test
> print('hello JavaScript!')
hello JavaScript!
> show dbs
admin
diaspora-development
local
magent
> use diaspora-development
switched to db diaspora-development
> db
diaspora-development
> show collections
aspects
comments
contacts
invitations
people
posts
requests
system.indexes
users
Note: you can specify non-existing databases and collections, they are initially empty but will be created, so do not misstype. You can use db.collection.help() to see the available methods on a collection object. find() is used to search and display documents. If you specify no parameters it will return a cursort with all documents. The first parameter can be a list of filter criterias, and the second parameters a list of properties to return. mongo shell will iterate and print the first ten entries of a cursor automatically:
> db.users.find({},{username:1,email:1})
{ "_id" : ObjectId("4cf1..02"), "username" : "bernd", "email" : "bernd-09@eckenfels.net" }
{ "_id" : ObjectId("4cf1..2d"), "username" : "mela", "email" : "mela@mela.de" }
{ "_id" : ObjectId("4cf2..3b"), "username" : null, "email" : "xx@example.com" }
Here you can see, that this pod has 3 users (seeds), two are already established, the third is a pending invite (token). To change the e-mail address of a existing user you can assign the document to a variable, change the desired property and update the collection. For this we use the findOne method, which does return the first match instead of a cursor:
> var bernd = db.users.findOne({username:"bernd"})
> print(bernd.email)
bernd-09@eckenfels.net
> bernd.email = "bernd-10@eckenfels.net"
> db.users.save(bernd)
> db.users.findOne({username:"bernd"}).email
bernd-10@eckenfels.net
The above will not create a new document, since the variable "bernd" contains the property _id, and therefore it will update the existing entry in the collection. You need to know that db.users contains the actual users of the pod (i.e. the seeds) and db.people contains a copy of the public part of other seeds (if you received a request from them, or if you added them to an aspect).
> db.requests.findOne()
{
        "_id" : ObjectId("4cf1...a3"),
        "sent" : true,
        "from_id" : ObjectId("4cf1...03"),
        "to_id" : ObjectId("4cee7...a9"),
        "into_id" : ObjectId("4cf1...9d")
}
> db.people.findOne({_id:ObjectId("4cf1...03")}).diaspora_handle
bernd@pod.eckenfels.net
> db.people.findOne({_id:ObjectId("4cee7...a9")}).diaspora_handle
daniel...@joindiaspora.com
> db.aspects.findOne({_id: ObjectId("4cf1...9d")}).name
Piraten
As you can see I sent a request to "Daniel", inviting him to my aspect "Piraten", but he has not yet responded. Hope this helps you to find your way around in the object model of Diaspora. I recommend you read the MongoDB tutorial to better use the mongo shell, and check the JS API documentation for the details.

Apache als Reverse Proxy für Diaspora

Diaspora* die Software für verteilte soziale Netze wurde in einer Alpha Version veröffentlicht. Bei Diaspora ist vorgesehen dass es keine zentrale Plattform gibt, sondern Benutzer Ihre eigenen Server - Pods genannt - betreiben. Da es aktuell auch auf dem offiziellen pod von joindiaspora.com keine Benutzer freigeschalten werden, ergibt es Sinn einen eigenen Server aufzusetzen. Im Diaspora Wiki findet man dazu eine Anleitung. Allerdings beschreibt diese nicht, wie man in einer Produktivumgebung die Ruby Anwendung mit einem Webserver versieht, der die Anfragen auf Port 80 entgegennimmt (und statische Assets direkt ausliefert). Ich habe dazu einen virtuellen Host mit Apache eingerichtet, die Konfiguration sieht so aus:
LoadModule proxy_module ...
LoadModule proxy_http_module...

<VirtualHost *>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/example.com/pod/data/public
    ServerName pod.example.com
    ErrorLog /var/log/httpd/pod.example.com-error_log
    CustomLog /var/log/httpd/pod.example.com-access_log combined

    Alias /uploads/ "/var/www/example.com/pod/data/public/uploads/"
    Alias /images/ "/var/www/example.com/pod/data/public/images/"
    Alias /stylesheets/ "/var/www/example.com/pod/data/public/stylesheets/"
    Alias /javascripts/ "/var/www/example.com/pod/data/public/javascripts/"

    ProxyPass / http://pod.example.com:3000/

  <Directory "/var/www/example.com/pod/data/public">
    Options Indexes FollowSymLinks MultiViews IncludesNoExec ExecCGI
    AllowOverride All
    Order Allow,Deny
    Allow from All
  </Directory>
</VirtualHost>
D.h. Diaspora ist im Verzeichnis /var/www/example.com/pod/data installiert, und der Ruby Server "thin" ist erreichbar auf dem Port 3000. Falls es jemand testen will, mein Diaspora Seed ist damit unter bernd@pod.eckenfels.net erreichbar.

WLAN to go (Trekstor Portable WLAN HotSpot)

Vor einiger Zeit habe ich mich bei der PR Agentur von Trekstor beschwert, dass diese mir als Blogger zwar unverlangt Pressemitteilungen senden, aber ohne Testgeräte ich nicht viel berichten kann und will. Jetzt habe ich überraschend ein Testgerät von Trekstor erhalten, und will dies hier gerne besprechen: In einem sehr kleinen Paket habe ich den "Trekstor Portable WLAN Hotspot" für einen 2-wöchigen Test erhalten. Ein Gerät in der Größe eines Mobiltelefons das als WLAN Hotspot eingesetzt werden kann, und dabei die Verbindung mit dem Internet mittels eingebauter UMTS Funktion herstellt. Es ist also ein UMTS WLAN Router, benötigt dabei aber keinen externen USB Stick, die SIM-Karte des Mobilfunkanbieters wird direkt in das UMTS fähige Gerät eingelegt. Bis zu 5 WLAN Geräte können sich mit dem Hotspot verbinden, und dieser stellt dann die Verbindung zum Internet via UMTS/HDSPA (3G) oder GSM her. Zusätzlich hat das Gerät einen Mini-USB Anschluss über das es geladen werden kann. Über diesen USB 2.0 Anschluss kann auch ein weitere Rechner (Via Hi-Speed USB 2.0 Netzwerk Interface Treiber) angebunden werden. Der kleine Hotspot kümmert sich dabei um NAT, Firewall, hat einen DNS Proxy und DHCP Server eingebaut. Konfiguriert wird das Gerät über den Web Browser. Die Knöpfe am Gerät beschränken sich auf ein Minimum (Ausschalter, WLAN Schalter, Manueller Connect). Das Trekstor Gerätes ist Baugleich mit dem E5 von Huawei (dies wird auch nicht versteckt, das Logo ist auf der Rückseite zu sehen). Das Gerät ist Netlock frei, konnte in meinem Test mit Prepaid Standard SIM Karten von blau.de ebenso wie mit einem UMTS Datenvertrag von O2 genutzt werden. Es unterstützt UMTS im 2100MHz Band sowie Quad-Band GSM (EDGE, GPRS) 850/900/1800/1900MHz - ist also für Reisen geeignet. Das WLAN Modul kann im 2,4GHz Band die Kanäle 1-13 nutzen. (Es gibt bei den Europäischen Modellen eine Ortseinstellung bei der man auch "Japan" auswählen kann, diese schaltet aber keinen weiteren Kanal frei). Das Gerät unterstütz WPS, konnte ich aber mangels Gegenstelle nicht testen. Diese Funktion klingt aber kaum einfacher als das abtippen eines Passwortes von der Gehäuserückseite.
Die Anwendungsfälle sind vielfältig. Als Besitzer von Internet Tablets oder Game Consolen die keine UMTS-Stick Möglichkeit haben ist das Gerät auf jeden Fall eine praktische Option. Weiterhin kann das Gerät von kleinen Reisegruppen oder Arbeitsgruppen mit Note- oder Netbooks genutzt werden um einen (teuren) Internetzugang gemeinsam zu benutzen. Es ist damit Ideal geeignet die Wartezeit am Flughafen zu überbrücken ohne dass jeder der beteiligten einen eigenen Datentarif haben muss (einige Provider erlauben nicht den Betrieb von mehreren Geräten per NAT, dies muss im Einzelfall geprüft werden). Praktisch an dem Prinzip der WLAN Anbindung ist, dass in der Regel alle Geräte ohne spezielle Treiber die Vermittlungsfunktion des Gerätes nutzen können. Es wird dabei WLAN nach 802.11 b/g mit WPA und oder WPA2. Der WLAN Hotspot wird mit einem austauschbaren 3.7 V, 1500 mAh Akku geliefert. Es kann über USB vom Rechner geladen und mit Strom versorgt werden. Bei meinen Tests hatte es Laufzeiten von über 4h. Es kann dabei auch von USB Steckernetzteilen oder externen Akkus (Test mit einem Phillips Reserveakku, der zum Beispiel von iPhones nicht akzeptiert wird, war erfolgreich). Als zusätzliche Funktion bietet das Gerät übrigens noch einen MicroSD Kartenslot in der Speicherkarten bis zu 32GB eingesteckt werden können. Diese können dann entweder über den USB Anschluss benutzt werden, oder der Zugriff auf den Inhalt steht über den Web Server des Geräts zur Verfügung. Generell ist das Gerät und die Software gut durchdacht, es können mehrere Mobilfunk Profile angelegt werden; mutige Zeitgenossen können die Mobilfunk-PIN im Gerät speichern; wenn Roaming erkannt wird vermeidet das Gerät automatisch Online zu gehen. Bei der Auslieferung hat das Gerät einen eindeutigen Verschlüsselungskey (der auf der Geräterückseite aufgedruckt ist). Die NAT (ALG, DMZ) und Firewall Funktionen können mit guten Home Routern locker mithalten. Das Gerät wird mit einem kurzen Mini-USB nach USB Kabel geliefert (aber keinem Netzteil) und einem Quick-Start Guide der keine der Optionen der Software auch nur ansatzweise erklärt. Er ist aber ausreichend um die erste WLAN Verbindung mit dem Gerät aufzubauen (Ich empfehle als einer der ersten Aktionen den WPA2 Modus zu aktivieren). Ja, ich kann das Gerät fast nur loben, auf der Seite der Nachteile sehe ich vor allem den relativ hohen Preis (wobei es im direkten Vergleich mit anderen Geräten in der Leistungsklasse mit 139,- Eur günstig abschneidet), kleinere Lieblosigkeiten in der recht technischen Web Oberfläche (zum Beispiel die Deutsche Übersetzung "x Tag x Stunden x Protokoll") und die doch recht knappe Begrenzung auf 5 WLAN Clients. Das OLED Dot Display ist recht übersichtlich aber unter vielen Lichtbedingungen kaum abzulesen (spiegelt). Dem Gerät fehlt auch eine VPN Funktion, allerdings sehe ich das nicht als Nachteil an, ein VPN sollte besonders in diesem Einsatzszenario (WLAN) auf dem Endgerät (Notebook) terminiert werden. Für den stationären Einsatz würde ich das Gerät nicht empfehlen, ebenfalls nicht zur (Not)Versorgung von Veranstaltungen mit Internet (wegen der Anzahl der Clients und den fehlenden externen WLAN Antennen). Aber als Reisebegleiter macht es eine sehr gute Figur. Ich habe keine Erfahrungen mit der Stabilität des Gehäuses, beim Anfassen traut man dem Gerät keine große Robustheit zu. Das Gerät ist auf jeden Fall im Vergleich zum Mitbewerb (D-Link MyPocket, Novalink MiFi) sehr kompakt.

Private Nutzung

Immer wieder liest man Empfehlungen dass man auf keinen Fall private Nutzung der Unternehmens-IT zulassen darf, dass es problematisch ist wenn man persönliche Mails duldet, ja sogar steuerlich schwierig ist, wenn man den Mitarbeitern geldwerte Vorteile (wie einen Internet Zugang) bietet. Auch vor den Sicherheitsaspekten wird gewarnt. Lizenzgründe oder Haftungsgründe werden angeführt. Ich möchte mich hier mal auf die andere Seite stellen: warum haben Arbeitgeber ein Interesse daran, dass Mitarbeiter die Firmen-IT auch für Aktivitäten nutzen die nicht direkt im Geschäftsinteresse stehen. Nun allen voran natürlich die Mitarbeiterzufriedenheit. Gute Mitarbeiter zu halten ist wichtig. Wenn diese ein offenes Klima erleben sind sie viel gewillter zu bleiben. Grade bei Überstunden oder exotischen Arbeitszeiten ist es wichtig nebenbei auch Kontakt mit den Lieben zu halten. Sich mit der Freundin im Messenger auszutauschen damit diese nicht den Arbeiter nach Hause zitiert. Daneben ist jeder Mitarbeiter der sich im Web bewegt auch ein informierter Mitarbeiter. Im Zweifel auch ein Mitarbeiter der für das Unternehmen Werbung macht. Ganz gemäss des (schon öfters genannten) Cluetrain Manifests werden immer mehr Kunden durch direkte Kontakte mit Mitarbeitern auf Produkte aufmerksam. Betrachtet man das Leben eines Consultants (Road Warriors) auf der Straße und in Hotels, so hat dieser gewiss andere Probleme als mehr als einen Notebook mit sich herumzuschleppen. Wird Ihm verwehrt diesen auch zum DVD Genuss einzusetzen, so wird er noch weiter benachteiligt und hat irgendwann kein Interesse mehr auf Außeneinsatz. Die Nutzung von Diensten des Arbeitgebers wie Mail und IM sollte so offen gestaltet sein, dass Mitarbeiter gerne auch nach Feierabend diese Medien nutzen. Ganz im Interesse der Firma: die Mitarbeiter bleiben in Notfällen einfacher ansprechbar. Das surfen am Arbeitsplatz - sei es nun in Wartezeiten oder der Mittagspause ist eine Entspannung vergleichbar mit der Raucherpause oder dem Mittagsspaziergang. Wird die Nutzung des Webs eingeschränkt oder strikt kontrolliert, so suchen sich kreativ arbeitende Köpfe andere Ablenkungen (zum Beispiel sinnlose Meetings). Es ist also nur in Ausnahmefällen so, dass die Produktivität dadurch gesteigert wird. Unmotivierte Mitarbeiter die Zeit haben ihren Tag zu vertrödeln sind eine Herausforderung an das Team oder die Vorgesetzten, aber sicher nicht für die interne-IT.

Piratenthemen

Wie einige meiner Leser sicher schon wissen, oder in der BNN gelesen habe, wurde ich am Samstag den 23.1 als Beisitzer in den Vorstand des Bezirksverbandes Karlsruhe gewählt. Ich möchte hier nur Entwarnung geben, ich habe nicht vor das IT-Blog hier mit Piraten Themen zu füllen. Ich werde mich weiterhin auf IT Themen und politische Themen mit IT Bezug beschränken. Meine Partei-Gedanken und allgemeinen politischen Ansichten werden ein anderes Zuhause finden. Vielleicht wieder eckes.org, aber bis dahin auf jeden Fall bei live.piratenpartei.de.

Vorratsdatenspeicherung vor dem BVerfG

Am Dienstag den 15.12.2009 wird die bisher größte Verfassungsbeschwerde vor dem Bundesverfassungsgericht in Karlsruhe verhandelt. Zu diesem Anlass ist eine Pressekonferenz der Beschwerdeführer geplant. Zudem bereitet der AK Vorratsdatenspeicherung einen News-Room und zwei Infostände vor. Die Piratenpartei ist mit von der Partei und informiert auf den Infoständen die Bürger. Auch zum Thema ELENA Verfahren (eine Art Arbeitnehmervorratsdatenspeicherung) werden die Piraten berichten. Ich werde Vor-Ort sein und beim Aufbau mithelfen