Zapomniana kopia zapasowa na serwerze, którą może pobrać każdy

Kopia zapasowa to dobra rzecz. Kłopot zaczyna się wtedy, gdy leży w złym miejscu.

Typowa historia wygląda tak. Programista przenosi stronę na nowy hosting albo wprowadza większe zmiany. Na wszelki wypadek pakuje całość do pliku backup.zip, zrzuca bazę danych do baza.sql i zostawia to w folderze strony, żeby mieć pod ręką. Praca się kończy, strona działa, plik zostaje. Po roku nikt już o nim nie pamięta.

Tyle że folder strony jest publiczny. Wszystko, co w nim leży, da się pobrać zwykłą przeglądarką, jeśli ktoś zna adres albo go zgadnie.

Co zwykle zostaje w folderze strony

Najczęstsze znaleziska wyglądają mniej więcej tak:

• archiwa całej strony, na przykład backup.zip, strona.tar.gz albo www-2023.zip,
• zrzuty bazy danych: dump.sql, baza.sql, db_backup.sql,
• kopie pliku konfiguracyjnego: wp-config.php.bak, wp-config.php.old, config.php~,
• całe stare wersje strony w folderach old/, stara/, test/ czy backup/,
• archiwa i pliki instalatora zostawione przez wtyczki do przenoszenia stron.

Najgroźniejszy bywa ten najmniejszy plik, czyli kopia konfiguracji. Oryginalny wp-config.php serwer uruchamia jak program, więc nikt z zewnątrz nie zobaczy jego treści. Natomiast wp-config.php.bak jest dla serwera zwykłym plikiem tekstowym. Odda go w całości, razem z nazwą bazy danych, loginem i hasłem.

Zrzut bazy to z kolei cała zawartość sklepu albo formularzy: imiona, adresy, telefony, historia zamówień, konta użytkowników. A folder old/ często kryje pełną, działającą kopię strony sprzed lat, z wtyczkami, których nikt nie aktualizuje. Główna strona może być zadbana, a włamanie i tak przyjdzie przez tę zapomnianą obok.

Dlaczego boty ich szukają

Nikt nie musi wiedzieć, że akurat Ty masz na serwerze kopię. Automatyczne skanery krążą po internecie i na każdej stronie, na którą trafią, sprawdzają listę popularnych nazw: /backup.zip, /site.zip, /dump.sql, /wp-config.php.bak, /.env. To tanie i szybkie, więc robią to bez przerwy.

Jeśli poprosisz hosting o logi dostępu do strony, prawie na pewno zobaczysz w nich takie próby. Na zadbanej stronie wszystkie kończą się kodem 404, czyli informacją, że takiego pliku nie ma. Na stronie z zapomnianą kopią jedna z nich kończy się kodem 200 i pobraniem pliku.

Druga droga prowadzi przez Google. Jeśli serwer ma włączone listowanie katalogów, wejście na twojadomena.pl/backup/ pokazuje zwykłą listę plików z nagłówkiem „Index of /backup”. Takie strony czasem trafiają do wyszukiwarki, a wtedy każdy może je znaleźć bez zgadywania.

Co sprawdzisz sam, bez dostępu do serwera

Kilka rzeczy zrobisz w pięć minut:

1. Wpisz w Google site:twojadomena.pl intitle:"index of". Brak wyników to dobry znak.
2. Wpisz w przeglądarce kilka adresów w rodzaju twojadomena.pl/backup.zip, twojadomena.pl/baza.sql albo twojadomena.pl/old/. Jeśli zamiast strony błędu zacznie się pobieranie albo zobaczysz listę plików, masz odpowiedź.
3. Przepuść stronę przez skaner, na przykład ShieldWave, który z zewnątrz próbuje tych samych typowych nazw co boty. Różnica polega na tym, że wynik trafia do Ciebie.

Zgadywanie ma jednak swoje granice, bo możliwych nazw są setki, a programista mógł nazwać plik dowolnie. Pewną odpowiedź da tylko ktoś, kto zajrzy do plików na serwerze.

Jak poprosić programistę albo hosting o sprawdzenie

Nie musisz znać szczegółów technicznych. Wystarczy wiadomość, w której poprosisz o cztery rzeczy:

• sprawdzenie, czy w publicznym folderze strony (zwykle nazywa się public_html, www albo httpdocs) nie leżą pliki .zip, .tar.gz, .sql, .bak, .old ani foldery w rodzaju old, backup czy test,
• przeniesienie wszystkiego, co się znajdzie, poza folder publiczny albo usunięcie tego,
• wyłączenie listowania katalogów, jeśli jest włączone,
• sprawdzenie w logach serwera, czy ktoś pobierał te pliki.

Ostatni punkt ma znaczenie. Jeśli okaże się, że ktoś pobrał kopię pliku konfiguracyjnego, samo usunięcie nie wystarczy. Hasło do bazy danych trzeba zmienić, bo ktoś mógł je już zapisać.

Jeśli pobrany plik zawierał dane klientów, masz do czynienia z naruszeniem ochrony danych osobowych. Artykuł 33 RODO daje wtedy 72 godziny od stwierdzenia naruszenia na zgłoszenie go do UODO, chyba że naruszenie raczej nie niesie ryzyka dla osób, których dane dotyczą. Nawet gdy nie zgłaszasz, trzeba je udokumentować.

Gdzie trzymać kopie, żeby były bezpieczne

Dobra kopia zapasowa spełnia kilka prostych warunków:

• leży poza publicznym folderem strony, a najlepiej w ogóle na innym serwerze albo w osobnej usłudze do przechowywania plików,
• robi się sama według harmonogramu, a nie wtedy, gdy ktoś sobie przypomni,
• jest przechowywana w kilku wersjach wstecz, bo infekcję strony często odkrywa się dopiero po tygodniach,
• ktoś przynajmniej raz sprawdził, że da się z niej odtworzyć stronę.

Uważaj na wtyczki do kopii w WordPressie. Część z nich domyślnie zapisuje archiwa w folderze strony, na przykład wewnątrz wp-content, i zabezpiecza je plikiem .htaccess. To zabezpieczenie działa na serwerach Apache i LiteSpeed, ale serwer nginx w ogóle tego pliku nie czyta. Najprościej ustawić wtyczkę tak, żeby wysyłała kopie na zewnątrz i nie zostawiała ich lokalnie.

Wśród administratorów znana jest zasada 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, w tym jedna poza firmą. Dla małej strony wystarczy jej skromniejsza wersja: kopia robiona przez hosting plus kopia automatycznie wysyłana gdzie indziej. Byle nie do folderu, który każdy może otworzyć w przeglądarce.

Jeśli masz zadać osobie od strony tylko jedno pytanie, niech brzmi tak: gdzie są nasze kopie zapasowe i kto poza nami może je pobrać?