# Osigurajte dokaze prije nego ponovno postavite poslužitelj

> Osiguranje dokaza prije nove instalacije: koji su tragovi na poslužitelju hlapljivi, kojim redoslijedom ih osigurati i kako sigurnosna kopija ostaje vjerodostojna.

Izvor: https://phpsos.de/hr/blog/beweise-sichern-vor-neuinstallation/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Prije ponovnog postavljanja kompromitiranog poslužitelja osigurajte dokaze redoslijedom njihove hlapljivosti: najprije procese, veze i prijavljene korisnike, zatim zapisnike i konfiguraciju, potom potpunu sliku sustava i podatke usluga ispred poslužitelja. Svako osiguranje dobiva kontrolni zbroj i pohranjuje se izvan poslužitelja. Poslužitelj se zbog toga odvaja od mreže, ali se ne gasi.

## Refleks da se odmah ponovno postavi

Tko otkrije provalu, želi je okončati što prije. Svjež sustav, čisto instaliran, s novim lozinkama: to daje osjećaj kontrole. Tehnički je ponovna izgradnja često i pravi put, osobito ako je napadač imao root prava.

Problem je trenutak. Sa starim sustavom nestaju svi odgovori na pitanja koja dolaze u danima nakon toga. Kroz koju je ranjivost napadač ušao? Otkad je bio u sustavu? Je li imao pristup podacima kupaca? Je li pogođen i poslužitelj baze podataka pokraj? Bez tragova ostaju samo pretpostavke, a one ne pomažu ni kod zaštite podataka ni kod osiguranja.

Nakon PHP2Shella dolazi i jedna posebnost: nema objavljenih, potvrđenih Indicators of Compromise. Je li i kako poslužitelj bio pogođen, može se iščitati samo iz ponašanja, dakle upravo iz tragova koje prenagljena ponovna izgradnja briše. Stručni tisak savjetuje čuvanje zapisnika poslužitelja od 20. 10. 2026.

## Osiguranje dokaza na poslužitelju: redoslijed je važan

Tragovi su različito hlapljivi. Što je u radnoj memoriji, nestaje sljedećim ponovnim pokretanjem. Zapisnici žive dulje, ali se rotiraju. Podaci na uslugama ispred poslužitelja nestaju prema njihovim rokovima. Iz toga proizlazi redoslijed:

| Trag | Hlapljivost | Kako osigurati |
|---|---|---|
| Procesi, mrežne veze, prijavljeni korisnici | nestaje pri ponovnom pokretanju | ispise sistemskih naredbi upisati u datoteke |
| Radna memorija | nestaje pri ponovnom pokretanju | samo specijalnim alatom, zadatak za forenzičare |
| Privremene datoteke u `/tmp` ili `/dev/shm` | često se brišu pri ponovnom pokretanju | kopirati, bez izvršavanja |
| Zapisnici web-poslužitelja, PHP-a, sustava | rotiraju se | kopirati u cijelosti, zaustaviti rotaciju |
| Datotečni sustav i baza podataka | stabilni do nove instalacije | snapshot ili slika nosača podataka, izvoz baze podataka |
| CDN, WAF, vatrozid, pružatelj hostinga | čuvanje prema rokovima pružatelja | zatražiti izvoz, dati ga pisano potvrditi |

Radnu memoriju osiguravate samo ako su spremni netko s odgovarajućim alatom i iskustvom. Kod sustava s osjetljivim podacima ili predvidljivim sudskim sporom to bi trebala preuzeti [IT forenzika](https://phpsos.de/hr/leistungen/it-forensik/).

## Hlapljive podatke zabilježiti za nekoliko minuta

Sljedeće naredbe ne mijenjaju ništa na sustavu. Trenutačno stanje upisuju u datoteke koje se zatim osiguravaju izvan poslužitelja. Ciljni direktorij po mogućnosti izradite na priključenom, odvojenom nosaču podataka:

```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"
```

Kako zatim zapisnike u cijelosti osigurati i analizirati, opisuje vodič [Analizirati zapisnike web-poslužitelja nakon napada](https://phpsos.de/hr/ratgeber/logfiles-auswerten/). Kod virtualnih poslužitelja snapshot putem upravljanja pružatelja najjednostavniji je put do potpune slike. Bilježi sustav bez potrebe da na kompromitiranom poslužitelju pokrećete dodatne alate.

## Da osiguranje kasnije vrijedi nešto

Osiguranje vrijedi koliko i njegov dokaz. Tri pravila čine ga vjerodostojnim:

1. **Kontrolni zbrojevi:** svaka osigurana datoteka dobiva SHA-256 kontrolni zbroj. Time se kasnije može pokazati da je kopija neizmijenjena.
2. **Zapisnik postupka:** tko je što i kada osigurao, kojom naredbom, kamo? Svaka predaja trećima bilježi se. Stručnjaci to nazivaju lancem nadzora dokaza (chain of custody).
3. **Odvojena pohrana:** kopije pripadaju na sustav kojem napadač nije imao pristup i dalje se koriste samo za čitanje.

Nakon toga radite samo s kopijama. Svaka analiza na originalu mijenja vremenske žigove i može prepisati tragove. Sumnjive datoteke nikada ne izvršavajte i ne otvarajte ih preko preglednika.

> **Važno:**
> Zapisnike CDN-a, WAF-a i pružatelja hostinga zatražite rano. Ti su podaci izvan Vašeg poslužitelja i napadaču ih je teško manipulirati, ali se često čuvaju samo kratko.

## Što uništava dokaznu situaciju

Mnogi tragovi ne propadnu zbog napadača, nego zbog dobronamjerne prve pomoći. Ove korake prije osiguranja treba izbjeći:

- **Ponovno pokretanje ili gašenje:** procesi, veze i radna memorija nakon toga nestaju.
- **Antivirusni program s automatskim brisanjem:** uklanja datoteke prije nego ih itko osigura i mijenja vremenske žigove.
- **Čišćenje zapisnika ili privremenih mapa:** čak i kad nedostaje prostora, najprije kopirati, tek onda brisati.
- **Instaliranje novih alata s interneta na poslužitelju:** svaka instalacija piše u datotečni sustav i može prekriti tragove.
- **Prijava s povlaštenim pristupnim podacima bez nužde:** ako na poslužitelju još radi zlonamjerni kod, unesene se lozinke mogu pročitati.

Osiguravatelji će kasnije upravo pitati što je i kada osigurano. Napomene o tipičnim obvezama nalaze se u članku [Kibernetičko osiguranje: što u slučaju štete vrijedi](https://phpsos.de/hr/compliance/cyberversicherung/).

## Odvagnuti: koliko je vremena na raspolaganju za osiguranje?

Ne dopušta svaki incident dugo osiguranje. Ako upravo traje odljev podataka ili se napadaju posjetitelji, obuzdavanje ima prednost. Odvajanje od mreže uz pokrenut sustav povezuje oboje: napadač gubi pristup, a tragovi ostaju. Za većinu web-poslužitelja nakon toga je za hlapljive podatke i snapshot dovoljno razmjerno kratko razdoblje.

Odluku donesite svjesno i zabilježite je: tko je odlučio kada se ponovno postavlja i što je prije toga osigurano? Ta je bilješka kasnije dio [vremenske crte incidenta](https://phpsos.de/hr/blog/zeitleiste-eines-vorfalls/). Je li ponovna izgradnja ili čišćenje pravi put, razmatra članak [Ponovno postaviti poslužitelj ili ga očistiti?](https://phpsos.de/hr/blog/neu-aufsetzen-oder-bereinigen/).

## Kako PHP SOS konkretno pomaže?

- Hlapljive podatke, zapisnike i slike sustava osiguravamo pravilnim redoslijedom, s kontrolnim zbrojevima i zapisnikom postupka.
- Podatke usluga ispred poslužitelja zatražujemo prije nego isteknu njihovi rokovi čuvanja.
- Po potrebi sa specijaliziranim partnerima preuzimamo forenzičko osiguranje i analizu.
- Tek nakon toga ponovno gradimo poslužitelj, zatvaramo ulaz i dokumentiramo incident do njegova zaključenja.


## Česta pitanja

**Zašto bih prije ponovnog postavljanja osigurao dokaze?**  
Jer samo tragovi pokazuju kako je napadač ušao, koliko je dugo bio u sustavu i do kojih je podataka mogao doći. Te odgovore trebate za zaštitu podataka, osiguranje i pitanje jesu li pogođeni drugi sustavi. Nakon ponovne izgradnje oni su izgubljeni.

**Što je kod osiguranja najhitnije?**  
Hlapljivi podaci poput pokrenutih procesa, mrežnih veza i prijavljenih korisnika nestaju gašenjem. Njih najprije treba zabilježiti. Zatim slijede zapisnici, slika sustava i podaci s usluga ispred poslužitelja.

**Je li običan backup dovoljan kao osiguranje dokaza?**  
Najčešće nije. Mnogi backupi ne sadrže zapisnike, sistemske datoteke ni metapodatke poput vremenskih žigova i vlasnika. Za osiguranje dokaza trebate potpunu, neizmijenjenu kopiju s kontrolnim zbrojem, idealno snapshot ili sliku nosača podataka.

**Smijem li poslužitelj prije osiguranja odvojiti od mreže?**  
Smijete, ako pritom ostane pokrenut. Odvajanje od mreže zaustavlja odljev podataka i daljinsko upravljanje, a ne uništava hlapljive tragove. Ponovno pokretanje ili gašenje, nasuprot tome, briše radnu memoriju i pokrenute procese.

## Izvori

- [BSI (njemački Savezni ured za informacijsku sigurnost): napomene o IT sigurnosnim incidentima](https://www.bsi.bund.de/)
- [GDPR čl. 33: prijava nadzornom tijelu](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Njemačka policija: središnje kontaktne točke za kibernetički kriminal](https://www.polizei.de/)
