Sicherheits-Checkliste / Webseite wurde gehackt oder verändert

From Joomla! Documentation

< Security Checklist
This page is a translated version of the page Security Checklist/You have been hacked or defaced and the translation is 100% complete.
Other languages:
Deutsch • ‎English • ‎français
Security Checklist Joomla CMS
Articles in this series

Die Webseite wurde gehackt oder verändert?

Bevor ein Beitrag im Joomla! Sicherheitsforum gepostet wird, sollte diese Zusammenfassung der Checkliste gelesen und dann als Vorlage für den Beitrag verwendet werden..

Liste der Maßnahmen

  • Das Forum Post Assistant and Security Tool (FPA) starten. Die einfachen Anweisungen sind hier verfügbar. Ausführlichere Anweisungen sind im Download-Paket enthalten. Dieses Paket muss entpackt und die Datei fpa-de.php in das Joomla-Stammverzeichnis des Servers hochgeladen werden. Der FPA ist auch in einem tar.gz-Paket erhältlich, falls ein Paket im Unix-Stil gewünscht oder benötigt wird. Die Datei fpa-de.php aus dem Paket muss in das Joomla-Stammverzeichnis des Servers hochgeladen werden.
  • Alle Rechner mit FTP-, Joomla-Super-Admin- und Joomla-Admin-Zugang nach Malware, Viren, Trojanern, Spyware usw. durchsuchen (siehe Lokale Sicherheit weiter unten)
  • Sicherstellen, dass die neueste Version von Joomla für die auf der Website verwendete Joomla-Serie verwendet wird. (siehe unten: Inkompatible Versionen)
  • Den Hosting-Provider benachrichtigen und mit ihm zusammenarbeiten, um die Webseite zu bereinigen und sicherzustellen, dass es keine Hintertüren zu Ihrer Website gibt.
  • Die Liste der anfälligen Erweiterungen überprüfen, um festzustellen, ob anfällige Erweiterungen installiert sind. Diese sollten nicht länger verwendet werden. Ein Anhaltspunkt für angegriffene Erweiterungen ist die Protokolldatei. Hier ist ein Beispiel dafür, wonach gesucht werden sollte:
//administrator/components/com_extension/admin.extension.php?mosConfig.absolute.path=http:

oder 

../../../../../../../../../../../../../../../../proc/self/environ
  • Die Sicherheits-Checkliste überprüfen, um sicherzustellen, dass alle Schritte durchlaufen wurden (bitte beachten, dass einige Schritte optional sind, aber trotzdem überprüft werden sollten).
  • Alle Passwörter ändern und wenn möglich auch die Benutzernamen für die Admin-Oberfläche des Hosting-Providers, mysql, FTP, Joomla! Super Admin und Joomla! Admin Passwort.Diese sollten häufig geändert werden. Passwörter sollten aus mindestens 12 gemischten alphanumerischen Zeichen bestehen und keine gemeinsamen Wortphrasen enthalten.
  • Der Standard-Admin-Benutzer sollte nicht verwendet, sondern deaktiviert werden. Wenn das Admin-Passwort zugesetzt werden muss, sollten diese Anweisungen befolgt werden.
  • Alle Templates und Dateien löschen und durch saubere Kopien ersetzen
  • Alle .pdf-, Bild- und Fotodateien auf Exploits überprüfen und/oder ersetzen. Alle verdächtigen Dateien löschen.
  • Server-Protokolle auf IPs überprüfen, die verdächtige Dateien aufrufen oder versuchen, POST-Befehle an Dateien ohne Formulare zu senden
  • Korrekte Berechtigungen für Dateien und Verzeichnisse verwenden. Sie sollten niemals 777[1] sein. Ideal ist 644 für Dateien und 755 für Ordner.
  • anonymes FTP deaktivieren

Chmod und Cron

WENN Zugriffsrechte für SSH (secure shell) über putty gesetzt sind, können die Berechtigungen für Dateien und Verzeichnisse mit chmod geändert werden. Wenn kein Shell-Zugriff vorhanden ist, können die Befehle über Cron ausgeführt werde, indem ein temporärer Cron-Job eingerichtet wird. Der Befehl kann kopiert und in einen Cron-Job eingefügt werden. Der Job sollte etwa 2 Minuten nach dem Speichern des Jobs ausgeführt werden. Bei Verwendung des Befehls per putty oder in einem Cron-Job wird für optimale Ergebnisse die Verwendung des vollständigen physischen Pfads zu public_html empfohlen.

Für Dateien wird verwendet: 

find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -exec chmod 644 {} \;

und für Order wird verwendet: 

find /home/xxxxxx/domains/xxxxxxx.com/public_html -type d -exec chmod 755 {} \;

Überwachung von Veränderungen der Dateien

Um das System auf aktuelle Dateiänderungen zu prüfen, können diese Befehle von putty (SSH - secure shell) oder über einen Cron-Job verwendet werden. Wenn der Befehl über einen Cron-Job ausgeführt wird, kann er so eingestellt werden, dass er mehrmals täglich auf geänderte Dateien prüft. Die Ergebnisse werden an den Inhaber des Domain-Kontos gesendet und zeigen den Zeit-/Datumsstempel für alle geänderten Dateien an. Bei Verwendung des Befehls per putty oder einem cron-Job wird für optimale Ergebnisse die Verwendung des vollständigen physischen Pfads zu public_html empfohlen. 

find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -ctime -1 -exec ls -ls {} \;

Es sollte beachtet werden, dass sich die Dateien der Webseiten in einem Verzeichnis namens public_html, httpdocs, www oder o. ä. befinden können, und dass der physische Pfad sich von den Beispielen unterscheiden kann. Er sollte daher entsprechend angepasst werden.

777-Dateiberechtigungen

Wenn der verwendete Server 777-Berechtigungen benötigt, damit Joomla korrekt funktioniert, dann sollte darauf bestanden werden, dass die Seite auf einen anderen Server mit php als cgi und suphp und aktueller serverseitiger Software (apache, php usw.) auf Ihrem bestehenden Host umgezogen wird. Falls nötig sollte ein anderer Hosting-Provider gesucht werden.

Um Verzeichnisse zu schützen, für deren Ausführung 777-Berechtigungen erforderlich sind oder wenn diese Berechtigungen als Standard im Bilder/Medien-Ordner festgelegt sind, kann dieser Code in einer .htaccess-Datei innerhalb des Ordners hilfreich sein: 

# Sicherung des Verzeichnisses durch Deaktivierung der Skript-Ausführung
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI

especially in your images folder

  • Es muss sichergestellt werden, dass sich dies in einer htaccess-Datei in einem Verzeichnis befindet, das keine Skripte ausführt oder die Erweiterungen wie erforderlich entfernt werden

Es ist wichtig zu wissen, ob der Hosting-Provider den Server, auf dem die Webseite liegt, absichtlich gesichert hat und dass er oder der Seiten-Inhaber regelmäßige (wöchentliche) Sicherheitsupdates durchführen, um den Server auf dem neuesten Stand zu halten. Es sollte auch überprüft werden, ob eine Jail-Shell vorhanden ist. Als Faustregel gilt: Je preiswerter das Hosting ist, desto weniger kann vom Provider erwartet werden.

Ein sicherer Weg aus der Katastrophe

  • Sicherung der Datei configuration.php und der Bilder und persönlichen Dateien nacheinander (nicht den gesamten Ordner, da er unerwünschte Dateien enthalten könnte).
  • Löschung des gesamten Ordners, in dem Joomla! installiert ist
  • Upload eines neuen sauberen Pakets der neuesten Version von Joomla Joomla 2.5.x oder Joomla 3.x (empfohlen), abzüglich des Installationsordners[2]
  • Erneuter Upload der configuration.php & der Bilder
  • Upload/Neuinstallation der neuesten Versionen der verwendeten Erweiterungen und Templates (noch besser ist die Verwendung von originalen sauberen Kopien, um sicherzustellen, dass der Hacker/Defacer keine Shell-Skriptdateien auf der Webseite hinterlassen hat)

Zu diesem Zweck wird die Webseite für etwa 15 Minuten vom Netz genommen. Das Aufspüren von gehacktem oder verändertem html kann Stunden oder sogar länger dauern.

Lokale Sicherheit

  • FTP-Zugangsdaten nicht im FTP-Programm speichern
    • Ein Passwort-Manager verwenden, wie etwa das kostenlose keepass
  • Überprüfung von allen Rechnern mit FTP-, Joomla-Super-Admin- und Joomla-Admin-Zugang auf Malware, Viren, Trojaner, Spyware usw.

Weitere Überlegungen

  • Den Standard-Tabellenpräfix jos_ nicht verwenden und wenn möglich Ein-Klick-Installationen vermeiden
  • Wenn möglich, sFTP statt FTP verwenden
  • Anonymes FTP unter keinen Umständen aktivieren oder verwenden
  • Einen Server verwenden, der mod_security korrekt installiert hat
  • Überprüfung auf hinzugefügte Sub-Domains und/oder Verzeichnisse
  • Überprüfung auf Cron-Jobs, die nicht vom Administrator eingerichtet wurden
  • Download und Überprüfung der primären Zugriffs- und Fehlerprotokolle [3]
  • Ablehnung aller IPs, die von der Webseite blockiert werden, aber zu einer Proxy-Seite gehören könnten
Wenn die Webseite in der Vergangenheit bereits gehackt und keine vollständige Bereinigung der Webseite durchgeführt wurde, um vorhandene (auch versteckte) Hacks zu entfernen, können diese eine Hintertür für eine erneute Infektion hinterlassen.

Bösartiger Code oder seltsame Links auf der Webseite

Es sollte überprüft werden, ob die originale Template-Datei unerwünschten Code/bösartiges Javascript enthält oder ob ein kostenpflichtiges Template von einer nicht vertrauenswürdigen Quelle, z. B. von File-Sharing-Sites, heruntergeladen wurde

Gumblar verwendet keine bestimmte Skript-Sicherheitslücke. Dieses Skript wird in jede Seite auf einer Webseite injiziert. Es ist vorstellbar, wenn auch nicht bestätigt, das es bei Bearbeitung und Speicherung der infizierten Seite auch in die Datenbank eingeschleust wird. Das Skript ändert sich bei jedem Zugriff. Es wurde in phpBB-, SMF- und vBulletin-Foren, in WordPress 2.7.1-Blogs und auf proprietären PHP-Seites gefunden. Das Skript beginnt mit (function(, hat keinen Namen und ist verschlüsselt. Eine verbreitete Gumblar-Version beschädigt Webseiten aufgrund eines Fehlers im Skript.

iFrames

Bei den jüngsten Iframe-Exploits wurde der bösartige Code nur in Dateien mit den gängigsten Dateinamen (z. B. index.html, index.php usw.) eingeschleust. Siehe auch Sticky im zugehörigen Forum

Mitwirkende & Edition

mandville PhilD fw116 JeffChannell dynamicnet

Referenzen

  1. ↑ Berechtigungen sollten niemals auf 777 gesetzt sein
  2. ↑ Inkompatible Versionen
  3. ↑ primäre Zugriffs- und Fehlerprotokolle

Wenn der Hosting-Provider PHP als Apache-Modul ausführt, wird es als Benutzer/Gruppe des Webservers ausgeführt, was normalerweise "nobody", "httpd" oder "apache" ist. In diesem Modus benötigen Dateien oder Verzeichnisse, in die php-Skripte schreiben sollen, 777-Rechte (Lesen/Schreiben/Ausführen auf Benutzer-/Gruppen-/Public-Ebene), wenn der Besitzer der Dateien und Verzeichnisse nicht Chown (Besitzer wechseln) des Benutzers ist. Ein solches Szenario ist vom Sicherheitsstandpunkt aus absolut inakzeptabel, da '777' nicht nur dem Webserver, sondern auch jedem anderen erlaubt, die Datei zu lesen oder zu überschreiben. Wenn ein Provider nicht in der Lage ist, dies zu ändern, sollte man unbedingt einen Wechsel des Hosting-Anbieters in Betracht ziehen!

Logs Die Raw-Access-Protokolle sollten im Kontrollpanel überprüft werden können.

Raw-Access-Protokolle ermöglichen es, ohne die Verwendung von Grafiken, Diagrammen oder anderen Darstellungen zu sehen, wer auf eine Webseite zugegriffen hat. In cPanel kann zum Beispiel das Menü Raw Access Logs verwendet werden, um eine gezippte Version des Server-Zugriffsprotokolls für die Webseite herunterzuladen. Dies kann sehr nützlich sein, wenn schnell überprüft werden soll, wer auf die Webseite zugreift. Viele vergessen, dass dies durch den Benutzer des Accounts aktiviert werden muss und nicht automatisch bei der Erstellung eines Hosting-Accounts im cPanel aktiviert wird!

Inkompatible Versionen

Dieses Dokument gilt für alle Versionen von Joomla. Für die Reparatur einer Webseite sollte stets die neueste Version von Joomla verwendet werden, die mit der Version der bestehenden Joomla-Webseite kompatibel ist. Einige Versions-Upgrades erfordern eine Migration der Webseite und machen die Joomla-Website unbrauchbar, wenn sie verwendet werden, um eine frühere Version von Joomla bei der Reparatur einer gehackten Webseite zu ersetzen. Zum Beispiel: Eine auf 1.5.xx basierende Website kann nicht durch die Joomla-Version 2.5.xx ersetzt werden. Dies würde die Website unbrauchbar machen und könnte außerdem zu einem Datenverlust führen.

Retrieved from "https://docs.joomla.org/index.php?title=Security_Checklist/You_have_been_hacked_or_defaced/de&oldid=675435"