pixel
Select Page

NETWAYS Blog

Jitsi Meetings mit Jibri aufzeichen

Trotz scheinbar eintretender Entspannung bei der aktuellen Corona-Krise ist Videoconferencing nicht mehr wegzudenken. Sei es durch das Umdenken bei den Arbeitgebern zu Homeofficeregeleungen oder bei international gewachsenen Teams. Alle müssen irgendwie miteinander kommunizieren. Wir von NETWAYS setzen ja schon seit Beginn der Krise auf Jitsi und konnten damit auch viele Kunden überzeugen, datenschutzkonforme Videokonferenzlösungen einzusetzen.

Neben unserer Jitsi-App (JaaS), welche sich übrigens 30 Tage kostenfrei testen lässt und darüber hinaus auch schon Branding nach eigenen Bedürfnissen anbietet, bauen wir auch Jitsi-Lösungen nach Kundenwunsch. Seien es spezielle Anforderungen an besonders viele gleichzeitige Nutzer, ein komplett eigenes Branding, JWT-Auth, Telefoneinwahl oder Datenschutz-Pop-Up’s.

Inzwischen erreichen uns auch immer öfter Anfragen, die den Wunsch äußern, solche Meetings aufzuzeichnen. Also haben wir uns hier auf die Suche gemacht und Jibri gefunden. Nachfolgend beschreibe ich in aller Kürze, wie man seinen Jitsi-Server dazu bringt Videos aufzuzeichnen. Als Basis hierzu dient ein Ubuntu 20.04 LTS-Server mit bereits eingerichtetem Jitsi.

Alle nachfolgenden Schritte werden als root auf dem Jitsi-Meet Server ausgeführt, hingegen zur offiziellen Dokumentation gibt es ein paar Stolpersteine, welche ich euch gern erspare.

Vorbereitung

Zu Beginn installieren wir die erforderlichen Kernel-Module:

apt install linux-modules-extra-$(uname -r)
apt install linux-generic
reboot
echo "snd-aloop" >> /etc/modules 
modprobe snd-aloop

Nun machen wir den Server mittels Chrome Stable als Client fit:

curl -sS -o - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list apt-get -y update apt-get -y install google-chrome-stable

Im nächsten Schritt kommen die Chrome managed-policies dazu:

mkdir -p /etc/opt/chrome/policies/managed
echo ‘{ “CommandLineFlagSecurityWarningsEnabled”: false }’ >>/etc/opt/chrome/policies/managed/managed_policies.json

Der Chrome-Treiber darf natürlich auch nicht fehlen, daher führen wir nun aus:

CHROME_DRIVER_VERSION=`curl -sS chromedriver.storage.googleapis.com/LATEST_RELEASE` wget -N http://chromedriver.storage.googleapis.com/$CHROME_DRIVER_VERSION/chromedriver_linux64.zip -P ~/ unzip ~/chromedriver_linux64.zip -d ~/ rm ~/chromedriver_linux64.zip sudo mv -f ~/chromedriver /usr/local/bin/chromedriver sudo chown root:root /usr/local/bin/chromedriver sudo chmod 0755 /usr/local/bin/chromedriver

Noch weitere benötigte Pakete:

apt install ffmpeg curl alsa-utils icewm xdotool xserver-xorg-input-void xserver-xorg-video-dummy

Installation Jibri

Die eigentliche Jibri-Installation machen wir über apt:

apt install jibri

Ohne Rechte geht natürlich nichts, daher kommen diese auch noch dazu:

usermod -aG adm,audio,video,plugdev jibri

In den nächsten Schritten kommt noch das erforderliche Java hinzu:

wget -O - https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | sudo apt-key add -
add-apt-repository https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/
apt-get -y update
apt-get install adoptopenjdk-8-hotspot

Wir müssen Java8 als default setzen, dazu ändern wir die nachfolgende Datei:

vim /opt/jitsi/jibri/launch.sh

Hier ändern wir das Wort “java” in den folgenden String “/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java”. Danach speichern und schließen wir Datei schon wieder.

Prosody benötigt auch noch eine kleine Änderung. Also kommt das nun direkt (Achtung, Pfad weicht auf die eigene Domain am Ende ab):

vim /etc/prosody/conf.avail/your.domain.com.cfg.lua

Dort hängen wir am Ende einfach an (your.domain.com wieder durch eigene Jitsi-Adresse ersetzen):

-- internal muc component, meant to enable pools of jibri and jigasi clients
Component "internal.auth.your.domain.com" "muc"
modules_enabled = {
"ping";
}
storage = "memory"
muc_room_cache_size = 1000

VirtualHost "recorder.your.domain.com"
modules_enabled = {
"ping";
}
authentication = "internal_plain"

Danach speichern und schließen wir die Datei wieder
Nun bekommt Prosody noch 2 neue Nutzer, die Passwörter “JPwd” und “RPwd” ersetzt man durch eigene, sichere Passwörter und notiert diese für später:

prosodyctl register jibri auth.your.domain.com JPwd
prosodyctl register recorder recorder.your.domain.com RPwd

Jicofo will auch noch eine Änderung, diese beginnen wir durch öffnen des Config-Files:

vim /etc/jitsi/jicofo/sip-communicator.properties

Dort fügen wir die Zeilen ein (Achtung, Domainname anpassen):

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.your.domain.com 
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90

Jetzt bringen wir Jitsi selbst wirklich noch bei, eine Aufnahme zu starten (!Domainname):

vim /etc/jitsi/meet/your.domain.com-config.js

hier prüfen wir, ob die folgenden Optionen so gesetzt sind, bzw. fügen den Code ein (!Domain):

fileRecordingsEnabled: true, 
liveStreamingEnabled: true, 
hiddenDomain: 'recorder.your.domain.com',

Der Dateispeicherort bekommt nun auch noch die Rechte, die er braucht, um von Jibri beschrieben zu werden:

mkdir /srv/recordings
chown jibri:jibri /srv/recordings

Zu guter Letzt, muss Jibri noch konfiguriert werden. Nachfolgend ein Beispiel hierfür. Man achte bitte auf das Ersetzen mit dem eigenen, korrekten Domainnamen und die korrekt vergebenen Passwörter:

vim /etc/jitsi/jibri/jibri.conf

jibri {
// A unique identifier for this Jibri
// TODO: eventually this will be required with no default
id = ""
// Whether or not Jibri should return to idle state after handling
// (successfully or unsuccessfully) a request. A value of 'true'
// here means that a Jibri will NOT return back to the IDLE state
// and will need to be restarted in order to be used again.
single-use-mode = false
api {
http {
external-api-port = 2222
internal-api-port = 3333
}
xmpp {
// See example_xmpp_envs.conf for an example of what is expected here
environments = [
{
name = "prod environment"
xmpp-server-hosts = ["your.domain.com"]
xmpp-domain = "your.domain.com"

control-muc {
domain = "internal.auth.your.domain.com"
room-name = "JibriBrewery"
nickname = "jibri-nickname"
}

control-login {
domain = "auth.your.domain.com"
username = "jibri"
password = "JPwd"
}

call-login {
domain = "recorder.your.domain.com"
username = "recorder"
password = "RPwd"
}

strip-from-room-domain = "conference."
usage-timeout = 0
trust-all-xmpp-certs = true
}]
}
}
recording {
recordings-directory = "/srv/recordings"
# TODO: make this an optional param and remove the default
finalize-script = "/path/to/finalize_recording.sh"
}
streaming {
// A list of regex patterns for allowed RTMP URLs. The RTMP URL used
// when starting a stream must match at least one of the patterns in
// this list.
rtmp-allow-list = [
// By default, all services are allowed
".*"
]
}
chrome {
// The flags which will be passed to chromium when launching
flags = [
"--use-fake-ui-for-media-stream",
"--start-maximized",
"--kiosk",
"--enabled",
"--disable-infobars",
"--autoplay-policy=no-user-gesture-required"
]
}
stats {
enable-stats-d = true
}
webhook {
// A list of subscribers interested in receiving webhook events
subscribers = []
}
jwt-info {
// The path to a .pem file which will be used to sign JWT tokens used in webhook
// requests. If not set, no JWT will be added to webhook requests.
# signing-key-path = "/path/to/key.pem"

// The kid to use as part of the JWT
# kid = "key-id"

// The issuer of the JWT
# issuer = "issuer"

// The audience of the JWT
# audience = "audience"

// The TTL of each generated JWT. Can't be less than 10 minutes.
# ttl = 1 hour
}
call-status-checks {
// If all clients have their audio and video muted and if Jibri does not
// detect any data stream (audio or video) comming in, it will stop
// recording after NO_MEDIA_TIMEOUT expires.
no-media-timeout = 30 seconds

// If all clients have their audio and video muted, Jibri consideres this
// as an empty call and stops the recording after ALL_MUTED_TIMEOUT expires.
all-muted-timeout = 10 minutes

// When detecting if a call is empty, Jibri takes into consideration for how
// long the call has been empty already. If it has been empty for more than
// DEFAULT_CALL_EMPTY_TIMEOUT, it will consider it empty and stop the recording.
default-call-empty-timeout = 30 seconds
}
}

Das wars, nun startet man die betroffenen Dienste noch neu und der Aufnahme-Button im Meeting zeigt nun auch die gewünschte Funktion:

systemctl restart jitsi-videobridge2 prosody jicofo
systemctl enable --now jibri

Die Aufnahmen sind nun in /srv/recordings zu finden. Sollte hier noch kein Bild und Ton sichtbar sein, hat final folgende Änderung in der Datei /etc/jitsi/jicofo/jicofo.conf noch Abhilfe geschafft

Man suche sich die Zeile:

trusted-domains: recorder.your.domain.com

und passt sie an, auf:

trusted-domains: [recorder.your.domain.com]

Nach einem letzten Dienstneustart läuft nun alles wie gewünscht.

Schlusswort

Bedenken sollte man, dass Videos gespeichert werden und entsprechend viel Platz verbrauchen. Dies sollte man beim Sizing des Systems beachten. Die Daten sind auch nicht einfach für jeden Teilnehmer herunterladbar, sondern liegen auf dem Jitsi-Server unter /srv/recordings.

Alles in Allem ist dies aber eine wunderbare Lösung, um Workshops mit Kollegen aufzuzeichnen und diese später an neue Kollegen weiter zu geben.

Sobald die Aufzeichnung ausgelöst wird, wird dies allen Teilnehmern auch via Text2Speech mitgeteilt. Im Meeting ist oben neben dem Meetingnamen auch ein Recording-Symbol zu sehen.

Wer ein solches Jitsi haben will, sich aber nicht gern selbst darum kümmert, wäre bei uns genau richtig und sollte den Kontakt zu unseren freundlichen Vertriebskollegen suchen. Unsere Server stehen in Nürnberg und ermöglichen so eine vollständig datenschutzkonforme Videokonferenzlösung.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

MyEngineer – IT-Systemadministration nach Maß

Mit unserem neuen Produkt OpenStack in NETWAYS-Web-Services, starten wir auch einen neuen Service – MyEngineer.
Doch was ist NETWAYS Web Services, OpenStack und MyEngineer? Genau das wird in diesem Artikel erklärt.

NETWAYS Web Services (NWS)

Bei NETWAYS Web Services, zunächst kürzer “NWS” handelt es sich um eine Software as a Service-Plattform (SaaS) auf der einige Produkte zur sofortigen Nutzung als fertig betriebene Software bereitstehen. Interessenten und Kunden müssen sich lediglich in einem einfachen Verfahren ein Konto anlegen und die Wunschsoftware bzw. Apps starten. Inzwischen stehen hier einige Produkte zur Auswahl – und das sogar die ersten 30 Tage kostenfrei! Die Produktpalette reicht von Gitlab (CE/EE) über Nextcloud, WordPress, SuiteCRM, Icinga 2 (Master/Satellite) bis hin zum Request-Tracker (und es kommen immer neue Produkte dazu). Für jedes Produkt gibt es verschiedene Pakete, die jedem Anwendungsfall entsprechen. Die Vorteile einer SaaS-Lösung liegen klar auf der Hand, die Kunden brauchen sich keine Gedanken über Sicherheit, Backups oder Aktualisierungen mehr machen, denn genau da drum kümmern wir uns dezent im Hintergrund. Als Nutzer eines NWS-Produktes konzentrieren Sie sich auf Ihre Arbeit und verlieren keine Zeit in der Administration Ihrer Anwendung. Schauen Sie doch mal rein!

OpenStack

Seit einigen Wochen bieten wir OpenStack als als Produkt im NWS an. Allerdings handelt es sich weniger um eine App, also nicht wirklich um SaaS (vielleicht doch – ein Bisschen), sondern viel mehr um Infrastructure as a Service (IaaS) – und das ist so ziemlich der letzte Schrei aktuell in der IT. Mit einem Zugang in unser OpenStack haben Anwender die Gelegenheit, ihre eigene IT-Infrastruktur aufzubauen – und da geht so einiges, also nicht nur VMs wie bei manch anderem Marktbegleiter. Unsere OpenStack-User können bei uns alles nach Wunsch anlegen: virtuelle Maschinen (Sizings mit nahezu beliebigen Spezifikationen, natürlich mit root-Zugriff), Netzwerke, Firewall-Regeln, interne Netzwerke, Snapshots, Loadbalancer, Router, VPNs, S3-Buckets – alles genau, wie es gebraucht und gewünscht ist. Mit OpenStack erhalten Administratoren Zugriff auf ein mächtiges Tool (Webinarvideo), welches dennoch leicht verständlich und wartbar ist. Das Beste kommt wie immer zum Schluss – die eigene OpenStack-App ist bei uns 100% kostenlos. Es werden nur Ressourcen gezahlt, die auch verbraucht wurden – und das zu günstigen Preisen und auf die Stunde genau. Also auch mal schnell eine Test-VM starten und was probieren, VM wieder löschen – kein Problem, die VM steht inkl. der Registrierung im NWS in unter 5 Minuten zur Verfügung (Videobeweis)! Mit unserem OpenStack Kosten-Rechner (erst zu sehen beim laufenden Produkt, aber hier sieht man, wie es aussieht) haben Sie immer die bisher aufgelaufenen, sowie die für diesen Monat zu erwartenden Kosten im Blick! Eine Preisübersicht über die einzelnen Ressourcen pro Stunde finde man auf der Produktseite. Gezahlt wird übrigens bequem via Kreditkarte oder auf Rechnung – und jetzt ganz neu: PayPal. Datenschutzkonform, gehostet in Deutschland über mehrere Standorte.

MyEngineer

Der NETWAYS-MyEngineer erfüllt den Wunsch nach einer wartungsfreien Software (wie bei NWS) und den Einsatz von OpenStack. Unerfahrene Anwender, oder solche, die sich ihrem Geschäft zuwenden wollen, greift MyEngineer unter die Arme, stellt gewünschte Applikationen bereit, kümmert sich um Updates, Backups, Firewalleinstellungen und stellt den Betrieb sicher. Die Anwendungsmöglichkeiten sind hier unbegrenzt. Was und wie viel gemacht wird, entscheiden Sie. Wir stellen beim Onboarding hierzu gezielt Fragen, damit wichtige Punkte nicht vergessen werden. Nach der initialen Einrichtung sind unsere MyEngineers für Sie da. Ein Anruf oder ein Ticket genügt und wir kümmern uns. Optional zur Entstörung kritischer Anwendungen bietet der MyEngineer 24×7 Support auch rund um die Uhr, am Wochenende und an Feiertagen.

Um einen Einblick zu bekommen, was so alles geht, nachfolgend eine kurzer Auszug von dem, was unsere MyEngineers kürzlich gemacht haben:

  • Ein Studierendenwerk bestellte einen zentralen im OpenStack gehosteten Unifi-SDN-Controller für 600 Unifi-Access Points, verteilt über mehrere Studentenwohnheime. Unsere MyEngineers stellten diesen innerhalb eines Tages nach Bestellung mit root-Zugriff für den Kunden inkl. aller erforderlichen Firewall-Regeln und Backup bereit. Die eigentliche Einrichtung der Access-Points und Netzwerke in der Controller-Software, wollte der Kunde übernehmen. Nach sauberer Dokumentation und kurzer Einweisung wollte der Kunde die letzte Firewall-Regel dann doch selbst einmal einrichten und von der einfachen Bedienung im OpenStack überzeugen. Der MyEngineer wird sich monatlich um die Updates des Controllers kümmern, alles andere auf Abruf.
  • Ein Systemlieferant für Maschinen- und Anlagenbau orderte eine virtuelle Maschine mit Docker und Docker-Compose, sowie ein einfaches Firewall-Regelwerk für den Webzugriff. Auch dies stellen unsere MyEngineers innerhalb kurzer Zeit zur Verfügung und standen auch bei der Inbetriebnahme der Container zur Verfügung.
  • Ein Softwarehersteller aus München orderte ein Gitlab EE und hatte den Wunsch nach einer zentralen Gitlab-Instanz mit besonders viel Power und AD-Anbindung. Für die AD-Anbindung war ein VPN erforderlich, welches unsere MyEngineers ihm gern direkt im OpenStack einrichteten und ihm bei der Anbindung an sein Gateway behilflich waren. Übrigens: die Lizenz für Gitlab EE hat der Kunde selbst mitgebracht.
  • Ein Softwarehersteller, der Kita-Anmeldungen zentral mit einer Webapplikation verwaltet, bereitet seinen Go live vor und bringt seine Anwendung (mit mächtig vielen Paketabhängigkeiten) frisch aus der Entwicklung mit. Kein Problem für die MyEngineers – diese bauen ein verteiltes Setup, mit getrennten Workern, Datenbanken und Webservern auf. Zudem ist die ganze Anwendung aus der Produktion noch einmal als Staging-Umgebung gespiegelt.
  • Ein IT-Dienstleister aus Nürnberg: Wünschte den Neuaufbau seines Webauftritts. Unsere MyEngineers kümmerten sich um die Bereitstellung der Maschinen mit einem klassischem LAMP-Stack. Besonders hier dran: dieser Kunde wünschte einen eigenen Puppetmaster um jederzeit neue Maschinen dazu nehmen zu können und ein zentrales Config-Management zu realisieren. Die Webanwendung läuft loadbalanced mit dem OpenStack Loadbalancer.

Kurzum, sollte der Wunsch an die Applikation doch etwas komplexer sein und wird nicht mit Standardprodukten abgebildet, helfen wir gerne. Abgerechnet wird fair nach aufgebrachter Zeit – kein Laufzeitvertrag mit monatlichen Kosten! Eine kurze Anfrage genügt!

 

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Lokale Time Machine Snapshots blockieren Speicherplatz

Kürzlich hatte ich den Plan, ein ca. 100GB iPhone Backup zwischenzeitlich auf dem Mac anzufertigen. Meinem Plan stand nach einem kurzen Blick auf den freien Diskspace des Finders eigentlich nichts im Wege, denn dieser zeigte noch 120 GB freien Speicherplatz an. Nachdem sich das Backup aber mit einem bisher unbekannten Fehler verabschiedete, machte ich mich einmal auf die Suche, was mein Mac denn so eigentlich macht.
Ein Kurzer Blick im Terminal bestätigte mir allerdings viel weniger freien Platz auf der Platte, als der Finder es tat. So waren hier nur noch 55 GB frei. Wie kann das sein?
Zunächst einmal öffnet ihr euer Terminal im Mac und gebt folgendes Kommando ein

df -h

Der Mac zeigt nun in aller Regel in der ersten Zeile die Informationen der Mac-Festplatte (Gegenkontrolle Anhand der Size-Spalte) an. In der Spalte Available steht der noch zur Verfügung stehende Speicherplatz. Sollten sich diese Werte im Finder und im Terminal erheblich unterscheiden, macht es Sinn, die Snapshots unter die Lupe zu nehmen.
Warum Snapshots?
Sollte das Time Machine Backup Volume (z. B. wenn man im Urlaub ist) nicht verfügbar sein, fertigt der Mac lokale Snapshots an. Ein solcher Snapshot schützt zwar nicht vor Datenverlust bei einem Hardwareschaden, wohl aber bei unbeabsichtigten Löschen – also die haben schon Ihre Daseinsberechtigung und fertigen zuverlässig auch ohne Backupvolume im Hintergrund eine Art Sicherung an. Normaler Weise gibt der Mac nach und nach die Snapshots frei, wenn er merkt, dass der Platz benötigt wird. Das ist wahrscheinlich auch der Grund, warum der Finder die Snapshots von der Kalkulation des freien Speicherplatzes excludiert.
Habe ich auch Snapshots?
Sofern ein Time Machine Backup läuft, wird diese Funktion aktiviert. Allerdings tritt sie nur in Kraft, wenn das Backup-Volume nicht verfügbar ist. Am besten prüft man das kurz über das Mac-Terminal mittels Eingabe des folgenden Kommandos. Es listet alle vorhandenen Snapshots der Primärplatte auf.

tmutil listlocalsnapshots /

Möchte man nun einmal solche Snapshots entsorgen, so lässt sich das mit folgendem Kommando erledigen

sudo tmutil thinLocalSnapshots / 10000000000 4

Kurze Erklärung hierzu: / Bezieht sich wieder auf das soeben ermittelte Volume (also die primäre Festplatte, das braucht man in aller Regel nicht ändern), 10000000000 bezieht sich auf den “purgeamount” also die Menge, in diesem Beispiel sind das 10 GB. Um mehr freizugeben, Zahl auf beliebigen Wert in Byte erhöhen, oder Kommando mehrfach ausführen. Die 4 steht für die “urgency”, also die Dringlichkeit. 1 ist hier die höchste, aber 4 reicht eigentlich auch zum Löschen.
Nachhaltig verhindern, lassen sich lokale Snapshots auf den Apple-Geräten mit folgendem Kommando:

sudo tmutil disablelocal

Alternativ Time Machine nicht mehr nutzen, oder dafür sorgen, dass die Backupvolumes immer verfügbar sind.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache

This entry is part 4 of 5 in the series SSL leicht gemacht

Die IT-Landschaften der Unternehmen wachsen prächtig – und auch die Anforderungen an die Sicherheit der dort gespeicherten Daten, denn besonders sensible Daten sind für so manch einen besonders interessant.
Passwörter werden noch heute viel genutzt, aber die vergangenen Jahre haben bewiesen, dass hier vor allem der Nutzer eine Schwachstelle darstellt. Passwörter werden hier sehr bequem; also zu kurz, mehrfach auf verschiedenen Diensten oder leicht zu erraten, gewählt.
Da nützt die beste Verschlüsselung im Zweifel nicht viel, wenn das Passwort auf einer der unzähligen Passwort-Listen im Internet rumschwirrt. Auch Phishing stellt ein Problem dar und nutzt die Unaufmerksamkeit der Nutzer aus. Kürzlich erhielten wir von einem unserer Managed-Services Kunden die Anfrage, ob wir nicht dafür eine Lösung haben. Das Stichwort “clientbasierte Zertifikats-Authentifizierung” kam dabei vom Kunden. Wenn man danach sucht, findet man schnell den Fachbegriff Mutual SSL Authentication (also gegenseitige SSL Authentifikation).
Gesagt, getan. Wir haben eine Lösung auf seinem Managed-Server-System bereitgestellt und zu Abnahmetests aufgefordert – das Ergebnis überzeugt. Für den Zugang zum Webdienst des Kunden braucht man nun kein Passwort mehr und es ist sicherer als zuvor. Aber wie genau funktioniert das?

  1. Der Nutzer beantragt Zugang auf eine geschützte Ressource
  2. Der Server antwortet nun neben seinen TLS-Zertifikat mit seinem Serverzertifikat
  3. Der Client verifiziert das erhaltene Zertifikat
  4. Der Client vertraut dem Zertifikat und übersendet sein Publickey
  5. Der Server überprüft die vom Client erhaltenen Daten
  6. Der Server gewährt dem Client Zugang zum gewünschten Medium

Im nachfolgenden Beispiel werde ich die Vorgehensweise zur Erstellung der selbstsignierten Zertifikate, Konfiguration des Webservers (hier Apache) und Einbindung in den Webbrowser beschreiben. Ausgangssituation ist ein aktuelles Linux mit Apache (dieser nutzt für TLS bereits Zertifikate). Tools wie openssl und vim sehe ich jetzt mal als gegeben.
Wir wechseln zunächst auf die grüne Wiese und erstellen uns einen neuen Ordner, z. B. /usr/local/src/SSL
1. Erstellung eines firmenweiten rootca-Zertifikates-Privatekeys mit 4096 BIT Schlüssellänge

openssl genrsa -out ssl.netways.de_rootca.key 4096

2. Nun erstellen wir ein Serverzertifikat mit 10 Jahren Gültigkeit, dies kann natürlich individuell angepasst werden

openssl req -x509 -new -nodes -key ssl.netways.de_rootca.key -sha256 -days 3650 -out ssl.netways.de_rootca.pem


3. Wir erstellen einen Key unseres ersten Clients, dieser kann natürlich individuell benannt werden, damit die Unterscheidung leichter fällt

openssl genrsa -out ssl.netways.de_client1.key 4096

4. Für den soeben erstellten Client-Key erstellen wir nun eine Zertifikatsanforderung, CSR
Eine Besonderheit, ist hier dass wir als OU (also Organizational Unit, bzw. Abteilung) ein Mitarbeiter-Kürzel (im Beispiel gmimietz) angeben, dazu später mehr

openssl req -new -key ssl.netways.de_client1.key -out ssl.netways.de_client1.csr


5. Wir legen schnell die erforderlichen Daten an, damit wir nicht die ganze OpenSSL-Config umbauen müssen

mkdir -p demoCA/newcerts && mkdir demoCA/certs && mkdir demoCA/crl && echo 00 > demoCA/serial && touch demoCA/index.txt

6. Jetzt signieren wir das CSR des Clients gegen unsere Serverzertifikate und erstellen ein Clientzertifikat mit 10 Jahren Gültigkeit, dies auf Korrektheit überprüfen und bestätigen.

openssl ca -in ssl.netways.de_client1.csr -cert ssl.netways.de_rootca.pem -keyfile ssl.netways.de_rootca.key -out ssl.netways.de_client1.crt -days 3650

7. Abschließend exportieren wir das Clientzertifikat und den Key übertragungstauglich in PKCS12-Format, hierzu wird ein Passwort abgefragt, welches wir später beim Import wieder brauchen.

openssl pkcs12 -export -in ssl.netways.de_client1.crt -inkey ssl.netways.de_client1.key -out NETWAYS_Client_gmimietz.p12

8. wir kopieren unseren rootca in unser ca-Verzeichnis (wichtig, dies muss dort mit crt benannt sein, um im nächsten Schritt eingelesen zu werden)

cp /usr/local/src/SSL-TEST/ssl.netways.de_rootca.pem /usr/local/share/ca-certificates/ssl.netways.de_rootca.crt

9. Zunächst aktualisieren wir unseren Zertifikats-Store mit

update-ca-certificates

10. In der Apache-Config brauchen wir noch ein paar kleine Anpassungen innerhalb der jeweiligen vhost-Definition

SSLCACertificatePath "/etc/ssl/certs"
SSLVerifyClient require
SSLVerifyDepth 5

11. Falls wir einem Zertifikat das Vertrauen entziehen möchten, so müssten wir eine Unterscheidung sicherstellen, deshalb haben wir in Punkt 4 eine OU angegeben, diese dient nur der Unterscheidung

<location />
  SSLRequire (%{SSL_CLIENT_S_DN_OU} ne "gmimietz")
</location>

12. Final starten wir den Apache neu

service apache2 restart

13. Zertifikat auf Client importieren
Wir importieren das Zertifikat (p12-File aus Schritt 7) unseren Browser. Dazu brauchen wir unser Entschlüsselungspasswort wieder, womit wir den Export verschlüsselt haben.
Im Firefox gehen wir hierzu auf Einstellungen -> Datenschutz & Sicherheit -> Zertifikate anzeigen.
Dort importieren wir im Register “Ihre Zertifikate” nun das p12-File und geben einmalig das Passwort ein.

Für die Anlage weiterer Client-Zertifikate führen wir die Schritte 3., 4., 6., 7. erneut aus und unterscheiden mittels Nutzernamen anhand der OU.
Fertig, wird laufen. Bitte noch beachten, dass andere Vhost-Configs natürlich auch abgedichtet werden müssen, falls die in das gleiche Doc-Root mit sensiblen Daten zeigen!
Ja, so tolle Sachen machen wir – was der Kunde sich wünscht, setzen wir um!

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Verschlüsselten File-Container mittels cryptsetup und LUKS erstellen


Datenschutz wird im Jahr 2018 so groß geschrieben wie nie zuvor. Verschiedene Anforderungen an die Absicherung der Daten zwingen Admins, sich elegante und sichere Setups einfallen zu lassen. Ich nehme das zum Anlass, eine neue Serie zur Dateiverschlüsselung zu eröffnen, bei der es um die verschiedensten Möglichkeiten geht, die gespeicherten Daten gegen den Zugriff Unbefugter abzusichern.
Oftmals ist eine Verschlüsselung der Daten aufgrund bestehender Infrastrukturen oder mangels Rechten (z. B. bei extern angemieteten Storages) nicht so einfach möglich. Früher war hier ECryptFS im Linux-Umfeld und TrueCrypt bei Windows State of the Art. Heute haben sich die Anforderungen geändert und ECryptFS ist wegen einer zu restriktiven Beschränkungen der Dateinamen nicht mehr alltagstauglich. Daher stelle ich hier eine moderne Alternative mit cryptsetup in Ergänzung mit LUKS vor.

Vorbereitung

Installation von cryptsetup (Beispiel Debian-Derivate)

sudo apt-get install cryptsetup

Laden des Kernel-Moduls (nur bei initialer Einrichtung)

sudo modprobe dm-crypt

File-Container erstellen

Zunächst wird mittels dd ein File-Container mit 1GB Größe erstellt, der Wert kann natürlich je nach Anforderung angepasst werden

dd if=/dev/zero of=/storage/my_container bs=1M count=1024

File-Container mittels cryptsetup initialisieren

 cryptsetup -y luksFormat /storage/my_container

Nun die gewünschte Passphrase eingeben. Aber Achtung, ohne ein gut gewähltes Passwort nutzt die stärkste Verschlüsselung nichts!
Verschlüsselten Container öffnen und Dateisystem erstellen

cryptsetup luksOpen /storage/my_container my_mount

hier wird das Kennwort abgefragt, dies sollte man sich natürlich zuvor gut merken. Der Container ist nun unter /dev/mapper/my_mount eingebunden.  Anschließend wird ein ext4-Dateisystem in dem Container erzeugt.

mkfs.ext4 -j /dev/mapper/my_mount

File-Container am Wunschort mounten

Ordner zum mounten erstellen

mkdir /my_data
mount /dev/mapper/my_mount /my_data

Fertig – alle Daten die nun in /my_data erzeugt werden, landen am Ende verschlüsselt im Container, wie in meinem Beispiel unter /storage/my_container

Mount aushängen und File-Container schließen

Damit die Daten während der Nichtnutzung auch wirklich sicher sind, empfehle ich, den Container wieder abzuschließen.

umount /my_data
cryptsetup luksClose my_mount

Protip

Ich habe auf diese Art der Verschlüsselung bei meiner Nextcloud zurückgegriffen, da mir die Bordmittel von Nextcloud nicht gefallen, oder zu langsam sind. Im nächsten Artikel werde ich auch erklären, wie man den Container entsprechend vergrößern kann. Alle mit my_ verwendeten Variablen, können natürlich auf die jeweiligen Bedürfnisse angepasst werden.

Haben wollen?

Wir bieten natürlich bei uns im Managed-Hosting individuelle Lösungen an. Falls unsere (potentiellen) Kunden ein solches Setup wünschen, so sind wir natürlich für jeden Spaß zu haben.

Disclaimer

LUKS verwaltet die Verschlüsselungsdaten im Header. Ohne den Header (oder im Falle einer Beschädigung), ist ein Zugriff auf die Daten nicht mehr möglich. Es gibt verschiedene Tools, wie beispielsweise zuluCrypt, mit denen die Schlüssel und Header verwaltet und gesichert werden können, doch dazu in einem späteren Artikel mehr. Die Anleitung wurde nach bestem Wissen und Gewissen erstellt, testet bitte jedoch selbst ausreichend, bevor diese Lösung in die Produktion geht, damit das ihr die Funktionsweise versteht und Datenverlust vermeidet.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.