Ich habe meine Metadaten gerne unter Kontrolle und mir deswegen einen XMPP Server unter Prosody gegönnt. Hier einige Notizen rund um die Installation.
Prosody Paketquellen einbinden um von der trägen Paketverwaltung in den Ubuntu Repos unabhängig zu werden:
echo deb http://packages.prosody.im/debian $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list
Den Key der Paketquelle holen und in APT werfen:
wget https://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add -
sudo apt-get update
Prosody installieren:
apt-get install prosody
Einstellungen für den Benutzer prosody in /etc/passwd kontrollieren, der nur /bin/false als Shell erhalten darf:
prosody:x:113:121:Prosody XMPP Server,,,:/var/lib/prosody:/bin/false
Prosody Konfiguration anpassen – unter Lua ist ein doppeltes Minus ein Kommentarzeichen:
vi /etc/prosody/prosody.cfg.lua
Die Konfigurationsdatei ist gut strukturiert und weitgehend selbsterklärend, so dass beim Lesen kaum Fragen offen bleiben. Im Zweifel alle Restfragen über die sauber strukturierte Dokumentation bei https://prosody.im klären.
In der Konfiguration
-
den Admin für den XMPP Server festlegen
-
die Sektion Module durchsehen und z.B. version sowie uptime deaktivieren, damit wir nach Außen hin nicht gleich alle Angriffspunkte verraten.
Ebenfalls kontrollieren, ob Registrierungen über Clients abgelehnt werden. Das scheint nötig zu sein, damit man nicht mit Konten zugespamt wird:
allow_registration = false;
Wir wollen die Verbindung zwischen Client und Server Zwangsverschlüsseln:
c2s_require_encryption = true
Das geht im Prinzip auch für s2s (Server to Server) Verbindungen. Hier liegt auch der Grund, warum wir dringend OTR Verschlüsselung haben wollen, wenn wir nicht auf der eigenen Domain chatten.
Die Passwörter der Benutzer verschlüsselt speichern, auch wenn die Nebenwirkung ist, dass manche Clients länger brauchen, um sich anzumelden:
authentication = "internal_hashed"
SSL Key einbinden. Hierbei für Zwischenzertifikate ein PEM basteln wie für Dovecot und Freunde ebenfalls üblich.
ssl = {
key = "/etc/prosody/certs/domain.key";
certificate = "/etc/prosody/certs/domain.pem";
}
Siehe zu intermediären Zertifikaten auch: https://prosody.im/doc/certificates?s[]=pem#certificate_chains
Unser Zertifikatsspeicher für Prosody verwendet schlicht Symlinks, um sich die Arbeit einfacher zu machen, wenn Zertifikate erneuert werden:
ls -la /etc/prosody/certs/
# Zeigt dann:
domain.key -> /etc/path/to/certs/ssl/domain.tld/domain.key
domain.pem -> /etc/path/to/certs/ssl/mailserver/domain.pem
Die Hosts einrichten:
VirtualHost "xmppserver.tld"
-- enabled = false -- Remove this line to enable this host
ssl = {
key = "/etc/prosody/certs/domain.key";
certificate = "/etc/prosody/certs/domain.pem";
}
Prosody neu starten:
sudo service prosody restart
Nach Fehlern suchen:
tail -f /var/log/prosody/prosody.err
Einen Fehler finden und wohl erst einmal schlicht hinnehmen:
The version of LuaExpat on your system does not support stanza size limits, which may leave servers on untrusted networks (e.g. the internet) vulnerable to denial-of-service attacks. You should upgrade to LuaExpat 1.3.0 or higher as soon as possible. See http://prosody.im/doc/depends#luaexpat for more information.
Siehe hierzu auch https://prosody.im/doc/depends#luaexpat und den Hinweis, dass man in diesem Fall auf compression verzichten sollte (das ist der Default).
Die Benutzer anlegen – den oben eingetragenen Admin hierbei nicht vergessen:
prosodyctl adduser admin@xmppserver.tld
Jetzt mit den ersten Clients eine Verbindung aufbauen und den Verbindungen zusehen, wie sie reinkommen:
tail -f /var/log/prosody/prosody.log
Einen Blick in den Benutzerkontenbereich werfen:
ls -la /var/lib/prosody/xmppserver.tld/accounts
Dort nachsehen, ob die *.dat Dateien auch wirklich nur verschlüsselte Passwörter enthalten.
Am Ende den gesamten Server auf den Prüfstand stellen: https://xmpp.net/
Siehe zum folgenden Abschnitt: https://code.google.com/p/prosody-modules/wiki/mod_log_auth und auch https://jabber.lqdn.fr/securing-our-jabber-server-with-fail2ban-securisation-du-serveur-jabber-avec-fail2ban/
Im Modules Verzeichnis von Prosody ein weiteres Modul hinterlegen:
# /usr/lib/prosody/modules
wget http://prosody-modules.googlecode.com/hg/mod_log_auth/mod_log_auth.lua
Das Modul umbenennen, damit es läuft:
mv mod_log_auth.lua mod_auth_log.lua
Das Modul in der Konfiguration einschalten
# /etc/prosody/prosody.cfg.lua
"auth_log" -- Anbindung fuer fail2ban http://prosody-modules.googlecode.com/hg/mod_log_auth/mod_log_auth.lua
Prosody neu starten und kontrollieren, ob nun die Connects mitgeschrieben werden:
tail -f /var/log/syslog
tail -f /var/log/prosody/prosody.log
Einen Filter für fail2ban anlegen:
vi /etc/fail2ban/filter.d/prosody-auth.conf
Inhalt:
# Fail2Ban configuration file for prosody authentication
[Definition]
failregex = Failed authentication attempt \(not-authorized\) from IP: <HOST>
ignoreregex =
In der jail.local hinterlegen:
# XMPP
[prosody-auth]
enabled = true
port = 5223
filter = prosody-auth
logpath = /var/log/prosody/*.log
maxretry = 10
Die Dienste neu starten:
sudo service prosody restart
sudo service fail2ban restart
In Check_MK die Service discovery für den XMPP-Server-Host neu anschubsen, damit man auch dort sieht, was passiert.
Die nächsten Schritte: Für meine Schule muss das auch noch eingerichtet werden – dann allerdings mit LDAPs Anbindung, damit es jeder gleich nutzen kann und die Benutzerverwaltung einfacher wird.
