News

Jitsi ist eine einfache Videokonferenzlösung, die sich selber hosten lässt. Dabei beziehe ich mich spezifisch auf das Produkt Jitsi Meet, welche jitsi-videobridge und jicofo beinhaltet. Es werden technologien, wie webrtc und libjitsi verwendet. Damit bietet Jitsi eine Open Source Alternative zu anderen Videokonferenzlösungen, wie z.B. Google Hangouts oder Skype. Jitsi ist eine Open Source Community, welche von der Firma Atlassian unterstützt wird.

Für Firmen, die noch eine Videokonferenzlösung suchen, aber jedoch eher weniger an “Skype for Business” oder allgemein proprietären Lösungen interessiert sind, ist dies eine praktische und kostengünstige Lösung, die man als Firma in Erwägung ziehen sollte.

Dadurch, dass Jitsi webbasiert ist, können z.B. Kunden schneller und praktischer mit Ihnen in Verbindung treten um ein Meeting oder eine Präsentation durch zu führen.

Interface Überblick

Um eine Videokonferenz mit Jitsi zu starten, kann einfach der Name der Videokonferenz nach der URL eingegeben werden, z.B. meet.example.com/brucewayneisbatman.

Der Konferenzraum wird im Browser sofort geöffnet. Alternativ hat Jitsi eine Startseite, bei welcher man einen Konferenzraum öffnen kann. Hier das Interface einer Videokonferenz.

Das Interface ist vergleichbar mit Google Hangouts und daher sehr familiär. Auf der linken Seite ist eine Bar. Hier bieten sich verschiedene Funktionen an, wie

• Chat
• Konferenz mit einem Passwort schützen
• Profilbild (Gravatar ist möglich)
• Handzeichen (man erkennt damit, dass man etwas sagen möchte)

Desktop sharing

Ab Firefox Version 52 ist es möglich den Desktop zu sharen ohne ein extra Plugin zu verwenden. Dafür braucht es auf dem Server folgende Einstellung in der Konfigurationsdatei (/etc/jitsi/meet/DOMAIN-config.js) :

desktopSharingFirefoxDisabled: false, desktopSharingFirefoxMaxVersionExtRequired: 51,

Für den Chrome Browser muss zuerst ein eigenes Plugin gebaut werden. Hier ist eine Anleitung zum Bauen des Chrome Plugins. Das Plugin kann dann per drag & drop bei anderen Clients installiert werden.

Kurzinstallation für Debian/Ubuntu

Du willst gleich durchstarten? There you go!

$ wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add - $ sudo sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list" $ sudo apt-get -y update $ sudo apt-get -y install jitsi-meet

Aktuelle Probleme

In der Testphase ist aufgefallen, dass manchmal die Verbindung bei Clients abgebrochen wird und es dann unmöglich ist eine Konferenz zu halten. Der Grund dafür war, dass der automatische Health Check alle verfügbaren File Descriptors aufbrauchte und diese nicht mehr sauber aufgeräumte. Hier das beschriebene Problem auf GitHub:

https://github.com/jitsi/jitsi-meet/issues/1231

Die Lösung dazu ist, in der Datei /etc/jitsi/jicofo/sip-communicator.properties folgendes einzufügen um den Health Check zu deaktiveren:

org.jitsi.jicofo.HEALTH_CHECK_INTERVAL=-1

Links

• Jitsi
• Atlassian
• Webrtc

Wenn es um SSL/TLS Konfigurationen geht, rücken Mailserver weniger schnell in den Blickpunkt als Webserver. Auch diese sollten eine solide SSL/TLS-Konfiguration mit gültigen Zertifikaten geniessen. In den Protokollen IMAP und POP3 fallen komplett falsch konfigurierte Mailserver schnell auf, in der Server-Server-Kommunikation jedoch sind oft unzureichende Standards gesetzt. Des Öfteren werden ungültige oder gar keine Zertifikate akzeptiert, da eine Verbindung wichtiger ist, als die Sicherheit.

SSL/TLS Konfiguration bei Postfix

Folgend ein Auszug aus der Postfix (htt Main Configuration, welcher sich allerdings jederzeit ändern kann. Sehr wichtige Optionen sind smtpd_tls_security_level und smtp_tls_security_level, welche standardmässig “none” sind. Das bedeutet, dass der Server nie TLS verwenden wird. Daher sollten diese Optionen immer auf may oder encrypt gesetzt werden

# TLS parameters
tls_high_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!MEDIUM:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_medium_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_low_cipherlist = !aNULL:ALL:!EXPORT:!DES:!3DES:!MD5:!RC4:@STRENGTH smtpd_tls_cert_file = /etc/postfix/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/postfix/ssl-cert-snakeoil.key smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh4096.pem
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

 

SSL/TLS Konfiguration bei Dovecot

Dies ist ein Auszug aus der Dovecot Configuration und zeigt eine mögliche Konfiguration der SSL/TLS-Parameter für Dovecot auf.

# DH parameters length to use. ssl_dh_parameters_length = 4096   # SSL protocols to use. ssl_protocols = !SSLv2 !SSLv3   # SSL ciphers to use ssl_cipher_list = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS   # Prefer the server's order of ciphers over client's. ssl_prefer_server_ciphers = yes

Sender Policy Framework (SPF)

Mit Hilfe von SPF (RFC 7208) kann validiert werden, ob ein Server, welcher eine E-Mail zustellen will, auch berechtigt ist von der entsprechenden Domain E-Mails zu versenden.

Beispielsweise baut der Server smtp.send.example.com eine Verbindung zum Server smtp.recv.example.com auf und versucht ihm eine E-Mail von user@mail.example.com zuzustellen. Anhand von SPF kann der Server smtp.recv.example.com überprüfen, ob der Server smtp.send.example.com ein gültiger E-Mail-Server für die Domain mail.example.com ist.

Der entsprechende SPF Record existiert im DNS-System und kann in etwa wie folgt aussehen:

mail.example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all"

Das heisst wenn eine der folgenden Bedingungen erfüllt ist, wird die E-Mail angenommen:

• • die IP Adresse des Servers smtp.send.example.com innerhalb von 192.0.2.0/24 oder 2001:db8::1 liegt
  • der DNS A Record mail.example.com der IP Adresse des Servers smtp.send.example.com entspricht

In allen anderen Fällen muss die E-Mail weitere Checks durchlaufen (welche selber definiert werden können).

DomainKeys Identified Mail (DKIM) Signaturen

Die Idee hinter DomainKeys Identified Mail (DKIM, RFC 6376) ist, zu prüfen, dass eine E-Mail während des Transports nicht verändert wurde. Um dies sicherzustellen, werden die Header, der Content und die Attachments einer E-Mail signiert. Dabei wird jedoch nicht der gesamte Header signiert, da sich dort beim Transport einer E-Mail gewisse Felder ändern können. Das RFC schlägt vor, folgende Werte zu signieren:

• From (REQUIRED)
• Reply-To
• Subject
• Date
• To, Cc
• Resent-Date, Resent-From, Resent-To, Resent-Cc
• In-Reply-To, References
• List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

DKIM-Signaturen werden im Header einer E-Mail abgelegt, das Feld nennt sich DKIM-Signature. Der Wert dieses Feldes beinhaltet mehrere Key-Value-Paare. Die Wichtigsten sind:

• v: DKIM version
• a: algorithm (e.g. rsa-sha256)
• d: signing domain (origin Domain)
• s: selector

Ein empfangender E-Mail-Server kann anhand der Domain und des Selectors den aktuellen Domain Key über DNS anfragen. Der DNS-Eintrag sieht in etwa wie folgt aus:

selector._domainkey.example.com IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" )

Wird also eine E-Mail mit dem Header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.org; s=mail; t=1498137281; bh=ClzbA4T6yvpEouOct2aSAnFWcEUHTr6SDxrQizAy6ao=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=QTY/4jFXMH2piHJ478mtyQ6heutdCLw/VCrD3XcDVugITPSXnrEqiV07+N9YNQcTraCmyxT49upd8uz9fqRLz0VTZWoPF3+9eT9X2jdQU/1WpVtalFrQuBoXfzy4KZJdxp/DjwAB89CkmvRvv5aYSw0XrJsry1uMoVJx6NDCskA=

empfangen, so ist der entsprechende TXT-DNS-Eintrag, welcher den Key referenziert, “mail._domainkey.example.org“.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) erweitert die beiden Mechanismen DKIM und SPF. Wenn kein DKIM Header vorhanden ist oder kein SPF Record gefunden wird, wird bei diesen beiden Verfahren nichts gemacht und die E-Mail normal behandelt. DMARC bietet die Möglichkeit, zu sagen, was mit einer E-Mail, bei der eines oder beide Verfahren nicht vorhanden sind, gemacht werden soll. DMARC ist auch ein bisschen strikter, was das DKIM Handling angeht, so muss z.B. die From-Adresse mit der Domain im DKIM-Signature Feld übereinstimmen. Ein weiterer Punkt, den DMARC ermöglicht, ist das Reporting von falsch verschickten E-Mails. So können Reports von empfangenden E-Mail-Servern angefordert werden.

Wie auch DKIM wird DMARC im DNS publiziert. Ein möglicher Eintrag sieht in etwa wie folgt aus:

_dmarc.example.com IN TXT "v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com"

Wobei die einzelnen Werte folgende Bedeutung haben:

• v: Version
• p: Policy für diese Domain
• sp: Policy für Subdomains
• pct: Prozent der “schlechten” E-Mails, ab wann die Policy greifen soll
• rua: DMARC Report URI Adresse

Testen

Manuell kann mit openssl getestet werden. Dies sind nur Basis-Befehle, welche den Inhalt des Server-Zertifikates in Textform darstellen. Es können auch Cipher-Suites getestet werden, da dies aber lange und vielzählige Commands sind, wird empfohlen, dies mit den vorhandenen Diensten (bspw. Hardenize) zu machen. Ist dies nicht gewünscht oder technisch nicht möglich, kann SSL Decoder auch lokal installiert werden, da die Software Open Source auf GitHub verfügbar ist.

• SMTP

$ openssl s_client -connect example.com:25 -starttls smtp 2>/dev/null </dev/zero | openssl x509 -noout -text

 

• IMAP

$ openssl s_client -connect example.com:143 -starttls imap 2>/dev/null </dev/zero | openssl x509 -noout -text

Zusätzliche Features wie SPF oder DMARC zu testen, kann zum einen sehr simpel gemacht werden, indem einfach die DNS Records überprüft werden:

# SPF Record $ dig +short TXT example.com "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all" # DKIM $ dig +short TXT mail._domainkey.example.com "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB"   # DMARC $ dig +short TXT _dmarc.example.com "v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.com"

Um umfassendere Tests mit einer Auswertung des Inhalts zu machen, eignen sich diverse Anbieter, wie z.B. Hardenize oder MX Toolbox.

Weiterführendes

Des Weiteren ist anzumerken, dass DNS-based Authentication of Named Entities (DANE) auch bei E-Mail-Servern eingesetzt werden kann. Dies sprengt aber den Rahmen dieses Blog-Posts und wird in einem anderen behandelt werden. Es gibt auch sehr gute HowTo-Guides für E-Mail-Server, hier sollen die folgenden zwei genannt werden:

• ISPmail guide for Debian Jessie
• Mailserver From Scratch (Debian 8)

Links

• MX Toolbox
• Cipherli.st
• Hardenize

 

Diverse Firmen setzen zur Zeit auf die proprietäre Enterprise Password Vault von CyberArk um sensitive Zugangsdaten, Zertifikate und SSH-Schlüssel sicher zu verwalten. Die Software ermöglicht es über ein Webinterface bspw. Benutzername und Passwort einer Applikation zu hinterlegen.

Sensitive Daten manuell via Webinterface abzulegen ist jedoch in der heutigen Zeit, wo Automation, Provisioning und Configuration Management zu den Grundpfeilern jeder optimierten IT-Infrastruktur gehört, kein gangbarer Weg mehr.

Entsprechend gehören saubere APIs auch zum “state of the art” jeder grösseren Webapplikation. Denn ohne API lassen sich viele Prozesse überhaupt nicht automatisieren und optimieren.

Auch die Password Vault von CyberArk ermöglicht es gewisse Abläufe via API zu tätigen. Jedoch ist die API qualitativ nicht so weit wie man sich dies gern wünschte und diverse API Endpunkte sind noch nicht verfügbar. Das Verwalten von Accounts funktioniert jedoch soweit schon einwandfrei, womit bspw. Credentials während einer OS-Installation problemlos automatisch im digitalen Tresor abgelegt werden können.

Hierzu haben wir das CLI Tool Pyark geschrieben, welches auf GitHub unter der GPLv3 frei zur Verfügung steht.

Pyark

Pyark ist ein python-basiertes Utility, welches die Interaktion mit der Password Vault API vereinfacht. Das Tool lässt sich leicht in bestehende Prozesse integrieren und nimmt einem mühsame curl-Basteleien ab.

Ein möglicher Anwendungsfall ist das Ablegen des root-Passworts während der automatisierten Installation einer Linux Distribution. Bei Distributionen der Red Hat Familie kann das Script bspw. als Kickstart Post-Task ausgeführt werden um das root-Passwort sicher zu verwahren.

An dieser Stelle fragt man sich ggf. wieso hierzu überhaupt ein weiteres Tool notwendig sei, hierzu gibt es doch curl und Konsorten? Das Problem lässt sich leider nicht mit einem curl-Einzeiler beheben, denn die API ist so aufgebaut, dass zuerst die Authentisierung durchgeführt werden muss. D.h. in einem ersten Schritt wird der Benutzername und das Passwort des Service Accounts an die API gesendet. Authentifiziert CyberArk den Benutzer erfolgreich erhält man im HTTP Header CyberArkLogonResult ein Token zurück. Dieses Token muss für alle folgenden Anfragen verwenden werden. Somit müssen etwaige Fehler oder Authentisierungs-Probleme sauber abgefangen und auch das Token aus dem HTTP Header extrahiert werden, was mit curl nicht ganz trivial ist.

Zur Zeit unterstützt Pyark folgende Funktionen:

• Accounts auslesen
• Accounts erstellen
• Accounts löschen

Dabei ist zu beachten, dass eine aktuelle Version der Password Vault installiert sein muss. Andernfalls besteht die Möglichkeit, dass die entsprechenden API-Endpunkte noch nicht integriert wurden. Hierzu verlangt man am besten vom Hersteller die passende API-Referenz Dokumentation und prüft, ob die Entpunkte vorhanden sind.

Installation

Die Installation ist soweit sehr simpel. Es kann wahlweise das GitHub Repository geklont und setup.py ausgeführt werden oder es wird mit pip install pyark direkt aus dem Internet installiert. Bei Bedarf kann natürlich auch nur das __init__.py kopiert und ausgeführt werden.

Beispiele

Untenstehend drei Beispiele, wie ein Account ausgelesen, erstellt und gelöscht werden kann.

• Account auslesen:

$ pyark --base https://vault.example.com \
        --apiuser foobar                 \
        --apipassword supersecret42      \
        account get                      \
        --safe MySafe                    \
        --keywords bruce

• Account erstellen:

$ pyark --base https://vault.example.com \
        --apiuser foobar                 \
        --apipassword supersecret42      \
        account create                   \
        --safe MySafe                    \
        --platformid TestPlatform        \
        --accountname brucewayne         \
        --address batcave.example.com    \
        --username brucew                \
        --password d4rkkn1ght

• Account löschen:

$ pyark --base https://vault.example.com \
        --apiuser foobar                 \
        --apipassword supersecret42      \
        account delete                   \
        --safe MySafe                    \
        --accountname brucewayne         \
        --keywords bruce