Aus laufendem Betrieb heraus: Weiße BIldschirme in Front- und Backend

Hallo zusammen,

wir haben ein akutes und sehr drängendes Problem mit unserem Shop, und hoffen, dass jemand mal etwas ähnliches erlebt hat, und uns weiterhelfen kann.

Es geht um eine Oxid PE Installation in der Version 4.9.6. Am Samstag Abend fiel uns auf, dass der Shop auf einmal nicht mehr erreichbar war. Backend und Frontend zeigten lediglich weiße Seiten.

Der Shop war ggn. Vormittag / Mittag des gleichen Tages definitiv noch erreichbar. Es wurden keine Änderungen oder Aktionen über das Backend, via Dateizugriff oder an der Datenbank selbst vorgenommen. Die Systemgesundheit der Installation war bei 100% - alles in Ordnung.

Irgendetwas ist im laufenden Betrieb passiert, so dass der Shop buchstäblich außer Gefecht gesetzt wurde …

[B]Die Diagnose:[/B]

  • EXCEPTION_LOG.txt überprüft: Keine Einträge / komplett leer.

  • error.log überprüft: Die Inhalte sind überschaubar (und vermutlich für das aktuelle Problem nicht relevant, da sie schon vor dem Zusammenbruch sporadisch ausgegeben wurden):
    [I][Sat Jan 09 07:09:16 2016] [error] [client 66.249.66.63] File does not exist: [SERVERPFAD]/
    [Sat Jan 09 12:40:29 2016] [error] [client 217.227.83.149] File does not exist: [SERVERPFAD]//[{$oViewConf->getCurrentHomeDir()}]out, referer: [/I]
    Einträge wie die i.g. existieren häufiger. Neu, und ggf. interessanter ist:
    [I][Sat Jan 09 16:48:57 2016] [error] Hostname ServerName provided via SNI and hostname provided via HTTP are different[/I] (Dieser Eintrag existiert nur einmal.)

  • Debug Mode auf Level 4 gesetzt. Es erfolgt kein Ausgabe.
    [B]
    Dann folgende Maßnahmen: [/B]

  • Löschen des /tmp Ordner und der VIEWS (Ergänzung der config.inc.php um $this->blSkipViewUsage = true;). Ohne Erfolg.

  • Prüfung der Verzeichnisstruktur auf Schreibrechte und getätigte Änderungen. Keine Hinweise, alles unangetastet, wie vorher.

  • Testweises Einspielen des aktuellen DB-Dumps auf paralleler Datenbank mit Anpassung der config.inc.php. Anschließend Deaktivierung sämtlicher Module über PHPMyAdmin als Ausschlußverfahren:
    delete from oxconfig where oxvarname in (
    ‘aDisabledModules’,
    ‘aLegacyModules’,
    ‘aModuleFiles’,
    ‘aModulePaths’,
    ‘aModules’,
    ‘aModuleTemplates’
    );
    Ohne Erfolg.

  • Testen eines DB-Dumps vom 05.01. als parallele DB über die config.inc.php), um zu schauen, ob die DB generell gecrasht wurde. Ohne Erfolg.

  • Testen des DB-Dumps vom 05.01 plus zugehöriger Sicherung vom 05.01 (alle Files). Ohne Erfolg.

Das Fehlerbild bleibt stets gleich.

Weitere Recherchen in den Oxid-Foren ergaben einen Hinweis auf einen möglichen Hackerangriff (http://forum.oxid-esales.com/showthread.php?t=39055). Erste Anfragen beim Hoster ergaben, dass das pauschal nicht überprüfbar bzw. nachvollziehbar sein.

WIr sind komplett ratlos. Hat jemand schon mal einen ähnlichen Fall erlebt?

Danke für jeden Hinweis / Tipp.

VG

Als PE Benutzer würde ich definitiv mal beim Support anrufen.

Was den Error log betrifft:

  1. Steht da tatsächlich “/[{$oViewConf->getCurrentHomeDir()}]out” drin oder hast du die tatsächliche URL durch Platzhalter ersetzt?
    Wenns tatsächlich so steht, ist ein Template irgendwo unsauber. Meistens passiert sowas bei background-images. Da müsste man untersuchen, aber das dürfte keine Ursache für dein Problem sein.

  2. “Hostname ServerName provided via SNI and hostname provided via HTTP are different” das war vermutlich ein Bot und wenn es nur ein mal aufgetreten ist, dann würde ich das ignorieren.

Weiße Seiten sind meistens PHP Fehler. Ist der Shop nun komplett weg oder nur gelegentlich?
Versuch mal die offline.html aufzurufen. Klappts?

Lege eine neue Datei im Shop root an: info.php

<?php phpinfo (); ?>

Rufe sie auf und such auf der Seite nach “error”.
Welche Werte stehen bei display_errors, error_log, error_reporting, log_errors?

Danke für deine Antwort, und deinen Ansatz:

  • display_errors = Off
  • error_log = no value
  • error_reporting = no value
  • log_errors = Off

Der Provider, mit dem ich parallel hierzu im Gespräch bin, ist profihost. Dort habe ich jetzt einmal die php5.4.ini angepasst, und display_errors = on gesetzt. Mal sehen, welche Infos ausgespuckt werden, sobald die Einstellungen greifen.

[B]EDIT:
[/B]
Dank des o.g. Ansatzes kontte der Fehler lokalisiert und behoben werden. Es stellte sich heraus, dass ein Drittanbieter-Modul dafür verantwortlich war …

The encoded file […]/modules/exonn_sengines/views/admin/de/exonnsengines_lang.php requires a license file.
The license file […]//modules/exonn_sengines/license.txt has expired. in Unknown on line 0

Kaum zu glauben …

Danke für die Hilfe.