Vor ein paar Wochen wurden ja auf mehreren Webseiten in erheblichen Ausmaß Passwörter entwendet. Betroffen waren unter anderem Linkedin und last.fm.
Das sollte man zum Anlass nehmen, sofort seine Passwörter bei diesen Diensten zu ändern. Leider erfährt man auf den Webseiten selber gar nichts von dem Vorfall und wie man darauf reagieren soll. Wenigstens gibt es eine Mitteilungsseite (last.fm, LinkedIn), nur verharmlosen diese den Vorfall und man findet man diese auch nicht auf der Startseite. Mittlerweile hat zumindest last.fm reagiert und E-Mails mit der Aufforderung dass Passwort zu ändern an seine Mitglieder verschickt. Man hätte aber gleich nach dem Vorfall reagieren müssen ohne dass man seine Mitglieder 2 Wochen (oder war es eher 1 Jahr?) in falscher Sicherheit wiegt.
Bei last.fm sollen ja angeblich 17 Millionen Passwörter abhanden gekommen sein (vermutlich bereits letztes Jahr) und bei LinkedIn auch 6.5 Millionen. Das ist ja immerhin mal eine Ansage. Es wäre aber eigentlich mal an der Zeit, dass diese Dienste genauso professionell reagieren, wie sie uns immer glauben lassen.
Entries tagged as security
Related tags
Saturday, 23. June 2012
Passwortleck bei last.fm und Linkedin
Tuesday, 12. January 2010
Sicheres Löschen eines Datenträgers
Möchte man einen PC verschrotten oder muß man mal die Festplatte zur Reparatur schicken (RMA) oder auch verkaufen, dann sollte man dafür sorgen, dass eventuell vorhandene Daten möglichst sicher gelöscht werden. Es gab bereits Fälle, wo Daten auf bei Ebay ersteigerten Festplatten gefunden wurden.
Denn man möchte vermutlich weder, dass irgendwelche geschäftlichen Daten Fremden in die Hände kommen, noch wird man scharf drauf sein, die privaten Bilder von Tante Erna aus ihrem Urlaub in Hinterzupfingen anderen Menschen zu präsentieren.
Dabei geht es nicht um sensible private Daten wie Lebensläufe, Bankdaten, Kontoauszüge oder wichtige geschäftliche Daten, nein vielmehr geht es um alle vorhandenen Daten, bzw. auch vermeintlich schon gelöschte Daten. Gelöscht heißt nämlich, dass das Betriebssystem nur den Verweis auf die Daten löscht bzw. den Bereich intern als leer markiert, so dass dort neue Daten gespeichert werden können.
Diese Daten sind nicht umsonst privater Natur und genau das sollen sie auch bleiben. Das heißt nicht, dass man etwas zu verstecken hat, denn schließlich laufen wir ja auch alle nicht grundlos mit Kleidung rum.
Nach gängiger Meinung genügt zum sicheren Löschen das Überschreiben der kompletten Festplatte mit einem Zufallsmuster. Gerüchte, wonach selbst überschriebene Daten aus "Restmagnetspuren" der Spurränder von Festplatten wiederhergestellt werden konnten, gehören wohl ins Reich der Verschwörungstheorien und scheinen nur Spekulationen zu sein. (Update: Ein entsprechender Artikel von Peter Gutmann, beschreibt daher eine Methodik zum sicheren Löschen von Daten durch mehrmaliges Überschreiben mit unterschiedlichen Bitmustern. Zu beachten ist aber, dass dieser Artikel von 1996 stammt und wohl mittlerweile durch die vergrößerte Speicherdichte heutzutage nicht mehr allgemein gültig ist. Es stellt sich sogar die Frage, ob einfaches Überschreiben durch Nullen nicht sogar eine ausreichende Sicherheit beim Überschreiben verspricht.)
Um das zu erreichen, genügt bei einer gängigen Linuxdistribution der dd Befehl. Damit kann man sehr einfach Daten auf die Festplatte schreiben. Die gängige Empfehlung ist dabei, dd if=/dev/urandom of=/dev/sda bs=1M auszuführen. Damit liest man aus dem Pseudo-Zufallspool des Systems und schreibt die Daten als 1 MB große Blöche auf das Gerät /dev/sda. Das ist grundsätzlich auch ok, das einzige Problem, was man dabei hat ist, dass der Zufallspool normalerweise nicht sehr gut gefüllt ist und nur relativ langsam gelesen werden kann.
Bei heutigen Festplattengenerationen mit mehreren hundert Gigabyte Speicher, kann da schon einmal ein Nacht für das Überschreiben drauf gehen (oder vielleicht sogar mehr, ich habe das noch nicht so genau getestet).
Schneller und äquivalent sicher ist es dagegen, die Festplatte mit Nullen zu beschreiben, die danach verschlüsselt werden. Dazu kann man cryptsetup verwenden, was mittlerweile wohl bei allen modernen Linux Distributionen dabei sein sollte:
Hier legt man eine logische Blockschicht über dem Gerät /dev/sda an, dass mit einem Zufallsschlüssel, der aus dem Zufallspool /dev/random kommt, verschlüsselt wird. Alles was auf dem neuen Blockschicht /dev/mapper/sda geschrieben wird, wird intern verschlüsselt auf das eigentliche Gerät /dev/sda geschrieben. Der Schlüssel ist eigentlich egal, er wird im Prinzip nur genutzt, um ein zufälliges Bitmuster aus den Nullen zu generieren und zu schreiben.
Damit braucht das System nicht auf den langsamen Zufalls-Entropiepool zu warten (es muß nämlich von dort nur zur Erstellung des Schlüssels einmalig 256bit lesen), sondern kann sehr schnell lesen die Nullen lesen. Durch die Verschlüsselung verlangsamt sich die Schreibgeschwindigkeit zwar, ist aber dennoch größer als bei der vorherigen Methode. In Zeiten immer schnellerer CPUs (zumindest in Desktop System) fällt der Geschwindigkeitsverlust wahrscheinlich immer geringer aus und wer von Anfang an ein verschlüsseltes Gesamtsystem verwendet, der wird gar keine Geschwindigkeitseinbußen bemerken.
Getestet habe ich das Ganze auch mal mit einer leeren 10GB Partition:
Wie man sieht, habe ich hier eine durchschnittliche Schreibgeschwindigkeit von 5,9MB/s mittels der traditionellen Methode erhalten. Durch das Verschlüsseln, konnte die Schreibgeschwindigkeit fast verneunfacht werden. Noch drastischer sind die absoluten Zeiten: fast 30 Minuten anstelle von 3,5 Minuten.
Das ist natürlich kein Benchmark, sondern soll nur zeigen, welch drastischen Unterschiede zwischen den Methoden existieren. Spielen kann man eventuell noch mit dem Blocksize Parameter, der in diesem Beispiel auf 1 Megabyte gesetzt war. Es ist nicht auszuschließen, dass es mit einem anderen Verschlüsselungsalgorithmus (hier aes-xts-plain) sogar noch schneller geht. (einfahcer Benchmark verschiedener Verschlüsselungsalgorithmen und noch ein Benchmark, ausführlicher)
Disclaimer: Unbedingt zweimal prüfen, auf welches Gerät man schreibt, bevor man sich sein System zerschießt. Dieses Gerät sollte auch nicht anderweitig parallel verwendet werden, sonst besteht die Gefahr, dass noch etwaige Daten nicht überschrieben werden konnten, weil sie noch geöffnet waren.
Denn man möchte vermutlich weder, dass irgendwelche geschäftlichen Daten Fremden in die Hände kommen, noch wird man scharf drauf sein, die privaten Bilder von Tante Erna aus ihrem Urlaub in Hinterzupfingen anderen Menschen zu präsentieren.
Dabei geht es nicht um sensible private Daten wie Lebensläufe, Bankdaten, Kontoauszüge oder wichtige geschäftliche Daten, nein vielmehr geht es um alle vorhandenen Daten, bzw. auch vermeintlich schon gelöschte Daten. Gelöscht heißt nämlich, dass das Betriebssystem nur den Verweis auf die Daten löscht bzw. den Bereich intern als leer markiert, so dass dort neue Daten gespeichert werden können.
Diese Daten sind nicht umsonst privater Natur und genau das sollen sie auch bleiben. Das heißt nicht, dass man etwas zu verstecken hat, denn schließlich laufen wir ja auch alle nicht grundlos mit Kleidung rum.
Nach gängiger Meinung genügt zum sicheren Löschen das Überschreiben der kompletten Festplatte mit einem Zufallsmuster. Gerüchte, wonach selbst überschriebene Daten aus "Restmagnetspuren" der Spurränder von Festplatten wiederhergestellt werden konnten, gehören wohl ins Reich der Verschwörungstheorien und scheinen nur Spekulationen zu sein. (Update: Ein entsprechender Artikel von Peter Gutmann, beschreibt daher eine Methodik zum sicheren Löschen von Daten durch mehrmaliges Überschreiben mit unterschiedlichen Bitmustern. Zu beachten ist aber, dass dieser Artikel von 1996 stammt und wohl mittlerweile durch die vergrößerte Speicherdichte heutzutage nicht mehr allgemein gültig ist. Es stellt sich sogar die Frage, ob einfaches Überschreiben durch Nullen nicht sogar eine ausreichende Sicherheit beim Überschreiben verspricht.)
Um das zu erreichen, genügt bei einer gängigen Linuxdistribution der dd Befehl. Damit kann man sehr einfach Daten auf die Festplatte schreiben. Die gängige Empfehlung ist dabei, dd if=/dev/urandom of=/dev/sda bs=1M auszuführen. Damit liest man aus dem Pseudo-Zufallspool des Systems und schreibt die Daten als 1 MB große Blöche auf das Gerät /dev/sda. Das ist grundsätzlich auch ok, das einzige Problem, was man dabei hat ist, dass der Zufallspool normalerweise nicht sehr gut gefüllt ist und nur relativ langsam gelesen werden kann.
Bei heutigen Festplattengenerationen mit mehreren hundert Gigabyte Speicher, kann da schon einmal ein Nacht für das Überschreiben drauf gehen (oder vielleicht sogar mehr, ich habe das noch nicht so genau getestet).
Schneller und äquivalent sicher ist es dagegen, die Festplatte mit Nullen zu beschreiben, die danach verschlüsselt werden. Dazu kann man cryptsetup verwenden, was mittlerweile wohl bei allen modernen Linux Distributionen dabei sein sollte:
CODE:
# cryptsetup -d /dev/random -c aes-xts-plain create sda /dev/sda
# dd if=/dev/zero of=/dev/mapper/sda bs=1M
# cryptsetup remove sda
Hier legt man eine logische Blockschicht über dem Gerät /dev/sda an, dass mit einem Zufallsschlüssel, der aus dem Zufallspool /dev/random kommt, verschlüsselt wird. Alles was auf dem neuen Blockschicht /dev/mapper/sda geschrieben wird, wird intern verschlüsselt auf das eigentliche Gerät /dev/sda geschrieben. Der Schlüssel ist eigentlich egal, er wird im Prinzip nur genutzt, um ein zufälliges Bitmuster aus den Nullen zu generieren und zu schreiben.
Damit braucht das System nicht auf den langsamen Zufalls-Entropiepool zu warten (es muß nämlich von dort nur zur Erstellung des Schlüssels einmalig 256bit lesen), sondern kann sehr schnell lesen die Nullen lesen. Durch die Verschlüsselung verlangsamt sich die Schreibgeschwindigkeit zwar, ist aber dennoch größer als bei der vorherigen Methode. In Zeiten immer schnellerer CPUs (zumindest in Desktop System) fällt der Geschwindigkeitsverlust wahrscheinlich immer geringer aus und wer von Anfang an ein verschlüsseltes Gesamtsystem verwendet, der wird gar keine Geschwindigkeitseinbußen bemerken.
Getestet habe ich das Ganze auch mal mit einer leeren 10GB Partition:
CODE:
chrisbra@ubuntu:/temp$ dd if=/dev/zero of=big_file bs=10M count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
10485760000 Bytes (10 GB) kopiert, 228,142 s, 46,0 MB/s
root@ubuntu:/temp# losetup /dev/loop2 big_file
root@ubuntu:/temp# time dd if=/dev/urandom of=/dev/loop2 bs=1M
dd: Schreiben von „/dev/loop2“: No space left on device
10000+1 Datensätze ein
9999+1 Datensätze aus
10485760000 Bytes (10 GB) kopiert, 1786,48 s, 5,9 MB/s
real 29m46.537s
user 0m0.050s
sys 25m36.450s
root@ubuntu:/temp#
root@ubuntu:/temp# cryptsetup -d /dev/random -c aes-xts-plain create loop /dev/loop2
root@ubuntu:/temp# time dd if=/dev/zero of=/dev/mapper/loop bs=1M
dd: Schreiben von „/dev/mapper/loop“: No space left on device
10001+0 Datensätze ein
10000+0 Datensätze aus
10485760000 Bytes (10 GB) kopiert, 205,879 s, 50,9 MB/s
real 3m25.885s
user 0m0.000s
sys 0m12.290s
Wie man sieht, habe ich hier eine durchschnittliche Schreibgeschwindigkeit von 5,9MB/s mittels der traditionellen Methode erhalten. Durch das Verschlüsseln, konnte die Schreibgeschwindigkeit fast verneunfacht werden. Noch drastischer sind die absoluten Zeiten: fast 30 Minuten anstelle von 3,5 Minuten.
Das ist natürlich kein Benchmark, sondern soll nur zeigen, welch drastischen Unterschiede zwischen den Methoden existieren. Spielen kann man eventuell noch mit dem Blocksize Parameter, der in diesem Beispiel auf 1 Megabyte gesetzt war. Es ist nicht auszuschließen, dass es mit einem anderen Verschlüsselungsalgorithmus (hier aes-xts-plain) sogar noch schneller geht. (einfahcer Benchmark verschiedener Verschlüsselungsalgorithmen und noch ein Benchmark, ausführlicher)
Disclaimer: Unbedingt zweimal prüfen, auf welches Gerät man schreibt, bevor man sich sein System zerschießt. Dieses Gerät sollte auch nicht anderweitig parallel verwendet werden, sonst besteht die Gefahr, dass noch etwaige Daten nicht überschrieben werden konnten, weil sie noch geöffnet waren.
Wednesday, 29. July 2009
Vergessenes Passwort
Mir ist letztens was blödes passiert. Es war mal wieder an der Zeit, mein Login Passwort meines Dienst-PCs zu ändern (90 Tage waren schon wieder um...)
Nun ja, also habe ich mir natürlich ein komplexes und sehr langes Passwort ausgedacht. Richtig lang und schwierig zu merken. Dummerweise hatte ich es 10 Minuten später doch wieder vergessen.
Egal was ich tat, Windows ließ mich nicht mehr rein. Normalerweise hilft eine kurze Gedenkminute, aber das brachte diesmal nichts. Ganz kurz fing ich an zu schwitzen, ich sah mich schon zum Support rennen, meinen Rechner geplättet und ein neues Image draufgezogen und damit alle meine Daten weg.
Doch dann fiel mir ein, dass ich ja noch ein zweites Betriebssystem auf dem Laptop habe, in diesem Fall Ubuntu 9.04 installiert durch den Wubi-Installer. Somit hatte ich von da aus zumindest Zugriff auf meine Daten und hätte sie wenigstens noch retten können, bevor ich zum Support laufe und nen halben Tag abschreiben kann. Irgendwann fiel mir zum Glück noch ein, kurz mal zu googeln, ob es nicht von Linux aus eine Möglichkeit gäbe, das Passwort zurückzusetzen. Und tatsächlich, es gibt sie. Und zwar in Form von chntpw.
Also schnell per apt-get installiert, kurz die Doku gelesen und losgelegt (gute Anleitung übrigens):
Funktioniert natürlich nicht, wie es im Netz steht. Super. Immer dann, wenn man sowas ganz dringend braucht, ist die Software borken. Ich fing wieder an zu schwitzen... Nochmal nach der Fehlermeldung gegoogelt und ich fand den folgenden Bug: Launchpad: 293809. Scheint, als wäre chntpw auf x86_64 kaputt. Dabei habe ich nichtmal absichtlich die 64bit Version von Ubuntu installiert. Das hat der Installer von alleine gemacht, ohne mich zu fragen!!!1ELF
Als nächstes versuchte ich dann mit den verschiedenen Images, die auf der Upstream Homepage bereitgestellt werden, einen USB-Stick bootfähig zu machen. Einen Rohling hatte ich nämlich nicht und ein Floppy Drive gibt es nicht mehr am Laptop (Überraschung!). Ging aber nicht, warum auch immer. Also doch zum Support rennen.
Aber halt, im Source, gibt es eine statisch kompilierte Version. Und das war die große Überraschung. Einfach das Source Paket von Upstream runterladen und mit chntpw.static arbeiten. Das funktioniert!
5 Minuten später hatte ich wieder einen funktionierenden Login bei Windows. Und das neue Passwort ist zwar auch wieder kompliziert, aber das kann ich mir merken.
Nun ja, also habe ich mir natürlich ein komplexes und sehr langes Passwort ausgedacht. Richtig lang und schwierig zu merken. Dummerweise hatte ich es 10 Minuten später doch wieder vergessen.
Egal was ich tat, Windows ließ mich nicht mehr rein. Normalerweise hilft eine kurze Gedenkminute, aber das brachte diesmal nichts. Ganz kurz fing ich an zu schwitzen, ich sah mich schon zum Support rennen, meinen Rechner geplättet und ein neues Image draufgezogen und damit alle meine Daten weg.
Doch dann fiel mir ein, dass ich ja noch ein zweites Betriebssystem auf dem Laptop habe, in diesem Fall Ubuntu 9.04 installiert durch den Wubi-Installer. Somit hatte ich von da aus zumindest Zugriff auf meine Daten und hätte sie wenigstens noch retten können, bevor ich zum Support laufe und nen halben Tag abschreiben kann. Irgendwann fiel mir zum Glück noch ein, kurz mal zu googeln, ob es nicht von Linux aus eine Möglichkeit gäbe, das Passwort zurückzusetzen. Und tatsächlich, es gibt sie. Und zwar in Form von chntpw.
Also schnell per apt-get installiert, kurz die Doku gelesen und losgelegt (gute Anleitung übrigens):
CODE:
~$ sudo chntpw -i SAM SECURITY system
chntpw version 0.99..., (c) Petter N Hagen
openHive(software): File does not seem to be a registry hive!
Simple registry editor. ? for help.
Funktioniert natürlich nicht, wie es im Netz steht. Super. Immer dann, wenn man sowas ganz dringend braucht, ist die Software borken. Ich fing wieder an zu schwitzen... Nochmal nach der Fehlermeldung gegoogelt und ich fand den folgenden Bug: Launchpad: 293809. Scheint, als wäre chntpw auf x86_64 kaputt. Dabei habe ich nichtmal absichtlich die 64bit Version von Ubuntu installiert. Das hat der Installer von alleine gemacht, ohne mich zu fragen!!!1ELF
Als nächstes versuchte ich dann mit den verschiedenen Images, die auf der Upstream Homepage bereitgestellt werden, einen USB-Stick bootfähig zu machen. Einen Rohling hatte ich nämlich nicht und ein Floppy Drive gibt es nicht mehr am Laptop (Überraschung!). Ging aber nicht, warum auch immer. Also doch zum Support rennen.
Aber halt, im Source, gibt es eine statisch kompilierte Version. Und das war die große Überraschung. Einfach das Source Paket von Upstream runterladen und mit chntpw.static arbeiten. Das funktioniert!
5 Minuten später hatte ich wieder einen funktionierenden Login bei Windows. Und das neue Passwort ist zwar auch wieder kompliziert, aber das kann ich mir merken.
Monday, 27. April 2009
Fetchmail SSL-Fingerprint erneuern
Gmx hat mal wieder sein SSL-Zertifikat erneuert. Man sieht das schön in den Logs von fetchmail:
Man muß dazu sagen, dass ich fetchmail mit der folgenden Konfiguration aufrufe:
(Nein, das Passwort ist nicht passwort und die E-Mail Adresse ist auch nicht user@gmx.de ;))
In dieser Konfiguration überprüft fetchmail den angegebenen SSL Fingerprint (Option sslfingerprint) gegen den Fingerprint des Zertifikats, dass der Server angibt und wenn der Fingerprint nicht stimmt, dann gibt es eben obige Fehlermeldung. Zusätzlich wird mit der Option sslcertck überprüft, ob das Zertifikat (direkt oder indirekt) vertrauenswürdig ist. GMX verwendet zum Beispiel ein Zertifikat das von Thawte ausgestellt ist. Wenn man das Paket ca-certificates installiert, bekommt man unter anderem das Thawte Root-Zertifikat installiert und das System betrachtet diese Zertifikate als vertrauenswürdig. Der generische, manuelle Weg diese Zertifikate zu erhalten ist für Thawte hier beschrieben.
Zurück zu der obigen Fehlermeldung. Die sieht verdächtig nach einem erneuerten Zertifikat aus. Glücklicherweise kann man das recht einfach prüfen und damit ich mir die passenden Optionen nicht jedesmal aus der Manpage raussuchen muß, hier die Schrittfolge in Kurzform:
In Langform: Zunächst bauen wir uns eine verschlüsselte Verbindung zu pop.gmx.net auf. Da sieht man z.B. welches Zertifikat der Server dem Client präsentiert. Dieses Zertifikat kann man sich dann auch in Textform ausgeben lassen (openssl x509 -text) oder wie hier nur die wichtigsten Daten anzeigen. Das sind hier Gültigkeitszeitraum und der md5-Fingerprint. (Denn fetchmail erwartet einen md5-Fingerprint bei der Option sslfingerprint. Wie man sieht, gab es heute morgen ein neues Zertifikat und dessen Fingerprint muß nun fetchmail bekannt gemacht werden. Also neuen Fingerprint in die .fetchmailrc eingetragen und schon funktioniert die verschlüsselte Kommunikation wieder:
Ach ja, und spätestens am 10. Mai 2010 wird es wieder ein neues Zertifikat geben.
CODE:
fetchmail: pop.gmx.net fingerprints do not match!
13589:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:951:
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from ...@gmx.de@pop.gmx.net
fetchmail: Query status=2 (SOCKET)
Man muß dazu sagen, dass ich fetchmail mit der folgenden Konfiguration aufrufe:
CODE:
poll pop.gmx.net proto POP3 timeout 30 uidl
user "user@gmx.de" password "passwort" is "user" ssl
sslproto tls1 sslcertpath /etc/ssl/certs sslfingerprint
"BA:03:AC:50:A9:A0:C7:AF:1E:79:3A:B7:C0:E7:19:5E" sslcertck keep
(Nein, das Passwort ist nicht passwort und die E-Mail Adresse ist auch nicht user@gmx.de ;))
In dieser Konfiguration überprüft fetchmail den angegebenen SSL Fingerprint (Option sslfingerprint) gegen den Fingerprint des Zertifikats, dass der Server angibt und wenn der Fingerprint nicht stimmt, dann gibt es eben obige Fehlermeldung. Zusätzlich wird mit der Option sslcertck überprüft, ob das Zertifikat (direkt oder indirekt) vertrauenswürdig ist. GMX verwendet zum Beispiel ein Zertifikat das von Thawte ausgestellt ist. Wenn man das Paket ca-certificates installiert, bekommt man unter anderem das Thawte Root-Zertifikat installiert und das System betrachtet diese Zertifikate als vertrauenswürdig. Der generische, manuelle Weg diese Zertifikate zu erhalten ist für Thawte hier beschrieben.
Zurück zu der obigen Fehlermeldung. Die sieht verdächtig nach einem erneuerten Zertifikat aus. Glücklicherweise kann man das recht einfach prüfen und damit ich mir die passenden Optionen nicht jedesmal aus der Manpage raussuchen muß, hier die Schrittfolge in Kurzform:
CODE:
chrisbra@256bit:~$ openssl s_client -connect pop.gmx.net:995 -tls1 </dev/null 2>/dev/null |sed -n /BEGIN/,/END/p | openssl x509 -dates -fingerprint -md5 -noout
notBefore=Apr 27 08:51:09 2009 GMT
notAfter=May 10 07:06:14 2010 GMT
MD5 Fingerprint=92:C8:49:13:3A:55:D6:57:37:5F:0F:12:83:39:CE:06
In Langform: Zunächst bauen wir uns eine verschlüsselte Verbindung zu pop.gmx.net auf. Da sieht man z.B. welches Zertifikat der Server dem Client präsentiert. Dieses Zertifikat kann man sich dann auch in Textform ausgeben lassen (openssl x509 -text
CODE:
fetchmail --verbose pop.gmx.net
fetchmail: 6.3.9-rc2 fragt pop.gmx.net ab (Protokoll POP3) um Mo 27 Apr 2009 21:43:53 CEST: Abfrage gestartet
Versuche, mit 213.165.64.22/995 zu verbinden...verbunden.
fetchmail: Herausgeber-Organisation: Thawte Consulting cc
fetchmail: Herausgeber-CommonName: Thawte Premium Server CA
fetchmail: Server-CommonName: pop.gmx.net
fetchmail: pop.gmx.net-Schlüssel-Fingerabdruck: 92:C8:49:13:3A:55:D6:57:37:5F:0F:12:83:39:CE:06
fetchmail: pop.gmx.net-Fingerabdrücke stimmen überein.
fetchmail: POP3< +OK GMX POP3 StreamProxy ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< STLS
....
Ach ja, und spätestens am 10. Mai 2010 wird es wieder ein neues Zertifikat geben.
Sunday, 4. May 2008
Alternative zu Siteminder ?
Welcher Admin kennt das nicht ? Man hat einen Stall von Webapplikationen und würde gerne die dazu gehörigen User nicht
nur zentral verwalten (z.B. mit einem LDAP Server), sondern auch eine applikations- bzw. serverübergreifend authentifizieren.
Das hat nicht nur den Vorteil das sich ein User nur einmal für alle Applikationen einloggen muss, sondern vermeidet auch
das Passwörter über alle beteiligen Server fließen.
Single Sign On (SSO) - manche große Konzerne setzen dafür ziemlich propietäre Software wie z.B. Siteminder - ein Produkt, das wie ich gehört habe wohl seit Jahren total verbugged ist, vom Hersteller auch mit teuren Supportverträgen nur schlecht supported wird, mit Linux-Systemen (besonders 64 Bit) nur schlecht harmoniert und sehr übel zu administrieren ist.
Heute bin ich zufällig bei Freshmeat über "mod_auth_pubtkt" gestolpert - möglicherweise eine leichtgewichtige Alternative zu den "Enterprise Lösungen"
Kennt das jemand, kann man damit was anfangen ?
Welche Erfahrungen habt ihr damit ?
Wenn ich mal wieder etwas Zeit habe, werde ich mir das mal anschauen...
nur zentral verwalten (z.B. mit einem LDAP Server), sondern auch eine applikations- bzw. serverübergreifend authentifizieren.
Das hat nicht nur den Vorteil das sich ein User nur einmal für alle Applikationen einloggen muss, sondern vermeidet auch
das Passwörter über alle beteiligen Server fließen.
Single Sign On (SSO) - manche große Konzerne setzen dafür ziemlich propietäre Software wie z.B. Siteminder - ein Produkt, das wie ich gehört habe wohl seit Jahren total verbugged ist, vom Hersteller auch mit teuren Supportverträgen nur schlecht supported wird, mit Linux-Systemen (besonders 64 Bit) nur schlecht harmoniert und sehr übel zu administrieren ist.
Heute bin ich zufällig bei Freshmeat über "mod_auth_pubtkt" gestolpert - möglicherweise eine leichtgewichtige Alternative zu den "Enterprise Lösungen"
mod_auth_pubtkt is an Apache module that authenticates a user based on a cookie with a ticket that has been issued by a central login server and digitally signed using either RSA or DSA. This means that only the trusted login server has the private key required to generate tickets, while web servers only need the corresponding public key to verify them.
Whenever mod_auth_pubtkt encounters a request without a valid ticket/cookie, it redirects the user to a pre-configured login URL, passing the originally requested URL as a GET parameter. The login server can then prompt the user for credentials, verify them using any authentication backend it chooses, and upon success, generate a login ticket (signed with its private key), return it in a cookie to the client, and finally redirect the user back to the originally requested URL.
Tickets may contain a list of "tokens", and each resource (directory etc.) can be made to require a specific token, thus giving a simple but effective form of authorization (the login server can assign different tokens to different users, e.g. based on group membership).
If the cookie is scoped to the entire domain, all web servers with mod_auth_pubtkt in the domain and configured with the same public key will accept the ticket and not require any further authentication from the client until the ticket expires.
Note that a rogue server could steal a valid ticket provided by a client (or it could be sniffed by an adversary if using plain HTTP); however, the client IP address can be included in the ticket, making it harder for other people to use.
Kennt das jemand, kann man damit was anfangen ?
Welche Erfahrungen habt ihr damit ?
Wenn ich mal wieder etwas Zeit habe, werde ich mir das mal anschauen...
Wednesday, 19. March 2008
Sofort-Überweisung?
Äh, ich bin Web2.0 mäßig nicht so recht auf dem Laufenden, aber sofort-überweisung.de scheint ja lustig zu sein.
Dabei handelt es sich um einen Online-Dienst, über den man seine Überweisungen abwickeln kann. Das heißt, wenn man bei einem Referenz-Onlineshop einkauft (siehe Referenzen), dann wählt man als Zahlungsmethode sofort-überweisung aus und muß dann auf der Webseite von Sofort-Überweisung nur noch seine eigenen Bankdaten angeben. Also Bankleitzahl, Kontonummer, PIN und natürlich TAN.
Anstatt also meine wichtigsten Bankdaten nur in meiner bekannten, gesicherten Onlinebanking - Session einzugeben, soll ich sie anstatt dessen auf einem wildfremden Server in ein wildfremdes Formular eintippen.
Ja wohl, richtig für mich als Kunden gibt es keinen zusätzlichen Komfort und nur zusätzlicher Unsicherheit. Das richt geradezu nach Phishing im Zusammenhang mit Cross-Site Scripting.
Dabei sollte man doch mittlerweile wirklich die Sicherheitshinweise beachten, die seit Jahr und Tag kommuniziert werden.
Oder kurz: Nie, wirklich NIE seine Bankdaten nicht vertrauenswürdigen Portalen/Webseiten oder Formularen anvertrauen. Und zwar auch dann nicht, wenn die Seite bekannt aussieht.
Weiter Infos drüben im Netplanet blog und bei der Verbraucherzentrale Sachsen
Dabei handelt es sich um einen Online-Dienst, über den man seine Überweisungen abwickeln kann. Das heißt, wenn man bei einem Referenz-Onlineshop einkauft (siehe Referenzen), dann wählt man als Zahlungsmethode sofort-überweisung aus und muß dann auf der Webseite von Sofort-Überweisung nur noch seine eigenen Bankdaten angeben. Also Bankleitzahl, Kontonummer, PIN und natürlich TAN.
Anstatt also meine wichtigsten Bankdaten nur in meiner bekannten, gesicherten Onlinebanking - Session einzugeben, soll ich sie anstatt dessen auf einem wildfremden Server in ein wildfremdes Formular eintippen.
Ja wohl, richtig für mich als Kunden gibt es keinen zusätzlichen Komfort und nur zusätzlicher Unsicherheit. Das richt geradezu nach Phishing im Zusammenhang mit Cross-Site Scripting.
Dabei sollte man doch mittlerweile wirklich die Sicherheitshinweise beachten, die seit Jahr und Tag kommuniziert werden.
Oder kurz: Nie, wirklich NIE seine Bankdaten nicht vertrauenswürdigen Portalen/Webseiten oder Formularen anvertrauen. Und zwar auch dann nicht, wenn die Seite bekannt aussieht.
Weiter Infos drüben im Netplanet blog und bei der Verbraucherzentrale Sachsen
Saturday, 10. November 2007
SSH keys mit single sign on
Jetzt habe ich bereits beschrieben, wie ssh keys generiert werden, wie man diese ssh keys mit putty benutzen kann und wie man sich die die Entschlüsselung der SSH Schlüssel vereinfachen kann.
Jetzt beschreibe ich, wie mit Single-Sign on bereits beim Einloggen die SSH Schlüssel entschlüsselt werden können.
Zunächst installiert man das Paket libpam-ssh. Dieses Pam-Paket (Die Möglichkeiten von PAM würden den Rahmen dieses Artikels sprengen) ermöglicht es, bereits bei der Anmeldung am System die SSH-Schlüssel zu entschlüsseln und den ssh-agent zu starten. Dafür stellt es die beiden Module pam-ssh-auth (Authentifizierung anhand des ssh-keys) und pam-ssh-session (Start des SSH Agents sowie Laden der Schlüssel) zur Verfügung.
Nach der Installation muß man dann das System so konfigurieren, dass bei bestimmten Aktionen die beiden Module geladen werden. Möchte man z.B. beim Einloggen auf einer Konsole, dass die vorhandenen Schlüssel geladen werden, dann sollte man diese beiden Module in die Datei /etc/pam.d/login (Für den Loginzugriff bei Debian System verantwortlich) hinzufügen. Beim Start des grafischen Loginmanagers ist dann die Datei /etc/pam.d/gdm bzw, kdm, wdm oder xdm für den jeweiligen Loginmanager zuständig. Weitere Module könnten angepasst werden (z.B. ssh für den Login per ssh) In diesen Scripten steht im Prinzip in welcher Reihenfolge bestimmte Pam Module geladen werden sollen
Nun wird in vielen Howtos und Anleitungen empfohlen das Modul pam-ssh-auth vor dem Modul common-auth zu laden. Der Effekt der dadurch erzielt wird, ist, dass man beim Login dann grundsätzlich sein SSH Schlüssel Passwort eingeben muß und nicht sein Standard Unix Passwort. Wer das möchte, der kann das gerne machen, ich finde das nicht so schön, v.a. weil es mich nervt, wenn ich mich als User einlogge, der gar keine SSH Schlüssel besitzt.
Es ist aber auch möglich, sich mit seinem Unix Passwort anzumelden und dennoch die SSH Schlüssel zu laden, vorausgesetzt, die beiden Passwörter stimmen überein. Prinzipiell sollte es auch möglich sein, wenn das Passwort anders ist, denn über den Parameter try_first_pass sollte pam-ssh in der Lage sein, bei einem nicht passenden Passwort extra nachzufragen. Das tut er aber hier nicht:
Wo wir gerade bei den Parametern sind, die weiteren Parameter geben an, in welche SSH Schlüssel beim Start geladen werden sollen. D.h. falls noch mehr Schlüssel geladen werden sollen, müssen hier die Namen angepasst werden.
Ein Beispiel Modul (hier wdm):
Login sieht ähnlich aus, auch hier wird nach der Zeile @include common-auth die Zeile @include pam-ssh-auth hinzugefügt. Und die Zeile @include pam-ssh-session wird hinter die Zeile @include pam-session eingefügt.
Wenn man das Prinzip verstanden hat, wie pam konfiguriert wird, ist es relativ simpel. Man könnte z.B. auch die obigen Zeilen an das Ende der Dateien common-auth bzw. common-session hinzufügen. Der Vorteil hier ist, dass automatisch alle Services, die diese beiden Module benutzen automatisch die pam-ssh Module benutzen.
Ich muß noch hinzufügen, dass pam-ssh hier bei grafischer Anmeldung nicht funktioniert hat. Es wurden keinerlei Keys geladen. Woran das lag, konnte ich jetzt nicht feststellen. Außerdem sollte man vielleicht noch erwähnen, dass es unter Berücksichtigung der Sicherheit eventuell kein so guter Rat ist, dass alle Schlüssel das gleiche Passwort haben und das diese Schlüssel dann auch alle gleich beim Start geladen werden. Wenn der Zugang kompromittiert wurde, müssen dann nämlich auch die Zugänge zu allen anderen Systemen als kompromittiert gelten, wenn die Schlüssel ohne Passwort benutzbar ist. (Das gilt natürlich im gleichen Maße für keychain).
Vielleicht wäre es auch keine schlechte Idee, wenn ssh-add mit dem Parameter -t gestartet würde. So kann man angeben, dass diese Schlüssel nur eine bestimmte Zeitspanne gültig sind:
Jetzt beschreibe ich, wie mit Single-Sign on bereits beim Einloggen die SSH Schlüssel entschlüsselt werden können.
Zunächst installiert man das Paket libpam-ssh. Dieses Pam-Paket (Die Möglichkeiten von PAM würden den Rahmen dieses Artikels sprengen) ermöglicht es, bereits bei der Anmeldung am System die SSH-Schlüssel zu entschlüsseln und den ssh-agent zu starten. Dafür stellt es die beiden Module pam-ssh-auth (Authentifizierung anhand des ssh-keys) und pam-ssh-session (Start des SSH Agents sowie Laden der Schlüssel) zur Verfügung.
Nach der Installation muß man dann das System so konfigurieren, dass bei bestimmten Aktionen die beiden Module geladen werden. Möchte man z.B. beim Einloggen auf einer Konsole, dass die vorhandenen Schlüssel geladen werden, dann sollte man diese beiden Module in die Datei /etc/pam.d/login (Für den Loginzugriff bei Debian System verantwortlich) hinzufügen. Beim Start des grafischen Loginmanagers ist dann die Datei /etc/pam.d/gdm bzw, kdm, wdm oder xdm für den jeweiligen Loginmanager zuständig. Weitere Module könnten angepasst werden (z.B. ssh für den Login per ssh) In diesen Scripten steht im Prinzip in welcher Reihenfolge bestimmte Pam Module geladen werden sollen
Nun wird in vielen Howtos und Anleitungen empfohlen das Modul pam-ssh-auth vor dem Modul common-auth zu laden. Der Effekt der dadurch erzielt wird, ist, dass man beim Login dann grundsätzlich sein SSH Schlüssel Passwort eingeben muß und nicht sein Standard Unix Passwort. Wer das möchte, der kann das gerne machen, ich finde das nicht so schön, v.a. weil es mich nervt, wenn ich mich als User einlogge, der gar keine SSH Schlüssel besitzt.
Es ist aber auch möglich, sich mit seinem Unix Passwort anzumelden und dennoch die SSH Schlüssel zu laden, vorausgesetzt, die beiden Passwörter stimmen überein. Prinzipiell sollte es auch möglich sein, wenn das Passwort anders ist, denn über den Parameter try_first_pass sollte pam-ssh in der Lage sein, bei einem nicht passenden Passwort extra nachzufragen. Das tut er aber hier nicht:
root@t41:/etc/pam.d# cat pam-ssh-auth
auth sufficient pam_ssh.so try_first_pass keyfiles=id_dsa,id_rsa,identity,id_dsa1,id_dsa2,id_dsa3
root@t41:/etc/pam.d# man libpam-ssh
[...]
try_first_pass This option is similar to the use_first_pass option,
except that if the previously obtained password fails,
the user is prompted for another password.
root@t41:/etc/pam.d#
Wo wir gerade bei den Parametern sind, die weiteren Parameter geben an, in welche SSH Schlüssel beim Start geladen werden sollen. D.h. falls noch mehr Schlüssel geladen werden sollen, müssen hier die Namen angepasst werden.
Ein Beispiel Modul (hier wdm):
root@t41:/etc/pam.d# cat wdm
#%PAM-1.0
auth required pam_nologin.so
auth required pam_env.so
@include common-auth
@include pam-ssh-auth
@include common-account
@include common-session
@include pam-ssh-session
Login sieht ähnlich aus, auch hier wird nach der Zeile @include common-auth die Zeile @include pam-ssh-auth hinzugefügt. Und die Zeile @include pam-ssh-session wird hinter die Zeile @include pam-session eingefügt.
Wenn man das Prinzip verstanden hat, wie pam konfiguriert wird, ist es relativ simpel. Man könnte z.B. auch die obigen Zeilen an das Ende der Dateien common-auth bzw. common-session hinzufügen. Der Vorteil hier ist, dass automatisch alle Services, die diese beiden Module benutzen automatisch die pam-ssh Module benutzen.
Ich muß noch hinzufügen, dass pam-ssh hier bei grafischer Anmeldung nicht funktioniert hat. Es wurden keinerlei Keys geladen. Woran das lag, konnte ich jetzt nicht feststellen. Außerdem sollte man vielleicht noch erwähnen, dass es unter Berücksichtigung der Sicherheit eventuell kein so guter Rat ist, dass alle Schlüssel das gleiche Passwort haben und das diese Schlüssel dann auch alle gleich beim Start geladen werden. Wenn der Zugang kompromittiert wurde, müssen dann nämlich auch die Zugänge zu allen anderen Systemen als kompromittiert gelten, wenn die Schlüssel ohne Passwort benutzbar ist. (Das gilt natürlich im gleichen Maße für keychain).
Vielleicht wäre es auch keine schlechte Idee, wenn ssh-add mit dem Parameter -t gestartet würde. So kann man angeben, dass diese Schlüssel nur eine bestimmte Zeitspanne gültig sind:
cb@t41:~$ ssh-add -t 5 ~/.ssh/id_dsa && ssh-add -l && sleep 5 && ssh-add -l
Enter passphrase for /home/cb/.ssh/id_dsa:
Identity added: /home/cb/.ssh/id_dsa (/home/cb/.ssh/id_dsa)
Lifetime set to 5 seconds
1024 d4:3d:21:a7:fe:16:39:a4:f5:12:d7:cd:8f:aa:6d:10 /home/cb/.ssh/id_dsa (DSA)
The agent has no identities.
cb@t41:~$
Thursday, 25. October 2007
putty mit OpenSSH Schlüsseln
Im vorigen Artikel wurde beschrieben, wie man ssh mit Schlüsseln benutzt. Man kann einen so generierten privaten Schlüssel auch mit Putty benutzen. Im Lieferumfang von putty befindet sich das Programm Putty Key Generator (puttygen.exe). Diese Programm startet man.
Dann clickt man auf Conversions, Import Key:
Und dann muß man seinen privaten Schlüssel id_rsa entschlüsseln:
Und dann speichert man diesen Schlüssel im Putty eigenen Format (putty private key):
Mit dem Programm Putty Authentication Agent (pageant.exe) kann ein so generierter Schlüssel geladen werden und steht dann putty zum Anmelden im Speicher zur Verfügung.
Mit einem kleinen Batchscript kann man beim Start von Windows dafür sorgen, dass immer pageant.exe gestartet wird:
@echo off
: Start is used to start the following command in the background
start /b "c:\program files\putty\pageant.exe" "c:\documents and settings\Administrator\My Documents\putty_keys\ssh_key.ppk" >NUL 2>&1
Im Skript einfach die Pfade anpassen und in den Startup/Autostart Ordner kopieren und schon startet bei der Anmeldung von Windows ein kleines Fenster von pageant.exe und möchte gern das Passwort für den angegebenen Schlüssel haben.
Das könnte man natürlich noch ausbauen und gleich eine ssh-Verbindung zu einem Server starten.
Dann clickt man auf Conversions, Import Key:
Und dann muß man seinen privaten Schlüssel id_rsa entschlüsseln:
Und dann speichert man diesen Schlüssel im Putty eigenen Format (putty private key):
Mit dem Programm Putty Authentication Agent (pageant.exe) kann ein so generierter Schlüssel geladen werden und steht dann putty zum Anmelden im Speicher zur Verfügung.
Mit einem kleinen Batchscript kann man beim Start von Windows dafür sorgen, dass immer pageant.exe gestartet wird:
@echo off
: Start is used to start the following command in the background
start /b "c:\program files\putty\pageant.exe" "c:\documents and settings\Administrator\My Documents\putty_keys\ssh_key.ppk" >NUL 2>&1
Im Skript einfach die Pfade anpassen und in den Startup/Autostart Ordner kopieren und schon startet bei der Anmeldung von Windows ein kleines Fenster von pageant.exe und möchte gern das Passwort für den angegebenen Schlüssel haben.
Das könnte man natürlich noch ausbauen und gleich eine ssh-Verbindung zu einem Server starten.
SSH mit Schlüsseln
Dies ist eine kurze Anleitung, wie man ssh mit keys benutzt. Vergleichbare Anleitungen finden sich wahrscheinlich haufenweise bei Google. Dies hier ist meine, damit ich nicht immer Google bemühen muss.
Voraussetzung dafür ist natürlich, dass PublicKey-Authentifizierung überhaupt erlaubt ist. Dies geschieht durch die Anweisung PubkeyAuthentication yes in /etc/ssh/sshd_config Und wenn man schon mal die Konfiguration prüft, kann man auch gleich überprüfen, dass Protokoll 2 verwendet wird und nicht das veraltete 1:
~$ egrep "PubkeyAuthentication|Protocol" /etc/ssh/sshd_config
Protocol 2
PubkeyAuthentication yes
Sieht gut aus. Nun können wir einen Key erstellen. Dies geschieht auf dem Client, von dem nachher auf den Server zugegriffen werden soll.
Grundsätzlich gibt es 2 vershiedene Arten: DSA und RSA. Die Art des Keys wird mit dem Parameter -t angegeben(default ist hier RSA). Für RSA-keys kann mit dem Parameter -b noch die bitlänge angegeben werden (default sind hier 768bit, DSA ist nur gültig mit 1024 bit).
user@host ~$ ssh-keygen -b 1024 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
47:bf:9c:7a:0f:d8:26:15:4f:1f:d0:d7:54:d1:b4:0a user@host
Wichtig: Der Key sollte immer verschlüsselt werden. Also nie eine leere Passphrase angegeben, denn falls dieser Schlüssel in falsche Hände gerät, dann hat der Angreifer damit auch gleich Zugriff auf den Server.
Der Schlüssel besteht dabei aus einem privaten und einem öffentlichen Teil. Der öffentliche Schlüssel (id_rsa.pub) authentifiziert gegen den privaten Schlüssel (id_rsa), d.h. er muß auf den Server kopiert werden. Dafür gibt es den Befehl ssh-copy-id. Man kann es aber auch händisch machen:
user@host ~$ cat id_rsa.pub | ssh user@server 'cat >> .ssh/authorized_keys'
Password:
Fertig. Jetzt noch die Verbindung testen:
Es wurde einfach eine SSH-Verbindung mit dem Schlüssel id_rsa (-i) aufgebaut, die gleich wieder beendet wurde.Die Logausgaben (-v) zeigen, dass auch wirklich die PublicKey Methode verwendet wurde (Hervorhebung durch mich).
Das Passwort wird nur zur Entschlüsselung des privaten Schlüssels (id_rsa) benötigt und nicht, um sich auf dem Server anzumelden. Es wandert also nicht über die "Leitung".
Nun ist es bisher nicht sonderlich komfortabel, die Passphrase muß auch weiterhin jedesmal eingegeben werden. Deshalb gibt es den ssh-agent. Wenn dieser gestartet wird, speichert er das Passwort im RAM und nutzt dieses dann zum einloggen. Auch diesem muß einmal das Passwort mitgegeben werden, dann jedoch benötigt er es nicht mehr, vorausgesetzt, der ssh-client weiß, dass er den ssh-agent benutzen soll.
Einen Schlüssel kann dem ssh-agent über ssh-add mitgegeben werden. Hier wird dann auch nach dem Passwort des Schlüssels gefragt.
Zunächst wird der ssh-agent gestartet:
user@host ~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-UL5yg0m5jV/agent.3636; export SSH_AUTH_SOCK;
SSH_AGENT_PID=5556; export SSH_AGENT_PID;
echo Agent pid 5556;
user@host ~$ eval `ssh-agent`
Agent pid 4520
Wenn der ssh-agent gestartet wird, startet er sofort im Hintergrund und gibt ein paar Umgebungsvariablen aus. Die Ausgabe erfolgt so, dass sie sofort an die bash weitergegeben werden kann. Damit der ssh-agent also genutzt werden kann, müssen diese Umgebungsvariablen der Shell zur Verfügung gestellt werden. Dies kann z.B. mit eval geschehen.
Neue Schlüssel können mit ssh-add hinzugefügt werden:
user@host ~$ ssh-add
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
Damit dies z.B. automatisch bei jedem Einloggen geschieht, kann man das folgende in seine .bashrc schreiben (falls die bash die login Shell ist):
test $SSH_AGENT_PID || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL --login -i"
Der Nachteil, loggt man sich auf verschiedenen Terminals ein, so werden u.U. mehrere ssh-agent gestartet. Wie man das komfortabel löst, erklärt eine andere Geschichte.
Voraussetzung dafür ist natürlich, dass PublicKey-Authentifizierung überhaupt erlaubt ist. Dies geschieht durch die Anweisung PubkeyAuthentication yes in /etc/ssh/sshd_config Und wenn man schon mal die Konfiguration prüft, kann man auch gleich überprüfen, dass Protokoll 2 verwendet wird und nicht das veraltete 1:
~$ egrep "PubkeyAuthentication|Protocol" /etc/ssh/sshd_config
Protocol 2
PubkeyAuthentication yes
Sieht gut aus. Nun können wir einen Key erstellen. Dies geschieht auf dem Client, von dem nachher auf den Server zugegriffen werden soll.
Grundsätzlich gibt es 2 vershiedene Arten: DSA und RSA. Die Art des Keys wird mit dem Parameter -t angegeben(default ist hier RSA). Für RSA-keys kann mit dem Parameter -b noch die bitlänge angegeben werden (default sind hier 768bit, DSA ist nur gültig mit 1024 bit).
user@host ~$ ssh-keygen -b 1024 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
47:bf:9c:7a:0f:d8:26:15:4f:1f:d0:d7:54:d1:b4:0a user@host
Wichtig: Der Key sollte immer verschlüsselt werden. Also nie eine leere Passphrase angegeben, denn falls dieser Schlüssel in falsche Hände gerät, dann hat der Angreifer damit auch gleich Zugriff auf den Server.
Der Schlüssel besteht dabei aus einem privaten und einem öffentlichen Teil. Der öffentliche Schlüssel (id_rsa.pub) authentifiziert gegen den privaten Schlüssel (id_rsa), d.h. er muß auf den Server kopiert werden. Dafür gibt es den Befehl ssh-copy-id. Man kann es aber auch händisch machen:
user@host ~$ cat id_rsa.pub | ssh user@server 'cat >> .ssh/authorized_keys'
Password:
Fertig. Jetzt noch die Verbindung testen:
user@host ~$ ssh -v -i id_rsa user@server "exit"
[...]
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key 'id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Es wurde einfach eine SSH-Verbindung mit dem Schlüssel id_rsa (-i) aufgebaut, die gleich wieder beendet wurde.Die Logausgaben (-v) zeigen, dass auch wirklich die PublicKey Methode verwendet wurde (Hervorhebung durch mich).
Das Passwort wird nur zur Entschlüsselung des privaten Schlüssels (id_rsa) benötigt und nicht, um sich auf dem Server anzumelden. Es wandert also nicht über die "Leitung".
Nun ist es bisher nicht sonderlich komfortabel, die Passphrase muß auch weiterhin jedesmal eingegeben werden. Deshalb gibt es den ssh-agent. Wenn dieser gestartet wird, speichert er das Passwort im RAM und nutzt dieses dann zum einloggen. Auch diesem muß einmal das Passwort mitgegeben werden, dann jedoch benötigt er es nicht mehr, vorausgesetzt, der ssh-client weiß, dass er den ssh-agent benutzen soll.
Einen Schlüssel kann dem ssh-agent über ssh-add mitgegeben werden. Hier wird dann auch nach dem Passwort des Schlüssels gefragt.
Zunächst wird der ssh-agent gestartet:
user@host ~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-UL5yg0m5jV/agent.3636; export SSH_AUTH_SOCK;
SSH_AGENT_PID=5556; export SSH_AGENT_PID;
echo Agent pid 5556;
user@host ~$ eval `ssh-agent`
Agent pid 4520
Wenn der ssh-agent gestartet wird, startet er sofort im Hintergrund und gibt ein paar Umgebungsvariablen aus. Die Ausgabe erfolgt so, dass sie sofort an die bash weitergegeben werden kann. Damit der ssh-agent also genutzt werden kann, müssen diese Umgebungsvariablen der Shell zur Verfügung gestellt werden. Dies kann z.B. mit eval geschehen.
Neue Schlüssel können mit ssh-add hinzugefügt werden:
user@host ~$ ssh-add
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
Damit dies z.B. automatisch bei jedem Einloggen geschieht, kann man das folgende in seine .bashrc schreiben (falls die bash die login Shell ist):
test $SSH_AGENT_PID || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL --login -i"
Der Nachteil, loggt man sich auf verschiedenen Terminals ein, so werden u.U. mehrere ssh-agent gestartet. Wie man das komfortabel löst, erklärt eine andere Geschichte.
Wednesday, 3. October 2007
Beobachtungen
In letzter Zeit beochbachte ich auffallend oft, dass bei Bezahlung mit EC-Karte/Kreditkarte und Verifizierung mit Unterschrift, die Kassierer oftmals die Unterschrift gar nicht überprüfen. Sehr schön vor allem die Tankstellen, an denen man die Karte nichtmal dem Kassierer geben muss. Vermutlich bemerkt keiner, wenn nur mit 3 Kreuzen unterschrieben würde.
Ich dachte eigentlich immer, dass die Kassierer immer die Unterschrift mit der auf der Karte aufgedruckten überprüfen müssten.
Irgendwie nicht sehr vertrauenserweckend, da ist mir die PIN lieber.
Ich dachte eigentlich immer, dass die Kassierer immer die Unterschrift mit der auf der Karte aufgedruckten überprüfen müssten.
Irgendwie nicht sehr vertrauenserweckend, da ist mir die PIN lieber.
Wednesday, 28. February 2007
Verschlüsselte Backups auf Windows Maschinen mittels TrueCrypt und rsnapshot
Vor kurzem hab ich mir überlegt, wie ich auf meinem dienstlichen Laptop möglichst effektiv meine Backups erledige. Leider besitzt dieser kein DVD-Laufwerk, so dass DVDs als Backupmedium ausfallen und CDs sind mittlerweile zu klein.
Vorüberlegung:
Ich bin beruflich recht viel unterwegs und so hab ich mich für eine kleine externe 2,5 Zoll USB-Festplatte als Medium entschieden, die nimmt nicht soviel Platz weg, kann über den USB-Port mit Strom versorgt werden und gibt es bei ausreichender Kapazität für einen angemessenes Entgelt.
Zusätzlich wollte ich meine Backups auf der Festplatte nicht unverschlüsselt rumliegen lassen. Also mußte eine Lösung her, bei der die Backups verschlüsselt werden auf die eine oder andere Weise.
Backuplösungen für Windows gibt es ja wie Sand am Meer, angefangen bei der mitgelieferten Windows eigenen Lösung bis hin zu Freeware, Shareware und andere kostenpflichtige Software. Da ich aber keine Lust hatte, ewig und 3 Tage passende Software zu testen (schließlich wollte ich meine Daten sichern), schaute ich mir zunächst die mir aus der Linuxwelt bekannten Lösungen duplicity und rsnapshot an.
Duplicity macht eigentlich genau das, was ich möchte. Es erstellt inkrementelle Backups, die zusätzlich noch in einem tar-Archiv verschlüsselt werden. Das habe ich aber zunächst nicht ans laufen bekommen unter Windows.
Rsnapshot war mir auch schon bekannt und benutzt rsync um nur die geänderten Daten zu übertragen. Durch die Nutzung von hardlinks ist dabei jedes Backup hinterher ein Vollbackup. Ein Hardlink ist im Prinzip ein Verweis auf eine Datei. Nachdem dieser Link angelegt ist, kann man nicht mehr unterscheiden, was der Link ist und was der Verweis. Beide zeigen auf das gleiche physikalische Objekt, dennoch wird nur einmal dessen Platz belegt.
Das macht die Datenübertragung natürlich effektiv und verkürzt die Backupdauer.
TrueCrypt:
Um das Backup verschlüsselt zu erstellen, benutzte ich TrueCrypt. Es ermöglicht das erstellen von verschlüsselten Laufwerken aus Containerdateien oder Partitionen. TrueCrypt unterstützt zudem seit Kernel 2.6.5 auch Linux, so dass es möglich ist, ein entsprechend verschlüsseltes Laufwerk auch unter Linux zu nutzen, was ich aber noch nicht ausprobieren konnte. TrueCrypt ist auch OpenSource und kommt mit einer sehr guten englischen Dokumentation, die ich nur empfehlen kann. Da TrueCrypt als Gerätetreiber installiert wird, benötigt man aber Administrator Rechte, damit es funktioniert; als nicht privilegierter User kann man TrueCrypt immerhin eingeschränkt nutzen, wenn ein Administrator es installiert hat.
Eine Anleitung, wie man jetzt eine verschlüsselte Partition erstellt, spare ich mir an dieser Stelle, das haben andere schon sehr gut gelöst:
Als Anmerkung sei dazu gesagt, wenn man bei den Backups den Vorteil von Hardlinks ausnutzen möchte, muß man als Dateisystem NTFS angeben, denn FAT unterstüzt keine Hardlinks.
Installation von rsnapshot:
Auf der Website von rsnapshot steht als unterstütztes Betriebssystem nicht explizit Windows dabei, rsnapshot funktioniert aber problemlos mittels Cygwin. Dabei ist darauf zu achten, dass mindestens Perl, rsync, coreutils und automake/autoconf installiert werden. Die werden aber normalerweise immer installiert, so dass keine besondere Selektion nötig ist. Möchte man rsnapshot sauber installieren, kann man zusätzlich noch Stow.
Auf der Website von rsnapshot lädt man sich das generische Unix-Paket herunter (momentan rsnapshot-1.3.0.tar.gz) und speichert es z.B. in c:\temp.
Nun startet man Cygwin:
$ cd /cygdrive/c/temp
$ tar -xzf rsnapshot-1.3.0.tar.gz
$ cd rsnapshot-1.3.0
$ ./configure --prefix=/usr/local/stow/rsnapshot-1.3.0
$ make test
$ make install
$ cd /usr/local/stow/
$ stow rsnapshot-1.3.0
(Cygwin mappt die Windowslaufwerke auf ein POSIX-Dateisystem, wobei die Laufwerke unter /cygdrive eingehängt sind. D.h. C:\temp findet sich unter /cygdrive/c/temp)
Man wechselt also in das temporäre Verzeichnis, in dem sich das Archiv von rsnapshot befindet und entpackt das Archiv (tar -xzf ...). Danach konfiguriert sich das Programm (es sucht nach abhängigen Programmen wie rsync und cp). Hierbei kann zusätzlich der Parameter --prefix angegeben werden (um es an einen ganz bestimmten Ort zu installieren oder es mittels stow installiert werden soll, falls nicht, fällt der letzte Schritt weg). Danach ist es sinnvoll, die Testsuite durchlaufen zu lassen und wenn dass alles erfolgreich war, kann man es im Dateisystem installieren.
Konfiguration von rsnapshot
Jetzt geht es an die Konfiguration von rsnapshot. Am besten man kopiert die rsnapshot.conf.default aus /usr/local/etc als rsnapshot.conf nach /usr/local/etc. Dies kann man unter cygwin machen (cp /usr/local/etc/rsnapshot.conf.default /usr/local/etc/rsnapshot.conf) oder auch mit dem Windows Explorer. Hier muß man die Cygwin Pfade wieder umwandeln in Windows Pfade. Wenn Cygwin nach C:\cygwin installiert wurde, findet man die Konfigurationsdatei unter C:\cygwin\usr\local\etc\rsnapshot.conf.default. Die kann man jetzt einfach umbenennen (.default löschen) bzw. kopieren.
Jetzt muß die Konfigurationsdatei noch angepasst werden. Dazu muß diese Datei mit einem Editor geöffnet werden. Anpassen tun wir die folgenden Stellen:
# Das Verzeichnis, wohin kopiert werden soll:
snapshot_root /cygdrive/d/
# Das snapshot_root nicht anlegen, falls es nicht existiert
# (Festplatte nicht angeschlossen)
no_create_root 1
# cmd_cp aktivieren (wir nutzen GNU cp!)
cmd_cp /usr/bin/cp
# auskommentieren von Syslog
# evtl. nicht installiert, bzw. wen interessiert das
# Syslog in Cygwin?
#cmd_logger /path/to/logger
# aktivieren von du, um eine Auswertung des Platzbedarfs zu
# erhalten
cmd_du /usr/bin/du
# aktivieren von rsnapshot-diff, um später Unterschiede
# verschiedener Backups herauszufinden
cmd_rsnapshot_diff /usr/local/bin/rsnapshot-diff
# Ich möchte gern rsync-Statistiken sehen, also wird noch
# der Parameter --stats für rsync hinzugefügt
rsync_long_args --delete --numeric-ids --relative --delete-excluded --stats
# Diese Datei enthält pro Zeile Verzeichnisse, die nicht gesichert werden.
exclude_file /cygdrive/c/rsnapshot_exclude
# neuere rsyncs können selber hardlinks erstellen, also aktivieren wir
# link_dest
link_dest 1
# Quellen definieren: Was soll gesichert werden?
# Achtung: \ durch / ersetzen, laufwerksbuchstaben
# ersetzen durch /cygdrive/laufwerk
backup /cygdrive/c/Documents and Settings/Administrator/My Documents/ localhost/
backup /cygdrive/c/Bilder/ localhost/
Das soll als Anregung reichen. Wichtig ist, am Ende zu definieren, was gesichert werden soll. In diesem Fall sollen die Ordner 'My Documents' und C:\Bilder gesichert werden. Durch die Angabe von exclude_file und include_file kann genau gesteuert werden, welche Dateien gesichert werden sollen und welche ausgelassen werden. Meine exclude_file sieht so aus:
/cygdrive/c/Documents and Settings/Administrator/My Documents/My Videos/
/cygdrive/c/Documents and Settings/Administrator/My Documents/My Pictures/
/cygdrive/c/Documents and Settings/Administrator/My Documents/My Music/
Achtung: rsnapshot ist extrem sensitiv in der Unterscheidung von Leerzeichen und Tabulatoren, Pfade müssen immer mit einem / aufhören. Deshalb ist es eine gute Idee, die Konfiguration prüfen zu lassen:
$ rsnapshot configtest
Syntax OK
Die Syntax ist ok. Um das Backup zu starten, reicht der Aufruf rsnapshot zusammen mit dem gewünschten Intervall, z.B. hourly, daily oder weekly:
$ rsnapshot hourly
Verschlüsseln und sichern:
Der Vorgang sieht so aus:
Aufwändig...
Doch man kann das auch alles mit einer kleinen Batch-Datei scripten und automatisieren:
@echo off & SETLOCAL ENABLEDELAYEDEXPANSION
:: Diese Variablen sollten angepasst werden.
:: TC: wo befindet sich Truecrypt?
set TC=%~dp0TrueCrypt
:: Welches Gerät soll eingehängt werden
set Device="\Device\Harddisk1\Partition1"
:: Das Gerät soll welchen Laufwerksbuchstaben bekommen?
set LW=D:
:: Das Passwort (Achtung: nicht empfehlenswert, es anzugeben!)
set PW=""
:: Wo befindet sich cygwin
set Cygwin="C:\Cygwin\bin"
set PATH=%TC%;%path%
:check
cls
echo Bitte eine Auswahl treffen:
echo ============================
echo.
echo 1. Starte monthly Backup
echo 2. Starte weekly Backup
echo 3. Starte daily Backup
echo 4. Starte hourly Backup (default)
echo.
echo 6. Mounte Gerät
echo 7. Unmounte Gerät
echo.
echo 0. Abbrechen
echo.
echo ___________________________
echo.
set /P aus=Auswahl:
echo.
:: Bestimme den Defaultwert wenn nur Enter gedrückt wurde.
if "%aus%" == "" (set aus=4)
if !aus! == 0 goto end
if !aus! == 1 set INTERVAL="monthly" & goto backup
if !aus! == 2 set INTERVAL="weekly" & goto backup
if !aus! == 3 set INTERVAL="daily" & goto backup
if !aus! == 4 set INTERVAL="hourly" & goto backup
if !aus! == 6 goto mount
if !aus! == 7 goto umount
:mount
if not exist %LW%\NUL (
echo Mount Gerät %Device% als Laufwerk D.
echo.
%TC%\TrueCrypt.exe /q /p%PW% /l%LW% /a /v%Device%
) else (
echo Gerät bereits eingehängt.
echo.
pause
)
goto check
:backup
if exist %LW%\NUL (
%Cygwin%\bash -l ~/backup.sh %INTERVAL%
pause
) else (
echo "Gerät nicht verfügbar."
echo "Breche ab..."
pause
)
goto check
:umount
echo Hänge Gerät %Device% aus.
echo.
%TC%\TrueCrypt.exe /q /d
goto check
:end
cls
echo.
echo Ich habe fertig.
echo.
pause
Ich hab das Script mal hier abgelegt.
Um das Backup korrekt auszuführen, wird noch das Shell-Script backup.sh benötigt. Es macht nichts weiter, als rsnapshot mit dem übergebenen Parameter aufzurufen und sieht so aus:
#!/bin/sh --
echo "Executing: rsnapshot "$1""
rsnapshot "$1"
Diese Datei einfach noch nach /home/user (bzw. C:\cygwin\home\user) kopieren und dann klappt es auch mit dem Aufruf von rsnapshot.
Ich benutze diese beiden Skript-Datei, um meine Daten zu sichern, dazu habe ich habe auf meiner USB-Festplatte 1 kleine unverschlüsselte Partition angelegt und diese Batch-Datei dort hin kopiert (F:\). Zusätzlich habe ich TrueCrypt im TravellerModus auf diesem Laufwerk installiert (F:\TrueCrypt). Wann immer ich jetzt Lust habe, meine Daten zu sichern, starte ich diese Batchdatei und alles andere funktioniert fast automatisch.
Update 01.03.2007: das Script backup.sh ergänzt.
Vorüberlegung:
Ich bin beruflich recht viel unterwegs und so hab ich mich für eine kleine externe 2,5 Zoll USB-Festplatte als Medium entschieden, die nimmt nicht soviel Platz weg, kann über den USB-Port mit Strom versorgt werden und gibt es bei ausreichender Kapazität für einen angemessenes Entgelt.
Zusätzlich wollte ich meine Backups auf der Festplatte nicht unverschlüsselt rumliegen lassen. Also mußte eine Lösung her, bei der die Backups verschlüsselt werden auf die eine oder andere Weise.
Backuplösungen für Windows gibt es ja wie Sand am Meer, angefangen bei der mitgelieferten Windows eigenen Lösung bis hin zu Freeware, Shareware und andere kostenpflichtige Software. Da ich aber keine Lust hatte, ewig und 3 Tage passende Software zu testen (schließlich wollte ich meine Daten sichern), schaute ich mir zunächst die mir aus der Linuxwelt bekannten Lösungen duplicity und rsnapshot an.
Duplicity macht eigentlich genau das, was ich möchte. Es erstellt inkrementelle Backups, die zusätzlich noch in einem tar-Archiv verschlüsselt werden. Das habe ich aber zunächst nicht ans laufen bekommen unter Windows.
Rsnapshot war mir auch schon bekannt und benutzt rsync um nur die geänderten Daten zu übertragen. Durch die Nutzung von hardlinks ist dabei jedes Backup hinterher ein Vollbackup. Ein Hardlink ist im Prinzip ein Verweis auf eine Datei. Nachdem dieser Link angelegt ist, kann man nicht mehr unterscheiden, was der Link ist und was der Verweis. Beide zeigen auf das gleiche physikalische Objekt, dennoch wird nur einmal dessen Platz belegt.
Das macht die Datenübertragung natürlich effektiv und verkürzt die Backupdauer.
TrueCrypt:
Um das Backup verschlüsselt zu erstellen, benutzte ich TrueCrypt. Es ermöglicht das erstellen von verschlüsselten Laufwerken aus Containerdateien oder Partitionen. TrueCrypt unterstützt zudem seit Kernel 2.6.5 auch Linux, so dass es möglich ist, ein entsprechend verschlüsseltes Laufwerk auch unter Linux zu nutzen, was ich aber noch nicht ausprobieren konnte. TrueCrypt ist auch OpenSource und kommt mit einer sehr guten englischen Dokumentation, die ich nur empfehlen kann. Da TrueCrypt als Gerätetreiber installiert wird, benötigt man aber Administrator Rechte, damit es funktioniert; als nicht privilegierter User kann man TrueCrypt immerhin eingeschränkt nutzen, wenn ein Administrator es installiert hat.
Eine Anleitung, wie man jetzt eine verschlüsselte Partition erstellt, spare ich mir an dieser Stelle, das haben andere schon sehr gut gelöst:
- Alp Uçkan - Festplatten verschlüsseln mit TrueCrypt (mit Containerdatei)
- Alp Uçkan - Truecrypt: Hidden volumes unter Linux (mit verstecktem Container in TC-Containerdatei)
- F!XMBR / Chris - TrueCrypt-Anleitung (mit Partition)
- F!XMBR / Chris - TrueCrypt-Anleitung (mit verstecktem Container in TC-Containerdatei)
- F!XMBR / Chris - TrueCrypt-Anleitung (Verwenden von Schlüsseldateien)
Als Anmerkung sei dazu gesagt, wenn man bei den Backups den Vorteil von Hardlinks ausnutzen möchte, muß man als Dateisystem NTFS angeben, denn FAT unterstüzt keine Hardlinks.
Installation von rsnapshot:
Auf der Website von rsnapshot steht als unterstütztes Betriebssystem nicht explizit Windows dabei, rsnapshot funktioniert aber problemlos mittels Cygwin. Dabei ist darauf zu achten, dass mindestens Perl, rsync, coreutils und automake/autoconf installiert werden. Die werden aber normalerweise immer installiert, so dass keine besondere Selektion nötig ist. Möchte man rsnapshot sauber installieren, kann man zusätzlich noch Stow.
Auf der Website von rsnapshot lädt man sich das generische Unix-Paket herunter (momentan rsnapshot-1.3.0.tar.gz) und speichert es z.B. in c:\temp.
Nun startet man Cygwin:
$ cd /cygdrive/c/temp
$ tar -xzf rsnapshot-1.3.0.tar.gz
$ cd rsnapshot-1.3.0
$ ./configure --prefix=/usr/local/stow/rsnapshot-1.3.0
$ make test
$ make install
$ cd /usr/local/stow/
$ stow rsnapshot-1.3.0
(Cygwin mappt die Windowslaufwerke auf ein POSIX-Dateisystem, wobei die Laufwerke unter /cygdrive eingehängt sind. D.h. C:\temp findet sich unter /cygdrive/c/temp)
Man wechselt also in das temporäre Verzeichnis, in dem sich das Archiv von rsnapshot befindet und entpackt das Archiv (tar -xzf ...). Danach konfiguriert sich das Programm (es sucht nach abhängigen Programmen wie rsync und cp). Hierbei kann zusätzlich der Parameter --prefix angegeben werden (um es an einen ganz bestimmten Ort zu installieren oder es mittels stow installiert werden soll, falls nicht, fällt der letzte Schritt weg). Danach ist es sinnvoll, die Testsuite durchlaufen zu lassen und wenn dass alles erfolgreich war, kann man es im Dateisystem installieren.
Konfiguration von rsnapshot
Jetzt geht es an die Konfiguration von rsnapshot. Am besten man kopiert die rsnapshot.conf.default aus /usr/local/etc als rsnapshot.conf nach /usr/local/etc. Dies kann man unter cygwin machen (cp /usr/local/etc/rsnapshot.conf.default /usr/local/etc/rsnapshot.conf) oder auch mit dem Windows Explorer. Hier muß man die Cygwin Pfade wieder umwandeln in Windows Pfade. Wenn Cygwin nach C:\cygwin installiert wurde, findet man die Konfigurationsdatei unter C:\cygwin\usr\local\etc\rsnapshot.conf.default. Die kann man jetzt einfach umbenennen (.default löschen) bzw. kopieren.
Jetzt muß die Konfigurationsdatei noch angepasst werden. Dazu muß diese Datei mit einem Editor geöffnet werden. Anpassen tun wir die folgenden Stellen:
# Das Verzeichnis, wohin kopiert werden soll:
snapshot_root /cygdrive/d/
# Das snapshot_root nicht anlegen, falls es nicht existiert
# (Festplatte nicht angeschlossen)
no_create_root 1
# cmd_cp aktivieren (wir nutzen GNU cp!)
cmd_cp /usr/bin/cp
# auskommentieren von Syslog
# evtl. nicht installiert, bzw. wen interessiert das
# Syslog in Cygwin?
#cmd_logger /path/to/logger
# aktivieren von du, um eine Auswertung des Platzbedarfs zu
# erhalten
cmd_du /usr/bin/du
# aktivieren von rsnapshot-diff, um später Unterschiede
# verschiedener Backups herauszufinden
cmd_rsnapshot_diff /usr/local/bin/rsnapshot-diff
# Ich möchte gern rsync-Statistiken sehen, also wird noch
# der Parameter --stats für rsync hinzugefügt
rsync_long_args --delete --numeric-ids --relative --delete-excluded --stats
# Diese Datei enthält pro Zeile Verzeichnisse, die nicht gesichert werden.
exclude_file /cygdrive/c/rsnapshot_exclude
# neuere rsyncs können selber hardlinks erstellen, also aktivieren wir
# link_dest
link_dest 1
# Quellen definieren: Was soll gesichert werden?
# Achtung: \ durch / ersetzen, laufwerksbuchstaben
# ersetzen durch /cygdrive/laufwerk
backup /cygdrive/c/Documents and Settings/Administrator/My Documents/ localhost/
backup /cygdrive/c/Bilder/ localhost/
Das soll als Anregung reichen. Wichtig ist, am Ende zu definieren, was gesichert werden soll. In diesem Fall sollen die Ordner 'My Documents' und C:\Bilder gesichert werden. Durch die Angabe von exclude_file und include_file kann genau gesteuert werden, welche Dateien gesichert werden sollen und welche ausgelassen werden. Meine exclude_file sieht so aus:
/cygdrive/c/Documents and Settings/Administrator/My Documents/My Videos/
/cygdrive/c/Documents and Settings/Administrator/My Documents/My Pictures/
/cygdrive/c/Documents and Settings/Administrator/My Documents/My Music/
Achtung: rsnapshot ist extrem sensitiv in der Unterscheidung von Leerzeichen und Tabulatoren, Pfade müssen immer mit einem / aufhören. Deshalb ist es eine gute Idee, die Konfiguration prüfen zu lassen:
$ rsnapshot configtest
Syntax OK
Die Syntax ist ok. Um das Backup zu starten, reicht der Aufruf rsnapshot zusammen mit dem gewünschten Intervall, z.B. hourly, daily oder weekly:
$ rsnapshot hourly
Verschlüsseln und sichern:
Der Vorgang sieht so aus:
- USB Festplatte anhängen
- TrueCrypt starten
- verschlüsselte Partition einhängen/mounten
- Cygwin starten
- rsnapshot aufrufen und Backup starten
- Ende abwarten
- Festplatte aushängen/dismounten/umounten
- Festplatte vom USB trennen
Aufwändig...
Doch man kann das auch alles mit einer kleinen Batch-Datei scripten und automatisieren:
@echo off & SETLOCAL ENABLEDELAYEDEXPANSION
:: Diese Variablen sollten angepasst werden.
:: TC: wo befindet sich Truecrypt?
set TC=%~dp0TrueCrypt
:: Welches Gerät soll eingehängt werden
set Device="\Device\Harddisk1\Partition1"
:: Das Gerät soll welchen Laufwerksbuchstaben bekommen?
set LW=D:
:: Das Passwort (Achtung: nicht empfehlenswert, es anzugeben!)
set PW=""
:: Wo befindet sich cygwin
set Cygwin="C:\Cygwin\bin"
set PATH=%TC%;%path%
:check
cls
echo Bitte eine Auswahl treffen:
echo ============================
echo.
echo 1. Starte monthly Backup
echo 2. Starte weekly Backup
echo 3. Starte daily Backup
echo 4. Starte hourly Backup (default)
echo.
echo 6. Mounte Gerät
echo 7. Unmounte Gerät
echo.
echo 0. Abbrechen
echo.
echo ___________________________
echo.
set /P aus=Auswahl:
echo.
:: Bestimme den Defaultwert wenn nur Enter gedrückt wurde.
if "%aus%" == "" (set aus=4)
if !aus! == 0 goto end
if !aus! == 1 set INTERVAL="monthly" & goto backup
if !aus! == 2 set INTERVAL="weekly" & goto backup
if !aus! == 3 set INTERVAL="daily" & goto backup
if !aus! == 4 set INTERVAL="hourly" & goto backup
if !aus! == 6 goto mount
if !aus! == 7 goto umount
:mount
if not exist %LW%\NUL (
echo Mount Gerät %Device% als Laufwerk D.
echo.
%TC%\TrueCrypt.exe /q /p%PW% /l%LW% /a /v%Device%
) else (
echo Gerät bereits eingehängt.
echo.
pause
)
goto check
:backup
if exist %LW%\NUL (
%Cygwin%\bash -l ~/backup.sh %INTERVAL%
pause
) else (
echo "Gerät nicht verfügbar."
echo "Breche ab..."
pause
)
goto check
:umount
echo Hänge Gerät %Device% aus.
echo.
%TC%\TrueCrypt.exe /q /d
goto check
:end
cls
echo.
echo Ich habe fertig.
echo.
pause
Ich hab das Script mal hier abgelegt.
Um das Backup korrekt auszuführen, wird noch das Shell-Script backup.sh benötigt. Es macht nichts weiter, als rsnapshot mit dem übergebenen Parameter aufzurufen und sieht so aus:
#!/bin/sh --
echo "Executing: rsnapshot "$1""
rsnapshot "$1"
Diese Datei einfach noch nach /home/user (bzw. C:\cygwin\home\user) kopieren und dann klappt es auch mit dem Aufruf von rsnapshot.
Ich benutze diese beiden Skript-Datei, um meine Daten zu sichern, dazu habe ich habe auf meiner USB-Festplatte 1 kleine unverschlüsselte Partition angelegt und diese Batch-Datei dort hin kopiert (F:\). Zusätzlich habe ich TrueCrypt im TravellerModus auf diesem Laufwerk installiert (F:\TrueCrypt). Wann immer ich jetzt Lust habe, meine Daten zu sichern, starte ich diese Batchdatei und alles andere funktioniert fast automatisch.
Update 01.03.2007: das Script backup.sh ergänzt.
Wednesday, 31. January 2007
Keine Reboots nach Securityupdates für Debian/Ubuntu
Dass kein Betriebssystem ohne regelmäßige Securityupdates auskommt weiß ja (hoffentlich) jeder - daher upgraden wir unseren Rootserver relativ automatisiert 2-3 Mal die Woche.
Bisher haben wir unsere Kiste innerhalb eines Shellscript automatisch aktualisiert, die betroffenen Daemons zum Restart ausgewählt, einen Satz Testscripte gegen alle relevante Dienste ausgeführt und einen Eintrag ins unser Serverchangelog gemacht.
Die Auswahl der Daemons und Programme die durchgestartet werden müssen war leider dem Erfahrung des Admins überlassen, was ziemlich fehlerträchtig ist.
Wer weiß schon z.B. welche aktuell aktiven Programme wirklich die "libsasl2" verwenden
(Die Dependencies des Packagemanagers geben da nur Anhaltspunkte)
Zum Spaß habe ich mal ein kleines Pythonscript namens 'whatsup' geschrieben, das sich die Tatsache zu Nutze macht, dass Linux alle gemappten Dateien eines Prozesses in "/proc//maps" darstellt.
Hier die möglichen Parameter
Möchte man herausbekommen welche Prozesse nach einen Upgrade von "libsasl2" einen Restart vertragen können - geht das so:
(BTW: wie bekommt man eigentliche eine Monospace-Darstellung von Codepassagen in Serendipity hin ?)
Als Nächstes steht eine Integration als "Pkg::Post-Invoke" in "/etc/apt/apt.conf.d" an.
Bisher haben wir unsere Kiste innerhalb eines Shellscript automatisch aktualisiert, die betroffenen Daemons zum Restart ausgewählt, einen Satz Testscripte gegen alle relevante Dienste ausgeführt und einen Eintrag ins unser Serverchangelog gemacht.
Die Auswahl der Daemons und Programme die durchgestartet werden müssen war leider dem Erfahrung des Admins überlassen, was ziemlich fehlerträchtig ist.
Wer weiß schon z.B. welche aktuell aktiven Programme wirklich die "libsasl2" verwenden
(Die Dependencies des Packagemanagers geben da nur Anhaltspunkte)
Zum Spaß habe ich mal ein kleines Pythonscript namens 'whatsup' geschrieben, das sich die Tatsache zu Nutze macht, dass Linux alle gemappten Dateien eines Prozesses in "/proc/
Hier die möglichen Parameter
CODE:
whatsup [-i] -h|p|-P|-r <pid|packagename> ...
-h view this help message
-p display the packagenames of the given pids
(running executable)
-P display all process ids which use parts of the given packages
-r resolve all processes which have file dependencies to files in
the given packages
-i display names of init scripts contained in the resulted
packages
Möchte man herausbekommen welche Prozesse nach einen Upgrade von "libsasl2" einen Restart vertragen können - geht das so:
CODE:
root@256bit: # whatsup -r libsasl2
package : pids : dependend-to-pkg
exim4-daemon-heavy : 26184 : libsasl2
cyrus21-imapd : 8812,15666 : libsasl2
cyrus21-common : 1358 : libsasl2
apache2-mpm-prefork : 1788,10261,1790,23570,1793,1792,1791,1795,23563,23571 : libsasl2
mutt : 9135,5707,15772 : libsasl2
(BTW: wie bekommt man eigentliche eine Monospace-Darstellung von Codepassagen in Serendipity hin ?)
Als Nächstes steht eine Integration als "Pkg::Post-Invoke" in "/etc/apt/apt.conf.d" an.
Wednesday, 15. March 2006
Scheinsicherheit
How to pick a Kensington lock in 60 seconds
Örgs, und ich verlaß mich normalerweise auf diese Schlösser.
Örgs, und ich verlaß mich normalerweise auf diese Schlösser.
Tuesday, 14. March 2006
sudo und die Umgebungsvariablen
Seit dem Sicherheitsupdate DSA 946-1 werden außer den Umgebungsvariablen LANG, LANGUAGE, LC_* und TERM keine weiteren Umgebungsvariablen an den aufzurufenden Prozess vererbt. Das führt dazu, dass z.B. $HOME oder $DISPLAY nicht mehr gesetzt ist und damit einige Programme Fehlermeldungen werfen, oder gar nicht mehr funktionieren (z.B. weil $DISPLAY nicht gesetzt ist).
Dies führte zu einer ganzen Menge an Bugreports gegen sudo: 349196, 349549, 349587 oder 349729.
Die Lösung ist eigentlich recht simpel und auch in der Manpage beschrieben. Um wieder bestimmte Variablen zu vererben, reicht der folgende Eintrag in /etc/sudoers:
Dies führte zu einer ganzen Menge an Bugreports gegen sudo: 349196, 349549, 349587 oder 349729.
Die Lösung ist eigentlich recht simpel und auch in der Manpage beschrieben. Um wieder bestimmte Variablen zu vererben, reicht der folgende Eintrag in /etc/sudoers:
CODE:
Defaults env_reset,env_keep+="DISPLAY HOME XAUTHORITY"
Details entnehme man der Manpage sudoers. Nur soviel, env_reset wird benötigt, damit env_keep funktioniert.Friday, 24. February 2006
Computer Forensics
Ein kostenloses Web-Book zum Thema Forensic-Discovery von Dan Farmer und Wietse Venema.
Wenn ich mal viel Zeit habe, dann muß ich das mal lesen.
Wenn ich mal viel Zeit habe, dann muß ich das mal lesen.
(Page 1 of 3, totaling 31 entries)
next page »
