XMPP

Prosody inaktive User löschen

Im Artikel „Prosody – inaktive User ausfindig machen“ hatte ich beschrieben, wie man nach inaktiven XMPP-Accounts in Prosody suchen kann. Eine elegante Möglichkeit diese User wieder loszuwerden zeigt Thomas Leister auf seinem Blog.

Ich habe mich für meinen XMPP-Server entschieden, Accounts welche drei Monate inaktiv waren zu löschen. Hierzu erstelle ich lt. Anleitung ein Script.

# prosodyctl mod_list_inactive intux.de 3month default | sed -e 's/^/prosodyctl deluser /' > delusers.sh

1	# prosodyctl mod_list_inactive intux.de 3month default \| sed -e 's/^/prosodyctl deluser /' > delusers.sh

Dieses wird dann im Anschluss ausgeführt.

# sh ./delusers.sh

1	# sh ./delusers.sh

Danach sind alle inaktiven User des zuvor erwähnten Zeitraums vom drei Monaten vom Server gelöscht.

XEP-0368 auf dem Prosody XMPP-Server

Letztes Wochenende hatte ich den ComplianceTester von Daniel Gultsch durchlaufen lassen und gesehen, dass enige XMPP-Erweiterungen (XEP) nicht aktiviert waren. Die größten Probleme hatte ich bei der Suche nach einer Lösung zur Aktivierung von XEP-0368. Schlußendlich half mir die Anleitung von Dominion auf adminforge.de.

Hier meine Änderungen am XMPP-Server intux.de:

Zuerst wurde sslh installiert.

# apt install sslh

1	# apt install sslh

An dieser Stelle wurde ein „eigenständiger Server“ ausgewählt.

Dann musste die Datei /etc/apache2/ports.conf (Apache2) mit

# nano /etc/apache2/ports.conf

1	# nano /etc/apache2/ports.conf

von

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 443
</IfModule>

<IfModule mod_gnutls.c>
        Listen 443
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

# If you just change the port or add more ports here, you will likely also

# have to change the VirtualHost statement in

# /etc/apache2/sites-enabled/000-default.conf

Listen 80

Listen 443

</IfModule>

Listen 443

</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 127.0.0.1:443
</IfModule>

<IfModule mod_gnutls.c>
        Listen 127.0.0.1:443
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

# If you just change the port or add more ports here, you will likely also

# have to change the VirtualHost statement in

# /etc/apache2/sites-enabled/000-default.conf

Listen 80

Listen 127.0.0.1:443

</IfModule>

Listen 127.0.0.1:443

</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

geändert werden. Im Anschluss wurde in die /etc/prosody/prosody.cfg.lua (Prosody) mit

# nano /etc/prosody/prosody.cfg.lua

1	# nano /etc/prosody/prosody.cfg.lua

die Zeile

legacy_ssl_ports = 5223

1	legacy_ssl_ports = 5223

eingefügt. In der /etc/default/sslh musste via

# nano /etc/default/sslh

1	# nano /etc/default/sslh

Prosody – inaktive User ausfindig machen

Da Spam-Registrierungen unter XMPP an der Tagesordnung sind, wird es immer mal wieder notwendig inaktive Accounts wieder los zu werden.

Mit folgendem Befehl kann man entsprechende User innerhalb des letzten Jahres auf seinem Prosody XMPP-Server ausfindig machen. Vorausgesetzt man hat die entsprechenden Community-Module mod_list_inactive sowie mod_lastlog installiert.

# prosodyctl mod_list_inactive domain.tld 1year default

1	# prosodyctl mod_list_inactive domain.tld 1year default

Der Zeitraum lässt sich mit day, week oder month natürlich auch kürzer fassen.

Das Ganze funktioniert natürlich auch umgekehrt. Hierfür ist das Modul mod_list_active nötig.

# prosodyctl mod_list_active domain.tld 1year default

1	# prosodyctl mod_list_active domain.tld 1year default

Prosody Admin Web

Das Neuaufsetzen von Prosody auf einen Server mit Debian 9 lief bei mir mal wieder nicht ganz ohne Probleme. So hatte ich erst am Wochenende festgestellt, dass es nicht möglich war einzelne Usern zu löschen. Die letzten Spam-User-Registrierungen, wollte ich aber schnell wieder los werden. Der Lösch-Befehl

# prosodyctl deluser user@domain.tld

1	# prosodyctl deluser user@domain.tld

brachte in /var/log/prosody/prosody.err eine Fehlermeldung mit dem Hinweis auf ein Upgrade der neuen Datenbank. Dies war notwendig, da Prosody zuvor auf MySQL lief. Debian 9 hingegen nutzt MariaDB. Dieser Fehler konnte nun recht einfach mit

# prosodyctl mod_storage_sql upgrade

1	# prosodyctl mod_storage_sql upgrade

behoben werden.

Nun fiel mir aber noch ein weiteres Problem ins Auge. Seit einiger Zeit nutze ich das Modul mod_admin_web. Auch hier konnte ich mich nicht mehr im Webinterface einwählen.

Die Ursache bestand darin, dass ich das Modul wie in der offiziellen Beschreibung

VirtualHost "example.com"
   modules_enabled = {
       .....
       "admin_web";
       .....
   }

VirtualHost "example.com"

modules_enabled = {

.....

"admin_web";

.....

}

zwar in die prosody.cfg.lua eingebunden hatte, jedoch die Installation im Nachgang nicht ausgeführt hatte.

Da meine Community-Module in /usr/lib/prosody/prosody-modules liegen, sah die Lösung dann wie folgt aus:

# cd /usr/lib/prosody/prosody-modules/mod_admin_web/admin_web
# ./get_deps.sh
# /etc/init.d/prosody restart

# cd /usr/lib/prosody/prosody-modules/mod_admin_web/admin_web

# ./get_deps.sh

# /etc/init.d/prosody restart

Der Systemstatus sah danach nun wieder unauffällig aus:

systemctl status prosody.service

1	systemctl status prosody.service

? prosody.service - LSB: Prosody XMPP Server
Loaded: loaded (/etc/init.d/prosody; generated; vendor preset: enabled)
Active: active (running) since Sun 2017-11-12 18:07:09 CET; 13h ago
Docs: man:systemd-sysv-generator(8)
Process: 15629 ExecStop=/etc/init.d/prosody stop (code=exited, status=0/SUCCESS)
Process: 13569 ExecReload=/etc/init.d/prosody reload (code=exited, status=0/SUCCESS)
Process: 15635 ExecStart=/etc/init.d/prosody start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4915)
Memory: 17.4M
CPU: 22.794s
CGroup: /system.slice/prosody.service
+-15651 lua5.1 /usr/bin/prosody

Nov 12 18:07:09 intux systemd[1]: Stopped LSB: Prosody XMPP Server.
Nov 12 18:07:09 intux systemd[1]: Starting LSB: Prosody XMPP Server...
Nov 12 18:07:09 intux prosody[15635]: Starting Prosody XMPP Server: prosody.
Nov 12 18:07:09 intux systemd[1]: Started LSB: Prosody XMPP Server.
Nov 13 06:25:16 intux systemd[1]: Reloading LSB: Prosody XMPP Server.
Nov 13 06:25:16 intux prosody[13569]: Reloading Prosody XMPP Server: prosody.
Nov 13 06:25:16 intux systemd[1]: Reloaded LSB: Prosody XMPP Server.

? prosody.service - LSB: Prosody XMPP Server

Loaded: loaded (/etc/init.d/prosody; generated; vendor preset: enabled)

Active: active (running) since Sun 2017-11-12 18:07:09 CET; 13h ago

Docs: man:systemd-sysv-generator(8)

Process: 15629 ExecStop=/etc/init.d/prosody stop (code=exited, status=0/SUCCESS)

Process: 13569 ExecReload=/etc/init.d/prosody reload (code=exited, status=0/SUCCESS)

Process: 15635 ExecStart=/etc/init.d/prosody start (code=exited, status=0/SUCCESS)

Tasks: 1 (limit: 4915)

Memory: 17.4M

CPU: 22.794s

CGroup: /system.slice/prosody.service

+-15651 lua5.1 /usr/bin/prosody

Nov 12 18:07:09 intux systemd[1]: Stopped LSB: Prosody XMPP Server.

Nov 12 18:07:09 intux systemd[1]: Starting LSB: Prosody XMPP Server...

Nov 12 18:07:09 intux prosody[15635]: Starting Prosody XMPP Server: prosody.

Nov 12 18:07:09 intux systemd[1]: Started LSB: Prosody XMPP Server.

Nov 13 06:25:16 intux systemd[1]: Reloading LSB: Prosody XMPP Server.

Nov 13 06:25:16 intux prosody[13569]: Reloading Prosody XMPP Server: prosody.

Nov 13 06:25:16 intux systemd[1]: Reloaded LSB: Prosody XMPP Server.

Und immer wieder Servercow

Mein Umstieg auf Debian 9

Aus IT-technischer Sicht sollte man Web- und Mailserver auf getrennten Systemen laufen lassen. Da ich aber meinen Server privat betreibe und das Ganze mehr ein Hobby ist, laufen bei mir Web- und Mailserver auf einem Host.

vServer, Servercow — Übersicht der laufenden Prozesse mit htop

Angefangen hatte ich mit Debian 8 auf dem bisher meine Seite intux.de lief. Parallel dazu hatte ich einen Mailserver mit Mailcow 0.14 aufgesetzt. Beides arbeitete bisher ohne Probleme und es gab eigentlich keinerlei Bedarf hieran irgendetwas zu ändern, da Debian 8 als LTS noch bis Ende April 2020 unterstützt wird.

Da ich aber mein System auf die aktuelle Version Debian 9 Stretch anheben wollte, musste ich mir Gedanken machen, wie das am besten zu realisieren ist. Da es momentan kein Upgrade für Mailcow 0.14 gibt und diese Version nicht auf dem aktuellen Debian Stretch läuft, kam für mich nur die Container-Variante Mailcow Dockerized in Frage.

Ein Upgrade auf Debian 9 wäre natürlich möglich gewesen, jedoch habe ich mich dazu entschlossen Stretch auf einem separaten Server zu installieren und alle Dienste nacheinander rüber zu holen. Dieses Vorhaben konnte ich ohne Zeitdruck auf Servercow realisieren. Der grandiose Support von André Peters war hierbei mehr als hilfreich. Bei einigen Problemen hatte ich so einen kompetenten Ansprechpartner, der sehr schnell auf Anfragen reagierte.

Da Mailcow Dockerized autonom und aus dem System herausgelöst in einer eigenen Virtualisierung arbeitet, wär mein Apache 2 mit dem Webserver Nginx in Dockerized kollidiert. Hierzu war es notwendig einen Reverse Proxy auf dem Apache, wo mein Blog läuft, einzurichten. Des Weiteren konnten von meinem frischen System keine Mails über PHP abgesetzt werden. Auch hier musste ich mich in eine für mich neue Thematik, einen Local MTA, einarbeiten, welcher dann u.a. Systemnachrichten an Mailcow Dockerized zum Versenden übergibt.

Fazit

Den Server parallel einzurichten und alle Dienste nach und nach umzuziehen stellte sich aus der Situation als die richtige Entscheidung heraus. Ich war so nicht gezwungen alles am Stück wieder zum Laufen zu bringen. Mailcow Dockerized ist leicht zu installieren und ohne ewige Konfiguration sofort einsatzbereit. Trotz zwei nun nebeneinander arbeitender Webserver läuft das gesamte System performanter als vorher.

Ich habe mich zur Verwirklichung meiner kleinen Projekte vor fast 10 Monaten bewusst und aufgrund guter Kritiken für Servercow entschieden. Bei Problemen am Server und speziell mit Mailcow steht ein kompetenter Ansprechpartner zur Seite. Diesen Schritt habe ich zu keinem Zeitpunkt bereut. Sicher hat man mit einem eigenen Server einiges an Arbeit und Verantwortung auf dem Schirm, aber man ist dafür wesentlich flexibler. Dafür bietet Servercow ein gutes Zuhause.

Sicherheitstest XMPP

Das XMPP Observatory ist wieder da. Nachdem der Dienst auf xmpp.net eingestellt wurde, ist die Testseite nun auf https://check.messaging.one wieder neu aufgelegt wurden.

http-upload in Prosody aktivieren

Um nun auch Bilder in den XMPP-Chaträumen versenden zu können, habe ich den http-upload in Prosody aktiviert. Dazu wurde zuerst ein A-Record für die Subdomain upload.intux.de angelegt. Danach musste mein Let’s Encrypt Zertifikat, welches für intux.de und www.intux.de gültig war, noch erweitert werden.

# /opt/letsencrypt/letsencrypt-auto certonly --renew-by-default --rsa-key-size 4096 -d intux.de -d www.intux.de -d upload.intux.de

1	# /opt/letsencrypt/letsencrypt-auto certonly --renew-by-default --rsa-key-size 4096 -d intux.de -d www.intux.de -d upload.intux.de

Im Anschluss wurden die Zertifikate noch in das entsprechende Verzeichnis /etc/prosody/certs kopiert.

# cp /etc/letsencrypt/live/intux.de/fullchain.pem /etc/prosody/certs
# cp /etc/letsencrypt/live/intux.de/privkey.pem /etc/prosody/certs
# chown root:prosody /etc/prosody/certs -R

# cp /etc/letsencrypt/live/intux.de/fullchain.pem /etc/prosody/certs

# cp /etc/letsencrypt/live/intux.de/privkey.pem /etc/prosody/certs

# chown root:prosody /etc/prosody/certs -R

Ich habe die Config von Prosody geöffnet.

nano /etc/prosody/prosody.cfg.lua

1	nano /etc/prosody/prosody.cfg.lua

Diese wurde um die Einträge

modules_enabled = {

.....
"http_upload";

.....
}

modules_enabled = {

.....

"http_upload";

.....

}

und

Component "upload.intux.de" "http_upload"

1	Component "upload.intux.de" "http_upload"

erweitert. Danach wurde Prosody neu gestartet und http-upload aktiviert.

# /etc/init.d/prosody restart

1	# /etc/init.d/prosody restart

Tipp

In Gajim muss das Plugin HttpUpload nachinstalliert werden.

Unerwünschte Anmeldungen in Prosody

Seit einiger Zeit kommt es auf meinem XMPP-Server immer wieder verstärkt zu Registrierungen von Spam-Accounts. Die neuen User sehen dann in etwa so aus:

l0v382l0stdust348@domain.tld

Das Schlimme dabei ist, dass solche Anmeldungen fast im Minutentakt erfolgen und sich so plötzlich dutzende neue unerwünschte Accounts in die Datenbank eintragen. Als erste Reaktion sperrte ich früher i.d.R. für eine gewisse Zeit die öffentliche Anmeldung. Da die Angriffe jedoch meist von ein und derselben IP kommen, kann man diese mit folgendem Eintrag in der /etc/prosody/prosody.cfg.lua recht erfolgreich abwehren.

Dazu setzt man dies entsprechende IP auf die Blacklist zur Registrierung. Hier ein Beispiel:

allow_registration = true
min_seconds_between_registrations = 300
registration_blacklist = { "83.218.198.86" }

allow_registration = true

min_seconds_between_registrations = 300

registration_blacklist = { "83.218.198.86" }

Dabei werden Registrierungen zwar erlaubt, jedoch nur alle 300 Sekunden. Die IP von der die Spam-Registrierungen ausging wird gesperrt.

Prosody kann auch nerven

Es hat einige Zeit gedauert bis ich den HTTP Server unter Prosody vernünftig einbinden konnte. Eigentlich wollte ich ja nur das Webinterface mod_admin_web nutzen. Egal wie ich es anstellte, ich bekam keinen Zugang, trotz Befolgung der Installationshinweise.

Das Problem kam eigentlich nur zustande, da ich die Config aus meinem Artikel zur Installation des XMPP-Servers auf Uberspace übernommen hatte. Hierbei wurde der VirtualHost vor den SSL-Pfaden gesetzt. Dies macht aber den Zugang zum HTTP-Server unmöglich.

Nachdem ich den VirtualHost, wie in meiner aktuellen Config nach den SSL-Pfaden eingetragen hatte, konnte ich endlich auch mein Webadmin wie gewünscht erreichen.

Auszug aus meiner alten Konfiguration bei Uberspace

Hier nun meine aktuelle prosody.cfg.lua:

pidfile = "/var/run/prosody/prosody.pid"

storage = "sql"
 
sql = {
    driver = "MySQL";
    database = "prosody";
    host = "localhost";
    username = "bn";
    password = "pw";
}

plugin_paths = { "/usr/lib/prosody/prosody-modules/" }

admins = {"admin@domain.tld" }
modules_enabled = {
	"roster";
	"saslauth";
 	"tls";
	"dialback";
	"disco";
	"private";
	"vcard";
	"privacy";
	"version";
	"uptime";
	"time";
	"ping";
	"posix";
	"pep";
	"register";
	"admin_adhoc";
	"motd";
	"welcome";
	"proxy65";
	"watchregistrations";
	"register_web";
	"admin_web";
	"http_upload";
}

log = {
 debug = "/var/log/prosody/prosody.log";
 error = "/var/log/prosody/prosody.err";
}

c2s_require_encryption = true  
s2s_require_encryption = true
s2s_secure_auth = true
s2s_secure_domains = { "trashserver.net", "jabber.de", "c0by.de", "jabber.org", "xmpp.org", "xmpp.maltris.org" }
s2s_insecure_domains = {}

proxy65_ports = { 55555 }

authentication = "internal_hashed"

allow_registration = true
min_seconds_between_registrations = 300
registration_blacklist = { "83.218.198.86" }

ssl = {
        key = "/etc/prosody/certs/privkey.pem";
        certificate = "/etc/prosody/certs/fullchain.pem";
       
        dhparam = "/etc/prosody/certs/dh-4096.pem";
 
        ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";
 
        options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" }

}

VirtualHost "domain.tld"

register_web_template = "/etc/prosody/register-templates/Prosody-Web-Registration-Theme"

Component "proxy.domain.tld" "proxy65"

	proxy65_acl = { "domain.tld" }

Component "conference.domain.tld" "muc"
        name = "Prosody Chatrooms"
        restrict_room_creation = false

Component "upload.domain.tld" "http_upload"

pidfile = "/var/run/prosody/prosody.pid"

storage = "sql"

sql = {

driver = "MySQL";

database = "prosody";

host = "localhost";

username = "bn";

password = "pw";

}

plugin_paths = { "/usr/lib/prosody/prosody-modules/" }

admins = {"admin@domain.tld" }

modules_enabled = {

"roster";

"saslauth";

"tls";

"dialback";

"disco";

"private";

"vcard";

"privacy";

"version";

"uptime";

"time";

"ping";

"posix";

"pep";

"register";

"admin_adhoc";

"motd";

"welcome";

"proxy65";

"watchregistrations";

"register_web";

"admin_web";

"http_upload";

}

log = {

debug = "/var/log/prosody/prosody.log";

error = "/var/log/prosody/prosody.err";

}

c2s_require_encryption = true

s2s_require_encryption = true

s2s_secure_auth = true

s2s_secure_domains = { "trashserver.net", "jabber.de", "c0by.de", "jabber.org", "xmpp.org", "xmpp.maltris.org" }

s2s_insecure_domains = {}

proxy65_ports = { 55555 }

authentication = "internal_hashed"

allow_registration = true

min_seconds_between_registrations = 300

registration_blacklist = { "83.218.198.86" }

ssl = {

key = "/etc/prosody/certs/privkey.pem";

certificate = "/etc/prosody/certs/fullchain.pem";

dhparam = "/etc/prosody/certs/dh-4096.pem";

ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";

options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" }

}

VirtualHost "domain.tld"

register_web_template = "/etc/prosody/register-templates/Prosody-Web-Registration-Theme"

Component "proxy.domain.tld" "proxy65"

proxy65_acl = { "domain.tld" }

Component "conference.domain.tld" "muc"

name = "Prosody Chatrooms"

restrict_room_creation = false

Component "upload.domain.tld" "http_upload"

OMEMO Für Gajim

Will man mit Gajim die Multi-Client-Ende-zu-Ende-Verschlüsselung OMEMO unter Debian 8 nutzen, so kann man ganz einfach das entsprechende Paket aus den Backports installieren.

# apt install gajim-omemo

1	# apt install gajim-omemo

Viel Spaß!