My-IT-Vi(m)-Cheat-Sheet
My-IT-Vi(m)-Cheat-Sheet
2 Antworten
Archiv des Autors: Jörg Kastning
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:
Backup, Backup, Backup – Von den Vorteilen einer Datensicherung
Das Thema ist so wichtig, dass man nicht oft genug darauf hinweisen kann. Denn noch immer haben viele Benutzer von Computern kein Backup ihrer wichtigsten Daten. Dieser Artikel möchte daher die Vorteile beleuchten, die ein gutes Backup mit sich bringt.
Um wen es in diesem Artikel gehen soll
Im Fokus dieses Artikels stehen die folgenden Anwender/Zielgruppen. Sollten Sie sich in einer der folgenden Beschreibungen wiedererkennen, so lohnt es sich in jedem Fall weiterzulesen. ;-)
Studenten
Alice ist Studentin. Ihr ständiger Begleiter im Studium ist ihr Notebook. Neben privaten Dingen wie den Fotos von Urlaubsreisen, dem Auslandssemester, etc. speichert Alice auf ihrem Notebook ihre Notizen zu Vorlesungen, Haus- und Abschlussarbeiten.
Während die Bilder für Alice vor allem einen ideellen Erinnerungswert haben, stecken viele Stunden Arbeit in der Erstellung ihrer Ausarbeitungen und vor allem in ihrer Abschlussarbeit. Schließlich hängt das Vorankommen und der erfolgreiche Abschluss ihres Studiums davon ab.
Heimanwender
Bob beschäftigt sich in seiner Freizeit gern mit seinem heimischen PC. Bob ist Hobbyfotograf. Auf seinem PC befinden sich neben den digitalen Fotoalben der Familie noch hunderte weitere Fotos von Reisen und Bobs Streifzügen durch die Natur. Bob bearbeitet viele dieser Fotos aufwendig mit Bildbearbeitungsprogrammen und speichert sie sortiert nach verschiedenen Kategorien. Darüber hinaus hat Bob seine Musiksammlung digitalisiert. Er hat dazu in mühevoller Arbeit hunderte von CDs eingelesen und mit Meta-Informationen zu Interpret, Album, Titel, etc. angereichert.
Kleinunternehmer
Frank führt einen kleinen Handwerksbetrieb. Sein Büro besteht aus zwei PC-Arbeitsplätzen, Netzwerkdrucker/-scanner und einem Netzwerkspeicher (NAS), auf welchem die Dateien gespeichert werden, auf die von beiden PC-Arbeitsplätzen aus zugegriffen wird. Darüber hinaus besitzt Frank noch ein Notebook, auf welchem ebenfalls Firmendaten gespeichert sind. Bob nimmt dieses Notebook häufig mit zu Kunden, um wichtige Informationen direkt im Zugriff zu haben. Zukünftig kann Frank sich auch vorstellen, hierfür ein Smartphone oder Tablet zu verwenden.
Zu den im Unternehmen verarbeiteten Daten zählen unter anderem Stammdaten von Lieferanten und Kunden, Marketing- und Projektunterlagen, Lieferscheine, Rechnungen, die Finanzbuchhaltung, etc.
Hier nicht Genannte
Wer sich in den oben genannten Personengruppen nicht wiederfindet, möge sich folgende Fragen stellen und diese nach gründlicher Überlegung für sich selbst beantworten. Selbstverständlich darf die Lektüre dieses Artikels danach fortgesetzt werden.
- Welche Arten von Daten besitze ich?
- Welche Bedeutung haben diese für mich?
- Was ist, wenn diese Daten von heute auf morgen weg sind?
Gemeinsamkeiten und Risiken
Was haben die oben beschriebenen Personen/-gruppen gemeinsam? Sie sind im gleichen Maße vom Risiko eines Datenverlustes bedroht.
Eine weltweite Umfrage[1] unter 6149 Teilnehmern aus dem Jahr 2010 ergab, dass 89 % der Befragten keine regelmäßige Datensicherung durchführen. Dabei erlitten von diesen bereits 76,6 % einen Datenverlust.
Im Jahr 2013 besaßen laut Angaben des PC-Magazins [2] noch immer 38 % der Befragten keine Datensicherung. Und diese Zahl sinkt nur langsam.
Die Zahlen vom „World Backup Day 2016“ [3] belegen, dass noch immer 30 % der Nutzer noch nie ein Backup gemacht haben.
Dabei ist die Wahrscheinlichkeit, dass ein Datenverlust eintritt, gar nicht so klein. Nach den Angabe der Seite „World Backup Day“:
- Gehen pro Minute 113 Smartphones/Handies verloren oder werden gestohlen
- Werden 1 von 10 Computern monatlich mit Viren infiziert
Hinzu kommen weitere Ursachen wie zum Beispiel Hardwaredefekte und Unfälle.
Gehen Notebook, Tablet oder Smartphone verloren bzw. werden gestohlen, sind damit auch die darauf gespeicherten Daten in der Regel unwiederbringlich verloren. Während das Risiko, einen PC oder ein NAS zu verlieren, eher gering ist, besteht jedoch auch hier das Risiko, dass diese Geräte z.B. bei einem Einbruch entwendet werden. Auch in diesem Fall sind die (geschäftlichen) Daten schlagartig weg.
Die Bedrohung durch Viren [4]/Ransomware [5] ist ebenfalls real. Dies belegen Berichte über den Kryptotrojaner „Locky“ [6], welcher 2016 zehntausende PCs infizierte und darauf gespeicherte Daten verschlüsselte.
Darüber hinaus besteht auch noch das Risiko, dass ein Speichermedium durch einen Hardwaredefekt ausfällt [7] oder darauf gespeicherte Daten (versehentlich) überschrieben [8] werden. Die darauf gespeicherten Daten sind in beiden Fällen verloren.
Auswirkungen
Doch welche Auswirkungen hat nun ein Datenverlust für die hier beschriebenen Personen?
Versetzen wir uns zuerst in die Rolle von Alice. Wie viele Studenten schreibt sie ihre Hausarbeiten immer erst auf den letzten Drücker. Dies ist auch bei ihrer Abschlussarbeit nicht anders. Was passiert nun, wenn ihr Werk von Heute auf Morgen verloren geht? Nun sind nicht nur viele Arbeitsstunden verloren, auch der Abgabetermin und damit das Bestehen der Prüfung/des Studiums sind in Gefahr. Die Folge: Noch mehr Stress, Zeitverlust und mindestens ein Fehlversuch.
Bob fällt durch keine Prüfung, wenn die Daten auf seinem PC plötzlich weg sind. Doch der Verlust mag für ihn genauso schwer, vielleicht sogar noch schwerer als für Alice wiegen. Denn mit den digitalen Fotoalben sind viele wertvolle Erinnerungen der Familie unwiederbringlich verloren. Darunter die Fotos der Hochzeit, der Taufe der Kinder und deren erste Jahre. Dagegen ist der Verlust der Musiksammlung noch eher zu verschmerzen. Bob hat ja noch die Original-CDs und kann die Sammlung in vielen mühevollen Stunden erneut einlesen.
Für Frank kann der Verlust der Daten noch ganz anderen Ärger bedeuten. Kann er doch die Vorschriften der GDPdU [9] nicht mehr einhalten. Und dies könnte noch das geringste Problem sein. Mit den Daten hat Frank auch den Überblick über laufende Projekte, Bestellungen, Aufträge, etc. verloren. Er kann sein Geschäft nicht mehr ordentlich weiterführen. Dies zieht verärgerte Kunden und entgangenen Gewinn nach sich und kann sogar sehr schnell die unternehmerische Existenz bedrohen.
Die Lösung
Zum Glück lässt sich all dieser Ärger vermeiden, wenn man mit einer regelmäßigen Datensicherung [10] für den Ernstfall vorgesorgt hat.
Alice, Bob und Frank bleibt viel Ärger erspart, wenn sie auf ein Backup zurückgreifen können, aus dem sie die verlorenen Daten wiederherstellen können.
So kann Alice den letzten gesicherten Bearbeitungsstand ihrer Arbeit auf einem anderen Gerät wiederherstellen und daran weiterarbeiten. So ist es ihr möglich, die Arbeit noch fristgerecht abgeben zu können.
Bob ist ebenfalls erleichtert, dass die Familienerinnerungen nicht verloren sind, da er sie aus der Datensicherung auf dem reparierten PC wiederherstellen kann.
Und auch Frank fällt ein Stein vom Herzen, dass er rechtzeitig in eine gute Datensicherung investiert hat, mit der es ihm möglich ist, nicht nur verlorene Daten wiederherzustellen, sondern auch die komplette Windows-Installation inkl. installierter Programme mit vollständiger Konfiguration auf einem neuen PC wiederherstellen zu können. Somit ist er bereits nach wenigen Tagen wieder voll arbeitsfähig, kann seinen Verlust minimieren und die Firmenpleite abwenden.
Es freut mich, wenn ich Sie mit diesem Artikel von den Vorteilen einer Datensicherung überzeugen konnte. Doch wie machen Sie von hier ab weiter? Sehen Sie unter den Quellen und weiterführenden Links am Ende dieses Artikels nach. Dort finden Sie Informationen, welche Daten man sichern sollte [11] und nach welchen Methoden [12] bzw. auf welche Arten [13] ein Backup durchgeführt werden kann. Das BSI für Bürger bietet online Leitfäden für eine Datensicherung unter Windows [14] und Linux [15].
Darüber hinaus befindet sich unter den Quellen auch ein Link zu einem Vergleich kommerzieller Backupsoftware [16]. Dieser hilft, sich einen Überblick zu verschaffen und zu entscheiden, welches Produkt am besten zu den persönlichen Anforderungen passt.
Zum Schluss noch ein wichtiger Hinweis. Das Speichermedium, welches als Ziel der Datensicherung dient, sollte stets getrennt von dem System aufbewahrt werden, auf dem sich die zu sichernden Daten befinden. Durch die räumlich getrennte Lagerung soll verhindert werden, dass das Medium, welches das Backup enthält, zusammen mit dem System gestohlen bzw. zerstört wird, von dem das Backup erstellt wurde.
Quellen und weiterführende Links
- Global Data Backup Survey Results {en}
- Vier von zehn Deutschen haben keine Sicherungskopie ihrer Daten
- World Backup Day 31.03.2016
- Computerviren – Wikipedia
- Ransomeware – Wikipedia
- Verschlüsselungstrojaner Locky – Wikipedia
- Gründe für einen Datenverlust – BSI für Bürger
- So können Daten verloren gehen – BSI für Bürger
- Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen – Wikipedia
- Datensicherung – Wikipedia
- Diese Daten sollten Sie sichern – BSI für Bürger
- Methoden der Datensicherung – BSI für Bürger
- Sicherungsarten – Wikipedia
- Datensicherung unter Windows – BSI für Bürger
- Datensicherung unter Linux – BSI für Bürger
- Backup-Software: Die besten Datensicherungsprogramme im Vergleich – Netzsieger
Datenpanne im Internet – Bin ich betroffen?
Sie passieren ständig – Datenpannen[1. Wikipedia: Datenpanne] im Internet. Und die Abstände zwischen ihnen werden gefühlt immer kürzer. In diesem Artikel möchte ich euch einen Weg aufzeigen, wie ihr selbst schnell und einfach feststellen könnt, ob ihr selbst von einer Datenpanne betroffen seid. Im Gegensatz zu vielen anderen Artikeln auf diesem Blog versuche ich dabei auf technische Details so weit wie möglich zu verzichten, um den Artikel allgemeinverständlich zu gestalten.
Datenpannen sind Verstöße, gegen die Datensicherheit und den Datenschutz, bei denen Staatsgeheimnisse, Betriebsgeheimnisse oder personenbezogene Daten Unberechtigten vermutlich oder erwiesenermaßen bekannt geworden sind. – Quelle: Deutschsprachige Wikipedia: Datenpanne
Und Datenpannen können überall passieren. Im Online-Shop, dem Online-Auktionsportal, im Online-Banking, in Tauschbörsen, in sozialen Netzwerken und auch im Cloud-Speicher-Dienst, dem wir unsere Dateien anvertrauen. Wikipedia listet einige bedeutende Vorfälle[2. Wikipedia: Bedeutende Datenpannen], die in den vergangenen Jahren bekannt wurden.
Doch wie kann man nun überprüfen, ob man selbst von einer solchen Panne betroffen ist? Eine erfreulich einfache Möglichkeit bietet die Webseite https://haveibeenpwned.com/.[3. ‚;–have i been pwned? {en}] [4. Wikipedia: Have I Been Pwned? {en}]
https://haveibeenpwned.com – Prüfe, ob einer deiner Accounts durch eine Datenpanne kompromittiert wurde.
Die Bedienung der Seite ist, wie bereits erwähnt, erfreulich einfach. Man trägt den zu überprüfenden Benutzernamen bzw. E-Mail-Adresse in das Suchfeld ein und startet die Suche. Das Ergebnis gibt Auskunft darüber, ob der Benutzername bzw. die E-Mail-Adresse von einer Datenpanne betroffen ist und bei welchem Dienst die Informationen stammen. Die folgenden beiden Screenshots zeigen zwei Beispiele. Das erste Beispiel zeigt einen Fall, bei dem die Kompromittierung eines Benutzernamens bis heute nicht bekannt geworden ist. Das zweite Beispiel zeigt die Abfrage einer E-Mail-Adresse, die mit anderen Daten bei einem Datenleck beim Cloud-Speicheranbieter Dropbox abgegriffen wurden.
Keine Kompromittierung des Benutzernamens bekannt
Die kompromittierte E-Mail-Adresse stammt aus einem Datenleck bei Dropbox
Neben der manuellen Überprüfung bietet die Webseite auch die Möglichkeit, eine E-Mail-Adresse zu hinterlegen. Taucht diese E-Mail-Adresse in einem öffentlich bekannt gewordenen Datenbestand auf, erhält man hierüber eine Nachricht an die hinterlegte E-Mail-Adresse.
Jetzt auch als deutschsprachiges Angebot: Der E-Mail Leak Check
Janis von Bleichert wies mich via E-Mail auf den E-Mail Leak Check hin, welcher unter der URL https://www.experte.de/email-check erreichbar ist. Herr Bleichert hat hier ein Angebot für deutschsprachige Benutzer geschaffen. Dazu hat her Bleichert eigenen Angaben zufolge Informationen zu mehr als 300 Daten-Leaks auf Deutsch übersetzt und ein Tool programmiert, mit welchem Benutzer ebenfalls überprüfen können, ob ihre E-Mail-Adresse von einem Datenleck betroffen ist.
Quelle: https://www.experte.de/email-check
Funktion, Nutzung, Datenschutzhinweis und Antworten auf häufige Fragen, werden in einfachem und verständlichem Deutsch gegeben.
Ich möchte Herrn Bleichert an dieser Stelle für den Hinweis auf diesen Dienst danken.
Was tun, wenn ich betroffen bin?
Stellt man nun fest, dass die geprüften Benutzerdaten kompromittiert sind, sollte man umgehend handeln. Es ist dringend empfohlen, in diesem Fall
- die Zugangsdaten (Benutzername, E-Mail-Adressse, Passwort) beim betroffenen Dienst zu ändern.
- die Zugangsdaten (Benutzername, E-Mail-Adressse, Passwort) bei allen sonstigen Diensten zu ändern, bei denen die gleichen Zugangsdaten verwendet wurden.
Mit dem zweiten Schritt soll sichergestellt werden, dass mit den kompromittierten Benutzerinformationen noch weitere Benutzerkonten bei anderen Online-Diensten gekapert werden können.
Um den Umgang und die Verwaltung von Benutzernamen und Passwörtern so komfortabel wie möglich zu gestalten, empfehle ich die Verwendung eines Passwortmanagers wie z.B. KeePass.[5. Wikipedia: KeePass] [6. KeePass Password Safe] [7. The Official KeePassX Homepage]
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:
- Die zu aktualisierenden Hosts werden in Gruppen im Ansible Inventory verwaltet. Eine Gruppe entspricht dabei einer Stage/Phase für das Patch-Management.
- An definierten Stichtagen sollen automatisiert fehlende Sicherheitsaktualisierungen auf den Systemen in den verschiedenen Stages/Phasen eingespielt werden können.
- Dabei sollen ausschließlich Pakete aktualisiert werden, für die Red Hat Security Advisory veröffentlicht wurden.
- 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:
- Ansible Galaxy: https://galaxy.ansible.com/tronde/rhel-patchmanagement
- GitHub: https://github.com/Tronde/ansible-role-rhel-patchmanagement
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
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.
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
| Betriebssystem | Ubuntu 14.04 LTS Server |
| Webserver | NGINX 1.4.6 |
| Datenbankserver | MySQL 5.6 |
| Seafile | 5.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:
- NGINX Server in Grundkonfiguration[6. nginx auf ubuntuusers.de]
- MySQL Datenbank[7. MySQL auf ubuntuusers.de]
- Erreichbarkeit unter der Domain „seafile.domain.tld“
- Optional: TLS-Zertifikat für die Domain „seafile.domain.tld“[8. Kapitel 3, TLS-Kochbuch mit Rezepten zur Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)]
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.