Linux: backup über ssh (tar)

2009 habe ich bereits einen kurzen Eintrag geschrieben, wie man ein Backup mittels rsync über ssh durchführt. Heute war es notwendig, ein Backup als Archiv über SSH durchzuführen. In so einem Fall macht es Sinn, einige Ordner vom Backup auszuschließen.

tar cvzf - --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found' --exclude='/backup/*' /* | ssh user@domain.tld "dd of=/path/to/backup.tar.gz"

OpenPGPKey mittels DNS

Wie gestern unter PresseBox.de veröffentlicht wurde, bietet der E-Mail Anbieter mail.de jetzt die Möglichkeit, PGP Schlüssel über den Standart OpenPGPKey per DNS zu veröffentlichen. Hierzu wurde von der IETF ein eigener Standart veröffentlicht obwohl es mit PKA bereits eine Option hierzu gab. Das neue Verfahren sieht vor, dass der Besitzer einer DNS-Zone für jede E-Mail-Adresse einen PGP-Schlüssel im DNS veröffentlichen kann. Dazu wurde von der IETG der DNS-Selekter _openpgpkey in Form einer Sub-Domain eingeführt. Um einen PGP-Schlüssel zu veröffentlichen, wird der lokale E-Mail Adressanteil (benutzer@domain.tld) mittels SHA224 gehashed, welchem anschließend der PGP-Zugewiesen wird.

475a43602bcc100c1bb1[...]f14cc4ca6b0b5a34716c02._openpgpkey.o-o-s.de
|                                              |           |        |
|                  SHA224 Hash                 | selector  | domain |

Auf diese Weise kann für jede E-Mail Adresse abgefragt werden, ob ein PGP-Key veröffentlicht wurde. Dies geht z.B über die Webseite https://openpgpkey.info/  oder direkt mittels bash ist dies wiefolgt möglich:

dig +short +vc type61 `printf benutzer|sha224sum|cut -f1 -d\ `._openpgpkey.2nibbles4u.de|sed 's/ [^ ]*//;s/\W//g'|xxd -r -p | gpg --import

Diese Verfahren bietet gegenüber Public Key-Servern verschiedene Vorteile sowie Nachteile .

Vorteile sind:

  • Geht der private Schlüssel verloren, kann durch das aktualisieren des DNS-Records einfach ein neuer Schlüssel veröffentlicht werden. Im Falle von Public-Key-Server können bereits veröfentlichte Schlüssel ohne den privaten Schlüssel nicht mehr zurückgeszogen werden.
  • PGP Anwendungen könnten direkt per DNS den PGP-Schlüssel des Empfängers ermitteln
  • Wurden ein PGP-Key auf einem Public-Key-Server veröffentlicht, konnten Spammer die eMail Adresse dort auslesen.
  • Nur noch der Domain-Besitzer kann PGP Schlüssel veröfentlichen. Über Public-Key-Server kann jeder für jede Adresse einen Schlüssel veröffentlichen.
  • DNS-Technologie hat sich bewährt und ist damit robust.

Doch es gibt auch Nachteile:

  • Um den PGP-Schlüssel veröffentlichen zu können, muss man Zugriff aud die DNS-Zine haben. Falls man diese nicht selber betreut, muss der Provider eine aktuelle DNS-Version einsetzten, welche OpenPGPKey unterstützt und seinen Kunden das setzten entsprechender DNS-Records erlaubt.
  • Die DNS-Zone sollte mittels DNSSec abgesichert sein um einer Manipulation der Einträge vorzubeugen.

Das die Veröffentlichung von PGP Schlüssel per DNS kein Hexenwerk ist, zeigen die Beiträge OPENPGPKEY mit Unix Bordmitteln und PGP-Schlüssel einfach und sicher verteilen von sys4.de. Beide Artikel zeigen sehr praxisnah, wie das Verfahren gehandhabt werden kann. Im ersten Artikel wird leider nicht expliziet erwähnt, dass der entsprechende PGP-Schlüssel vorher mittels

pgp --import

imporitert wurden muss.

Apache2 Freak Angriff auf TLS

Wie heute auf Golem.de mitgeteilt wurde, hat ein Team des französischen Forschungsinstituts im Rahmen des Projektes Smack Inira bei der Untersuchung von TLS Implementierungen zwei neue Sicherheitslücken gefunden. Verwundbare Systeme wie z.B. Apple-Systeme akzeptieren einen schwachen temporären 512-Bit RSA Schlüssel. Theoretisch ist das Risiko für so einen Angriff gering, da der Schlüssel für den Angriff fast in Echtzeit dechiffriert werden muss,jedoch speichert z.B. Apache den Schlüssel für die Dauer eines gesamten Serverprozesses. Hinzu kommt, dass sich diese schwachen 512-Bit RSA Schlüssel nachgewiesen maßen binnen 7 Minuten knacken lassen, wodurch die notwendige Zeit für einen Angriff gegeben gegeben ist.

Weitere Informationen zu der Sicherheitslücke sind auch unter freakattack.com zu finden.

Um seinen eigenen Webserver auf die Verwundbarkeit hin zu testen, hat Devin EGAN ein Bash-Skript zur Verfügung gestellt.

Weitere Quellen

Nachtrag vom 11.03.2014

Bei den Kollegen von sys4.de bin ich gerade auf zwei Einträge gestoßen, wie man Postfix und Dovecot gegen die FREAK Atacke absichert.

Debian 7: openssl 1.0.x selber kompilieren

In letzter Zeit hat sich im Bereich der SSL Sicherheit viel getan. Es sind immer wieder neue Sicherheitslücken aufgetaucht, wie z.B: die Poodle Lücke. Debian gilt seit je her als stables, aber leider auch immer etwas angestaubtes Betriebssystem. Letzteres von beidem bekommt man gerade in letzter Zeit immer wieder zu spüren. Viele neue Funktionen oder Schutzmechanismen sind in Debian 7 (stable) einfach nicht mehr enthalten. Aus diesem Grund möchte nachfolgend einmal beschreiben, wie man sich selber ein openssl Paket bauen kann, um die ein oder andere Sicherheitslücke (TLS_FALLBACK_SCSV, bzw. CRIME) schließen zu können.

OpenSSL kompilieren

Um alle Pekete für openssl zu bauen, werden zuerst einige weitere Pakete sowie die abhängigen Pakete zu openssl benötigt.

cd /usr/src
apt-get install build-essential fakeroot
apt-get build-dep openssl

Anschließend läd man sich die letzte Version von OpenSSL herunter. Welche Version das ist, findet man über https://www.openssl.org/source/ heraus.

wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1k-1.dsc
wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1k.orig.tar.gz
wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1k-1.debian.tar.xz

Die oben genannte CRIME Attacke lässt sich nur durch das deaktivieren der SSL Kompression deaktivieren. Da diese jedoch erst ab Apache 2.2.24+ über die Konfiguration deaktiviert werden kann, muss sie für alle Vorgängerversionen beim kompilieren von openssl deaktiviert werden.

Weiterlesen

Bullshit made in Germany

Normalerweise versuche ich neutral zu bleiben, aber ich bin gerade auf die Seite https://de.ssl-tools.net/bullshit-germany gestoßen, welche genau das unterstreicht, was mir damals bei der Initiative "E-Mail Made in Germany" so gegen den Strich gegangen ist. Leider hat die Presse diese offensichtliche Veräppelung der Menschen bei diesem Thema irgendwie kommentarlos passieren lassen. Schade!

bullshit

Logo: CC-BY-SA MathiasM

 
Execution time 0.08660101890564 seconds