„Das ist doch nur die Website" ist der Satz, der solche Fälle teuer macht. Er stimmt oft – und dann wieder nicht, und der Unterschied zeigt sich erst, wenn man nachsieht. Nach PHP2Shell stellt sich diese Frage für sehr viele Unternehmen gleichzeitig: Wenn jemand auf dem Webserver Code ausführen konnte, wie weit kommt er von dort?
Dieser Beitrag geht die üblichen Wege durch und sagt bei jedem, was ihn versperrt.
Was ein Angreifer auf dem Webserver zuerst findet
Der Webserver-Benutzer hat selten Administratorrechte. Was er hat, reicht trotzdem:
- Die Konfigurationsdateien der Website. Darin stehen die Zugangsdaten zur Datenbank im Klartext. Das ist kein Versäumnis, sondern notwendig – die Anwendung muss sich ja anmelden können.
- Die Datenbank selbst. Kundendaten, Bestellungen, Formularnachrichten, Benutzerkonten.
- Schlüssel für Schnittstellen. Zahlungsdienstleister, Mailversand, Warenwirtschaft, Newsletter-Dienst.
- Den Mailversand. Fast jede Website kann E-Mails verschicken – für Kontaktformulare, Bestellbestätigungen, Passwortrücksetzungen.
Das ist der Ausgangspunkt. Was daraus wird, hängt davon ab, wie Ihr Haus gebaut ist.
Weg 1: Über die E-Mail-Funktion
Der häufigste und am meisten unterschätzte. Wer den Webserver hat, kann über Ihre Domain Nachrichten verschicken – mit Ihrem Absender, durch Ihre SPF- und DKIM-Prüfung, an Ihre Kunden.
Für einen Angreifer ist das wertvoll, weil solche Nachrichten ankommen. Eine Rechnung mit geänderter Bankverbindung von Ihrer echten Adresse an einen echten Kunden ist etwas anderes als eine Phishing-Mail von einer Wegwerfadresse.
Wie so etwas abläuft und was es kostet, haben wir in einer Fallstudie zum Rechnungsbetrug aufgeschrieben – dort lief der Einstieg über eine andere Lücke, aber der Mechanismus ist derselbe.
Was es versperrt: Der Website-Mailversand sollte über ein eigenes Konto mit eigenem Schlüssel laufen, nicht über ein Postfach aus dem Haus. Dieses Konto darf nur versenden, nicht empfangen, und nur an die Adressen, die es braucht. Wird der Webserver übernommen, lässt sich dieser eine Zugang in Minuten sperren, ohne dass der Rest der Kommunikation steht.
Weg 2: Über wiederverwendete Zugangsdaten
Die Datenbank der Website enthält Benutzerkonten mit Passwörtern. Die sind heute in aller Regel verschlüsselt gespeichert – aber Menschen verwenden Passwörter mehrfach.
Interessanter sind die Zugänge, die unverschlüsselt dastehen müssen: der Datenbankzugang, der Zugang zur Warenwirtschaft über eine Schnittstelle, der Zugang zum Dateiablageort für Produktbilder.
Was es versperrt: Jeder dieser Zugänge sollte nur das dürfen, wofür er da ist. Der Datenbankbenutzer der Website braucht Lese- und Schreibrechte auf eine Datenbank – nicht auf alle. Der Schnittstellenzugang zur Warenwirtschaft braucht Artikel und Bestände – nicht die Kundenliste. Das kostet einmalig eine Stunde Nachdenken und begrenzt den Schaden dauerhaft.
Weg 3: Über die Netzverbindung
Hier entscheidet sich, ob aus einem Website-Vorfall ein Unternehmensvorfall wird.
Steht der Webserver bei einem Hoster und hat keine Verbindung in Ihr Haus, endet der Weg dort. Steht er im eigenen Serverraum oder hat eine Verbindung ins Firmennetz – für die Warenwirtschaft, für die Datensicherung, für die Fernwartung –, dann ist diese Verbindung der nächste Schritt.
Angreifer suchen dann nach dem, was von dort erreichbar ist: Dateifreigaben, Verwaltungsoberflächen, Druckserver, Kameras, alles mit einer Anmeldemaske.
Was es versperrt: Der Webserver gehört in ein eigenes Netzsegment, aus dem heraus nur das erreichbar ist, was er wirklich braucht – meist eine Datenbank und ein Mailausgang. Wie man das aufteilt, steht in Netzwerk-Segmentierung. Dass das kein Großprojekt sein muss, zeigt derselbe Beitrag.
Weg 4: Über die Sicherungen
Der unangenehmste Fall, weil er die Rettung selbst betrifft. Liegen die Sicherungen der Website auf demselben Server oder auf einem Speicher, auf den dieser Server schreiben darf, hat ein Angreifer sie mit übernommen.
Was es versperrt: Sicherungen gehören dorthin, wo der gesicherte Server nicht hinschreiben kann. Das ist der eine Satz, auf den sich das Thema zusammenziehen lässt.
Weg 5: Über die Menschen
Wer in Ihrer Website sitzt, liest Ihre Formularnachrichten mit – Anfragen, Bewerbungen, Supportmeldungen. Daraus lässt sich lernen, wer bei Ihnen wofür zuständig ist und wie Sie schreiben.
Diese Kenntnis ist die Grundlage für den nächsten Schritt: ein Anruf oder eine Nachricht, die glaubwürdig klingt, weil sie die richtigen Namen und den richtigen Ton trifft. Dazu: Helpdesk-Betrug und Deepfake-Anruf vom Chef.
Was es versperrt: Eine feste Regel für Zahlungsänderungen und Zugangsrücksetzungen, die nicht von der Glaubwürdigkeit des Anrufers abhängt, sondern vom Verfahren.
Die Frage, die Sie heute beantworten sollten
Nicht „sind wir gehackt worden", sondern:
> Wenn unser Webserver heute übernommen wäre – was wäre von dort aus erreichbar?
Diese Frage lässt sich ohne Vorfall beantworten, in einer Stunde, mit dem, was Sie ohnehin wissen. Und sie ist die Grundlage dafür, in welcher Reihenfolge Sie aufräumen.
Bei den meisten Unternehmen mit 10 bis 500 Arbeitsplätzen lautet die ehrliche Antwort: mehr als gedacht, aber weniger als befürchtet. Der Mailversand ist fast immer der erste Treffer, die Netzverbindung der entscheidende.
Checkliste: erste Schritte
- Klären, wo der Webserver steht und ob er eine Verbindung ins Firmennetz hat
- Auflisten, welche Zugangsdaten auf dem Webserver lesbar sind
- Prüfen, ob der Website-Mailversand über ein eigenes, eingeschränktes Konto läuft
- Rechte des Datenbankbenutzers auf das Nötige begrenzen
- Prüfen, ob die Sicherungen vom Webserver aus beschreibbar sind
- Festlegen, welche Dienste aus dem Webserver-Segment überhaupt erreichbar sein müssen
- Nach einem Vorfall: alle auf dem Server lesbaren Zugänge erneuern, nicht nur den offensichtlichen
- Regel für Zahlungsänderungen und Zugangsrücksetzungen schriftlich festhalten
Wie DAVINCI unterstützt
Wir sehen uns an, was von Ihrem Webserver aus erreichbar ist, trennen ihn sauber vom Rest und richten den Mailversand so ein, dass er im Ernstfall einzeln abschaltbar ist. Bei einem konkreten Verdacht übernimmt unser Incident Response die Aufarbeitung – einschließlich der Frage, ob jemand weitergekommen ist. Für eine schnelle erste Einschätzung gibt es den Quick-Check. Akut: IT-Notfall, rund um die Uhr.
Häufige Fragen
Unsere Website liegt bei einem Hoster. Sind wir damit sicher?
Sicherer, ja. Der Weg über die Netzverbindung entfällt in der Regel. Die Wege über Mailversand, Zugangsdaten und Formularnachrichten bleiben – die hängen nicht daran, wo der Server steht.
Woran erkennen wir, ob jemand von der Website aus weitergekommen ist?
An Spuren in den Systemen dahinter: Anmeldungen zu ungewöhnlichen Zeiten, Zugriffe auf Freigaben, die der Webserver sonst nie anfasst, ausgehende Verbindungen. Voraussetzung ist, dass diese Dinge protokolliert werden – zentral und außerhalb des betroffenen Systems. Das BSI behandelt das im Grundschutz-Baustein zur Protokollierung.
Müssen wir wirklich alle Zugänge tauschen?
Alle, die auf dem Webserver lesbar waren. Das sind typischerweise vier oder fünf, nicht hundert. Wer stattdessen nur den offensichtlichen tauscht, lässt die anderen offen.
Wie aufwendig ist eine Netztrennung?
Für einen einzelnen Webserver meist überschaubar: ein eigenes Segment, eine Regel, was heraus darf. Aufwendig wird es, wenn gewachsene Verbindungen bestehen, von denen niemand mehr weiß, wofür sie da sind – und genau die sind das eigentliche Risiko.
Wir haben keine Protokolle. Was heißt das?
Dass Sie für die Vergangenheit keine Aussage treffen können. Für die Zukunft lässt sich das in überschaubarer Zeit einrichten; aus unserer Praxis empfehlen wir mindestens zwölf Monate Aufbewahrung, zentral und manipulationsgeschützt. Das ist keine gesetzliche Frist, sondern das, was wir aus solchen Fällen ableiten.
Verwandte Themen: Wer hier weiterdenkt, liest bei PHP2Shell, KNX Secure und Incident Response weiter.
