Rekonesans HTTP/HTTPS W Praktyce: Nmap i skrypty NSE

Co znajdziesz w tym artykule?

1 Od czego zaczyna się rekonesans webowy
2 Szybki rekonesans interfejsów webowych – na czym polega?
3 Jak wykorzystać skrypty Nmap (NSE) do rekonesansu aplikacji webowych?
4 Praktyczny przykład: szybki rekonesans aplikacji webowej za pomocą Nmap
5 Inne przydatne skrypty Nmap do rekonesansu aplikacji webowych
6 Skrypt → co daje → kiedy używać
7 Co dalej zrobić z wynikami rekonesansu?
8 Dlaczego to ma znaczenie
9 Checklista szybkiego rekonesansu interfejsów webowych
10 Podsumowanie
11 Bibliografia

Od czego zaczyna się rekonesans webowy

Co można zrobić po przeskanowaniu sieci i znalezieniu otwartych portów HTTP/HTTPS? Załóżmy, że Nmap pokazał nam hosty nasłuchujące na porcie 80 lub 443 – chcemy teraz szybko sprawdzić, jakie aplikacje webowe tam działają. Oczywiście można ręcznie wklepać każdy adres w przeglądarce, ale inżynierska ciekawość i lenistwo podsuwają lepsze rozwiązanie: użyjmy możliwości Nmap Scripting Engine (NSE).

Nmap to nie tylko skaner portów. Więcej o samym narzędziu możesz przeczytać w artykule Kompletny Przewodnik Po Nmap – Od Skanowania Portów Po Zaawansowaną Analizę. Dzięki skryptom NSE Nmap potrafi automatycznie zebrać cenne informacje o webowych interfejsach aplikacji. Brzmi jak coś w sam raz dla nas? No to do dzieła – zobaczmy, jak zrobić szybki rekonesans (ang. recon) aplikacji webowej za pomocą sprytnego skryptu Nmapa.

Szybki rekonesans interfejsów webowych – na czym polega?

Rekonesans interfejsu webowego polega na zebraniu podstawowych informacji o aplikacji działającej pod danym adresem URL lub IP, bez zagłębiania się w szczegóły implementacyjne. Chcemy w szybki sposób odpowiedzieć na pytania: Jaka to aplikacja? Na jakim serwerze działa? Jak się identyfikuje? Czy ma ukryte pliki lub katalogi? Taki rekonesans mapuje nam powierzchnię ataku – ujawnia elementy, które mogą być potencjalnymi punktami wejścia dla ataku lub dalszej analizy. W praktyce sprowadza się to do kilku kluczowych czynności:

Odczyt banera lub nagłówków HTTP serwera – dzięki temu dowiemy się, jakiego rodzaju serwer HTTP działa (np. Apache, Nginx, IIS) i często poznamy jego wersję. Identyfikacja wersji serwera jest ważna, bo starsze wersje mogą mieć znane podatności. To tzw. fingerprinting serwera webowego.
Sprawdzenie tytułu strony (HTML Title) – tytuł strony bywa prostą, ale cenną informacją. Panel administracyjny routera może mieć tytuł "Admin - Login", drukarka sieciowa zdradzi model w tytule, a system CMS może wyświetlić nazwę witryny. Mając tytuł, łatwiej zorientować się, z czym mamy do czynienia.
Pobranie podstawowych plików konfiguracyjnych/metadanych – np. pliku robots.txt lub innych metafiles. Plik robots.txt potrafi wskazać ukryte ścieżki w aplikacji (te, których nie powinni indeksować crawlery). Bywa tak, że właśnie tam znajdziemy odnośniki do paneli administracyjnych lub innych wrażliwych części aplikacji.
Sprawdzenie dozwolonych metod HTTP – domyślnie każda aplikacja obsługuje GET i POST, ale czy pozwala np. na PUT, DELETE, TRACE? Metoda OPTIONS pozwala zapytać serwer o obsługiwane metody. Jeśli serwer akceptuje np. PUT albo DELETE, może to wskazywać na potencjalnie niebezpieczną funkcjonalność (np. możliwość przesłania pliku na serwer).
Wykrycie popularnych aplikacji i katalogów – szybki rekonesans może obejmować próbę enumeracji powszechnie występujących ścieżek lub plików. Na tej zasadzie działa np. narzędzie Nikto – sprawdza istnienie tysięcy znanych plików (jak /admin, /phpmyadmin, /backup.zip itp.). Podobnie możemy użyć skryptu Nmap, który spróbuje odnaleźć ślady popularnych aplikacji webowych (WordPress, Joomla, phpMyAdmin, panel admina urządzeń itp.) poprzez sprawdzanie znanych URL-i.

Wszystkie powyższe czynności możemy wykonać ręcznie – np. telnetem, przeglądarką lub komendami curl (curl -I do sprawdzenia nagłówków, curl --head lub zwykłe curl do pobrania strony, itp.). W istocie, każdą z akcji można zrealizować ręcznie za pomocą np. wget lub curl. Jednak przy większej liczbie hostów lub gdy chcemy zautomatyzować proces, ręczne klikanie szybko staje się niepraktyczne. Tu właśnie wkracza Nmap ze swoimi skryptami NSE – pozwalając wykonać cały ten rekonesans z poziomu jednego skanera, nawet na wielu hostach jednocześnie.

Jak wykorzystać skrypty Nmap (NSE) do rekonesansu aplikacji webowych?

Nmap od wersji 5 umożliwia użycie Nmap Scripting Engine (NSE) – wbudowanego mechanizmu, który potrafi uruchamiać skrypty napisane w Lua podczas skanowania. Skrypty te mogą wykonywać przeróżne zadania: od prostego pobrania banera, przez sprawdzanie konfiguracji, aż po symulację logowania czy exploitowanie podatności. Nas oczywiście interesują skrypty związane z protokołem HTTP i aplikacjami webowymi.

Jak uruchomić skrypty NSE? Nmap daje kilka opcji. Najprostsza to użycie przełącznika -sC, który uruchamia domyślny zestaw skryptów na wykrytych portach (to skrót od --script=default). W kontekście HTTP domyślne skrypty obejmują m.in. pobranie tytułu strony, sprawdzenie metod HTTP oraz pliku robots.txt – czyli dokładnie to, czego potrzebujemy w podstawowym rekonesansie. Innym podejściem jest jawne wskazanie skryptu lub całej kategorii skryptów parametrem --script. Przykładowo:

nmap -sV --script=http-title <target> – spróbuje pobrać tytuł strony z hosta (lub wielu hostów).
nmap -sV --script "http-*" <target> – uruchomi wszystkie skrypty, których nazwa zaczyna się od „http-„. To potężne, ale ryzykowne – niektóre z nich mogą być inwazyjne.
nmap -sV --script "default or (discovery and safe)" <target> – uruchomi skrypty z kategorii default lub discovery, które są oznaczone jako safe (bezpieczne).

Na marginesie: Skrypty NSE pogrupowane są w kategorie (np. default, safe, intrusive, vuln, discovery, itp.). Skrypty typu safe nie powinny negatywnie wpływać na skanowany system. Inne, jak intrusive czy brute, mogą powodować większe obciążenie lub odciski w logach – używaj ich z rozwagą. Domyślnie -sC uruchamia tylko bezpieczne skrypty z kategorii default.

W kontekście rekonesansu webowego, wiele ciekawych skryptów należy do kategorii discovery. Możemy je wykorzystać, by automatycznie wykonać czynności, które normalnie zrobilibyśmy ręcznie lub przy pomocy np. OWASP ZAP/Burpa. Np. zamiast otwierać każdą stronę w przeglądarce po kolei, skrypt http-title przeiteruje przez listę adresów IP i wyciągnie tytuły wszystkich stron, dając nam szybki przegląd urządzeń i serwisów. Podobnie http-headers zautomatyzuje to, co daje curl -I, zwracając nam nagłówki HTTP w raporcie Nmap. A co ze wspomnianym wyszukiwaniem ścieżek znanych aplikacji? Tu przychodzi z pomocą skrypt http-enum, który działa analogicznie do Nikto – próbuje odpalić ponad 2000 popularnych URL-i i sprawdza, co zwróci serwer.

Kluczową zaletą użycia Nmap do takiego rekonesansu jest skala i szybkość. Nmap może objąć skanem całą podsieć i od razu zebrać podstawowe informacje o wszystkich dostępnych interfejsach webowych. Wyobraź sobie, że masz do przeanalizowania 50 serwerów w sieci lokalnej – zamiast sprawdzać każdy ręcznie, jednym poleceniem Nmap możesz otrzymać listę adresów i np. tytułów stron czy typów serwerów. Otrzymujesz wstępny inventory usług webowych. Jednocześnie, dzięki możliwości filtrowania skryptów, masz kontrolę nad tym, jak głęboki i agresywny będzie skan. Na początek zwykle warto trzymać się skryptów safe – nie wywołają one destrukcyjnych akcji, a dają dużo informacji.

Podsumowując: Nmap + NSE to doskonały duet do szybkiego rekonesansu. Pokażemy teraz krok po kroku, jak wykorzystać konkretny skrypt Nmapa do błyskawicznej inspekcji aplikacji webowej.

Praktyczny przykład: szybki rekonesans aplikacji webowej za pomocą Nmap

Środowisko testowe i zakres skanowania

Aby przeprowadzić demonstrację, potrzebujemy środowiska testowego. Załóżmy, że mamy testowy serwer webowy dostępny pod adresem 192.168.56.101. Na serwerze działa przykładowa aplikacja – powiedzmy, że jest to strona oparta o WordPress na serwerze Apache (typowe środowisko LAMP). Port 80 jest otwarty i to nasz cel rekonesansu. Możemy sobie wyobrazić, że ten host został wykryty w poprzednim kroku (skanowaniu portów) i teraz chcemy zebrać o nim więcej informacji.

Zakres skanowania w tym przykładzie ograniczymy do pojedynczego hosta i portu 80, aby skupić się na interfejsie webowym tej jednej aplikacji. Oczywiście nic nie stoi na przeszkodzie, by skierować Nmap na całą podsieć (np. 192.168.56.0/24) – wówczas skrypt przeskanuje każdą maszynę pod kątem wskazanych usług.

Uwaga: Pamiętaj, żeby zawsze mieć zgodę na skanowanie danego hosta. My działamy w kontrolowanym labie. W prawdziwym audycie bezpieczeństwa upewnij się, że zakres i metody skanowania są uzgodnione z właścicielem infrastruktury.

Uruchomienie skanowania Nmap z odpowiednim skryptem

Do szybkiego rekonesansu naszej aplikacji użyjemy wspomnianego wcześniej skryptu http-enum. Dlaczego akurat jego? Ponieważ daje przekrojowy obraz aplikacji webowej: próbuje wykryć pliki, katalogi i znane aplikacje webowe na podstawie domyślnych ścieżek. To coś w rodzaju „szybkiego rentgena” dla strony – w kilka sekund dowiemy się, czy strona ma np. otwarty panel logowania WordPressa, plik konfiguracyjny phpMyAdmin czy katalogi z listingiem. Skrypt ten nie wymaga żadnych specjalnych uprawnień – po prostu wysyła mnóstwo zwykłych zapytań HTTP GET do różnych URL-i i obserwuje odpowiedzi.

Wykonajmy skan następującym poleceniem (parametr -p80 ogranicza skan do portu 80):

nmap -p 80 --script http-enum 192.168.56.101

Po krótkiej chwili powinniśmy otrzymać wynik. Poniżej przedstawiam skrócony i najważniejszy fragment raportu Nmap:

Nmap scan report for 192.168.56.101
80/tcp open  http
| http-enum: 
|   /robots.txt: Robots file
|   /readme.html: WordPress version 3.9.2
|   /css/: Potentially interesting directory w/ listing on 'apache/2.2.22 (Ubuntu)'
|   /images/: Potentially interesting directory w/ listing on 'apache/2.2.22 (Ubuntu)'
|_  /js/: Potentially interesting directory w/ listing on 'apache/2.2.22 (Ubuntu)'

(Powyższy output został skrócony do istotnych wpisów).

Jak widać, skrypt przeskanował port 80 hosta i zwrócił listę kilku znalezisk. Omówmy, co one oznaczają.

Omówienie wyników rekonesansu

Już pobieżny rzut oka na wyniki daje nam bardzo konkretny obraz testowanej aplikacji webowej:

Wykryto plik /robots.txt – skrypt zaznaczył, że na serwerze istnieje plik Robots file, czyli właśnie robots.txt. To wskazówka, że warto podejrzeć zawartość tego pliku, bo może on zawierać listę „Disallow”, czyli ścieżek, których nie indeksować (często to administracyjne lub wrażliwe URL-e). Sam skrypt http-enum nie wypisuje tu szczegółów (po prostu widzi kod 200 OK na ten URL), ale fakt istnienia pliku już jest informacją. Pro tip: Można uruchomić dedykowany skrypt http-robots.txt albo po prostu ręcznie pobrać ten plik (curl http://192.168.56.101/robots.txt), by zobaczyć, co zawiera. W trybie zwiększonej szczegółowości Nmap potrafi wypisać nawet kilkadziesiąt pierwszych wpisów z tego pliku, co bywa przydatne, gdy robots.txt jest długi (np. jak u Google’a).
Znaleziono /readme.html: WordPress version 3.9.2 – to strzał w dziesiątkę. Skrypt wykrył plik readme.html, który jest charakterystyczny dla WordPressa i zawiera informację o wersji. Tutaj jasno podano: WordPress version 3.9.2. Dzięki temu w sekundę wiemy, że nasza aplikacja to WordPress i to w dość leciwej wersji (3.9.2 jest z 2014 roku). Dla bezpieczeństwa to cenna informacja: stare wersje WordPressa mają znane podatności, które potencjalny atakujący może chcieć wykorzystać. Już na tym etapie, wiedząc o wersji CMS, możemy sprawdzić listę CVE dla WordPressa 3.9.2 i ocenić, czy warto od razu uderzyć w znane exploity. To pokazuje, czemu rekonesans jest tak ważny – pozwala szybko namierzyć „oczko w słabym ogniwie” systemu.
Otwarty indeks katalogu /css/, /images/, /js/ – skrypt wypunktował kilka katalogów i dopisał, że są to “Potentially interesting directory w/ listing on 'apache/2.2.22 (Ubuntu)’”. Innymi słowy, serwer Apache nie ma wyłączonego listingu katalogów w tych lokalizacjach. Jeśli wejdziemy np. na http://192.168.56.101/css/, prawdopodobnie zobaczymy listę plików .css w tym folderze (zamiast 403 Forbidden albo przekierowania). Same katalogi /css, /images, /js zwykle zawierają statyczne zasoby strony, więc raczej nie ma w nich wrażliwych danych – ale fakt, że listing jest włączony, może świadczyć o niedopatrzeniu w konfiguracji serwera. Czasem w takich katalogach admini przez pomyłkę zostawią np. plik backup.zip albo stare wersje plików – a wtedy gratis odkrywamy coś ciekawego. Na razie jednak odnotujmy: listing jest włączony, co podpada pod kategorę misconfiguration (OWASP zalicza takie rzeczy do problemów bezpieczeństwa konfiguracji).
Informacja o serwerze: Apache/2.2.22 (Ubuntu) – warto zwrócić uwagę, że przy każdym katalogu w wynikach pojawia się nazwa serwera: 'apache/2.2.22 (Ubuntu)'. Skąd to się wzięło? Skrypt http-enum wykrył te katalogi na podstawie odpowiedzi serwera, a w odpowiedzi (najpewniej w nagłówku Server lub w stopce strony z listingiem) widoczny jest właśnie identyfikator serwera. Tak więc mimo że nie użyliśmy -sV, i tak dostaliśmy banner serwera: Apache 2.2.22 na Ubuntu. To kolejna istotna informacja – Apache 2.2.x to bardzo stara gałąź (obecnie od dawna mamy 2.4.x). Serwer zapewne nie był aktualizowany, co w połączeniu z przestarzałym WordPressem potwierdza obraz środowiska, które wymaga uwagi (idealny kandydat do audytu bezpieczeństwa!). Możemy to traktować jako czerwone flagi: stary CMS + stary serwer = prawdopodobnie wiele znanych podatności czekających na wykorzystanie.

Powyższe dane uzyskaliśmy jednym poleceniem Nmap, w czasie kilku sekund. W tle Nmap wykonał około 2000 zapytań HTTP w poszukiwaniu różnych plików i katalogów. Znalazł kilka trafień, które wypisał. Cała reszta prób (te zakończone 404 Not Found) pozostała niewidoczna dla nas, ale… nie dla serwera! Jeśli zajrzymy teraz do logów serwera HTTP na naszym testowym hostcie, zobaczymy tam mnóstwo wpisów 404 wygenerowanych przez ten skan. Każde sprawdzenie nieistniejącego URL-a to przecież odnotowany błąd w logu. Dlatego skrypt http-enum uchodzi za dość głośny – wyraźnie widać jego aktywność i łatwo go wykryć po śladach (administrator od razu zorientuje się, że ktoś bruteforce’ował ścieżki). W kontekście testów bezpieczeństwa nie jest to problem (działamy za zgodą i często w kontrolowanym oknie czasowym), ale dla prawdziwego atakującego może to oznaczać podniesienie alarmu. Warto o tym wiedzieć i w razie potrzeby używać mniej nachalnych metod lub ograniczyć zakres skanowanych ścieżek.

Nasze znaleziska można podsumować tak: szybki rekonesans wykazał, że host 192.168.56.101 to serwer Apache 2.2 na Ubuntu z zainstalowanym WordPress 3.9.2, mający włączony listing katalogów i dostępny plik robots.txt. Dla bezpieczeństwa aplikacji to zestaw potencjalnych problemów: przestarzałe oprogramowanie (zarówno CMS, jak i serwer), możliwe niepożądane ujawnianie zawartości katalogów, ewentualne wskazówki w robots.txt. Każdy z tych punktów to trop do dalszej analizy. W prawdziwym audytie bezpieczeństwa (security audit) takie informacje pozwalają priorytetyzować testy – np. wiemy, że warto od razu sprawdzić znane exploity pod tę wersję WordPressa i Apache, a także skontrolować konfigurację serwera (czy listing jest potrzebny, czy nie leżą tam jakieś ciekawsze pliki).

Na tym przykładzie widać, że rekonesans webowy jest nieoceniony na starcie testów penetracyjnych. Oczywiście http-enum to tylko jeden ze skryptów NSE, który nam to ułatwia. W następnym rozdziale przyjrzymy się innym użytecznym skryptom Nmap do szybkiej enumeracji usług webowych.

Inne przydatne skrypty Nmap do rekonesansu aplikacji webowych

Nmap posiada bogaty zestaw skryptów NSE dedykowanych protokołowi HTTP i aplikacjom webowym. Poniżej przedstawiamy kilka przydatnych skryptów (poza omówionym już http-enum), które warto znać podczas szybkiego rekonesansu webowego:

http-title – Pobiera tytuł strony (z tagu <title> lub nagłówka HTML). To szybki sposób na zidentyfikowanie aplikacji lub urządzenia. Skrypt automatycznie podąża za ewentualnymi przekierowaniami (do 5 hopów) i zwraca ostateczny tytuł strony. Przy skanowaniu wielu hostów w sieci, http-title potrafi w jednym przebiegu wypisać listę hostów z ich tytułami – co natychmiast daje kontekst, czym dana usługa jest. Przykładowo, skanując podsieć, możemy zobaczyć komunikaty typu: 401 Unauthorized (co sugeruje panel administracyjny wymagający logowania) albo konkretny tytuł jak “WorkForce 630” zdradzający, że pod danym IP działa drukarka Epson WorkForce 630. Dzięki temu od razu wiesz, że np. 192.168.1.1 to panel routera Linksys, a 192.168.1.118 to interfejs drukarki sieciowej. Bez zagłębiania się – same tytuły stron często mówią, z czym masz do czynienia.
http-headers – Wysyła zapytanie HEAD (domyślnie) do serwera i zwraca pełen zestaw nagłówków HTTP z odpowiedzi. To tak jakby zrobić curl -I – dostajemy np. Date, Server, X-Powered-By, Content-Type i inne pola. Najważniejszy bywa nagłówek Server, który ujawnia oprogramowanie serwera i często jego wersję (np. Server: Apache/2.2.14 (Ubuntu)). Ponadto możemy zobaczyć nagłówki typu X-Powered-By (np. wersję PHP czy .NET na serwerze), co również bywa przydatne do identyfikacji technologii. http-headers jest skryptem z kategorii safe, można go spokojnie uruchamiać nawet w domyślnym skanie. Warto wspomnieć, że istnieje też wariant http-security-headers, który skupia się na sprawdzeniu bezpieczeństwa nagłówków – np. czy serwer ustawia nagłówek Strict-Transport-Security, X-Frame-Options, X-XSS-Protection itp. (wg zaleceń OWASP Secure Headers Project). Taki skrypt może od razu wskazać, czy aplikacja używa dobrych praktyk związanych z nagłówkami bezpieczeństwa (np. czy nie brakuje jej nagłówka HSTS dla HTTPS, czy ustawia X-Content-Type-Options, itd.). To już bardziej szczegółowa analiza konfiguracji, ale w szybkim rekonesansie można rzucić okiem na te nagłówki.
http-methods – Sprawdza, jakie metody HTTP obsługuje serwer, wysyłając żądanie OPTIONS i testując metodami spoza listy odpowiedzi. Skrypt wypisze wspierane metody, a w trybie verbose zaznaczy, które z nich uznaje za potencjalnie niebezpieczne (czyli inne niż typowe GET, HEAD, POST, OPTIONS). Na przykład, jeżeli serwer odpowie, że dopuszcza PUT lub DELETE, skrypt to wyłapie i poda jako „rzadkie” metody do sprawdzenia. Niekoniecznie oznacza to od razu podatność, ale według OWASP Testing Guide należy każdą z tych niecodziennych metod zweryfikować pod kątem bezpieczeństwa (np. czy PUT nie pozwala zapisu plików, czy TRACE nie ujawnia nagłówków – tzw. XST). http-methods szybko daje nam obraz, czy aplikacja ogranicza się do typowego zestawu metod, czy zostawiono włączone coś ekstra (np. ślady WebDAV-u lub debugowania). Dla nas – kolejna czerwona lampka lub potwierdzenie, że konfiguracja jest standardowa.
http-robots.txt – Jak sama nazwa wskazuje, ten skrypt pobiera plik robots.txt (o ile istnieje) i wypisuje znalezione w nim ścieżki z Disallow. W trybie standardowym pokazywanych jest kilkanaście-kilkadziesiąt pierwszych wpisów, a przy wyższej werbosyjności więcej. Dzięki temu od razu w raporcie Nmap zobaczymy listę potencjalnie ukrytych URL-i, których nie powinni indeksować crawlery. Przykład: jeśli w robots.txt znajdziemy wpis Disallow: /admin, to jasne, że powinniśmy zajrzeć pod /admin – pewnie kryje się tam panel administracyjny. Skrypt ten bywa bardzo przydatny na starcie, bo webmasterzy często w dobrej wierze umieszczają w robots.txt ścieżki do rzeczy, których „nie chcą pokazywać światu”, a tym samym… paradoksalnie je ujawniają. (Wystarczy przypomnieć incydenty, gdzie plik robots.txt wymieniał Disallow: /backup – co oczywiście każdy atakujący zaraz sprawdził). Z punktu widzenia obrońcy: nigdy nie należy traktować robots.txt jako zabezpieczenia – bo jak mówi OWASP, roboty mogą go po prostu zignorować. Z naszego punktu widzenia ofensywnego: robots.txt to nasz sprzymierzeniec w znajdowaniu ciekawych dróg.
http-enum – Nasz bohater z przykładu praktycznego. Warto go wypunktować również tutaj, dla podsumowania. Skrypt ten bruteforcuje ścieżki URL w poszukiwaniu znanych plików, folderów i aplikacji. Wykorzystuje wewnętrzną bazę (inspirowaną bazą Nikto) do rozpoznawania sygnatur aplikacji na podstawie odpowiedzi. Może nawet próbować ustalić wersje niektórych web aplikacji, jeśli znajdzie charakterystyczne informacje. Jak widzieliśmy, wykrył u nas WordPressa po samym pliku readme, a mógłby też np. rozpoznać panel Citrix czy OWA po unikalnych URL-ach. Zaleta: daje szeroki obraz tego, co “siedzi” na serwerze, łącznie z aplikacjami, o których byśmy nie wiedzieli (np. ukryte sub-aplikacje pod dziwnymi URL-ami). Wada: jest inwazyjny i hałaśliwy – wysyła tysiące zapytań, co widać w logach (o czym już wspomnieliśmy). Mimo to, dla szybkiego rekonesansu w kontrolowanych warunkach jest niezastąpiony, bo potrafi w minutę wykryć zaniedbane, “schowane” aplikacje, które administratorzy uznali za niewidoczne. Warto zaznaczyć, że http-enum ma opcje dodatkowe, np. można wskazać niestandardowy base path jeśli aplikacje nie są pod / (przykład: http-enum.basepath=/owa/ żeby skanować ścieżki w obrębie /owa/).

Oprócz powyższych, istnieje cała masa innych skryptów NSE dla HTTP – od bardzo specyficznych (np. wykrywających panel Joomli, szukających plików konfiguracyjnych kopii zapasowych, testujących podatności XSS/SQLi) po te ogólnego zastosowania. Na etapie szybkiego rekonesansu zazwyczaj nie uruchamiamy od razu skryptów exploitujących podatności (to zostawiamy na później, gdy już wiemy, co potencjalnie jest dziurawe). Natomiast możemy jeszcze wspomnieć o skrypcie http-favicon, który próbuje rozpoznać aplikację po hash’u ikony favicon – działa to tak, że porównuje ikonę strony z bazą znanych ikon i na tej podstawie zgaduje np. “to jest panel VMware” itp.. Sprytne, choć działa tylko, gdy dana aplikacja/produkt ma unikalny favicon w bazie. Tego typu narzędzia pokazują, jak Nmap automatyzuje naprawdę zaawansowany recon, wykraczając poza proste sprawdzenie portów.

Skrypt → co daje → kiedy używać

Poniżej tabela najpopularniejszych skryptów NSE do rekonesansu HTTP, wraz z podsumowaniem ich funkcji i zastosowań w praktyce:

Nazwa skryptu NSE	Co wykrywa / daje	Kiedy warto go użyć
http-title	Pobiera tytuł strony (tag `<title>`) z domyślnej strony danego hosta. Ułatwia to identyfikację aplikacji lub urządzenia – np. tytuł może zdradzać nazwę produktu lub panelu (“Dell iDRAC Login” itp.).	Gdy skanujemy wiele hostów w poszukiwaniu web interfejsów – dzięki tytułom szybko zorientujemy się, co znajduje się na danej stronie (np. odróżnimy panel routera od strony www). Przydaje się też przy testach, by od razu widzieć, która usługa wymaga uwierzytelnienia (tytuł “401 Unauthorized”).
http-headers	Wykonuje zapytanie HEAD na serwer i zwraca wszystkie nagłówki HTTP z odpowiedzi. Pozwala zobaczyć m.in. banner serwera (np. Apache/Nginx + wersja), użyte technologie (nagłówki `X-Powered-By`, cookies sesyjne itp.) oraz ustawienia bezpieczeństwa (np. czy jest Strict-Transport-Security, jakie metody dozwolone – czasem ujawnia to nagłówek Allow). Analiza nagłówków pomaga wykryć brakujące zabezpieczenia oraz potencjalne podatności (np. przestarzałe wersje oprogramowania).	Zawsze na początku rekonesansu aplikacji web – aby zebrać podstawowe info o serwerze i platformie. Przydatny przed głębszym atakiem, by wiedzieć z czym mamy do czynienia (jaki serwer, język, framework) i czy zastosowano podstawowe zabezpieczenia.
http-robots.txt	Sprawdza, czy istnieje plik robots.txt i wypisuje zawarte w nim wpisy Disallow (czyli ścieżki, które administrator wyłączył z indeksowania). W trybie verbose pokaże wszystkie znalezione ścieżki.	Gdy chcemy szybko znaleźć ukryte lub wrażliwe lokacje na serwerze. Wpisy Disallow często wskazują na strony admina, sekcje testowe albo pliki, których nie chciano pokazywać wyszukiwarce – co czyni je ciekawymi celami do zbadania podczas pentestu.
http-methods	Wysyła zapytanie OPTIONS i sprawdza, jakie metody HTTP obsługuje serwer. Wymienia wszystkie dozwolone metody i wyróżnia te potencjalnie ryzykowne (czyli inne niż GET, HEAD, POST, OPTIONS). Dodatkowo potrafi testować niestandardowe metody – wysyła próbne żądania i sprawdza kody odpowiedzi, aby potwierdzić ich działanie.	Kiedy chcemy sprawdzić powierzchnię ataku protokołu HTTP. Przydaje się w wykrywaniu nieoczywistych dróg ataku – np. enabled PUT czy DELETE sugeruje możliwość nadpisania lub usunięcia zasobów, TRACE wskazuje na potencjalny XST. Ten skrypt warto uruchomić dla każdej usługi HTTP/HTTPS, by nie przegapić nietypowych metod przed przystąpieniem do testów bezpieczeństwa.
http-enum	Agresywny skan katalogów i plików – próbuje odnaleźć znane ścieżki na serwerze na podstawie obszernej listy (ponad 2000 popularnych plików/dir) podobnej do bazy Nikto. W wyniku otrzymujemy listę istniejących zasobów (np. `/admin/`, `/login.php`, `/robots.txt`, `/backup/` itp.), a nawet rozpoznanie niektórych aplikacji po sygnaturach plików (np. wersja WordPress w `readme.html`).	Gdy chcemy wykryć ukryte części aplikacji lub znane podatne pliki. Szczególnie użyteczny w późniejszej fazie rekonesansu, po identyfikacji serwera – można wtedy odpalić http-enum, by znaleźć panel administracyjny, strony testowe, pliki konfiguracyjne, kopie bazy itp. Uwaga: skrypt generuje duży ruch i hałas w logach (mnóstwo 404), więc nie jest to opcja “cicha” – raczej do testów wewnątrz sieci lub za zgodą, gdy szybko chcemy przeszukać wiele potencjalnych drzwi.
http-favicon	Pobiera favicon strony (ikonę) i porównuje jej hash z bazą znanych ikon aplikacji. Jeśli znajdzie dopasowanie, raportuje nazwę wykrytej aplikacji lub platformy. Działa to na podobnej zasadzie jak rozpoznawanie aplikacji po fingerprintach – wiele produktów web ma unikalne favicon.	Kiedy standardowe bannery i tytuły nie dają jasnej odpowiedzi jaka aplikacja działa na hoście. Np. serwer może nie zdradzać się w HTML ani nagłówkach, ale favicon.ico pasuje do konkretnego urządzenia (np. kamera, panel routera albo framework). Wtedy jednym skanem http-favicon możemy zyskać tę informację. Przydatne przy szukaniu znanych podatnych urządzeń w sieci – szybko wskaże np. “Oracle Application Express” lub “Jenkins” po ikonie, co nakieruje dalszy pentest.
http-waf-detect	Wysyła serię specjalnych żądań z “złośliwymi” payloadami i obserwuje reakcje serwera. Na tej podstawie wykrywa obecność Web Application Firewall lub systemu IDS/IPS chroniącego aplikację. Jeśli odpowiedzi na złośliwe zapytania różnią się (kody błędów, brak odpowiedzi, blokada) od normalnych, skrypt zgłasza wykrycie WAF/IDS.	Gdy podejrzewamy, że testowana aplikacja jest chroniona przez WAF – np. nasze próby ataku dziwnie się nie powiodły lub otrzymujemy komunikaty o blokadzie. Użycie tego skryptu pozwala potwierdzić istnienie WAF/IPS przed dalszym atakiem. Informacja o tym, że jest WAF, zmienia taktykę pentestera: przygotuje on payloady omijające filtrowanie, rozważy wolniejsze tempo ataku albo skupi się na lukach poza zasięgiem WAF. Krótko mówiąc – warto go użyć przed fazą exploitacji, żeby wiedzieć, na co możemy sobie pozwolić (i czy musimy działać pod radarem).
http-default-accounts	Sprawdza, czy aplikacja/web interface nie korzysta z domyślnych loginów i haseł. Skrypt rozpoznaje popularne aplikacje po typowych URL (np. `/manager/html` dla Tomcata, `/phpmyadmin/` dla phpMyAdmin) i próbuje zalogować się zestawem znanych fabrycznych poświadczeń. Jeśli się uda – zwróci znalezione działające combo.	Gdy znajdziemy panel logowania do znanej aplikacji lub urządzenia i chcemy szybko przetestować, czy zostawiono domyślne hasło. To typowe w przypadku urządzeń IoT, routerów, kamer, ale też np. frameworków (Tomcat, Jenkins, Cacti itp.). Używamy na etapie rozpoznania dostępu, bo udane logowanie na domyślne konto to zazwyczaj natychmiastowy sukces (pełen dostęp do panelu) – przykład: skrypt znalazł [Cacti] admin:admin na portalu Cacti. Jeśli nic nie znajdzie, mamy pewność, że trzeba przeprowadzić standardowe łamanie haseł lub szukać innych podatności, ale wielu początkujących adminów wciąż zostawia defaulty, więc warto to sprawdzić jako jedno z pierwszych.

Co dalej zrobić z wynikami rekonesansu?

Nmap dostarczył nam sporo informacji o znalezionych usługach webowych – teraz pora je wykorzystać. Poniżej typowe scenariusze i konkretne rekomendacje operacyjne co zrobić z danymi z takich skryptów jak http-enum, http-title, http-methods, http-headers, http-robots.txt itp.:

Wykryta znana aplikacja lub CMS (np. WordPress, Joomla) – Jeśli skan wykazał konkretny CMS lub jego wersję (np. WordPress 3.9.2 znaleziony przez plik readme.html), należy poszukać znanych podatności (CVE) dla tej wersji i sprawdzić dostępność exploitów. W przypadku WordPressa warto np. przejrzeć bazę CVE lub użyć WPScan w poszukiwaniu słabych punktów tej wersji. Następnie sprawdź, czy dostępny jest panel logowania administracyjnego (np. wp-login.php lub wp-admin dla WordPressa). Jeśli tak, rozważ próbę ataku brute-force (na podstawie słownika popularnych haseł) lub wykorzystanie znanego exploita na daną wersję aplikacji (przykładowy ciąg działań: WordPress 3.9.2 → wyszukanie CVE → sprawdzenie dostępu do /wp-login.php → atak brute-force lub odpowiedni exploit).
Znaleziony panel logowania lub interfejs admina – Gdy rekonesans ujawnił stronę logowania (np. /admin, /login, /manager itp.), kolejnym krokiem jest próba uzyskania dostępu przy pomocy domyślnych danych logowania. Wielu administratorów pozostawia fabryczne hasła, dlatego warto to sprawdzić (automatycznie zrobi to np. skrypt http-default-accounts, który wykrywa aplikację po ścieżce i testuje typowe loginy/hasła). Przykładowo, jeśli znajdziemy panel Tomcat Manager, warto spróbować domyślnych kredencji (admin:admin, tomcat:tomcat itp.), dla phpMyAdmin – root: (puste hasło) lub inne znane domyślne loginy. Gdy fabryczne dane nie działają, można rozważyć brute-force (np. Hydra, medusa) lub wykorzystanie ewentualnej podatności umożliwiającej ominięcie logowania. Warto też zweryfikować, czy interfejs nie podaje podpowiedzi (banner, tytuł strony) co do wersji – to pomoże dobrać odpowiednią metodę ataku.
Dozwolone niebezpieczne metody HTTP – Informacja z http-methods o obsługiwanych metodach może wskazać potencjalne wektory ataku. Jeśli serwer oprócz typowych GET/POST akceptuje np. PUT lub DELETE, to zapala się czerwona lampka. Metoda PUT pozwala na upload pliku na serwer – możesz spróbować wgrać plik (np. webshell lub złośliwy HTML) na zidentyfikowany URL. Jeżeli otrzymasz odpowiedź “201 Created”, plik został zapisany i możesz go wykorzystać (np. wywołanie w przeglądarce HTML-a z payloadem XSS potwierdzi lukę XSS, a wgranie skryptu .php da potencjalnie zdalne wykonanie kodu). DELETE z kolei pozwoliłaby na usunięcie zasobów – co zwykle oznacza poważną lukę (można skasować np. stronę lub ważny plik aplikacji). TRACE bywa wykorzystywana do ataku XST (Cross-Site Tracing) – jeśli włączona, można spróbować wysłać specjalne żądanie, by serwer odesłał nagłówki (w tym ciasteczka) w treści odpowiedzi. Ogólna zasada: każda metoda poza GET/HEAD/POST/OPTIONS jest potencjalnie niebezpieczna – warto dokładnie zbadać, co umożliwia. Często kolejnym krokiem będzie użycie dedykowanych skryptów (np. http-put.nse do uploadu pliku) lub narzędzi curl/Burp Suite, aby ręcznie wykorzystać daną metodę.
Ciekawe wpisy w robots.txt lub podejrzane pliki – http-robots.txt zwraca ścieżki oznaczone jako Disallow. Administratorzy często ukrywają tam wrażliwe lokacje (backupy, sekcje admin, pliki konfiguracyjne), licząc że użytkownicy ich nie znajdą. Dlatego wejdź w każdą z wykrytych ścieżek z robots.txt – może tam być np. kopia bazy (/dump.sql), kopia konfiguracji (/config.bak), katalog /admin_old/ itp. Jeżeli http-enum lub inny skan pokazał konkretne pliki (np. backup, config, ~, .old) czy katalogi, spróbuj je pobrać lub obejrzeć w przeglądarce. Często takie znaleziska to skarbnica informacji: np. backup bazy może zawierać hasła, plik konfiguracyjny może zdradzić dane dostępowe do bazy, a katalog „old” może zawierać stare, podatne wersje plików. Tego typu dane mogą umożliwić kolejny krok, np. eskalację ataku (wykorzystanie danych dostępowych, przygotowanie SQL injection z danych z bazy, itp.). W skrócie: masz ciekawy plik → pobierz → przeanalizuj zawartość → wykorzystaj pozyskane informacje.
Informacje z nagłówków HTTP – Szczegółowe banery serwera i inne nagłówki (wynik http-headers) przydają się do profilowania celu. Jeśli widzisz nagłówek Server: Apache/2.4.10 (Debian), X-Powered-By: PHP/5.4 albo ASP.NET-Version:4.0.30319, to wiesz, z czym masz do czynienia technologicznie. Stare wersje serwerów czy języków wskazują na potencjalne podatności – np. przestarzałe PHP czy Apache miewały exploity umożliwiające przejęcie kontroli (choć często wymagają dodatkowych błędów w aplikacji). To sygnał, by sprawdzić dostępne CVE dla danej wersji oprogramowania (serwera WWW, frameworka itp.) oraz czy w danej konfiguracji da się je zaatakować. Nagłówki mogą też ujawnić mniej oczywiste wektory – np. obecność X-Powered-By: JSP/2.3 zasugeruje aplikację Java (można rozważyć ataki typowe dla Javy, jak deserializacja). Z kolei brak pewnych nagłówków bezpieczeństwa (CSP, X-Frame-Options, HSTS…) sam w sobie nie daje dostępu, ale pokazuje możliwe słabości konfiguracyjne – np. brak X-Frame-Options oznacza podatność na clickjacking, a brak zabezpieczeń ciasteczek (HttpOnly, Secure) ułatwia ich przechwycenie. Te informacje wykorzystujemy głównie na etapie oceny podatności: można je wypunktować w raporcie lub połączyć z innymi atakami (np. clickjacking ułatwi exploitację, jeśli znajdziemy XSS). Reasumując: dokładnie przeanalizuj nagłówki – każdy element to wskazówka, gdzie nacisnąć dalej.
Obecność WAF/IDS – Jeśli skan (np. http-waf-detect) wykrył, że aplikacja jest chroniona przez firewall aplikacyjny (WAF) lub system wykrywania włamań (IDS/IPS), trzeba ostrożnie zaplanować dalsze kroki. W praktyce oznacza to, że proste exploity czy brute-force mogą być blokowane lub logowane. Co robić? Możliwe strategie to obejście lub wyczerpanie WAF: np. spróbować innych wektorów ataku mniej oczywistych dla reguł WAF, wysyłać payloady w zmutowanej formie (obfuskacja), korzystać z mniejszej częstotliwości zapytań, by nie wzbudzać alarmów, albo atakować inną usługę (ominąć WAF jeśli chroni tylko front-end web). Czasem pomocne jest też zidentyfikowanie konkretnego producenta WAF (np. ModSecurity, Cloudflare, F5 BIG-IP) – wtedy wiemy, jakie obejścia są znane dla tego rozwiązania. Podsumowując: wynik o istnieniu WAF to sygnał, by działać sprytniej (i przygotować się na potencjalne logi naszego ruchu u obrońców).

Dlaczego to ma znaczenie

Można zadać pytanie: po co tyle zachodu z tym rekonesansem? Czy nie wystarczy po prostu uruchomić skanowanie podatności i od razu atakować? Otóż zbieranie informacji to fundamentalny etap każdego testu bezpieczeństwa. Według OWASP i ogólnych praktyk pentesterskich, faza Information Gathering (rekonesansu) jest pierwszym krokiem, od którego zależy skuteczność dalszych działań. Kilka powodów, dla których szybki rekonesans interfejsów webowych ma ogromne znaczenie:

Identyfikacja celu i priorytetów: Dzięki rekonesansowi wiemy, z czym mamy do czynienia. Przykład z naszego labu – zamiast traktować wszystkie serwery jednakowo, od razu wiemy, że host X ma WordPressa 3.9.2 i stary Apache. To sygnał: tu prawdopodobnie znajdziemy coś ciekawego (znane exploity lub misconfigi). Inny host mógłby okazać się np. świeżo zaktualizowanym Nginxem z pustą stroną – mało interesujące. Rekonesans pozwala skupić wysiłki na najbardziej podatnych celach. Jak mówi OWASP WSTG, dokładne rozpoznanie typu i wersji serwera umożliwia testerowi dobór właściwych metod ataku i znalezienie znanych podatności.
Wykrywanie “ukrytych” aplikacji: Wiele poważnych incydentów bezpieczeństwa bierze się stąd, że gdzieś w cieniu działa zapomniana aplikacja. Może pod nietypowym URL-em, na nietypowym porcie, albo pod innym wirtualnym hostem tego samego serwera. Jeśli pominiesz rekonesans, łatwo przeoczyć np. panel administracyjny dostępny pod /secret-admin albo starą wersję aplikacji działającą równolegle. Nmap potrafi to wychwycić – czy to poprzez http-enum, czy choćby skanując standardowo wszystkie popularne porty (np. ktoś wystawi aplikację na porcie 8080 i zapomni, a my ją znajdziemy). OWASP zaleca enumerację wszystkich aplikacji na serwerze właśnie po to, by mieć pełny obraz i nie zostawić “dziury” nietkniętej.
Szybkie wyłapanie misconfigurations i informacji jawnych: Rekonesans pokazuje nam od razu pewne potencjalne błędy konfiguracji: np. wspomniane directory listing, pliki README pozostawione na serwerze, brak restrykcji metod HTTP, brak nagłówków bezpieczeństwa itd. Każdy z tych elementów to albo osobna podatność (np. możliwość wgrania pliku przez PUT), albo informacja wyciekająca (np. wersja oprogramowania, struktura katalogów). W kategoriach OWASP Top 10 wiele z nich podpada pod “Security Misconfiguration” czy “Information Disclosure”. Dla pentestera to jak prezent – serwer sam mówi, gdzie go może boleć. Dla obrońcy – sygnał, co należy poprawić, zanim zrobi to atakujący. Mając te dane, możemy od razu zaplanować dalsze testy: czy próbujemy ataku XSS/SQLi, czy raczej skupiamy się na sprawdzeniu uploadu pliku, czy szukamy exploitów na starą wersję Apache, itp.
Efektywność i oszczędność czasu: Automatyzując rekonesans, oszczędzamy mnóstwo czasu. Ręczne sprawdzenie 50 hostów pod kątem tytułów stron, nagłówków i robots.txt mogłoby zająć godziny. Nmap zrobi to w parę minut i to jednym poleceniem. W testach penetracyjnych czas jest cenny – lepiej poświęcić go na kreatywne exploitowanie niż na mechaniczne sprawdzanie, jaki jest tytuł strony na każdym hostcie. Dlatego doświadczeni pentesterzy mają swoje skrypty i check-listy szybkiego rekonesansu (nierzadko właśnie z użyciem Nmapa lub podobnych narzędzi) – to fundament pracy.
Bezpieczeństwo defensywne: Warto wspomnieć, że znajomość tych technik rekonesansu pomaga także obrońcom. Skoro wiesz, co atakujący może łatwo podejrzeć, możesz się zabezpieczyć: usunąć zbędne pliki (readme, example, backupy), wyłączyć listing katalogów, ukryć wersje oprogramowania w banerach (poprzez ServerTokens/ServerSignature off w Apache, itp.), ograniczyć metody HTTP do niezbędnych, dodać nagłówki bezpieczeństwa. Innymi słowy, zmniejszyć swoją widoczność. Pamiętaj, że atakujący też używają Nmapa – to, co my tu robimy legalnie w labie, ktoś inny może robić Twojej produkcyjnej stronie. Im mniej się wyświetlasz na ich radarze (np. brak oczywistych dziur w konfiguracji), tym większa szansa, że pójdą szukać łatwiejszego celu.

Reasumując, szybki rekonesans interfejsów webowych to krok, którego nie należy pomijać. Zarówno w ofensywie (pentest, security audit aplikacji), jak i defensywie (samodzielny przegląd własnych systemów), daje on ogrom wiedzy o systemie niemal za darmo. Cytując klasyka: “Informacja to potęga” – a na wojnie między atakującym a obrońcą wygrywa ten, kto lepiej tę informację zbierze i wykorzysta.

Checklista szybkiego rekonesansu interfejsów webowych

Na koniec przedstawiamy krótką checklistę czynności, które warto wykonać podczas szybkiego rekonesansu aplikacji webowej (w kontekście testów bezpieczeństwa):

1. Zidentyfikuj otwarte porty webowe: Najpierw skanuj hosty, aby znaleźć działające usługi HTTP/HTTPS (typowo port 80, 443, ale też 8080, 8443 i inne niestandardowe). To baza – musisz wiedzieć, gdzie w ogóle są interfejsy webowe. (Nmap z opcją -p- lub skan typu -sV na popularnych portach załatwi sprawę).
2. Wykonaj podstawowe skrypty NSE na usługach webowych: Użyj -sV -sC na znalezionych hostach z portem HTTP/HTTPS. Domyślne skrypty podadzą Ci od razu tytuł strony, nagłówek serwera, metody HTTP i ewentualny wynik http-robots.txt. To szybki rzut oka na każdy host. Alternatywnie, użyj konkretnych skryptów: http-title, http-headers, http-methods, http-robots.txt dla większej kontroli nad outputem.
3. Sprawdź banery i wersje oprogramowania: Na podstawie nagłówków (np. Server: Apache/2.4.51) i ewentualnie informacji z skanowania wersji (Nmap -sV często wskaże nazwę serwera i wersję) określ, na jakim serwerze działa aplikacja i czy są to aktualne wersje. Zanotuj technologiczne stacki – np. Apache + PHP, nginx + uwsgi, Microsoft IIS, itd. To pozwoli Ci dobrać ewentualne exploity (np. konkretne CVE pod daną wersję) i sprawdzić konfigurację typową dla danego serwera.
4. Przeanalizuj tytuły i treść stron głównych: Tytuł strony (<title>) często mówi dużo. Jeśli to np. “Login – CompanyX”, prawdopodobnie widzisz stronę logowania do jakiegoś panelu. Jeśli pojawia się nazwa produktu lub CMS (WordPress, Joomla, “Welcome to Tomcat” itp.), od razu wiesz, z czym masz do czynienia. Zajrzyj też na samą stronę (możesz użyć szybkiego podglądu przez curl lub w przeglądarce) – czasem na stronie głównej widać komentarze HTML, meta tagi lub stopkę z wersją (np. “Powered by Drupal 7”).
5. Pobierz plik robots.txt: Jeżeli skan wskazał obecność robots.txt (albo nawet jeśli nie, spróbuj i tak, bo może skan mógł pominąć), pobierz go (curl http://host/robots.txt). Przejrzyj, czy są tam interesujące Disallow – każdą niewinną z pozoru ścieżkę warto odnotować i później odwiedzić. Często znajdują się tam foldery typu /admin/, /private/, /test/ – a to już zaprasza do zbadania.
6. Sprawdź metody HTTP: Jeśli http-methods pokazał dziwne metody (PUT, DELETE, TRACE, CONNECT itp.), to duży wykrzyknik. Spróbuj samemu wykonać test: np. wyślij żądanie OPTIONS (curl -X OPTIONS -i http://host/) żeby zobaczyć nagłówek Allow, albo spróbuj użyć metod w praktyce (np. testowy PUT pliku, jeśli masz zgodę, lub TRACE – czasem by zobaczyć czy nagłówki wracają). Niebezpieczne metody powinny być wyłączone, więc ich obecność to potencjalna podatność (np. możliwość uploadu pliku na serwer).
7. Uruchom skan enumeracyjny (opcjonalnie): Gdy podstawowe info jest zebrane, możesz odpalić bardziej agresywne skrypty typu http-enum lub dedykowane skrypty dla konkretnych aplikacji (np. http-wordpress-enum, http-drupal-enum, http-open-proxy itp.), o ile masz na to zgodę i jest to w scope testu. Taki skan dogłębny wskaże dodatkowe ścieżki, paneliki, pliki konfiguracyjne – ale pamiętaj o konsekwencjach (głośność). Najlepiej robić to w porach testów zaplanowanych, żeby nie zaśmiecać logów produkcji bez potrzeby.
8. Analizuj wyniki i planuj dalsze kroki: Z zebranymi informacjami zastanów się, które obszary są najbardziej warte uwagi. Czy mamy stary CMS – sprawdź dostępne exploity (np. w OWASP Exploit DB albo poprzez skrypt Nmap vuln), czy widać otwarty panel logowania – może spróbować brute force (Nmap ma skrypty http-brute, ale rozważ też dedykowane narzędzia). Czy listing katalogów – zajrzyj do tych katalogów, poszukaj w nich plików .bak, .old, backupów DB. Rekonesans to dopiero wstęp – ale dobry wstęp ustawia całą resztę testu.
9. Dokumentuj odkrycia: Na koniec nie zapomnij zanotować wszystkiego, co znalazłeś. W raporcie z audytu sekcja rekonesansu jest podstawą do opisu potencjalnych ryzyk. Np. “Serwer ujawnia w nagłówku wersję Apache 2.2.22, która jest przestarzała – zalecana aktualizacja”, albo “Znaleziono plik readme.html z wersją CMS – możliwe znane podatności CVE-XXXX”. Taka dokumentacja przyda się przy raportowaniu i przy poprawkach po teście.

Ta checklista może być rozszerzana zależnie od kontekstu (inaczej podejdziemy do aplikacji public-facing, inaczej do wewnętrznej korporacyjnej). Jednak rdzeń pozostaje ten sam: poznaj swojego przeciwnika – czyli aplikację, którą testujesz. Im więcej wiesz na starcie, tym skuteczniej i szybciej namierzysz realne problemy.

Na sam koniec – CTA: Uruchom na własnym testowym hostcie taki skan, jak pokazaliśmy, i sprawdź logi serwera HTTP. Zobaczysz tam ślady swojego rekonesansu (np. serię błędów 404 od http-enum). To cenna lekcja zarówno dla pentestera (widzisz, co wykrywalne), jak i dla administratora (widzisz, co atakujący zostawiają w logach). Powodzenia w eksperymentach i bezpiecznym rekonesansie!

Podsumowanie

Rekonesans interfejsów webowych to dokładnie ten moment, w którym zwykłe „port 80 jest otwarty” zamienia się w konkret: wiemy, jaka aplikacja tam stoi, jak się identyfikuje, co ujawnia i gdzie ma słabe miejsca. W tym artykule przeszliśmy drogę od prostego skanowania portów Nmapem, przez użycie skryptów NSE (http-title, http-headers, http-methods, http-robots.txt, http-enum), aż do ułożenia z tego sensownego planu dalszych działań – zarówno ofensywnych, jak i defensywnych.

Jeżeli dojdziesz do etapu, w którym na podstawie samego outputu z Nmapa potrafisz powiedzieć: „tu jest stary WordPress, tu listing katalogów, tu dziwne metody HTTP, tu WAF broni frontu” – to znaczy, że rekonesans webowy masz już w ręku. Reszta (eksploatacja, raportowanie, hardening) to kolejne warstwy dokładane na ten fundament. Nieważne, czy siedzisz po stronie Red Teamu, Blue Teamu, czy po prostu uczysz się bezpieczeństwa – umiejętność przeczytania i zinterpretowania wyników takiego skanu to jeden z kluczowych nawyków inżyniera bezpieczeństwa.

Dobry nawyk na dalszą część nauki: odpal raz na jakiś czas te same skrypty na różnych hostach (lab, własne projekty, środowiska testowe), porównuj wyniki i patrz, jak zmieniają się konfiguracje oraz błędy. Z czasem zaczniesz „widzieć” problemy już w locie, po kilku linijkach outputu. I o to chodzi w rekonesansie interfejsów webowych – żeby zanim otworzysz Burpa czy specjalistyczne skanery, mieć już w głowie mapę: co tu stoi, gdzie jest wejście i co może się rozsypać jako pierwsze.