Când un server Linux pare compromis, prima greșeală este graba: comenzi rulate la întâmplare, fișiere deschise direct pe sistemul afectat, reporniri „ca să vedem dacă își revine”. Pentru cine vrea o carieră în Cyber & AI, documentarea incidentului este o competență practică: arăți ce ai observat, ce ai colectat, când, de unde și cu ce limitări, fără să transformi investigația într-o modificare a dovezilor.
Principiul de bază: conservi înainte să interpretezi
RFC 3227 recomandă să colectezi dovezile ținând cont de volatilitate: unele date dispar rapid, cum ar fi conexiunile active sau procesele în memorie, iar altele rămân mai mult timp, cum ar fi fișierele de pe disc. Același document avertizează să eviți schimbări inutile pe sistemul analizat. În practică, asta înseamnă că notezi starea inițială, limitezi intervențiile și separi observația de concluzie.
NIST SP 800-86 descrie integrarea tehnicilor forensic în răspunsul la incidente și insistă pe colectare, examinare, analiză și raportare. Pentru un începător, lecția utilă este simplă: nu începe prin a „curăța” serverul. Mai întâi documentează ce există, apoi decizi împreună cu responsabilul tehnic dacă sistemul trebuie izolat, clonat, restaurat sau predat unei echipe specializate.
Ce notezi imediat în jurnalul incidentului
Un jurnal bun este cronologic. Notează ora locală și fusul orar, persoana care a observat problema, sursa alertei, numele sistemului, rolul serverului și cine a avut acces administrativ. Dacă ai capturi de ecran, loguri exportate sau fișiere copiate, notează de unde provin și unde au fost salvate.
Separă faptele de ipoteze. „Serviciul web nu răspundea la ora 09:14” este fapt observabil. „Atacatorul a șters fișierele” este concluzie și trebuie susținută de dovezi. Această disciplină te ajută și la raportarea internă: managerii au nevoie de impact, administratorii au nevoie de detalii tehnice, iar echipa de securitate are nevoie de traseul complet al acțiunilor.
Pentru context tehnic de bază, merită să stăpânești noțiunile din Fișiere, permisiuni și procese în Linux: baza pentru analiză și administrare sigură, deoarece multe observații se reduc la cine a rulat ce, cu ce drepturi și asupra căror fișiere.
Date utile care pot fi colectate defensiv
Colectarea trebuie adaptată procedurilor organizației, dar câteva categorii apar frecvent în incidente Linux. În zona de sistem, documentezi distribuția, versiunea kernelului, ora sistemului, utilizatorii relevanți, grupurile și configurațiile de acces administrativ. Pentru partea de activitate, notezi procesele vizibile, serviciile active, conexiunile existente și joburile programate, fără să oprești procese doar ca să „fie mai curat”.
Logurile sunt esențiale, dar trebuie tratate ca dovezi, nu ca material de editat. Manualul journalctl descrie instrumentul ca interfață pentru interogarea jurnalului systemd; folosește-l pentru export sau consultare conform politicii interne, nu pentru modificarea istoricului. Dacă investighezi accesul, articolul despre audit Linux defensiv: utilizatori, grupuri și acces sudo te ajută să formulezi întrebările corecte fără să sari direct la concluzii.
Pentru fișiere suspecte, documentează calea, proprietarul, permisiunile, dimensiunea și timpii afișați de sistem. Manualul stat arată că utilitarul afișează starea fișierului sau a sistemului de fișiere, iar sha256sum calculează și verifică digesturi SHA-256. Un hash nu spune dacă fișierul este malware, dar ajută la identificarea aceleiași copii în timp și între sisteme.
Cum reduci modificarea dovezilor
Orice acces poate schimba ceva: timpi de acces, loguri, cache sau procese. De aceea, lucrează pe cât posibil cu copii, medii montate doar pentru citire și canale controlate de colectare. Dacă organizația are proceduri forensic, urmează-le. Dacă nu, documentează explicit ce ai făcut și de ce, inclusiv limitările: de exemplu, faptul că sistemul era în producție și nu putea fi oprit imediat.
Nu instala instrumente noi pe serverul suspect fără aprobare, pentru că poți suprascrie spațiu relevant sau introduce artefacte noi. Nu „repari” permisiuni, nu șterge conturi și nu modifică servicii înainte ca dovezile necesare să fie conservate. Dacă vezi servicii neașteptate, compară observațiile cu o bază defensivă, precum cum identifici servicii active care nu ar trebui să ruleze pe un server Linux, dar păstrează investigația orientată pe observare.
Ce predai la final
Un pachet minim de incident include cronologia, sistemele afectate, datele colectate, hashurile fișierelor copiate, persoanele implicate, deciziile luate și întrebările rămase deschise. Raportul nu trebuie să pară mai sigur decât dovezile. Scrie ce știi, ce nu știi și ce trebuie verificat în continuare.
Pentru carieră, acesta este un semn de maturitate: un bun analist nu este cel care rulează cele mai multe comenzi, ci cel care protejează integritatea informațiilor și poate explica, peste o lună, cum a ajuns la fiecare concluzie.
Întrebări frecvente
Trebuie să opresc imediat serverul după un incident Linux?
Nu există o regulă universală în articol: decizia depinde de procedurile organizației, rolul serverului și nevoia de conservare a datelor volatile. Înainte de acțiuni majore, documentează starea inițială și limitele intervenției.
De ce sunt utile hashurile fișierelor copiate?
Un hash nu confirmă singur că un fișier este rău intenționat, dar ajută la identificarea aceleiași copii în timp și între sisteme. El face parte din documentarea pachetului de incident.
Pot edita logurile ca să scot informațiile sensibile?
Nu pe sistemul afectat și nu în materialul păstrat ca dovadă. Logurile trebuie tratate ca dovezi; dacă ai nevoie de o versiune redactată pentru raportare, păstrează separat originalul conform politicii interne.
Ce ar trebui să conțină raportul final?
Raportul ar trebui să includă cronologia, sistemele afectate, datele colectate, hashurile fișierelor copiate, persoanele implicate, deciziile luate și întrebările rămase deschise.
