# Pentestas, Bug Bounty ar pažeidžiamumų skenavimas? Pasirinkti tinkamą patikros būdą

> Pentestas ar pažeidžiamumų skenavimas, o gal Bug Bounty? Ką randa kiekvienas patikros būdas, kur jis aklas ir kokia eilės tvarka tinka MVĮ.

Šaltinis: https://phpsos.de/lt/blog/pentest-bugbounty-scan/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** pentestas ar pažeidžiamumų skenavimas nėra „arba-arba“ klausimas, o eilės tvarkos klausimas. Pažeidžiamumų skenavimas automatizuotai randa žinomas spragas ir klaidingas konfigūracijas, greitai ir pigiai, bet su klaidingais aliarmais ir aklomis dėmėmis. Įsilaužimo testas tikslingai tikrina, ką užpuolikas iš tikrųjų galėtų pasiekti. Bug Bounty programa atveria patikrą išoriniams tyrėjams ir verta tik tada, kai skenavimai ir pentestai tampa rutina. Daugumai MVĮ eilės tvarka tokia: reguliariai skenuoti, šalinti radinius, tikslingai užsakyti testą, įsteigti pranešimo apie pažeidžiamumus punktą.

## Kodėl klausimas po PHP2Shell keliamas iš naujo

Kas po PHP2Shell tikrina savo svetainę internetiniu skeneriu, gali gauti painius rezultatus. Skeneris galbūt praneša apie kritinę spragą, nors hostingo teikėjas pataisą patvirtino. Kitas nieko nepraneša, nors serveris dar naudoja seną PHP versiją, nes versijos informacija paslėpta.

Priežastis slypi darbo būde. Daugelis skenerių pažeidžiamumą išveda iš rodomos versijos. Tačiau distribucijos įdiegia backport nekeisdamos versijos numerio; pasak pranešimų, Ubuntu 24.04 po atnaujinimo toliau rodo 8.3.6. Kodėl taip yra, paaiškina [Kodėl php -v po atnaujinimo rodo tą patį numerį](https://phpsos.de/lt/blog/php-v-zeigt-alte-nummer/). Patikimą įrodymą pateikia paketo pakeitimų žurnalas, žr. [Kaip teisingai patikrinti PHP versiją ir pataisų būseną](https://phpsos.de/lt/php2shell/php-version-pruefen/).

Tai ne argumentas prieš skenerius, o argumentas pažinti jų ribas ir derinti juos su kitais būdais.

## Pentestas ar pažeidžiamumų skenavimas: trys būdai palyginime

| Kriterijus | Pažeidžiamumų skenavimas | Įsilaužimo testas | Bug Bounty |
|---|---|---|---|
| Kas tikrina? | Automatizuotas įrankis | Pasamdyti specialistai | Išoriniai tyrėjai, dažnai per platformą |
| Kas randama? | Žinomos spragos, pasenusios versijos, klaidingos konfigūracijos | Išnaudojamos silpnybės, logikos klaidos, grandinės | Ką tyrėjai suranda ir praneša, dažnai netikėta |
| Gylis | Platus, bet paviršutiniškas | Gilus sutartos apimties ribose | Skirtingas, priklauso nuo dalyvių |
| Klaidingi aliarmai | Dažni | Reti, radiniai įrodomi | Daug pranešimų, kuriuos reikia vertinti |
| Planuojamumas | Didelis, galima kartoti kiek nori | Didelis, fiksuotas laikotarpis ir apimtis | Mažas, pranešimai ateina nuolat |
| Prielaidos įmonėje | Kas nors, kas vertina rezultatus | Suderinta apimtis, bandomoji aplinka ar aptarnavimo langas | Brandus vertinimo, šalinimo ir atlygio procesas |
| Tipinis naudojimas | Nuolat, pavyzdžiui, kas mėnesį ar po pakeitimų | Prieš paleidimą, po didesnių pakeitimų, reguliariai | Papildomai brandžioms, viešai pasiekiamoms programoms |

Nė vienas būdas nepakeičia kitų. Skenavimas per trumpą laiką parodo daug, pentestas parodo, kas tikrai svarbu, o Bug Bounty randa tai, apie ką niekas negalvojo.

Skenerių atveju verta pažvelgti ir į skenavimo rūšį. Skenavimas iš išorės mato tik tai, ką mato kiekvienas lankytojas, ir versijas turi dažnai spėlioti iš serverio atsakymų. Autentifikuotas skenavimas, kai įrankis su savo prisijungimo duomenimis nuskaito serveryje įdiegtus paketus, duoda gerokai patikimesnius rezultatus, ypač dėl faktinės PHP paketo būsenos. Tačiau jam reikia, kad tam sukurtumėte ribotą prieigą ir ją gerai apsaugotumėte. Savų PHP programų priklausomybėms yra savi patikros įrankiai, pavyzdžiui, `composer audit` Composer paketams.

## Prasminga eilės tvarka MVĮ

1. **Inventorius ir skenavimas:** pirmiausia žinoti, kokios svetainės ir serveriai yra, tada reguliariai skenuoti. Radinių neperimti netikrinant, o įvertinti.
2. **Pašalinti pagrindus:** pasenusią programinę įrangą, trūkstamus atnaujinimus ir akivaizdžias klaidingas konfigūracijas. Pentestą skirti nepataisytoms sistemoms yra biudžeto švaistymas.
3. **Tikslingas įsilaužimo testas:** svarbiausioms programoms, pavyzdžiui, parduotuvei, klientų portalui ar sąsajoms, su aiškiai sutarta apimtimi ir pakartotiniu testu.
4. **Kodo patikra savo kūriniams:** kas eksploatuoja savo PHP programas, testą papildo šaltinio kodo peržiūra. Kaip tai vyksta, aprašo [Saugumo kodo peržiūra PHP projektams](https://phpsos.de/lt/blog/sicherheits-code-review-php/).
5. **Pranešimo apie pažeidžiamumus punktas:** politika, kaip išoriniai asmenys gali pranešti apie spragas, ir security.txt failas pagal RFC 9116 adresu `/.well-known/security.txt` su kontaktu ir galiojimo pabaigos data.
6. **Bug Bounty, kai pagrindai sutvarkyti:** tik kai pranešimai patikimai vertinami, o spragos greitai šalinamos.

Kad iš to atsirastų pastovi eiga, verta pažiūrėti į [Pažeidžiamumų valdymas vidutinėms įmonėms](https://phpsos.de/lt/blog/schwachstellenmanagement-mittelstand/).

## Ko nepadaro nė vienas būdas

Joks patikros būdas neįrodo, kad sistema saugi. Jis tik parodo, kas tam tikru momentu tam tikrais metodais buvo rasta. Švari pavasario pentesto ataskaita nieko nesako apie tokią spragą kaip PHP2Shell, paaiškėjusią spalį.

Taip pat nei skenavimas, nei pentestas neatsako į klausimą, ar serveris jau kompromituotas. Tam reikia pėdsakų paieškos pačioje sistemoje: procesų, failų, cron užduočių, paskyrų, ryšių. Tai atskira užduotis su savais metodais.

> **Svarbu:**
> Tikrinkite tik sistemas, kurioms turite teisę, o prieglobos sistemoms iš anksto išsiaiškinkite teikėjo taisykles. Įsilaužimo testui reikia rašytinio užsakymo su apimtimi, laikotarpiu ir kontaktiniais asmenimis.

## Kada išorinio testo nereikia

Paprastai įmonės svetainei be formų su jautriais duomenimis, pas hostingo teikėją, kuris patikimai diegia atnaujinimus, dažnai pakanka reguliaraus skenavimo su kritišku rezultatų vertinimu. Pentestas čia dažniausiai būtų neproporcingas. Svarbiau aktuali programinė įranga, stiprios prieigos ir atsarginės kopijos.

Išorinis testas verta parduotuvėms, portalams, savo kūriniams, sąsajoms su vidinėmis sistemomis ir visur, kur klientai ar normos reikalauja nepriklausomo įrodymo.

## Kaip PHP SOS padeda konkrečiai?

- Nustatome reguliarius skenavimus ir vertiname rezultatus, įskaitant dėl backport kylančius klaidingus aliarmus.
- Padedame pašalinti pagrindus, kol pinigai dar neinvestuoti į pentestą.
- Kartu su specializuotais partneriais atliekame [saugumo auditus ir įsilaužimo testus](https://phpsos.de/lt/leistungen/sicherheitsaudit-penetrationstest/) su suderinta apimtimi ir pakartotiniu testu.
- Padedame sukurti pranešimo apie pažeidžiamumus punktą ir security.txt.

## Išvada

Skenavimas, pentestas ir Bug Bounty yra pakopos, o ne konkurentai. Kas pradeda nuo reguliarių skenavimų, pašalina pagrindus ir tik tada užsako tikslingą testą, už savo biudžetą gauna daugiausia saugumo. Bug Bounty yra papildoma pakopa organizacijoms, kurių pagrindinės pareigos jau sutvarkytos.


## Dažni klausimai

**Kuo skiriasi pentestas ir pažeidžiamumų skenavimas?**  
Pažeidžiamumų skenavimas automatizuotai tikrina, ar atpažįstamos žinomos spragos ar klaidingos konfigūracijos. Įsilaužimo testas (pentestas) eina toliau: specialistai sutartu mastu bando tas silpnybes iš tikrųjų išnaudoti ir sujungti bei įvertina pasekmes.

**Ar skeneris išsiaiškina, ar mano serveris pataisytas nuo PHP2Shell?**  
Tik ribotai. Daugelis skenerių nuskaito rodomą PHP versiją. Jei distribucija įdiegia backport, numeris dažnai lieka tas pats, o skeneris praneša apie spragą, kuri seniai uždaryta. Atvirkščiai, gali būti rodomas naujas numeris, nors seni procesai dar veikia.

**Ar Bug Bounty programa tinka mažoms įmonėms?**  
Dažniausiai dar ne. Bug Bounty reikalauja, kad pranešimai būtų greitai vertinami, o spragos greitai šalinamos. Geras įėjimas yra paprasta pranešimo apie pažeidžiamumus politika su security.txt failu.

**Ar savo svetainę galiu pats patikrinti skeneriu?**  
Savo sistemas paprastai taip, jei turite tam teisę. Jei svetainė yra pas hostingo teikėją, iš anksto išsiaiškinkite, ar skenavimai leidžiami arba ar apie juos reikia pranešti. Svetimas sistemas tikrinkite tik turėdami raštišką operatoriaus leidimą.

**Kaip dažnai turėtų vykti pentestas?**  
Nustatytos taisyklės nėra. Įprasta atlikti testą prieš naujos programos paleidimą, po didesnių pakeitimų ir reguliariais intervalais, kuriuos lemia jūsų rizika ir, jei yra, klientų ar normų reikalavimai.

## Šaltiniai

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [security.txt (RFC 9116)](https://securitytxt.org/)
- [BSI](https://www.bsi.bund.de/)