Krótko: Pentest czy skan podatności to nie pytanie typu albo-albo, lecz pytanie o kolejność. Skan podatności znajduje automatycznie znane luki i błędne konfiguracje, szybko i tanio, ale z fałszywymi alarmami i ślepymi plamami. Test penetracyjny sprawdza celowo, co atakujący mógłby faktycznie osiągnąć. Program bug bounty otwiera kontrolę dla zewnętrznych badaczy i opłaca się dopiero wtedy, gdy skany i pentesty należą do rutyny. Dla większości MŚP kolejność jest taka: regularnie skanować, usuwać ustalenia, zlecać celowe testy, utworzyć punkt zgłaszania podatności.
Dlaczego po PHP2Shell pytanie to pada na nowo
Kto po PHP2Shell sprawdza swoją stronę skanerem online, może otrzymać mylące wyniki. Jeden skaner zgłasza być może krytyczną lukę, choć firma hostingowa potwierdziła poprawkę. Inny nie zgłasza nic, choć serwer nadal używa starej wersji PHP, ponieważ informacja o wersji jest ukryta.
Przyczyna leży w sposobie działania. Wiele skanerów wnioskuje o podatności z wyświetlanej wersji. Dystrybucje instalują jednak backporty bez zmiany numeru wersji; według doniesień Ubuntu 24.04 po aktualizacji nadal pokazuje na przykład 8.3.6. Dlaczego tak jest, wyjaśnia artykuł Dlaczego php -v po aktualizacji pokazuje ten sam numer. Wiarygodny dowód daje dziennik zmian pakietu, zob. Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
To nie argument przeciwko skanerom, lecz za tym, aby znać ich ograniczenia i łączyć je z innymi metodami.
Pentest czy skan podatności: trzy metody w porównaniu
| Kryterium | Skan podatności | Test penetracyjny | Bug bounty |
|---|---|---|---|
| Kto sprawdza? | Zautomatyzowane narzędzie | Zlecone osoby fachowe | Zewnętrzni badacze, często przez platformę |
| Co zostaje znalezione? | Znane luki, przestarzałe wersje, błędne konfiguracje | Podatności możliwe do wykorzystania, błędy logiczne, łączenia | To, co badacze znajdą i zgłoszą, często rzeczy niezwykłe |
| Głębokość | Szeroka, ale powierzchowna | Głęboka w uzgodnionym zakresie | Różna, zależna od uczestników |
| Fałszywe alarmy | Częste | Rzadkie, ustalenia są dokumentowane | Wiele zgłoszeń, które trzeba ocenić |
| Planowalność | Wysoka, dowolnie powtarzalny | Wysoka, stały okres i zakres | Niska, zgłoszenia napływają na bieżąco |
| Warunki w firmie | Ktoś, kto ocenia wyniki | Uzgodniony zakres, środowisko testowe lub okno serwisowe | Dojrzały proces oceny, usuwania i nagradzania |
| Typowe zastosowanie | Stale, np. co miesiąc lub po zmianach | Przed startem, po większych zmianach, regularnie | Uzupełniająco przy dojrzałych, eksponowanych aplikacjach |
Żadna z metod nie zastępuje pozostałych. Skan pokazuje dużo w krótkim czasie, pentest pokazuje to, co naprawdę się liczy, a bug bounty znajduje to, o czym nikt nie pomyślał.
Przy skanerach warto też przyjrzeć się rodzajowi skanu. Skan z zewnątrz widzi tylko to, co widzi każdy odwiedzający, i wersje musi często zgadywać z odpowiedzi serwera. Skan uwierzytelniony, w którym narzędzie z własnymi danymi logowania odczytuje zainstalowane pakiety na serwerze, daje wyraźnie wiarygodniejsze wyniki, zwłaszcza co do rzeczywistego stanu pakietu PHP. Wymaga jednak, aby założyli Państwo w tym celu ograniczony dostęp i dobrze go chronili. Dla zależności własnych aplikacji PHP istnieją z kolei osobne narzędzia kontrolne, na przykład composer audit dla pakietów z Composera.
Sensowna kolejność dla MŚP
- Inwentarz i skan: Najpierw wiedzieć, jakie strony i serwery istnieją, potem regularnie skanować. Ustaleń nie przejmować bez sprawdzenia, lecz je oceniać.
- Usunąć podstawy: Wyeliminować przestarzałe oprogramowanie, brakujące aktualizacje i oczywiste błędne konfiguracje. Zlecanie pentestu na niezałatanych systemach marnuje budżet.
- Celowy test penetracyjny: Dla najważniejszych aplikacji, na przykład sklepu, portalu klientów lub interfejsów, z jasno uzgodnionym zakresem i testem końcowym.
- Kontrola kodu przy własnych rozwiązaniach: Kto prowadzi własne aplikacje PHP, uzupełnia test o przegląd kodu źródłowego. Jak to przebiega, opisuje artykuł Przegląd kodu pod kątem bezpieczeństwa w projektach PHP.
- Punkt zgłaszania podatności: Polityka określająca, jak osoby z zewnątrz mogą zgłaszać luki, i plik security.txt zgodny z RFC 9116 pod
/.well-known/security.txtz kontaktem i datą ważności. - Bug bounty, gdy podstawy stoją: Dopiero gdy zgłoszenia są rzetelnie oceniane, a luki sprawnie usuwane.
Aby z tego powstał trwały przebieg, warto spojrzeć na Zarządzanie podatnościami w średnich firmach.
Czego żadna z metod nie zapewnia
Żadna metoda kontroli nie dowodzi, że system jest bezpieczny. Pokazuje tylko to, co w danym momencie znaleziono określonymi metodami. Czysty raport z pentestu z wiosny nic nie mówi o luce takiej jak PHP2Shell, która staje się znana w październiku.
Podobnie skan ani pentest nie odpowiadają na pytanie, czy serwer został już skompromitowany. Do tego potrzebne jest poszukiwanie śladów w samym systemie: procesy, pliki, zadania cron, konta, połączenia. To osobne zadanie z własnymi metodami.
Proszę sprawdzać tylko systemy, do których są Państwo uprawnieni, i w przypadku systemów hostowanych wcześniej wyjaśnić zasady dostawcy. Test penetracyjny wymaga pisemnego zlecenia z zakresem, okresem i osobami kontaktowymi.
Kiedy nie potrzebują Państwo zewnętrznego testu
Dla prostej strony firmowej bez formularzy z wrażliwymi danymi, u firmy hostingowej rzetelnie instalującej aktualizacje, często wystarcza regularny skan z krytyczną oceną wyników. Test penetracyjny byłby tu zwykle niewspółmierny. Ważniejsze są aktualne oprogramowanie, silne dostępy i kopie zapasowe.
Zewnętrzny test opłaca się w przypadku sklepów, portali, własnych rozwiązań, interfejsów do systemów wewnętrznych i wszędzie tam, gdzie klienci lub normy wymagają niezależnego dowodu.
Jak konkretnie pomaga PHP SOS?
- Konfigurujemy regularne skany i oceniamy wyniki, łącznie z fałszywymi alarmami wywołanymi przez backporty.
- Pomagamy usunąć podstawy, zanim pieniądze trafią do pentestu.
- Wspólnie ze specjalistycznymi partnerami przeprowadzamy audyty bezpieczeństwa i testy penetracyjne z uzgodnionym zakresem i testem końcowym.
- Wspieramy przy budowie punktu zgłaszania podatności i pliku security.txt.
Podsumowanie
Skan, pentest i bug bounty to stopnie, a nie konkurenci. Kto zacznie od regularnych skanów, usunie podstawy, a potem zleci celowe testy, otrzyma za swój budżet najwięcej bezpieczeństwa. Bug bounty to wisienka na torcie dla organizacji, których obowiązkowa część już działa.
Częste pytania
Jaka jest różnica między pentestem a skanem podatności?
Skan podatności sprawdza automatycznie, czy widoczne są znane luki lub błędne konfiguracje. Test penetracyjny idzie dalej: specjaliści w uzgodnionych ramach próbują faktycznie wykorzystać podatności, łączyć je ze sobą i oceniają skutki.
Czy skaner ustali, czy mój serwer jest załatany przeciwko PHP2Shell?
Tylko w ograniczonym zakresie. Wiele skanerów odczytuje wyświetlaną wersję PHP. Jeśli dystrybucja instaluje backport, numer często pozostaje taki sam, a skaner zgłasza lukę, która dawno jest zamknięta. I odwrotnie, może być wyświetlony nowy numer, podczas gdy stare procesy nadal działają.
Czy program bug bounty to coś dla małych firm?
Zwykle jeszcze nie. Bug bounty zakłada, że zgłoszenia są szybko oceniane, a luki sprawnie usuwane. Dobrym początkiem jest prosta polityka zgłaszania podatności z plikiem security.txt.
Czy mogę sam sprawdzić swoją stronę skanerem?
Własne systemy zazwyczaj tak, jeśli są Państwo do tego uprawnieni. Jeśli strona leży u firmy hostingowej, proszę wcześniej wyjaśnić, czy skany są dozwolone lub należy je zapowiedzieć. Obcych systemów należy sprawdzać tylko z pisemną zgodą operatora.
Jak często powinien odbywać się pentest?
Stałej reguły nie ma. Zwykle test przeprowadza się przed uruchomieniem nowej aplikacji, po większych zmianach i w regularnych odstępach, które wyznaczają Państwa ryzyko oraz ewentualne wymagania klientów lub norm.