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.

Angriff auf Joomla!-Installation

Vor ein paar Tagen wurde eine auf meinem vServer laufende Joomla!-Instanz massiv angegriffen. Der Inhaber dieser Seite bekam in ca. einer Stunde über 600 Mails vom Nachrichtensystem. So etwas ist bedauerlich und nicht gerade schön mit anzusehen.

Was war passiert?

Die Analyse des Logs /var/log/mail.log zeigte, dass Mails im 5-6 Sekunden-Takt vom Server an den Administrator gesendet wurden. 

Was wurde kurzfristig unternommen?

Zu allererst wurde der Versand der Systemmails der Joomla!-Installation deaktiviert. Damit konnte die Spam-Welle vorerst gestoppt werden. Bei der weiteren Analyse stellte sich heraus, dass die User-Registrierung aktiv war und sich über 600 User registriert hatten. Die dazu verwendeten eMail-Adressen hatten alle die Domain-Endung .ru. Im nächsten Schritt wurde die Registrierung ebenfalls deaktiviert. Warum diese aktiv war, kann ich leider nicht mehr nachvollziehen. Alle verdächtigen registrierten User der Seite wurden gelöscht.

Wie ging es weiter?

Da ich zu dem Zeitpunkt immer noch nicht genau wusste was genau passiert war, habe ich ein älteres Backup der Datenbank eingespielt (zum Glück werden Backups der Datenbanken, wie im Artikel „MySQL- Sicherung ohne Passwort im Script“ beschrieben, täglich automatisch angelegt). Nach dem Einspielen stellte sich heraus, dass hier nur die bekannten Administratoren als Benutzer in der Joomla!-Installation gespeichert waren. Die Registrierung wurde wieder deaktiviert und so die Sicherheitslücke geschlossen. Abschließend habe ich nachgeschaut, ob Dateien oder Verzeichnisse der Joomla!-Installation in den letzten Tagen verändert wurden. Dazu wechselte ich in das entsprechende Verzeichnis

und suchte die Änderungen der Dateien der letzten fünf Tage

Ausgabe:

sowie den Änderungen der Verzeichnisse

Ausgabe:

Die Dateien und Verzeichnisse wurden dann meinerseits überprüft. Da es hier keinerlei Auffälligkeiten gab, konnte auf das Einspielen eines Backups der kompletten Installation verzichtet werden.

Was war nun tatsächlich passiert?

Es konnten sich von außen User registrieren. Die so erstellten Accounts wurden aber nicht aktiviert, da die angegeben eMail-Adressen wahrscheinlich nicht valide waren. Das System verschickte jedoch bei jeder neuen Registrierung eine entsprechende eMail an den Superadministrator. So kam es zu einer massiven Welle von Registrierungsbestätigungen. Da die registrierten Accounts nicht aktiviert werden konnten, hatten die Aktionen keine Auswirkungen auf das System.

Kann das nochmal vorkommen?

Durch die deaktivierte Registrierung kann es zu dieser Art von Angriffen nun nicht mehr kommen.

MySQL- Sicherung ohne Passwort im Script

Nach dem ich nun nieder geschrieben hatte, wie ich meine SQL-Datenbanken automatisch sichere, kamen einige gute Anregungen in den Kommentaren. Darauf hin habe ich das System etwas umgestellt. Dazu wurde zu allererst der Storage vom root auf einen User übertragen. Somit konnte ich auch den Cronjob für den User einrichten. Der Eintrag, wie im ersten Artikel „MySQL-Sicherung“ in /etc/crontab wurde wieder entfernt. und der Cron neu gestartet.

Als eingeloggter User habe ich dem selbigen mit

folgenden Befehl eingetragen.

Dann wurde eine ~/.my.cnf

mit entsprechendem Inhalt erstellt. Diese enthält das MySQL root Passwort.

„meinpasswort“ musste hier natürlich angepasst werden. Nach dem Abspeichern wurden der Datei die Rechte 600 vergeben.

Im Anschluss habe ich ein neues Script mit dem Inhalt

erstellt und dieses mit

ausführbar gemacht. Um die Datenbanken besser auseinander halten zu können, bekamen alle Datenbanken dieses Mal ein separates Verzeichnis.

Nun werden die Datenbank-Sicherungen jeden Morgen 2:00 Uhr in von einander getrennten Verzeichnissen komprimiert abgelegt.

Der Servercow-Storage wurde mit der Nextcloud-App „External Storage“ in die Cloud eingebunden und die Sicherungen landen so regelmäßig auf meinem Notebook.

MySQL-Sicherung

Inspiriert durch den Artikel „Backup oder Datensicherung eines root-Servers / vServers / VPS„von Bitblokes habe ich mir Gedanken gemacht, wie ich meine MySQL-Datenbanken vernünftig und regelmäßig sichern kann. Die Snapshots von Servercow sind schon sehr gut, um ein Backup des ganzen Servers zu erstellen. Jedoch ist man hin und wieder auf eine einzelne Datenbank angewiesen.

Da ich bei Servercow einen zusätzlichen RAID5 HDD-Netzwerkspeicher von 150 GB und diesen in meine Nextcloud eingebunden habe, kann ich dort bequem meine Datenbanksicherungen ablegen. Bei jeder Synchronisation zu Hause, landen dann die Sicherungen auf meinem Notebook. 

Da ich bisher meine Datenbanken manuell mit mysqldump durchgeführt habe, wollte ich das Ganze nun automatisieren.

Dazu wurde das Script MySQLscript.sh

mit folgendem Inhalt erstellt.

Dabei ist „in**********“ der Name meiner ersten Datenbank. Der Eintrag „meinpasswort“ im Script muss natürlich durch das MySQL root Passwort ersetzt werden. 

Im Anschluss wird das Script ausführbar gemacht

und der Befehl mit 

in den crontab eingetragen.

So wird nach dem Neustart von Cron jeden Tag um 2:00 Uhr eine Sicherung jeder einzelnen Datenbank im Verzeichnis /samba_share/backup abgelegt.

Upgrade auf Roundcube 1.3.0

Gestern wurde Roundcube in Version 1.3.0 released. Ich habe das Upgrade heute gleich auf meinem vServer angestoßen. Dazu wurde der Download von Roundcube 1.3.0 in /var/www/html abgelegt.

Der Tarball wurde entpackt,

das neue Verzeichnis betreten

und das Upgrade ausgeführt. Der Pfad muss hierbei entsprechend angepasst werden. Da meine Roundcube-Installation in /var/www/mail/rc liegt, sieht die Eingabe wie folgt aus:

Roundcube 1.3.0

Das Upgrade verlief ohne Probleme. Zum Schluss konnten das temporäre Upgrade-Verzeichnis und der Download gelöscht werden.

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:

Upgrade auf Roundcube 1.2.4

Heute habe ich das überfällige Upgrade von Roundcube auf Version 1.2.4 angestoßen. Dazu wurde der Download von Roundcube 1.2.4 in /var/www/html abgelegt.

Der Tarball wurde entpackt,

das neue Verzeichnis betreten

und das Upgrade ausgeführt. Dabei muss der Pfad individuell angepasst werden. Meine Roundcube-Installation liegt in /var/www/mail/rc.

Zum Schluss noch das überflüssige Verzeichnis und den Download entfernen.

Fertig!

Webadmin von ZNC nachträglich über SSL erreichbar machen

Als ich ZNC auf meinem Debian-Server installiert habe, hielt ich mich bei der Konfiguration an meine damalige Uberspace-Installation. Dort hatte ich die Standard-Abfrage

einfach nur bestätigt. Dies stellte nun kein gravierendes Problem dar. Im nachhinein war ich aber über den unverschlüsselten Zugang zum Webinterface via http://IP:Port nicht glücklich. Der Zugang über domain.tld:Port wurde logischerweise verwehrt.

Nun bin ich der Sache auf den Grund gegangen, warum ich das Webinterface nicht über domain.tld:Port erreiche. Hier verhinderte eine Kombination von dem Erzwingen von https und HSTS (HTTP Strict Transport Security) den Zugang zum Webinterface über intux.de. 

Der Entwickler rät davon ab die znc.conf im Editor zu bearbeiten. Stattdessen sollte hier das Webinterface zur weiteren Konfiguration genutzt werden. Dieses konnte ich ja, wie oben beschrieben, über http://IP:Port nutzen. Hier musste ich dann einen neuen Eintrag (anderer Port) in Listen Port(s) mit dem Häkchen SSL versehen. Über diesen Port ist dann nach dem Einpflegen von Let’s Encrypt das Webinterface via https erreichbar.

Ich verbinde mich nun mit mit dem ZNC-Bouncer via SSL mit: