Skaner podatności serwera

Znajduje to, co serwer WWW oddaje na zewnątrz: wycieki konfiguracji i kopii zapasowych, otwarte katalogi, wersje oprogramowania w nagłówkach, przestarzały TLS, ryzykowne punkty końcowe i błędy DNS.

• Wszystkie usługi

Większość włamań nie zaczyna się od sprytnej luki zero-day. Zaczyna się od czegoś, co serwer oddaje każdemu, kto zapyta: zapomnianego pliku .env, archiwum kopii zapasowej w katalogu głównym, wersji oprogramowania w nagłówku, która wskazuje prosto na znaną podatność. Skaner podatności serwera szuka właśnie takich słabych punktów — tych samych, których codziennie szukają zautomatyzowane boty na każdym publicznym adresie.

Co sprawdza skaner

Wycieki plików i sekretów. Skaner odpytuje adresy, pod którymi wdrożenia najczęściej coś zostawiają: .env i inne pliki konfiguracyjne, katalog .git, zrzuty bazy danych, archiwa strony .zip i .tar.gz, kopię wp-config.php, .DS_Store, strony phpinfo i server-status. Znalezisko trafia do raportu tylko wtedy, gdy potwierdza je treść odpowiedzi — prawdziwy .git/HEAD, prawdziwa lista zmiennych — więc strona odpowiadająca „200 OK” na każdy adres nie generuje fałszywych alarmów.

Otwarte katalogi i kod źródłowy. Listowanie katalogów zamienia folder w publiczny spis wszystkiego, co kiedykolwiek tam wgrano. Publiczne mapy źródeł JavaScript oddają niezminifikowany kod razem z komentarzami i wewnętrznymi ścieżkami. Oba problemy łatwo wyłączyć i oba są zgłaszane z dokładnym adresem.

Wersje oprogramowania w nagłówkach. Nagłówki w rodzaju Server: Apache/2.4.29 czy X-Powered-By: PHP/7.2.5 podpowiadają atakującemu, które znane podatności wypróbować najpierw. Skaner wymienia każdy nagłówek i fragment strony z dokładną wersją i pokazuje, jak ją ukryć w konfiguracji serwera.

Protokoły i szyfrowanie. Sprawdzamy, jakie wersje TLS i jakie certyfikaty akceptuje serwer, czy łańcuch jest kompletny, czy HTTP przekierowuje na HTTPS i czy serwer obsługuje HTTP/2 i HTTP/3. Stare protokoły same w sobie są podatnością i częstą przyczyną niezaliczenia audytów PCI DSS i podobnych.

Niebezpieczne metody i dostęp z innych źródeł. Serwer, który odpowiada na TRACE albo odbija dowolne źródło w Access-Control-Allow-Origin wraz z danymi uwierzytelniającymi, może zostać użyty przeciwko Twoim własnym odwiedzającym. Skaner wysyła nieszkodliwe żądania testowe i raportuje, co wróciło.

Punkty końcowe CMS. Dla stron na WordPressie sprawdzamy trasy odpowiadające każdemu: trasę REST z listą loginów wszystkich autorów oraz xmlrpc.php — punkt, przez który zgaduje się hasła, bo pozwala na setki prób w jednym żądaniu. Dla innych platform szukamy odsłoniętych stron administracyjnych i instalacyjnych.

DNS i perymetr. Rekordy wildcard DNS, wiszące rekordy CNAME wskazujące na nieistniejące już usługi (klasyczny scenariusz przejęcia subdomeny), brak rekordów CAA, stan DNSSEC i IPv6 — wszystko, co opisuje konfigurację samej domeny.

Bezpieczne skanowanie

Skaner niczego nie wykorzystuje. Nie zgaduje haseł, nie wysyła ładunków ataku, nie próbuje obejść uwierzytelniania i nie przeciąża serwera: żądań jest niewiele, są rozłożone w czasie i nie różnią się od tych, które wysyła zwykła przeglądarka. Dlatego można go bezpiecznie uruchamiać na produkcyjnej stronie w godzinach pracy. Oznacza to jednak, że skaner znajduje słabości konfiguracji i wycieki, a nie błędy głęboko w logice aplikacji — do nich potrzebny jest test penetracyjny za Twoją zgodą i z dostępami.

Jak wygląda raport

Każde znalezisko ma poziom — krytyczny, wysoki, średni lub niski — i wyjaśnienie prostym językiem: co dokładnie znaleziono, pod jakim adresem, co atakujący mógłby z tym zrobić i jak to zamknąć. Gdzie to możliwe, poprawka jest podana jako gotowa konfiguracja dla nginx, Apache lub platformy. Znaleziska krytyczne, jak pobieralny .env czy .git, są pokazywane na samej górze, bo trzeba je zamknąć dziś, a nie w następnym sprincie.

Regularne kontrole

Serwera nie konfiguruje się raz na zawsze: nowe wydanie, aktualizacja wtyczki czy przeprowadzka do innego hostingu mogą przywrócić stary problem. Dodaj stronę do monitoringu, a skanowanie będzie powtarzane automatycznie; nowe krytyczne znalezisko przyjdzie e-mailem lub wiadomością w Telegramie. Przez API to samo skanowanie można uruchamiać z CI po każdym wdrożeniu, aby wyciek pliku wykryć, zanim znajdzie go bot.