Nimmst Du die Änderungen im Front- oder im Backend vor?
Zur Fehlersuche würde ist testweise alle (Fremd)Plugins deaktivieren die nicht unbedingt notwendig sind. Wenn es unterschiedliche Slider von unterschiedlichen Entwicklern betrifft, scheint es auch ein systemweites Problem zu sein. Und da kommen für mich zuerst das eingesetzte Template (Bearbeitung im Frontend) und Plugins in Frage.
Moin
Da fallen mir spontan fünf mögliche Fehlerquellen ein ...
1. Die Verzeichnisse auf dem Webserver haben keine ausreichenden Leserechte. CHMOD 755 per FTP sollte reichen.
2. Eine Regel in der htaccess verhindert den Zugriff
3. Eine Rechteverwaltung im Joomla verhindert den Zugriff
4. Eine Einstellung im Slider für das Bildverzeichnis (Quelle) ist falsch gesetzt.
5. Es gibt eventuell Einschränkungen durch eine zusätzliche Komponente die Bilderverzeichnisse für jeden Benutzer anlegt / verwaltet.
Gruß Jan
OK Zero, dann könnte dir dieser Text weiterhelfen:
Moin Dirk
Ich würde noch dazu schreiben das dieser Text nur ein Beispiel (!) ist, aus welcher Quelle er stammt und das hier im Forum natürlich Niemand eine Rechtsberatung geben kann. Ist Quatsch, wissen wir beide, aber wir müssen ja keine unnötige Fläche für Abmahnungen schaffen. 
Gruß Jan
Hast Du die versteckte .htaccess gelöscht? Damit Du sie sehen kannst, muss in Deinem FTP-Programm die Anzeige versteckter Dateien eingeschaltet sein. In Deiner Joomla-Konfiguration ist das Mod-Rewrite deaktiviert? Die Seite einmal neu laden lassen damit die Änderungen sichtbar werden?
Jetzt grade habe ich neue Datei runtergeladen (wie du sagtest) und es hat sich nix geändert
Wir sprechen von der htaccess?
- Du hast die htaccess.txt aus dem frischen Joomla-Paket kopiert?
- In das Verzeichnis mit dem "kaputten" Joomla einfügen lassen?
- Die "kaputte" versteckte .htaccess gelöscht?
- Die neue htaccess.txt in .htaccess umbekannt?
Und dort steht jetzt das drin?
##
# @package Joomla
# @copyright (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
# @license GNU General Public License version 2 or later; see LICENSE.txt
##
##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line 'Options +FollowSymLinks' may cause problems with some server configurations.
# It is required for the use of Apache mod_rewrite, but it may have already been set by
# your server administrator in a way that disallows changing it in this .htaccess file.
# If using it causes your site to produce an error, comment it out (add # to the
# beginning of the line), reload your site in your browser and test your sef urls. If
# they work, then it has been set by your server administrator and you do not need to
# set it here.
##
## Can be commented out if causes errors, see notes above.
Options +FollowSymlinks
Options -Indexes
## No directory listings
<IfModule mod_autoindex.c>
IndexIgnore *
</IfModule>
## Suppress mime type detection in browsers for unknown types
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>
## Protect against certain cross-origin requests. More information can be found here:
## https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)
## https://web.dev/why-coop-coep/
#<IfModule mod_headers.c>
# Header always set Cross-Origin-Resource-Policy "same-origin"
# Header always set Cross-Origin-Embedder-Policy "require-corp"
#</IfModule>
## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag
<FilesMatch "\.svg$">
<IfModule mod_headers.c>
Header always set Content-Security-Policy "script-src 'none'"
</IfModule>
</FilesMatch>
## These directives are only enabled if the Apache mod_rewrite module is enabled
<IfModule mod_rewrite.c>
RewriteEngine On
## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site then comment out the operations listed
# below by adding a # to the beginning of the line.
# This attempts to block the most common type of exploit `attempts` on Joomla!
#
# Block any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root home page
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.
## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects
##
# Uncomment the following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##
# RewriteBase /
## Begin - Joomla! core SEF Section.
#
# PHP FastCGI fix for HTTP Authorization, required for the API application
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# -- SEF URLs for the API application
# If the requested path starts with /api, the file is not /api/index.php
# and the request has not already been internally rewritten to the
# api/index.php script
RewriteCond %{REQUEST_URI} ^/api/
RewriteCond %{REQUEST_URI} !^/api/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the /api/index.php script
RewriteRule .* api/index.php [L]
# -- SEF URLs for the public frontend application
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.
</IfModule>
## These directives are only enabled if the Apache mod_rewrite module is disabled
<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When Apache mod_rewrite is not available, we instruct a temporary redirect
# of the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 302 ^/$ /index.php/
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip
# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>Nabend
Lass uns zusammen einfach mal eine hoch spekulative, natürlich nur rein theoretische Situation durchspielen...
- Du gehst auf joomla.org.
- Du lädst Dir das aktuelle (passende) Joomla-Paket herunter.
- Du entpackst es auf Deinem Computer.
- Du hast die original htaccess die Du benötigst.
Magieeeee!
Gruß Jan
Aber wird wohl nichts nützen....
Also ich kann nur vermuten, aber für mich hört es sich so an, als wenn dieses Formular bereits von einem anderen Projekt "recycelt" wurde. Die Bezeichnung "Sendungskennzeichen" kommt mir zu spezifisch vor, als wenn es etwas mit einer Voreinstellung der Komponente zu tun hätte. Es klingt für mich eher danach, als wenn ein bestehendes Formular um nicht benötigte Felder bereinigt wurde, eventuell sogar nur ausgeblendet. Gerne in Kombination mit dem manuellen Löschen von Feldern in der Datenbank. Durch die Migration wurden diese kleinen "Leichen" dann wieder aktiv und sorgen jetzt für den Ärger.
Wie gesagt nur eine Vermutung, aber eventuell kannst Du uns zu der Geschichte des Formulars aufklären.
PS: Du fummelst mit dem Problem bereits seit mindestens 7 Tagen herum, dass Formular selbst wäre wahrscheinlich in unter zwei Stunden neu angelegt gewesen.
Moin flowmotion
Was Backups betrifft wäre ich vorsichtig. Spielst Du diese einfach nur zurück, werden nur jene Dateien / Verzeichnisse ersetzt, welche im Backup vorkommen. Zusätzlich hinterlegte Dateien / Verzeichnisse wie z.B. eine PHP-Shell bleiben einfach liegen. Daher der immer wieder zu lesende Hinweis das man entweder das Verzeichnis mit der Webseite vorher leert, oder hinterher scannt ob "alte" Dateien liegen geblieben sind.
Einfache HowTo's gibt es übrigens schon seit vielen Jahren.
Joomla! gehackt was tun - Joomla!-Security, mehr Sicherheit
FAQ/Support - Joomla!/WordPress wurde gehackt - was tun? - fc-hosting.de | Webhoster
Jeder Fall ist aber individuell und diese Anleitungen decken nur das allgemeine Vorgehen ab.
Gruß Jan
Moin
Mein Vorschlag ---> Leg Dir bitte mal ein neues Formular mit Visforms an, nur mit den ersten paar Felder aus dem alten (Namen, Vornamen usw.) und schau ob der Fehler dort auch auftritt. Wenn ja ist es ein Problem in Visforms oder im Kontext mit der Migration. Falls nein tastest Du Dich langsam weiter vor und fügst die nächsten Felder hinzu. Dann stoßen wir entweder auf die Fehlerquelle, oder Du hast am Ende ein neues, funktionierendes Formular.
Gruß Jan
Ja muss ich nichts zu sagen.. ich habe gesucht wie ein verrückter! Die Joomla-Konfig Zeit stand auf UTC... Danke!
Hat Niemand gesehen, wir vergessen es einfach und sprechen nie wieder darüber...
Nabend Markus
Was sagt die Systemzeit in der Joomla-Konfiguration unter dem Reiter "Server"?
Gruß Jan
Hey Jan - das "gewissenhafte Kontrollieren des Webspaces" schreibt sich ja immer so toll - aber mal im Ernst: wie will man (ich glaube Joomla hat aktuell 64000 Einzeldateien) händisch, gewissenhaft kontrollieren und abschätzen, ob diese zum System gehören?! Das geht mir nicht ein. Bzw. kann ich mir nicht vorstellen, wie das händisch von statten gehen soll.
Niemand erwartet das jeder tausende von Dateien und dessen Inhalt kennt, aber zumindest das Schema wie diese im System abgelegt werden und was wo keinesfalls hingehört. Zum Beispiel haben ausführbare PHP-Dateien oder Javascripte nichts im Image- und dessen Unterverzeichnissen zu suchen. CSS und HTML kannst Du aussortieren, weil nicht für Angriffe nutzbar. Lässt Du den Core frisch installieren hast Du ein aktuelles Dateidatum und kannst z.B. per FileZilla alle älteren Dateien auflisten lassen usw. Und natürlich das Vergleichen von Dateien / Verzeichnissen (Diff) das jsc_01 genannten hat.
Bringt aber alles nichts, wenn die Aufgaben nicht alle abgearbeitet wurden. Ist der Rechner des Kunden mit einem Trojaner infiziert, bringt es nichts die Webseite zu bereinigen, ist das FTP-Passwort im Umlauf muss ich den Kunden daran hindern das alte Passwort aus Bequemlichkeit wieder zu setzen usw.
Jedenfalls könnte man hier einen Roman schreiben.
Gruß Jan
Sendet Dein Browser die "Do not Track"-Kennung?
Moin
Ist eine Erweiterung / Plugin mit dem Namen "iFAQ" installiert?
Gruß Jan
Da solltest Du nichts neu installieren müssen, soweit ich mich erinnern kann speichert Matomo die Grundeinstellungen in der /config/config.ini.php
Schau einfach mal ob dort ein Pfad für Matomo hinterlegt ist.
Gruß Jan
Moin
Ja, Du kannst Matomo auch in einem Unterverzeichnis installieren und damit das vorhandene Zertifikat nutzen.
Gruß Jan
Bei den letzten "Meldungen" war es - (hatte da auch lange mit all inkl geredet) wohl ein "fehlgeschlagener" Versuch in ein WP Backen rein zu kommen. Die Dateien, die dafür verwendet wurden, lagen aber immer noch rum und haben dann den scanner ausgelöst.
Moin
Wenn fremde Dateien auf Deinem Webspace liegen, dann war das kein Versuch die Seite zu kompromittieren, sondern bereits erfolgreich. In solchen Fällen kommst Du nicht umhin den gesamten Webspace gewissenhaft nach Schadcode zu kontrollieren, alle Zugangsdaten zu ändern und die Schwachstelle zu finden und zu schließen. Alles andere wird zu einer Endlosschleife. Außerdem würde ich alle Computer / Geräte kontrollieren bei denen Zugangsdaten hinterlegt waren und auch dort nach Viren / Trojanern suchen, sowie die Passwörter neu setzen.
Kopiert man sich Sicherungen auf den eigenen Rechner springen die Virenscanner gerne auf PHP-Shells oder die Payload einer Attacke an. In Javascripten auf dem Webspace wird hingegen gerne mit Base64 codierten Bestandteilen gearbeitet die sich auch mitten in einer Datei befinden können. Wie gesagt kommst Du nicht um eine genaue Kontrolle des Webspace herum. Betrifft übrigens potenziell alle Webseite die mit ihn diesem Paket lagen und zu denen man per PHP oder FTP "überspringen" konnte.
Gruß Jan
Moin
Gibt es noch Sicherungen vor Deinem letzten Restore? Hast Du die Möglichkeit in einem vollständig getrennten Bereich (z.B. Subdomain mit eigener Datenbank) an einer Kopie zu arbeiten? Gut möglich das man das noch hinbiegen kann, aber erst einmal muss das sauber getrennt werden.
Gruß Jan
Von jemandem, der eigenständig eine Webseite erstellt und diese in´s Netz stellt, würde ich das schon erwarten, und so jemand ist nicht einfach "Benutzer".
Moin Jürgen
Ja, dass sollte so sein, aber wir kennen auch beide die Realität. Bestes Beispiel ist wie hier der genannte Verein. Ein Mitglied soll sich um die Seite kümmern und hat als Administrator "nur" Zugriff auf das Backend. Zugangsdaten zum Hoster und Vertrag liegen irgendwo in den Unterlagen des Vereins. Läuft das Backend nicht mehr, muss ich keine Fragen stellen die sich für diese Person nur über die Systeminformationen im Backend schnell ermitteln lassen.
Aber bevor wir hier den Thread zumüllen, können wir bei Bedarf einen eigenen "Sinn und Unsinn von Fragebögen" eröffnen.
PS: Schön übrigens, dass die Seite wieder läuft.
Gruß Jan
Mir ist das nebenbei wurst, weil ja von Spinnern in Joomla 4
Muss ich Dir schon wieder das garstige kleine Schandmundwerk mit Kernseife auswaschen? 
Hättest Du hier nicht explizit diese Hilfe-Texte erwähnt, ich wäre überhaupt nicht darüber gestolpert das sie fehlen könnten. Wenn Sie noch da, aber nur ausgeblendet sind, könntest Du sie mit dem Firefox-Plugin "Stylus" wieder sichtbar machen. Nutze ich manchmal für sehr, sehr, sehr, sehr große Formulare mit RSForms in der Verwaltungsoberfläche.
Gruß Jan
