sudo insults – auch der Admin muss Spass haben!

Fluchen tut man als Admin nur oft genug. Ein bisschen Spass dabei kann nicht schaden. Damit sudo einem das Beschimpfen gegenueber eines Nutzers abnimmt, kann man die insults Option nutzen. Die Manpage sagt dazu:

insults           If set, sudo will insult users when they enter an
                  incorrect password.  This flag is off by default.

Um die Funktion zu aktivieren in der /etc/sudoers folgende Zeile hinzufuegen:

Defaults        insults

Anschliessend gibt sudo nette Kommentare zu falsch eingegebenen Passwoertern:

user@host:~$ sudo /bin/false
[sudo] password for user: 
Where did you learn to type?
[sudo] password for user: 
You silly, twisted boy you.
[sudo] password for user: 
What, what, what, what, what, what, what, what, what, what?
sudo: 3 fehlerhafte Anmeldeversuche
user@host:~$

Apache2 mod_proxy und mod_rpaf

Mein Webserver ist in einem internen Netz und davor sitzt ein Apache Webserver der die Anfragen mittels mod_proxy nach hinten weiterreicht. Damit in den Logfiles des internen Webservers dennoch die korrekten IP Adressen auftauchen muss dort das Apache Modul rpaf installiert und konfiguriert werden.

Vor der Installation und Konfiguration sehen bei mir die Logeintraege wie folgt aus:

[Sat Nov 09 18:32:14 2013] [error] [client 10.10.10.10] File does not exist: /var/www/foobar

Die Installation des Moduls erfolgt bei Debian aus den Paketquellen:

apt-get install libapache2-mod-rpaf

Anschliessend muss das Modul aktiviert werden:

a2enmod rpaf

Konfiguriert wird es in der Datei /etc/apache2/mods-enabled/rpaf.conf. Dort muss die IP des oder der Proxy-Server entsprechend hinzugefuegt werden. In dem Beispiel oben ist 10.10.10.10 der Proxy-Server und wird entsprechend unter RPAFproxy_ips hinzugefuegt:

<IfModule rpaf_module>
    RPAFenable On
 
    # When enabled, take the incoming X-Host header and
    # update the virtualhost settings accordingly:
    RPAFsethostname On
 
    # Define which IP's are your frontend proxies that sends
    # the correct X-Forwarded-For headers:
    RPAFproxy_ips 10.10.1.2
 
    # Change the header name to parse from the default
    # X-Forwarded-For to something of your choice:
#   RPAFheader X-Real-IP
</IfModule>

Nach dem Neustart des Apache Webservers steht dann die korrekte IP in der Logdatei:

[Sat Nov 09 18:46:32 2013] [error] [client 77.176.69.123] File does not exist: /var/www/foobar

Mehr Sicherheit fuer die eigenen Daten – vollverschluesselte Festplatten auf Servern

Dieses ist der neunte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten acht Artikeln befinden sich am Ende des Blogposts. Im neunten Teil moechte ich meine Ueberlegungen zu selbstgehosteten Servern und deren Sicherheit im Kontext Verschluesselung der Festplatten vorstellen.

Wenn ich eine verschluesselte Verbindung zu einem anderen Rechner / Dienst im Internet aufbaue kann ich das ungewollte Mitlesen der Kommunikation erschweren bis verhindern. Speichere ich nun die Daten auf eigenen Servern und vertraue sie nicht Firmen wie Google (Mail, Drive), Microsoft (Outlook.com, Skydrive) oder Amazon Cloud (Dropbox) an, dann erschwere ich auch erst einmal das ungewollte Lesen meiner Daten. Ich bin ja schliesslich kein Administrator auf dem anderen Server und weiss nicht wann sich wo auf deren Seite jemand potentiell dazwischen schaltet.

Meine Daten liegen also auf einem selbstgehosteten Server und ich baue eine verschluesselte Verbindung dahin auf. Die Daten auf dem Server selbst sind aber immer noch unverschluesselt gespeichert. Es kann also potentiell jemand ins Rechenzentrum gehen, sich den Server schnappen, analysieren und die Daten dort herunter ziehen. Was liegt da naeher als die Festplatten zu verschluesseln.

Mit LUKS (klick) steht dafuer unter Linux auch eine gute Loesung zur Verfuegung. Auf meinem Laptop oder meinem Arbeitsplatzrechner setze ich sie bereits ein. Ist ja auch kein Problem beim Booten das Passwort einzugeben. Das bei einem Server zu tun ist es schon sehr viel umstaendlicher, denn man sitzt ja eigentlich nie direkt davor…

Ich werde hier nun keine Anleitung schreiben wie man die Schritte 1:1 geht um seine Festplatte mit LUKS zu verschluesseln. Davon gibt es bereits genuegend im Netz. Einige Distributionen wie Debian bieten es sogar im Installer gleich an die Festplatte mit LVM zu erzeugen und dann mit LUKS zu verschluesseln. Die Stichworte beim Suchen nach entsprechenden Dokumentationen sind Distributionsname + „LUKS“ oder „cryptsetup“ oder „encrypted filesystem“. Nicht zu vergessen auch unter /usr/share/doc/cryptsetup/ nach zuschauen!

Der Clou an der Geschichte ist nun, das man einen dropbear SSH Server in die initramfs seines Servers hinzufuegen kann. So ist es moeglich waerend des Bootvorgangs eine SSH Verbindung in die initramfs aufzubauen und dort das Passwort zum entschluesseln der Festplatte einzugeben. Damit das ganze komfortabel wird, nutze ich dafuer SSH-Keys ohne Passwort in Verbindung mit einem Miniskript pro Maschine.

Boese boese mag sich nun mancher denken, aber alles halb so wild. Ich habe eine Maschine die ist unverschluesselt. Einfach, weil Sie es nicht benoetigt und dort nichts wichtiges abgespeichert ist. Auf dieser Maschine habe ich einen Ordner mit ecryptfs verschluesselt (klick fuer Anleitung). In diesem Ordner bewahre ich folgendes auf:

  1. private Keys fuer die Verbindung zu dem Dropbear Servern im initramfs der virtuellen Maschinen
  2. eigene known_hosts Datei dafuer
  3. Ein Skript pro VM das mir die Eingabe des Passworts erleichtert.

Das Skript sieht schematisch wie folgt aus:

#!/bin/bash
 
ssh -o "UserKnownHostsFile=known_hosts/known_hosts.initramfs" -i "keys/servername" root@1.2.3.4 "echo -ne "**TOPSECRET**" &gt;/lib/cryptsetup/passfifo"

Wenn ich nun einen Server neu starte bei dem die Festplatte verschluesselt ist, dann melde ich mich auf der unverschluesselten Maschine an, mounte den ecryptfs verschluesselten Ordner und muss dann nur noch das entsprechende Skript starten, z.B. ./unlock_servername und schon bootet die Maschine durch.

In diesem Kontext sicherlich noch einmal spannend ist auf einen drei Jahre alten Blogeintrag „Howto: virsh console“ zu verweisen um sich das ganze auch vom physikalischen Server aus anzuschauen ;-)

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.
  • Im sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.
  • Der siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.
  • Der achte Teil stellt webbasierte Dienste vor, die man selber hosten kann und dadurch die eigenen Daten unter mehr Kontrolle hat.

HowTo: Ordner mit ecryptfs verschluesseln

Wenn man auf einem Server einen Ordner durch Verschluesselung schuetzen moechte dann kann man das recht einfach mit ecrypt tun. Dazu die nachfolgend beschriebenen Schritte ausfuehren. Als erstes die notwendigen Pakete installieren:

sudo apt-get install ecryptfs-utils

Anschliessend das zu verschluesselnde Verzeichnis erstmalig mit ecryptfs ueber sich selbst mounten:

mkdir -p /path/to/folder
sudo mount -t ecryptfs /path/to/folder /path/to/folder

Die nun folgenden Fragen wie folgt beantworten:

  • Passphrase: **TOPSECRET**
  • Select cipher: aes
  • Select key bytes: 16
  • Enable plaintext passthrough: n
  • Enable filename encryption: n
  • Would you like to proceed with the mount: yes
  • Would you like to append sig…: yes

Zwischendrin wurde ausgegeben mit welchen Optionen gemountet wird. Dieses nun noch kopieren und in die /root/.ecryptfsrc einfuegen, fertig. Damit ich beim Abmelden nicht vergesse den mount wieder zu entfernen habe ich die folgenden Zeilen in meine ~/.bash_logout hinzugefuegt:

if [ "$(mount | grep /path/to/folder | grep ecryptfs | wc -l)" == "1" ]; then 
	echo "Unmounting /path/to/folder";
	sudo umount /path/to/folder
fi

Selbstredent muss mit sudo das Recht fuer den ausfuehrenden Nutzer existieren den umount Befehl fuer das Verzeichnis auszufuehren…