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.
10. Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is known about it. And as a hosting account owner, it is your responsibility that you have installed only stable applications in your account.
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.
13. For added security, if you can block access to certain administrative sections of your site, do that by giving access to only authorized IP addresses and blocking access for everyone else, Or password protect it.
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) checked and validated to be not exploitable
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.
16. If you're just testing / trying something, which only you need and you know you won't actively keep up to date, just lock it behind a password right away.
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.
10. Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is known about it. And as a hosting account owner, it is your responsibility that you have installed only stable applications in your account.
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.
13. For added security, if you can block access to certain administrative sections of your site, do that by giving access to only authorized IP addresses and blocking access for everyone else, Or password protect it.
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) checked and validated to be not exploitable
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.
16. If you're just testing / trying something, which only you need and you know you won't actively keep up to date, just lock it behind a password right away.
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.
A short conversation with an engineer. No quote-bot, no callback queue. We'll tell you honestly if we're not the right fit.