Un job entry-level în SOC sau administrare Linux nu începe cu „tool-ul magic”, ci cu loguri curate, complete și ușor de corelat. Dacă un server trimite către SIEM evenimente fără hostname stabil, fără timp sincronizat sau cu mesaje amestecate, analiza devine lentă exact când contează. Pentru cine învață Linux pentru Cyber, pregătirea logurilor este un exercițiu foarte bun: combină disciplină operațională, înțelegerea sistemului și gândire defensivă.
Ce trebuie să ajungă în SIEM
Un SIEM are valoare când primește evenimente relevante, nu zgomot exportat la întâmplare. Pornește de la trei familii de loguri: autentificare, servicii de sistem și audit. Pentru autentificare, sunt utile evenimentele legate de login, sudo, SSH și schimbări de conturi. Pentru servicii, urmărești daemonii expuși, erorile repetate și repornirile. Pentru audit, colectezi evenimentele definite prin politica organizației, nu tot ce poate produce kernelul.
Pe systemd, journald este punctul natural de pornire pentru multe distribuții. Documentația journald.conf descrie opțiuni precum stocarea, compresia, sigilarea și forwardarea către syslog. Asta nu înseamnă că activezi orice opțiune pe un server critic fără test: verifici întâi politica internă, spațiul pe disc și fluxul existent. Dacă vrei un exercițiu separat de investigare, articolul despre analiza logurilor de autentificare Linux și tentative suspecte explică ce semnale merită urmărite.
Normalizează înainte să colectezi masiv
În SIEM, câmpurile consecvente sunt mai importante decât mesajele frumoase. Elastic Common Schema definește un set comun de câmpuri pentru evenimente, inclusiv loguri și metrici, cu nume și tipuri de date. Chiar dacă nu folosești Elastic, ideea rămâne utilă: stabilește cum notezi hostul, utilizatorul, serviciul, severitatea, acțiunea și rezultatul.
Pentru syslog, rsyslog permite template-uri, adică formate controlate pentru ieșire. În practică, asta te ajută să trimiți evenimente într-un format previzibil către colector. Evită transformările care șterg contextul original. Păstrează mesajul brut într-un câmp separat, iar câmpurile normalizate folosește-le pentru căutare și alerte.
Checklist defensiv, înainte de conectarea la SIEM:
- verifică hostname-ul și convenția de numire a serverelor;
- sincronizează timpul prin mecanismul aprobat intern;
- stabilește ce loguri sunt necesare pentru securitate și ce loguri sunt doar zgomot;
- păstrează severitatea, serviciul, procesul și identificatorul evenimentului, unde există;
- testează pe staging sau pe un server non-critic înainte de producție.
Auditd și syslog: atenție la interpretare
Auditd poate produce evenimente valoroase pentru investigații, dar are nevoie de reguli clare. Pluginul audisp-syslog este descris ca mecanism de trimitere a evenimentelor de audit către syslog. Documentația sa menționează opțiuni pentru facility, nivel și interpretarea evenimentelor. Observația importantă pentru carieră: „mai detaliat” nu înseamnă automat „mai sigur”. Dacă transformi evenimentele prea agresiv, riști să pierzi date utile sau să produci câmpuri greu de comparat între sisteme.
Într-un mediu real, separă trei lucruri: generarea evenimentului, transportul și analiza. Auditd generează sau colectează evenimente conform regulilor. Syslog sau agentul de colectare le transportă. SIEM-ul le normalizează, le corelează și le păstrează conform politicii. Pentru context Linux mai larg, poți lega acest pas de auditul defensiv al utilizatorilor, grupurilor și sudo și de verificările de fișiere, permisiuni și procese Linux.
Calitatea logurilor este o competență de carieră
NIST SP 800-92 tratează log management ca proces, nu ca simplă instalare de software. Pentru un junior, asta schimbă întrebarea: nu „ce SIEM știi?”, ci „poți explica ce colectezi, de ce, unde se pierde contextul și cum verifici că alerta se bazează pe date corecte?”.
Un exercițiu bun pentru portofoliu este să documentezi un flux simplu: journald sau syslog local, template predictibil, câteva evenimente de autentificare, câmpuri normalizate și o regulă de alertare defensivă. Nu publica loguri reale cu utilizatori, IP-uri interne sau nume de servere. Anonimizează exemplele și explică limitele.
Pregătirea pentru SIEM nu înseamnă să colectezi tot. Înseamnă să păstrezi evenimentele care ajută la investigație, să le trimiți într-un format stabil și să poți demonstra că fluxul funcționează. Aceasta este o competență practică, apreciată atât în Linux, cât și în securitate.
Întrebări frecvente
Trebuie să trimit toate logurile Linux către SIEM?
Nu. Începe cu logurile relevante pentru autentificare, servicii și audit, apoi elimină zgomotul care nu ajută investigația sau alertarea.
De ce contează normalizarea logurilor?
Normalizarea face evenimentele comparabile între sisteme. Câmpuri consecvente pentru host, utilizator, serviciu, severitate și rezultat ajută căutarea, alertele și corelarea.
Pot folosi journald și rsyslog împreună?
Da, în multe medii journald este sursa locală, iar syslog sau un agent dedicat transportă evenimentele către colector. Configurația trebuie testată înainte de producție.
Ce pot pune într-un portofoliu de începător?
Un flux defensiv simplu: sursă de loguri, format predictibil, câmpuri normalizate, câteva evenimente de autentificare și o regulă de alertare, fără date reale sau sensibile.
