Pe scurt: Pentest sau scanare de vulnerabilități nu este o întrebare de tip ori-ori, ci una de ordine. O scanare de vulnerabilități găsește automat breșe cunoscute și configurări greșite, rapid și ieftin, dar cu alarme false și puncte oarbe. Un test de penetrare verifică țintit ce ar putea obține efectiv un atacator. Un program bug bounty deschide verificarea către cercetători externi și merită abia când scanările și pentesturile fac parte din rutină. Pentru majoritatea IMM-urilor, ordinea este: scanați regulat, remediați constatările, lăsați să se testeze țintit, înființați un punct de raportare a vulnerabilităților.
De ce întrebarea se pune din nou după PHP2Shell
Cine își verifică după PHP2Shell site-ul cu un scaner online poate primi rezultate derutante. Un scaner raportează poate o breșă critică, deși furnizorul de hosting a confirmat patchul. Altul nu raportează nimic, deși serverul folosește încă o versiune PHP veche, pentru că indicația de versiune este ascunsă.
Motivul stă în modul de lucru. Mulți scanere deduc vulnerabilitatea din versiunea afișată. Distribuțiile instalează însă backporturi fără a schimba numărul de versiune; potrivit rapoartelor, de exemplu Ubuntu 24.04 afișează în continuare 8.3.6 după actualizare. De ce este așa explică De ce php -v afișează același număr după actualizare. Dovada fiabilă o oferă changelog-ul pachetului, vezi Verificarea corectă a versiunii PHP și a nivelului de patch.
Acesta nu este un argument împotriva scanerelor, ci unul pentru a le cunoaște limitele și a le combina cu alte proceduri.
Pentest sau scanare de vulnerabilități: cele trei proceduri comparate
| Criteriu | Scanare de vulnerabilități | Test de penetrare | Bug bounty |
|---|---|---|---|
| Cine verifică? | Unealtă automatizată | Specialiști însărcinați | Cercetători externi, adesea printr-o platformă |
| Ce se găsește? | Breșe cunoscute, versiuni învechite, configurări greșite | Vulnerabilități exploatabile, erori de logică, înlănțuiri | Ce găsesc și raportează cercetătorii, adesea lucruri neobișnuite |
| Profunzime | Largă, dar superficială | Mare în domeniul convenit | Variabilă, în funcție de participanți |
| Alarme false | Frecvente | Rare, constatările sunt dovedite | Multe raportări care trebuie evaluate |
| Planificabilitate | Mare, repetabilă oricând | Mare, perioadă și domeniu fixe | Redusă, raportările sosesc continuu |
| Condiții prealabile în companie | Cineva care evaluează rezultatele | Domeniu coordonat, mediu de test sau fereastră de mentenanță | Proces matur de evaluare, remediere și recompensă |
| Utilizare tipică | Continuu, de exemplu lunar sau după modificări | Înainte de lansare, după modificări mari, regulat | Complementar, la aplicații mature, expuse |
Niciuna dintre proceduri nu le înlocuiește pe celelalte. Scanarea arată multe într-un timp scurt, pentestul arată ce contează cu adevărat, iar bug bounty găsește ceea ce nu s-a gândit nimeni.
La scanere merită și o a doua privire asupra tipului de scanare. O scanare din exterior vede doar ceea ce vede orice vizitator și trebuie adesea să ghicească versiunile din răspunsurile serverului. O scanare autentificată, în care unealta citește cu date de acces proprii pachetele instalate pe server, oferă rezultate mult mai fiabile, mai ales pentru starea reală a pachetului PHP. Ea presupune însă să configurați în acest scop un acces restricționat și să îl protejați bine. Pentru dependențele aplicațiilor PHP proprii există la rândul lor unelte proprii de verificare, de exemplu composer audit pentru pachetele din Composer.
Ordinea sensibilă pentru IMM-uri
- Inventar și scanare: Mai întâi aflați ce site-uri și servere există, apoi scanați regulat. Nu preluați constatările neverificate, ci evaluați-le.
- Remediați bazele: Eliminați software-ul învechit, actualizările lipsă și configurările greșite evidente. Programarea unui pentest pe sisteme neactualizate risipește bugetul.
- Test de penetrare țintit: Pentru aplicațiile cele mai importante, de exemplu magazinul online, portalul pentru clienți sau interfețele, cu un domeniu clar convenit și retest.
- Verificarea codului la dezvoltările proprii: Cine operează aplicații PHP proprii completează testul cu o trecere în revistă a codului sursă. Cum decurge aceasta descrie Code review de securitate pentru proiecte PHP.
- Punct de raportare a vulnerabilităților: O politică prin care terții pot raporta breșe și un fișier security.txt conform RFC 9116 la
/.well-known/security.txt, cu contact și dată de expirare. - Bug bounty, când bazele sunt stabilite: Abia când raportările sunt evaluate fiabil, iar breșele sunt remediate prompt.
Pentru ca din toate acestea să rezulte o procedură permanentă, merită o privire la Managementul vulnerabilităților în întreprinderile mijlocii.
Ce nu oferă nicio procedură
Nicio procedură de verificare nu dovedește că un sistem este sigur. Ea arată doar ce a fost găsit la un moment dat cu anumite metode. Un raport curat de pentest din primăvară nu spune nimic despre o breșă ca PHP2Shell, care devine cunoscută în octombrie.
La fel, nici scanarea, nici pentestul nu răspund la întrebarea dacă un server este deja compromis. Pentru aceasta este nevoie de o căutare de urme pe sistemul însuși: procese, fișiere, cronjoburi, conturi, conexiuni. Aceasta este o sarcină proprie, cu metode proprii.
Verificați doar sisteme pentru care sunteți autorizat și clarificați în prealabil, la sistemele găzduite, regulile furnizorului. Un test de penetrare necesită o comandă scrisă, cu domeniu, perioadă și persoane de contact.
Când nu aveți nevoie de un test extern
Pentru un simplu site de firmă fără formulare cu date sensibile, la un furnizor de hosting care instalează fiabil actualizările, este adesea suficientă o scanare regulată, cu evaluare critică a rezultatelor. Un test de penetrare ar fi aici de obicei disproporționat. Mai importante sunt software-ul actual, accesele puternice și copiile de rezervă.
Un test extern merită la magazine online, portaluri, dezvoltări proprii, interfețe către sisteme interne și oriunde clienții sau normele cer o dovadă independentă.
Cum ajută PHP SOS concret?
- Configurăm scanări regulate și evaluăm rezultatele, inclusiv alarmele false cauzate de backporturi.
- Ajutăm la remedierea bazelor înainte ca banii să curgă într-un pentest.
- Împreună cu parteneri specializați realizăm audituri de securitate și teste de penetrare cu domeniu coordonat și retest.
- Sprijinim înființarea unui punct de raportare a vulnerabilităților și a unui fișier security.txt.
Concluzie
Scanarea, pentestul și bug bounty sunt trepte, nu concurenți. Cine începe cu scanări regulate, remediază bazele și lasă apoi să se testeze țintit obține cea mai multă securitate pentru bugetul său. Bug bounty este nota de excelență pentru organizațiile a căror obligație este deja îndeplinită.
Întrebări frecvente
Care este diferența dintre pentest și scanarea de vulnerabilități?
O scanare de vulnerabilități verifică automat dacă sunt recognoscibile breșe cunoscute sau configurări greșite. Un test de penetrare merge mai departe: specialiști încearcă, într-un cadru convenit, să exploateze efectiv vulnerabilitățile, să le înlănțuie și evaluează consecințele.
Află un scaner dacă serverul meu este actualizat împotriva PHP2Shell?
Doar limitat. Mulți scanere citesc versiunea PHP afișată. Dacă distribuția instalează un backport, numărul rămâne adesea același, iar scanerul raportează o breșă care de mult este închisă. Invers, poate fi afișat un număr nou, în timp ce procese vechi rulează încă.
Este un program bug bounty potrivit pentru companii mici?
De obicei nu încă. Bug bounty presupune că raportările sunt evaluate rapid, iar breșele remediate prompt. Un bun punct de plecare este o politică simplă de raportare a vulnerabilităților, cu un fișier security.txt.
Am voie să îmi verific singur site-ul cu un scaner?
Sistemele proprii, de regulă da, dacă sunteți autorizat pentru asta. Dacă site-ul se află la un furnizor de hosting, clarificați în prealabil dacă scanările sunt permise sau trebuie anunțate. Sisteme străine verificați doar cu permisiunea scrisă a operatorului.
Cât de des ar trebui să aibă loc un pentest?
Nu există o regulă fixă. Obișnuit este un test înainte de lansarea unei aplicații noi, după modificări mai mari și la intervale regulate, determinate de riscul dumneavoastră și, dacă este cazul, de cerințele clienților sau ale normelor.