Sicherheitsmechanismen von Bluetooth Low Energy

Dieser Beitrag ist mal wieder eine Zweitverwertung. Im Rahmen meines Studiums habe ich einen Text über die Sicherheitsmechanismen von Bluetooth Low Energy geschrieben. Warum muss man eigentlich sechsstellige Zifferncodes abtippen oder miteinander vergleichen? Und was bedeutet es für die Sicherheit, wenn man das (nicht) machen muss?

Die Arbeit gibt einen Überblick über den Protocol Stack, die Sicherheitsmechanismen und einige Schwächen. Weil ich es immer ein bisschen schade finde, wenn solche Texte nach der Abgabe in der Schublade verschwinden, veröffentliche ich den Text hier für alle Interessierten. Viel Spaß beim Lesen!

„Sicherheitsmechanismen von Bluetooth Low Energy“ weiterlesen »

Backups mit Tarsnap

Vor einiger Zeit kam es bei meinem (inzwischen ehemaligen) Hoster zu einem Problem mit dem RAID des Storage, auf dem die virtuelle Festplatte meines vServers lag. Das Resultat war ein korruptes Dateisystem in meiner VM; ich konnte es zwar teilweise wieder reparieren, allerdings blieben einige Schäden, einige Dateien blieben verschollen oder wurden beim Reparaturvorgang falschen Dateinamen zugeordnet. Kurzum, ein Großteil des Dateisystems war zwar noch da, es reichte aber nicht aus, um mein Ubuntu-Server-System zu booten – und mein Vertrauen in die auf den ersten Blick intakten Überreste hielt sich ebenfalls in Grenzen.

Also war es an der Zeit, das Backup aus der Schublade zu holen. Ich hatte erst zwei Wochen zuvor mein altes Konzept, gpg-verschlüsselte Files per rsync auf einen externen Speicher zu schieben, durch den Service Tarsnap ersetzt. Tarsnap verschlüsselt die Daten lokal auf dem Server und schiebt sie dann in den gleichnamigen Onlinespeicher, der auf Amazon S3 basiert. Dabei kommt eine Deduplikation zum Einsatz, was es recht günstig macht, viele Versionen des Datenbestands aufzubewahren. Das dazugehörige Kommandozeilentool tarsnap ist – dank der guten Dokumentation auf der Website und der Manpage – recht einfach zu bedienen. Per Cronjob mache ich jeden Morgen ein neues, automatisches Backup meines vServers, und von Zeit zu Zeit lösche ich manuell mal die alten Snapshots weg.

Die letzte Version meines Tarsnap-Backups enthielt daher den Stand ein paar Stunden vor dem Crash. Also habe ich mir einen neuen vServer geklickt, die Basiseinrichtung durchgeführt, Tarsnap installiert, meinen Tarsnap-Key auf den neuen Server übertragen und die Wiederherstellung angestoßen.

Ich hatte nicht das gesamte Filesystem des alten Servers gesichert, sondern nur die Dateien der Webapplikationen und jeweils zum Backupzeitpunkt generierte Dumps der zugehörigen Datenbanken. Das Zurückspielen hat hervorragend funktioniert.

Insofern ist mein Backupkonzept jetzt unfreiwilligerweise praxiserprobt, sodass ich sagen kann: Tarsnap hat mir mal den Kopf gerettet – kann ich empfehlen!

Seitenverhältnisse

Aus aktuellem Anlass hier mal einige Gedanken zum Seitenverhältnis von Präsentationen bzw. Vortragsfolien.

Es gibt ja im Wesentlichen 2½ gängige Seitenverhältnisse, die von Projektoren verwendet werden, nämlich 4:3, 16:9 und vielleicht noch 16:10. Die Differenz zwischen 16:9 und 16:10 ist so gering, dass ich letzteres in diesem Artikel vernachlässigen werde.

Vortragende sollten ihre Foliensätze im passenden Format anlegen. Jede gängige Software ermöglicht das. Nur so kann man die zur Verfügung stehende Projektionsfläche optimal ausnutzen – und ein großes Bild ist immer besser als ein kleineres Bild.

Zeigt man 16:9-Folien auf einer 4:3-Projektion oder 4:3-Folien auf einer 16:9-Projektion, führt das dagegen zu ungenutzten Flächen an den Rändern der Projektionsfläche, weil der Projektor das empfangene Signal herunterskalieren muss (die einzige Alternative wäre, an den Rändern Inhalte abzuschneiden, aber das führt zu Anrufen bei der Support-Hotline; Ränder fallen dem durchschnittlichen Vortragenden dagegen gar nicht auf und werden stillschweigend akzeptiert).

So weit, so gut: als Vortragender kann man nun mal nicht immer wissen, welches Seitenverhältnis die Technik am Vortragsort verwendet, insofern sind die oben genannten Szenarien manchmal einfach nicht zu vermeiden – zumindest nicht ohne den Mehraufwand zu treiben, zwei Foliensätze vorzubereiten.

Manchmal – und jetzt kommen wir zum Anlass zu diesem Blogpost – wird das Skalierungsspiel aber noch eine Stufe weiter getrieben, sodass ein Rand rundherum um die Projektionsfläche entsteht. Das geht zum Beispiel so: Man steuert einen 4:3-Projektor mit einem 16:9-Signal an, sodass oben und unten Ränder entstehen. Auf diesem ohnehin schon beschnittenen Bild zeigt man nun 4:3-Folien, die wiederum von der Präsentationssoftware ins 16:9-Format skaliert und somit links und rechts mit Rändern aufgefüllt werden. So verliert man ca. 25% der Höhe, über 40% der Projektsfläche und einige Sympathien in den hinteren Reihen. Die Lösung ist einfach, da noch nicht einmal die Folien angepasst werden müssen: der Projektor muss lediglich mit dem korrekten Seitenverhältnis angesprochen werden.

Zusammenfassend also die Tipps bezüglich des Seitenverhältnisses:

  • Bringe möglichst vorab in Erfahrung, welches Seitenverhältnis der Projektor am Vortragsort verwendet und lege deine Folien darauf aus.
  • Liefere dem Projektor möglichst ein Signal in seiner nativen Auflösung, mindestens aber ein Signal in demselben Seitenverhältnis.

Entwürfe

Hin und wieder – meistens recht spät abends – packt mich der Gedanke, dass ich ja mal wieder einen Blogpost schreiben müsste. Meistens habe ich dann auch schon eine konkrete Idee im Kopf. Ich logge mich ins Backend ein und beginne mit dem Schreiben. Es wird später und später und irgendwann ist der „Ach, kannste eigentlich auch morgen weitermachen“-Punkt erreicht – was dann gelegentlich nicht passiert.

So geschah es auch heute wieder. Eigentlich wollte ich einen neuen Blogpost erstellen. Auf dem Weg in den WordPress-Editor habe ich im Backend aber noch ein wenig unveröffentlichtes, exklusives Material entdeckt. Deshalb kommen jetzt erst mal die ollen Kamellen, der „neue“ Artikel folgt dann die Tage – den hätte ich ohnehin noch nicht veröffentlichen, sondern nur vorbereiten können.

Außerdem habe ich endlich den schon lange existierenden Twitter-Account @returnfalsede mithilfe von IFTTT mit dem Blog verknüpft, sodass neue Posts ab sofort auch dort erscheinen sollten. Dafür ist dieser Beitrag ein Testballon. Ich bin gespannt.

Mail-Backups mit Getmail

Meine E-Mail-Konten rufe ich für gewöhnlich per IMAP ab. Das ist zwar einerseits komfortabel, weil auf all meinen Geräten derselbe Stand vorhanden ist, andererseits bin ich natürlich von der Verfügbarkeit des Mailservers und dem Ausbleiben technischer Pannen beim jeweiligen Provider abhängig. Hinzu kommt das Risiko versehentlich gelöschter E-Mails.

Aus diesem Grund habe ich mir mithilfe von Getmail 5.4 eine eine Archivierung auf meinem Homeserver gebastelt. Diese läuft alle paar Stunden, holt neue Mails aus den Postfächern ab und speichert sie in einem lokalen Maildir. Dabei werden ungelesene Mails nicht als gelesen markiert und es werden auch keine Mails auf dem Server gelöscht. Das einzige Problem, das ich noch nicht lösen konnte: Wenn ich eine Mail in einen anderen IMAP-Ordner verschiebe, lädt Getmail sie erneut herunter. Aber damit kann ich leben.

Ich habe dazu folgende Ordnerstruktur und einige Dateien angelegt:

/data/mail
├── getall.sh
├── getall.log
├── example@gmail.com
│   ├── conf
│   │   └── getmailrc
│   ├── log
│   │   └── getmail.log
│   └── maildir
│       ├── cur
│       ├── new
│       └── tmp
├── me@example.com
│   ├── conf
│   │   └── getmailrc
│   ├── log
│   │   └── getmail.log
│   └── maildir
│       ├── cur
│       ├── new
│       └── tmp
└── <weitere E-Mail-Adressen>
    └── …

getall.sh ruft Getmail mit den entsprechenden Konfigurationsdateien pro Unterverzeichnis auf:

#!/bin/bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo "Script run $(date)"
for i in ${DIR}/*/conf
do
    echo $i
    cd $i
    getmail -g./
done
echo "-------------------"

Ich rufe getall.sh einmal am Tag via cron auf.

0 3 * * * /bin/bash /data/mail/getall.sh >> /data/mail/getall.log 2>&1

Für die Gmail-Adresse sieht meine Getmail-Konfiguration getmailrc wie folgt aus:

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = example@gmail.com
password = PASSWORD1234
mailboxes = ALL
use_peek = true

[destination]
type = Maildir
path = /data/mail/example@gmail.com/maildir/

[options]
verbose = 1
message_log = /data/mail/example@gmail.com/log/getmail.log
read_all = false

Die heruntergeladenen Mails landen als einzelne Dateien in maildir/new. Die IMAP-Ordnerstruktur geht dabei zunächst verloren, ist in den Mail-Dateien aber in einem zusätzlichen Header-Feld X-getmail-retrieved-from-mailbox noch vermerkt, sodass man sie bei Bedarf schon rekonstruieren könnte.