Auch kleine Websites sind Angriffs-Ziele

Der Schock: Mein Postfach voll mit fremden Mails

Es war ein ganz normaler Morgen. Ich öffnete mein Zoho-Postfach und wurde mit Dutzenden verdächtiger E-Mails überschwemmt:

• Bounce-Mails von mailer-daemon@mail.zoho.eu mit dem Betreff „Undelivered Mail Returned to Sender“
• Drängende Nachrichten auf Französisch: „URGENT: Risque de suspension immédiate pour [Domain]“ oder „Renouvellement de [Domain] en attente“

Mein erster Gedanke: „Das ist doch nur Backscatter-Spam! Jemand fälscht meine Absenderadresse, und die Bounces landen bei mir.“ Falsch gedacht.

Plötzlich explodierte der E-Mail-Verkehr auf der einen Absendeadresse aber nicht durch legitime Nachrichten.

À tous ceux qui ont reçu des messages de spam de mon domaine pendant cette période : Je suis sincèrement désolé. Le fait que mon site ait été utilisé à ces fins n’était absolument pas mon intention et j’ai tout fait pour régler ce problème au plus vite et renforcer la sécurité.

An alle, die in dieser Zeit Spam-Nachrichten von meiner Domain erhalten haben: Es tut mir leid. Dass meine Website für solche Aktivitäten missbraucht wurde, war nicht in meinem Sinne. Ich habe alles unternommen, um den Vorfall schnellstmöglich zu beheben und die Sicherheit zu erhöhen.

Die unangenehme Wahrheit: Ich war selbst schuld

Nach einigem Suchen fand ich im Zoho-Anmeldeprotokoll einen verdächtigen Eintrag:

Jemand hatte sich mit meinen SMTP-Zugangsdaten angemeldet und verschickte Mails in meinem Namen!

Der Beweis: Ein Login aus Marokko, den ich nicht war.

Dank der Zoho-Konfiguration, die alle gesendeten Mails im Postausgang speichert, konnte ich später sehen, dass der Angreifer Dutzende Spam-Mails in meinem Namen verschickt hatte. Und zwar an Adressen, die ich nicht kannte. Ein weiterer Beweis, dass es kein reines Spoofing war, sondern ein aktiver Missbrauch meiner SMTP-Zugangsdaten.

Noch deutlicher wurde der Missbrauch durch eine Testnachricht im Postausgang: Der Angreifer hatte nicht nur Zugriff, sondern testete die SMTP-Verbindung aktiv. Mit meiner Domain, dem kompromittierten Passwort und sogar einem „SMTP Working!“-Hinweis an eine gmail-Adresse(!). Ein klarer Beleg für den aktiven Versand von Mails in meinem Namen.

Wie war das möglich?

Ich hatte Zwei-Faktor-Authentifizierung (2FA) aktiviert, aber der Angreifer nutzte ein App-spezifisches Passwort (das 2FA umgeht, um z. B. SMTP-Clients zu ermöglichen). Und dieses Passwort lag offen im Web.

Mein Fehler: Die Datei .env war öffentlich abrufbar und enthielt die SMTP-Zugangsdaten. Warum?

• Bei vielen Hosting-Setups liegt das Projektverzeichnis direkt im Webroot (z. B. /public_html/).
• Apache und Nginx liefern .env-Dateien standardmäßig aus, wenn keine explizite Regel sie blockiert.
• Automatisierte Scanner prüfen Millionen Domains nach solchen Dateien und ich war eine davon.

Ja, ich gebe es zu: Das war schlampig. Aber ich bin nicht der Einzige. Viele denken: „Meine kleine Seite hat kaum Traffic, wer sollte mich angreifen?“

Falsch.

• Botnets scannen alles, egal ob Großkonzern oder Privatblog.
• Gefundene Schwachstellen werden ausgenutzt, selbst wenn die Seite „unwichtig“ scheint.
• Die Folgen (Spam, Blacklisting, Reputationsverlust) treffen jeden und sind schmerzhaft zu bereinigen.

Sofortmaßnahmen: Wie ich den Schaden begrenzt habe

1. App-Passwort sofort gesperrt & neu generiert

Das kompromittierte Zugang wurde gelöscht, ein neuer erstellt und in der Kontaktformular-Konfiguration aktualisiert. Innerhalb von Sekunden beruhigte sich der Postausgang.

2. Die .env-Datei: Vom Risiko zur sicheren Konfiguration

Mein erster Versuch: Die Datei in .php umbenennen. Schlechte Idee!

• Ohne <?php ?>-Tags wird der Inhalt trotzdem als Klartext ausgegeben.
• Korrekte Lösung:
  • Datei mit echten PHP-Code (<?php return [...];)** umgewandelt.
  • In ein Unterverzeichnis verschoben und umbenannt.
  • Alte URL liefert jetzt 404 und das Kontaktformular funktioniert weiter.

3. E-Mail-Authentifizierung: SPF, DKIM & DMARC

Ohne diese Mechanismen können fremde Server Mails in deinem Namen verschicken und genau das war passiert.

Warum DMARC so wichtig ist:

• p=none = „Beobachte nur“ (kein Schutz).
• p=quarantine = „Verdächtige Mails in den Spam-Ordner“ (mein aktueller Zustand).
• p=reject = „Blockiere gefälschte Mails komplett“ (Zielzustand nach Beobachtungsphase).

So sahen die Mails aus, die ich plötzlich erhielt. Alles Folgen des missbrauchten SMTP-Zugangs.

Lehren für dich: So schützt du deine Website

Checkliste für sofortige Maßnahmen

• .env-Dateien nie im Webroot ablegen oder zumindest per .htaccess blockieren:
  <FilesMatch "^\."> Require all denied </FilesMatch>
• App-Passwörter wie Hauptpasswörter behandeln, sie umgehen 2FA!
• SPF, DKIM & DMARC prüfen (z. B. mit MXToolbox oder DMARCian).
  • SPF: Maximal 10 DNS-Lookups (sonst PermError!).
  • DMARC: Starte mit p=none, dann p=quarantine, dann p=reject.
• Directory Listing deaktivieren (verhindert das Auflisten von Verzeichnissen).
• .git/ und andere sensible Verzeichnisse schützen (gleiche Gefahr wie .env!).

Langfristige Empfehlungen

• Secrets außerhalb des Webroots speichern (z. B. in /var/secure/ oder Umweltvariablen des Servers).
• Regelmäßig Serverlogs prüfen (wer hat auf .env oder .git/config zugegriffen?).
• E-Mail-Authentifizierung alle 6 Monate überprüfen (DKIM-Keys rotieren, SPF aktualisieren).

Warum auch kleine Seiten Ziele sind

Ich dachte immer: „Meine Website hat kaum Besucher, wer sollte mich angreifen?“ Das ist ein gefährlicher Irrtum.

1. Automatisierte Angriffe
   Botnets scannen das gesamte Internet nach Schwachstellen, egal ob Großkonzern oder Privatblog.
   Jede gefundene Lücke wird ausgenutzt, selbst wenn die Seite „uninteressant“ scheint.
2. Die Folgen treffen jeden
   Spam-Versand in deinem Namen → Deine Domain landet auf Blacklists.
   Bounces fluten dein Postfach → Du verlierst den Überblick über echte Mails.
   Reputationsverlust → E-Mail-Anbieter wie Gmail oder Outlook blockieren deine Mails.
3. „Schlampig“ wird bestraft
   Ich habe gelernt: Auch kleine Projekte verdienen professionelle Sicherheit.
   Ein einziger Fehler (wie eine öffentliche .env) kann stundenlange Aufräumarbeit bedeuten.

Fazit: Sicherheit ist kein Luxus sondern Pflicht

Dieser Vorfall hat mich demütig gemacht. Ich dachte, ich hätte alles richtig gemacht bis ich merkte, wie einfach es war, meine Daten zu kompromittieren.

Die gute Nachricht: Mit ein paar einfachen Maßnahmen (SPF/DKIM/DMARC, sichere Secrets) kann jeder seine Website schützen auch ohne IT-Profi zu sein.

Die schlechte Nachricht: Wenn du jetzt denkst „Bei mir passiert das nicht“: Ich lag damit falsch und du auch.

Handle jetzt: Prüfe deine Website mit den oben genannten Tools und schließe die offensichtlichen Lücken. Bevor es jemand anderes tut.

Was sind deine Erfahrungen mit Sicherheitsvorfällen? Hast du ähnliche Fehler gemacht oder Tipps für andere Leser?