XMPP Archive -

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.

# 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.

# 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ß!

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.

# cd  /etc/prosody

1	# cd /etc/prosody

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

# cp migrator.cfg.lua migrator.cfg.lua_bak

1	# cp migrator.cfg.lua migrator.cfg.lua_bak

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

# nano migrator.cfg.lua

1	# nano migrator.cfg.lua

local data_path = '/etc/prosody/data';

input {
type = "prosody_files";
path = data_path;
}

mydatabase {
type = "prosody_sql";
driver = "MySQL";
database = "Name der Datenbank";
username = "Benutzername der Datenbank";
password = "Passwort der Datenbank";
host = "localhost";
}
--[[

input {
type = "prosody_files";
path = data_path;
}
output {
type = "prosody_sql";
driver = "SQLite3";
database = data_path.."/prosody.sqlite";
}

]]

local data_path = '/etc/prosody/data';

input {

type = "prosody_files";

path = data_path;

}

mydatabase {

type = "prosody_sql";

driver = "MySQL";

database = "Name der Datenbank";

username = "Benutzername der Datenbank";

password = "Passwort der Datenbank";

host = "localhost";

}

--[[

input {

type = "prosody_files";

path = data_path;

}

output {

type = "prosody_sql";

driver = "SQLite3";

database = data_path.."/prosody.sqlite";

}

]]

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

# prosody-migrator input mydatabase

1	# prosody-migrator input mydatabase

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,

svc -d ~/service/prosody

1	svc -d ~/service/prosody

toast disarm prosody

1	toast disarm prosody

dann die neue Version 0.9.11 installiert

toast arm https://prosody.im/downloads/source/prosody-0.9.11.tar.gz

1	toast arm https://prosody.im/downloads/source/prosody-0.9.11.tar.gz

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

mv ~/.toast/armed/etc/prosody/prosody.cfg.lua ~/etc/prosody/prosody.cfg.lua.stock

1	mv ~/.toast/armed/etc/prosody/prosody.cfg.lua ~/etc/prosody/prosody.cfg.lua.stock

Nun musste der Symlink zur Config erneut erstellt werden.

ln -s ~/etc/prosody/prosody.cfg.lua ~/.toast/armed/etc/prosody/prosody.cfg.lua

1	ln -s ~/etc/prosody/prosody.cfg.lua ~/.toast/armed/etc/prosody/prosody.cfg.lua

Im Anschluss wurde der Service zu Prosody neu gestartet

svc -u ~/service/prosody

1	svc -u ~/service/prosody

und die alte Version 0.9.10 deinstalliert.

toast remove https://prosody.im/downloads/source/prosody-0.9.10.tar.gz

1	toast remove https://prosody.im/downloads/source/prosody-0.9.10.tar.gz

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

toast status prosody

1	toast status prosody

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:

openssl version

1	openssl version

toast arm https://www.openssl.org/source/openssl-1.0.2j.tar.gz && . ~/.bash_profile

1	toast arm https://www.openssl.org/source/openssl-1.0.2j.tar.gz && . ~/.bash_profile

Check der Version von OpenSSL nach der Installation:

openssl version

1	openssl version

Check der Versionen der Lua-Module vorher:

luarocks list

1	luarocks list

luarocks install luafilesystem --local
luarocks install luasec 0.5.1 --local OPENSSL_DIR=~/.toast/armed/usr/local/

1 2	luarocks install luafilesystem --local luarocks install luasec 0.5.1 --local OPENSSL_DIR=~/.toast/armed/usr/local/

Check der Versionen der Lua-Module nach der Installation:

luarocks list

1	luarocks list