Website-Sicherheit und Wartung: was vor und nach einem Hack zu tun ist

Am Morgen schreibt Ihnen ein Kunde: „Ihre Website leitet mich auf eine Casino-Seite weiter.“ Oder Sie suchen bei Google nach Ihrer Firma und sehen unter dem eigenen Eintrag den Hinweis, die Website sei möglicherweise gehackt worden. Sie versuchen, die Agentur zu erreichen, die die Seite gebaut hat. Das Projekt wurde vor zwei Jahren übergeben, seitdem hat sich niemand mehr eingeloggt.

Dieser Beitrag soll Ihnen diesen Morgen ersparen und zeigen, was zu tun ist, falls er doch kommt. Es geht darum, warum Websites gehackt werden, welche Maßnahmen bei WordPress zählen, wie Update- und Backup-Routinen aussehen sollten, um Zugänge und Infrastruktur, um Monitoring, um das Vorgehen nach einem Angriff und um Meldepflichten, wenn personenbezogene Daten betroffen sind. Am Ende steht eine Tabelle mit allem, was ein Wartungsvertrag regeln sollte.

Warum werden Websites gehackt?

Viele Unternehmer denken: „Bei uns gibt es doch nichts zu holen.“ Das Problem ist, dass die meisten Angreifer Sie gar nicht ausgesucht haben. Automatisierte Werkzeuge durchsuchen rund um die Uhr das Netz, und wo sie eine Plugin- oder Theme-Version mit bekannter Schwachstelle finden, dringen sie ein. Größe, Branche und Besucherzahl Ihrer Website spielen dabei keine Rolle.

Ist der Angreifer drin, geht es oft nicht einmal um Ihre Daten. Die Website wird zum Werkzeug: Sie veröffentlicht Spam-Seiten, leitet Besucher auf betrügerische Angebote um, beherbergt Phishing-Seiten oder greift andere Server an. Meist merken Sie es erst, wenn Google warnt oder sich ein Kunde beschwert.

Die Einfallstore, die wir in der Praxis am häufigsten sehen:

• Veraltete Plugins und Themes. Nach Bekanntwerden einer Lücke erscheint ein Update; wer es nicht einspielt, bleibt monatelang angreifbar.
• Verwaiste Plugins. Gibt der Entwickler auf und hat ein jahrelang nicht gepflegtes Plugin eine Lücke, kommt die Korrektur nie. Im Plugin-Verzeichnis von WordPress.org tragen aus Sicherheitsgründen geschlossene Plugins den Hinweis „This plugin has been closed… Reason: Security Issue“. Schauen Sie ab und zu auf die Seiten Ihrer Plugins.
• Raubkopierte, sogenannte „nulled“ Themes und Plugins. Die unlizenzierte Kopie eines Premium-Themes bringt häufig eine versteckte Hintertür mit. Die WordPress-Dokumentation sagt es deutlich: keine Plugins oder Themes aus nicht vertrauenswürdigen Quellen.
• Schwache oder mehrfach verwendete Passwörter. Anderswo erbeutete Kombinationen aus E-Mail-Adresse und Passwort werden automatisiert an Tausenden Login-Seiten durchprobiert.
• Fehlkonfiguration: öffentlich abrufbare Backup-Dateien, aktivierte Verzeichnisauflistung, zu weite Dateirechte, vergessene Testinstallationen.

Die OWASP Top 10, die Referenzliste für die Sicherheit von Webanwendungen, nennt in der Ausgabe 2025 auf den ersten drei Plätzen fehlerhafte Zugriffskontrolle, Sicherheitsfehlkonfiguration und Fehler in der Software-Lieferkette. Die letzte Kategorie erweitert den früheren Punkt „veraltete Komponenten“, und für eine kleine Unternehmenswebsite heißt das schlicht: Jedes Plugin, jedes Theme und jede Bibliothek gehört zu Ihrer Angriffsfläche.

Die WordPress-Grundlagen

WordPress ist das System, das wir bei Unternehmenswebsites am häufigsten antreffen, und es ist an sich nicht unsicher. Die meisten Probleme entstehen nicht im Kern, sondern durch Erweiterungen und fehlende Pflege. Die Grundlagen:

• Weniger Plugins. Jedes ist eine eigene Codebasis mit eigenem Entwickler und eigenem Update-Rhythmus. Nicht genutzte Plugins nicht nur deaktivieren, sondern löschen.
• Plugins nur aus dem WordPress.org-Verzeichnis oder von bekannten Herstellern installieren und prüfen, wann sie zuletzt aktualisiert und ob sie mit Ihrer WordPress-Version getestet wurden.
• In die wp-config.php die Zeile define( 'DISALLOW_FILE_EDIT', true ); eintragen. Damit lässt sich Theme- und Plugin-Code nicht mehr im Backend bearbeiten, und ein gekapertes Admin-Konto kann nicht einfach Schadcode einfügen.
• Keine erratbaren Benutzernamen wie „admin“, dafür Zwei-Faktor-Authentifizierung für alle Administratoren.
• Anmeldeversuche begrenzen, per Sicherheits-Plugin oder an der Firewall vor dem Server.
• Dateirechte eng halten. Die WordPress-Dokumentation empfiehlt für die wp-config.php Rechte, die nur Ihnen und dem Webserver Lesezugriff geben, typischerweise 400 oder 440.
• Regelmäßig unter Werkzeuge > Website-Zustand nachsehen; dort tauchen veraltete PHP-Versionen oder deaktivierte automatische Updates auf.

Update-Richtlinie und Staging-Umgebung

„Wir machen die Updates“ ist keine Richtlinie. Eine Richtlinie legt fest, was wann von wem und wie aktualisiert wird.

Seit WordPress 3.7 werden kleinere Wartungs- und Sicherheitsversionen standardmäßig automatisch installiert, seit Version 5.5 lassen sich automatische Updates in der Plugin-Übersicht für jedes Plugin und Theme einzeln einschalten. Ab Werk ist diese Option aus. Wie viel Sie automatisch laufen lassen, hängt davon ab, wie viel individueller Code in der Website steckt.

Die Routine, die wir empfehlen:

1. Sicherheitsupdates haben Vorrang. Wird in einem genutzten Plugin eine Lücke bekannt, gehört das Update innerhalb weniger Tage eingespielt, bei schweren Lücken noch am selben Tag.
2. Übrige Plugin- und Theme-Updates gesammelt im festen Rhythmus einspielen, wöchentlich oder alle zwei Wochen.
3. Größere Versionssprünge zuerst auf einer Staging-Umgebung testen: neue WordPress-Hauptversionen, Page Builder, Shop-Plugins.
4. Vor jedem Update ein Backup anlegen und wissen, wie man zurückkehrt.
5. Nach dem Update Startseite, Formulare, Kassenprozess und Kunden-Login prüfen.

Eine Staging-Umgebung ist eine passwortgeschützte, für Suchmaschinen gesperrte Kopie der Live-Website. Viele Hoster richten sie mit einem Klick ein. Ohne Staging werden Updates entweder gar nicht oder blind auf der Live-Seite eingespielt, und beides geht irgendwann schief.

Backups: 3-2-1-Regel und Wiederherstellungstest

Ein Backup ist erst dann ein Backup, wenn es sich zurückspielen lässt. Am häufigsten erleben wir eine Sicherungsroutine, an die alle glauben, die aber nie getestet wurde und sich im Ernstfall als lückenhaft oder beschädigt erweist.

Die 3-2-1-Regel, die auch das BSI empfiehlt, lautet: mindestens drei Kopien der Daten, auf mindestens zwei verschiedenen Medien, davon mindestens eine an einem anderen Ort. Für eine Website heißt das:

• Das tägliche Backup des Hosters ist die erste Ebene, reicht aber allein nicht. Wird Server oder Konto kompromittiert, liegen die Sicherungen am selben Ort.
• Die zweite Kopie liegt bei einem anderen Anbieter, etwa in einem separaten Cloud-Speicher, mit anderen Zugangsdaten als die Website.
• Gegen Ransomware sollte mindestens eine Kopie unveränderbar oder offline sein. Das BSI weist in seinem Maßnahmenkatalog zu Ransomware darauf hin, dass Angreifer gezielt nach erreichbaren Backups suchen.
• Dateien und Datenbank sichern. Ein reines Datenbank-Backup bringt hochgeladene Bilder und Dokumente nicht zurück.
• An die Aufbewahrungsdauer denken: Ein Hack fällt manchmal erst nach Wochen auf. Wer nur sieben Tage vorhält, hat womöglich nur noch infizierte Sicherungen.

Der wichtigste Punkt ist der Wiederherstellungstest, den auch das IT-Grundschutz-Kompendium des BSI regelmäßig verlangt. Spielen Sie einmal im Quartal ein Backup auf die Staging-Umgebung zurück und prüfen Sie, ob alles läuft. Sie lernen dabei zweierlei: ob die Sicherung taugt und wie lange die Wiederherstellung dauert. Letzteres bestimmt, was Sie Ihren Kunden im Ernstfall sagen.

Zugänge und Infrastruktur

Zwei-Faktor-Authentifizierung und minimale Rechte

Die Schlüssel zu Ihrer Website liegen nicht nur im WordPress-Backend. Domain-Registrar, DNS-Verwaltung, Hosting-Panel, E-Mail, Google Search Console und Analytics lassen sich jeweils nutzen, um die Website zu übernehmen. Aktivieren Sie überall die Zwei-Faktor-Authentifizierung, besser per Authenticator-App oder Hardware-Schlüssel als per SMS, und prüfen Sie, ob die Transfersperre Ihrer Domain aktiv ist.

Das Prinzip der minimalen Rechte ist einfach: Jeder bekommt genau die Rechte, die er für seine Aufgabe braucht. Wer Blogbeiträge schreibt, braucht die Rolle Redakteur oder Autor, nicht Administrator. Jede Person erhält ein eigenes Konto statt eines gemeinsamen Firmenlogins, damit nachvollziehbar bleibt, wer was getan hat. Konten ausgeschiedener Mitarbeitender und ehemaliger Agenturen werden am selben Tag geschlossen; eine der häufigsten Lücken bei übernommenen Websites ist ein funktionierendes Admin-Konto von jemandem, der seit Jahren nicht mehr da ist.

HTTPS und HSTS

Über HTTPS muss man nicht mehr diskutieren: Zertifikate gehören zu den meisten Hosting-Paketen, und Browser warnen, sobald jemand auf einer HTTP-Seite ein Formular ausfüllt. Entscheidend ist, dass sich das Zertifikat automatisch erneuert und alle Seiten, Bilder und Skripte über HTTPS geladen werden.

Der HSTS-Header (HTTP Strict Transport Security) weist Browser an, Ihre Website künftig nur noch per HTTPS aufzurufen. Für die HSTS-Preload-Liste der Browser braucht der Header ein max-age von mindestens einem Jahr (31536000 Sekunden) sowie die Direktiven includeSubDomains und preload. Vorsicht: Die Entfernung von der Liste dauert Monate, und alle Subdomains müssen HTTPS beherrschen. Eine vergessene Subdomain ohne Zertifikat ist dann schlicht nicht mehr erreichbar.

WAF, CDN und Trennung beim Hosting

Eine Web Application Firewall (WAF) blockt bekannte Angriffsmuster, bevor sie Ihren Server erreichen. Das leisten etwa ein CDN mit Sicherheitsfunktionen wie Cloudflare, Dienste wie Sucuri oder ModSecurity auf dem Server. Eine WAF ersetzt keine Updates, sie verschafft Zeit, bis eine Korrektur verfügbar ist.

Beim Hosting ist der klassische Fehler, mehrere Websites unter einem einzigen Benutzerkonto zu betreiben. Wird eine vergessene Aktions-Microsite gehackt, ist die Hauptseite im selben Konto gleich mit betroffen. Jede Website sollte getrennt unter einem eigenen Systembenutzer laufen. Nutzen Sie SFTP oder SSH-Schlüssel statt FTP und bleiben Sie auf einer PHP-Version, die noch unterstützt wird.

Monitoring: Probleme vor den Kunden bemerken

Ohne Monitoring erfahren Sie von Problemen durch Kunden, durch Google oder durch den Angreifer. Mindestens einrichten sollten Sie:

• Verfügbarkeitsüberwachung, die per E-Mail oder Nachricht warnt, wenn die Website länger als ein paar Minuten nicht antwortet.
• Integritätsprüfungen, die Core- und Plugin-Dateien mit den offiziellen Versionen vergleichen, per Sicherheits-Plugin oder mit den WP-CLI-Befehlen wp core verify-checksums und wp plugin verify-checksums.
• Den Bericht „Sicherheitsprobleme“ in der Google Search Console. Erkennt Google Malware, eingeschleusten Code oder eingeschleuste Inhalte, erscheint das dort, und Sie bekommen eine E-Mail. Ohne Search-Console-Konto erreicht Sie diese Warnung nie.
• Ablaufdaten von Zertifikat und Domain. Eine verfallene Domain richtet ähnlich viel Schaden an wie ein Hack.
• Ein Protokoll von Ereignissen wie neuen Administratorkonten oder Plugin-Installationen.
• Sperrlisten: Markiert Google Safe Browsing Ihre Website, warnen Browser die Besucher, und andere Sicherheitsdienste ziehen oft nach.

Gehackt: Schritt für Schritt

Panik ist ein schlechter Ratgeber. Wer in Eile alles löscht, kann nicht mehr nachvollziehen, wie der Angreifer hereinkam, und eine Woche später ist er über dieselbe Lücke wieder da. Gehen Sie in dieser Reihenfolge vor:

1. Dokumentieren Sie den Zustand. Screenshots anfertigen, Warn-E-Mails aufbewahren, sicherstellen, dass Server-Logs nicht gelöscht werden.
2. Nehmen Sie die Website in Quarantäne: Wartungsmodus oder vorübergehende Abschaltung in Absprache mit dem Hoster. Der Schutz der Besucher geht vor.
3. Informieren Sie Ihren Hoster; womöglich sind weitere Konten auf demselben Server betroffen.
4. Ändern Sie alle Passwörter: Admin-Konten, Datenbank, SFTP, Hosting-Panel, API-Schlüssel. Erneuern Sie bei WordPress die Sicherheitsschlüssel (Salts) in der wp-config.php, damit offene Sitzungen beendet werden.
5. Prüfen Sie die Benutzerliste und entfernen Sie unbekannte Administratoren.
6. Bereinigen Sie. Am sichersten ist die Rückkehr zu einem geprüften, sauberen Backup aus der Zeit vor dem Angriff. Sonst Core-, Plugin- und Theme-Dateien aus offiziellen Quellen neu einspielen und nach Überresten suchen, etwa PHP-Dateien in Upload-Ordnern.
7. Finden und schließen Sie das Einfallstor. Ein veraltetes Plugin? Ein geleaktes Passwort? Wer ohne Antwort wieder online geht, lässt die Tür offen.
8. Öffnen Sie in der Search Console den Bericht „Sicherheitsprobleme“, klicken Sie auf „Überprüfung anfordern“ und beschreiben Sie genau, was Sie unternommen haben. Laut Google dauern die meisten Überprüfungen mehrere Tage bis Wochen; die Warnung bleibt so lange bestehen.
9. Verschärfen Sie danach das Monitoring und halten Sie den Vorfall in einem kurzen Bericht fest.

Wenn personenbezogene Daten betroffen sind

Liegen auf Ihrer Website Formulareingaben, Kundenkonten oder Bestelldaten, und könnten diese in falsche Hände geraten sein, ist das Thema nicht mehr rein technisch. Nach Art. 33 DSGVO muss der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der zuständigen Aufsichtsbehörde melden, in Deutschland in der Regel der Datenschutzbehörde Ihres Bundeslandes. Das entfällt nur, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten der Betroffenen führt. Bei hohem Risiko verlangt Art. 34 DSGVO zusätzlich, die Betroffenen zu benachrichtigen.

Jede Verletzung ist nach Art. 33 Abs. 5 DSGVO zu dokumentieren, auch wenn Sie sie nicht melden. Informationen dürfen schrittweise nachgereicht werden, wenn nicht alles sofort vorliegt. Verarbeitet eine Agentur oder ein Hoster Daten in Ihrem Auftrag, muss er Ihnen eine Verletzung unverzüglich melden; die Meldung an die Behörde bleibt Ihre Aufgabe. Unternehmen, die unter die deutsche NIS-2-Umsetzung fallen, haben seit dem 6. Dezember 2025 zusätzlich Meldepflichten gegenüber dem BSI: eine Erstmeldung binnen 24 Stunden, eine Folgemeldung binnen 72 Stunden und eine Abschlussmeldung spätestens nach einem Monat.

Was ein Wartungsvertrag regeln sollte

„Monatliche Wartung“ bedeutet bei jeder Agentur etwas anderes. Manche klicken nur auf den Update-Button, andere übernehmen auch Monitoring, Wiederherstellungstests und Notfallhilfe. Der Unterschied zeigt sich im Ernstfall. Lassen Sie sich diese Punkte schriftlich geben:

Die letzte Zeile wird oft übersehen und gehört zu den wichtigsten. Domain, Hosting und Admin-Konten sollten auf Ihren Namen laufen, nicht auf den der Agentur. Wenn sich die Wege trennen, bleiben die Schlüssel zu Ihrer Website bei Ihnen.

Wo fangen Sie an?

1. Listen Sie alle Konten rund um Ihre Website auf: Domain, DNS, Hosting, CMS-Administratoren, E-Mail, Search Console. Notieren Sie, auf wen sie laufen und ob die Zwei-Faktor-Authentifizierung aktiv ist.
2. Löschen Sie ungenutzte Plugins, Themes und Benutzerkonten.
3. Prüfen Sie bei den übrigen Plugins das letzte Update und den Status im Verzeichnis; ersetzen Sie verwaiste.
4. Finden Sie heraus, wo Ihre Backups liegen, und machen Sie diesen Monat einen Wiederherstellungstest.
5. Bestätigen Sie die Search Console und richten Sie eine Verfügbarkeitsüberwachung ein.
6. Legen Sie eine schriftliche Update-Richtlinie fest und schaffen Sie eine Staging-Umgebung.
7. Schreiben Sie einen kurzen Notfallplan für Datenpannen: wer entscheidet, wer die Rechtsberatung anruft, wer die Behörde informiert. Für eine erste Standortbestimmung eignet sich der CyberRisikoCheck nach DIN SPEC 27076, den das BSI für kleine Unternehmen mitentwickelt hat.
8. Vergleichen Sie Ihren Wartungsvertrag mit der Tabelle oben und lassen Sie fehlende Punkte schriftlich ergänzen.

Bei AYTE Digital richten wir die Website-Wartung an den Punkten dieser Tabelle aus, nicht nur bei selbst gebauten Websites: Wenn wir eine Seite übernehmen, prüfen wir zuerst den Ist-Zustand und legen gemeinsam mit Ihnen fest, welche Lücken zuerst geschlossen werden. Wenn wir uns Ihre Website ansehen sollen, genügt für den Anfang eine Liste der zugehörigen Konten.