KENNTNISSE · WEB HOSTING
Meine Website wurde gehackt, was tun?
Zuletzt aktualisiert 2020-04-02
Hier sind einige Tipps, um Ihre Website sicher zu halten. Dies wurde in erster Linie als Reaktion auf eine gehackte Website geschrieben:
1. Als erstes müssen Sie alle Anbieter- / Entwickler-Websites auf ALLE in Ihrem Konto verwendeten Webskripte / Anwendungen auf Updates einschließlich aller Mods überprüfen, die Sie möglicherweise in einer Webanwendung verwenden. Wenn Sie eine Open-Source-Webanwendung verwenden, ist dies möglicherweise der Hauptverdächtige. Sie müssen jedoch alle überprüfen und sie auf dem neuesten Stand halten. Überprüfen Sie die Datenbank auf www.secunia.com für alle bekannten Exploits in der Öffentlichkeit veröffentlicht.
2. Sobald Sie überprüft haben, dass 100% der installierten Skripte die neueste stabile Version sind, müssen Sie alle Dateien Ihres Kontos durchgehen und sicherstellen, dass keine von Hackern hochgeladen wurden, bevor Sie von einer alten Installation einer Anwendung auditiert oder von Ihnen hinterlassen wurden. Es kann verdächtige Dateien in Ordnern geben, die Sie sich nie vorstellen würden, und in Ordnern mehrere Ebenen nach unten. Sie können den Dateimanager ftp oder cPanel verwenden, um alle Dateien unter public html durchzugehen und sie mit Ihrer lokalen Kopie zu vergleichen. [Sie sollten immer eine lokale Kopie für diesen Vergleich sowie Backup beibehalten.]
3. Stellen Sie sicher, dass alle Passwörter eine Mischung aus alphanumerisch und nicht ein Wörterbuchwort sind. Nur weil Sie an ein schwieriges Wort aus dem Wörterbuch gedacht haben, sind Sie nicht sicher. Bitte verwenden Sie auch Groß- und Kleinbuchstaben und mindestens 8 Zeichen.
4. Der Zugriff auf die MySQL-Datenbank auf alle Webanwendungen sollte über separate db-Benutzer erfolgen. Verwenden Sie niemals Ihren Hauptkontobenutzer / -pass dafür. Ihr Hauptbenutzer / Pass sollte niemals in einer Datei in Ihrem Konto gespeichert werden.
5. Aktivieren Sie in Ihrem Bedienfeld die Archivierungsoption Ihrer Weblogs im Raw Log Manager. Dies gibt Ihnen die Möglichkeit zu überprüfen, wie der Hacker eines der Skripte ausgenutzt hat. Ansonsten werden alle Rohprotokolle nach der Generierung von Statistiken gelöscht. Wenn Sie bereits gehackt wurden, ist es jetzt zu spät, aber Sie können die Protokolle für zukünftige Angriffe archivieren.
6. Wenn Sie eine Webanwendung mit einem Mod angepasst haben, stellen Sie sicher, dass es auch die neueste stabile Version ist. Viele beliebte Web-Anwendungen können stabil sein, aber einer der Addon-Mods kann ausnutzbar sein und möglicherweise nicht mehr gepflegt werden.
7. Wenn Sie selbst Code geschrieben haben, stellen Sie sicher, dass alle Eingabevariablen bereinigt sind (vor der Verwendung auf gültige Daten überprüft). Andernfalls kann eine einzelne Zeile schlechten Codes Zugriff auf Ihr gesamtes Konto gewähren. Der übliche Fehler besteht darin, eine Datei basierend auf Benutzereingaben einzuschließen. Stellen Sie erneut sicher, dass alle Eingaben in ein Skript auf gültige Daten überprüft werden. Alle Exploits basieren auf Eingabedaten. Wenn Ihre Website keine Eingaben entgegennimmt, sind Sie 100% sicher vor Web-Exploits, d.h. wenn Sie 100% statische HTML-Site ohne Skript in Ihrem Konto ausführen.
8. Für PHP hat jede Anwendung, die register globals verwendet, um aktiv zu sein, mehr Chancen, ausnutzbar zu sein. Vermeiden Sie solche Anwendungen.
9. Wenn Sie ein Mail-Skript haben, stellen Sie sicher, dass es vor Header-Injektion sicher ist. Stellen Sie im Wesentlichen sicher, dass E-Mail-Adresse, Betreff und andere Teile der Daten, die vom Benutzer übermittelt werden, keine Zeilenumbrüche enthalten. Einige Codierungshilfe wird in unseren Foren zur Verfügung gestellt.
Die Verwendung von Open-Source-freien Web-Anwendungen ist großartig, aber Sie müssen sie durch regelmäßige Updates pflegen oder Sie können alle Ihre Daten und Ihre Website verlieren, wenn ein neuer Exploit darüber bekannt ist. Und als Hosting-Account-Inhaber liegt es in Ihrer Verantwortung, dass Sie nur stabile Anwendungen in Ihrem Account installiert haben.
11. Wenn Ihre Website seit Jahren gut läuft, bedeutet das nicht, dass es keine Sicherheitslücken gab. Es bedeutet eigentlich, dass Exploit unbekannt war oder Sie Glück hatten, dass niemand es vorher ausgenutzt hat.
12. Für zusätzliche Sicherheit ändern Sie die Berechtigungen Ihrer Konfigurationsdateien (mit Datenbankanmeldeinformationen usw.) auf 660. Sie können dies über ftp oder file manager tun. Diese Funktion kann auf freigegebenen Hosting-Servern funktionieren oder wenn Ihr VPS / dedizierter Server über phpsuexec über cPanel verfügt.
Für zusätzliche Sicherheit, wenn Sie den Zugriff auf bestimmte administrative Bereiche Ihrer Website blockieren können, tun Sie dies, indem Sie nur autorisierte IP-Adressen zugreifen und den Zugriff für alle anderen blockieren, oder ein Passwort schützen.
14. Wenn es eine Datei-Upload-Funktion in Ihrem Konto gibt, stellen Sie sicher, dass nur autorisierte Mitglieder es verwenden können.
Auch die hochgeladene Datei sollte nicht direkt über die Web-URL zugänglich sein (d.h. außerhalb von public html gespeichert), es sei denn,
a) es wird nur von einem Website-Administrator (verantwortliche Person) hochgeladen
b geprüft und validiert, um nicht verwertbar zu sein
15. Wenn es eine URL-Weiterleitung oder Webmail-Funktion für Ihre Website-Mitgliedschaft gibt, stellen Sie sicher, dass sie nicht an alle ohne ordnungsgemäße Autorisierung vergeben wird oder für Spamming verwendet werden kann.
Wenn Sie nur etwas testen / ausprobieren, was nur Sie brauchen und Sie wissen, dass Sie nicht aktiv auf dem neuesten Stand bleiben, sperren Sie es einfach hinter einem Passwort sofort.
17. Da Shared/sdx/Reseller-Server mit suPHP ausgestattet sind, benötigen Sie keine Dateien oder Ordner mit World Write-Berechtigungen. Die normalen Ordnerberechtigungen sollten 755 nicht überschreiten. PHP/HTML-Dateien können 644 (oder niedriger durch ssh) sein. CGI/Perl-Skripte sollten 755 sein.
18. Jeder, der Web-Anwendungscode schreibt, sollte mit Sicherheit vertraut sein. Ich fand dieses Buch in meiner lokalen Bibliothek, insbesondere auf PHP: http://www.oreilly.com/catalog/phpsec/ Ich empfehle es allen. Es deckt alle Aspekte von Sicherheitslücken ab, die heute in Webanwendungen gefunden werden. Diese Seite fand ich auch aus dem Buch: http://phpsec.org
1. Als erstes müssen Sie alle Anbieter- / Entwickler-Websites auf ALLE in Ihrem Konto verwendeten Webskripte / Anwendungen auf Updates einschließlich aller Mods überprüfen, die Sie möglicherweise in einer Webanwendung verwenden. Wenn Sie eine Open-Source-Webanwendung verwenden, ist dies möglicherweise der Hauptverdächtige. Sie müssen jedoch alle überprüfen und sie auf dem neuesten Stand halten. Überprüfen Sie die Datenbank auf www.secunia.com für alle bekannten Exploits in der Öffentlichkeit veröffentlicht.
2. Sobald Sie überprüft haben, dass 100% der installierten Skripte die neueste stabile Version sind, müssen Sie alle Dateien Ihres Kontos durchgehen und sicherstellen, dass keine von Hackern hochgeladen wurden, bevor Sie von einer alten Installation einer Anwendung auditiert oder von Ihnen hinterlassen wurden. Es kann verdächtige Dateien in Ordnern geben, die Sie sich nie vorstellen würden, und in Ordnern mehrere Ebenen nach unten. Sie können den Dateimanager ftp oder cPanel verwenden, um alle Dateien unter public html durchzugehen und sie mit Ihrer lokalen Kopie zu vergleichen. [Sie sollten immer eine lokale Kopie für diesen Vergleich sowie Backup beibehalten.]
3. Stellen Sie sicher, dass alle Passwörter eine Mischung aus alphanumerisch und nicht ein Wörterbuchwort sind. Nur weil Sie an ein schwieriges Wort aus dem Wörterbuch gedacht haben, sind Sie nicht sicher. Bitte verwenden Sie auch Groß- und Kleinbuchstaben und mindestens 8 Zeichen.
4. Der Zugriff auf die MySQL-Datenbank auf alle Webanwendungen sollte über separate db-Benutzer erfolgen. Verwenden Sie niemals Ihren Hauptkontobenutzer / -pass dafür. Ihr Hauptbenutzer / Pass sollte niemals in einer Datei in Ihrem Konto gespeichert werden.
5. Aktivieren Sie in Ihrem Bedienfeld die Archivierungsoption Ihrer Weblogs im Raw Log Manager. Dies gibt Ihnen die Möglichkeit zu überprüfen, wie der Hacker eines der Skripte ausgenutzt hat. Ansonsten werden alle Rohprotokolle nach der Generierung von Statistiken gelöscht. Wenn Sie bereits gehackt wurden, ist es jetzt zu spät, aber Sie können die Protokolle für zukünftige Angriffe archivieren.
6. Wenn Sie eine Webanwendung mit einem Mod angepasst haben, stellen Sie sicher, dass es auch die neueste stabile Version ist. Viele beliebte Web-Anwendungen können stabil sein, aber einer der Addon-Mods kann ausnutzbar sein und möglicherweise nicht mehr gepflegt werden.
7. Wenn Sie selbst Code geschrieben haben, stellen Sie sicher, dass alle Eingabevariablen bereinigt sind (vor der Verwendung auf gültige Daten überprüft). Andernfalls kann eine einzelne Zeile schlechten Codes Zugriff auf Ihr gesamtes Konto gewähren. Der übliche Fehler besteht darin, eine Datei basierend auf Benutzereingaben einzuschließen. Stellen Sie erneut sicher, dass alle Eingaben in ein Skript auf gültige Daten überprüft werden. Alle Exploits basieren auf Eingabedaten. Wenn Ihre Website keine Eingaben entgegennimmt, sind Sie 100% sicher vor Web-Exploits, d.h. wenn Sie 100% statische HTML-Site ohne Skript in Ihrem Konto ausführen.
8. Für PHP hat jede Anwendung, die register globals verwendet, um aktiv zu sein, mehr Chancen, ausnutzbar zu sein. Vermeiden Sie solche Anwendungen.
9. Wenn Sie ein Mail-Skript haben, stellen Sie sicher, dass es vor Header-Injektion sicher ist. Stellen Sie im Wesentlichen sicher, dass E-Mail-Adresse, Betreff und andere Teile der Daten, die vom Benutzer übermittelt werden, keine Zeilenumbrüche enthalten. Einige Codierungshilfe wird in unseren Foren zur Verfügung gestellt.
Die Verwendung von Open-Source-freien Web-Anwendungen ist großartig, aber Sie müssen sie durch regelmäßige Updates pflegen oder Sie können alle Ihre Daten und Ihre Website verlieren, wenn ein neuer Exploit darüber bekannt ist. Und als Hosting-Account-Inhaber liegt es in Ihrer Verantwortung, dass Sie nur stabile Anwendungen in Ihrem Account installiert haben.
11. Wenn Ihre Website seit Jahren gut läuft, bedeutet das nicht, dass es keine Sicherheitslücken gab. Es bedeutet eigentlich, dass Exploit unbekannt war oder Sie Glück hatten, dass niemand es vorher ausgenutzt hat.
12. Für zusätzliche Sicherheit ändern Sie die Berechtigungen Ihrer Konfigurationsdateien (mit Datenbankanmeldeinformationen usw.) auf 660. Sie können dies über ftp oder file manager tun. Diese Funktion kann auf freigegebenen Hosting-Servern funktionieren oder wenn Ihr VPS / dedizierter Server über phpsuexec über cPanel verfügt.
Für zusätzliche Sicherheit, wenn Sie den Zugriff auf bestimmte administrative Bereiche Ihrer Website blockieren können, tun Sie dies, indem Sie nur autorisierte IP-Adressen zugreifen und den Zugriff für alle anderen blockieren, oder ein Passwort schützen.
14. Wenn es eine Datei-Upload-Funktion in Ihrem Konto gibt, stellen Sie sicher, dass nur autorisierte Mitglieder es verwenden können.
Auch die hochgeladene Datei sollte nicht direkt über die Web-URL zugänglich sein (d.h. außerhalb von public html gespeichert), es sei denn,
a) es wird nur von einem Website-Administrator (verantwortliche Person) hochgeladen
b geprüft und validiert, um nicht verwertbar zu sein
15. Wenn es eine URL-Weiterleitung oder Webmail-Funktion für Ihre Website-Mitgliedschaft gibt, stellen Sie sicher, dass sie nicht an alle ohne ordnungsgemäße Autorisierung vergeben wird oder für Spamming verwendet werden kann.
Wenn Sie nur etwas testen / ausprobieren, was nur Sie brauchen und Sie wissen, dass Sie nicht aktiv auf dem neuesten Stand bleiben, sperren Sie es einfach hinter einem Passwort sofort.
17. Da Shared/sdx/Reseller-Server mit suPHP ausgestattet sind, benötigen Sie keine Dateien oder Ordner mit World Write-Berechtigungen. Die normalen Ordnerberechtigungen sollten 755 nicht überschreiten. PHP/HTML-Dateien können 644 (oder niedriger durch ssh) sein. CGI/Perl-Skripte sollten 755 sein.
18. Jeder, der Web-Anwendungscode schreibt, sollte mit Sicherheit vertraut sein. Ich fand dieses Buch in meiner lokalen Bibliothek, insbesondere auf PHP: http://www.oreilly.com/catalog/phpsec/ Ich empfehle es allen. Es deckt alle Aspekte von Sicherheitslücken ab, die heute in Webanwendungen gefunden werden. Diese Seite fand ich auch aus dem Buch: http://phpsec.org
Sagen Sie uns, was aufbleiben muss.
Ein kurzes Gespräch mit einem Ingenieur. Kein quote-bot, keine callback-warteschlange.