Într-un audit Linux defensiv, una dintre primele întrebări este simplă: cine are acces pe sistem și ce poate face cu acel acces? În practică, multe probleme nu pornesc de la tehnici spectaculoase, ci de la conturi vechi, grupuri prea permisive, reguli sudo uitate sau utilizatori care au primit privilegii administrative „temporar” și au rămas așa luni întregi.
Pentru cine lucrează în cybersecurity, administrare de sisteme sau DevOps, verificarea utilizatorilor, grupurilor și accesului sudo este o rutină esențială. Nu este o operațiune de atac, ci una de igienă digitală: identifici ce există, compari cu ce ar trebui să existe și documentezi diferențele.
Primul pas: inventarul conturilor
Pe Linux, conturile locale sunt descrise în mod tradițional în /etc/passwd. Documentația Linux explică faptul că acest fișier conține câmpuri precum numele utilizatorului, UID-ul, GID-ul principal, directorul home și shell-ul de login. Important: UID 0 este asociat contului privilegiat root.
Într-un audit defensiv, nu te uiți doar după numele conturilor. Verifici dacă există mai multe conturi cu UID 0, dacă apar utilizatori necunoscuți, dacă sunt conturi fără scop clar sau conturi de foști angajați care nu au fost dezactivate. Pentru o imagine mai corectă, este recomandat să folosești mecanisme care consultă sursele sistemului, nu doar fișierele locale.
Aici intră în discuție getent passwd. Pe sisteme integrate cu LDAP, Active Directory, NIS sau alte surse de identitate, /etc/passwd poate arăta doar o parte din realitate. Fișierul nsswitch.conf stabilește ordinea surselor pentru baze precum passwd, group și shadow, iar asta înseamnă că auditul trebuie să țină cont de configurația reală a sistemului.
Ce urmărești la utilizatori
Un auditor defensiv caută mai ales abateri de la normal. Conturile de sistem au de obicei UID-uri și shell-uri specifice distribuției. Conturile umane au directoare home, shell-uri interactive și o justificare de business. Dacă un server de producție are conturi personale care nu mai corespund echipei actuale, este un semnal de verificat.
Merită documentate conturile cu shell interactiv, conturile blocate, conturile fără parolă locală, conturile de serviciu și conturile cu privilegii speciale. Atenție: un cont blocat pentru login prin parolă poate avea în continuare alte forme de acces, în funcție de configurație, chei SSH, joburi programate sau servicii. De aceea, concluziile trebuie formulate prudent și verificate cu administratorul sistemului.
Grupurile: unde se ascund multe permisiuni
Grupurile sunt adesea mai importante decât par la prima vedere. Pe Ubuntu și distribuții similare, grupul sudo acordă de regulă privilegii administrative. Pe RHEL, CentOS, Rocky Linux și distribuții apropiate, grupul wheel este frecvent folosit pentru acces administrativ.
În audit, verifici apartenența la grupurile sudo, wheel, admin și la alte grupuri locale cu acces sensibil: docker, lxd, adm, systemd-journal sau grupuri create intern pentru administrare. Nu toate aceste grupuri înseamnă automat acces root, dar pot oferi vizibilitate, control asupra serviciilor sau căi legitime de administrare care trebuie justificate.
O regulă sănătoasă este principiul least privilege: fiecare utilizator primește doar accesul necesar rolului său, pentru perioada necesară. Dacă un freelancer, un cont de suport sau un cont temporar are în continuare acces administrativ complet, constatarea trebuie trecută în raport.
Accesul sudo: nu verifica doar grupul
O greșeală comună este să presupui că sudo înseamnă doar apartenența la grupul sudo sau wheel. În realitate, politica sudo este definită prin /etc/sudoers și, de obicei, prin fișierele din /etc/sudoers.d. Documentația sudoers arată că regulile pot fi aplicate utilizatorilor și grupurilor, pot limita comenzile și pot controla modul în care sunt executate.
Într-un audit defensiv, trebuie verificat cine apare direct în sudoers, ce grupuri sunt autorizate, dacă există reguli cu NOPASSWD și dacă anumite comenzi sunt permise fără parolă. NOPASSWD nu este automat greșit, dar trebuie să aibă o justificare clară și să fie limitat la cazuri controlate.
Validarea configurației este importantă. Pentru sudoers, verificarea trebuie făcută cu instrumente sigure, precum visudo -c, nu prin editări manuale riscante. O eroare de sintaxă în sudoers poate bloca administrarea sistemului sau poate crea comportamente neașteptate.
Jurnalele spun ce s-a întâmplat
Auditul nu se oprește la „cine are voie”. Trebuie verificat și „cine a folosit accesul”. sudoers poate înregistra comenzi acceptate și refuzate, iar aceste evenimente pot ajunge în syslog, journald sau fișiere dedicate, în funcție de distribuție și configurare.
Pentru un raport util, notează utilizatorii care au folosit sudo recent, comenzile administrative relevante, încercările refuzate și momentele care nu se potrivesc cu activitatea normală. Nu este nevoie să transformi auditul într-o investigație forensică completă, dar orice abatere importantă trebuie escaladată către responsabilul sistemului.
Cum arată o concluzie bună de audit
Un audit defensiv bun nu spune doar „există riscuri”. El listează conturile verificate, grupurile sensibile, regulile sudo relevante, jurnalele consultate și recomandările concrete. De exemplu: eliminarea conturilor inactive, reducerea membrilor din grupurile administrative, înlocuirea accesului complet cu reguli limitate, verificarea periodică a sudoers.d și documentarea fiecărui cont privilegiat.
Pentru cariera în cyber, acesta este unul dintre exercițiile cele mai utile: te învață să gândești în termeni de acces, responsabilitate și dovezi. În securitate, nu contează doar dacă un sistem funcționează. Contează dacă poți explica, verifica și justifica cine are voie să facă lucruri importante pe el.
