SSH

Inkrementelles Backup eines Webhosting Auftritts per sshfs

Viele Webhoster bieten eine Möglichkeit, einfache Backups zu erstellen oder diese sogar nach „extern“ per FTP wegzusichern. Dummerweise handelt es sich bei dieser Sicherung jedes mal um ein Fullbackup. Will sagen, in der Regel hat man genau einen Wiederherstellungspunkt für das Backup auf dem Webserver liegen. Oder eben alternativ viele Fullbackups auf einem FTP Server – wobei man hier ja auch noch aufpassen muss, dass die Backups sich nicht bei jedem Lauf überschreiben. Meistens heißen die Dateien ja doch alle gleich.

Wie schon im vorherigen Artikel beschrieben gehe ich bei der Sicherung wie folgt vor: per sshfs wird das Filesystem des Webservers lokal gemountet. Auf dem Webserver des Hosters läuft ein CRON-Job, der jede Minute ein Script auf dem Server startet. Das Script schaut zunächst in einem Verzeichniss nach einem Startflag (Datei). Wenn die Datei gefunden wurde dumpt es die gefüllten MySQL Datenbanken ins Filesystem und schreibt die Aktionen in ein Logfile. Auf dem Backupserver wird per CRON-Job das Backuptool backup2l gestartet. In der Config des Backuptools wird vor dem Backup ein Script gestartet, dass per sshfs das Dateisystem des Webservers mountet und das Startflag für den CRON-Job auf dem Webserver erzeugt. Nach einem Timeout von 5 Minuten wird geprüft ob das Datenbankbackup gelaufen ist und eine entsprechende Meldung ausgegeben. Anschließend läuft backup2l los und sichert per afio und gzip/bzip den Inhalt des Filesystems.

Was wird benötigt?

Auf dem Webserver:

  • cron mit der Möglichkeit eigene Scripts laufen zu lassen
  • Zugang per ssh/sftp (oder ftp/webdav)
  • mysqldump [Read more…]

Zertifikate mit OpenSSL erstellen (Debian OpenSSL Bug)

Aus gegebenem Anlass habe ich mal zur Sicherheit das Zertifikat von Wesselonline neu erstellt. Da die Debian basierten Distributionen ja unter Umständen über einen Fehler in dem OpenSSL Paket angreifbar sind gab’s natürlich sehr zeitnah ein Update der betroffenen Programmpakete. Das Update allein nützt aber nichts, da ja die erstellten Zertifikate in der Regel noch in Benutzung sind und somit relativ leicht ausgehebelt werden können.

Recht vereinfacht lässt sich das so erklären: Bei der Erzeugung der Schlüssel werden mehrere zufällige Zahlen dazu benutzt, einen besonders einzigartigen Schlüssel zu erstellen, der durch die Nutzung von Unbekannten entsprechend sicher ist. Kennt man jedoch das Erstellungsverfahren und die Unbekannten, dann kann man einen erstellten Schlüsselcode berechnen. Die betroffenen OpenSSL Versionen haben leider einen solches Verhalten an den Tag gelegt. Als zufällige Zahlen haben die Pakete nur noch die Prozess-IDs mit einbezogen. Diese sind 15 bit groß und erlauben somit max. 32768 Prozesse oder verschiedene IDs auf einem unixartigen System (also auch Linux). Eine Zahl von 0 bis 32767 wurde also zur Schlüsselerstellung benutzt. Ergo braucht man max. 32768 (2^15) Versuche einen Schlüssel zu brechen. Und das ist durchaus machbar…

Also schnellstmöglich das Update einspielen:

apt-get update && apt-get upgrade -q -y

und anschließend neue Zertifikate erstellen. Die neuen Zertifikate kann man sehr schön zentral unter /etc/ssl/private/ ablegen. Das zentrale Ablegen der Schlüssel hat den Vorteil, dass mehrere verschiedene Dienste auf die Schlüssel zugreifen können ohne das man ihn in diverse Verzeichnisse linken oder gar kopieren müsste. Eine Änderung des Schlüssels würde also direkt nach dem Neustart der entsprechenden Dienste wie Postfix, Dovecot, Apache… etc. greifen.

[Read more…]