Pyssly

Die RoboterSteckbrief des Diebs

Die Liste des Diebs

Jeden Tag fragen Programme bei Pyssly nach Dateien, die wir nie hatten: Passwörter, Quellcode und Backups. Hier ist die Liste, wie oft gefragt wurde, warum der Dieb die Dateien will und wie du deine eigene Seite schützt.

Ein Roboter aus Papier mit einem leeren Sack schleicht auf einen Aktenschrank zu.

Wer ist der Dieb?

Der Dieb ist meistens kein Mensch, der sucht. Es ist ein Programm, das mit derselben Liste von Seite zu Seite geht und nach jeder Datei fragt.

Antwortet eine Seite mit der Datei, hat der Dieb den Schlüssel, ohne irgendetwas aufzubrechen. Pyssly hat keine dieser Dateien, also bekommt der Dieb eine Scheinseite und wir zählen die Anfrage.

Hast du eine Homepage, eine Website oder einen Server: Sorge dafür, dass sich diese Dateien nicht abrufen lassen. Ganz unten steht, wie du das prüfst.

Am meisten gesucht

So oft haben Roboter bei Pyssly nach den Dateien gefragt.

Ich zähle …

Passwörter und Schlüssel

Der größte Schatz: eine einzige Datei mit allem, was die Seite aufschließt.

So schützt du dich

  • Lege Geheimnisse nie in den Ordner, den der Webserver zeigt. Lies sie stattdessen aus Umgebungsvariablen oder einem Geheimnis-Dienst (Secrets in Kubernetes, GitHub Actions oder der Cloud).
  • Sperre im Webserver alle Dateien und Ordner, die mit einem Punkt anfangen, außer /.well-known/. Wie das geht, steht weiter unten.
  • Lege nie einen privaten Schlüssel in den Webordner, und behalte deine eigenen Anmeldeschlüssel für dich, geschützt mit einer Passphrase.

Der Quellcode

Der ganze Code der Seite, mit jeder Änderung, die je gemacht wurde.

So schützt du dich

  • Lade den .git-Ordner nie hoch. Baue die Seite und schicke nur das Gebaute, oder halte den Ordner mit einer .dockerignore draußen.
  • Sperre Punkt-Ordner im Webserver als zusätzliche Sicherung.
  • Stand einmal ein Passwort im Code: Ändere es. Es in einer neuen Änderung zu löschen reicht nicht, denn in der Geschichte bleibt es erhalten.

Datenbanken und Backups

Kopien, die jemand kurz auf den Server gelegt und dann vergessen hat.

So schützt du dich

  • Speichere Backups außerhalb des Webordners, am besten auf einem anderen Rechner.
  • Sperre .sql, .bak, .zip und Ähnliches im Webserver.
  • Bearbeite Dateien nicht direkt auf dem Server: Editoren lassen Kopien wie .swp und ~ zurück.

WordPress

WordPress treibt einen großen Teil des Webs an, deshalb probiert der Dieb immer seine Türen aus, auch bei Seiten ohne WordPress, wie Pyssly.

So schützt du dich

  • Aktualisiere WordPress, Themes und Plugins, und lösche Plugins, die du nicht benutzt.
  • Schalte die Zwei-Faktor-Anmeldung ein und deaktiviere xmlrpc.php, wenn du sie nicht brauchst.
  • WordPress sucht wp-config.php auch einen Ordner über der Installation. Verschiebe sie nur dorthin, wenn dieser Ordner nicht selbst im Web zu sehen ist, und lass nie Kopien der Datei liegen.

Datenbank-Werkzeuge

Programme, mit denen man die Datenbank von einer Webseite aus verwalten kann.

So schützt du dich

  • Lege keine Datenbank-Werkzeuge auf die öffentliche Seite. Nutze sie auf deinem eigenen Computer und erreiche die Datenbank über einen SSH-Tunnel oder ein VPN.
  • Müssen sie sein: Sperre sie hinter einer zusätzlichen Anmeldung oder einer Liste erlaubter Adressen.

Fehlersuche-Seiten

Seiten, mit denen Entwickler in eine laufende Seite hineinschauen. Gut auf deinem eigenen Computer, gefährlich im Web.

So schützt du dich

  • Lasse eine Seite im Web nie im Debug-Modus laufen: APP_DEBUG=false, und keine Entwicklungsumgebung im Betrieb.
  • Entferne phpinfo-Dateien und Testwerkzeuge, bevor die Seite online geht (composer install --no-dev).
  • Beschränke den Zugriff auf Betriebsseiten wie Actuator und server-status auf deine eigene IP-Adresse oder ein internes Netz.

Alte Türen

Programme und Seiten, die der Server ausführt, wenn jemand danach fragt.

So schützt du dich

  • Entferne alles, was der Server nicht ausführen muss: alte Skripte, Testseiten und Ordner wie cgi-bin.
  • Ändere das Werkspasswort von Routern und Kameras, aktualisiere sie und zeige ihre Einstellungsseiten nie im Internet.
  • Lass nur ausführen, was ausgeführt werden soll: Eine hochgeladene Datei darf nie als Code laufen.

Shops und Phishing-Seiten

Zwei Arten von Suchen, die nicht gleich ein Einbruch sind, aber nah dran.

So schützt du dich

  • Was ein Shop allen zeigt, kann jeder lesen. Lege nichts Geheimes in Waren oder Produktfelder.
  • Siehst du auf deinem Server einen Ordner oder eine Datei, die du nicht kennst, wie lander/: Vielleicht ist jemand eingebrochen. Lösche sie, ändere alle Passwörter und aktualisiere alles.

Im Webserver sperren

Der beste Schutz ist, dass die Dateien nie auf dem Server liegen. Die Sperren hier sind eine zusätzliche Sicherung, falls doch etwas dort landet.

Alle lassen /.well-known/ offen, denn der Ordner wird zum Beispiel für Zertifikate gebraucht. Probiere es zuerst auf einer Testseite aus.

nginx Ganz oben im Server-Block der Seite. nginx nimmt die erste Regex-Regel, die passt, und eine location ^~ (zum Beispiel für /static/) überspringt sie ganz, also schreib dieselben Regeln auch dort hinein.
# First in the server block: nginx takes the first regex location that matches,
# and a location ^~ (such as /static/) skips them, so repeat these inside it.
# Dotfiles (.env, .git, .htaccess) at any depth, but not /.well-known/
location ~ /\.(?!well-known/) {
    return 404;
}
# Databases, backups and old copies
location ~* \.(sql|bak|old|orig|swp|zip|tar|gz|7z)$ {
    return 404;
}
Apache In den Einstellungen der Seite oder in .htaccess (Apache 2.4).
# Dotfiles (.env, .git, .htaccess) at any depth, but not /.well-known/
RedirectMatch 404 "/\.(?!well-known/)"
# Databases, backups and old copies
<FilesMatch "\.(sql|bak|old|orig|swp|zip|tar|gz|7z)$">
    Require all denied
</FilesMatch>
Caddy Im Block der Seite in der Caddyfile.
# Dotfiles (.env, .git, .htaccess) at any depth, but not /.well-known/
@hidden {
    path_regexp /\.
    not path_regexp ^/\.well-known/([^./][^/]*/?)*$
}
respond @hidden 404
# Databases, backups and old copies, /.well-known/ included
@copies path_regexp \.(sql|bak|old|orig|swp|zip|tar|gz|7z)$
respond @copies 404
.dockerignore Legt fest, was beim Bauen ins Image kommt, in allen Ordnern. Es gilt nicht für Dateien, die eingebunden werden, während der Container läuft, und ist keine Sperre in Traefik: Die Sperre gehört in die App oder den Webserver.
**/.git
**/.env*
**/*.sql
**/*.bak
**/*.zip
**/id_*
**/*.tfvars

So prüfst du es

Fünf Minuten in einem Terminal. Ersetze example.com durch deine eigene Adresse.

Prüfe nur deine eigene Seite. Nach den Dateien anderer zu suchen ist genau das, was der Dieb tut.

  1. Nach .env fragen

    curl -sS -i https://example.com/.env

    Schau dir die Antwort und den Inhalt an. 404 oder 403 ist gut. Kommen deine Einstellungen mit, ist die Datei öffentlich. (Antwortet die Seite auf alles mit 200, wie viele Apps, sollte der Inhalt deine normale Seite sein.)

  2. Nach .git fragen

    curl -sS -i https://example.com/.git/HEAD

    Siehst du eine Zeile wie ref: refs/heads/main, liegt der ganze Quellcode offen. Eine Fehlerseite oder deine normale Seite ist gut.

  3. Probiere es unter anderen Ordnern

    curl -sS -i https://example.com/static/.env

    Eine Sperre kann in Ordnern fehlen, die direkt ausgeliefert werden, wie /static/ oder /assets/. Probiere es dort, und probiere mehr Dateien aus der Liste, etwa eine .sql oder eine alte Kopie einer Einstellungsdatei. Es zählt, ob der Inhalt zu sehen ist.

  4. Schau ins Log

    grep -E '\.env|\.git/|wp-login|phpinfo|\.sql' /var/log/nginx/access.log

    Die Anfragen kommen jeden Tag, dass man sie sieht, ist also nichts Besonderes. Ein 200 im Log beweist noch kein Leck, denn viele Apps antworten mit 200 und ihrer normalen Seite. Siehst du 200 für .env oder .git/HEAD, ruf die Adresse wie oben ab und schau dir den Inhalt an.

Wenn eine Datei herauskam

  • Lösche die Datei und sperre die Adresse.
  • Ändere jedes Passwort und jeden Schlüssel, die darin standen: Datenbank, E-Mail, Bezahldienste und Cloud-Konto. Gehe davon aus, dass der Dieb sie schon hat.
  • Schau im Log nach, wer die Datei abgerufen hat und ob seitdem etwas mit den Konten passiert ist.

Mehr über Diebe und andere Arten von Robotern in So funktionieren die Roboter.