Pozwól Czytelniku, że posłużę się o to taką analogią: W pierwszym kroku by móc przejść do skanowania portów należy wykryć czy dany host jest aktywny (czytaj włączony). Wykrycie takiego komputera jest jak znalezienie adresu domu. Gdy posiadamy adres domu możemy pójść dalej i poszukać sposobu dostania się do tego domu. Aby wejść do środka można skorzystać z drzwi frontowych ale również poszukać wejścia od tyłu czy przez garaż. Co bardziej kreatywni stwierdzą, że do środka można dostać się przez okno czy otwór przeznaczony dla zwierząt. Tak więc sam Czytelniku widzisz, że jest kilka dróg by osiągnąć zamierzony cel. W przypadku komputerów potencjalnymi sposobami uzyskania dostępu jest skorzystanie z otwartych portów a w znalezieniu wejścia pomoże nam skanowanie portów. Wyniki uzyskane dzięki przeprowadzonemu skanowaniu są potencjalnymi drzwiami przy wykorzystaniu, których wrota „domu” staną przed nami otworem. Tak więc port jest rodzajem „drzwi” przy pomocy, którego możemy uzyskać dostęp do komputera.

Tak więc proces skanowania sprowadza się do odnalezienia działających systemów a dodatkowo usług oferowanych przez te systemy.

Proces skanowania możemy podzielić na trzy odrębne fazy tj.:

• określenie czy dany system zdalny działa,
• skanowanie i wykrycie używanych portów,
• skanowanie systemu pod kątem wykrycia luk, które to w późniejszej fazie można wykorzystać jako cel ataku.

Proces wykrycia działającego systemu jak już wspomniałem został omówiony więc tak by treści nie powtarzać odsyłam do wpisu - http://slow7.pl/item/110-co-w-sieci-siedzi-skanowanie-sieci-aktywne-hosty

Skanowanie i wykrycie otwartych portów sprowadza się do odnalezienie portu oraz identyfikacji usługi korzystającej z danego portu. Można to ująć w ten sposób: port to nic innego jak otwarte okno bądź furtka dzięki, której inny komputer bądź program może ustanowić połączenie, tak by mogła nastąpić wymiana danych. Porty posiadają swoje unikalne numery a dodatkowo dzięki zastosowaniu idei portów komputer może prowadzić wiele równoległych kanałów wymiany danych tak aby jeden proces nie musiał czekać na zakończenie innego. Dlatego równocześnie możemy wysyłać/odbierać pocztę, pobierać pliki czy słuchać ulubionego radia internetowego.

Niektóre z portów przyjęte są jako znane, oznacz to, że na portach tych działają określone usługi. Przykładem takiej usługi, która do swego działania wykorzystuje port o numerze 22 jest SSH. Usługa odpowiedzialna jest za nawiązanie bezpiecznych połączeń z hostem zdalnym. Każdy klient próbujący nawiązać ten typ połączenia wie, że aby móc skomunikować się z innym komputerem należy użyć docelowego portu 22, gdyż na tym porcie nasłuchuje serwer SSH. Kolejnym przykładem jest użycie przeglądarki internetowej. Nawiązując połączenie z daną stroną internetową, po podaniu adresu, przeglądarka próbuje ustanowić połączenie z serwerem WWW wykorzystując do tego zdalny port o numerze 80 gdyż na porcie tym serwer domyślnie oczekuje przychodzących połączeń. Na komputerze lokalnym zostaje otwarty losowy port, tak aby mógł być zestawiony pełny kanał komunikacyjny. Oczywiście można zmienić domyślny port pracy serwera WWW lecz wtedy celem nawiązania połączenia trzeba się do niego odwołać.

Numery portów reprezentowane są przez liczby naturalne z zakresu od 0 do 65535.

• wartości od 0 do 1023 przyjęto jako ogólnie znane, (ang. well known ports),
• zarejestrowane porty (ang. registered ports) to porty o numerach od 1024 do 49151 Porty te są przewidziane dla usług, które zwyczajowo korzystają z określonych portów,
• porty przydzielane dynamicznie (ang. dynamically allocated ports, również ephemeral ports) to porty o numerach od 49152 do 65535.

Dodatkowo porty mogą być typu TCP bądź UDP (w zależności od użytego protokołu transportowego).

Przykładami innych usług, które korzystają ze standardowych numerów portów są te przedstawione poniżej:

• DNS – 53 (TCP, UDP),
• FTP – 20, przesyłanie danych (TCP),
• FTP – 21, przesyłanie poleceń (TCP),
• HTTP – 80, (TCP),
• HTTPS – 443 (HTTP na SSL) (TCP),
• IMAP – 143 (TCP),
• POP3 – 110 (TCP),
• SMTP – 25 (TCP),
• Telnet – 23 (TCP).

Oczywiście nie jest to pełna lista lecz jej niewielki wycinek. Listę portów i wykorzystujące je usługi, znajdziesz tu: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Skanowanie systemu pod kątem wykrycia luk ma za zadanie wykrycie i zidentyfikowanie wszelkich słabych punktów w usługach udostępnianych na określonych portach tak by mogły być one celem skutecznego ataku. Zagadnienie te w tym wpisie tylko „liźniemy” gdyż temat ten jest materiałem na kolejny artykuł.

Aby móc skutecznie wykorzystać skanowanie portów należy dokładnie zrozumieć działanie protokołów TCP oraz UDP (często niedocenianego) dlatego też zanim przejdziemy dalej winien jestem parę słów wprowadzenia.

Zaczniemy od protokołu TCP.

Głównymi zadaniami protokołu TCP jest stwierdzenie czy transmitowane dane są:

• uszkodzone,
• zagubione,
• powielone,
• dostarczone w nieodpowiedniej kolejności do odbiorcy.

Protokół TCP używany jest wszędzie tam gdzie musi być zachowana integralność przesyłanych danych, należy do tzw. protokołów niezawodnych. Aby została zapewniona niezawodność transmisji i by dane dotarły w nie zmienionej formie stosuje się następujące mechanizmy:

• każdy wysłany pakiet danych TCP jest numerowany,
• każdy pakiet TCP potwierdzający odbiór jest numerowany,
• protokół wykorzystuje mechanizm pozytywnego potwierdzenia odbioru danych z retransmisją tzn. potwierdzany jest poprawny odbiór danych,
• stosowany jest zegar mierzący czas oczekiwania na potwierdzenie odbioru.

Nagłówek protokołu TCP został przedstawiony poniżej.

Budowa nagłówka TCP rozpoczyna się od pól w których przechowywane są wartości portu źródłowego oraz portu docelowego. Wartości te w połączeniu z danymi zawartymi w nagłówku IP (adres IP źródłowy oraz adres docelowy) są podstawą identyfikacji połączenia.

Pola numer sekwencyjny oraz numer potwierdzenia zawierają wartości, które są niezbędne aby prowadzić skuteczną wymianę danych gdyż tylko w oparciu o numerowanie pakietów hosty prowadzące ze sobą komunikację wiedzą jakich pakietów mają się spodziewać, czy nadchodzą one w prawidłowej kolejności i czy przypadkiem, któryś z pakietów nie zaginął. Więcej informacji i użyciu tych pól już za chwilę.

Wartość w polu długość nagłówka zawiera informację o długości nagłówka.

W polu bity kodu znajduje się osiem jednobitowych pól (zwanych również flagmi), których włączenie bądź wyłączenie sygnalizuje z jakim typem nagłówka TCP mamy do czynienia. Co ważne włączenie jednego z pól nie wyklucza włączenia innych. Zastosowanie poszczególnych pól zaprezentowano poniżej (opis ten jest skrótowy, gdyż do tematu flag będziemy wracać nie raz):

• CWR (ang. Congestion Window Reduced) - ustawienie flagi informuje o zmniejszeniu szybkości transmisji,
• ECE (ang. ECN Echo) - informacja o przeciążeniu,
• URG (ang. Urgent) - pilne dane (rzadko używane),
• ACK (ang. Acknowledgement) - numer potwierdzenia,
• PSH (ang. Push) - otrzymane dane maja być przekazane tak szybko jak to możliwe (nieużywane, gdyż sposób implementacji tej funkcji nie do końca spełnia niezawodność),
• RST (ang. Reset) - zresetowanie połączenia na wskutek błędu,
• SYN (ang. Synchronize) - flaga używana celem synchronizacji numerów ISN,
• FIN (ang. Finished) - flaga używana przy kończeniu połączenia sygnalizująca koniec wysyłania danych.

W protokole TCP celem zapewnienia ciągłości komunikacji oraz optymalnej dla danego typu połączenia szybkości przesyłania danych zastosowano tzw. mechanizm przesuwnego okna pakietów (działanie tej funkcji wykracza poza ramy tego artykułu więc wybacz Czytelniku iż tematu nie rozwijam). Pole okno jest odpowiedzialne za ustawienie rozmiaru okna pakietów.

Pole suma kontrolna jest odpowiedzialne za wyliczenie wartości bazującej na danych zawartych w nagłówku TCP (acz nie tylko) a celem jest sprawdzenie czy dane podczas przesyłu nie uległy modyfikacji. Pole te jest wyliczane przez nadawcę a weryfikowane przez odbiorcę.

Pole wskaźnik ważności ma znaczenie tylko przy ustawionej fladze URG i odznacza dane, które mają być pilnie przekazane.

W nagłówku TCP mogą być definiowane różne parametry, których ustawienie ma wpływ na działanie protokołu TCP i tu również opis ich wszystkich stanowiłby zbyt dalekie zboczenie z tematu wpisu aczkolwiek opiszemy jedną. Najczęściej umieszczanym parametrem w polu opcje jest maksymalny rozmiar segmentu (tzw. MSS, ang. maximum segment size). Opcja ta odpowiedzialna jest za ustalenie rozmiaru największego segmentu jaki może zostać przesłany. Rozmiar segmentu ustalany jest podczas procesu nawiązywania połączenia.

Ostatnie pole zawiera dane, choć zdarzają się pakiety, które tych danych są pozbawione

Po omówieniu podstawowych parametrów protokołu TCP czas przejść do pokazania ich zastosowania.

Podczas nawiązywania połączenia pomiędzy dwoma urządzeniami i przy wykorzystaniu protokołu TCP w pierwszej kolejności musi nastąpić proces zestawienia połączenia (ang. Three-Way Handshake). Dopiero po dokonanym uzgodnieniu można przejść do właściwej wymiany informacji.

Cały proces negocjacji rozpoczyna się od wysłania na zdefiniowany adres IP i do określonego portu pakietu z ustawioną flagą SYN. Pakiet ten wysyła host nawiązujący połączenie. Jeśli host docelowy jest uruchomiony i usługa korzystająca z danego portu nasłuchuje na tym porcie w kierunku hosta ustanawiającego połączenie zostaje odesłany pakiet z ustawioną flagą SYN/ACK. Po otrzymaniu takiego pakietu w kierunku hosta z którym nawiązujemy połączenie zostaje wysłane potwierdzenie w postaci pakietu z włączoną flagą ACK.

Proces nawiązywania połączenia TCP przedstawia poniższy rysunek, komputer Host jest inicjującym połączenie z Serwerem.

Dociekliwy Czytelnik mógłby zadać pytanie - Ale jak to się dzieje, że komputer rozróżnia poszczególne sesje TCP, przecież w danej chwili może być nawiązanych kilka sesji? Rozróżnienie sesji TCP opiera się na wykorzystaniu numerów sekwencyjnych oraz numerów potwierdzenia. Numer sekwencyjny często jest określany jako ISN zaś numer potwierdzenia jako ACK.

Jak już wiesz Czytelniku aby sesja TCP mogła zostać nawiązana w pierwszej kolejności zostaje wysłany pakiet z ustawioną flagą SYN. Pakiet ten został pokazany na rysunku poniżej. Prześledzimy sesję nawiązaną pomiędzy hostem o adresie IP 192.168.1.140 a komputerem o adresie IP 192.168.1.205 na przykładzie ruchu przechwyconego za pomocą Wireshark-a.

Pakiet SYN (punkt 1) z hosta 192.168.1.140 (port 1074) zostaje wysłany w kierunku komputera 192.168.1.205 na port 80 (sesja WWW). Numer sekwencyjny został ustalony na 2831575758 (punkt 2). Numer sekwencyjny ISN jest losową liczbą z przedziału od 0 do 2^32-1.

Host 192.168.1.205 na otrzymany pakiet SYN odpowiada pakietem z ustawioną flagą SYN/ACK (punkt 4). Pakiet ten zostaje odesłany z źródłowego portu 80 na docelowy port 1074 w kierunku hosta 192.168.1.140 (punkt 1). Host w pakiecie SYN/ACK umieszcza swój własny numer sekwencyjny: 1854235621 (punkt 2) ale dodatkowo zostaje jeszcze umieszczony tzw. numer potwierdzenia Numer ten ma wartość o jeden większą niż numer sekwencyjny otrzymany w pakiecie SYN - 2831575759 (punkt 3).

Ostatnim pakietem jest pakiet ACK (punkt 4), który jest odpowiedzią hosta 192.168.1.140 na otrzymany pakiet SYN/ACK (punkt 1). W pakiecie tym numer sekwencyjny zostaje ustalony na wartość o jeden większą w stosunku do pierwszego pakietu, którym był pakiet SYN - 2831575759 (punkt 2) zaś numer potwierdzenia stanowi wartość o jeden większą niż wartość numeru sekwencyjnego otrzymanego od hosta192.168.1.205 w pakiecie SYN/ACT - 1854235622 (punkt 3).

Proces ustanowienia sesji TCP zakończył się sukcesem. Nasz schemat ustanawiania sesji TCP możemy wzbogacić o dodatkowe informacje.

Po tym etapie następuje transmisja danych, która również opiera się na przekazywaniu pomiędzy hostami pakietów z odpowiednimi wartościami numerów sekwencyjnych i numerów potwierdzenia.

Po przesłaniu wszystkich danych komunikacja musi się zakończyć. Zakończenie sesji może odbyć się na dwa sposoby. Jeden należy do sposobów „eleganckich” i polega na wykorzystaniu czterech pakietów wraz z ustawioną flagą FIN. Drugi zaś np. na skutek nieoczekiwanego błędu (wyłączenie hosta, błędna konfiguracja) wykorzystuje pakiety TCP z ustawioną flagą RST.

Użycie pierwszego ze sposobów rozpoczyna się od wysłania pakietu z ustawionymi flagami FIN i ACK (pakiet wysyła host chcący zakończyć sesję). Komputer do którego trafia pakiet odpowiada pakietem ACK a dodatkowo wysyła własny pakiet w którym ustawione są flagi FIN i ACK. Host inicjujący zamknięcie odpowiada pakietem ACK.

Poniżej na zrzucie pokazano zamknięcie sesji TCP przy wykorzystaniu pakietu FIN.

Host 192.168.1 .140 inicjuje zamknięcie w tym celu do komputera o adresie 192.168.1.205 zostaje wysłany pakiet FIN/ACK. Host 192.168.1.205 odpowiada dwoma pakietami – pakietem ACK oraz własnym pakietem FIN/ACK. Po otrzymaniu od hosta 192.168.1.205 pakietu FIN/ACK komputer 192.168.1 .140 potwierdza fakt zamknięcia sesji pakietem ACK.

Zwróć uwagę Czytelniku na wartości numerów sekwencyjnych i potwierdzenia. Jak można stwierdzić schemat numeracji opiera się na tej samej zasadzie jaka została wykorzystana w przypadku nawiązywania połączenia. Schematycznie proces został przedstawiony na rysunku poniżej.

Drugi ze sposobów jak zostało wspomniane wykorzystuje pakiet TCP z ustawioną flagą RST. Wysłanie takiego pakietu informuje hosta o zerwaniu połączenia bądź odmowie jego nawiązania.

Poniżej przedstawiono pakiet wysłany od hosta 192.168.1.140 kończącego sesję TCP na wskutek wystąpienia błędu. Pakiet ma ustawione flagi RST oraz ACK. Wysłanie pakietu kończy komunikację pomiędzy komputerami 192.168.1.140 a 192.168.1.205.

Podczas skanowania będziemy mieli do czynienia z jeszcze jednym protokołem a mianowicie z protokołem UDP (ang. User Datagram Protocol). Informacje o tym protokole znajdziesz w dalszej części wpisu gdy przejdziemy do przykładów użycia go podczas skanowania.

Wykrywanie systemu

Naszą przygodę ze skanowaniem portów rozpoczniemy od zaprezentowania sposobów wykrycia skanowanego systemu. Tak zwany fingerprinting systemu jest metodą, która pozwoli nam poznać wersję skanowanego systemu. Można by zapytać – Jakie korzyści z posiadania takiej informacji będziemy mieli? Otóż poznanie wersji systemu pomoże nam w doborze skutecznych technik skanowania. Dobór odpowiedniej metody skanowania w zależności od naszego celu (skanowanego systemu) będzie łatwiejszy i da bardziej wymierny efekt w zdobyciu poszukiwanych informacji. Mówiąc inaczej wybór danej metody skanowania zależny jest od wykrytego systemu operacyjnego, gdyż po co wykorzystać dany rodzaj skanu gdy z góry wiadomo, że w danym systemie on nie zadziała. Tak więc system operacyjny wymusza na nas zastosowanie określnych rozwiązań.

Identyfikacja systemu operacyjnego możliwa jest dzięki różnej interpretacji wytycznych zawartych w dokumentach RFC. Oznacza to, że dani producenci inaczej w swoich systemach operacyjnych implementują rozwiązania związane z obsługą protokołów IP, TCP czy UDP. Wychwycenie tych różnic (często bardzo subtelnych) umożliwia narzędziom wykorzystywanym do skanu zidentyfikowanie skanowanego systemu.

Poniżej przykład różnej implementacji początkowej wartości pola TTL w nagłówku IP oraz rozmiaru zastosowanego okna TCP. Porównanie tych informacji z dużym prawdopodobieństwem da nam odpowiedź o typie systemu operacyjnego.

Inne typy analizowanych danych opierają się m.in. o:

• Porównanie numerów ISN (ang. Initial Sequence Number) – wartość ISN jest wykorzystywana przy zestawianiu sesji TCP. Numer ten z reguły jest losowy lecz niektóre z systemów preferują bardziej lub mniej pewne wartości. Analiza wzorca numeru pozwala na określenie typu systemu.
• Wykorzystanie pakietów TCP – celem weryfikacji systemu można wysłać w kierunku celu specjalnie spreparowane pakiety TCP. Pakiety te mają ustawione nietypowe flagi protokołu TCP, które nie są przewidziane w specyfikacji dokumentów RFC. Analizując otrzymaną odpowiedź można wykonać pewne założenia odnośnie systemu z którego zostały wysłane. Np. pakiet TCP z ustawioną flagą FIN jest wysyłany do otwartego portu, zgodnie z dokumentacją RFC odpowiedzią na tak otrzymaną informację powinien być brak odpowiedzi lecz systemy z rodziny Windows na odebrany pakiet odpowiadają pakietem z ustawioną flagą FIN/ACK.
• Wykorzystanie komunikatów ICMP – podczas wystąpienia błędów protokołu ICMP, dane systemy w odpowiedziach odsyłają różną liczbę danych, analiza otrzymanych danych definiuje system z którego zostały wysłane.
• Zastosowanie bitu „nie dziel na fragmenty” – bit ten jest wykorzystywany w komunikacji TCP celem zwiększenia wydajności, lecz nie jest on stosowany przez wszystkie systemy operacyjne, weryfikacja bitu pozwala zawęzić liczbę systemów operacyjnych,
• Zaawansowane opcje protokołu TCP – protokół TCP w różnych odstępach czasu podlegał modyfikacjom i usprawnieniom, implementacja i ocena przyjętych rozwiązań (np. maksymalna wielkość segmentu, blok niewykonywalny czy współczynnik skalowania okna) pozwala na wytypowanie systemu zdalnego.

Przedstawione i opisane mechanizmy oczywiście nie wyczerpują tematu identyfikacji używanego systemu operacyjnego lecz mają za zadanie ukazanie jak wiele metod może zostać użytych aby mieć pewność iż cel ataku zostanie poprawnie rozpoznany.

Pierwszym z narzędzi jakie chciałbym zaprezentować jest już wcześniej opisywany Nmap. Ten wszechstronny program nie tylko pozwala nam na odkrycie aktywnych hostów ale również przy wykorzystaniu pełni jego możliwości możemy wykonać proces identyfikacji systemu operacyjnego oraz proces skanowania portów (w wpisie tym często a nawet bardzo często będziemy z tego narzędzia korzystać).

Aby zidentyfikować system zdalny należy posłużyć się poleceniem: nmap -O <adres_hosta> Po wydaniu komendy uzyskamy informację o systemie operacyjnym – polecenie przyjmie postać: nmap -O 192.168.1.140. Jak widać poniżej system zdalny został określony jako Windows 2000 bądź Windows XP. Oprócz identyfikacji systemu uzyskamy również informację o otwartych portach – 139, 445, 3389

Otrzymane wyniki potwierdzają, że mamy do czynienia z systemem Windows ponieważ oprócz występujących sprzeczności w implementacji protokołów, identyfikację systemu możemy także oprzeć o analizę aktywnych numerów portów. Gdyż w systemach operacyjnych wykorzystywane porty stale się powtarzają. Wykryte porty 139, 445 a w szczególności 3389 są przynależne systemowi Windows. W przypadku systemu Linux będziemy mieli do czynienia z innym zestawem charakterystycznych dla tego systemu wartości numerów portów.

Spróbujmy wykonać skan na innym systemie operacyjnym.

Tym razem po wydaniu polecenia uzyskujemy informację, że mamy do czynienia z systemem Windows 7, Windows 8, Windows Vista bądź Windows 2008.

No to kolejny przykład, tym razem system został określony jednoznacznie jako Windows 10.

I ostatni przykład. Tym razem skanowany system zdalny został określony jako Linux w wersji 2.6.X (gdzie X od 9 do 33).

Dokładniejsze wyniki uzyskamy jeśli skorzystamy z funkcji włączenia detekcji OS i wersji usług. Aby wykonać tę operację należy wydać polecenie: nmap -A <adres_hosta> Poniżej przykład w którym względem hosta 192.168.1.140 ponownie zostaje wydane polecenie celem identyfikacji systemu operacyjnego. Przy wykorzystaniu opcji -O system został określony jako Windows 2000 bądź Windows XP zaś przy wykorzystaniu flagi -A system został zawężony do Windows XP z zainstalowanym SP3 (co w 100% jest prawdą).

Wydanie komendy detekcji systemu i usług względem komputera 192.168.1.205 (informacje uzyskane dzięki wcześniejszemu skanowaniu to: Windows 7, Windows 8, Windows Vista bądź Windows 2008) również zawęża dane – wykryty system to Windows 7 (poznajemy również dokładną wersję systemu). Dodatkowo oprócz poznania wersji systemu Windows nasza wiedza o skanowanym hoście zostaje poszerzona m.in. o: nazwę komputera, tryb pracy sieciowej (domena, grupa robocza) czy informację o sposobie logowania. Zaprezentowane poniżej wyniki zostały zawężone do informacji dotyczących wersji systemu.

Użycie detekcji systemu odnośnie hosta 192.168.1.200 dostarcza nam szeregu informacji o typie usług działających na określonych portach (wyniki zostały zawężone).

Mechanizm wykrywania systemu zdalnego wykorzystywany przez narzędzie Nmap opiera się na wysyłaniu do badanego systemu odpowiednio przygotowanych żądań i analizie uzyskanych odpowiedzi. Do analizy uzyskanych odpowiedzi jest wykorzystywana baza sygnatur. Baza sygnatur programu Nmap jest przechowywana w pliku nmap-os-db bądź nmap-os-fingerprints.

Na podobnej zasadzie analizę systemu operacyjnego będą przeprowadzały narzędzia omówione w dalszej części wpisu. Pierwszym (oprócz Nmap-a) narzędziem, które chciałbym przedstawić jest xProbe2.

Aby za pomocą tego programu określić system zdalny należy posłużyć się poleceniem: xprobe2 <adres_hosta>

Narzędzie wykorzystamy odnośnie znanego nam już hosta 192.168.1.140 Sprawdźmy zatem czy wyniki uzyskane dzięki xProbe2 pokrywają się z wynikami uzyskanymi dzięki użyciu Nmap-a.

Wydanie komendy identyfikującej system określa, że mamy do czynienia z systemem Mac OS bądź z produktami firmy HP.

Uzyskany wynik całkowicie nie pokrywa się z danymi jakie uzyskaliśmy po uruchomieniu Nmap-a. Taki stan rzeczy jest spowodowany faktem iż narzędzie te już od dość dłuższego czasu nie jest rozwijane.

By uściślić wyniki otrzymane w poprzednim kroku spróbujmy użyć narzędzia xProbe2 w odniesieniu do zdefiniowanego portu. Aby narzędzie xProbe2 wykryło system zdalny poprzez analizę danych otrzymanych z określonego portu należy w definicji polecenia użyć przełącznika -T <numer_portu>.

Przypuśćmy, że podejrzewamy iż skanowany system będzie należał do systemów z rodziny Windows. Dlatego też doskonałym wyborem sprawdzanego numeru portu będzie port o numerze 3389 (port odpowiedzialny za realizację połączeń Pulpitu zdalnego - rozwiązanie stosowane tylko w systemie Windows). Zatem polecenie przyjmie postać: xprobe2 192.168.1.140 -T3389

Jak widać poniżej analizowany system zdalny zostaje określony jako Windows.

Wyniki uzyskane dzięki narzędziu xProbe2 względem hosta o adresie IP 192.168.1.200 identyfikują system jako Linux w wersji 2.6.X (podobnie jak Nmap).

Oba zaprezentowane do tej pory narzędzia opierały się na tzw. aktywnym fingerprintigu stosu czyli wersja systemu zdalnego została ustalona dzięki przesłaniu w kierunku celu specjalnie przygotowanych pakietów. Analiza otrzymanych odpowiedzi wraz z ich porównaniem z bazą sygnatur pozwala odpowiedzieć na pytanie z jakim systemem mamy do czynienia.

Przeciwieństwem metody aktywnej jest pasywne zdobycie informacji o typie zainstalowanego systemu. Metoda ta charakteryzuje się brakiem jakiejkolwiek interakcji z badanym hostem. Określenie systemu zdalnego odbywa się tylko na podstawie analizy pakietów pojawiających się w sieci. Metoda ta nie jest tak precyzyjna jak aktywna lecz zastosowanie jej eliminuje szanse wykrycia wykonywanego skanu.

Jednym z narzędzi jakie możemy wykorzystać przy pasywnym określaniu systemu jest program p0f.

Użycie narzędzia sprowadza się tylko do wydania polecenia: p0f Po uruchomieniu programu, narzędzie rozpoczyna analizę otrzymywanych pakietów. Aby metoda pasywna zdała egzamin należy zadbać o odpowiednią ilość danych do analizy. Dane te możemy dostarczyć np. poprzez wykonanie ataku MITM (ang. Man in the middle – atak polegający na podsłuchu a czasem modyfikacji wiadomości przesyłanych pomiędzy dwiema stronami bez ich wiedzy), fizycznym zainstalowaniu TAP-a sieciowego (urządzenie odpowiedzialne za klonowanie sygnału sieciowego i przesłanie go do atakującego, możliwe jest użycie zwykłego HUB-a lecz wtedy obniżymy przepustowość łącza do 10Mb/s i dodatkowo dochodzi problem z kolizją pakietów) czy wykorzystaniem portu lustrzanego (opcja kopiowania pakietów odbieranych/wysyłanych przez określony port przełącznika do innego portu).

Poniżej na zrzucie efekt użycia narzędzia p0f (aplikacja dostępna w systemie Linux). Po uruchomieniu programu zostały wykryte dwa systemy zdalne – host o adresie 192.168.1.30 korzysta z systemu Linux 3.11 lub nowszego natomiast host 192.168.1.140 to system Windows.

Podobnym programem potrafiącym określić system zdalny poprzez pasywną analizę pakietów jest NetworkMiner. NetworkMiner to tzw. sniffer czyli narzędzie służące do przechwytywania pakietów pojawiających się w sieci. Aplikacja potrafi je analizować i na tej podstawie definiować typ systemu (program ma więcej możliwości m.in. potrafi określić otwarte porty, przechwycić pojawiające się pliki czy dane uwierzytelniające - nazwy użytkowników oraz hasła). Aplikacja do działania wykorzystuje graficzny interfejs użytkownika i dla odmiany jest dostępna w systemie Windows.

Poniżej na rysunku zaprezentowano efekt pracy programu. Po krótkiej chwili od uruchomienia, narzędzie identyfikuje host 192.168.1.140 jako Windows (co jak wiemy po efektach pracy innych narzędzi jest wynikiem prawidłowym).

Aplikację NetworkMiner prócz systemu Windows możemy również uruchomić w systemach Linux, MacOS czy FreeBSD - strona programu: http://www.netresec.com/?page=NetworkMiner

Skanowanie portów

Teraz jak już wiemy jak zidentyfikować system operacyjny zdalnego hosta możemy przejść do omówienia metod wykorzystywanych w procesie skanowania portów.

Rozpoczniemy od podstawowej operacji jaką jest skanowanie TCP. Ten rodzaj skanu należy do najczęściej wykorzystywanych metod. Skanowanie te w pierwszej kolejności wykonamy przy użyciu Nmap-a. Nmap przeprowadza proces pełnego nawiązania połączenia a następnie zamyka połączenie. Proces ten wykonywany jest odnośnie każdego portu.

Skanowanie inicjujemy poprzez wydanie polecenia: nmap -sT <adres_IP> Wydanie komendy spowoduje wykonanie skanowania TCP (opcja -sT – opcja -s wskazuje na typ skanowania natomiast -T oznacza skanowanie TCP) hosta o zdefiniowanym adresie IP. Skan wielu hostów przeprowadzamy poprzez definicję początkowego i ostatniego adresu IP np. nmap -sT 192.168.0.1-254 bądź opcjonalnie gdy skanowana jest cała podsieć korzystamy z notacji CIDR (definicja adresu sieci i długości maski) - nmap -sT 192.168.0.1/24 Podczas definicji adresów IP hostów, które będą podlegać skanowaniu możemy za pomocą opcji: --exclude <adres_IP> wykluczyć komputery - hosty zdalne o zdefiniowanych adresach IP nie będą skanowane. Użycie np. takiej komendy: nmap 192.168.0.0/24 --exclude 192.168.0.10,192.168.0.24 spowoduje przeskanowanie wszystkich hostów należących do podsieci 192.168.0.0/24 za wyjątkiem adresów IP: 192.168.0.10 oraz 192.168.0.24

Jak widać powyżej udało nam się przeskanować hosta o adresie IP 192.168.1.110 i wykryć na tym hoście otwarte porty. Czas skanowania wyniósł niecałe 5 sekund. Niestety nie jest to komplet informacji gdyż zostało przeskanowanych tylko tysiąc najczęściej używanych portów.

Aby wykonać pełne skanowanie wszystkich portów należy do polecenia dodać parametr: -p-

Możliwe jest przeprowadzenie skanowania wybranego portu bądź zakresu portów. Aby wykonać skanowanie jednego portu po fladze -p należy zdefiniować docelowy port bądź grupę portów. Jeżeli zaś chcemy wykonać skan określonych, niekolejnych portów to ich numery oddzielone przecinkami podajemy również po opcji -p. Zakres portów definiujemy za pomocą znaku: - podając pierwszy i ostatni numer portu.

Na zrzucie poniżej ukazano kilka przykładów użycia flagi -p.

1 - skanowanie TCP pojedynczego portu 3389,

2 - skanowanie TCP portu 3389 oraz 139,

3 - skanowanie TCP zakresu portów - od 100 do 200.

Do tej pory skanowaniu podlegały tylko porty korzystające z protokołu TCP, a jak już Czytelniku wiesz (lecz temat nie został jeszcze dokładnie omówiony) prócz protokołu TCP istnieje również UDP. Trochę może wyprzedzam temat lecz to co chciałbym pokazać to to, iż przy wykorzystaniu flagi -p (z dodatkowymi opcjami) można definiować różne metody skanu, które będą stosowane względem określonych portów.

Na zrzucie poniżej za pomocą komendy: nmap -sU -sT -p U:53,11,137,T:3389 192.168.1.205 zostało uruchomione skanowanie określonych numerów portów lecz co ważne w procesie tym do skanowania wykorzystywany jest zarówno protokół UDP jaki i TCP.

Wytłumaczmy zatem wydane polecenie:

• opcja -sU - włącza skanowanie UDP,
• opcja -sT - włącza skanowanie TCP,
• flaga -p wraz z opcjami U:53,11,137,T:3389 definiuje skanowane porty, przy czym port 53, 11 oraz 137 skanowany jest przy wykorzystaniu protokołu UDP (wykorzystanie parametru U) zaś port 3389 podlega skanowaniu z wykorzystaniem TCP (wykorzystanie parametru T).

Opcją, którą bardzo często wykorzystuje się przy skanowaniu jest flaga -PN. Należy mieć na uwadze, że w procesie odkrywania aktywnych hostów może zdarzyć się sytuacja w której host zdalny będzie włączony lecz nasze skanowanie faktu tego nie potwierdzi. Użycie opcji -PN nakazuje Nmap-owi wykonanie skanowania portów tak jakby host był włączony i aktywny. Np wydanie polecenia: nmap -sT -p- -PN 192.168.1.1-10 spowoduje wykonanie skanowania TCP hostów od adresu IP 192.168.1.1 do 192.168.1.10 tak jakby hosty te były aktywne a dodatkowo proces skanowania obejmie wszystkie porty. Pominięty jest proces wykrywania aktywnych hostów.

A co w sytuacji w której musimy wykonać proces wykrywania aktywnych portów dla hostów, których adres IP nie są ułożone kolejno? Dobrym rozwiązaniem tego problemu jest umieszczenie adresów IP w osobnym pliku tekstowym (jeden adres IP na wiersz pliku) i zaimportowanie tak przygotowanej listy do narzędzi Nmap. Import dokonujemy przy wykorzystaniu opcji: -iL <ścieżka_do_pliku>.

Poniżej pokazano przykład wykonania skanu wszystkich portów dwóch komputerów, których adresy IP zostały zapisane w pliku tekstowym: nmapscan.txt. Skanowanie zostało wywołane za pomocą komendy: nmap -sT -p- -iL nmapscan.txt

Pliku tekstowego z zdefiniowanymi adresami IP możemy także użyć do określenia adresów IP hostów, które nie będą podlegały skanowaniu. Wydanie komendy: nmap -iL nmapscan.txt --excludefile nieskanuj.txt spowoduje wykonie skanowania hostów których adresy IP zostały zapisane w pliku nmapscan.txt za wyjątkiem tych określonych w pliku nieskanuj.txt

Zatrzymajmy się jeszcze chwilę nad powyższym zrzutem. Analizując listę otwartych portów na hoście 192.168.1.205 można zauważyć iż część działających usług nie została rozpoznana (porty z zakresu od 49152 do 49157 oraz 49166). Nmap oprócz skanowania portów potrafi również przeprowadzić operację skanowania wersji usług. Skanowanie te polega na wysłaniu w kierunku badanego hosta próbek, których zadaniem jest bardziej dokładne zidentyfikowanie usługi działającej na określonym porcie. Wywołanie skanowania wersji wywołujemy za pomocą flagi: -sV

Poniżej przedstawiono użycie opcji -sV odnośnie niezidentyfikowanych portów hosta 192.168.1.205 a ponieważ skan ujawnił otwarty port 80 dodatkowo został przeprowadzony skan tego portu w celu uzyskania bardziej szczegółowych informacji na temat działającego serwera www. Komenda uruchamiająca proces skanowania wersji przybierze postać: nmap -sV -p49152-49157,80,49166 192.168.1.205

Analizując informacje uzyskane po wydaniu polecenia dochodzimy do wniosku iż na portach tych działają usługi systemu Windows. Zaś serwer WWW został zidentyfikowany jako IIS w wersji 7.5. Co odpowiada stanu faktycznemu. Poniżej zrzut z skanowanego hosta.

Jak widać Nmap potrafi być naprawdę skuteczny.

Dodatkowo za pomocą parametru --version-intensity <level> możemy zdefiniować stopień - nazwijmy to agresywności przeprowadzanego testu. Poziom testu ustalamy w zakresie od 0 do 9 (0 - test łagodny, 9 - test brutalny). Aby wykonać test z ustalonym poziomem na 9 można opcjonalnie posłużyć się parametrem: --version-all

Zdefiniowanie parametru --version-trace spowoduje uruchomienie procesu debugowania przeprowadzanego skanu a tym samym uzyskamy wgląd w wykonywane operacje i trwające etapy uruchomionego procesu.

Prócz tradycyjnego skanowania TCP Nmap umożliwi nam przeprowadzenia tak zwanego skanowania SYN. Czym ta metoda różni się od poprzedniej? Otóż jak już wiesz skanowanie TCP nawiązuje pełną sesję z badanym hostem. Proces skanowania obejmuje pełne ustanowienie połączenia. Do przeprowadzenia skanowania SYN wykorzystywane są tylko dwa pierwsze etapy nawiązywania połączenia TCP. Oznacza to, że komputer atakujący wysyła standardowy pakiet SYN, na który uzyskuje odpowiedź w postaci pakietu SYN/ACK. Kolejnym krokiem powinno być odesłanie przez komputer wykonujący skanowanie pakietu ACK. Tak się jednak nie dzieje. Zamiast pakietu ACK zostaje wysłany pakiet RST (tzw. pakiet zerowania). Pakiet ten nakazuje zignorowanie wcześniej przesłanych informacji i zamknięcie połączenia.

Ten typ skanowania w literaturze bardzo często określany jest skanowaniem typu stealth. Skojarzenie z niewykrywalnymi samolotami jest jak najbardziej na miejscu. Gdyż tak jak samolot dla radarów pozostaje niewykrywalny tak ten typ skanowania może pozostać niezauważony dla narzędzi, których zadaniem jest monitorowanie ruchu sieciowego. Niewykrywalność tej metody bazuje na fakcie iż połączenie pomiędzy hostem atakującym a celem ataku nigdy w 100% nie zostaje nawiązane.

Tak więc aby zilustrować ten proces spójrz na poniższy rysunek przedstawiający schematycznie przebieg skanowania SYN.

Już po opisie tej metody można wysunąć wniosek, iż ten rodzaj skanowania przebiega szybciej niż tradycyjne wyliczanie portów TCP. Szybkość skanowania wynika z mniejszej liczby przesłanych pakietów.

Aby przeprowadzić skanowanie SYN w definicji polecenia należy użyć flagi: -sS Tak naprawdę dodanie w linii poleceń flagi -sS jest zbędne gdyż domyślnie wykonywanym przez Nmap-a skanowaniem jest skanowanie TCP stealth.

Poniżej przykład wykonania skanu SYN wszystkich portów hosta o adresie IP 192.168.1.205, polecenie przybrało postać: nmap -sS -p- 192.168.1.205

Czas skanowania wyniósł 24,23s Aby nie być gołosłownym odnośnie czasu wykonywania skanu poniżej przedstawiam zrzut z wykonanego wyliczania portów tego samego hosta lecz z wykorzystaniem metody TCP.

Porównując czas obu skanów wyraźnie widać iż skanowanie SYN przebiega znacznie szybciej (o ponad 20 sekund) a różnic w uzyskanych wynikach nie widać. Może Ci się to Czytelniku wydać mało istotne ale wykonując skan całej podsieci o masce /24 różnica w czasie skanowania będzie już znaczna.

Innym narzędziem jakie możemy użyć do przeprowadzenia skanowania SYN jest aplikacja hping3. W poprzednim wpisie narzędzia tego używaliśmy do wykrycia aktywnych hostów zaś w tym pokarzę jak program wykorzystać do skanowania portów.

Aby za pomocą hping3 wykonać proces skanowania należy posłużyć się poleceniem: hping3 <adres_IP_celu> --scan <skanowane_porty> -S Poniżej przedstawiono proces skanowania hosta o adresie IP 192.168.1.200, skanowaniu podlegają wszystkie porty.

Po wydaniu polecenia uzyskujemy listę otwartych portów. Działanie programu polega na wysłaniu na wskazane porty pakietu TCP z ustawioną flagą SYN (za wysłanie tego typu pakietu odpowiada flaga: -S). Zgodnie z zasadą ustanawiania sesji TCP otwarty i aktywny port na otrzymany pakiet SYN odpowiada pakietem SYN/ACK (na zrzucie powyżej lista wszystkich portów, które na otrzymane żądanie odpowiedziały - jak widać odpowiedzią są pakiety SYN/ACK - kolumna flags).

Aby zdefiniować listę określonych portów ich numery wymieniamy w linii poleceń oddzielając je od siebie przecinkami. Zakres portów definiujemy za pomocą myślnika (np. --scan 200-300).

Narzędzie hping3 czasem nie wyświetla wszystkich informacji dlatego warto w linii poleceń użyć dodatkowej opcji: -v

Skanowanie UDP

Warstwa czwarta modelu ISO/OSI to nie tylko protokół TCP ale również protokół UDP. Często protokół ten w procesie wykrywania aktywnych portów jest pomijany i lekceważony. A nie wolno zapomnieć iż otwarte porty UDP i usługi działające na tych portach w późniejszej fazie np. przeprowadzanego testu penetracyjnego mogą stanowić wektor ataku.

Aby za pomocą narzędzia Nmap przeprowadzić proces skanowania portów UDP w składni polecenia należy użyć flagi: -sU

Połączenie realizowane poprzez protokół UDP należy do tzw. połączeń bezpołączeniowych oznacza to, że pomiędzy nadawcą a odbiorcą w żaden sposób nie jest zestawiany kanał komunikacyjny, który umożliwiłby w jakikolwiek weryfikację czy pakiety wysłane od adresata trafią do nadawcy. Brak jest również jakiegokolwiek mechanizmu zapewniającego ponowną retransmisje uszkodzonych bądź zagubionych pakietów. Komunikacje poprzez protokół UDP możemy porównać do sytuacji w której wrzucamy zaadresowany list do skrzynki pocztowej z nadzieją, że szczęśliwie dotrze do odbiorcy. W większości przypadków tak się oczywiście dzieje ale są sytuacje w których na skutek nieprzewidzianych okoliczności nasz list zaginie.

Protokół UDP nie ma zaimplementowanych funkcji: kontroli kolejności wiadomości, eliminowania duplikatów, korekcji błędów czy sterowania przepływem. Jedynym z ważnych mechanizmów wspieranych przez ten protokół jest detekcja błędów. Detekcja ta opiera się na wyliczaniu sum kontrolnych, które są dodawane i analizowane przez nadawcę i adresata (suma jest obliczana po stronie nadawcy a weryfikuje ją adresat). Brak wielu ważnych i wymienionych funkcji sugerowałby iż stosowanie tego protokołu jest bezzasadne. Nie do końca stwierdzenie te jest prawdą, gdyż wielką zaletą protokołu UDP jest jego prostota a co za tym idzie niewielki narzut danych generowanych przez sam protokół. Dodatkowo łatwiej przy pomocy protokołu UDP zrealizować proces transmisji danych opartych o multiemisję.

Skanowanie przy wykorzystaniu protokołu UDP jest utrudnione gdyż należy mieć na uwadze fakt iż ze względu na naturę działania protokołu, nadawcy rzadko są udzielane odpowiedzi. Nmap tak samo jak w przypadku skanowania z użyciem protokołu TCP wysyła pakiety UDP do wybranych portów, zawartość pakietu zmienia się w zależności od numeru skanowanego portu. Po wysłaniu pakietu Nmap czeka na odpowiedź, jeśli taka odpowiedź nadejdzie port przyjmie status: open. Port zamknięty jest określany na podstawie komunikatu ICMP Port Unreachable. W przypadku skanowania UDP może wystąpić jeszcze trzecia sytuacja a mianowicie stan portu może zostać zdefiniowany jako: open|filtered Dlatego też w wynikach skanu UDP port często będzie przyjmować ten stan. Status open|filtered przyjmie port, który nie udzieli żadnej odpowiedzi. Brak odpowiedzi może być spowodowany filtrowaniem pakietów przez zaporę sieciową bądź winne może być oprogramowanie, które na zapytania wysłane przez Nmap-a nie odpowiada.

To co jeszcze należy dopowiedzieć odnośnie wykonywania wyliczania portów przy wykorzystaniu protokołu UDP to to iż skanowanie to jest czasochłonne. Przeprowadzenie skanu domyślnych tysiąca portów potrafi zająć około 15 minut i więcej. W przykładzie powyżej, czas skanu wyniósł 15 minut.

Aby uzyskać dokładniejsze wyniki można nakazać narzędziu zastosowanie wspomnianej już funkcji wykrywania wersji. Uaktywnienie funkcji spowoduje wysłanie do wszystkich skanowanych portów dodatkowych pakietów (próbek), których celem jest dokładniejsza identyfikacja działających usług. Jak pewnie pamiętasz nakazanie Nmap-owi włączenie funkcji wykrywania wersji odbywa się poprzez zastosowanie przełącznika:-sV a skanowanie UDP wymaga użycia flagi: -sU dlatego też całość opcji możemy połączyć w jeden ciąg i użyć parametru: -sUV

Kolejnym narzędziem za pomocą, którego przeprowadzimy skanowanie UDP jest Metasploit a tak naprawdę należy użyć jeden z modułów zawarty w tym narzędziu - udp_sweep.

Aby móc uruchomić moduł w pierwszej kolejności za pomocą polecenia: msfconsole uruchamiamy linie poleceń narzędzia Metasploit.

Aby móc uruchomić moduł skanujący w linii poleceń wydajemy polecenie: use wraz z ścieżką do modułu. Aby uruchomić moduł udp_sweep wydaj komendę: use auxiliary/scanner/discovery/udp_sweep (punkt 1).

Po uruchomieniu modułu za pomocą komendy: set RHOSTS <adres_IP> ustalamy adres zdalnego hosta - cel ataku (punkt 2). Aby zdefiniować większą liczbę celów należy określić pierwszy i ostatni adres IP, adresy oddzielone są od siebie myślnikiem (np. set RHOSTS 192.168.1.200-210), skanowanie podsieci definiujemy z wykorzystaniem notacji CIDR (np. set RHOSTS 192.168.1.200/24),

Kolejne polecenie: set THREADS <wartość> odpowiedzialne jest za ustalenie liczby uruchomionych wątków modułu. Im wyższa wartość skanowanie będzie przebiegało szybciej - bardziej agresywnie. Gdy naszym priorytetem jest pozostanie nie zauważonym ustalenie niskiej wartości parametru THREADS spowoduje przeprowadzenie skanowania z mniejszą szybkością co zwiększa nasze szanse na pozostanie niezauważonym (punkt 3).

Aby sprawdzić konfigurowane opcje należy posłużyć się poleceniem: show options (punkt 4). Jak widać poniżej definiowane parametry zostały wprowadzone.

Uruchomienie skanowania UDP rozpoczynamy po wydaniu komendy: run (punkt 5).

Wyniki skanowania zostaną zaprezentowane po zakończeniu procesu.

Skanowanie Xmas

Ten rodzaj skanowania swoją nazwę Xmas przyjął od analogi związanej z świecącą choinką gdyż do jego przeprowadzenia jest używany pakiet TCP, który ma włączone flagi URG, PSH i FIN natomiast brak jest włączenia flagi SYN lub ACK. Jest to nietypowy rodzaj pakietu, którego specyfikacja zawarta w dokumentach RFC nie obejmuje. Zastosowanie tak spreparowanego pakietu TCP odnośnie skanowanego systemu spowoduje wymuszenie nietypowych odpowiedzi. Ponieważ odpowiedzi te w różnych systemach przyjmą inny kształt to analiza ich może dać informację o stanie aktywnych portów. Producenci oprogramowania z powodu braku dokładnych wytycznych w dokumentach RFC wdrożyli swoje własne autorskie rozwiązania.

Poniżej przedstawiono pakiet Xmas przechwycony podczas wykonywania skanu. Jak można zauważyć i tak jak to zostało opisane powyżej pakiet ten ma ustawione flagi URG, PSH i FIN.

Aby przeprowadzić skanowanie Xmas należy w linii poleceń narzędzia Nmap użyć flagi: -sX Jak można zaobserwować poniżej użycie tego typu skanu względem systemu Windows (a dokładniej Windows 7) nie przyniosło nam żadnych wymiernych efektów. Skanowanie Xmas odnośnie systemu Windows jest nieskuteczne (dlatego warto przed zastosowaniem danego typu skanu znać wersję systemu odnośnie którego będzie przeprowadzane badanie).

Sprawdźmy zatem jaki efekt uzyskamy gdy celem będzie system Linux. Po przeprowadzeniu skanu jedyną informację jaką uzyskujemy to to iż w badanym systemie dostępnych jest 30 portów o statusie open|filtered.

Aby uzyskać bardziej dokładne informacje o wykrytych portach należy użyć znanej nam opcji -sV. Po wydaniu komendy uzyskamy bardziej szczegółowe informacje.

Skanowanie NULL

Ten typ skanu podobnie jak Xmas wykorzystuje pakiet TCP, który jest niezgodny z specyfikacją zawartą w dokumentach RFC. W przypadku tej metody używany jest pakiet, który ma wyłączone wszystkie flagi (stąd nazwa skanowania).

Poniżej tak jak w przypadku metody Xmas został przedstawiony przechwycony pakiet Null. Wszystkie flagi pakietu TCP zostały wyłączone.

Aby użyć tej metody należy w linii poleceń zdefiniować opcję -sV. Podobnie jak w poprzednim przypadku w pierwszej kolejności skanowanie zostało użyte wobec systemu Windows 7. Zastosowana metoda nie wykryła żadnych otwartych portów. Tak jak w przypadku metody Xmas, skan przy wykorzystaniu pakietów Null gdy celem jest system Windows jest nieskuteczny.

Sprawdźmy zatem co osiągniemy w przypadku systemu Linux. Skan Null systemu Linux o adresie IP 192.168.1.200 wykazał szereg portów o statusie: open|filtered.

I tak jak poprzednio aby uzyskać dodatkowe informacje o działających usługach wykorzystamy flagę: -sV. Użyta opcja pozwala na zidentyfikowanie usług wykorzystujących dane porty.

Wykorzystanie obu metod odnośnie systemu Windows nie dało żadnych efektów zaś w przypadku systemu Linux pozwoliło nam na określenie otwartych portów. W przypadku obu metod należy mieć na uwadze fakt, iż ich zadaniem nie jest ustanowienie kanału komunikacji przez który moglibyśmy przesłać dane ale wykrycie w badanym systemie potencjalnych luk. Opisane metody ze względu na swój nietypowy charakter działania mogą pozostać niezauważone przez administratora odpowiedzialnego za ochronę skanowanych systemów a dodatkowo pozwalają na ominięcie list kontroli dostępu (ACL), których zadaniem jest uniemożliwienie przeprowadzania skanowania TCP czy skanowania SYN.

Skanowanie ACK

Skanowanie ACK polega na wysłaniu pakietu TCP, który ma ustawiony aktywny bit ACK. Proces skanowania sprowadza się do wysłania w kierunku celu pakietu z aktywna flagą ACK, jeśli system zdalny odpowie pakietem RST oznacza to, że port jest niefiltrowany w przypadku otrzymania odpowiedzi w postaci komunikatu ICMP lub braku jakiejkolwiek odpowiedzi Nmap uzna port za filtrowany.

Trochę to zagmatwane ale już spieszę z wytłumaczeniem. Ten typ skanowania w szczególności przydatny jest w sytuacjach w których mamy do czynienia z zaporą sieciową. W przypadku zapór sieciowych ich klasyfikację możemy przeprowadzić ze względu na charakter działania. Tak więc zapory sieciowe czy bardziej popularnie - firewalle możemy podzielić na bezstanowe i stanowe.

Zapory bezstanowe są odpowiedzialne za filtrowanie ruchu sieciowego (ruch wychodzący jaki i przychodzący) przy czym analiza tego ruchu obejmuje warstwę trzecią i warstwę czwartą modelu ISO/OSI. Tak więc analizowanymi protokołami są IP, TCP i UDP a mówiąc bardziej szczegółowo informacje zawarte w przenoszonych pakietach - źródłowy adres IP, docelowy adres IP, port źródłowy i port docelowy. Największą wadą tego typu zapór jest fakt iż zapory tego typu decyzję o zablokowaniu bądź przepuszczeniu danego ruch sieciowego podejmują w oparciu o analizę pojedynczego pakietu. Działanie tego typu zapór nie obejmuje sprawdzenia czy dany pakiet jest fragmentem całości czyli już nawiązanego połączenia, czy jest pakietem przypadkowym bądź pakietem wygenerowanym przez atakującego. Stąd podatność tego typu zapór na ataki typu ACK czy FIN.

Poniżej przedstawiono przykład w którym host o adresie 192.168.1.50 przeprowadza skanowanie ACK hosta 192.168.1.205 (skanowany port 139) - punkt 1. W wyniku skanowania cel ataku odsyła pakiet TCP z ustawioną flagą RST - punkt 2. Oznacza to, że port jest niefiltrowany. Odpowiedź RST została odesłana ponieważ host znajdował się za bezstanową zaporą.

Zapory stanowe jeśli można tak powiedzieć są „bardziej mądre” od swoich braci. Cały ruch sieciowy przez zaporę jest traktowany jako całość co oznacza, że decyzja o przepuszczeniu bądź zablokowaniu danego datagramu jest podejmowana w oparciu o analizę pakietów tworzących połączenie. Mówiąc trochę inaczej, firewall „wie”, czy otrzymany pakiet jest częścią aktualnie realizowanego połączenia czy może jest całkowicie odrębnym i nieoczekiwanym pakietem.

Poniżej przedstawiono ten sam scenariusz jaki miał miejsce wyżej z tą tylko różnicą iż aktualnie host 192.168.1.205 znajduje się za zaporą stanową. W kierunku hosta zostaje wysłany pakiet TCP z ustawioną flagą ACK - punkt 1. Tym razem odpowiedź nie nadchodzi. Port przyjmuje status filtrowany.

Odpowiedź od hosta została zablokowana przez zaporę gdyż nie stanowiła większej całości połączenia.

Skanowanie FIN

Skanowanie te jest podobne do omówionego powyżej skanowania ACK lecz z tą różnicą, że zamiast pakietu z ustawioną flagą ACK zostaje wysłany pakiet z aktywną flagą FIN. W tej metodzie skanowania sprawdzamy powracający pakiet - domyślnie brak odpowiedzi oznacza, że port jest otwarty, a odpowiedź w postaci datagramu z ustawioną flagą RST/ACK, oznacza zamknięty port. Przy użyciu tej metody skanowania ważne jest rozpoznanie systemu, który będzie stanowił nasz cel ponieważ część systemów wysyła odpowiedzi RST niezależnie od tego czy port jest otwarty czy nie. Brak rozróżnienia powoduje, że w wynikach skanowania wszystkie porty przyjmą status zamknięty. Systemy, które zachowują się w ten sposób to systemy z rodziny Windows lecz też wiele urządzeń Cisco. Skanowanie tego typu przeprowadzamy wobec systemów Linux. Dodatkowo skanowanie te pomoże nam wykryć typ używanej zapory sieciowej.

Rozważmy analogiczną sytuację jaka miała miejsce przy skanowaniu ACK i sprawdźmy zachowanie hosta o adresie IP 192.168.1.205 w zależności od typu użytej zapory.

W pierwszej kolejności host za zaporą bezstanową. Po wykonaniu skanowania FIN (port 3986) - punkt 1 zostaje udzielona odpowiedź w postaci pakietu RST/ACK - punkt 2. Status portu w wyniku skanowania zostaje zakwalifikowany jako closed. Można zastanawiać się - Czemu port jest zamknięty skoro została udzielona odpowiedź? Otóż skanowanym hostem jest Windows 7 a system ten udzieli odpowiedzi RST/ACK niezależnie od statusu portu - pakiet RST/ACK jest wysyłany dla portu otwartego ale również zamkniętego.

Umieśćmy hosta za zaporą stanową i wykonajmy skanowanie tego samego portu. Tym razem w wynikach skanowania status portu zostaje ustawiony jako: open|filtered Status portu przyjął taki stan gdyż nie został odesłany pakiet RST/ACK. Brak pakietu oznacza iż został on zablokowany przez zaporę.

Po wykonaniu skanowania FIN jesteśmy w stanie stwierdzić jaka zapora chroni dostęp do hosta.

W systemie Linux mamy do czynienia z sytuacją odwrotną. Przeprowadzono skanowanie FIN wobec hosta 192.168.1.200, skanowany port 22 (SSH). Status portu został ustawiony na open|filtered gdyż otwarty port nie wysyła flagi RST/ACK.

W przypadku wykonania skanu FIN zamkniętego portu 29, status portu przyjmie stan closed. Status portu przyjął taki stan gdyż został odesłany datagram RST/ACK.

Opisana wyżej sytuacja odnosi się do hosta, który znajduje się za zaporą bezstanową.

To sprawdźmy jak przebiegnie skanowanie gdy hosta będzie chroniła zapora stanowa.

W przypadku portu otwartego status portu zostaje określony jako open|filterd.

Port zamknięty zgłasza ten sam status.

W przypadku zapory stanowej nie jest możliwe dokładne określenie statusu portu gdyż stan portu zostaje zdefiniowany na podstawie odpowiedzi w postaci pakietu RST/ACK. Zapora stanowa blokuje te pakiety tak więc wszystkie skanowane porty zostaną wykryte jako open|filterd.

Wszystkie przedstawione do tej pory metody, angażowały do skanowania host na którym zostało wydane polecenie wykonania skanu. Oznacza to, że przeprowadzanie wielu skanów naraża nas na wykrycie. Różne systemy w swoich logach rejestrują informacje przeprowadzanych operacji a dodatkowo w sieciach funkcjonują systemy IDS/IPS (ang. Intrusion Detection System, Intrusion Prevention System), których zadaniem jest wykrywanie (IDS) lub wykrywanie i blokowanie ataków (IPS) w czasie rzeczywistym. Zabezpieczenia te są więc odpowiedzialne za rejestrowanie zdarzeń, które mogą wpłynąć na bezpieczeństwo chronionej sieci. Wykorzystanie metod opisanych powyżej może wywołać alarm, który doprowadzi do wykrycia przeprowadzanych operacji.

Aby uniemożliwić wykrycie adresu IP hosta przeprowadzającego skanowanie można skorzystać z tzw. skanowania jałowego (ang. Idle Scanning). Przy użyciu tej techniki skanowania w całości procesu uczestniczy dodatkowy host tzw. zombie. Najlepsze kryterium wyboru hosta zombie stanowi komputer, który w sieci generuje mało ruchu. Hostem zombie może również zostać maszyna wirtualna.

Znalezienie i wykorzystanie hosta, który w naszym imieniu przeprowadziłby skanowanie jest największym problemem gdyż większość nowych systemów na pełnienie tej (zaszczytnej) funkcji jest już uodporniona ale nic nie stoi na przeszkodzie by użyć odpowiednio przygotowany system wykorzystując do tego oprogramowanie VirtualBox czy VMware (Windows XP SP2 świetnie się w tej roli sprawdzi).

Skanowanie przy użyciu hosta zombie bazuje na trzech założeniach:

• Skanowany otwarty port po odebraniu pakietu TCP z ustawioną flagą SYN odpowiada pakietem SYN/ACK, natomiast port zamknięty odpowie pakietem RST,
• Komputer zombie na skutek odebrania nieoczekiwanego datagramu SYN/ACK odpowiada wiadomością RST (sytuacja w przypadku portu otwartego), natomiast odebranie przez komputer zombie nieoczekiwanego komunikatu RST jest przez niego ignorowane (sytuacja w przypadku portu zamkniętego),
• Host zombie a raczej system operacyjny musi spełnić warunek tzw. sekwencyjnej inkrementacji numerów identyfikacyjnych (tzw. identyfikator IPID). By móc wykorzystać dany system jako hosta zombie identyfikator IPID musi być przydzielany w sposób przewidywalny tj. wartości IPID muszą przyjmować kolejne wartości zwiększane o 1. W przypadku nowych systemów wartość numeru IPID jest wartością losową zaś starsze systemy działają według zasady przypisywania kolejnej wartości numerowi IPID.

Aby skanowanie jałowe mogło zostać przeprowadzone, napastnik wysyła w kierunku hosta zombie pakiet z ustawioną flagą SYN/ACK. W odebranym pakiecie RST sprawdzana jest wartość identyfikatora IPID.

Kolejnym krokiem jest wysłanie specjalnie przygotowanego pakietu SYN lecz tym razem celem jest dany port skanowanego hosta. Wysłany pakiet zawiera ustawiony adres źródłowy IP hosta zombie. Jeśli badany port jest otwarty zgodnie z zasadą ustalania sesji TCP system skanowany po otrzymaniu pakietu SYN w kierunku hosta zombie odsyła pakiet SYN/ACK. Dla hosta zombie otrzymany pakiet jest nieoczekiwany (pamiętamy, że pakiet SYN wysłał napastnik) dlatego też odsyła on w kierunku celu skanowania datagram RST, wysłanie pakietu powoduje zwiększenie wartości identyfikatora IPID o 1.

Ostatnim krokiem w tym procesie jest ponowne wysłanie w kierunku hosta zombie pakietu z aktywnymi flagami SYN/ACK (pakiet ten wysyła napastnik). Dla hosta zombie otrzymany pakiet znów jest pakietem nieoczekiwanym więc odsyła on pakiet RST, tym samym powiększając wartość identyfikatora IPID znów o 1.

Podsumowując wszystkie czynności, wartość identyfikatora IPID wzrosła o 2 od sprawdzonej wartości początkowej. Oznacza to, że na skanowanym hoście, badany port jest portem otwartym.

A co w przypadku portu zamkniętego? Sytuacja przebiega podobnie lecz z jednym małym wyjątkiem. Ale wszystko po kolei. Tak jak poprzednio w kierunku hosta zombie zostaje wysłany pakiet SYN/ACK, celem pakietu jest sprawdzenie wartości identyfikatora IPID.

Kolejny krok przebiega identycznie jak w przypadku sytuacji z portem otwartym - zostaje wysłany pakiet SYN w którym źródłowy adres IP wskazuje na hosta zombie (celem jest skanowany host). Ponieważ badany port jest portem zamkniętym w kierunku hosta zombie zostaje odesłany datagram RST (wartość IPID nie ulega zmianie).

Ostatnim krokiem jest wysłanie w kierunku hosta zombie kolejnego pakietu SYN/ACK, celem pakietu jest zbadanie o ile wzrosła wartość identyfikatora IPID. Ponieważ pakiet ten jest pakietem nieoczekiwanym host zombie odsyła pakiet RST, wysłanie pakietu wymusza na hoście zwiększenie wartości IPID o 1.

Reasumując w scenariuszu z portem zamkniętym sprawdzana wartość IPID wzrasta tylko o 1. Taki wzrost wartości IPID jest sygnałem dla napastnika iż skanowany port jest portem zamkniętym.

Aby sprawdzić czy dany host wspiera sekwencyjną inkrementację numerów identyfikacyjnych IPID można posłużyć się narzędziem hping3. Po wydaniu polecenia: hping3 -c 6 <adres_IP_hosta> zostanie wysłana seria pakietów TCP Null (brak aktywnych flag), analiza otrzymanych wyników pozwala nam stwierdzić czy host wspiera sekwencyjną inkrementację. Jak widać poniżej wartości IPID są powiększane o 1 co oznacza, że komputer ten może zostać hostem zombie (system Windows XP SP2).

Poniżej przedstawiono wykorzystanie tego samego polecenia ale względem systemu Ubuntu 14.04 jak można zaobserwować wartości IPID są wartościami losowymi. Host ten nie spełnia warunku sekwencyjności wartości IPID czego skutkiem jest brak możliwości wykorzystania go do skanowania w trybie Idle.

Innym sposobem wykrycia systemów, które mogły by posłużyć do pełnienia roli hostów zombie jest wykorzystanie skanerów IPIDSeq.

Pierwszym z skanerów jest skaner wbudowany w framework Metasploit. Zaletą użycia skanerów jest fakt iż możemy ich użyć w poszukiwaniu potencjalnych systemów zombie przeczesując całą podsieć.

Aby wykorzystać skaner należy w pierwszej kolejności za pomocą polecenia: msfconsole uruchomić framework. Po wydaniu polecenia (Metasploit korzysta z własnej linii poleceń) musimy wykonać czynności:

1 - za pomocą polecenia: use auxiliary/scanner/ip/ipidseq (polecenia możemy dopełniać za pomocą użycia klawisza TAB) uruchamiamy skaner,

2 - komenda: set RHOSTS <adres_IP/zakres> ustawia zakres przeprowadzanego skanu,

3 - komenda: set THREADS <wartość> ustala liczbę uruchamianych wątków, niższa wartość wolniejsze skanowanie zaś wartość wyższa spowoduje szybsze wykonanie skanu,

4 - komenda: show options pozwala na sprawdzenie wprowadzonych ustawień.

Po zdefiniowaniu wszystkich ustawień możemy uruchomić skaner. Uruchomienie skanu rozpoczynamy po wydaniu polecenia: run Skan wykrył jednego hosta o adresie IP 192.168.1.230, który spełnia warunki do użycia go w roli zombie.

Tą samą czynność wykrycia hostów spełniających warunek sekwencyjnej inkrementacji wykonamy za pomocą narzędzia Nmap i dołączonych skryptów. Aby uruchomić skan należy wydać polecenie: nmap <adres_IP/zakres> --script ipidseq Po wydaniu polecenia (w tym scenariuszu przeszukujemy sieć 192.168.1.0/24) Nmap rozpoczyna skanowanie. Jak widać poniżej efektem przeprowadzanego skanu jest wykrycie tego samego hosta co w przypadku użycia frameworku Metasploit.

Po odnalezieniu hosta możemy przejść do przeprowadzenia skanu portów. Nie zmieniamy scenariusza - wykonujemy skanowania portów z komputera o adresie IP 192.168.1.50, celem będzie host o adresie IP 192.168.1.205 zaś hostem zombie komputer 192.168.1.230.

Wykonanie skanowania portów z wykorzystaniem trybu jałowego uruchamiamy za pomocą polecenia: nmap <host_skanowany> -sI <host_zombie> Użycie dodatkowego parametru -Pn spowoduje brak pingowania systemu docelowego.

Host 192.168.1.205 został przeskanowany a skan ujawnił otwarte porty.

Dodatkowo na hoście 192.168.1.205 podczas prowadzonego skanowania został uruchomiony Wireshark tak by przekonać się czy rzeczywiście cały proces jest wykonywany przez hosta zombie. Jak widać poniżej całość przechwyconej komunikacji odbyła się tylko pomiędzy hostem zombie a skanowanym systemem, brak jest śladu obecności adresu IP komputera, który faktycznie skan przeprowadzał (host 192.168.1.50).

Opisany proces skanowania pozwala nam na wykonanie skanu bez pozostawienia w badanym systemie, śladów wskazujących na faktycznego sprawcę ataku.

Wiemy już jak przeprowadzać skanowanie w sposób całkowicie anonimowy. A co jeśli nie mamy możliwość przeprowadzenia skanu z wykorzystaniem metody opisanej powyżej i musimy narazić się na ewentualne wykrycie? Nieumiejętnie przeprowadzony proces skanowania lub przeprowadzony bez dodatkowych środków bezpieczeństwa może wzbudzić alarm a informacja o atakującym (adres IP) zostanie zapisana w dziennikach firewalli i systemów IDS. Aby utrudnić administratorom analizę logów po wykryciu skanu możemy wykorzystać opcję, nazywaną wabikiem (użycie parametru -D ang. decoy). Co ważne użycie tej opcji nie chroni Twojego adresu IP przed rejestracją ale sprawia, że wynik skanowania jest „zaciemniony”. Proces ten polega na stworzeniu iluzji, która ma przekonać, że w tym samym czasie nastąpił jednoczesny skan z różnych hostów.

Składnia polecenia wykorzystująca opcję wabika przedstawia się następująco: nmap <tryb_skanowania> <cel> -D <pozorne_adresy_IP> Możliwe jest użycie więcej niż jednego pozornego adresu IP, adresy te oddzielamy od siebie przecinkiem.

Poniżej został przedstawiony przykład skanowania stealth z wykorzystaniem parametru -D. Adresy IP podane po fladze -D są fałszywymi adresami, które również pojawią się w logach. Skanowanym hostem jest komputer o adresie IP 192.168.1.205 natomiast adresy 10.0.0.2 oraz 172.16.45.67 są adresami fikcyjnych hostów.

Aby fałsze adresy IP mogły być zarejestrowane w logach, fizycznie muszą zostać odebrane przez cel skanowania. Przechwytując ruch sieciowy na hoście docelowym można zaobserwować pakiety od nieistniejących hostów.

Użycie flagi -D utrudnia stwierdzenie, kto faktycznie skan przeprowadził.

Skanowanie - DNmap

Przeprowadzenie skanu portów pojedynczych hostów nie stanowi problemu - A co w sytuacji w której musimy przeprowadzić odkrywanie aktywnych portów na kilkunastu bądź kilkudziesięciu maszynach? Wykonanie tego zadania z wykorzystaniem pojedynczego hosta będzie utrudnione i czasochłonne. Dlatego w takiej sytuacji można użyć narzędzia DNmap. Narzędzie te zostało stworzone przez Sebastiana Garcię i jest odpowiedzią na postawione pytanie. Działanie narzędzia oparte jest o model klient-serwer. Oznacza to, że z wykorzystaniem aplikacji możemy stworzyć sieć komputerów, która przy pomocy narzędzia Nmap będzie prowadzić proces skanowania a wyniki skanowania zostaną zapisane na serwerze.

Myślę, że poniższa ilustracja w dość wymowny sposób przedstawia zasadę prowadzenia procesu skanowania z wykorzystaniem narzędzia DNmap.

Narzędzie DNmap tak naprawdę jest skryptem napisanym z wykorzystaniem języka Python i aby działać w systemie musi być zainstalowany interpreter tego języka wraz z bibliotekami: python-twisted oraz python-openssl. DNmap do działania wymaga również zainstalowanego Nmap-a. Narzędzie pobierzemy ze strony: https://sourceforge.net/projects/dnmap/

Aby móc utworzyć sieć komputerów, które będą realizować proces skanowania musimy wykonać trzy kroki:

1 - utworzyć listę poleceń narzędzia Nmap, listę poleceń zapisujemy w pliku tekstowym,

2 - uruchomić serwer DNmap, utworzony w poprzednim kroku plik posłuży nam do uruchomienia serwera,

3 - podłączyć klientów do serwera.

Rozpoczynamy od punktu pierwszego. Polecenia narzędzia Nmap zapisujemy w pliku tekstowym o nazwie: dnmapscan.txt. Plik zostaje zapisany w katalogu domowym. Serwer uruchamiamy w systemie Linux.

Po utworzeniu pliku zawierającego zapisane komendy Nmap-a przechodzimy do uruchomienia serwera DNmap. Serwer aktywujemy za pomocą polecenia: dnmap_server -f <plik_poleceń> W naszym przykładzie komenda przyjmie postać: dnmap_server -f dnmapscan.txt

Serwer został uruchomiony.

Ostatnim krokiem jest podłączenie klientów. W ramach ćwiczenia do serwera zostanie podłączonych dwóch klientów. Oba komputery klienckie pracują pod kontrolą systemu Linux.

Podłączenie klientów realizujemy po uprzednim pobraniu DNmap-a i niezbędnych bibliotek. Aby klient mógł skomunikować się z serwerem należy wydać polecenie: dnmap_client -s <adres_IP_serwera> -a <nazwa_klienta> (w niektórych wersjach systemu Linux polecenie należy poprzedzić komendą: python)

W scenariuszu do serwera o adresie IP 192.168.1.50 zostaje podłączony host o nazwie komp1 (IP 192.168.1.245).

Klient uzyskuje połączenie i zaczyna realizować proces skanowania.

Po podłączeniu pierwszego klienta przystępujemy do klienta drugiego. Do serwerem DNmap zostaje podłączony host komp02 (IP 192.168.1.246). Tak jak poprzednik, po zestawieniu połączenia klient realizuje proces skanowania.

Status podłączających się klientów możemy obserwować w oknie terminala w którym zostało wydane polecenie uruchamiające serwer. Jak widać poniżej oba hosty komp1 i komp02 zostały prawidłowo podłączone a status hostów został ustalony na Executing.

Proces skanowania trwa, oba podłączone hosty wykonują polecenia otrzymywane od serwera DNmap. Proces trwa tak długo, aż zostaną wykonane wszystkie polecenia zawarte w wcześniej utworzonym pliku tekstowym.

Poniżej host komp1 zakończył wykonywanie pierwszego zadania a że na serwerze zostały zdefiniowane trzy polecenia tak więc host zaczął realizować kolejne zadanie.

Host komp02 po wykonaniu swojej części pracy zakończył zadanie - serwer nie ma zdefiniowanych więcej poleceń.

Po przeprowadzeniu skanu wszystkie wyniki są umieszczone na serwerze w katalogu: nmap_results.

Obszar skanowania obejmował sieć 192.168.1.0/24 oraz hosta 192.168.1.205. Na hoście tym podczas wykonywania skanowania zostało włączone przechwytywanie pakietów zaś wynik tego procesu został zaprezentowany poniżej. Jak można zaobserwować brak jest śladu w wynikach adresu IP serwera DNmap (IP 192.168.1.50) jako faktycznie tego hosta, który koordynował cały proces, natomiast wyniki jednoznacznie wskazują, że hostami przeprowadzającymi skanowanie były komputery o adresach IP 192.168.1.245 oraz 192.168.1.246. Wnioski Czytelniku mam nadzieję, że nasunęły Ci się same - użycie serwera DNmap, również w pewien sposób maskuje faktycznego sprawcę ataku.

Na koniec jeszcze dwie krótkie uwagi odnośnie omawianego narzędzia.

Jeśli będziesz chciał przeprowadzić ponowne skanowanie z wykorzystaniem wcześniej utworzonego pliku z poleceniami koniecznie skasuj plik: nazwa_pliku.dnmaptrace gdyż w przeciwnym wypadku nie uruchomisz serwera. W omawianym scenariuszu polecenia zostały zapisane w pliku dnmapscan.txt tak więc przed ponownym uruchomieniem serwera skasuj plik: dnmapscan.txt.dnmaptrace Ewentualnie utwórz plik o innej nazwie.

Podane przeze mnie narzędzia oraz przykłady ich zastosowania oczywiście omawianego tematu skanowania portów do końca nie wyczerpują lecz do pokazanych metod wykonania odkrywania aktywnych portów jeszcze wrócimy. Gdy już mamy wiedzę na temat wykrywania aktywnych hostów oraz skanowania ich portów w kolejnym wpisie pójdziemy o krok dalej czyli zajmiemy się przechwytywaniem banerów oraz skanowaniem systemu pod kątem wykrycia luk.

 BIBLIOGRAFIA:

What You Must Know About OS Fingerprinting - InfoSec Resources

7 Nmap NSE Scripts for Recon | HackerTarget.com

Nmap Scripting Engine – Basic Usage | Penetration Testing Lab

Scanning Windows Deeper With the Nmap Scanning Engine - scanning-windows-deeper-nmap-scanning-engine-33138

Passive OS Fingerprinting - NETRESEC Blog

Top 30 Nmap Command Examples For Sys/Network Admins

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz