PSA: Shellshock / Bashbleed – CVE-2014-6271

Hallo Leute,

nach “Heartbleed” ist jetzt eine weitere große Sicherheitslücke bekannt geworden:

CVE-2014-6271 – auch als Shellshock und Bashbleed bekannt gibt Angreifern die Möglichkeit von der ferne aus Befehle auszuführen. (Betrifft alle Linux und OS X Systeme!)

Mit diesem Test könnt ihr feststellen ob euer System vom dem Bug betroffen ist:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Wenn in eurer Ausgabe “vulnerable” vorkommt seid ihr betroffen. Debian hat den Fehler in “stable” und “squeeze-lts” schon gepatched – siehe hier.

Es sollte schnellstmöglich ein System Upgrade durchgeführt werden:

apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y

Mehr Infos findet ihr hier: Shellshocker.net

peace
LEWIS

rdiff-backup – Die Linux TimeMachine

Hallo Leute,

ich suchte vor einiger Zeit lange nach einem geeigneten Backupsystem für unsere Linux IT Landschaft. Wir hatten damals bacula im Einsatz; dies hat uns überhaupt nicht zugesagt. Danach schrieb ich eigene Shell Backupscripts, was zwar funktionierte, aber sehr mühsam zu warten war und somit auch nicht ideal war.

Im Grunde waren folgende Punkte wichtig:

  • Inkrementelle Backups (Platz sparen bzw. Bandbreite sparen)
  • Voll automatisiert
  • Einfach und verständlich in der Konfiguration

im Grunde also eine Art “TimeMachine” für Linux. Durch Zufall stieß ich dann endlich auf rdiff-backup – dies war ein Heureka für mich. Zuletzt hatte ich das gefunden was ich seit Monaten suchte. Wir setzen rdiff-backup jetzt seit knappen 2 Jahren ein und waren nie glücklicher. Auch die schlechten Gefühle am Abend sind jetzt weg. Noch dazu verwenden wir mein “offsite-backup-script”.

rdiff-backup ist im Grunde eine Kombination aus rsync, ssh und einem klugen Shell Script.

Zur Installation

“rdiff-backup” muss auf dem Backupserver sowie auf dem zu sichernden Server installiert werden.

apt-get install rdiff-backup

das wars auch schon bezüglich Installation.

Konfiguration

Die Konfiguration ist kinderleicht und funktioniert auch leicht und übersichtlich wenn man mehrere Server sichern will.

Zuerst erstellt man einen SSH Key auf dem Backupserver (Server A) und fügt diesem auf dem zu sichernden Server (Server B) ein.

Danach erstellt man ein “ssh-konfiguration file” unter dem Benutzer der dann das Backup ausführen soll (in diesem Fall root):

vim /root/.ssh/config

Hier fügen wir dann alle Server im folgendem Format ein:

Host serverB
HostName serverB.example.com
Port 22
User root

danach die Datei speichern und schließen.

Nun solltet ihr auf dem Backup Server via

ssh serverB

auf den zu sichernden Server zu kommen (ohne Passwort und weitere Angaben). Funktioniert das können wir fortfahren.

Der letzte Schritt ist ein Script anlegen, welches “rdiff-backup” ausführt und die Backups macht:

vim /root/scripts/rdiff-backup.sh

#!/bin/bash

# Lokales Backup
rdiff-backup /etc /srv/backups/serberA/etc/

# Remote Backup
rdiff-backup serverB::/etc /srv/backups/serverB/etc

Das Script muss man natürlich an seine Anforderungen anpassen. Die Verzeichnisse müssen schon erstellt worden sein (/srv/backups/serverB/etc usw) ansonsten funktioniert “rdiff-backup” nicht.

Danach speichern und das Script ausführbar machen:

chmod +x /root/scripts/rdiff-backup.sh

und via

crontab -e
30 1 * * * sh /root/scripts/rdiff-backup.sh

als Cronjob hinzufügen. Ihr könnt das Script auch jederzeit manuell ausführen, danach findet ihr in eurem Backupverzeichnis immer die aktuellen Files sowie die Inkrementellen Files (diese müssen via einem Befehl wiederhergestellt werden)

Kleiner Tipp: Fügt “10 22 * * * dpkg -l > /etc/dpkg_list” in euren Contab hinzu, damit wisst ihr bei einem Totalausfall eures Servers immer genau welche Pakete/Libraries installiert waren und spart so viel Zeit beim Wiederherstellen.

Wiederherstellung

Zum Wiederherstellen eines Verzeichnisses könnt ihr entweder den Ordner auf wieder auf den Server kopieren (im Backupordner sind immer die aktuellsten Files) oder ihr verwendet den “rdiff-backup” Befehl dafür:

#Stellt ein aktuelles Backup wieder her
rdiff-backup -r now serverB::/etc /srv/backups/serverB/etc

#Stellt das Verzeichnis wieder her wie es vor 10 Tagen war
rdiff-backup -r 10D serverB::/etc /srv/backups/serverB/etc

Backups löschen die älter als X Tage sind

Falls ihr ältere Backups nicht mehr benötigt, dafür aber den Speicherplatz, könnt ihr mit

rdiff-backup --force --remove-older-than 12W /srv/backups/serverB/etc

alle Inkrementellen Daten löschen die älter als 12 Wochen sind.

Links

Hoffe ihr habt so viel Freude mit diesem Backupsystem wie ich es habe

peace
LEWIS

Apache / SSL

Von einem fleißigem Leser, bekamen wir eine Mail, mit der Frage, ob wir nicht auch was über Apache und SSL schreiben könnten. Wenn man uns schon so nett fragt, können wir natürlich nicht Nein sagen! ;)

Was ist Apache und was ist SSL?

Apache ist ein Webserver, der sehr häufig im World-Wide-Web eingesetzt wird. Apache ist für die Verwaltung, Zugriffe etc. der Webseiten zuständig.

SSL oder, hier genauer erklärt, OpenSSL ist ein Add-On für Apache.
SSL bedeutet “Secure Sockets Layer” und ist für die sichere Verbindung zwischen zwei Server/Rechner/etc. zuständig. Genauer gesagt, verschlüsselt SSL die Daten, bevor sie auf die Reise gehen.
Somit ist gewährleistet, dass ein abhören bzw. Mitschneiden, auf dem Weg zum Ziel nicht mehr so einfach Möglich ist. Dies wird auch “Man-in-the-Middle” genannt.
Erkennbar, ob SSL benutzt wird, ist am besten am “https://” der Web-Adresse zu erkennen.

Um mit SSL eine Verbindung aufzubauen benötigt man einen Schlüssel oder auch SSL-Zertifikat genannt, das man zuerst generieren muss. Allerdings gibt es da Unterschiede:
Zum testen oder für den privaten Einsatz reicht ein selbstgeneriertes Zertifikat.
Will man allerdings einen öffentlichen Server absichern, kommt man um ein offizielles Zertifikat nicht herum.

Ich will hier aber nur die Vorgehensweise für ein selbstgeneriertes Zertifikat erklären.

Ich gehe davon aus, dass der Webserver Apache2 installiert wurde und auch einwandfrei funktioniert.

Um SSL einzurichten müssen folgende Schritte ausgeführt werden:
– Ein SSL-Verzeichnis anlegen
– Das SSL-Modul starten
– Das Zertifikat generieren
– Key schützen
– Port 443 öffnen
– Konfiguration
– Den Web-Server neustarten

Und los gehts :)

– SSL-Verzeichnis anlegen:

mkdir /etc/apache2/ssl

– SSL-Modul starten:

a2enmod ssl

– Zertifikat generieren:

openssl req -newkey rsa:2048 -x509 -days 365 -nodes -keyout /etc/apache2/ssl/debian-blog.key -out /etc/apache2/ssl/debian-blog.crt

Hier kurz die Bedeutung:
req – Befehl zum erstellen des Zertifikats.
newkey rsa:2048 – neues Zertifikat RSA mit 2048 Bit.
x509 – Selbstgeneriertes Zertifikat.
days 365 – Die Gültigkeit des Zertifikats. Hier 365 Tage.
nodes – Schlüssel soll nicht mit einem Passwort verschlüsselt werden.
keyout – Pfad zum Key
out – Pfad zum Zertifikat

– Key schützen:
Um unberechtigten Zeitgenossen den Zugang zu blockieren, muss der Key geschützt werden:

chown root:root /etc/apache2/ssl/debian-blog.key
chmod 600 /etc/apache2/ssl/debian-blog.key

– Port 443 öffnen:
In der Datei

/etc/apache2/ports.conf

muss folgender Eintrag stehen:

Listen 443

Es kann sein, dass ihr hier nichts ändern müsst, aber überprüfen solltet ihr das schon!

– Konfiguration:
Damit Apache auch weiß, wo die Keys stehen, erstellt man eine eigene Konfigurationsdatei:

touch /etc/apache2/sites-available/ssl

und gibt folgende Einträge ein:

Listen *:443
<VirtualHost localhost:443>
  ServerName localhost
  DocumentRoot /var/www
  ServerAdmin admin@admin.de

  # SSL
  SSLEngine On
  SSLCipherSuite HIGH:MEDIUM
  SSLCertificateFile    /etc/apache2/ssl/debian-blog.crt
  SSLCertificateKeyFile /etc/apache2/ssl/debian-blog.key

  # Logfiles:
  CustomLog /var/log/apache2/access-debian-blog combined
  ErrorLog /var/log/apache2/error-debian-blog
  LogLevel warn

  <Location />
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
  </Location>

</VirtualHost>

Die Fett markierten Einträge müssen natürlich angepasst werden!

Diese Konfigurationsdatei muss noch aktiviert werden:

a2ensite ssl

– Webserver neustarten:
Nun muss Apache nur noch neu gestartet werden und SSL ist eingerichtet.

/etc/init.d/apache2 reload

Wenn ihr jetzt den Browser startet und folgende Adresse eingibt, solltet ihr eine Sicherheitsmeldung des Browsers bekommen.

https://localhost

Diese Sicherheitsmeldung ist normal, weil wir hier einen selbstgeneriertes Zertifikat benutzen.

Für den privaten Server ist dies ausreichend. Wer aber eine öffentliche Webseite betreibt, sollte sich das Zertifikat von einer öffentlichen Stelle beglaubigen lassen.

Seid gegrüßt
Alf