Skip to main content

Website gehackt – was nun? Interview mit einem Web Security-Experten

Am 23.12.2016 erhielt ich von meinem Hoster einen überraschenden Anruf: Eine meiner Websites wurde gehackt und es wurden massenweise Spam-Mails über meinen Server verschickt. So viele, dass die Mailfunktion deaktiviert werden musste. Und es kam noch schlimmer: Bei näherer Betrachtung stellte sich heraus, dass nicht eine, sondern gleich 12 meiner Websites von dem Hackerangriff betroffen waren. Aus Sicherheitsgründen musste der Hoster sämtliche betroffenen Domains sperren.

Bäm, da saß ich jetzt, am Tag vor Heilig Abend. Auch meine größte Weihnachtsseite war betroffen (an dem Wochenende erwartete ich über 100.000 Besucher auf der nun gesperrten Seite). Einige der Seiten waren nicht wichtig, um die habe ich mich schon jahrelang nicht mehr groß gekümmert. Andere Seiten dagegen gehören zum „Brot und Butter-Geschäft“.

Über mein Facebook-Netzwerk fand ich glücklicherweise fast unmittelbar einen Web Security-Profi, der sich die Seiten sofort ansah. Damian Schwyrz wurde mir wärmstens empfohlen – heute weiß ich, warum.

Über die Weihnachtsfeiertage bereinigte er alle meine Seiten von der Schadsoftware, schloss die Lücken und half mir so, größeren Schaden zu verhindern. Danke nochmal an dieser Stelle, Damian!

Der Schock saß so tief (und ich habe in fast jedem zweiten Seminar mindestens einen Teilnehmer, der zu dem Zeitpunkt ebenfalls gehackt ist), dass ich ihn zum Interview eingeladen habe.

Dieses Interview richtet sich vor allem an Website-Betreiber, die sich bisher nicht allzu intensiv mit Web Security beschäftigt haben. Wie werden Websites gehackt? Welche Lücken müssen unbedingt geschlossen werden? Helfen Security-Plugins? Und woran erkennt man überhaupt, dass man gehackt wurde? Die Antworten auf diese und weitere Fragen hat Damian in laienverständliche Sprache gepackt. Viel Spaß!

Das Interview mit dem Security-Experten

1. Hi Damian, danke dass du dir die Zeit für das Interview nimmst. Kannst du kurz zusammenfassen, was in meinem Fall die Ursache für den Hack war, was die Hacker gemacht haben und was die Auswirkungen waren?  

Was die exakte Ursache für den Erfolg des Angriffs war, lässt sich schwer sagen, weil die ersten Hintertüren in Form von Webshells bereits vor mehr als 1 Jahr auf dem Server platziert, aber erst jetzt aktiv verwendet wurden. Das Fehlen von Logs für den Zeitraum, erlaubt es mir hier eigentlich nur zu spekulieren:

Du hast auf dem betroffenen Server zu Spitzenzeiten etwa ein Dutzend verschiedener Websites gehostet – alle basierend auf WordPress und Plugins, von denen man weiß, dass sie in der Vergangenheit kritische Sicherheitslücken hatten. Gleiches gilt für viele der eingesetzten Themes – besonders aufgefallen ist hier das Tool “TimThumb” in sehr alter Version. Eine der Seiten verwendete sogar noch WordPress 4.2.x. Der Zustand aller Websites, die du mir übergeben hast, deutete also darauf hin, dass du es nicht so exakt mit zeitnahen Aktualisierungen genommen hast. Entsprechend hast du es Angreifern bzw. automatisierten Tools sehr einfach gemacht, irgendeine deiner Seiten zu hacken.

In vielen Ordnern auf deinem Server gab es eigentlich entweder eine klassische Webshell (c99, rlx, …) oder unauffällige Manipulationen von WordPress Core-/Plugin- oder Theme-Dateien, über die man beliebigen PHP Code ausführen konnte. Als das erledigt war, wurden einige dieser Hintertüren dazu verwendet, von deinem Server aus eine riesige Menge Spam in die Welt zu verschicken.

Das hat dein Hostinganbieter mit der Zeit bemerkt und natürlich den Server gesperrt, so dass er von außen nicht mehr erreichbar war. Das ist natürlich kurz vor der Weihnachtszeit alles andere als optimal.

Gleichzeitig ist die IP-Adresse, von der die E-Mails verschickt wurden, auf diversen Blacklists gelandet.

2. Woran merkt man denn allgemein, dass man gehackt wurde?

Du hast es gemerkt, weil dein Hostinganbieter deinen Server gesperrt hat – und so geht es eigentlich den meisten meiner Kunden. Der Laie ist in vielen Fällen überfordert und würde einen erfolgreichen Angriff nicht erkennen.

Es gibt Fälle, bei denen man es beispielsweise merkt, weil man als Besucher der Website plötzlich auf dubiose Seiten weitergeleitet wird oder die Seite ohne eigenes Zutun übersäht von PHP Fehlern ist. Der Zufall kann einem natürlich auch weiterhelfen – wer in seiner Nutzerliste plötzlich einen neuen Administrator bemerkt, darf davon ausgehen, dass es irgendwem gelungen ist, die Seite zu hacken. Wer etwas mehr PHP kann, der neigt auch dazu selbst Kleinigkeiten im Theme anzupassen und sieht womöglich kryptische Zeichen in den PHP Dateien – das kann ebenfalls ein Zeichen dafür sein, dass jemand ins System eingedrungen ist.

Es lohnt sich auch nach der eigenen Seite via Google (“site:deine-seite.de”) zu suchen – wenn unter der eigenen Adresse Warez-, Viagra- oder Porno-Seite im Google-Index zu finden sind, dann hat man ein recht eindeutiges Zeichen, dass etwas nicht stimmt. In so einem Fall kann man außerdem davon ausgehen, dass der Angriff nicht erst kürzlich stattgefunden hat.

Wer erweiterten Zugriff auf seinen Server hat (z.B. SSH), der kann relativ schnell feststellen, ob etwas nicht stimmt. Man kann sich beispielsweise die zuletzt geänderten oder hinzugefügten Dateien ausgeben lassen. Man kann auch mal in Log-Dateien schauen (error.log, mail.log, …). Hierzu bedarf es allerdings etwas tieferes Verständnis von Servern und der Software, die installiert ist. Außerdem sollte man dann in der Lage sein, das was man sieht, richtig zu interpretieren. Für einen Laien eine denkbar schwere Aufgabe.

3. Was sind die häufigsten Gründe für Hacks? Warum machen sich die Hacker die “Arbeit”?

Wie oben schon erwähnt: der wohl häufigste Grund sind veraltete CMS, Shopsysteme oder andere Tools – sei es nun WordPress, Joomla, Magento oder Piwik. Schlechte Passwörter (“123456”, “passwort”,…) in diesen Tools, aber auch in Software, die auf dem Server läuft (FTP, SSH, …), sind ebenfalls hin und wieder Einfallstore.

Ich würde nicht sagen, dass sich da jemand sonderlich viel Arbeit machen muss. Alles was man braucht, findet man im Internet umsonst. Für aktuelle Exploits gibt es Datenbanken (z.B. exploit-db.com), es gibt Programme, die in der Lage sind automatisch Lücken auszunutzen. Entweder man nimmt so etwas fertiges und lässt es durch das Internet jagen oder man programmiert sich einen eigenen kleinen Bot, der nach bestimmter Software Ausschau hält und versucht, Schwachstellen in dieser Software auszunutzen. Bei Angriffen hat man es also in der überwiegenden Mehrzahl an Angriffsversuchen und erfolgreichen Angriffen mit Bots zu tun.

Ist eine Seite bzw. ein Server gehackt, kann man damit allerhand Dinge anstellen. Das was die meisten kennen ist eben der klassische Spamversand, der den Leuten dahinter nicht wenig Geld bringt. Der ein oder andere wird auch von “Drive by Downloads” gehört haben. Gehackte Seiten können so manipuliert werden, dass sie den Besuchern (halb-)automatisch Trojaner und Viren installieren. Diesen Besuchern kann man dann Kreditkartendaten oder deren Passwortlisten zu PayPal, Amazon, Ebay und Co. vom Rechner kopieren.

Blackhat SEO ist ebenfalls ein beliebter Grund. Dabei werden Backlinks – oft nur sichtbar für den Googlebot – auf einer gehackten Seite platziert.

Seltener sieht man den Fall, dass ein gehackter Server als Warezserver verwendet wird. Es kommt allerdings vor – solche Server werden dann in Untergrundforen verteilt und dazu verwendet dort illegale Filme, Musik, Spiele usw. zu hosten.

4. WordPress ist mit Abstand das meistgenutzte CMS der Welt, aber leider nicht wirklich sicher. Was sind denn die wichtigsten Schritte, um WordPress so sicher, wie möglich zu machen?

WordPress als CMS ist erst einmal alles andere als unsicher – es ist vielleicht aus heutiger Sicht nicht modern programmiert. Das heißt aber noch lange nicht, dass es unsicher ist. Schaut man sich die ganzen erfolgreichen Hacks an, stellt man eher fest, dass schlecht bzw. unsicher programmierte Themes und Plugins der Grund sind.

Spannend ist, wenn man es mit Custom-Plugins oder -Themes zu tun hat – wenn die Entwickler da unerfahren sind, darf man eigentlich mit Sicherheitslücken rechnen. In solchen Fällen werde ich regelmäßig in beratender bzw. kontrollierender Rolle hinzugezogen, um eine gewisse Qualität hinsichtlich Sicherheit zu gewährleisten. Leider stellt man dann fest, dass die Entwickler sich kaum mit dem WordPress Codex auseinandergesetzt haben und z.B. lieber ihre eigenen Datenbankklassen verwenden, wo sie Benutzereingaben ungefiltert/unvalidiert in die Datenbank schicken. Hier fehlt oft das allgemeine Verständnis für Sicherheit in Webapplikationen.

Vorsichtig sollte man außerdem bei Premium-Plugins und Premium-Themes sein, die man z.B. via Themeforest kaufen kann. Was man hier oft vor allem bei den Plugins sieht, sind schnell zusammen gefrickelte Codes, die an die Masse verkauft werden sollen. kommerzielle Plugins und Themes sollte man nie mit besserer Codequalität gleichsetzen!

Was ich sagen will: WordPress ist per se nicht unsicher. Es sind meist stupide Fehler von unerfahrenen Entwicklern, die zum Sicherheitsrisiko werden können.

Im Fall von WordPress würde ich als Basis immer empfehlen ein langes sicheres Passwort zu verwenden. Man sollte ein Auge auf Plugins und Themes haben. Zeitnahe Updates sind Pflicht. Wird ein Theme über Monate nicht gepflegt, würde ich es einfach nicht verwenden – es sei denn ich bin in der Lage den Quellcode zu beurteilen und Sicherheitslücken auszuschließen. Das sind allerdings auch Tipps, wie man sie für jede andere Websoftware geben kann.

Ich persönlich finde es nicht verkehrt, wenn man den “wp-admin”-Ordner und die wp-login.php mit einer .htaccess zusätzlich schützt – sofern es die eigene Seite erlaubt. Wer ein Forum oder einen Onlineshop mit Login betreibt, bei dem sich Nutzer einloggen können, wird das nur schwer realisieren können. Außerdem gibt es Plugins und Themes, die beispielsweise auf die admin-ajax.php im “wp-admin”-Ordner zugreifen. Hierfür muss man dann Ausnahmen einrichten – ansonsten kann es dazu führen, dass die Seite nicht so funktioniert, wie sie soll.

Neben dem Sicherheitsaspekt hat eine .htaccess auf den Login einen weiteren Vorteil: Es lässt die hunderte und tausende Bots nicht bis zur Eingabemaske kommen. Bots probieren gerne diverse Nutzer/Passwort-Kombinationen aus und das oft in kurzen Zeitintervallen. Damit belasten sie den Server teilweise nicht wenig. Das kommt besonders zum Tragen, wenn man eine ohnehin schon hochfrequentierte Seite hat, bei der Performance ein großes Thema ist.

5. Helfen “Security-Plugins” für WordPress weiter?

WordFence, iThemes Security und Co. kann man verwenden, sie schaden allgemein erstmal nicht, aber man sollte nicht wirklich erwarten, dass so ein Plugin wirklich schützt. Solche Plugins hängen sich an einem bestimmten Punkt ins System, ist der Schadcode schneller, dann bringt der “Schutz” nichts. Gleiches gilt für externe Scripte – wie sie z.B. oft von Themes verwendet werden (Bildmanipulation, …).

Die Plugins sind gut gegen simple Angriffsmethoden und Versuche, Schadcode ins System zu bringen (SQL Injections, XSS, …). Hat man es mit einer “gemeineren” Sicherheitslücke (z.B. PHP Object Injections) zu tun, wird man von diesen Plugins oft enttäuscht.

Pluspunkte soll es aber auch geben – die Monitoring-Funktionen dieser Security-Plugins kann man als durchaus hilfreich bezeichnen. Gemeint sind hier die versuchten Logins aber auch der Abgleich der Core-Dateien bzw. deren Hashes mit der WordPress Datenbank.

Der Profi wird aber keines der Plugins benötigen, weil die wirklich nützlichen Features auch anderweitig und deutlich besser zur Verfügung stehen. So lässt sich die Integrität des WordPress Cores direkt über wp-cli prüfen. Änderungen der Dateien lassen sich schnell via SSH finden (siehe dazu meinen Artikel “WordPress gehackt”).
Es sei im Fall von Security-Plugins auch anzumerken, dass sie selbst zur Sicherheitslücke werden können – das ist in der Vergangenheit schon häufig passiert und wird sich sicherlich wiederholen. Daher heißt es auch hier – wenn ein Update zur Verfügung steht, aktualisieren. Wenn das Plugin nicht mehr gewartet wird, runter damit.

6. Und unabhängig von WordPress: Was sollte man noch tun, um Hackerangriffe zu vermeiden oder zumindest das Risiko zu minimieren?  

Man sollte zusehen, dass man auf allen Ebenen up to date ist – das fängt bei der Software auf dem Server an und endet bei der eigenen Software auf dem PC. Dazwischen ist natürlich irgendwo das CMS samt Plugins, Extensions, Themes und Co. Überall ein anderes Passwort zu verwenden, ist ein Tipp, der nicht umsonst immer wieder genannt wird!

Was mir leider oft begegnet sind Menschen mit vielen Seiten auf einem managed Server, die das, was so ein Server anbietet, nicht ausnutzen. Viele Anbieter erlauben es problemlos pro Website/Projekt Quotas oder einen eigenen Benutzer samt eingeschränkter Dateirechte anzulegen. Das funktioniert je nach Anbieter unterschiedlich. All Inklusive ist da sehr vorbildlich – man sollte hier zum Beispiel für jedes Projekt einen eigenen Unteraccount anlegen. Gleichzeitig ist es durchaus ratsam die Dateirechte so einzustellen, dass der PHP-Nutzer nur eingeschränkt schreiben darf. Volle Schreibrechte sollte nur der FTP-Nutzer haben. Server von Domainfactory erlauben nur Quotas, was besser als nichts ist. WebGo – der Anbieter von Felix – realisiert Zugriffs/Dateirechte über den Punkt “Zusatz FTP”.

Die Aufteilung der eigenen Projekte und das Verwenden strikter Dateirechte hat mehrere Vorteile. Wird man gehackt, ist der Bot/Angreifer nicht in der Lage sich außerhalb des gehackten Projekts auszubreiten und ggf. andere Projekte zu infizieren. Sind dann noch ordentliche Dateirechte eingestellt worden, kann sich Schadcode selbst innerhalb eines Projekts nur in den beschreibbaren Ordnern ausbreiten.

Im Fall von WordPress sollte man für den PHP Nutzer beispielsweise nur den “wp-content/uploads/”-Ordner beschreibbar machen (chmod 777). Verwendet man ein Caching-Plugin, müssen in der Regel auch die Cache-Dateien sowie der “cache”-Ordner beschreibbar sein, damit das Plugin ordentlich funktioniert. Hier muss man aber mit Verstand agieren – es gibt Caching-Plugins, die gerne Schreibrechte auf alles mögliche hätten – beispielsweise die .htaccess. Ich für meine Teil erlaube das nicht und ändere die Datei bei Bedarf von Hand.

Schaut man sich das Vorgehen von Schadsoftware/Schadcode an, stellt man fest, dass als erstes in einem der klassischen immer beschreibbaren Ordner eine Webshell platziert wird. Das wäre meist der “uploads”-Ordner. Ist die Shell platziert, kann man sie ausführen. Und hier kann man ansetzen. Es gibt Webhoster, die es erlauben die PHP-Engine für einzelne Verzeichnisse zu deaktivieren. Das funktioniert meist über eine leicht angepasste .htaccess, die man in den “uploads”-Ordner legen kann. Damit verhindert man das Ausführen von PHP-Dateien.

Was im speziellen Fall machbar ist, kann man meist beim Webhoster erfragen. Was davon dann wirklich sinnvoll ist, hängt von vielen Faktoren ab. Da sollte man vielleicht den Fachmann fragen.

Bekommt man vom eigenen Webhoster als Antwort, dass so etwas gar nicht möglich ist, dann empfehle ich den Wechsel. Man wird es früher oder später bereuen!

Ein weiteres großes Thema ist die Betreuung von root Servern. Der Trend geht gefühlt in die Richtung, dass sich Laien ganze root Server mieten, dort schon allerhand installiert ist und sie sie verwenden. Ihnen wird aber nicht gesagt, dass der Server gewartet werden muss. Genauso, wie WordPress aktualisiert werden muss, muss man sich um die Updates für Apache, nginx, mysql, dovecot, openssl und wie die Pakete eben alle heißen kümmern. Und das ist eben alles andere als trivial, d.h. der Laie macht es einfach nicht und wundert sich, warum er dann gehackt wird. Daher, wer so etwas nicht kann, der nimmt einen managed Server oder Webspace. Eine Alternative ist natürlich ein fähiger System-Administrator.

Die Verwendung aktueller Systemsoftware sollte eine Selbstverständlichkeit sein. Als Beispiel will ich hier PHP selbst nennen. Diverse Hoster bieten in ihren Paketen eine breite Auswahl an Versionen – angefangen von PHP 5.3 bis PHP 7.1. Ich empfehle jedem, der seine Seiten noch auf PHP 5.3 oder drunter betreibt, auf die aktuellste stabile Version von mindestens PHP 5.6 zu setzen. Unter PHP 5.3 lassen sich diverse Arten von Sicherheitslücken viel einfach ausnutzen, als unter PHP 5.6 – das gilt insbesondere für Sicherheitslücken in Zusammenhang mit der unserialize-Funktion von PHP.

Ein guter Tipp, um die Sicherheit der eigenen Seiten zu verbessern, ist es jemanden, wie mich über einen Wartungsvertrag zu engagieren, der sich in definierten Intervallen die Seiten und den Server näher anschaut, Code bewertet und sich bei Bedarf auch um Aktualisierungen kümmert 😉

Erwähnenswert ist aber auch folgendes: Absolute Sicherheit wird es nie geben. Gegen Bots kann man sich relativ einfach wehren. Wird man bzw. die eigene (populäre) Seite Ziel von “richtigen Blackhats”, die ein tiefes Verständnis für IT Security haben, hat man ein viel größeres Problem. Trotzdem muss man es Angreifern so schwer, wie möglich machen.

Vielen Dank, Damian, für das spannende Interview und vor allem nochmal für deine schnelle Hilfe!

Über Damian Schwyrz

Von Berlin aus entwickelt Damian schnelle und sichere Websoftware mit Laravel oder Slim PHP im Auftrag von Kunden. Neben der Arbeit als Entwickler beschäftigt er sich aktuelle mit Python und künstlicher Intelligenz und betreibt u.a. fernseher-kaufberatung.com. IT-Sicherheit & Hacking sind Themen, in denen er nicht nur theoretische Erfahrung hat.

Mehr zu Damian findest du auf seiner Website. Am schnellsten kannst du mit ihm über Facebook Kontakt aufnehmen.



Ähnliche Beiträge



Kommentare


Florian Busch 23. Januar 2017 um 9:39

Hallo,
Danke für das Interview.
@Damian:
Mir ist leider immer noch nicht klar, wie ich das machen soll, auf WordPress Themes und Plugins "ein Auge werfen"? Woran erkenne ich als Laie, ob ich das Theme bzw. Plugin installieren soll, oder nicht?
Du schreibst dazu zwar "Daher heißt es auch hier – wenn ein Update zur Verfügung steht, aktualisieren. Wenn das Plugin nicht mehr gewartet wird, runter damit."
Aber was heißt "nicht gewartet". Sollte es regelmäßig Aktualisierungen geben, und wenn ja, wie oft ungefähr?

Antworten

Damian Schwyrz 24. Januar 2017 um 10:56

Hallo Florian,

"Mir ist leider immer noch nicht klar, wie ich das machen soll, auf WordPress Themes und Plugins "ein Auge werfen"? Woran erkenne ich als Laie, ob ich das Theme bzw. Plugin installieren soll, oder nicht?"

1. Wenn du ein Theme/Plugin findest, dessen letztes Update Monate oder Jahre her ist, wäre das wohl ein Zeichen.
2. Wenn du ein Theme/Plugin findest, was alle möglichen WP Versionen unterstützt, außer die aktuelle – wäre das ein Zeichen.
3. Die Bewertungen allgemein sind ebenfalls ein recht gutes Indiz dafür, ob das Plugin was taugt oder nicht – da würde ich z.B. drauf achten, ob Supportanfragen beantwortet werden.

Allgemein ist es aber auch so, dass es Plugins gibt, die a) seit 2 Jahren nicht aktualisiert wurden und b) trotzdem mit aktuellen Versionen von WP funktionieren. Meist sind das kleinere Plugins. Hin und wieder verwende ich solche Plugins auch, allerdings bin ich in der Lage mir den PHP Code anzuschauen und ihn zu bewerten. Das wird die Mehrheit der Laien wohl nicht können.

Grüße,

Damian

Antworten

Patrick 26. Januar 2017 um 9:08

Hallo Damian,

eine gute Zusammenfassung der möglichen Lücken in WordPress. Ich würde noch folgendes hinzufügen:

.) BackUps im wp-content Folder löschen (wp-config.php)
.) debug.log im wp-content Folder einer Live Instanz deaktivieren (Pfad des Servers)
.) Directory Listing am Server deaktivieren (Infos, Infos, Infos ;-))

Und wenn man eine alte WP Version verwendet sollte man das im Quellcode nicht unbedingt anzeigen.

Antworten

Damian Schwyrz 27. Januar 2017 um 12:46

Hi,

naja, das sind ja alles keine konkreten Lücken bzw. eig. hab nur nur einige allgemeine Arten von Lücken genannt. Die Möglichkeiten einen Webspace abzusichern bzw. das Nicht nutzen dieser Möglichkeiten ist keine Sicherheitslücke sondern eher verschwendetes Potential.

Zu a) Manche Plugins legen leider solche Backups in den wp-content Ordner – da die Namen zu erraten ist zwar meist schwer, trotzdem sollte man in solchen verzeichnissen eine htaccess mit deny from all drin haben.
Zu b) Debugging gehört nie in da s LiveSystem, egal ob php debug oder eben das was WP da machen kann. Ein gut eingestellter Server macht da aber auch keine Probleme 😉
Zu c) Wessen Server DL aktiviert hat, ist selbst schuld… das ist sowas von keine Standardeinstellung…

Zur letzten Aussage – Security by Obscurity ist erstmal GAR KEIN Schutz… man muss nicht im Quellcode anzeigen, welche WP Version man verwendet… man kriegt das auch über tausend andere Wege raus 😉
Bitte auf sowas nie verlassen… genauso, wie das "verstecken" von wp-admin. Das hat nix mit IT Sicherheit zu tun.
Grüße
Zu c)

Antworten

Michael 8. Februar 2017 um 23:34

Hallo,

unser Magento Shop ist gehackt worden. Wir bieten Drohnen und RC Spielzeuge an. Nachdem ein IT Forensiker unser Onlineshop nach dem Hacking Angriff wieder repariert hat, fragte ich mich wie wir dies in Zukunft verhindern können. Die Aktion kostete uns 2900 EUR und ich weiß nicht ob wir Kundendaten verloren haben? Wahrscheinlich ist es.

Auf meiner Suche habe ich 2 Angebote gefunden. Eines aus Deutschland und eines aus den USA. Kann mir jemand sagen was man von diesen Angeboten halten kann und für welches sollte ich mich entscheiden?

Nr. 1 Deutschland
https://janotta-partner.de/projekt-defense.html

Nr. 2 USA:
https://sucuri.net/website-firewall/signup

Freue mich auf Meinungen…
Gruß Michael

Antworten

Damian Schwyrz 13. Februar 2017 um 11:43

Hi Michael,
ja, du kannst davon ausgehen, dass die Daten weg sind.

Wenn ich für mich sprechen soll: Du gehst es schon direkt falsch an. Das wichtigste ist, dass dein System sicher ist. Ist es sicher, also aktuell, dann bist du halbwegs auf der sicheren Seite. Danach kann man sich anschauen, was man noch auf deiner Seite machen kann. Und oft ist da was zu machen 😉

Erst DANACH kannst du dir überlegen, dich für eine "Firewall" zu entscheiden. Du solltest aber nicht erwarten, dass dir so ein Dienst die ohnehin notwendige Arbeit abnimmt oder dich vor 0days schützt. Diese Dienste pflegen oft selbst erst nach Erscheinen der Lücken ihre Regeln ein und können dann erst schützen. Anders herum: sie schützen nur vor dem, was bisher bekannt ist und was bekannt ist, kann man in der Regel durch ein Update des Systems/Plugins/Themes verhindern.

Zu den beiden Anbietern: wenn ICH du wäre und das unbedingt wollen würde, würde ich einen Anbieter, wie Sucuri nehmen. Die beweisen immer wieder, dass da wirkliche Experten dahinter stecken 😉

Grüße

Antworten

WordFence WordPress Sicherheitstest | damianschwyrz.de 14. März 2017 um 16:34

[…] Möglichkeit einzelne Websites voneinander zu trennen. Der häufigste Fehler, den viele machen (Beispiel Felix Beilharz), ist dass sie solche Server mieten, aber nicht von den Möglichkeiten Gebrauch machen. In Folgen […]

Antworten

Oliver Heim 14. April 2017 um 11:34

Hallo Felix, hallo Damian,

vielen Dank für den sehr informativen Artikel. Auch ich war von einem Hack betroffen. Selbst, schuld, da ich es versäumt habe Updates des Themes und von Plug-ins zeitnah einzuspielen. Da der Hack wohl schon länger zurück lag, also im Vergleich zum Zeitpunkt, zu dem mein Provider (1&1) mich darauf aufmerksam gemacht hat, war für mich als Laie nichts zu machen. Die automatischen Backups von 1&1 waren ebenfalls verseucht und die Hilfe des 1&1-Support überschaubar. Ich habe mich am Ende entschlossen alles neu aufzusetzen und habe per FTP alles gelöscht und zuvor meine Artikel manuell gesichert. Ich habe insgesamt bemerkt, wie hilflos man als Laie ist. Da ich meine Seite als Hobby, also ohne Geschäftsmodell betreibe, kam kostenpflichtige Hilfe nicht wirklich in Frage.

Nun fange ich neu an, was auch seine Vorteile hat, da ich sowieso das Theme wechseln wollte. Ich habe mich jetzt erstmal wieder für ein Theme aus dem Envarto Market entschlossen. Nach dem Studium dieses Artikels bin ich unsicher ob die Wahl gut war. Darüber hinaus habe ich mich beim neuaufsetzen des Webs gegen einen "managed Server" entschieden, da ich den Eindruck hatte, dass sich in dieser Version das Theme und seine Beispielinhalte nicht richtig installieren lassen. Auf der anderen Seite ist mir das Risiko bewusst, da ich nun wirklich nicht so viel Ahnung habe. Ich achte nun auf die Updates von WP & Co. Kenne aber natürlich keine sonstigen Systemkomponenten und weiß nicht wirklich um was sich 1&1 kümmert und um was nicht.

Da ich vermute das es vielen Bloggern so geht und 1&1 als Marktführer in Sachen Hosting gilt, könnte ich mir vorstellen dass eine Einschätzung zu 1&1 und den dortigen Optionen bzw. Stolperfallen auch für andere Leser sehr interessant ist.

Antworten

Hacke deine Website bevor es Hacker tun! 4. Oktober 2017 um 15:07

[…] Eine gehackte, infizierte oder anderweitig unsichere Webseite hat zahlreiche negative Folgen. Aber selbst wenn man sich in Sicherheit wiegt, kann jederzeit ein Angriff erfolgen. So wurde auch Felix Beilharz letztes Jahr Opfer von Cyberkriminellen. Seinen Bericht kannst du hier nachlesen. -> Website gehackt- was nun?  […]

Antworten

Du hast eine Frage oder eine Meinung zum Artikel? Teile sie mit uns!

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*
*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Auszeichnungen

Mitgliedschaften, Zertifizierungen & Auftritt