# Zabezpieczyć dowody, zanim zainstalują Państwo serwer od nowa

> Zabezpieczanie dowodów przed reinstalacją: które ślady na serwerze są ulotne, w jakiej kolejności je zabezpieczać i jak zachować wiarygodność kopii.

Źródło: https://phpsos.de/pl/blog/beweise-sichern-vor-neuinstallation/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Zanim zainstalują Państwo przejęty serwer od nowa, należy zabezpieczyć dowody w kolejności ich ulotności: najpierw procesy, połączenia i zalogowanych użytkowników, potem logi i konfigurację, następnie pełny obraz systemu oraz dane usług znajdujących się przed serwerem. Każda kopia otrzymuje sumę kontrolną i jest przechowywana poza serwerem. W tym celu serwer odłącza się od sieci, ale nie wyłącza.

## Odruch natychmiastowej reinstalacji

Kto odkryje włamanie, chce je zakończyć jak najszybciej. Świeży system, czysto zainstalowany, z nowymi hasłami: to daje poczucie kontroli. Technicznie przebudowa jest często także właściwą drogą, zwłaszcza gdy atakujący miał uprawnienia roota.

Problemem jest moment. Wraz ze starym systemem znikają wszystkie odpowiedzi na pytania, które pojawią się w kolejnych dniach. Przez jaką lukę wszedł atakujący? Od kiedy był w systemie? Czy miał dostęp do danych klientów? Czy serwer bazy danych obok również jest dotknięty? Bez śladów zostają tylko przypuszczenia, a te nie pomagają ani w sprawie ochrony danych, ani wobec ubezpieczyciela.

Po PHP2Shell dochodzi szczególny aspekt: nie ma opublikowanych, potwierdzonych wskaźników włamania (Indicators of Compromise). To, czy i jak serwer został dotknięty, można odczytać wyłącznie z zachowania, a więc z dokładnie tych śladów, które pochopna przebudowa kasuje. Prasa branżowa radzi przechowywać logi serwera od 20.10.2026.

## Zabezpieczanie dowodów na serwerze: liczy się kolejność

Ślady są ulotne w różnym stopniu. To, co znajduje się w pamięci operacyjnej, znika przy następnym restarcie. Logi żyją dłużej, ale są rotowane. Dane w usługach znajdujących się przed serwerem znikają po ich własnych terminach. Z tego wynika kolejność:

| Ślad | Ulotność | Jak zabezpieczyć |
|---|---|---|
| Procesy, połączenia sieciowe, zalogowani użytkownicy | znika przy restarcie | zapisać wyniki poleceń systemowych do plików |
| Pamięć operacyjna | znika przy restarcie | tylko specjalnym narzędziem, zadanie dla specjalistów informatyki śledczej |
| Pliki tymczasowe w `/tmp` lub `/dev/shm` | często usuwane przy restarcie | skopiować bez uruchamiania |
| Logi serwera WWW, PHP, systemu | są rotowane | skopiować w całości, wstrzymać rotację |
| System plików i baza danych | stabilne do reinstalacji | migawka lub obraz nośnika, eksport bazy danych |
| CDN, WAF, zapora, dostawca hostingu | przechowywanie według terminów dostawcy | zażądać eksportu, uzyskać pisemne potwierdzenie |

Pamięć operacyjną zabezpieczają Państwo tylko wtedy, gdy dostępna jest osoba z odpowiednim narzędziem i doświadczeniem. W przypadku systemów z wrażliwymi danymi lub przewidywanego sporu prawnego powinna to przejąć [informatyka śledcza](https://phpsos.de/pl/leistungen/it-forensik/).

## Zapisanie danych ulotnych w kilka minut

Poniższe polecenia niczego w systemie nie zmieniają. Zapisują bieżący stan do plików, które następnie są zabezpieczane poza serwerem. Katalog docelowy należy w miarę możliwości utworzyć na podłączonym, oddzielnym nośniku:

```bash
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
```

Jak następnie kompletnie zabezpieczyć i przeanalizować logi, opisuje poradnik [Analiza logów serwera WWW po ataku](https://phpsos.de/pl/ratgeber/logfiles-auswerten/). W przypadku serwerów wirtualnych migawka wykonana przez panel dostawcy jest najprostszą drogą do pełnego obrazu. Obejmuje system bez potrzeby uruchamiania dodatkowych narzędzi na przejętym serwerze.

## Aby zabezpieczenie miało później wartość

Zabezpieczenie jest tyle warte, co jego dowód. Trzy zasady czynią je wiarygodnym:

1. **Sumy kontrolne:** każdy zabezpieczony plik otrzymuje sumę kontrolną SHA-256. Pozwala to później wykazać, że kopia jest niezmieniona.
2. **Protokół:** kto, kiedy, co zabezpieczył, jakim poleceniem i dokąd? Każde przekazanie osobom trzecim jest odnotowywane. Specjaliści nazywają to łańcuchem dowodowym.
3. **Oddzielne przechowywanie:** kopie należą do systemu, do którego atakujący nie miał dostępu, i są dalej używane wyłącznie w trybie do odczytu.

Potem należy pracować już tylko na kopiach. Każda analiza oryginału zmienia znaczniki czasu i może nadpisać ślady. Podejrzanych plików nie wolno nigdy uruchamiać ani otwierać przez przeglądarkę.

> **Ważne:**
> Proszę wcześnie zażądać logów od CDN, WAF i dostawcy hostingu. Dane te znajdują się poza Państwa serwerem i trudno je zmanipulować atakującemu, ale często są przechowywane tylko krótko.

## Co niszczy materiał dowodowy

Wiele śladów ginie nie z winy atakującego, lecz przez dobrze zamierzoną pierwszą pomoc. Tych kroków należy unikać przed zabezpieczeniem:

- **Restart lub wyłączenie:** procesy, połączenia i pamięć operacyjna znikają.
- **Skaner antywirusowy z automatycznym usuwaniem:** usuwa pliki, zanim ktokolwiek je zabezpieczy, i zmienia znaczniki czasu.
- **Sprzątanie logów lub katalogów tymczasowych:** nawet gdy brakuje miejsca, najpierw skopiować, potem usunąć.
- **Instalowanie na serwerze nowych narzędzi z internetu:** każda instalacja zapisuje do systemu plików i może przykryć ślady.
- **Logowanie uprzywilejowanymi danymi dostępowymi bez potrzeby:** jeśli na serwerze nadal działa złośliwy kod, wpisywane hasła mogą zostać podejrzane.

Ubezpieczyciele pytają później właśnie o to, co i kiedy zabezpieczono. Wskazówki dotyczące typowych obowiązków ubezpieczonego znajdą Państwo w artykule [Cyberubezpieczenie: co się liczy w razie szkody](https://phpsos.de/pl/compliance/cyberversicherung/).

## Rozważenie: ile czasu jest na zabezpieczenie?

Nie każdy incydent pozwala na długie zabezpieczanie. Jeśli właśnie trwa wyciek danych albo atakowani są odwiedzający, pierwszeństwo ma powstrzymanie ataku. Odłączenie od sieci przy działającym systemie łączy jedno z drugim: atakujący traci dostęp, ślady zostają zachowane. Dla większości serwerów WWW wystarcza potem rozsądny czas na dane ulotne i migawkę.

Decyzję proszę podjąć świadomie i ją odnotować: kto zdecydował, kiedy system zostanie zainstalowany od nowa, i co wcześniej zabezpieczono? Ta notatka stanie się później częścią [osi czasu incydentu](https://phpsos.de/pl/blog/zeitleiste-eines-vorfalls/). To, czy właściwą drogą jest przebudowa, czy oczyszczenie, omawia artykuł [Zainstalować serwer od nowa czy oczyścić?](https://phpsos.de/pl/blog/neu-aufsetzen-oder-bereinigen/).

## Jak konkretnie pomaga PHP SOS?

- Zabezpieczamy dane ulotne, logi i obrazy systemu we właściwej kolejności, z sumami kontrolnymi i protokołem.
- Zamawiamy dane usług znajdujących się przed serwerem, zanim upłyną terminy ich przechowywania.
- W razie potrzeby wraz ze specjalistycznymi partnerami przejmujemy zabezpieczenie i analizę śledczą.
- Dopiero potem budujemy serwer od nowa, zamykamy furtkę, którą wszedł atakujący, i dokumentujemy incydent, aż zostanie zamknięty.


## Częste pytania

**Dlaczego przed ponowną instalacją powinienem zabezpieczyć dowody?**  
Ponieważ tylko ślady pokazują, jak atakujący się dostał, jak długo był w systemie i do jakich danych mógł dotrzeć. Odpowiedzi te są potrzebne w sprawie ochrony danych, wobec ubezpieczyciela i do oceny, czy dotknięte są inne systemy. Po przebudowie są utracone.

**Co jest najpilniejsze przy zabezpieczaniu?**  
Dane ulotne, takie jak działające procesy, połączenia sieciowe i zalogowani użytkownicy, znikają przy wyłączeniu. Zabezpiecza się je najpierw. Potem następują logi, obraz systemu i dane z usług znajdujących się przed serwerem.

**Czy zwykła kopia zapasowa wystarczy jako zabezpieczenie dowodów?**  
Zwykle nie. Wiele kopii zapasowych nie zawiera logów, plików systemowych ani metadanych, takich jak znaczniki czasu i właściciele. Do zabezpieczenia dowodów potrzebna jest kompletna, niezmieniona kopia z sumą kontrolną, najlepiej migawka lub obraz nośnika.

**Czy mogę odłączyć serwer od sieci przed zabezpieczeniem?**  
Tak, jeśli przy tym nadal działa. Odłączenie od sieci zatrzymuje wyciek danych i zdalne sterowanie, nie niszcząc śladów ulotnych. Restart lub wyłączenie z kolei kasuje pamięć operacyjną i działające procesy.

## Źródła

- [BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej): wskazówki dotyczące incydentów bezpieczeństwa IT](https://www.bsi.bund.de/)
- [RODO art. 33: zgłoszenie do organu nadzorczego](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Policja (Niemcy): centralne punkty kontaktowe ds. cyberprzestępczości](https://www.polizei.de/)