Schlagwort-Archiv: Planet

Tag für den Ubuntuusers.de Planeten.

SELinux Booleans

Bei SELinux Booleans handelt es sich um kleine Schalter, mit denen sich das Verhalten der SELinux-Richtlinien beeinflussen lässt. Dieser Artikel knüpft an die „Einführung in das grundlegende Konzept von SELinux“ an und erläutert die Verwendung von SELinux Booleans anhand eines einfachen Beispiels.

Hinweis: Das Beispiel aus diesem Artikel wurde auf einem RHEL/CentOS 7.3 getestet. Unter CentOS 7.2 funktioniert die hier gezeigte Konfiguration nicht. Für Details wird auf das Topic[2. Solved SELinux Booleans and httpd_enable_homedirs] im CentOS-Support-Forum verwiesen.

Im Einführungsartikel[3. „Einführung in das grundlegende Konzept von SELinux“] wurde SELinux dazu genutzt, um den Zugriff des Apache auf das DocumentRoot-Verzeichnis /var/www/html zu beschränken. Nun möchte der Webmaster den Benutzern gestatten, Webseiten über ihre HOME-Verzeichnisse zu veröffentlichen und aktiviert dazu die Konfiguration für das Modul Userdir.[4. Linux Basics: How To Enable Apache UserDir In CentOS 7/RHEL 7 {en}] [5. Enable Userdir in CentOS 7 {en}] [6. Apache: Benutzerspezifische Verzeichnisse – wiki.ubuntuusers.de]

[root@centos ~]$ cat /etc/httpd/conf.d/userdir.conf

    UserDir enabled
    UserDir public_html



    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    Require method GET POST OPTIONS


[root@centos ~]#

Nun kann ein Benutzer in seinem HOME-Verzeichnis den Ordner public_html erstellen und eine test.txt-Datei erstellen:

[jkastning@centos ~]$ mkdir public_html
[jkastning@centos ~]$ sudo chmod 711 /home/jkastning/
[jkastning@centos ~]$ sudo chmod 755 public_html/
[jkastning@centos ~]$ vim public_html/test.txt

Hello User

Nach einem Neustart des Dienstes httpd sollte sich nun die Datei index.html aus dem Benutzerverzeichnis abrufen lassen. Statt dessen wird der Zugriff verweigert.

apache_userdir_forbidden

httpd_enable_homdirs –> off

In den Logdateien finden sich Hinweise, die auf SELinux als Ursache hindeuten.

[root@centos ~]# tail /var/log/audit/audit.log|grep AVC
type=AVC msg=audit(1480446615.354:844): avc:  denied  { getattr } for  pid=23150 comm="httpd" path="/home/jkastning/public_html/index.html" dev="sda1" ino=1052157 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file

[root@centos ~]# tail /var/log/messages | grep SELinux
Nov 29 20:10:44 centos setroubleshoot: SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html. For complete SELinux messages. run sealert -l 13419731-cedd-4433-abb7-b2e7715d5636

Um weitere Informationen zu erhalten, führen wir das Kommando aus /var/log/messages aus (Ausgabe gekürzt):

[root@centos ~]# sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html.

*****  Plugin catchall_boolean (24.7 confidence) suggests   ******************

If you want to allow httpd to enable homedirs
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'None' man page for more details.
Do
setsebool -P httpd_enable_homedirs 1

In der obigen Ausgabe wird neben der Ursache auch gleich die Lösung mitgeliefert. Nach der Aktivierung des SELinux Boolean httpd_enable_homedirs kann der Inhalt der Datei index.html im Webbrowser abgerufen werden.

apache_userdir_allowed

httpd_enable_homedirs –> on

Damit wurde eine weitere Funktionalität von SELinux kurz vorgestellt. Für weiterführende Informationen sei auf die Manpages booleans(8)[6. booleans(8) – Linux man page {en}], getsebool(8)[7. getsebool(8) – Linux man page {en}] und setsebool(8)[8. setsebool(8) – Linux man page {en}] verwiesen.

Einführung in das grundlegende Konzept von SELinux

SELinux[1. SELinux – Wikipedia] (Security-Enhanced Linux; engl. „sicherheitsverbessertes Linux“) ist eine Erweiterung des Linux-Kernels, mit der eine zusätzliche Sicherheitsschicht in das Betriebssystem eingezogen wird.

In dieser Einführung wird das zu Grunde liegende Konzept kurz vorgestellt und erläutert, welche Modi SELinux besitzt, wie diese angezeigt und umgeschaltet werden können. An einem einfachen Beispiel mit dem Apache Webserver wird dargestellt, wie SELinux in der Praxis wirkt. Des Weiteren wird mit Hilfe des Beispiels das Vorgehen bei einer Fehleranalyse erläutert.

SELinux ist dazu gedacht, das bestehende Berechtigungskonzept unter Linux zu erweitern, um zu verhindern, dass kompromittierte Dienste auf Daten zugreifen, auf die kein Zugriff erforderlich ist.

Als einfaches Beispiel mag hier der Webserver Apache[2. Apache HTTP Server – Wikipedia] dienen.

Dieser liest die Dateien, welche er ausliefern soll, in der Standardkonfiguration aus dem dem Verzeichnis /var/www/html. Daneben darf der Dienst z.B. auch alle Verzeichnisse und Dateien unterhalb der Verzeichnisse /tmp und /var/tmp lesen.

user@host:~$ ls -ld /tmp
drwxrwxrwt. 5 root root 4096 Nov 27 19:05 /tmp
user@host:~$ ls -ld /var/tmp
drwxrwxrwt. 2 root root 4096 Nov 10 06:34 /var/tmp
user@host:~$

Grundsätzlich hat der Dienst Zugriff auf alle Verzeichnisse und Dateien, welche den Lese- bzw. Schreibzugriff für alle Benutzer erlauben.

SELinux kann nun dazu genutzt werden, um genau diesen Zugriff zu unterbinden. Die folgende Abbildung soll dies verdeutlichen:

selinux-example-apache

Mögliche Zugriffe mit und ohne SELinux am Beispiel des Apache

SELinux stellt einfach gesprochen ein Regelwerk dar, nach welchem bestimmt wird, auf welche Verzeichnisse, Dateien, Prozesse und Ports ein Dienst zugreifen darf. Dazu erhalten diese Objekte ein Label mit einem Security Context. Nur wenn das SELinux-Regelwerk den Zugriff von einer Ressource auf eine weitere Ressource explizit erlaubt, ist der Zugriff gestattet. Andernfalls wird die Interaktion unterbunden. Dabei unterscheidet SELinux die verschiedenen Label nach Kontexten. Diese sind:

  • user
  • role
  • type
  • sensitivity

Im Folgenden wird ausschließlich der Kontext „type“ weiter betrachtet. So besitzt z.B. der Dienst Apache das Label httpd_t, während Dateien unterhalb von /var/www/html das Label httpd_sys_content_t tragen. Da SELinux eine Regel besitzt, welche den Zugriff des Kontext httpd_t auf Dateien und Verzeichnisse mit dem Kontext httpd_sys_content_t gestattet, kann der Apache die Datei index.html aus dem Verzeichnis /var/www/html anzeigen:

output-index-html

Ausgabe der Datei /var/www/html/index.html

Obiger Screenshot enthält neben dem obligatorischen „Hallo Welt“ auch noch die Ausgabe des Verzeichnis-Listings, welches neben den üblichen Angaben wie Berechtigungen, Benutzer und Gruppe auch den SELinux-Kontext mit ausgibt. Wie man SELinux steuert und sich den Kontext von Verzeichnissen, Dateien und Prozessen anzeigen lässt, wird im Folgenden Abschnitt erläutert.

Steuerung von SELinux

SELinux kennt drei Modi:

  • Enforcing
  • Permissive
  • Disabled

In welchem Status sich SELinux befindet, kann mit dem Kommando getenforce abgefragt werden:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Obige Ausgabe bedeutet, dass SELinux im Modus „Enforcing“ ausgeführt wird. In diesem Modus verhindert SELinux Zugriffe, welche nicht explizit durch das Regelwerk erlaubt werden. Im Unterschied dazu werden diese Zugriffe im Modus „Permissive“ nicht verhindert, sie werden jedoch protokolliert. Dieser Modus eignet sich daher hervorragend, um das aktuelle Verhalten von Diensten zu analysieren und die Konfiguration ggf. anzupassen. Die Umschaltung zwischen den Modi „Enforcing“ und „Permissive“ kann zur Laufzeit erfolgen:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]# setenforce 0
[root@centos ~]# getenforce
Permissive
[root@centos ~]# setenforce 1
[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Der Standard-Modus wird in der Datei /etc/selinux/config festgelegt.

Anzeige der SELinux-Kontexte

Der kleine Punkt (im Screenshot rot markiert) hinter den Berechtigungen zeigt an, dass ein SELinux-Kontext für eine Datei bzw. ein Verzeichnis existiert:

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Welchen Kontext eine Datei bzw. ein Prozess besitzt, kann angezeigt werden, indem bekannte Kommandos mit der Option „-Z“ benutzt werden. Das folgende Listing zeigt einige Beispiele:

[root@centos ~]# ps -eZ | grep httpd
system_u:system_r:httpd_t:s0     2876 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2920 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2921 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2922 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2923 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2924 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2925 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     3152 ?        00:00:00 httpd
[root@centos ~]# ls -lisaZ /var/www/html/
total 12
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 ..
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
[root@centos ~]# ls -lisaZ /var/tmp
total 28
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
drwxr-xr-x. abrt abrt system_u:object_r:abrt_var_cache_t:s0 abrt
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-colord.service-MczkBW
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-cups.service-c3Aouq
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-httpd.service-oAqhlb
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-rtkit-daemon.service-xpSsO2
[root@centos ~]# ls -lisaZ /tmp |head -n4
total 96
drwxrwxrwt. root      root      system_u:object_r:tmp_t:s0       .
dr-xr-xr-x. root      root      system_u:object_r:root_t:s0      ..
-rw-r--r--. root      root      system_u:object_r:tmp_t:s0       anaconda.log
[root@centos ~]#

Die Datei index.html hat bei ihrer Erstellung im Verzeichnis /var/www/html automatisch den korrekten Kontext httpd_sys_content_t erhalten und kann daher im Webbrowser angezeigt werden. Wird eine Datei im Verzeichnis /tmp erstellt, erhält diese automatisch den Kontext user_tmp_t:

[root@centos ~]# echo 'TEST' > /tmp/test.txt
[root@centos ~]# ls -lisaZ /tmp/test.txt
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 /tmp/test.txt
[root@centos ~]#

Was tun, wenn’s klemmt?

Um zu erläutern, wie man einem Fehler auf die Spur kommt, baue ich zuerst einen ein. Dazu verschiebe ich die im vorangegangenen Abschnitt erzeugte Datei in das DocumentRoot des Apache und versuche, diese im Browser aufzurufen.

forbidden

Forbidden

SELinux verhindert den Zugriff des Dienstes „httpd“ auf die Datei „text.txt“, da keine Regel existiert, welche den Zugriff vom Kontext httpd_t auf user_tmp_t explizit erlaubt. Doch wie kann man dies feststellen, wenn man nicht bereits zu Beginn um den falschen Kontext weiß?

Zuerst wirft man einen Blick auf die Dateiberechtigungen, welche aber keinen Fehler erkennen lassen:

[root@centos ~]# ls -lZ /var/www/html/
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 test.txt
[root@centos ~]#

Da die Dateiberechtigungen als Fehlerquelle ausscheiden und in diesem Beispiel keine POSIX-ACL[3. ACL – wiki.ubuntuusers.de] verwendet werden, bleibt nur noch SELinux als Fehlerquelle übrig. Daher suchen wir einmal in /var/log/audit/audit.log nach Ereignissen vom Typ „AVC“:

[root@centos ~]# tail /var/log/audit/audit.log | grep AVC
type=AVC msg=audit(1480277043.225:537): avc:  denied  { open } for  pid=2922 comm="httpd" path="/var/www/html/test.txt" dev="sda1" ino=924457 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

Treffer! Um die Sache weiter zu analysieren, untersuchen wir als nächstes /var/log/messages (Ausgabe gekürzt). Hinweis: Unter RHEL 7 muss das Paket ’setroubleshoot-server‘ installiert sein, damit SELinux-Ereignisse auch in /var/log/messages geloggt werden (siehe Abschnitt 4.2. Which Log File is Used).

Nov 27 21:29:13 centos setroubleshoot: SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt. For complete SELinux messages. run sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a

Hier findet sich eine Bestätigung, dass SELinux den Zugriff blockiert hat und ein Vorschlag, wie dieser Vorfall genauer analysiert werden kann. Damit lassen sich umfassende Informationen abrufen, welche sogar die Lösung mit ausgeben (Ausgabe gekürzt):

[root@centos ~]$ sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a
SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt.

*****  Plugin restorecon (92.2 confidence) suggests   ************************

If you want to fix the label. 
/var/www/html/test.txt default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/test.txt

*****

Der Bericht gibt an, wie das Standard-Label für die Datei text.txt gesetzt sein sollte. Darüber hinaus ist dem Bericht der Befehl zu entnehmen, mit dem die Label wieder auf den Standardwert zurückgesetzt werden können. Nachdem dieser Befehl ausgeführt wurde, kann die Datei text.txt im Webbrowser geöffnet werden.

[root@centos ~]# /sbin/restorecon -v /var/www/html/test.txt
/sbin/restorecon reset /var/www/html/test.txt context unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
[root@centos ~]#
correct-selinux-context

Aufruf von test.txt mit korrektem SELinux-Kontext

Schlusswort

Es wurde in das grundlegende Konzept von SELinux und die möglichen Betriebsmodi eingeführt. Darüber hinaus wurde erläutert, wie man sich die zu einem Objekt gehörenden SELinux-Kontexte anzeigen lassen kann und wie diese auf einen Standard-Kontext zurückgesetzt werden können. Abschließend wurde ein kleiner Einblick in das Vorgehen zur Fehleranalyse gegeben.

Damit bin ich am Ende dieser kleinen Einführung angekommen, wobei das Thema SELinux damit noch lange nicht abschließend behandelt ist. Für weiterführende Informationen sei an dieser Stelle auf die Dokumentation der einzelnen Distributionen verwiesen.[4. RHEL 7: SELinux User’s and Administrator’s Guide: Basic and advanced configuration of Security-Enhanced Linux (SELinux) {en}] [5. SELinux – CentOS Wiki {en}] [6. SELinux – Fedora Project {en}]

Quellen und weiterführende Links

Benutzer die Ausführung eines Skripts mit sudo gestatten

In diesem kurzen Tutorial wird beschrieben, wie man einem normalen Benutzer das Recht einräumt, ein einzelnes Skript mit sudo auszuführen. Das Tutorial ist auf alle Linux-Distributionen anwendbar, welche sudo[1. sudo – Wikipedia] unterstützen.

Schritt 1: Skript und Benutzerkonto erstellen

Zuerst wird natürlich das Skript benötigt, welches der neue Benutzer später ausführen soll. Als Beispiel mag hier folgendes einfaches Beispiel dienen:

#!/bin/bash
echo "Hallo Welt."

Wichtig! Der Benutzer, welcher das Skript später ausführen soll, darf selbst keine Schreibrechte darauf besitzen. Andernfalls könnte er das Skript bearbeiten und durch eintragen von bash eine root-shell öffnen. Danke an Gerald für diesen wichtigen Hinweis.

Der Benutzer kann, sofern er nicht schon existiert, mit folgendem Kommando angelegt werden:

sudo adduser USERNAME

Schritt 2: /etc/sudoers konfigurieren

Um einem Benutzer das Recht zu verleihen, gibt es grundsätzlich mehrere Möglichkeiten.

Benutzer einer Gruppe hinzufügen

Auf vielen Linux-Distributionen existiert bereits eine Gruppe, deren Mitglieder die Berechtigung zur Verwendung von sudo besitzen. Unter Ubuntu ist dies z.B. die Gruppe ’sudo‘. Unter RHEL, CentOS und Fedora ist dies bspw. die Gruppe ‚wheel‘. Um welche Gruppe es sich konkret handelt, kann in der Datei /etc/sudoers nachgeschlagen werden. Dort findet sich auf einem Ubuntu 16.04 LTS z.B. folgender Eintrag:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Da dem Benutzer im hier beschriebenen Fall jedoch nur erlaubt werden soll, ein einziges Skript mittels sudo auszuführen, ist diese Methode ungeeignet.

Benutzer in /etc/sudoers

Um einem Benutzer das Recht zu gewähren, ein bestimmtes Skript oder Programm mit sudo auszuführen, kann der Benutzer wie folgt in die Datei /etc/sudoers eingetragen werden.

Wichtig! Die Datei /etc/sudoers sollte nur als root mit dem Kommando visudo editiert werden, da hiermit eine Syntaxprüfung erfolgt. Eine Beschädigung der Datei /etc/sudoers, z.B. durch Syntaxfehler, kann dazu führen, dass das gesamte System unbrauchbar wird.

# User privilege specification
USERNAME    ALL=/path/to/script.sh

Mit obiger Zeile wird dem Benutzer ‚USERNAME‘ erlaubt, das Skript unter /path/to/script.sh mit sudo auszuführen.

Diese Methode ist bereits geeignet, um die gestellte Aufgabe zu lösen.

Datei unter /etc/sudoers.d/ erstellen

Unter aktuellen Versionen von Debian, Ubuntu, RHEL, CentOS und Fedora besteht die Möglichkeit, eine Datei im Verzeichnis /etc/sudoers.d/ zu erstellen, welche den Eintrag aus dem vorangegangenen Abschnitt enthält. Voraussetzung dafür ist, dass die Datei /etc/sudoers folgende Direktive enthält:

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Beachte: Das Zeichen ‚#‘ vor ‚includedir‘ stellt in diesem Fall kein Kommentarzeichen dar.

Diese Methode hat den Vorteil, dass die Datei /etc/sudoers unverändert bleibt und es bei Updates nicht zu einem Versionskonflikt kommen kann.

Fazit

Mittels /etc/sudoers ist es möglich, sudo-Berechtigungen granular an Benutzer zu delegieren. Neben dem in diesem Tutorial beschriebenen Beispiel existieren noch weitere Möglichkeiten. Beispiele dazu finden sich in der Manpage von sudoers.

ejabberd mit Let’s Encrypt Zertifikat

In diesem Artikel wird dokumentiert, wie ein Let’s Encrypt[1. https://letsencrypt.org/ {en}] [2. Let’s Encrypt – Wikipedia] Zertifikat für ejabberd eingerichtet werden kann. Dabei stütze ich mich auf mein TLS-Kochbuch[3. TLS/SSL Kochbuch: Rezepte für die Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)].

Die Dokumentation bezieht sich dabei auf meine konkrete Installation und ist nicht ohne Transferleistung auf andere Installationen übertragbar. Es ist also keine Schritt-für-Schritt-Anleitung! Der Artikel bietet über die Dokumentation hinaus jedoch auch Hintergrundinformationen und Wissenswertes für abweichende Konfigurationen.

Ausgangssituation

In meiner Umgebung ist ejabberd auf einem Ubuntu Server 14.04 LTS[4. Trusty Tahr – wiki.ubuntuusers.de] installiert und nutzt ein TLS-Zertifikat von CAcert[5. https://www.cacert.org/ {en}] [6. CAcert – Wikipedia].

Außer ejabberd läuft auf dem Server auch noch ein Webserver, welcher verschiedene Webseiten ausliefert.

Daneben ist bereits der Let’s Encrypt Client acme-tiny[7. Fork des acme-tiny Clients auf GitHub {en}] installiert, dessen Verwendung in Abschnitt 3.6.2 TLS-Kochbuch erläutert wird.

Der Ablauf im Überblick

Wie vorstehend bereits erwähnt, verwendet ejabberd bereits ein TLS-Zertifikat, welches nun durch ein Let’s Encrypt Zertifikat ersetzt werden soll. Der Ablauf gliedert sich dabei im Wesentlichen in zwei Teile. Zuerst wird ein Let’s Encrypt Zertifikat für den Hostnamen des ejabberd-Servers ausgestellt. Anschließend wird ejabberd konfiguriert, um zukünftig dieses Zertifikat zu nutzen.

Zur Durchführung der Domainvalidierung wird ein VirtualHost für den Hostnamen des ejabberd-Servers konfiguriert. Da sich die genaue Konfiguration je nach verwendeter Webserver-Software unterscheidet, wird hier nicht näher darauf eingegangen, sondern auf die Dokumentation des jeweiligen Webservers verwiesen.

Generierung des TLS-Zertifikats

Nun wird mit Hilfe von OpenSSL[8. OpenSSL: Cryptography and SSL/TLS Toolkit {en}] [9. OpenSSL – Wikipedia] ein privater Schlüssel und eine Zertifikatsanfrage (engl. Certificate Signing Request (CSR)) erstellt. Beide Schritte werden ausführlich in Abschnitt 3.1 TLS-Kochbuch beschrieben.

Ich persönlich generiere den privaten Schlüssel und den CSR stets offline auf einem sicheren Computer. Anschließend lade ich sie zum Server hoch. Die Zugriffsrechte auf den Schlüssel sind so eingeschränkt, dass nur root und der Benutzer, unter dem der Webserver ausgeführt wird, diesen Schlüssel lesen dürfen.

Da bereits eine Installation von acme-tiny auf dem Server existiert und bereits ein Account-Key erstellt wurde, wird dieser in dem Verzeichnis verlinkt, in dem auch der private Schlüssel und der CSR liegen.

Nun kann das TLS-Zertifikat angefordert werden. Wie dies im Detail funktioniert, wird in Abschnitt 3.6.2 im TLS-Kochbuch beschrieben.

Sind bis hier alle Schritte erfolgreich gewesen, liegen nun Schlüssel und Zertifikat in einem Verzeichnis vor.

$ python acme-tiny/acme_tiny.py --account-key /var/www/sites/ssl/account.key --csr /var/www/sites/ssl/request.csr --acme-dir /var/www/sites/public/.well-known/acme-challenge/ > /var/www/sites/ssl/cert.crt
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying fqdn...
fqdn verified!
Signing certificate...
Certificate signed!

$ ls -l /var/www/sites/ssl/
-rw-r—– 4 root root account.key
-rw-r—– 1 root www-data cert.crt
-rw-r—– 1 root root priv.key
-rw-r—– 1 root root request.csr

Zertifikat für ejabberd präparieren

Der Dienst ejabberd erwartet, dass der private Schlüssel, das Zertifikat und die Zertifikatskette in einer Datei übergeben werden.[10. Ejabberd SSL Certificate – Raymii.org {en}] Dazu wird noch die Zertifikatskette von Let’s Encrpyt[11. Let’s Encrypt: Chain of Trust {en}] heruntergeladen und ebenfalls in /var/www/sites/ssl/ gespeichert.

Das folgende Skript zeigt, wie das Zertifikat erzeugt, die Zertifikatsdatei für ejabberd zusammengesetzt und der Dienst neugestartet wird:

#!/bin/bash
# Datum: 2016-11-13
# Autor: Joerg Kastning <webmaster(aet)my-it-brain(Punkt)de>
#
# Beschreibung:
# Dieses Skript dient der Erneuerung des TLS-Zertifikats fuer
# jabber.my-it-brain.de über Let's Encrypt mit dem Client acme-tiny-by-frezbo.

DIR='/var/www/sites/ssl'

# Erneuerung des Zertifikats
python acme-tiny-by-frezbo/acme_tiny.py --account-key ${DIR}/account.key --csr ${DIR}/request.csr --acme-dir /var/www/sites/fqdn/.well-known/acme-challenge/ > ${DIR}/cert.crt

# Erzeugung der Zertifikatsdatei fuer ejabberd
cat ${DIR}/priv.key ${DIR}/cert.crt ${DIR}/lets-encrypt-x3-cross-signed.pem >${DIR}/ejabberd_cert.pem

sudo chown root:ejabberd ${DIR}/ejabberd_cert.pem
sudo chmod 0640 ${DIR}/ejabberd_cert.pem
sudo mv ${DIR}/ejabberd_cert.pem /etc/ejabberd/ejabberd_cert.pem

# Neustart von ejabberd
sudo service ejabberd restart

Abschluss der Migration

Durch den im vorangegangenen Abschnitt dargestellten Code wird das neue Let’s Encrypt Zertifikat an der gleichen Stelle und unter dem gleichen Dateinamen wie das alte Zertifikat abgelegt. Auf diese Weise muss die Konfiguration von ejabberd nicht weiter angepasst werden. Der Dienst lädt nach einem Neustart das neue Zertifikat. Die Migration ist damit abgeschlossen.

Let’s Encrypt Zertifikate besitzen eine Gültigkeit von 90 Tagen.[12. Let’s Encrypt: Why ninety-day lifetimes for certificates? {en}] Um die Erneuerung des Zertifikats zu automatisieren, wird das Skript „SmartRenew.sh“ verwendet (siehe Abschnitt 5.4 im TLS-Kochbuch).

Quellen und weiterführende Links:

Der eigene Mailserver – TLS-Migration zu Let’s Encrypt

Durch die Ankündigung von Mozilla, den Zertifizierungsstellen StartCom und WoSign das Vertrauen entziehen zu wollen,[1. Golem: Mozilla will Startcom und Wosign das Vertrauen entziehen] [2. Mozilla’s proposed conclusion for community discussion, regarding the matter of WoSign and StartCom. {en}] entstand für mich Handlungsbedarf. Denn ich wollte die Zertifikate dieser Anbieter nun so schnell wie möglich loswerden.

In Teil 2 meiner Artikelreihe „Der eigene Mailserver“ wird ein TLS/SSL-Zertifikat von StartSSL verwendet, um dieses zur Absicherung von Postfix, Dovecot und dem Webmailer Roundcube zu verwenden. An dieser Stelle halte ich nun die Umstellung auf TLS-Zertifikate von Let’s Encrypt fest.

Für die Bereitstellung und automatisierte Erneuerung der Zertifikate verwende ich certbot-auto.[3. Automatically enable HTTPS on your website with EFF’s Certbot, deploying Let’s Encrypt certificates. {en}] Dessen Installation und Nutzung wird in Abschnitt 3.6.1 TLS-Kochbuch[4. TLS-Kochbuch – Rezepte für die Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)] beschrieben.

Das von cerbot-auto erzeugte Zertifikat und der dazugehörige private Schlüssel werden unter dem Pfad /etc/letsencrypt/live/ abgelegt. Um das Zertifikat in die gewünschten Dienste einzubinden, ist der Pfad zum Zertifikat in den Konfigurationsdateien der Dienste zu aktualisieren. Das folgende Listing gibt den Namen der Konfigurationsdateien und der anzupassenden Parameter wieder:

# /etc/nginx/sites-available/roundcube
ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem;

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/FQDN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/FQDN/privkey.pem

# /etc/dovecot/conf.d/99-mail-stack-delivery.conf
ssl_cert =

Die Konfiguration der Dienste muss anschließend neu geladen werden. Um dies bei zukünftigen Erneuerungen des Zertifikats zu automatisieren, habe ich ein kleines Skript renew_certs.sh erstellt, welches täglich via Cron ausgeführt wird.

#!/bin/sh
/home/USERNAME/certbot/certbot-auto renew --quiet --no-self-upgrade
sudo service nginx reload
sudo service postfix reload
sudo service dovecot reload

certbot-auto renew erneuert das Zertifikat, sobald die Gültigkeitsdauer kleiner 30 Tage ist. Durch die tägliche Ausführung soll sichergestellt werden, dass die Aktualisierung auch dann rechtzeitig gelingt, sollte die Schnittstelle von Let’s Encrypt vorübergehend nicht erreichbar sein.

Ansible: Patch-Management für Red Hat Systeme

Als Linux-Distribution für den Betrieb im Rechenzentrum fiel unsere Wahl vor einiger Zeit auf Red Hat Enterprise Linux. Zu meinen Aufgaben gehört es, ein Patch-Management für diese Systeme zu entwickeln, welches die folgenden Anforderungen erfüllt:

  1. Die zu aktualisierenden Hosts werden in Gruppen im Ansible Inventory verwaltet. Eine Gruppe entspricht dabei einer Stage/Phase für das Patch-Management.
  2. An definierten Stichtagen sollen automatisiert fehlende Sicherheitsaktualisierungen auf den Systemen in den verschiedenen Stages/Phasen eingespielt werden können.
  3. Dabei sollen ausschließlich Pakete aktualisiert werden, für die Red Hat Security Advisory veröffentlicht wurden.
  4. Wenn Pakete aktualisiert wurden, soll der Host anschließend neugestartet werden.

Ich habe mich entschieden, diese Anforderungen durch die Verwendung von Ansible zu erfüllen. Wem Ansible noch kein Begriff ist, möge einen Blick in die Quellen am Ende des Artikels werfen.[1. Ansible – IT-Automation für Jedermann] [2. Ansible Documentation {en}] [3. Linux-Benutzerkonten mit Ansible verwalten] [4. Das Modul yum_repository] [5. Die Module copy und cron]

Mit den Anregungen meines Arbeitskollegen habe ich dazu das folgende Playbook erstellt, welches die Rolle rhel-patchmanagement auf allen Hosts mit einem Red Hat Betriebssystem ausführt:

---
- hosts: all

  tasks:
    - name: Group by OS
      group_by: key=os_{{ ansible_distribution }}
      changed_when: False

- hosts: os_RedHat
  roles:
    - rhel-patchmanagement

Die Rolle rhel-patchmanagement besteht aus den beiden folgenden Dateien:

  • roles/patch_rhel/tasks/main.yml
  • roles/patch_rhel/vars/main.yml

roles/patch_rhel/vars/main.yml:

---
rhsa_to_install: RHSA-2016:1626,RHSA-2016:1628,RHSA-2016:1633

Obiges Listing gibt ein kurzes Beispiel, wie die Red Hat Security Advisory (RHSA) Nummern einer Variablen zugewiesen werden können. Die Variable rhsa_to_install wird dann in der Task-Datei verwendet.

roles/patch_rhel/tasks/main.yml:

---
  - name: Install Red Hat Security Advisory (RHSA)
    command: yum -y update-minimal --advisory {{ rhsa_to_install }}
    register: yum_output
  - debug: var=yum_output

  - name: Reboot Host if packages were updated
    shell: sleep 2 && shutdown -r now "Ansible updates triggered"
    async: 1
    poll: 0
    ignore_errors: true
    when: ('"Complete!" in "{{ yum_output.stdout_lines[-1] }}"') or
          ('"Komplett!" in "{{ yum_output.stdout_lines[-1] }}"')

  - name: waiting for access server
    local_action: wait_for
      host={{ inventory_hostname }}
      state=started
      port=22
      delay=30
      timeout=300
      connect_timeout=15

Zuerst wird das Kommando zur Aktualisierung der zu den angegebenen RHSA gehörenden Pakete auf den Hosts ausgeführt. Dabei wird die Ausgabe des Kommandos yum auf den Hosts der Variable yum_output zugewiesen.[6. Registered Variables] Diese Variable wird im nächsten Schritt ausgewertet, um zu ermitteln, ob Pakete aktualisiert wurden. Ist dies der Fall, wird der Host neugestartet.

Erklärung: Wurden Pakete aktualisiert, steht in der letzten Zeile der YUM-Ausgabe der Ausdruck „Complete!“. "{{ yum_output.stdout_lines[-1] }}" dereferenziert die Variable und liefert die Ausgabe des YUM-Kommandos als Liste zurück. Dabei wird in diesem Fall auf das letzte Element der Liste zugegriffen. Enthält diese Zeile den genannten Ausdruck, wird der Host neugestartet. Hinweis: Die zweite Zeile der when-Bedingung aus dem oberen Listing dient der Behandlung einer deutschsprachigen Ausgabe. In diesem Fall wird das Schlüsselwort „Komplett!“ ausgegeben und in der Variable gespeichert.

Der letzte Task wartet 30 Sekunden ab, um dem Host Zeit für den Neustart zu geben und prüft, ob eine Verbindung hergestellt werden kann. Damit soll sichergestellt werden, dass der Host nach dem Neustart wieder korrekt hochfährt.

Damit sind die Anforderungen aus Punkt 2 und 3 erfüllt. Um auch noch die Anforderung aus Punkt 1 zu erfüllen, setze ich folgendes Wrapper-Skript ein, welches das Playbook zu den definierten Stichtagen ausführen soll:

#!/bin/sh

DOM=`date +%d`
DOW=`date +%w`
LOG="/var/log/ansible/patch_run_`date +%Y-%m-%d`.log"
SETUP_LOG="/var/log/ansible/setup_patch_run_`date +%Y-%m-%d`.log"
SSH_KEY="/pfad/zum/ssh-key"
PLAYBOOK="/data/ansible/patch_rhel.yml"
CREATEVARS="/pfad/zu/roles/rhel-patchmanagement/create_vars.sh"

# Run Patch-Management ad-hoc in the specified phase.
# Example: './run_rhel_patch_mgmt.sh NOW rhel-patch-phase1'
if [ "${1}" = "NOW" ] && [ -n "${2}" ]
then
  ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit="${2}" >>$LOG 2>&1
  exit
fi

if [ "${1}" = "NOW" ] && [ -z "${2}" ]
then
  echo "ERROR: Second argument is missing."
  echo "Example: './run_rhel_patch_mgmt.sh NOW rhel-patch-phase1'"
  exit
fi

# Setup the next patchcycle
if [ "$DOW" = "2" ] && [ "$DOM" -gt 0 ] && [ "$DOM" -lt 8 ]
then
    $CREATEVARS > $SETUP_LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase1 on the second Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 7 ] && [ "$DOM" -lt 15 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase1 > $LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase2 on the third Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 14 ] && [ "$DOM" -lt 22 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase2 > $LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase3 on the fourth Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 21 ] && [ "$DOM" -lt 29 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase3 > $LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase4 on the fourth Wednesday of a month
if [ "$DOW" = "3" ] && [ "$DOM" -gt 21 ] && [ "$DOM" -lt 30 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase4 > $LOG 2>&1
fi

Mit diesem Wrapper-Skript möchte ich dafür sorgen, dass an jedem 2. Dienstag im Monat die RSHA-Aktualisierungen auf den Hosts in der rhel-patch-phase1, jeden 3. Dienstag in der rhel-patch-phase2, jeden 4. Dienstag in der rhel-patch-phase3 und jeden 4. Mittwoch in rhel-patch-phase4 installiert werden.

So kann sichergestellt werden, dass die Informationen aus den RHSA alle Hosts erreichen. Gleichzeitig wird den Betreibern der Hosts die Gelegegnheit gegeben, die Aktualisierungen bis zu den genannten Stichtagen selbst einzuspielen. Damit sollte ich auch an Punkt 1 einen Haken dran machen können.

Die Ansible-Rolle und dazugehörende Skripte und Beispiel-Dateien findet ihr auf:

Fragen zur Anwendung, Konfiguration und Nutzung des RHEL-Patchmanagements könnt ihr gerne auf GitHub oder hier in den Kommentaren stellen.

Aktualisiert am: 07.09.2018

Kurz vorgestellt: Mozilla SSL Configuration Generator

In diesem Artikel möchte ich euch kurz den Mozilla SSL Configuration Generator vorstellen, auf den mich ein Kollege aufmerksam machte.

mozilla_ssl_configuration_generator

Mozilla SSL Configuration Generator

Es handelt sich dabei um eine Seite, die dabei hilft, valide Konfigurationen für verschiedene Webserver wie Apache, NGINX, Lighttpd, HAProxy oder AWS ELB zu erstellen. Man gibt dazu den verwendeten Webserver, dessen Version und die OpenSSL Version an. Die Seite erstellt daraufhin die Konfiguration, welche per Copy&Paste übernommen werden kann. Lediglich die enthaltenen Pfadinformationen sind an die eigenen Bedürfnisse anzupassen.

mozilla_ssl_configuration_generator_nginx

Konfiguration für nginx 1.4.6 | modern profile | OpenSSL 1.0.1e

Neben der Konfiguration erhält man auch noch die Information dazu geliefert, welche Browser mit der erstellten Version kompatibel sind.

In einer ersten Stichprobe scheint die Seite ganz brauchbare Ergebnisse zu liefern. Ich freue mich über eure Meinungen und Erfahrungen zu diesem Dienst.

Bei positiver Resonanz nehme ich einen Hinweis auf diesen Dienst in eine kommende Version meines TLS-Kochbuchs auf.

Installation von Seafile auf einem Ubuntu/Debian Server

Diese Anleitung beschreibt, wie die Software Seafile[1. Wikipedia Artikel zu Seafile}] auf einem Ubuntu Server installiert werden kann. Sie gilt prinzipiell auch für Debian. Jedoch müssen einzelne Schritte ggf. angepasst werden.

Hinweis zu Seafile Version 6.2: Bitte beachten Sie bei der Installation von Seafile in Version 6.2 den Kommentar von Christoph weiter unten. Ich Danke Christoph für diesen Hinweis.

Getestete Versionen

BetriebssystemUbuntu 14.04 LTS Server
WebserverNGINX 1.4.6
DatenbankserverMySQL 5.6
Seafile5.1.4 64bit

Einleitung

Seafile ist eine freie Software, um Dateien zentral auf einem eigenen Server zu speichern (Filehosting). Benutzer können auf ihre Daten über eine Webschnittstelle zugreifen oder über Desktop-Clients synchronisieren. Quelle: Wikipedia {de}

Seafile[2. Seafile Homepage {en}] bildet damit einen Teil des Funktionsumfangs bekannter Open Source Projekte wie ownCloud und Nextcloud ab, konzentriert sich dabei jedoch auf die „Sync+Share“-Funktion für Dateien. Jan Karres hat in seinem Blog einen schönen Artikel über den Vergleich ownCloud vs Seafile geschrieben, welcher die Eigenschaften sowie die Vor- und Nachteile beider Projekte erläutert.

Bei dem hier vorliegenden Anwendungsfall habe ich mich für Seafile entschieden, da die einzige Anforderung im Sync+Share von Dateien besteht. Seafile bietet im Gegensatz zu ownCloud auf diesem Gebiet auch clientseitige Verschlüsselung[3. How to Use Encrypted Libraries] an. Die zukünftigen Anwender sind im Umgang bereits geübt und die Sync-Clients bereits auf den meisten ihrer Endgeräte installiert.

Um dieser Anleitung folgen zu können, werden grundlegende Kenntnisse in der Administration eines Linuxservers vorausgesetzt.

Anleitung

Die folgende Anleitung wurde auf Basis der Artikel von Jan Karres[4. Raspberry Pi: Owncloud-Alternative Seafile Server installieren] und André P.[5. Seafile 4.0.x mit Nginx und MySQL-Backend auf Debian/Ubuntu] erstellt.

Voraussetzungen

Folgende Dienste müssen auf dem Server installiert und funktionsfähig sein, um Seafile installieren zu können:

Als Servername wird im Folgenden stets seafile verwendet. Dieser ist an den gewünschten Servernamen der eigenen Installation anzupassen.

Installation und Konfiguration

Zuerst werden die von Seafile benötigten Abhängigkeiten installiert:

sudo apt-get install python2.7 python-setuptools python-simplejson python-imaging python-mysqldb

Im zweiten Schritt wird ein Systembenutzer[9. Der Unterschied zwischen einem Systembenutzer und einem normalen Benutzer] erstellt, dessen Home-Verzeichnis die gesamte Seafile-Installation aufnehmen wird. Der Benutzername kann dabei frei gewählt werden.

sudo adduser --system --group BENUTZERNAME

Mit den folgenden Befehlen wird der Benutzer gewechselt, die benötigte Verzeichnisstruktur erstellt, die Software heruntergeladen und entpackt.

# Wechselt zum erstellten Systembenutzer für die Seafile-Installation
sudo su - BENUTZERNAME -s /bin/bash

# Erstellen der Verzeichnisstruktur
mkdir -p seafile/installed && cd seafile/installed
wget wget https://download.seafile.de/seafile-server_latest_x86-64.tar.gz

# Archiv in das Zielverzeichnis entpacken und zurück ins Home-Verzeichnis wechseln
tar -xzvf *tar.gz -C ../ && cd ..

Im Home-Verzeichnis sollte die Verzeichnisstruktur nun wie folgt aussehen:

seafile@rs212997:/home/seafile/seafilesrv$ tree -L 2
.
├── installed
│   └── seafile-server_latest_x86-64.tar.gz
└── seafile-server-5.1.3
    ├── check_init_admin.py
    ├── reset-admin.sh
    ├── runtime
    ├── seaf-fsck.sh
    ├── seaf-fuse.sh
    ├── seaf-gc.sh
    ├── seafile
    ├── seafile.sh
    ├── seahub
    ├── seahub.sh
    ├── setup-seafile-mysql.py
    ├── setup-seafile-mysql.sh
    ├── setup-seafile.sh
    └── upgrade

6 directories, 11 files

Nun wechselt man in das Verzeichnis mit der Software (in diesem Fall seafile-server-5.1.3) und führt das Skript setup-seafile-mysql.sh aus. Die Antworten auf die Fragen sind selbstverständlich an die eigene Umgebung anzupassen.

./setup-seafile-mysql.sh 
Checking python on this machine ...
  Checking python module: setuptools ... Done.
  Checking python module: python-imaging ... Done.
  Checking python module: python-mysqldb ... Done.

-----------------------------------------------------------------
This script will guide you to setup your seafile server using MySQL.
Make sure you have read seafile server manual at

        https://github.com/haiwen/seafile/wiki

Press ENTER to continue
-----------------------------------------------------------------


What is the name of the server? It will be displayed on the client.
3 - 15 letters or digits
[ server name ] seafile

What is the ip or domain of the server?
For example: www.mycompany.com, 192.168.1.101
[ This server's ip or domain ] seafile.domain.tld

Where do you want to put your seafile data?
Please use a volume with enough free space
[ default "/home/BENUTZERNAME/seafilesrv/seafile-data" ] 

Which port do you want to use for the seafile fileserver?
[ default "8082" ] 

-------------------------------------------------------
Please choose a way to initialize seafile databases:
-------------------------------------------------------

[1] Create new ccnet/seafile/seahub databases
[2] Use existing ccnet/seafile/seahub databases

[ 1 or 2 ] 1

What is the host of mysql server?
[ default "localhost" ] 

What is the port of mysql server?
[ default "3306" ] 

What is the password of the mysql root user?
[ root password ] 

verifying password of user root ...  done

Enter the name for mysql user of seafile. It would be created if not exists.
[ default "root" ] seafile_user

Enter the password for mysql user "seafile_user":
[ password for seafile_user ] 

Enter the database name for ccnet-server:
[ default "ccnet-db" ] my-ccnet-db

Enter the database name for seafile-server:
[ default "seafile-db" ] my-seafile-db

Enter the database name for seahub:
[ default "seahub-db" ] my-seahub-db

---------------------------------
This is your configuration
---------------------------------

    server name:            seafile
    server ip/domain:       seafile.domain.tld

    seafile data dir:       /home/BENUTZERNAME/seafilesrv/seafile-data
    fileserver port:        8082

    database:               create new
    ccnet database:         my-ccnet-db
    seafile database:       my-seafile-db
    seahub database:        my-seahub-db
    database user:          seafile_user



---------------------------------
Press ENTER to continue, or Ctrl-C to abort
---------------------------------

Generating ccnet configuration ...

done
Successly create configuration dir /home/BENUTZERNAME/seafilesrv/ccnet.
Generating seafile configuration ...

Done.
done
Generating seahub configuration ...

----------------------------------------
Now creating seahub database tables ...

----------------------------------------

creating seafile-server-latest symbolic link ...  done




-----------------------------------------------------------------
Your seafile server configuration has been finished successfully.
-----------------------------------------------------------------

run seafile server:     ./seafile.sh { start | stop | restart }
run seahub  server:     ./seahub.sh  { start  | stop | restart  }

-----------------------------------------------------------------
If you are behind a firewall, remember to allow input/output of these tcp ports:
-----------------------------------------------------------------

port of seafile fileserver:   8082
port of seahub:               8000

When problems occur, Refer to

        https://github.com/haiwen/seafile/wiki

for information.

Möchte man Seafile via HTTPS nutzen, sind noch zwei Dateien anzupassen. Zuerst wird in die Datei ~/seafilesrv/conf/ccnet.conf der Parameter SERVICE_URL wie folgt angepasst:

SERVICE_URL = https://seafile.domain.tld:8000

Die zweite zu bearbeitende Datei ist seahub_settings.py. Hier wird am Ende der Datei die folgende Zeile eingefügt:

FILE_SERVER_ROOT = 'https://seafile.domain.tld/seafhttp'

Durch manuelles Starten der Dienste wird der Administrator-Account erstellt. Das folgende Listing zeigt die auszuführenden Befehle und Abfragen:

:~$ ~/seafilesrv/seafile-server-latest/seafile.sh start

[09/02/16 21:56:00] ../common/session.c(132): using config file /home/BENUTZERNAME/seafilesrv/conf/ccnet.conf
Starting seafile server, please wait ...
Seafile server started

Done.
:~$ ~/seafilesrv/seafile-server-latest/seahub.sh start-fastcgi

LC_ALL is not set in ENV, set to en_US.UTF-8
Starting seahub (fastcgi) at 127.0.0.1:8000 ...

----------------------------------------
It's the first time you start the seafile server. Now let's create the admin account
----------------------------------------

What is the email for the admin account?
[ admin email ] EURE E-MAIL-ADRESSE

What is the password for the admin account?
[ admin password ] SICHERESPASSWORThttp://start.ubuntu.com/16.04/Google/?sourceid=hphttp://start.ubuntu.com/16.04/Google/?sourceid=hp

Enter the password again:
[ admin password again ] SICHERESPASSWORT



----------------------------------------
Successfully created seafile admin
----------------------------------------




Seahub is started

Done.

Zum Abschluss werden die manuell gestarteten Dienste wieder beendet:

:~$ ~/seafilesrv/seafile-server-latest/seafile.sh stop
:~$ ~/seafilesrv/seafile-server-latest/seahub.sh stop

Um sicherzustellen, dass der lokale Seafile-Webdienst nicht aus dem Internet erreichbar ist, sollte folgender Block in der Datei ~/seafilesrv/conf/seafile.conf vorhanden sein:

[fileserver]
host=127.0.0.1
port=8082

An dieser Stelle wird die aktuelle Shell mit exit verlassen. Von nun an kann mit sudo oder als root weitergearbeitet werden.

Konfiguration von NGINX

Für NGINX wird ein neuer VirtualHost für die Domain seafile.domain.tld erstellt. Wird die Konfiguration aus folgendem Listing übernommen, so sind mindestens die Werte für den root-Pfad, server_name, ssl_certificate und ssl_certificate_key an die eigene Konfiguration anzupassen.

server {
        listen       80;
        server_name  seafile.domain.tld;
        rewrite ^/(.*) https://$server_name/$1 permanent;
}
server {
        listen 443; #IPv4
        #listen [::]:443; # IPv6
        ssl on;
        ssl_certificate /etc/nginx/certs/ssl-unified.crt;
        ssl_certificate_key /etc/nginx/certs/ssl.key;
        server_name seafile.domain.tld;

        location / {
                fastcgi_pass    127.0.0.1:8000;
                fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param   PATH_INFO           $fastcgi_script_name;

                fastcgi_param   SERVER_PROTOCOL     $server_protocol;
                fastcgi_param   QUERY_STRING        $query_string;
                fastcgi_param   REQUEST_METHOD      $request_method;
                fastcgi_param   CONTENT_TYPE        $content_type;
                fastcgi_param   CONTENT_LENGTH      $content_length;
                fastcgi_param   SERVER_ADDR         $server_addr;
                fastcgi_param   SERVER_PORT         $server_port;
                fastcgi_param   SERVER_NAME         $server_name;

                fastcgi_param   HTTPS on;
                fastcgi_param   HTTP_SCHEME https;
        }

        location /seafhttp {
                rewrite ^/seafhttp(.*)$ $1 break;
                proxy_pass http://127.0.0.1:8082;
                client_max_body_size 0;
        }

        location /media {
                root /home/BENUTZERNAME/seafilesrv/seafile-server-latest/seahub;
        }
}

Mit der oben stehenden Konfiguration erfolgt automatisch eine Weiterleitung von HTTP auf HTTPS. Wer für die Beantragung und Implementierung des Zertifikats Anleitung benötigt oder die Installation zusätzlich noch mit HSTS und HPKP schützen möchte, sei auf mein TLS-Kochbuch[10. Kapitel 4, TLS-Kochbuch mit Rezepten zur Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)] verwiesen.

Konfiguration des Seafile-Dienstes

Zur Konfiguration des Dienstes bediene ich mich der Arbeit aus dem Artikel von André P. Dazu wird die Datei /etc/init.d/seafile mit folgendem Inhalt erstellt. Die Parameter user und seafile_dir sind dabei an die eigene Installation anzupassen.

#!/bin/bash

### BEGIN INIT INFO
# Provides:          seafile
# Required-Start:    $local_fs $remote_fs $network
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Starts Seafile and Seahub
# Description:       starts Seafile and Seahub
### END INIT INFO

#### CONFIG START ####
user=seafile
seafile_dir=/srv/seafile/servername
##### CONFIG END #####

script_path=${seafile_dir}/seafile-server-latest
seafile_init_log=${seafile_dir}/logs/seafile.init.log
seahub_init_log=${seafile_dir}/logs/seahub.init.log
[ -d ${seafile_dir}/logs ] || mkdir ${seafile_dir}/logs && chown $user:$user ${seafile_dir}/logs

# Change the value of fastcgi to true if fastcgi is to be used
fastcgi=true
# Set the port of fastcgi, default is 8000. Change it if you need different.
fastcgi_port=8000

case "$1" in
        start)
                sudo -u ${user} ${script_path}/seafile.sh start >> ${seafile_init_log}
                if [  $fastcgi = true ];
                then
                        sudo -u ${user} ${script_path}/seahub.sh start-fastcgi ${fastcgi_port} >> ${seahub_init_log}
                else
                        sudo -u ${user} ${script_path}/seahub.sh start >> ${seahub_init_log}
                fi
        ;;
        restart)
                sudo -u ${user} ${script_path}/seafile.sh restart >> ${seafile_init_log}
                if [  $fastcgi = true ];
                then
                        sudo -u ${user} ${script_path}/seahub.sh restart-fastcgi ${fastcgi_port} >> ${seahub_init_log}
                else
                        sudo -u ${user} ${script_path}/seahub.sh restart >> ${seahub_init_log}
                fi
        ;;
        stop)
                ${script_path}/seafile.sh $1 >> ${seafile_init_log}
                ${script_path}/seahub.sh $1 >> ${seahub_init_log}
        ;;
        *)
                echo "Usage: /etc/init.d/seafile {start|stop|restart}"
                exit 1
        ;;
esac

Mit den folgenden Kommandos wird das Skript ausführbar gemacht, installiert und der Dienst gestartet:

chmod +x /etc/init.d/seafile
update-rc.d seafile defaults
service seafile start

Ende

Die Installation ist damit abgeschlossen. Die Seafile-Installation kann nun über https://seafile.domain.tld aufgerufen und genutzt werden.

An dieser Stelle möchte ich mich noch einmal bei André P. für seinen Artikel „Seafile 4.0.x mit Nginx und MySQL-Backend auf Debian/Ubuntu bedanken. Er stellt die Basis für diese Anleitung mit der aktuellen Version von Seafile dar.

Solltet ihr Seafile mit dieser Anleitung auch unter anderen Versionen von Ubuntu/Debian, etc. installieren können, freue ich mich über eure Kommentare, um die Tabelle mit den getesteten Versionen ergänzen zu können.

Mein TLS/SSL-Kochbuch

Heutzutage werden immer mehr Kommunikationsverbindungen im Internet mit TLS/SSL-Verbindungen geschützt. Die Verschlüsselung hilft, die Vertraulichkeit der zwischen Sender und Empfänger übertragenen Daten zu schützen und sollte daher standardmäßig aktiviert sein. Doch bereitet der Einsatz von TLS/SSL-Verschlüsselung noch immer vielen Administratoren und Betreibern verschiedenster Anwendungen Kopfschmerzen. Zu undurchsichtig scheint der Dschungel aus Zertifizierungsstellen, Zertifikaten, Zertifikatsanfragen, öffentlichen und privaten Schlüsseln zu sein. Verschiedenste Validierungsverfahren und Dateiformate für Zertifikate tragen nicht gerade dazu bei, den Durchblick zu behalten. Bereits die Erstellung einer Zertifikatsanfrage gerät dabei häufig genug zu einem Problem. Die richtige Konfiguration der zu sichernden Server bzw. Dienste erscheint kompliziert und Fehler in der Konfiguration führen nicht selten zur Nichterreichbarkeit einer Webseite. Die Folge: Immer noch wird viel zu häufig auf den Einsatz von TLS/SSL-Verschlüsselung verzichtet.

Mit meinem TLS-Kochbuch möchte ich dazu beitragen, etwas Licht ins Dunkel zu bringen. Darin finden sich Rezepte mit praktischen Tipps für die Verwendung von TLS/SSL-Verschlüsselung mittels OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP).

Aus dem Inhalt

Nach der Einleitung führt Kapitel 2 in das Thema ein und definiert die wesentlichen Begriffe. Es bildet die Grundlage für das Verständnis der daran anschießenden Kapitel.

In Kapitel 3 geht es um die Implementierung von TLS/SSL. Hier werden verschiedene Methoden zur Generierung von privaten Schlüsseln und Certificate Signing Requests vorgestellt. Darüber hinaus werden einige Zertifizierungsstellen kurz vorgestellt, bei denen Zertifikate beantragt werden können. Im Folgenden wird auf die Implementierung von TLS/SSL-Zertifikaten in verschiedenen Diensten eingegangen. Hier wird insbesondere die Implementierung von Zertifikaten der recht jungen Zertifizierungsstelle „Let’s Encrypt“ erläutert, mit deren Hilfe sich der Prozess der Zertifikatserneuerung automatisieren lässt.

Der Implementierung des HTTP Public Key Pinning (HPKP) widmet sich Kapitel 4. Das Pinning-Verfahren wird am Beispiel des Webservers NGINX erläutert und getestet.

Zum Schluss werden die in den einzelnen Kapiteln vorgestellten Techniken und Methoden nochmals zusammenfassend an einem konkreten Beispiel in Kapitel 5 verdeutlicht.

Hier geht es zum Text

Mir persönlich hat die Arbeit an folgendem Dokument geholfen, mich detailliert mit der Thematik auseinanderzusetzen und mein Wissen zu erweitern und zu vertiefen. Ich freue mich, wenn mein Kochbuch auch euch dabei hilft, ein besseres Verständnis für das Thema zu entwickeln.

Dies ist die erste Ausgabe meines TLS/SSL-Kochbuchs und es gibt sicher noch viel mehr, was man zu diesem Thema schreiben kann. Fehler sowie Wünsche zum Inhalt zukünftiger Ausgaben können gern an die E-Mail-Adresse tls-rezepte(aet)my-it-brain(Punkt)de gemeldet werden.

Downloads zum Text