Beiträge von Galak

UCEPROJECT wird auch gar nicht von allen Blacklistchecks überhaupt aufgerufen, im Idealfall sollte diese "Liste" auch komplett ignoriert werden. Die Betreiber können weder kontaktiert werden, noch gibt es ein Impressum, noch irgendetwas Anderes was auf nur ein Mindestmaß an Seriosität hinweisen würde. Stattdessen stellen sie jeden bloß der es doch schafft sie zu kontaktieren (http://www.uceprotect.org/cart00neys/index.html) und das unzensiert, mit Mailheader, Adressen und Namen. (Dürfte schon als DGSVO-Verstoß durchgehen, allerdings scheinen die in der Schweiz zu sitzen.)

Zitat von Ingob

Mailcow kann doch gar nicht auf Webhoster installiert werden, dazu braucht man doch schon einen Server oder nicht?

Dass es um Webhosting geht, sollte idealerweise im ersten Beitrag schon erwähnt werden.

Ansonsten kann ich mich der Empfehlung zu Nextcloud nur anschließen, das kann eigentlich alles was du möchtest und vermutlich Dinge von denen du noch gar nicht wusstest, dass du sie möchtest.

Die für Nextcloud nötigen Pakete sollten im Webhosting eigentlich aktiv sein, wenn nicht könntest du den Support kontaktieren ob man das aktivieren kann.

Das betrifft dann auch nicht exklusiv Teamspeak, sondern die gesamte Netzwerkverbindung zum Server. Ich hatte eben auch meinen ersten, eigenen Timeout und in dem Moment auch keinen Zugriff via SSH.

Man kann auch folgendes in crontab eintragen. Das funktioniert dann ohne Probleme, oder zusätzliche Scripte/Modifikationen.

@reboot PFAD/ts3server_startscript.sh start

(PFAD ist dann mit dem Pfad zum Script zu ersetzen.)

Es ist seltsam, ich kann die Sicherheitslücke selbst auf der offiziellen Version 0.9.34-1+wheezy1 noch problemlos reproduzieren. Sobald man irgendeinen Unsinn als Passwort angibt wird dieses munter in die Log-Dateien geschrieben.
Wichtig ist dabei eigentlich nur, dass der Login von Froxlor an der eigenen Datenbank scheitert.

Wie es aussieht muss ich da wohl mal mit einer weiteren Installation von Froxlor testen, ob es wirklich nur an meiner Version so funktioniert. Wobei ich es schon recht seltsam finde, dass es wohl sonst keiner reproduzieren kann.

Die Daten werden konstant neu geschrieben, was ich auch nicht blockieren kann. Allerdings wurde nicht mit dem Netcup Paket, sondern wirklich mit der Version von Froxlor selbst aktualisiert.

Ich bin auch noch dabei das genauer zu untersuchen, wollte das nur sicherheitshalber hier vermerken, falls es kein Einzelfall ist.

Sicherheitsprobleme wurden dadurch bei mir allerdings nicht ausgelöst, weil Froxlor das aktuelle Passwort noch gar nicht kennt.

Der Fehler ist auch in der offiziellen Version 0.9.3.2-1 auf Debian Wheezy nicht wirklich behoben. Die Log-Dateien werden nach wie vor mit einer Vorschau des Passwortes angelegt. Sollte man der DB Server ausfallen wird das Passwort, bzw Teile davon sogar direkt im Index gezeigt.

Version: 0.9.33.2-1+wheezy1 ist jetzt auch von Froxlor in den Standart Repos verfügbar. Allerdings muss das /logs/-Verzeichnis noch selbst geleert werden.

Quelle: Important bugfix release 0.9.33.2 - Announcements - Froxlor Forum

Welches Script wäre in diesem Fall wichtig genug, um eine deart veraltete Funktion wieder zu aktivieren? Wenn es sich wirklich nur um ein Theme handelt, solltest du wirklich lieber beim Froxlor Standart bleiben, anstatt ein PHP Downgrade und noch dazu register_globals = on in Erwägung zu ziehen.