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:

Reverse Proxy für Mailcow-Dockerized

Mit dem Aufsetzen eines neuen Servers auf Basis von Debian 9 kamen wieder einige neue Dinge auf mich zu. Da ich mich für die Mailserver-Groupware Mailcow-Dockerized von André Peters entschieden hatte, musste ich mich erstmals mit einem Reverse Proxy auseinander setzten.

Wozu brauche ich einen Reverse Proxy?

Auf dem neuen Server sollte neben dem Webserver ein Mailserver installiert werden. Da Mailcow-Dockerized eine Container-Lösung ist und in diesem Container neben Postfix, Dovecot und Co. auch der Webserver Nginx läuft, würden aber die Ports 443 und 80 mit dem zuvor installierten Apache, auf dem eine Test-Webseite aktiv ist, kollidieren. 

Mailcow, Servercow
Mailcow UI

Um Mailcow zu installieren, musste zuerst der Apache gestoppt werden. Der Mailserver wurde dann in ein paar Minuten aufgesetzt und eingerichtet. Das Mailcow UI konnte wie gewünscht via HTTP und HTTPS erreicht werden. Im Anschluss wurde die Konfiguration nochmals geöffnet, um die Bindung an die Ports 80 und 443 entsprechend in 8080 und 8443 in der /root/mailcow.dockerized/mailcow.conf zu ändern. 

Natürlich hätte man das auch während der Installation durchführen können, jedoch wollte ich zuvor die testen, ob der Mailserver ordnungsgemäß läuft.

Nach dem nochmaligen Durchlauf der Konfigurationsänderungen, konnte nun das Mailcow UI natürlich von außen nicht mehr aufgerufen werden.

Nun wurde der Apache wieder gestartet und die Test-Websites ging wieder online.

Erstellen eines neuen Virtual Host

Um nun auch den Nginx in Mailcow-Dockerized zu erreichen, musste ein Reverse Proxy eingerichtet werden. Dazu habe ich einen Virtual Host, welcher auf Port 80 und Port 443 lauscht, in einer neu erstellten /etc/apache2/sites-available/proxy.conf mit folgendem Inhalt eingerichtet. Dieser leitet die Anfragen von mail.domain.tld an den Nginx im Container weiter. Das hatte zur Folge, dass die alten Zertifikate aus Mailcow-Dockerized unbrauchbar wurden. Ich habe darauf hin mein bestehendes Zertifikat um die Subdomain https://mail.domain.tld erweitert. Der Ort, wo die Zertifikate hinterlegt sind, musste im Codeblock (siehe unten) noch eingetragen werden.

Nach einem erneuten Neustart des Apache2 lief alles wie gewünscht, sowohl die Test-Webseite, als auch das Mailcow UI.

Weiterführende Infos und Anleitungen findet man auf der Projektseite von Mailcow-Dockerized unter: https://mailcow.github.io/mailcow-dockerized-docs/

Welche Version ist installiert?

Bei grafischen Anwendungen ist es recht einfach herauszufinden welche Version in Debian eines Paketes installiert ist. Auch auf dem Desktop kann man das entsprechende Programm schnell mit Synaptic identifzieren. Auf dem Server fehlen hierzu die entsprechenden grafischen Hilfsmittel.

Synaptic, Debian, Linux
Synaptic

Hier kann man folgenden Befehl verwenden, um entsprechende Informationen zum installierten Paket erhalten.

Beispiel Prosody:

Viel Spaß!

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.

Stretch auf den Raspberry Pi

Gestern habe ich nun auch meinen Raspberry Pi Raspbian Stretch spendiert. Ich war dabei etwas skeptisch, ob Flightradar mit dem neuen stabilen OS zurecht kommt. Meine Bedenken waren aber völlig unbegründet.

Zuerst wird in der /etc/apt/sources.list

 „jessie“ durch „stretch“ ersetzt und die Datei mit Ctrl + o gespeichert und der Editor mit Ctrl + x verlassen. Dann werden die Quellen neu eingelesen

und Stretch installiert.

Zum Schluss sollte man mit

noch etwas aufräumen.

Wie wäre es mit einem Rolling Release?

Ein Rolling Release ist schon eine feine Sache. Ständig wird das Betriebssystem mit neuen Software- und Sicherheitspaketen versorgt. Neuere Kernel finden zeitnah den Weg ins Projekt. Das System ist somit immer aktuell.

Was gibt es nun für Möglichkeiten? Typische Vertreter der Rolling Releases sind Arch, Gentoo, Solus oder Manjaro. Ich habe mich jedoch vor einigen Tagen für Debian Testing entschieden. An dieser Stelle muss man aber erwähnen, dass es sich beim Testing-Zweig nur solange um ein Rolling Release handelt bis Testing den Status Freeze erreicht. Dieser Status hält ca. drei bis vier Monate an. In dieser Zeit werden keine neuen Softwarepakete und Kernel mehr aufgenommen. Nur noch Sichereitsupdates fließen in das Projekt, bis Debian eine neue stabile Version veröffentlicht. Testing wird dann zu Stable und alles beginnt von neuem. Da es also einen gewissen Zeitrum gibt, wo keine Neuerungen in Debian Testing einfließen, ist Testing kein wirkliches Rolling Release.

Entsprechende Images werden wöchentlich hier zur Verfügung gestellt.

Wie wechselt man hingegen von Debian Stretch auf Debian Testing. Das ist relativ einfach. Zuerst bearbeitet man die /etc/apt/sources.list. Hierbei sollten alle Fremdquellen auskommentiert werden. Danach werden die Einträge „Stretch“ durch „Testing“ ersetzt. (siehe Screenshot)

/etc/apt/sources.list

Das Upgrade  wird dann wie folgt angestoßen.

Bevor man sich auf Debian Testing einlässt, sollte man zuvor natürlich ein Backup anlegen!

Debian GNU/Linux buster/sid 64 Bit

Es kann natürlich beim Einsatz zu Problemen kommen. Bugs werden i.d.R. aber schnell gefixt.

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.