# Întocmirea cronologiei unui incident

> Întocmirea cronologiei unui incident IT: folosiți corect sursele și fusurile orare și marcați fiecare afirmație ca dovedită, probabilă sau necunoscută.

Sursa: https://phpsos.de/ro/blog/zeitleiste-eines-vorfalls/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** O cronologie a unui incident IT ordonează cronologic toate observațiile, deciziile și măsurile, într-un fus orar unitar, ideal UTC. Fiecare rând indică sursa, observația, dovada și o evaluare ca dovedit, probabil sau necunoscut. Astfel rezultă o imagine verificabilă despre când a fost atacatorul în sistem, ce a putut obține și când ați luat la cunoștință.

## De ce, în cele din urmă, toți întreabă când

După un incident, întrebările vin din toate direcțiile. Responsabilul cu protecția datelor vrea să știe de când erau accesibile datele cu caracter personal. Asigurătorul întreabă când a fost descoperită și raportată dauna. Conducerea dorește să știe dacă vulnerabilitatea era deschisă deja înainte de ultima actualizare. Toate aceste întrebări au un punct comun: se învârt în jurul unor momente.

Fără cronologie, fiecare răspunde la aceste întrebări din memorie, iar răspunsurile se contrazic. Cu o cronologie ținută curat există o bază comună, la care se raportează toți participanții. Ea este totodată scheletul raportului final.

La PHP2Shell, cronologia este deosebit de elocventă, pentru că datele publice esențiale sunt bine documentate. Ele pot fi așezate ca puncte de ancorare lângă propriile observații. Succesiunea completă a evenimentelor publice o descrie ghidul [PHP2Shell: cronologia](https://phpsos.de/ro/ratgeber/php2shell-chronologie/).

## Structura: ce coloane are nevoie o cronologie

Un tabel este suficient, fie într-o foaie de calcul, fie într-un document comun. Importante sunt coloanele fixe, completate pentru fiecare rând. Modelul următor arată datele publice esențiale PHP2Shell ca ancore, iar dedesubt intrări proprii tipice, sub formă de substituenți:

| Timp (UTC) | Sursă | Observație | Dovadă | Evaluare |
|---|---|---|---|---|
| 17.10.2026 | rapoarte din presă | prima tentativă de atac observată la PHP2Shell | articol de presă | dovedit ca raport din presă |
| 20.10.2026 | php.net | anunț prealabil al actualizărilor de securitate | anunț pe php.net | dovedit |
| 21.10.2026, 14:00 | php.net | publicarea versiunilor 8.5.12, 8.4.27, 8.3.36, 8.2.35 | anunț pe php.net | dovedit |
| ora proprie | jurnal de acces | acumulare de erori 500 pe pagini normale | extras din jurnal, număr de rând | probabil relevant |
| ora proprie | sistemul de fișiere | fișier PHP nou în dosarul de upload | copie cu sumă de control | dovedit, momentul nesigur |
| ora proprie | intern | incident observat, conducerea informată | e-mail, notă de conversație | dovedit |
| ora proprie | intern | actualizare aplicată, toți workerii reporniți | jurnalul pachetelor, lista proceselor | dovedit |

Coloana Evaluare este partea cea mai importantă. Ea separă ce este dovedit, ce pare plauzibil și ce rămâne deschis. Cititorii de mai târziu văd astfel imediat unde rezistă cronologia și unde există lacune.

## Cronologia unui incident IT: reunirea surselor

Intrările provin din multe surse, fiecare cu formate și fusuri orare proprii. Procedați în această ordine:

1. **Stabiliți fusul orar:** Țineți totul în UTC. Trecerea la ora de iarnă din 25.10.2026 deplasează cu o oră orele locale germane chiar în mijlocul perioadei. Cine amestecă orele locale deplasează evenimente fără să observe.
2. **Verificați ceasurile:** Mergea corect ceasul serverului? O comparație cu un eveniment cunoscut, de exemplu cu propria autentificare, arată abaterile.
3. **Mai întâi sursele externe:** Jurnalele de la CDN, WAF, furnizorul de hosting sau firewall se află în afara serverului și sunt greu de manipulat. Ele formează scheletul.
4. **Completați cu jurnalele serverului:** Server web, PHP-FPM, autentificări, jurnalul de sistem. Metodologia pentru aceasta o descrie [Evaluarea jurnalelor serverului web după un atac](https://phpsos.de/ro/ratgeber/logfiles-auswerten/).
5. **Încadrați sistemul de fișiere:** Adăugați ca indicii marcajele de timp ale fișierelor noi și modificate.
6. **Înregistrați evenimentele interne:** Când s-a observat ceva, cine a fost informat, ce decizie s-a luat când?

## Ce dezvăluie marcajele de timp ale fișierelor și ce nu

Linux stochează pentru fiecare fișier mai multe momente, printre care ultima modificare a conținutului (mtime) și ultima modificare a metadatelor (ctime). Ambele pot fi afișate doar în citire, aici ca listă a fișierelor PHP modificate de la o dată de referință, sortate după timp în UTC:

```bash
# Modificări de conținut de la 17.10.2026, sortate, în UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

# Toate marcajele de timp ale unui singur fișier
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
```

Lucrați aici doar pe o copie sau pe o imagine securizată, așa cum este descris în [Salvați probele înainte de a reinstala serverul](https://phpsos.de/ro/blog/beweise-sichern-vor-neuinstallation/). Aveți în vedere două limite. În primul rând, un atacator poate reseta cu mijloace simple data modificării unui fișier; un mtime neobservabil nu este o achitare. În al doilea rând, operațiunile de copiere și unele unelte modifică marcajele de timp. De aceea se aplică: orele fișierelor sunt indicii, înregistrările din jurnale externe sunt dovezi.

> **Important:**
> Consemnați momentul în care firma dumneavoastră a aflat de o posibilă încălcare a securității datelor. Conform art. 33 RGPD, termenul de 72 de ore pentru o notificare începe, în principiu, de la luarea la cunoștință. Evaluarea revine responsabilului dumneavoastră cu protecția datelor sau unui avocat.

## Greșeli tipice și cum le evitați

Cele mai frecvente greșeli sunt nespectaculoase. Cronologia este reconstituită abia la final din memorie, în loc să fie ținută pe parcurs. Intrările conțin concluzii în loc de observații, de exemplu „atacatorul a intrat prin formular” în loc de „cerere POST către formular, apoi fișier nou”. Iar dovezile lipsesc, pentru că nimeni nu a notat din ce fișier de jurnal și din ce rând provine o intrare.

Desemnați de aceea o persoană care ține cronologia și consemnați evenimentele imediat ce apar. Concluziile aparțin unei coloane proprii sau raportului, nu observației.

Tratați, în plus, cronologia ca document confidențial. Ea conține adesea adrese IP, nume de utilizator și indicii despre puncte slabe. Stabiliți cine are voie să o citească și să o modifice și păstrați versiunile anterioare. Dacă o apreciere se schimbă, de exemplu pentru că apare un nou extras din jurnal, rândul vechi nu se suprascrie, ci se completează. Astfel rămâne verificabil ce se știa la ce moment și pe ce bază s-a decis.

## Cum ajută PHP SOS concret?

- Ținem cronologia de la primul contact, continuu și în UTC, cu sursă și dovadă pentru fiecare intrare.
- Evaluăm împreună jurnalele externe, jurnalele serverului și sistemul de fișiere și marcăm fiecare afirmație ca dovedită, probabilă sau necunoscută.
- La nevoie, preluăm împreună cu parteneri specializați [criminalistica IT](https://phpsos.de/ro/leistungen/it-forensik/) pentru o evaluare utilizabilă în instanță.
- Predăm cronologia ca parte a unui raport pentru conducere, protecția datelor și asigurare.


## Întrebări frecvente

**La ce îmi trebuie o cronologie după un incident de securitate?**  
Ea așază toate observațiile într-o ordine și arată când a fost atacatorul în sistem, ce a putut obține și când ați aflat dumneavoastră. Aceste informații sunt necesare responsabililor cu protecția datelor, asigurătorilor, autorităților și conducerii pentru deciziile lor.

**În ce fus orar ar trebui să țin cronologia?**  
Unitar, în UTC. Serverele, serviciile și notificările folosesc fusuri orare diferite, iar trecerea la ora de iarnă la sfârșitul lui octombrie deplasează în plus orele locale. Cine convertește totul în UTC și adaugă ora locală doar suplimentar evită erorile la comparare.

**Mă pot baza pe marcajele de timp ale fișierelor?**  
Doar limitat. Data modificării unui fișier poate fi falsificată cu mijloace simple. Mai fiabile sunt înregistrările din jurnale, în special din jurnalele aflate în afara serverului afectat. Marcajele de timp ale fișierelor sunt indicii, care ar trebui confirmate prin alte surse.

**Ce intră în cronologie în afară de evenimentele tehnice?**  
Și deciziile și comunicarea: când a fost observat incidentul, cine a fost informat, când a fost deconectat serverul de la rețea, când s-a aplicat patchul. Tocmai momentul luării la cunoștință este important pentru termenele de notificare.

## Surse

- [php.net: anunțuri de securitate privind PHP2Shell](https://www.php.net/)
- [RGPD art. 33: notificarea către autoritatea de supraveghere](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI (Oficiul Federal German pentru Securitatea Informațiilor): indicații privind incidentele de securitate IT](https://www.bsi.bund.de/)