Websicherheit: Wie Websites gehackt werden und wie man es stoppt
Websites werden selten gehackt, weil jemand beschlossen hat, Ihr Unternehmen ins Visier zu nehmen. Sie werden gehackt, weil automatisierte Software rund um die Uhr das gesamte Internet nach Nachlässigkeiten durchsucht. Die gute Nachricht ist, dass die meisten Einbrüche durch ein Dutzend unauffälliger Gewohnheiten gestoppt werden, und die meisten von ihnen erfordern keinen Entwickler.
Warum selbst kleine Seiten angegriffen werden
Lassen Sie uns mit dem Glauben beginnen, den wir in fast jedem ersten Treffen hören: "Wer würde sich mit uns beschäftigen? Wir haben fünf Seiten und bekommen drei Anfragen pro Woche." Es klingt vernünftig. Es ist auch genau der Grund, warum solche Seiten am häufigsten kompromittiert werden.
Niemand hat dich ausgewählt. Die überwältigende Mehrheit der Angriffe auf kleine und mittelständische Unternehmen ist überhaupt nicht persönlich. Software erledigt die Arbeit: Sie nimmt Listen von Domains und IP-Adressen, geht sie einzeln durch und testet jede auf Dutzende bekannter Schwachstellen. Der Bot hat keine Ahnung, ob du eine Zahnarztpraxis oder ein Keramikstudio bist. Er liest eine Versionszeichenfolge in der Serverantwort, überprüft seine Liste und macht weiter, wenn es keinen Treffer gibt. Wenn es einen Treffer gibt, legt er los.
Es ist das Äquivalent dazu, die Türgriffe von Autos auf einer Straße zu ziehen. Niemand hat dein Auto ausgewählt. Deins war einfach nur nicht abgeschlossen.
Was eine Broschüren-Website überhaupt wert ist
Ein Angreifer möchte fast nie dir speziell schaden. Eine kompromittierte Website hat einen Marktwert, der aus mehreren Dingen gleichzeitig resultiert: speziell. Eine kompromittierte Seite hat einen Marktwert, und dieser ergibt sich aus mehreren Faktoren gleichzeitig:
- Versteckte Links oder ganze versteckte Abschnitte über Casinos, Kredite oder Apotheken werden heimlich in deine Seiten eingefügt. Du siehst sie nicht. Suchmaschinen schon. Versteckte Links oder ganze versteckte Abschnitte über Casinos, Kredite oder Apotheken werden heimlich in Ihre Seiten eingefügt. Sie sehen sie nicht. Suchmaschinen schon.
- Verkehr.Ihre Besucher werden woanders hingeleitet – aber nicht alle. Oft nur mobile Nutzer, nur diejenigen, die über die Suche kommen, und nur einmal pro Tag pro Person. Genau deshalb können Sie Ihre eigene Seite monatelang von Ihrem eigenen Laptop aus besuchen und nichts bemerken.
- Serverressourcen.Ihr Hosting wird zu einem Knotenpunkt für das Versenden von Spam, Mining oder Angriffe auf andere Seiten.
- Daten.Eine Datenbank mit Anfragen, Telefonnummern, Adressen und E-Mails ist ein Produkt mit Käufern. Selbst wenn Sie nur "ein Kontaktformular" haben.
- Erpressung.Dateien werden verschlüsselt oder gelöscht, und Sie werden eingeladen, für ihre Rückkehr zu zahlen.
Was zu der Schlussfolgerung führt, die das gesamte Thema anders erscheinen lässt: Websicherheit geht nicht darum, sich gegen einen Genie in einem Kapuzenpullover zu verteidigen. Es ist Hygiene, die Sie aus dem Pool der leichten Ziele herausbewegt. Ein Bot wird keine Zeit auf einer gut gepflegten Seite verbringen, während tausend vernachlässigte daneben sitzen.
Wie Eigentümer normalerweise erfahren
Die Symptome kommen fast nie von dir. Dein Host sendet E-Mails über verdächtige Aktivitäten. Google Search Console gibt eine Warnung aus. Ein Kunde ruft an und sagt, sein Browser schreit ihn an. Unternehmens-E-Mails landen plötzlich im Spam-Ordner von jedem. Der Suchverkehr sinkt ohne Erklärung. Wenn dir das passiert ist, hast du es zu spät erfahren – aber zu spät ist nicht dasselbe wie zu spät.
Wie Seiten tatsächlich kompromittiert werden
Vergiss die Filme. In Wirklichkeit lässt sich fast jeder Kompromiss bei kleinen Unternehmen auf eine kurze und bemerkenswert langweilige Liste zurückführen. Wir haben Dutzende von infizierten Seiten bereinigt, und der Einstiegspunkt war fast immer einer dieser.
Veraltetes CMS und Plugins vor allem
Das ist der klare Gewinner. WordPress, Joomla, OpenCart – die Plattformen selbst sind nicht von Natur aus undicht. Das Ökosystem ist das Problem: ein Galerie-Plugin, das zuletzt 2021 aktualisiert wurde, ein Theme, das auf einem Marktplatz gekauft wurde, dessen Autor vor Jahren aufgehört hat, ein Formularmodul, das ein Auftragnehmer installiert und vergessen hat.
Verstehe die Mechanik hier, denn sie ist kontraintuitiv. Wenn eine Schwachstelle in einem Plugin gefunden wird, wird sie veröffentlicht. So funktioniert die Branche, und das ist korrekt. Aber ab diesem Moment beginnt ein Wettlauf: Der Entwickler liefert einen Fix, und Scanning-Bots erhalten innerhalb von Stunden den Fingerabdruck der verwundbaren Version. Eine Seite, die einmal im Jahr aktualisiert wird, ist an diesem Wettlauf überhaupt nicht beteiligt.
Schwache Passwörter und noch schlimmer, wiederverwendete
Ein Passwort wie Admin2024! fühlt sich stark an – Großbuchstabe, Ziffern, ein Ausrufezeichen. Es ist in jedem Knack-Wörterbuch. Aber das ist nicht der eigentliche Schaden. Der eigentliche Schaden ist dasselbe Passwort auf deinem Hosting-Panel, deinem Seiten-Admin, deiner E-Mail und einem Dienst, der vor zwei Jahren gehackt wurde. Der Leak von jemand anderem wird zu deinem Login, und technisch gesehen passiert überhaupt kein "Hacking". Der Angreifer gibt einfach einen Benutzernamen und ein Passwort ein.
Anmeldeinformationen von einem Laptop des Personals gestohlen
Der klassische Fall, bei dem niemand Verdacht schöpft. FTP-Anmeldeinformationen, die in einem Dateimanager auf dem Laptop eines Designers gespeichert sind, werden von gewöhnlicher Malware ausgelesen. Die Seite wird durch einen legitimen Login "gehackt". Das verräterische Zeichen: Sie reinigen alles gründlich und die Infektion ist innerhalb von zwei Tagen zurück.
Ungeschützte Formulare und offene Endpunkte
Jeder Ort, an dem Ihre Seite Eingaben von außen akzeptiert — ein Kontaktformular, die Site-Suche, ein Datei-Upload, ein API-Endpunkt — ist eine Tür. Wenn Eingaben akzeptiert werden, ohne ihren Typ, ihre Größe und ihren Inhalt zu überprüfen, funktioniert die Tür in beide Richtungen. Datei-Uploads verdienen besondere Angst: Jemandem zu erlauben, etwas auf Ihrem Server abzulegen, das der Server später ausführt, bedeutet im Wesentlichen, die Schlüssel zu übergeben.
Dateien, die im Web-Stammverzeichnis liegen gelassen werden
Der stille Killer, und wir finden ihn ständig. Lebt im öffentlichen Ordner: backup.zip von der vorherigen Agentur, dump.sql mit der vollständigen Datenbank, ein .gitOrdner, der die gesamte Projektgeschichte mit Passwörtern in alten Commits enthält, ein test.php, ein info.php, eine Konfigurationskopie mit dem Namen config.php.bak. Jeder von diesen ist von jedem herunterladbar, der die URL errät. Und Bots raten nicht — sie haben Listen der üblichen Namen und überprüfen diese in Sekunden.
Ein Wort speziell über .bak und .alt Erweiterungen: Der Server führt diese nicht als Code aus, sondern liefert sie als einfachen Text. Das bedeutet, dass er dein Datenbankpasswort direkt an den Browser übergibt.
Vergessene und Verlassene Projekte
Eine alte Kampagnen-Landingpage auf einer Subdomain. Eine Staging-Kopie, die vor zwei Jahren erstellt und nie entfernt wurde. Ein Forum, das niemand nutzt. Sie werden nie aktualisiert, weil sich niemand daran erinnert, dass sie existieren. Und sie sitzen normalerweise im selben Hosting-Konto — das Kompromittieren einer vergessenen Landingpage übergibt die Dateien deiner Hauptseite. Wir beginnen jede Prüfung mit "Was lebt sonst noch in diesem Konto?", und die Antwort überrascht den Eigentümer regelmäßig mehr als jeden anderen.
HTTPS und SSL: Nicht länger zur Debatte
Wenn du kein HTTPS hast, hör auf zu lesen und behebe das zuerst. Im Jahr 2026 ist eine Seite ohne Verschlüsselung kein Schnäppchen. Es ist ein Fehler.
Was ein SSL-Zertifikat tatsächlich tut
Ohne HTTPS reisen Daten zwischen dem Browser deines Besuchers und deinem Server im Klartext. Jeder, der sich auf diesem Weg befindet, kann sie lesen und ändern: der Café-WLAN-Besitzer, ein ISP, Geräte in einem Zwischennetzwerk. Sie zu lesen bedeutet, Passwörter und Formularinhalte zu lesen. Sie zu ändern bedeutet, dass sie deine Seite umschreiben oder ihre eigenen Anzeigen darin einfügen können, und dein Besucher wird sich sicher sein, dass sie von dir stammen.
Ein SSL-Zertifikat löst zwei Probleme auf einmal. Es verschlüsselt den Kanal und beweist, dass die Domain demjenigen gehört, der sie bereitstellt. Das zweite ist genauso wichtig wie das erste: Ohne Identität ist Verschlüsselung sinnlos, denn du könntest einen Kanal zu einem Betrüger verschlüsseln.
Die Details, die wichtiger sind als das Zertifikat selbst
Zertifikate sind jetzt kostenlos und automatisch – Let's Encrypt hat diese Frage für alle geklärt. Die Fehler betreffen also nicht mehr "haben oder nicht haben". Sie liegen in der Konfiguration:
- Weiterleitungen. Jede HTTP-Anfrage muss dauerhaft auf HTTPS umgeleitet werden. Andernfalls läuft die alte Version einfach neben der neuen weiter.
- Gemischte Inhalte. Die Seite lädt über HTTPS, zieht aber ein Bild, eine Schriftart oder ein Skript über HTTP. Der Browser beschwert sich und das Schloss-Symbol verschwindet. Alte Analyse-Snippets und Widgets von Drittanbietern sind die üblichen Übeltäter.
- Automatische Verlängerung. Zertifikate haben eine kurze Lebensdauer und werden von einem Roboter erneuert. Wenn der Roboter ausfällt, erfahren Sie am schlimmsten möglichen Tag von den Kunden davon. Überwachen Sie das Ablaufdatum.
- Kanonische URLs. Stellen Sie nach dem Umstieg auf HTTPS sicher, dass jede Seite eine Adresse hat, anstatt vier Variationen mit und ohne www.
Was HTTPS nicht tut
Hier lebt ein gefährliches Missverständnis. Das Vorhängeschloss bedeutet nicht, dass die Seite sicher ist. Es bedeutet genau eines: Der Kanal zum Server ist verschlüsselt. Eine kompromittierte Seite voller bösartigem Code wird glücklich über HTTPS mit intaktem Vorhängeschloss bereitgestellt. Phishing-Seiten haben ebenfalls Zertifikate – sie werden kostenlos und automatisch an jeden ausgegeben. HTTPS ist ein Fundament, kein Dach.
Für Seiten, die mit Geld umgehen, ist die Messlatte viel höher. Die Kanalverschlüsselung ist das Eintrittsticket; danach kommen die Überprüfung der Webhook-Signatur, idempotente Operationen und strikte Trennung des Zugriffs. Wir haben diese Mechanismen im Detail durchlaufen, indem wir das Payora-Zahlungsgateway verwendet haben, wo die Transaktionssicherheit jede andere Funktion im Aufbau überragt.
Sicherheitsheader: Die stille Verteidigung, die niemand aktiviert
Sicherheitsheader sind Anweisungen, die Ihr Server zusammen mit der Seite an den Browser sendet. Der Punkt ist, dass Browser standardmäßig vertrauensvoll sind: Sie führen jedes Skript aus, das sie auf Ihrer Seite finden, und zeigen Ihre Seite in einem anderen Fenster an, wenn sie darum gebeten werden. Header sind, wie Sie dem Browser sagen, "mach das nicht mit mir."
Ihre große Tugend ist, dass sie kostenlos, einmal konfiguriert und auf der Seite des Besuchers durchgesetzt werden, ohne Ihren Server zu belasten. Ihr großes Problem ist, dass sie standardmäßig fast überall abwesend sind.
Content-Security-Policy (CSP)
Die mächtigste und die launischste. Es ist eine Erlaubenliste: von wo diese Seite Skripte, Stile, Bilder und Schriftarten laden darf. Wenn es einem Angreifer gelingt, ein fremdes Skript in Ihre Seite einzuschleusen, weigert sich der Browser einfach, es auszuführen, weil die Quelle nicht auf der Liste steht. Effektiv verwandelt CSP einen erfolgreichen Kompromiss in einen gescheiterten.
Eine ehrliche Warnung: CSP zu überstürzen wird Ihre Seite kaputt machen. Der richtige Weg ist zuerst der Nur-Bericht-Modus, sammeln Sie die Verstöße und ziehen Sie dann die Schrauben an. Bei einer Seite mit einem Dutzend Drittanbieter-Widgets sind das mehrere Tage Arbeit, nicht zehn Minuten.
Strict-Transport-Security (HSTS)
Sagt dem Browser: Diese Domain ist nur HTTPS, erinnere dich ein Jahr lang daran. Es schließt die Lücke zwischen jemandem, der eine Adresse ohne Präfix eingibt, und dem Auslösen der Weiterleitung. Diese Lücke ist genau der Ort, an dem Abfangen passiert. Aktivieren Sie es nur, wenn Sie sicher sind, dass HTTPS überall und dauerhaft funktioniert – die Entscheidung rückgängig zu machen, ist langsam.
X-Frame-Options
Verhindert, dass Ihre Seite in einem Frame auf der Seite eines anderen eingebettet wird. Es schützt vor einem einfachen, gemeinen Trick: einer unsichtbaren Schicht, die über Ihrem echten Button platziert ist, sodass der Klick des Benutzers irgendwohin geht, wo er nie beabsichtigt war. Für jede Seite mit einem Kundenkonto oder einem Checkout ist dies obligatorisch.
X-Content-Type-Options
Eine Zeile, keine Konfiguration. Es verbietet dem Browser, den Typ einer Datei zu erraten, im Gegensatz zu dem, was der Server erklärt hat. Ohne dies kann ein hochgeladenes Bild unter den richtigen Bedingungen als Skript interpretiert und ausgeführt werden.
Referrer-Policy
Steuert, welche Informationen über Ihre Seite der Browser weitergibt, wenn ein Besucher wegklickt. Ohne dies reist die vollständige Seiten-URL – einschließlich Parameter wie ein Passwort-Zurücksetzen-Token oder eine interne Kennung – in die Analysen eines anderen. Das ist kein Hack. Es ist ein Leck: leise und kontinuierlich.
Permissions-Policy
Schaltet aus, was Ihre Seite offensichtlich nicht benötigt: Kamera, Mikrofon, Geolokalisierung, Sensoren. Die Regel ist einfach – alles, was nicht genutzt wird, sollte ausgeschaltet sein.
Jeder öffentliche Online-Scanner bewertet Ihre Header in einer Minute, und das Ergebnis ist normalerweise ernüchternd. Für uns sind Header Teil des Grundaufbaus jedes Projekts – Teil der Entwicklung selbst, nicht ein kostenpflichtiges Extra, das später hinzugefügt wird.
Updates und Drittanbieter-Code: Disziplin über Heldentaten
Der Rat ist langweilig: Halten Sie die Dinge aktuell. Das Problem ist, dass es der eine Ratschlag ist, den jeder gehört hat und den fast niemand befolgt. Lassen Sie uns ansehen, warum – und wie man es durchhält.
Warum Updates aufgeschoben werden
Nicht Faulheit. Angst. Ein Update hat einmal das Layout zerstört, oder der Warenkorb hat aufgehört zu funktionieren, und der "Update"-Button wurde seitdem gemieden. Die Angst ist rational: Updates können tatsächlich Dinge kaputt machen, insbesondere wenn eine Seite aus Plugins zusammengesetzt ist, die direkt in ihrem Quellcode bearbeitet wurden.
Aber rechnen Sie nach. Das Risiko eines kaputten Layouts kostet Sie eine Stunde. Das Risiko eines Kompromisses kostet Sie eine Wiederherstellung, eine Bereinigung, unangenehme Gespräche mit Kunden und Monate, um die Suchrankings zurückzugewinnen. Das zweite Risiko ist um ein Vielfaches teurer.
Wie man ohne Panik aktualisiert
- Sichern Sie vorher, nicht danach.Vollständige Sicherung: Dateien und Datenbank. Überspringen Sie diesen Schritt niemals, ohne Ausnahmen.
- Behalten Sie eine Staging-Kopie.Eine separate Umgebung, die für Suchmaschinen und Außenstehende geschlossen ist, in der Updates getestet werden, bevor sie live gehen. Bei jedem ernsthaften Projekt ist dies nicht optional.
- Trennen Sie Kritisches von Routinemäßigem.Sicherheitsupdates werden sofort installiert. Kleinere werden nach einem Zeitplan durchgeführt. Größere Versionssprünge sind ein eigenes Projekt mit einem Plan.
- Überprüfen Sie die wichtigen Dinge danach.Ein Formular einreichen, eine Zahlung durchführen, sich in ein Konto einloggen, es auf einem Telefon ansehen. Drei Minuten manuelle Überprüfung sparen Wochen.
Überprüfung des Codes anderer Personen
Einmal im Quartal, öffnen Sie Ihre Plugin-Liste und stellen Sie zwei Fragen. Erstens: Wird dies überhaupt verwendet? Ein Plugin, das "nur für den Fall" installiert ist, ist ein Loch ohne Funktion. Und beachten Sie, dass ein deaktiviertes Plugin immer noch im Dateisystem sitzt und weiterhin anfällig sein kann – also müssen ungenutzte Dinge gelöscht und nicht abgeschaltet werden.
Zweitens: Ist der Autor noch am Leben? Wenn das letzte Update vor drei Jahren war und die Beschreibung sagt, dass es mit einer Version kompatibel ist, die längst veraltet ist, handelt es sich um veralteten Code. Er wird von selbst nicht sicherer. Finden Sie ruhig im Voraus einen Ersatz, anstatt in der Nacht nach einem Kompromiss.
Und die Regel, die es wert ist, an die Wand gehängt zu werden: Je weniger Drittanbieter-Code auf Ihrer Seite, desto kleiner ist Ihre Angriffsfläche. Jedes Plugin ist ein Fremder, dem Sie stillschweigend Zugang zu Ihrem Server gewährt haben.
Zugangs- und Hosting-Hygiene: Größere Gewinne als Code
Die häufigste reale Ursache für einen Kompromiss ist kein cleverer Exploit. Es ist verstreuter Zugang. Hier wird auch die Ordnung am schnellsten wiederhergestellt und das fast ohne Kosten.
Minimaler Zugriff
Jede Person und jeder Prozess sollte genau die Rechte haben, die für ihre Aufgabe erforderlich sind, und nicht einen Tropfen mehr. Ein Content-Manager benötigt keine Administratorrechte; er muss Artikel veröffentlichen. Ein Auftragnehmer, der eine Seite bearbeitet, benötigt nicht die Datenbank. Ein Skript, das einen Katalog liest, benötigt keinen Schreibzugriff.
Öffnen Sie jetzt Ihre Liste der Administratorkonten. Bei Prüfungen finden wir routinemäßig aktive Konten von Personen, die gegangen sind, von einer Agentur, mit der Sie vor einem Jahr getrennte Wege gegangen sind, und einem mysteriösen Benutzer namens admin2, den niemand erklären kann. Letzteres ist kein Versehen – es ist ein Symptom.
Ein Konto pro Person
Ein gemeinsames adminDie Anmeldung mit dem Passwort, das in einem Chatverlauf sitzt, bedeutet, dass niemand verantwortlich ist. Wenn etwas passiert, sagt das Protokoll "admin angemeldet", was dir genau nichts sagt. Einzelne Konten bieten dir zwei Dinge: eine lesbare Historie darüber, wer was getan hat, und die Möglichkeit, den Zugriff einer Person zu widerrufen, ohne die Passwörter für das gesamte Unternehmen zu ändern.
Zwei-Faktor-Authentifizierung
Wenn du genau einen Punkt aus diesem gesamten Artikel umsetzen möchtest, dann diesen. 2FA macht ein gestohlenes Passwort wertlos. Jeder Brute-Force-Versuch und jeder Drittanbieter-Verstoß funktioniert nicht mehr gegen dich, weil das Passwort allein nicht mehr ausreicht. Aktiviere es überall, wo es existiert: Hosting-Panel, Domain-Registrar, Site-Admin, E-Mail, Cloudflare, GitHub.
Ein besonderes Wort über den Domain-Registrar. Es ist der am meisten unterschätzte Ausfallpunkt im gesamten Stack. Die Kontrolle über deine Domain zu verlieren, ist schlimmer, als deine Website zu verlieren: Eine Website wird innerhalb einer Stunde aus einem Backup wiederhergestellt, während eine Domain über Monate hinweg Support-Tickets zurückkommt — wenn sie überhaupt zurückkommt.
SSH-Schlüssel statt Passwörter und kein FTP
Ein Passwort kann erraten oder von einem Laptop gestohlen werden. Ein Schlüssel kann in einem nützlichen Zeitrahmen nicht erraten werden. Die Einrichtung dauert einmal fünfzehn Minuten, danach wird die Passwortanmeldung zum Server vollständig deaktiviert.
Separat: Verwerfe einfaches FTP. Es sendet deinen Benutzernamen und dein Passwort im Klartext, als wäre es 1998. Verwende nur SFTP oder SSH. Wenn dein Host FTP als primäre Methode anbietet, sagt dir das etwas über den Host.
Ein Passwort-Manager statt Gedächtnis
Kein Mensch kann sich vierzig verschiedene komplexe Passwörter merken, weshalb sie sie genau wiederverwenden. Ein Passwortmanager beseitigt das Problem vollständig: Er generiert ein einzigartiges Passwort pro Dienst, speichert sie verschlüsselt und ermöglicht es Ihnen, Anmeldeinformationen an einen Kollegen weiterzugeben, ohne sie in einen Messenger einzufügen. Es kostet ein Taschengeld und verhindert eine Katastrophe.
Formulare, Spam und Ratenbegrenzung
Das Kontaktformular ist der zugänglichste Teil Ihrer Website. Es ist für jeden offen, funktioniert ohne Anmeldung und wartet darauf, mit Daten gefüllt zu werden. Kein Wunder, dass es am meisten missbraucht wird.
Warum CAPTCHA nicht die Antwort ist
CAPTCHA fängt primitive Skripte und nervt echte Menschen. Moderner Spam-Verkehr kommt entweder technisch daran vorbei oder über Lösungsdienste, bei denen echte Menschen CAPTCHAs für Bruchteile eines Cent lösen. In der Zwischenzeit schadet es messbar der Konversion: Einige echte Kunden geben einfach auf, wenn sie die verzerrten Buchstaben sehen, und verlassen die Seite.
Der Ansatz, der funktioniert, ist geschichtet und für den Besucher unsichtbar:
- Honeypot.Ein verstecktes Feld, das ein Mensch niemals sieht oder ausfüllt, und ein Bot füllt es automatisch aus. Ausgefüllt bedeutet verworfen. Einfach, kostenlos, effektiv gegen den Großteil davon.
- Zeitprüfungen.Ein Formular, das eine halbe Sekunde nach dem Laden der Seite abgeschickt wurde, wurde nicht von einer Person ausgefüllt.
- Ratenbegrenzung.Nicht mehr als ein paar Einsendungen von einer Adresse in einem bestimmten Zeitraum. Dies ist der Schlüsselmechanismus, und derselbe schützt Ihre Anmeldeseite vor Passwort-Ratenangriffen.
- Unsichtbare Bewertung.Moderne Systeme bewerten das Verhalten und fordern nur Anfragen heraus, die verdächtig erscheinen. Ein echter Kunde sieht überhaupt nichts.
Serverseitige Validierung ist nicht verhandelbar
Elegante Feldvalidierung im Browser ist eine Bequemlichkeit für die Benutzer, keine Verteidigung. Daten, die auf Ihrem Server ankommen, können gesendet werden, ohne jemals Ihre Seite zu berühren. Daher wird alles erneut serverseitig überprüft: Typ, Länge, Format, erlaubte Werte. Die Regel ist einfach und universell: Eingaben aus der Außenwelt sind niemals vertrauenswürdig, selbst wenn Ihr eigenes Skript es vor einem Moment validiert hat.
Datei-Uploads sind ein eigenes Problem
Wenn ein Besucher eine Datei hochladen kann, verhalten Sie sich so, als ob er etwas Feindliches hochlädt. Überprüfen Sie den tatsächlichen Inhaltstyp, nicht die Erweiterung im Namen. Benennen Sie die Datei selbst um. Begrenzen Sie die Größe. Und am wichtigsten, speichern Sie Uploads an einem Ort, an dem der Server physisch keinen Code ausführen kann – idealerweise auf einem völlig separaten Speicher.
Ratenbegrenzung geht über Formulare hinaus
Der gleiche Mechanismus gehört zu Ihren API-Endpunkten, der Site-Suche, der Passwortzurücksetzung und jeder teuren Operation. Ohne ihn bringt ein hartnäckiger Bot Ihren Server durch schiere Wiederholung zum Absturz. Es ist besonders wichtig, wenn Geld im Spiel ist: Bei Zahlungsprojekten begrenzen wir immer, wie schnell Transaktionen erstellt werden können — unser Artikel über die Akzeptanz von Krypto-Zahlungen erklärt, warum das Ihre Buchhaltung ebenso schützt wie Ihren Server.
Backups: Die eine Versicherungspolice, die immer auszahlt
Eindeutig: Backups sind wichtiger als alles andere in diesem Artikel. Jede andere Maßnahme senkt die Wahrscheinlichkeit einer Katastrophe. Backups entscheiden, wie die Katastrophe endet — ein unangenehmer Abend oder ein geschlossenes Geschäft.
Die 3-2-1 Regel
Ein Klassiker, der lange vor uns erfunden wurde und immer noch ungeschlagen ist:
- 3 Kopien Ihrer Daten: die aktuelle und zwei Backups.
- 2 verschiedene Medien oder Plattformen — nicht alles in einen Korb.
- 1 Kopie außerhalb des Standorts, physisch und administrativ vom Server getrennt.
Dieser letzte Punkt ist der, an dem die meisten Setups scheitern. Ein Backup, das sich auf demselben Server oder im selben Hosting-Konto befindet, ist kein Backup. Ein Angreifer, der eindringt, löscht es zuerst – das ist ein Standard-Schritt, kein Kunststück. Ransomware verschlüsselt es zusammen mit allem anderen. Und wenn der Host ausfällt, fällt es auch aus.
Ein ungetestetes Backup ist kein Backup
Hier ist der Teil, der schmerzt. Wir sehen immer wieder dasselbe Szenario: Backups liefen treu zwei Jahre lang, und am Tag, an dem es darauf ankommt, stellt sich heraus, dass die Archive beschädigt sind. Oder sie enthalten Dateien, aber keine Datenbank. Oder die Datenbank ist vorhanden, aber der Export hat die Kodierung durcheinandergebracht und der Text besteht aus Fragezeichen. Oder das Archiv ist 40 Kilobyte groß, weil das Skript im ersten Ordner abgestürzt ist und die Fehlermeldung an ein Postfach ging, das niemand liest.
Die Schlussfolgerung: Wiederherstellungen müssen geübt werden. Einmal im Quartal eine Kopie in einer Testumgebung bereitstellen und sich ansehen. Lädt die Seite? Ist die Datenbank vorhanden? Sind die Bilder vorhanden? Erscheinen die Bestellungen? Es ist der einzige Weg, die Wahrheit über Ihre Backups im Voraus zu erfahren, anstatt während einer Katastrophe.
Aufbewahrung schlägt Häufigkeit
Ein tägliches Backup mit einer Aufbewahrungsfrist von drei Tagen ist gegen eine stille Infektion nutzlos. Schadcode sitzt oft monatelang untätig. Bis du ihn findest, sind alle drei Kopien bereits infiziert. Halte die Tiefe: täglich für zwei Wochen, wöchentlich für ein paar Monate, monatlich für ein Jahr. Speicherplatz ist ungleich günstiger als eine Seite, von der es nichts wiederherzustellen gibt.
Was zu sichern ist
Dateien und Datenbank sind offensichtlich. Was oft vergessen wird, ist alles andere: Serverkonfiguration, Webserver-Regeln, geplante Aufgaben, DNS-Einstellungen, E-Mail. Ein guter Maßstab ist die Frage: "Wenn das Hosting-Unternehmen morgen verschwinden würde, wie lange würde ein vollständiger Neuaufbau woanders dauern?" Wenn du keine Antwort hast, ist dein Backup unvollständig.
Überwachung und Protokolle: Sehen Sie es, bevor Ihr Kunde es tut
Kompromisse sind selten laut. Viel häufiger sind sie still, und das ist der ganze Punkt: Je länger du es nicht bemerkst, desto länger verdient das Asset Geld für denjenigen, der es genommen hat. Daher besteht die Aufgabe der Überwachung nicht darin, einen Hacker zu "erwischen". Es geht darum, die Zeitspanne zwischen dem Ereignis und deinem Wissen darüber zu verkürzen.
Das Mindestset
- Uptime-Überwachung.Eine Verfügbarkeitsprüfung jede Minute mit einer Benachrichtigung. Grundlegende Dienste sind kostenlos und benötigen zehn Minuten zur Einrichtung.
- Dateiintegritätsüberwachung.Das System zeichnet den Zustand deiner Dateien auf und informiert dich, wenn sich etwas ändert. Niemand hat den Code berührt, und doch haben sich um 3 Uhr morgens zwei Dateien geändert – das ist ein Gespräch.
- SSL- und Domainablauf.Warnungen im Voraus, nicht danach. Eine vergessene Domainverlängerung schmerzt mehr als die meisten Hacks.
- Google Search Console.Kostenlos und verpflichtend. Suchmaschinen erkennen oft eine Infektion, bevor der Eigentümer es tut, und sie sagen es klar im Sicherheitsbereich.
- Externe Malware-Scans.Regelmäßige Überprüfungen von außen erfassen, was nur ein Besucher sieht: Weiterleitungen, injizierte Skripte, ausgetauschte Inhalte.
Protokolle: Langweilig, und wo die Wahrheit liegt
Webserver-Protokolle zeichnen jede Anfrage an Ihre Website auf. An einem ruhigen Tag möchte sie niemand. Am Tag eines Vorfalls sind sie Ihre einzige Quelle für Fakten: wann, von wo, was genau angefordert wurde und was der Server geantwortet hat.
Zwei Dinge sind es wert, im Voraus erledigt zu werden, da sie nicht rückgängig gemacht werden können. Erstens, bestätigen Sie, dass Protokolle tatsächlich geschrieben und mindestens einen Monat lang aufbewahrt werden. In vielen Setups werden sie nach 24 Stunden gekürzt, und es bleibt nichts übrig, um zu untersuchen. Zweitens, aktivieren Sie das Protokollieren von Admin-Logins — erfolgreich und fehlgeschlagen. Ein Anstieg der Fehlversuche ist ein Live-Passwort-Raten, und Sie können reagieren, bevor es erfolgreich ist.
Worauf man achten sollte
Man muss kein Analyst sein, um das Offensichtliche zu erkennen. Anfragen nach Dateien, die Sie nicht haben und nie hatten. Admin-Anfragen um 3 Uhr morgens aus einem Land, in dem Sie niemanden beschäftigen. Eine Adresse, die in einer Minute Hunderte von Anfragen stellt. Ein Anstieg von Fehlermeldungen, wo vorher keine waren. Keines dieser Dinge ist für sich genommen ein Beweis, aber jedes ist ein Grund, genauer hinzusehen.
Wir inkludieren Basisüberwachung in jedes Projekt, das wir nach dem Start unterstützen — Beispiele für diese Arbeit finden sich in unserem Portfolio. Die Lektion ist unglamourös: Eine Seite, die niemand beobachtet, wird schließlich eine Überraschung produzieren, und die Überraschung kostet immer mehr als die Beobachtung.
WAF und CDN: Was Cloudflare tut und was nicht
Cloudflare und ähnliche Dienste sind eine wirklich nützliche Schicht, weshalb so viel Mythologie sie umgibt. Lassen Sie uns ehrlich sein, wo der Wert liegt und wo die Illusion beginnt.
Was sie sind
Ein CDN platziert ein Netzwerk von Knoten weltweit zwischen Ihrem Besucher und Ihrem Server. Statische Dateien werden vom nächstgelegenen Knoten bereitgestellt — die Seite ist schneller und Ihr Server wird entlastet. Eine WAF (Webanwendungsfirewall) ist ein Filter, der eingehende Anfragen überprüft und angreifende Anfragen verwirft, bevor sie Ihren Code erreichen.
Der echte Wert
- DDoS absorbieren.Junk-Traffic bricht gegen das Netzwerk des Anbieters und nicht gegen Ihren Server. Ein kleines Unternehmen wird diesen Angriff nicht alleine überstehen.
- Verstecken Ihrer echten Server-IP.Direkte Angriffe werden schwieriger, wenn das Ziel nicht sichtbar ist.
- Bot-Filterung.Ein großer Teil des Scanning-Geräuschs wird automatisch herausgefiltert, und Ihre Protokolle werden über Nacht lesbar.
- Virtuelles Patchen.Eine WAF-Regel kann eine frische Schwachstelle vorübergehend schließen, während Sie ein richtiges Update vorbereiten. Das ist geliehene Zeit, kein Fix.
- Geschwindigkeit.Ein angenehmer Nebeneffekt, den sowohl Besucher als auch Suchmaschinen bemerken.
Was sie nicht tun werden
Jetzt der unangenehme Teil. Ein WAF wird Ihnen nicht helfen, wenn:
- Ihr Passwort gestohlen wurde. Ein Login mit gültigen Anmeldedaten ist eine legitime Anfrage. Der Filter lässt es durch, und das ist richtig.
- Ihr echte IP bereits bekannt ist und Ihr Server Verbindungen direkt akzeptiert, wodurch der Filter umgangen wird. Dies ist eine äußerst häufige Fehlkonfiguration: Ihr Server muss den Datenverkehr nur vom Netzwerk des Anbieters akzeptieren.
- Der Fehler liegt in Ihrer eigenen Geschäftslogik. Wenn Ihr Code es einem Benutzer erlaubt, die Bestellung eines anderen Benutzers abzurufen, indem er eine Zahl ändert, ist das aus Sicht des WAF eine vollkommen gut geformte Anfrage.
- Schadhafter Code ist bereits drin. Der Filter überwacht die Eingangstür, nicht was im Haus passiert.
- Die Verschlüsselung ist auf "flexibel". Dann reist das Bein von Cloudflare zu Ihrem Server im Klartext, während Ihr Besucher ein Schloss sieht und annimmt, dass alles in Ordnung ist. Das ist eine gefährliche Imitation von Sicherheit – verwenden Sie den strengen Modus mit Zertifikatsvalidierung.
Kurz gesagt: Ein WAF und CDN sind ein hervorragender Perimeterzaun. Ein Zaun ist nutzlos, wenn der Schlüssel unter der Matte liegt und ein Fenster im Erdgeschoss offen ist. Es ergänzt die Hygiene. Es ersetzt sie nicht.
Was zu tun ist, wenn Sie bereits kompromittiert sind
Bleiben Sie ruhig. Panik kostet mehr als der Hack selbst: In einer Panik löschen die Menschen genau die Dinge, die eine Untersuchung benötigt. Das Verfahren ist gut etabliert. Befolgen Sie es.
1. Isolieren
Setzen Sie die Website hinter eine Wartungsseite, die einen 503-Status zurückgibt. Das schützt Besucher vor Infektionen und teilt Suchmaschinen mit, dass die Ausfallzeit vorübergehend und nicht endgültig ist. Löschen Sie noch nichts.
2. Bewahren Sie die Beweise
Gegensätzlich, aber entscheidend. Machen Sie eine vollständige Kopie der infizierten Website sowie der letzten Monat der Protokolle vor jeglicher Bereinigung. Wenn Sie aus einem Backup wiederherstellen, ohne den Einstiegspunkt zu identifizieren, werden Sie auf die gleiche Weise erneut kompromittiert, normalerweise innerhalb einer Woche. Diese Kopie ist Ihre einzige Chance zu verstehen, wie sie eingedrungen sind.
3. Rotieren Sie jede Anmeldeinformation
Alle, ohne Ausnahmen, kein "das eine konnte definitiv nicht geleakt sein". Hosting, SSH, Datenbank, jeder Admin-Benutzer, FTP, Domain-Registrar, E-Mail, verbundene Dienste. Aktivieren Sie 2FA überall dort, wo es fehlte, während Sie dort sind. Eine Warnung, die viele übersehen: Machen Sie dies von einem sauberen Computer aus. Wenn der Laptop infiziert ist, lecken Ihre neuen Passwörter genau wie die alten.
4. Finden Sie den Einstiegspunkt
Beginnen Sie mit Dateien, die am Tag der Infektion geändert wurden – die schnellste Spur, die es gibt. Durchsuchen Sie die Protokolle nach der Anfrage, die kurz bevor die erste fremde Datei erschien, einging. Überprüfen Sie alles im Hosting-Konto, einschließlich vergessener Subdomains. Überprüfen Sie die Computer aller mit Zugang. Bis der Einstiegspunkt gefunden ist, ist der Vorfall nicht abgeschlossen.
5. Wiederherstellen
Der beste Weg ist eine saubere Neuinstallation: frisches CMS, frische Plugins aus offiziellen Quellen und nur Ihre Inhalte und Datenbank aus dem Backup — wobei die Datenbank zuerst überprüft werden sollte, da dort ebenfalls Code injiziert wird, normalerweise in Vorlagen und Einstellungen. Manuelles Reinigen infizierter Dateien ist ein Glücksspiel: Verpassen Sie eine einzige Datei und das Ganze kommt zurück.
6. Schließen Sie die Lücke und stellen Sie Ihren Ruf wieder her
Beheben Sie die Ursache, die Sie identifiziert haben, oder Sie haben einfach die Uhr zurückgesetzt. Dann: Fordern Sie eine Überprüfung in der Google Search Console an, überprüfen Sie die Mail-Daten Ihres Domains (eine kompromittierte Seite hat wahrscheinlich Spam versendet, und Ihre Domain könnte bereits auf Blocklisten stehen), und bestätigen Sie, dass keine unbekannten Administratoren mehr in der Datenbank vorhanden sind.
Eine ehrliche Anmerkung: Wenn Ihre Seite Zahlungen entgegennimmt oder persönliche Daten von Kunden speichert, ist Improvisation der falsche Weg. Sie wollen jemanden, der das schon einmal gemacht hat — nehmen Sie Kontakt auf. Wir bearbeiten Vorfälle wie diese, und noch wichtiger, wir erklären danach genau, was schiefgelaufen ist und wie man sicherstellt, dass es nicht wieder vorkommt.
Eine praktische Sicherheitscheckliste
Lassen Sie uns alles oben in eine Liste komprimieren, mit der Sie heute beginnen können. Sie ist nach Effekt im Verhältnis zum Aufwand geordnet — beginnen Sie oben.
Heute, an einem Abend
- Aktivieren Sie 2FA für Hosting, Ihren Domain-Registrar, E-Mail und den Site-Admin.
- Überprüfen Sie HTTPS funktioniert überall und alle HTTP-Weiterleitungen dorthin.
- Öffnen Sie Ihre Benutzerliste und entfernen Sie alle, die dort nicht sein sollten: ehemalige Mitarbeiter, alte Auftragnehmer, Konten, die niemand erkennt.
- Überprüfen Sie das Web-Stammverzeichnis auf verirrte Dateien: Archive, Datenbank-Dumps, ein .git Ordner, Konfigurationskopien, Testskripte.
- Bestätigen dass Backups existieren und nicht auf demselben Server gespeichert sind.
- Verbinden Sie die Seite mit Google Search Console und lesen Sie den Sicherheitsbereich.
Diese Woche
- Richten Sie einen Passwortmanager ein und ersetzen Sie jedes wiederverwendete Passwort durch ein einzigartiges.
- Aktualisieren Sie das CMS und alle Plugins, nachdem Sie ein vollständiges Backup erstellt haben.
- Löschen Sie nicht verwendete Plugins und Themes — löschen, nicht deaktivieren.
- Konfigurieren Sie Sicherheitsheader: Beginnen Sie mit X-Content-Type-Options, X-Frame-Options und Referrer-Policy, die sofort aktiviert werden können.
- Deaktivieren Sie FTP und wechseln Sie zu SSH-Schlüsseln.
- Fügen Sie Uptime-Überwachung und Warnungen für SSL- und Domainablauf hinzu.
- Begrenzen Sie Anmeldeversucheim Admin-Panel.
Diesen Monat
- Testen Sie eine Wiederherstellungin einer Staging-Umgebung — setzen Sie es tatsächlich ein und sehen Sie es sich an.
- Setzen Sie ein CDN und WAFdavor und schließen Sie den direkten Zugriff auf den Server, damit nichts den Filter umgeht.
- Führen Sie CSP, beginnend im Nur-Bericht-Modus.
- Alles im Hosting-Konto überprüfen: Subdomains, Staging-Kopien, vergessene Landing-Pages. Löschen, was nicht benötigt wird.
- Einrichten von Dateiintegritätsüberwachung.
- Überprüfen von Datei- und Ordnerberechtigungen, Schreibzugriff entfernen, wo er nicht erforderlich ist.
Wiederholen, damit Sie diesen Artikel nie wieder benötigen
- Wöchentlich: Sicherheitsupdates, ein Blick auf das Anmeldeprotokoll.
- Monatlich:Backups überprüfen, Benutzer überprüfen, Protokolle durchsehen.
- Vierteljährlich:Wiederherstellung testen, Plugins prüfen, Schlüsselpasswörter rotieren.
- Jährlich:vollständige Prüfung, überdenken, wer Zugang hat und warum.
Ein letzter Gedanke, den Sie mitnehmen sollten. Sicherheit ist kein Zustand, den man erreicht und vergisst; es ist eine Gewohnheit, wie das Abschließen der Bürotür. Niemand kann absolute Sicherheit garantieren, und jeder, der es verspricht, führt Sie in die Irre. Aber der Unterschied zwischen einer Seite, auf der diese Liste abgearbeitet wird, und einer Seite, auf der nichts davon gemacht wird, ist der Unterschied zwischen "jemand hat es versucht und ist gescheitert" und "wir sind in Woche drei der Wiederherstellung unserer Daten".
Häufig gestellte Fragen
Meine Seite ist klein – wer würde sich überhaupt darum kümmern?
Genau das ist der Punkt: niemand im Besonderen. Sie werden nicht ausgewählt, sondern von automatisierten Scannern gefunden, die das gesamte Internet nach bekannten Schwachstellen durchsuchen. Ein Bot interessiert sich nicht dafür, ob Sie fünf Seiten oder fünftausend haben: Eine kompromittierte Broschürenseite funktioniert genauso gut für versteckte Links, um Besucher umzuleiten, Spam zu versenden und andere Ziele anzugreifen. Klein zu sein macht Sie nicht unsichtbar. Es macht Sie bequem, denn kleine Seiten haben normalerweise keine Updates, keine Überwachung und keine Backups.
Ist ein SSL-Zertifikat ausreichend, um meine Website zu sichern?
Nein, und das ist das am weitesten verbreitete Missverständnis in diesem Bereich. SSL verschlüsselt den Kanal zwischen Browser und Server, schützt Daten während der Übertragung und beweist, dass die Domain Ihnen gehört. Es hat keinerlei Einfluss darauf, was auf dem Server selbst passiert. Eine kompromittierte Seite voller bösartigem Code funktioniert perfekt über HTTPS mit dem Schloss-Symbol. Phishing-Seiten haben ebenfalls Zertifikate. HTTPS ist obligatorisch, aber es ist eine Grundlage, kein vollständiger Schutz: ohne Updates, solide Zugriffskontrolle und Backups erreicht es nichts.
Wie oft sollte ich Backups erstellen und wo sollten sie gespeichert werden?
Konzentrieren Sie sich auf eine Frage: Wie viele Daten können Sie sich leisten zu verlieren? Eine Broschürenseite, die sich monatlich ändert, ist mit wöchentlichen Backups in Ordnung. Ein Online-Shop, der Bestellungen entgegennimmt, benötigt mindestens täglich, idealerweise häufiger. Der Speicher muss außerhalb des Hauptservers sein — eine Kopie auf demselben Hosting übersteht weder einen Kompromiss noch einen Plattformausfall. Und behalten Sie die Aufbewahrungsdauer im Auge: täglich für zwei Wochen, wöchentlich für ein paar Monate, monatlich für ein Jahr, da Infektionen oft Wochen nach ihrem Beginn entdeckt werden.
Was sind Sicherheitsheader und brauche ich sie wirklich?
Das sind Anweisungen, die Ihr Server mit jeder Seite an den Browser sendet: welche Skripte ausgeführt werden dürfen (CSP), ob HTTPS obligatorisch ist (HSTS), ob die Seite in den Rahmen eines anderen eingebettet werden kann (X-Frame-Options) und welche Informationen bei ausgehenden Klicks übertragen werden (Referrer-Policy). Sie sind kostenlos, einmal konfiguriert und erfordern keine Änderungen am Code Ihrer Seite. Mehrere von ihnen — X-Content-Type-Options, X-Frame-Options, Referrer-Policy — können in fünf Minuten ohne Risiko aktiviert werden. CSP ist das mächtigste, benötigt aber eine sorgfältige Einführung über den Nur-Bericht-Modus.
Wird Cloudflare meine Seite vor Hacks schützen?
Teilweise. Cloudflare absorbiert DDoS-Angriffe gut, verbirgt Ihre echte Server-IP, filtert enorme Mengen von Scanning-Bots und kann vorübergehend eine frische Schwachstelle mit einer WAF-Regel schließen. Aber es ist machtlos, wenn Ihr Passwort gestohlen wurde – ein Login mit korrekten Anmeldedaten sieht aus wie eine gewöhnliche legitime Anfrage. Es hilft nicht, wenn Ihre echte IP bekannt ist und Ihr Server Verbindungen akzeptiert, die den Filter umgehen. Und es kann keinen Fehler in Ihrer eigenen Geschäftslogik erkennen. Es ist ein Perimeterzaun, und ein Zaun ersetzt kein Schloss an der Tür.
Wir wurden gehackt – kann ich einfach aus dem Backup wiederherstellen?
Sie können, aber nur das zu tun, führt fast immer innerhalb einer Woche zu einem zweiten Kompromiss. Eine Wiederherstellung bringt die Seite zurück; sie entfernt nicht die Ursache. Wenn sie über ein anfälliges Plugin eingedrungen sind, kehrt dasselbe Plugin mit dem Backup zurück. Die richtige Reihenfolge: die Seite isolieren, eine Kopie der infizierten Version und die Protokolle zur Untersuchung aufbewahren, alle Anmeldedaten von einem sauberen Computer rotieren, den Einstiegspunkt finden und erst dann neu aufbauen – idealerweise eine saubere Neuinstallation des CMS und der Plugins, wobei nur Inhalte und eine verifizierte Datenbank aus dem Backup übernommen werden.