Beiträge von bembelimen

Danke fürs Testen. Ein paar Kommentare, die vielleicht helfen:

Zitat von deltapapa

Moin Moin,

also jetzt mal ein kurzes Feedback von meinem Ausflug zum public Ordner:

Stef: Deswegen kann diese Möglichkeit unter Laragon / Windows nicht funktionieren, weil Windows kein symlink kennt, sondern nur Verknüpfung.

Windows kann sogenannte "junctions", die sind fast wie Symlinks. Es gibt hier auch ein Tool für: https://schinagl.priv.at/nt/hardlinkshe…lextension.html

Zitat von deltapapa

Was natürlich auch nicht mehr da ist, ist der Backend Schutz, da im neuen Verzeichnis /public/administrator die entsprechende htaccess und htpasswd Datei fehlt.

Du kannst ganz normal in deinem public-Folder htaccess Schutzt fürs Backend einrichten. Auch das Frontend hat eine htaccess, die du mit z.B. Caching etc. bestücken kannst.

Zitat von deltapapa

Fazit: Eine coole und eigentlich recht einfach umzusetzende Maßnahme, jedoch ist die Unterstützung und das handling dazu noch nicht überall gegeben. ich werde das weiter beobachten, aber zur zeit ist die Nutzung des public Ordners noch ein Abenteuer

Wichtig ist, dass man vorher prüft ob Extensions (besonders Templates bzw. Template-Frameworks) manchmal immer noch ihre Assets aus dem Template-Ordner laden statt sauber aus "media". Da muss man den entsprechenden Ordner noch mit symlinken.

Zitat von z0r0z

Guten Abend, hat jemand schon den MW Image Manager für den TinyMCE im Einsatz und kann berichten?

https://mertsch-web.com/mw-image-manager.html

(Wenn der Link unpassend ist, bitte löschen)

Ich sehe da jetzt nichts was der Joomla!-Media-Manager nicht auch kann.

Besonders nach RE: Pro / Contra TinyMCE / JCE und eventuell mit https://github.com/joomla/joomla-cms/pull/48138 könnte es noch einfacher mit dem TinyMCE werden.

Zitat von bemerkenswelt

• Starke Passwörter verwenden
  Da bin ich zugegebenermaßen etwas schludrig.
  Habe aber im Video-Vortrag von SniperSister gehört (bzw. es so verstanden), dass es mehr auf die Länge des Passwortes ankommt und nicht so sehr auf die kreative Mischung von Zeichen etc.

Das stimmt. Um auf Nummer sicher zu gehen, kannst du in den User-Optionen die Mindest-Passwortstärke bestimmen

Zitat von bemerkenswelt

• MFA (Google Authenticator) verwenden
  Werde ich nicht tun!
  Sowas Ist mir alles zu nervig. Im Notfall habe ich Backups.

Hier gibt es aber auch einige Alternativen, vielleicht ist da was dabei?

Zitat von bemerkenswelt

• So wenig wie möglich weitere Extension einsetzen
  Da bin ich generell sehr sparsam.
  Allerdings, auf JCE verzichten möchte ich nicht. TinyMCE ist für mich keine Alternative.

Was fehlt dir denn beim TinyMCE? Eventuell reicht es ja, wenn du ihn einmal unter Plugins durchkonfigurierst?

Zitat von bemerkenswelt

• Backup, Backup, Backup
  Das habe ich durch das Mitlesen der zurückliegenden Angriffswellen, hier im Forum, gelernt!
  Seitdem mache nach jeder Änderung Akeeba Backups und lagere sie sogar lokal, bei mir.
  Eine früher gänzlich unübliche Verhaltensweise.

Das ist gut Da ich selbst ja faul bin, kann der nächste Schritt auch sein, dass du per Cronjob die antriggerst und dann automaitiert z.B. auf eine Hetzner-Storage-Box verschiebst.

Zitat von bemerkenswelt

Ich hatte 9 Websites damit ausgestattet und nehme es von allen wieder runter.
Und um Sicher zu sein, dass es keine Rückstände gibt, werde ich in den nächsten Wochen (und Monaten?) alle 9 Websites wahrscheinlich komplett neu einrichten.

Nicht vergessen: einige kleine Dinge solltest du trotzdem umsetzen:

• Backend per htaccess schützen
• Starke Passwörter verwenden
• MFA (Google Authenticator) verwenden
• So wenig wie möglich weitere Extension einsetzen
• Immer auf Updates achten (Auto Update des core und eventuell das Plugin von Tobias um bei Extensions zumindest informiert zu werden)
• Backup, Backup, Backup

Mit diesem Ansatz deckst du ziemlich viel ab und es ist überschaubar

Die Hacks versuchen u.a. auch einen Cronjob bzw. Hintergrundprozess auf dem Server anzulegen, damit werden dann gelöschte Dateien sofort wieder angelegt. Das ist wahrscheinlich bei dir passiert. Wenn dir nicht selbst der Server gehört, sodass du das überprüfen kannst, musst du wohl deinen Hoster kontaktieren ansonsten schaue mal in die Cronjobs bzw. Prozesse.

Zitat von WM-Loose

bembelimen wie hoch wäre schätzungweise die Zielsumme um das durchzuführen?

Das muss SniperSister sagen, ob da Interesse besteht und was der abgeschätzte Aufwand ist.

Zitat von flotte

Aus meiner Sicht sind automatische Updates des Cores und aller Erweiterungen die einzig wirksame Lösung - meinetwegen auch abschaltbar und mit Email, aber es muss vorhanden sein. WordPress kann das schon lange, ich weiß nicht was Joomla hier für ein Problem hat.

Wie David schrieb, ist der Aufwand das sicher zu machen enorm, angefangen von der Infrastruktur (hierbei meine ich nicht den Server sondern die technische Infrastruktur) und Schulung bzw. SDKs. Wir sind alleine beim Core-Auto-Update, startend bei TUF mehrere Jahre dran gewesen.

Hier nun die Frage: da diese Funktion ja vielen Parteien helfen würde wäre es doch eventuell sinnvoll ein Crowdfunding aufzusetzen. Kennst du den da mehrere größere Player, die da mitmachen würden, damit da was zustande kommt?

Das könnte man dann dem Security Team zur Verfügung stellen, die dann das nicht nur in ihrer Freizeit bauen müssten.

Aktuell wird gerade an mehr Ajax im Backend gearbeitet. Vielleicht macht es Sinn da mal mit den Mentoren/Studenten zu reden. Die sind alle in Mattermost und einige davon sprechen auch Deutsch falls Englisch ein Hindernis ist.

Leg doch in den gleichen Ordner ein Bootstrap ab und importiere diesen in deine user.css.

Zitat von Svenoldman

Von den Konkurrenten z.b. WordPress usw. hört man kaum was.

Wahrscheinlich liest du einfach keine Wordpress News

Du kannst den Public folder auch lassen und lokal auf das Hauptverzeichnis von Joomla zeigen und online auf den Public folder.

Am Ende, wenn du den Ordner gar nicht mehr willst, einfach auf das Hauptverzeichnis zeigen und den Ordner löschen.

Ich habe leider kein Laragon zum Testen. Im Endeffekt sind symlinks ja ein Feature von dem Betriebssystem, nicht von Joomla. Wenn du ein Backup einspielst, machst du das indem zu den Public folder noch nicht verwendest und erst danach ihn einrichtest.

Was ich gestern eigentlich sagen wollte, theoretisch kannst du denn Public folder auch per Hand einrichten, indem du symlinks anlegst.

Hallo,

sorry für die verspätete Rückmeldung.

Also der public Folder ist ja eigentlich nur das Symlinken von ein paar Ordner. Der SSH Weg ist der "komfortable".

Eigentlich brauchst du nur diese eine Zeile: https://github.com/joomla/joomla-…Command.php#L91

Diese führt nach und nach diese Schritte aus: https://github.com/joomla/joomla-…rHelper.php#L95

Sprich wenn du den code irgendwo zum ausführen bekommst, kannst du es selbst erstellen. Die Frage ist, warum du da einen Installation-Ordner hast. Hast du den Symlink des "installation"-Ordner mal vor dem Backup wieder gelöscht?

Zitat von Esquilo

Warum kann denn der public Ordner bei einer "normalen" Installation nicht automatisch mit angelegt werden?

Weil du am Ende die Domain auf den Public Ordner umzeigen lassen musst.

Zitat von kitepascal

Dazu der Knackpunkt beim aktuellen Hack: die Webshell landet in images/ – einem Ordner, der auch mit Public Folder öffentlich bleiben muss.

Die landen erst in tmp und von dort wird verteilt. Also ist es durchaus hilfreich wenn der tmp-Ordner nicht mehr erreichbar ist. 🤷

Und die Liste von mir ist deutlich länger als nur der public-Ordner

Das ist halt wieder das nächste Pflaster für ein Problem, was man mit Joomla Coremitteln sauber hätte verhindern können:

• nutzt den public-Folder von Joomla (wichtig)
• sperrt den Admin-Bereich per htaccess ab
• deaktiviert die API Plugins, wenn ihr sie nicht braucht
• nutzt lange Passwörter
• aktiviert Multi-Factor-Authentication
• erlaubt im Image-Ordner nur Dateitypen, die ihr wirklich braucht
• Same for "media", auch hier braucht es eigentlich nur CSS/JS/Fonts/Bilder
• etc. pp.

Ich weiß nicht ob das unter "sachdienlich" fällt, aber ich würde heutzutage solche kleinen Dinge einfach in eine KI werfen und der entsprechende Anweisungen geben.

Zur weißen Seite: es hilft manchmal error_reporting +ini_set display_error direkt am Anfang des Moduls zu setzen.

Das Problem an der Versionierung ist, dass da nur X Einträge vorgehalten werden. Dafür gibt's die Actionlogs, damit kannst du das tracken, was passiert.

Mit ein bisschen testen, werden die Module eventuell in 6.2 noch "intelligenter": https://github.com/joomla/joomla-cms/pull/47570

Wäre ein Astroid-Beitrag, in dem das alles gesammelt wird nicht akzeptabel? Dann gibts zumindest nicht jedesmal einen neuen Beitrag und wens nicht interessiert kanns einfach nicht abonnieren? Meinjanur

Eine Software-seitige Firewall ist eher Semi-gut

1. Schau ob dein Hoster etwas Serverseitiges anbietet
2. nutze den "public folder" von Joomla! um so ziemlich alle Ordner außer images/media und die index.php wegzusperren
3. schütze dein Backed-Ordner per htaccess
4. (optional) deaktiviere PHP in dem Media/Image-Ordnern

Dann braucht es keine komischen Firewalls.