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 das entsprechende Community-Module installiert. 

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

Das Ganze funktioniert natürlich auch umgekehrt.

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

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

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.

Prosody – Admin Web

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

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:

Der Systemstatus sah danach nun wieder unauffällig aus:

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.

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.

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

Ich habe die Config von Prosody geöffnet.

Diese wurde um die Einträge

und 

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

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:

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. 

Prosody Webadmin

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:

Prosody – Migrator

Vor ein paar Tagen habe ich nachträglich Prosody auf meinem Server an eine MySQL-Datenbank angebunden. Diese Funktion hat einige Vorteile gegenüber der herkömmlichen Speicherung der Daten im Datenverzeichnis. 

Die Anbindung an MySQL ist relativ einfach. Deshalb möchte ich hierauf nicht weiter eingehen.

Mit dem Prosody Migrator kann man nun den Altbestand der User in die Datenbank übernehmen. Der Pfad des Datenverzeichnisses ist in meinem Fall /etc/prosody/data. Zu beachten wäre, dass alle schon vorhandenen User-Daten dabei überschrieben werden.

Um mit der Migration zu beginnen, wechselt man in das Verzeichnis in dem der Ordner „data“ liegt. 

Von der Beispiel-Konfiguration sollte man vorhe eine Sicherung anlegen.

Nun öffnet man die Config und bearbeitet diese folgendermaßen:

Hierbei ist der Pfad (falls data woanders liegt) sowie die Zugangsdaten zur MySQL-Datenbank anzupassen. Das Ganze speichert man mit Ctrl + o und verlässt den Editor mit Ctrl + x. Nun migriert man mit 

alle bestehenden Accounts. Erscheint

Migrating…
Done!

war die Migration erfolgreich.

Viel Spaß!

Uberspace – Prosody 0.9.10 => 0.9.11

Seit einiger Zeit betreibe ich meinen eigenen XMPP-Server auf meinem Uberspace. Mittlerweile wird auch dieser Server mit einem Let’s Encrypt Zertifikat verschlüsselt. 

Da ich nun gestern dabei war Roundcube zu aktualisieren und alles so reibungslos lief, habe ich mich im Nachgang an Prosody gewagt. Hier lief noch die Version 0.9.10.

Zuerst wurde der Service angehalten,

dann die neue Version 0.9.11 installiert

und die Beispiel-Config nach ~/etc/prosody/ verschoben.

Nun musste der Symlink zur Config erneut erstellt werden.

Im Anschluss wurde der Service zu Prosody neu gestartet

und die alte Version 0.9.10 deinstalliert.

Ein abschließender Check zeigt nun aktuelle Version (siehe Screenshot).

Nachtrag

Einige Anpassungen habe ich laut der Anleitung https://0101010.one noch nachgeschoben. Dazu gehören eine neue OpenSSL-Version sowie zwei Anpassungen von Lua.

Check der Version von OpenSSL vorher:

Check der Version von OpenSSL nach der Installation:

Check der Versionen der Lua-Module vorher:

Check der Versionen der Lua-Module nach der Installation: