Pliki .env i .git na serwerze: czego szukają skanery

Automatyczne skanery szukają na stronach firm plików .env, .git i kopii ZIP. Sprawdź swoją stronę w 10 minut i zablokuj dostęp do takich plików.

Ilustracja: serwer z otwartą szufladą pełną kluczy i folderów, nad którym unosi się robot z lupą.
Ilustracja wygenerowana przez AI

W logach mojego serwera regularnie widzę zapytania o adresy, których na stronie nie ma: /.env, /.git/config, /backup.zip, /phpinfo.php. To nie są klienci ani wyszukiwarki, tylko automatyczne skanery. Odpytują po kolei tysiące stron firm i sprawdzają, czy ktoś zostawił na serwerze plik z hasłami albo kopię całej strony.

Jeśli taki plik jest dostępny, wystarczy jedno pobranie: hasło do bazy danych, klucz do poczty albo kopia danych klientów trafia do obcej osoby. W tej poradzie pokazuję, czego szukają skanery, jak w 10 minut sprawdzić własną stronę i jak zablokować te pliki.

Czego szukają skanery

Te same adresy powtarzają się w logach wielu serwerów. Każdy z nich to plik, który czasem zostaje w katalogu strony po wdrożeniu albo aktualizacji.

Adres Co w nim bywa Skutek wycieku
/.env hasła do bazy danych, klucze API, dane do wysyłki poczty przejęcie bazy, spam z Twojej domeny, rachunek za cudze zapytania do API
/.git/ (np. /.git/config) historia kodu strony odtworzenie kodu, a w nim haseł z dawnych wersji
/backup.zip, /strona.zip, /old.tar.gz cała strona razem z plikiem konfiguracyjnym wszystko naraz: kod, hasła, czasem dane klientów
/dump.sql, /baza.sql kopia bazy danych wyciek danych klientów, czyli naruszenie ochrony danych osobowych
/wp-config.php.bak, /wp-config.php.old kopia konfiguracji WordPressa hasło do bazy zapisane zwykłym tekstem
/phpinfo.php, /info.php pełny opis konfiguracji serwera podpowiedź dla atakującego: wersje i ścieżki

Ważna różnica: plik wp-config.php serwer uruchamia jako program, więc z zewnątrz nie widać jego treści. Jego kopia z inną końcówką (.bak, .old, .txt) to już zwykły plik tekstowy, który przeglądarka po prostu pokaże albo pobierze.

Skąd te pliki biorą się na serwerze

Nikt nie zostawia ich celowo. Najczęściej widzę pięć scenariuszy:

  1. Wdrożenie przez skopiowanie całego folderu projektu. Razem z plikami strony trafia na serwer ukryty katalog .git i plik .env.
  2. Kopia „na chwilę” przed aktualizacją. Ktoś pakuje stronę do backup.zip w katalogu strony i zapomina ją usunąć.
  3. Kopie z edytora. Edytor zostawia pliki z końcówką ~, .bak albo .swp obok edytowanego pliku.
  4. Stara wersja strony w podkatalogu. Po zmianie strony poprzednia ląduje w /old/ albo /test/ i dalej działa, często bez aktualizacji.
  5. Kopie zapasowe w katalogu publicznym. Niektóre narzędzia do kopii zapisują archiwa w miejscu, do którego da się dojść z przeglądarki.

Jak sprawdzić swoją stronę w 10 minut

Sprawdzaj wyłącznie własną stronę albo stronę, którą opiekujesz się z upoważnienia właściciela.

Krok 1: wpisz adresy w przeglądarce. Zamień twojadomena.pl na swój adres i otwórz po kolei:

https://twojadomena.pl/.env
https://twojadomena.pl/.git/config
https://twojadomena.pl/.git/HEAD
https://twojadomena.pl/backup.zip
https://twojadomena.pl/phpinfo.php

Dobry wynik to błąd 403 albo 404. Zły wynik to wyświetlona treść pliku albo rozpoczęte pobieranie.

Krok 2: przejrzyj katalog strony. Zaloguj się do menedżera plików w panelu hostingu (albo przez FTP) i otwórz katalog strony, zwykle public_html albo www. Szukaj plików z końcówkami .zip, .sql, .tar.gz, .bak, .old i katalogów old, test, kopia.

Krok 3: sprawdź listę plików w katalogach. Otwórz adres katalogu, w którym są zdjęcia, np. https://twojadomena.pl/wp-content/uploads/ w WordPressie. Jeśli widzisz listę plików zamiast pustej strony albo błędu, serwer pokazuje zawartość katalogów każdemu odwiedzającemu.

Szerszy przegląd strony, nie tylko pod kątem tych plików, znajdziesz w poradzie jak sprawdzić stronę firmy za darmo.

Co zrobić, gdy plik jest dostępny

Jeśli któryś adres pokazał treść, działaj w tej kolejności:

  1. Usuń plik albo przenieś go poza katalog strony. Kopie zapasowe nie powinny leżeć w miejscu dostępnym z internetu.
  2. Uznaj hasła z tego pliku za ujawnione. Zmień hasło do bazy danych, wygeneruj nowe klucze API i unieważnij stare, zmień hasło do skrzynki używanej przez stronę. W WordPressie wygeneruj też nowe klucze uwierzytelniania i sole, co wyloguje wszystkich zalogowanych.
  3. Poproś hosting o logi. Zapytaj, czy ktoś pobrał ten adres (odpowiedź serwera 200). To pokaże, czy plik wyciekł, czy tylko leżał.
  4. Oceń, czy wyciekły dane osobowe. Jeśli w kopii była baza z danymi klientów, to może być naruszenie ochrony danych. Art. 33 RODO wymaga zgłoszenia do Prezesa UODO bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny po stwierdzeniu naruszenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. Informacje i formularz są na stronie uodo.gov.pl.

Pełny plan pierwszej doby po wykryciu problemu opisuję w poradzie luka w stronie firmy: co robić w pierwszych 24 godzinach.

Blokada w konfiguracji serwera

Usunięcie plików to podstawa, ale warto też zablokować takie adresy na stałe. Wtedy przypadkowo wgrany plik nie będzie dostępny.

Apache (wiele hostingów współdzielonych), plik .htaccess w katalogu strony:

# Bez listy plików w katalogach
Options -Indexes

# Pliki i katalogi zaczynające się od kropki (.env, .git), z wyjątkiem .well-known
RedirectMatch 404 /\.(?!well-known)

# Kopie i zrzuty, których nie powinno być w katalogu strony
<FilesMatch "(\.(sql|bak|old|swp)|~)$">
  Require all denied
</FilesMatch>

Trzy uwagi przed wklejeniem:

  • Zrób kopię obecnego .htaccess i po zmianie od razu otwórz stronę. Część hostingów nie pozwala na linię Options i wtedy strona pokaże błąd 500. Usuń tę linię i zapytaj hosting, jak wyłączyć listę plików.
  • Require all denied działa w Apache 2.4, czyli na zdecydowanej większości obecnych serwerów.
  • Wyjątek dla .well-known jest potrzebny, bo tamtędy działa m.in. odnawianie certyfikatu SSL.

Nginx (serwery VPS, zmianę robi administrator):

location ~ /\.(?!well-known) {
    deny all;
}

location ~* \.(sql|bak|old|swp)$ {
    deny all;
}

Po zmianie i usunięciu zbędnych plików powtórz krok 1 ze sprawdzania: wszystkie adresy powinny zwrócić 403 albo 404.

Jak nie dopuścić do tego w przyszłości

  • Wgrywaj na serwer tylko pliki strony, bez katalogu .git, plików projektu i notatek. Narzędzia do wdrożeń mają do tego listę wykluczeń.
  • Trzymaj .env poza katalogiem publicznym. Frameworki takie jak Laravel mają osobny katalog public i tylko on powinien być widoczny z internetu, a plik .env leży piętro wyżej.
  • Kopie zapasowe przechowuj poza katalogiem strony i poza serwerem. Jak to zorganizować, opisuję w poradzie o kopii zapasowej strony i zasadzie 3-2-1.
  • Sprzątaj po każdej aktualizacji: usuń pliki testowe, archiwa i stare wersje strony.
  • Raz na kwartał powtórz sprawdzenie z tej porady. To 10 minut, a skanery nie robią przerw.

Podsumowanie

Skanery szukają plików, które zostały na serwerze przez przypadek, i robią to automatycznie, niezależnie od wielkości firmy. Sprawdź pięć adresów z tej porady, usuń zbędne kopie i dodaj blokadę w konfiguracji serwera. Jeśli wolisz, żeby zrobił to ktoś za Ciebie, w ramach audytu bezpieczeństwa sprawdzę stronę i serwer, a stałą ochronę zapewnia opieka techniczna. Możesz też po prostu napisać do mnie.

Najczęstsze pytania

Usługi związane z tematem

Masz podobny projekt?

Opisz, czego potrzebujesz, a w 24 godziny odeślę wycenę. Nowi klienci dostają 20% rabatu na pierwsze zlecenie.

Wyceń projektUmów rozmowę (20 min)

Czytaj dalej