Röviden: A pentest vagy a sebezhetőségi szkennelés nem vagy-vagy kérdés, hanem a sorrend kérdése. A sebezhetőségi szkennelés automatizáltan találja meg az ismert réseket és hibás konfigurációkat, gyorsan és olcsón, de téves riasztásokkal és vak foltokkal. A penetrációs teszt célzottan vizsgálja, mit érhetne el valójában egy támadó. A bug bounty program megnyitja a vizsgálatot külső kutatók számára, és csak akkor éri meg, ha a szkennelések és a pentestek rutinná váltak. A legtöbb kkv-nak a sorrend: rendszeresen szkennelni, kijavítani a megállapításokat, célzottan teszteltetni, sebezhetőségi bejelentő pontot felállítani.
Miért teszik fel újra a kérdést a PHP2Shell után
Aki a PHP2Shell után egy online szkennerrel vizsgálja a weboldalát, zavaros eredményeket kaphat. Az egyik szkenner kritikus rést jelent, noha a tárhelyszolgáltató megerősítette a javítást. Egy másik semmit sem jelent, noha a szerver még régi PHP-verziót használ, mert a verziókijelzés el van rejtve.
Az ok a működésmódban van. Sok szkenner a sebezhetőséget a megjelenített verzióból vezeti le. A disztribúciók azonban a verziószám módosítása nélkül telepítenek backportokat; a beszámolók szerint például az Ubuntu 24.04 a frissítés után is 8.3.6-ot mutat. Hogy ez miért van így, azt a Miért mutatja a php -v ugyanazt a számot a frissítés után magyarázza el. A megbízható igazolást a csomag changelogja adja, lásd PHP-verzió és javítási állapot helyes ellenőrzése.
Ez nem érv a szkennerek ellen, hanem amellett, hogy ismerjük a határaikat, és más eljárásokkal kombináljuk őket.
Pentest vagy sebezhetőségi szkennelés: a három eljárás összehasonlítása
| Szempont | Sebezhetőségi szkennelés | Penetrációs teszt | Bug bounty |
|---|---|---|---|
| Ki vizsgál? | Automatizált eszköz | Megbízott szakemberek | Külső kutatók, gyakran egy platformon keresztül |
| Mit talál? | Ismert réseket, elavult verziókat, hibás konfigurációkat | Kihasználható sebezhetőségeket, logikai hibákat, láncolásokat | Amit a kutatók találnak és jelentenek, gyakran szokatlant |
| Mélység | Széles, de felszínes | Mély a megállapodott terjedelemben | Változó, a résztvevőktől függ |
| Téves riasztások | Gyakoriak | Ritkák, a megállapításokat igazolják | Sok bejelentés, amelyeket értékelni kell |
| Tervezhetőség | Magas, tetszés szerint megismételhető | Magas, rögzített időszak és terjedelem | Alacsony, a bejelentések folyamatosan érkeznek |
| Feltételek a vállalkozásban | Valaki, aki értékeli az eredményeket | Egyeztetett terjedelem, tesztkörnyezet vagy karbantartási ablak | Érett folyamat az értékelésre, javításra és jutalmazásra |
| Tipikus alkalmazás | Folyamatosan, például havonta vagy módosítások után | Indítás előtt, nagyobb módosítások után, rendszeresen | Kiegészítésként érett, kitett alkalmazásoknál |
Egyik eljárás sem pótolja a többit. A szkennelés rövid idő alatt sokat mutat, a pentest megmutatja, mi számít valójában, a bug bounty pedig megtalálja azt, amire senki sem gondolt.
A szkennereknél emellett érdemes másodszor is megnézni a szkennelés fajtáját. A kívülről végzett szkennelés csak azt látja, amit minden látogató, és a verziókat gyakran a szerver válaszaiból kell kitalálnia. A hitelesített szkennelés, amelynél az eszköz saját hozzáférési adatokkal kiolvassa a szerveren telepített csomagokat, lényegesen megbízhatóbb eredményeket ad, éppen a PHP tényleges csomagállapotánál. Feltételezi azonban, hogy ehhez korlátozott hozzáférést állít be, és jól védi. A saját PHP-alkalmazások függőségeihez viszont külön ellenőrző eszközök vannak, például a composer audit a Composer csomagokhoz.
A kkv-knak értelmes sorrend
- Leltár és szkennelés: Először tudni, mely weboldalak és szerverek vannak, azután rendszeresen szkennelni. A megállapításokat nem ellenőrzés nélkül átvenni, hanem értékelni.
- Az alapok kijavítása: Az elavult szoftvert, a hiányzó frissítéseket és a nyilvánvaló hibás konfigurációkat megszüntetni. Egy pentestet javítatlan rendszerekre kiírni a költségvetés elpazarlása.
- Célzott penetrációs teszt: A legfontosabb alkalmazásokra, például webshopra, ügyfélportálra vagy interfészekre, egyértelműen megállapodott terjedelemmel és utóteszttel.
- Kódellenőrzés saját fejlesztéseknél: Aki saját PHP-alkalmazásokat üzemeltet, a tesztet a forráskód átvizsgálásával egészíti ki. Hogyan zajlik ez, azt a Biztonsági kódellenőrzés PHP-projektekhez írja le.
- Sebezhetőségi bejelentő pont: Egy irányelv arról, hogyan jelenthetnek külsők réseket, és egy RFC 9116 szerinti security.txt fájl a
/.well-known/security.txthelyen kapcsolattartóval és lejárati dátummal. - Bug bounty, ha az alapok megvannak: Csak ha a bejelentéseket megbízhatóan értékelik, és a réseket gyorsan kijavítják.
Hogy ebből tartós folyamat legyen, érdemes megnézni a Sebezhetőségkezelés a közép- és kisvállalkozásoknál cikket.
Amit egyik eljárás sem tud
Egyetlen vizsgálati eljárás sem bizonyítja, hogy egy rendszer biztonságos. Csak azt mutatja meg, mit találtak egy időpontban bizonyos módszerekkel. Egy tavaszi tiszta pentest-jelentés semmit sem mond egy olyan résről, mint a PHP2Shell, amely októberben válik ismertté.
Éppígy sem a szkennelés, sem a pentest nem válaszolja meg azt a kérdést, hogy egy szerver már kompromittált-e. Ehhez a rendszeren magán végzett nyomkeresés kell: folyamatok, fájlok, cron-feladatok, fiókok, kapcsolatok. Ez saját feladat saját módszerekkel.
Csak olyan rendszereket vizsgáltasson, amelyekhez jogosult, és hosztolt rendszereknél előtte tisztázza a szolgáltató szabályait. Egy penetrációs teszthez írásbeli megbízás kell a terjedelemmel, az időszakkal és a kapcsolattartókkal.
Mikor nincs szüksége külső tesztre
Egy egyszerű cégweboldalhoz, érzékeny adatokat tartalmazó űrlapok nélkül, olyan tárhelyszolgáltatónál, amely megbízhatóan telepíti a frissítéseket, gyakran elég egy rendszeres szkennelés az eredmények kritikus értékelésével. Egy penetrációs teszt itt többnyire aránytalan lenne. Fontosabb az aktuális szoftver, az erős hozzáférések és a mentések.
Egy külső teszt webshopoknál, portáloknál, saját fejlesztéseknél, belső rendszerekhez vezető interfészeknél és mindenütt megéri, ahol az ügyfelek vagy a szabványok független igazolást követelnek.
Hogyan segít konkrétan a PHP SOS?
- Rendszeres szkenneléseket állítunk be, és értékeljük az eredményeket, a backportok okozta téves riasztásokat is.
- Segítünk kijavítani az alapokat, mielőtt pénz folyna egy pentestbe.
- Specializált partnerekkel közösen biztonsági auditokat és penetrációs teszteket végzünk egyeztetett terjedelemmel és utóteszttel.
- Támogatjuk a sebezhetőségi bejelentő pont és egy security.txt felállítását.
Összegzés
A szkennelés, a pentest és a bug bounty fokozatok, nem versenytársak. Aki rendszeres szkenneléssel kezdi, kijavítja az alapokat, majd célzottan teszteltet, a költségvetéséért a legtöbb biztonságot kapja. A bug bounty a kűr azoknak a szervezeteknek, amelyeknél a kötelező már rendben van.
Gyakori kérdések
Mi a különbség a pentest és a sebezhetőségi szkennelés között?
A sebezhetőségi szkennelés automatizáltan vizsgálja, hogy felismerhetők-e ismert rések vagy hibás konfigurációk. A penetrációs teszt továbbmegy: szakemberek egy megállapodott keretben megpróbálják a sebezhetőségeket ténylegesen kihasználni és láncolni, és értékelik a következményeket.
Megállapítja egy szkenner, hogy a szerverem javítva van-e a PHP2Shell ellen?
Csak korlátozottan. Sok szkenner a megjelenített PHP-verziót olvassa ki. Ha a disztribúció backportot telepít, a szám gyakran ugyanaz marad, és a szkenner olyan rést jelent, amely rég le van zárva. Fordítva, új szám jelenhet meg, miközben régi folyamatok még futnak.
Való egy bug bounty program kis vállalkozásoknak?
Többnyire még nem. A bug bounty feltételezi, hogy a bejelentéseket gyorsan értékelik, és a réseket gyorsan kijavítják. Jó kezdet a sebezhetőségek bejelentésére szolgáló egyszerű irányelv egy security.txt fájllal.
Szkennelhetem magam a weboldalamat szkennerrel?
A saját rendszereit általában igen, ha jogosult rá. Ha a weboldal tárhelyszolgáltatónál van, előtte tisztázza, hogy a szkennelések engedélyezettek vagy bejelentendők-e. Idegen rendszereket csak az üzemeltető írásbeli engedélyével vizsgáljon.
Milyen gyakran legyen pentest?
Szigorú szabály nincs. Szokásos egy teszt egy új alkalmazás indítása előtt, nagyobb módosítások után és rendszeres időközönként, amelyeket az Ön kockázata és adott esetben az ügyfelek vagy a szabványok előírásai határoznak meg.