nohostname.de Tech-Stuff

Gerade eben bei StudiVZ/MeinVZ gesehen:

Als Provider zur Auswahl: AOL, GMX, Google, MSN, Web.de und Yahoo. Ich möchte nicht wissen, wieviele Leute da ihre Zugangsdaten angeben… Viel Spaß dabei!

Seit mehreren Monaten, ich glaube sogar Jahren, habe ich keinen Spam mehr erhalten, bei dem es um Microsoft ging. Vor zwei Wochen habe ich mich bei Microsoft registriert, weil ich den RC von Windows 7 testen wollte.
Heute kam dann wieder eine Spam-Mail, die angeblich von Microsoft stammen sollte.
Ob das wirklich Zufall ist?

Grüße!

Wirklich sichere Authentifizierungsverfahren gibt es nicht, klar. Daher versucht man es immer so sicher wie möglich zu halten. Doch bringen die in Online- und Printmedien vorgeschlagenen Methoden wirklich mehr Sicherheit?

Das habe ich mich gefragt, als ich neulich einen Artikel[1] im Linux-Magazin[2] gelesen habe.
Die Rede ist da von Public-Key-Authentifizierung[3] welche “einen deutlich besseren Schutz” bieten soll als “das beste Passwort”.
Ein Passwort habe ich im Kopf und ich gebe es direkt ein. Dabei kann man mir über die Schulter gucken oder einen Keylogger verwenden. Schreibe ich das Passwort irgendwo hin ist das natürlich risikobehaftet.

Eine Public-Key-Authentifizierung dagegen basiert auf 2 Dateien im Homeverzeichnis. Einem privaten und einem öffentlichen Schlüssel. Dem Server wird der öffentliche Schlüssel bekannt gemacht, indem er in die Datei ~/.ssh/authorized_keys geschrieben wird. Das geht sehr komfortabel über das Kommando ssh-copy-id. Mit diesem öffentlichen Schlüssel chiffriert der Server beim Loginversuch nun eine Nachricht an den Client, die dieser nur mit dem zum öffentlichen Schlüssel passenden privaten Schlüssel dechiffrieren kann. Der Client sendet die entschlüsselte Nachricht zurück und damit weiß der Server, dass der Empfänger im Besitz des privaten Schlüssels ist.

Den privaten Schlüssel kann ich zwar mit einem Passwort schützen, das lässt sich aber wesentlich einfacher und unbemerkter knacken als bei der Variante per Bruteforce oder eine Wörterbuchattacke über Loginversuche auf dem Server an das Passwort zu kommen. Und das eigentliche Problem an der Sache ist eben, dass diese beiden Dateien für mich lesbar in meinem Homeverzeichnis liegen. Kriegt jemand diese Datei, dann hat er quasi gewonnen. Und das lässt sich dann auch super zuhause beim Angreifer knacken – da gibt es nirgendwo eine Logdatei, die fehlerhafte Login-Versuche aufzeichnet, so wie es bei dem fehlerhaften Versuch an meinem SSH-Login passiert.
Jetzt mag der ein oder andere sagen, dass die /etc/shadow auch nur eine Datei ist die man, wenn man sie kopiert hat, lokal beim Angreifer bearbeiten kann, aber dazu sind eben in den allermeisten Fällen root-Rechte auf dem Rechner notwendig, auf dem die Datei liegt. Bei meinem privaten Schlüssel in /home/cisa/.ssh/ sieht das anders aus: Eine geeignete Sicherheitslücke in dem Browser meiner Wahl oder irgend einer anderen Software, die einen Zugriff auf meine Dateien via Internet bietet, reicht aus.

Noch größer schätze ich das Problem ein, dass man mit einem privaten Schlüssel meistens Zugriff auf mehrere Systeme hat, während viele (sicherheitsbewusste) Personen für verschiedene Systeme auch verschiedene Passwörter benutzen. Man kann bei einem Login via SSH und Public-Key-Authentifizierung zwar auch einen anderen privaten Schlüssel, der mit einem anderen Passwort geschützt sein kann, angeben (das geht sogar recht komfortabel über die ~/.ssh/config mit IdentityFile, damit man nicht jedes mal die Kommandozeilenoption eintippen muss), doch macht man das wenn man sich erstmal mit dieser Methode in Sicherheit wiegt?

Jetzt bin ich natürlich super gespannt auf die Meinung meiner Leser. Also husch husch einen oder mehrere Kommentare oder Blog-Einträge verfassen. E-Mails sind natürlich auch OK.

[1] Linux-Magazin, Ausgabe 08/09, S. 90 “Grundlagen: Sichere Remote-Logins”
[2] http://www.linux-magazin.de/Heft-Abo/Ausgaben/2009/08
[3] http://de.wikipedia.org/wiki/Public-Key-Authentifizierung

Hi,

ich habe vor kurzem aus 2 defekten Notebooks ein funktionierendes gemacht. Dabei hat sicher herausgestellt das das bei Ebay ersteigerte Gerät, was laut Verkäufer ein Mainboard defekt haben sollte, nur einen schief sitzenden RAM Riegel hatte.
Was macht man jetzt mit Notebook ohne Display ? Einen Fileserver!

Der Plan:

2 externe USB Platten im Software RAID 1 auf denen das System und die Daten liegen.

Das Problem:

Wenn beide USB Laufwerke eingesteckt sind bootet das Notebook nicht! Es liegt wohl irgendwie am BIOS, jedenfalls hängt er beim “Detecting Hard Drives”.

Die Lösung:

Da ich schon immer gerne gebastelt habe, war die Lösung ja ganz einfach .
Booten werde ich über SD Karte.
Die Festplatten sollen immer angeschlossen sein, deshalb werde ich am parallel Port ein Relais betreiben welches per Software gesteuert wird.

Der Plan B:

Notebook bootet per SD Karte.
Nach dem Boot startet ein Script die Festplatten per Parallelport -Relais, mountet diese und macht dort ein Swap.

Ok, soviel zum Plan B .
Quellcodes und Bilder kommen wenn das ganze Lauffähig ist. (Sonntag , ich glaube fest daran)

Hallo zusammen,

ich mache nun ein Upgrade von etch auf lenny. Kann sein, dass einige Dienste kurz nicht erreichbar sind.

Bitte beten.

UPDATE: Der Reboot ist nun durch – alle Dienste wurden anscheinend gestartet und Mails gehen raus. Löppt.

Ich habe mich gestern 2 1/2 Stunden mit einem ziemlich verrückten Bug rumgeärgert. Die Aufgabe war: Emuliere einen Browser und lade mit Curl eine Datei per HTTP hoch. Super einfach eigentlich, wenn man nicht gerade Lighttpd einsetzt

Curl greift wunderbar auf Lighty zu, bis man ein Feld per Post zu übermitteln versucht. Denn dann passiert folgendes:

user@host:~> curl -v -F "test=test" http://example.com/upload.php
* About to connect() to example.com port 80 (#0)
*   Trying 127.0.0.1... connected
* Connected to example.com (127.0.0.1) port 80 (#0)
> POST /upload.php HTTP/1.1
> User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
> Host: example.com
> Accept: */*
> Content-Length: 143
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=----------------------------65ad699c79c1
>
< HTTP/1.1 417 Expectation Failed
< Connection: close
< Content-Length: 0
< Date: Thu, 11 Jun 2009 08:40:02 GMT
< Server: lighttpd/1.4.19
<
* Closing connection #0

Curl sendet den Header Expect: 100-continue und Lighty sendet HTTP/1.1 417 Expectation Failed zurück. Das mag Curl garnicht und hört einfach auf. Um den HTTP-Header Expect von Curl zu unterdrücken, gibt man als Option noch -H "Expect: " an. Die Kommandozeile sieht dann so aus:

curl -v -H "Expect: " -F "test=test" http://example.com/upload.php

$uploadfile="test.pdf";
$ch = curl_init("http://example.com/upload.php");

//curl_setopt($ch, CURLOPT_VERBOSE, 1);
//curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, Array('Expect: '));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);

curl_setopt($ch, CURLOPT_POSTFIELDS,
    array(  'datei'=>"@$uploadfile",
            'feld1'=>'test',
            'feld2'=>'test',
    )
);

$postResult = curl_exec($ch);
curl_close($ch);
print $postResult;