Pyssly

RobotarnaTjuvens eget kort

Tjuvens lista

Varje dag frågar program Pyssly efter filer vi aldrig haft: lösenord, källkod och säkerhetskopior. Här är listan, hur många gånger de frågat, varför tjuven vill ha filerna och hur du skyddar din egen sajt.

En robot i papper med en tom säck smyger mot ett arkivskåp.

Vem är tjuven?

Tjuven är oftast ingen människa som sitter och letar. Det är ett program som går från sajt till sajt med samma lista och frågar efter varje fil på den.

Svarar en sajt med filen har tjuven fått nyckeln, utan att bryta upp något alls. Pyssly har inga av filerna, så tjuven får en låtsassida och vi räknar frågan.

Har du en hemsida, en sajt eller en server: se till att de här filerna inte går att hämta. Längst ner står hur du kollar.

Mest eftersökt

Så många gånger har robotar frågat Pyssly efter filerna.

Räknar …

Lösenord och nycklar

Den största skatten: en enda fil med allt som låser upp sajten.

Så skyddar du dig

  • Lägg aldrig hemligheter i mappen som webbservern visar upp. Läs dem från miljövariabler eller en hemlighetstjänst (secrets i Kubernetes, GitHub Actions eller molnet) i stället.
  • Spärra alla filer och mappar som börjar med punkt i webbservern, utom /.well-known/. Hur står längre ner.
  • Lägg aldrig en privat nyckel i webbmappen, och håll dina egna inloggningsnycklar för dig själv, skyddade med en lösenfras.

Källkoden

Hela sajtens kod, med varje ändring som någonsin gjorts.

Så skyddar du dig

  • Ladda aldrig upp .git-mappen. Bygg sajten och skicka bara det byggda, eller håll mappen utanför med en .dockerignore.
  • Spärra punktmappar i webbservern som en extra säkring.
  • Har ett lösenord någon gång legat i koden: byt det. Att ta bort det i en ny ändring räcker inte, det finns kvar i historien.

Databaser och säkerhetskopior

Kopior som någon lade på servern för en stund och sedan glömde.

Så skyddar du dig

  • Spara säkerhetskopior utanför webbmappen, helst på en annan maskin.
  • Spärra .sql, .bak, .zip och liknande i webbservern.
  • Redigera inte filer direkt på servern: editorer lämnar kopior som .swp och ~ efter sig.

WordPress

WordPress driver en stor del av webben, så tjuven provar alltid dess dörrar, också hos sajter som inte har WordPress, som Pyssly.

Så skyddar du dig

  • Uppdatera WordPress, teman och tillägg, och ta bort tillägg du inte använder.
  • Slå på tvåstegsinloggning, och stäng av xmlrpc.php om du inte behöver det.
  • WordPress letar också efter wp-config.php en mapp ovanför installationen. Flytta den dit bara om den mappen inte själv visas på webben, och lämna aldrig kopior av filen.

Databasverktyg

Program som låter en sköta databasen från en webbsida.

Så skyddar du dig

  • Lägg inte databasverktyg på den publika sajten. Kör dem på din egen dator och nå databasen genom en SSH-tunnel eller ett VPN.
  • Måste de finnas: lås dem bakom en extra inloggning eller en lista med tillåtna adresser.

Felsökningssidor

Sidor som utvecklare använder för att se in i en sajt medan den körs. Bra på din egen dator, farliga på webben.

Så skyddar du dig

  • Kör aldrig en sajt i felsökningsläge på webben: APP_DEBUG=false, och ingen utvecklingsmiljö i drift.
  • Ta bort phpinfo-filer och testverktyg innan sajten går live (composer install --no-dev).
  • Lås driftsidor som Actuator och server-status till din egen adress eller ett internt nät.

Gamla dörrar

Program och sidor som servern kör när någon frågar efter dem.

Så skyddar du dig

  • Ta bort allt servern inte behöver köra: gamla skript, testsidor och mappar som cgi-bin.
  • Byt fabrikens lösenord på routrar och kameror, uppdatera dem, och visa aldrig deras inställningssidor mot internet.
  • Låt bara köras det som ska köras: en uppladdad fil ska aldrig kunna köras som kod.

Butiker och fiskesajter

Två sorters letande som inte är ett inbrott på en gång, men nära.

Så skyddar du dig

  • Det en butik visar för alla kan alla läsa. Lägg inget hemligt i varor eller produktfält.
  • Ser du en mapp eller fil du inte känner igen på din server, som lander/: någon kan ha brutit sig in. Ta bort den, byt alla lösenord och uppdatera allt.

Spärra i webbservern

Det bästa skyddet är att filerna aldrig finns på servern. Spärrarna här är en extra säkring om något ändå hamnar där.

Alla låter /.well-known/ vara öppen, för den behövs till exempel för certifikat. Prova på en testsajt först.

nginx Först i sajtens server-block. nginx använder den första regex-regel som passar, och en location ^~ (till exempel för /static/) hoppar över dem helt, så lägg samma regler i den också.
# 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 I sajtens inställningar eller i .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 I sajtens block i 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 Bestämmer vad som följer med in i avbilden när den byggs, i alla mappar. Det täcker inte filer som monteras in när containern körs, och är ingen spärr i Traefik: spärren hör hemma i appen eller webbservern.
**/.git
**/.env*
**/*.sql
**/*.bak
**/*.zip
**/id_*
**/*.tfvars

Så kollar du

Fem minuter i en terminal. Byt example.com mot din egen adress.

Kolla bara din egen sajt. Att leta efter andras filer är precis det tjuven gör.

  1. Fråga efter .env

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

    Titta på både svaret och innehållet. 404 eller 403 är bra. Kommer dina inställningar med är filen publik. (Svarar sajten 200 på allt, som många appar gör, ska innehållet vara din vanliga sida.)

  2. Fråga efter .git

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

    Ser du en rad som ref: refs/heads/main ligger hela källkoden ute. En felsida eller din vanliga sida är bra.

  3. Prova under andra mappar

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

    En spärr kan missas i mappar som visas direkt, som /static/ eller /assets/. Prova där, och prova fler filer från listan, som en .sql eller en gammal kopia av en inställningsfil. Det som räknas är om innehållet syns.

  4. Titta i loggen

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

    Frågorna kommer varje dag, så att de syns är inget konstigt. Ett 200 i loggen bevisar inte att något läckt, för många appar svarar 200 med sin vanliga sida. Ser du 200 på .env eller .git/HEAD: hämta adressen som ovan och titta på innehållet.

Om en fil kom fram

  • Ta bort filen och spärra adressen.
  • Byt varje lösenord och nyckel som stod i den: databasen, e-posten, betaltjänster och molnkontot. Utgå från att tjuven redan har dem.
  • Titta i loggen efter vem som hämtade filen, och om något har hänt med kontona sedan dess.

Mer om tjuvar och andra sorters robotar i Så funkar robotarna.