Wichtiges Sicherheitsupdate für J4 | 4.2.8

Wenn ich mich recht erinnere, hatte ich "Web Services Joomla Token" mal deaktiviert und das Backend war nicht mehr aufrufbar.

Zitat von CurlY BracketS

Ich bin für den Joomla D-A-CH Newsletter angemeldet, und da habe ich gestern Abend Post gekriegt zum Thema.

Guten Morgen,

Wo gibt's den? Finde nichts...

cu...O.D:

Zitat von flotte

So, die vom Security-Team gelieferten Infos sind in die Firewall eingetragen. Damit sollte hier schon mal alles sicher sein.

Guten Morgen,

in die Firewall? Wie wo was? Kannst Du das bitte mal näher erklären?

Danke!

cu...O.D.

Ich deaktiviere, neben mehreren anderen:

Web Services - Bannerverwaltung
Web Services - Benutzerverwaltung
Web Services - Datenschutzverwaltung
Web Services - Inhaltsverwaltung
Web Services - Installation
Web Services - Konfiguration
Web Services - Kontaktverwaltung
Web Services - Medien
Web Services - Menüverwaltung
Web Services - Modulverwaltung
Web Services - Nachrichtenverwaltung
Web Services - Newsfeedverwaltung
Web Services - Pluginverwaltung
Web Services - Schlagwörterverwaltung
Web Services - Sprachverwaltung
Web Services - Templateverwaltung
Web Services - Weiterleitungsverwaltung

API Authentifizierung - Joomla Token
Benutzer - Joomla API Token

Geplante Aufgaben
System - Aufgabenbenachrichtigung
Weitere Plugins zum Bereich "Aufgabe".

Zitat von deGobbis

Ich meine, man sollte bei der Installation auswählen können, was man an Core Erweiterungen braucht und das dann darüber steuern lassen.

Die Schwierigkeit "Was ist das überhaupt?" bleibt ja trotzdem und zieht die Installation in die Länge. Gerade für Menschen, die das das erste Mal machen, eine Qual. Ich PERSÖNLICH, weil ich o.g. Features bisher nur auf 1 Seite nutze, fände es besser, wen die erst mal gar nicht aktiviert sind. Umgekehrt ist es aber manchmal verwirrend, was man nun aktivieren muss, damit man bestimmte Features nutzen kann.

Schwierig, irgendwie. Bleibt halt doch eine individuelle Entscheidung.

Zitat von deGobbis

Ich stimme Dir voll und ganz zu, aber wir haben es häufig mit Anfängern zu tun, die das nicht richtig einschätzen können.

Ich meine, man sollte bei der Installation auswählen können, was man an Core Erweiterungen braucht und das dann darüber steuern lassen.

Besser wäre es sogar, auch Core Erweiterungen nur zu installieren, wenn sie benötigt werden.

Das würde die Basis schmälern und das System sicherer machen.

Ja eben, gerade als Anfänger weiß man da ja noch (nicht) welche Erweiterungen benötigt werden.

Weiß auch jetzt nicht auswendig, ob diese "Webservices" per default auf de-aktiviert stehen. Schaue ich mir noch an.

Zitat von Re:Later

Ja, da gibt es schon länger Probleme, dass vielleicht sogar falsche Pakete installiert werden könnten. Ob das mittlerweile gänzlich gefixt ist, habe ich den Überblick verloren.

Deshalb mein Hinweis:

Also von https://developer.joomla.org/nightly-builds.html herunterladen.

War mir bei vorherigen Updates auch schon aufgefallen.

Muss mich da um eine Seite kümmern, welche seit der DB PW - im Kundenpanel Änderung (dann inkl. in die configuration.php) einen 500er schmeißt. Hmpf.

Liebe Grüße

Christine

Meine Meinung ist hier eigentlich ganz simpel:

Natürlich sollten alle Services/APIs etc. deaktiviert sein, die nicht zwangsweise für ein Default-Setup genutzt werden und nur aktiviert werden müssen, wenn man sie tatsächlich einsetzen will. Das sollte doch überhaupt gar kein Problem sein.

Die Installation auf gar keinen Fall aufblähen, sondern immer so schlank wie möglich halten.

Zitat von O.D.

in die Firewall? Wie wo was? Kannst Du das bitte mal näher erklären?

Das Security Team ist in Kontakt mit einer Vielzahl von Hostern. Zum Zeitpunkt des Release stellen wir den Hostern Regelsätze bereit, die in die von den Hostern betriebenen Firewall-Applikationen eingespielt werden können.

Zitat von SniperSister

Das Security Team ist in Kontakt mit einer Vielzahl von Hostern. Zum Zeitpunkt des Release stellen wir den Hostern Regelsätze bereit, die in die von den Hostern betriebenen Firewall-Applikationen eingespielt werden können.

Das ist auch absolut super David!
Wenn ich mal spaßeshalber quer-beet über die Server schaue sind nicht einmal 50% aller 4er-Joomla geupdated worden - trotz direkter Anspache an alle Kunden, als das Update das erste mal angekündigt wurde.

Zitat von flotte

Wenn ich mal spaßeshalber quer-beet über die Server schaue sind nicht einmal 50% aller 4er-Joomla geupdated worden - trotz direkter Anspache an alle Kunden, als das Update das erste mal angekündigt wurde.

Ich habe nichts anderes erwartet...

Ja ich auch nicht - umso wichtigr sind die Firewall-Regeln.

im heise-Forum steht:

Zitat

der patch lässt schlimmes befürchten...

Der Patch ist jetzt auf github. Sieht aus als könnte ich ungepatcht jede nicht-öffentliche API mit 'public' als Query Parameter wie eine offene API aufrufen.

Das wäre Joomlas Log4Shell...

Joomla 4 war von Anfang an so konzipiert, dass Core-Erweiterungen installiert werden, aber nahezu alle deaktivierbar sind, aber nicht deinstallierbar. Ein Hintergrund ist auch das Handling bzw. die Pflege dieser Erweiterungen bei/für Installation und Updates. Es gibt jetzt einfach sozusagen "Listen", in denen die Core-Erweiterungen hinterlegt sind. Keine Wenn und Abers.

Das Entkoppeln von Erweiterungen hat sich aus Sicht eines Nutzers ein bisschen als unwägbar rausgestellt. Wer pflegt das, wann wo wie? Wie kompatibel sind die Änderungen? Wie schnell kommen sie Neuerungen und Bugs hinterher? Können Joomla-Releases gebremst werden, weil diese oder jene Entkoppelte Unsinn macht? Welche entkoppelt man? Welche Prioritäten bekommen die?

Kurz: Dass alle installiert werden und weitgehend zentral in 1 Repository liegen, auf das eben mehr Leute einen Blick haben, selbst, wenn sie bestimmte Bereiche nicht nutzen, aber doch mal testen bei Issues, finde ich derzeit schon besser.

Auf meinem Android-Smartphone hätte ich das natürlich gern, dass ich diesen ganzen "Schrott", der da so rumdümpelt aktiv selber installieren muss (und mich das Phon dann nicht die ganze Zeit nervt, dass doch mit deaktiviertem/deinstalliertem Schrott alles viel besser wäre...)

Zitat von Stef

Joomla sollte aber mit gutem Beispiel vorangehen und noch den Administrator-Bereich absichern.

Und wie? htaccess nach Schema F ist jedenfalls nicht in allen Fällen geeignet. Schon alleine nicht technisch immer und je Provider. Oder mit Rattenschwanz für Nutzer, wenn z.B. Bilder aus dem administrator/Cache-Stammordner im Frontend nicht angezeigt werden bzw. andere Cache-Ordner nicht aus Backend gelöscht werden, wenn man den traditionellen verwendet. Oder nur der, den man eingestellt hat, den aber Erweiterungen ignorieren, die hart kodiert /cache/ verwenden. Früher wurden einfach alle gelöscht

Es gibt auch Provider, die /administrator/ per se per htaccess und unveränderlich dicht machen.

/libraries/ hat bereits eine .htaccess drinnen, aber simpel. Man darf halt nicht per Browser rein.

Alles kein Spaß in dieser oder jener Situation.

Betonung auf Rattenschwanz, wenn man es allen recht machen will.

Zitat von Stef

Hier kannst du dich am Newsletter anmelden: (weiter unten)

https://dach.joomladay.org/

Super! Danke!

Zitat von SniperSister

Das Security Team ist in Kontakt mit einer Vielzahl von Hostern. Zum Zeitpunkt des Release stellen wir den Hostern Regelsätze bereit, die in die von den Hostern betriebenen Firewall-Applikationen eingespielt werden können.

Das ist ja sehr interessant. Welche Hoster sind das denn? Wir sind bei Domainfactory.

Wir setzen auf allen Seiten die Akeeba Admintools ein. Kann man bei diesen in Bezug auf diese Geschichte was einstellen?

cu...O.D.

Zitat von O.D.

Wir setzen auf allen Seiten die Akeeba Admintools ein. Kann man bei diesen in Bezug auf diese Geschichte was einstellen?

Joomla! aktuell halten und das Problem ist gelöst

Zitat von Stef

Schön wurde die Cassiopeia Vorschau auf 4.2.8 gebracht.

Joomla sollte aber mit gutem Beispiel vorangehen und noch den Administrator-Bereich absichern.

https://cassiopeia.joomla.com/

Natürlich würde die Seite aktualisiert. "Joomla" in diesem Fall bin ich
Bzgl. Administrator Absicherung... ja, könnte man machen... hab bei CloudAccess (joomla.com) nicht geschaut, was für Möglichkeiten es gibt + s. Post von Re:Later