Nessus przez VPN: gdzie umieścić skaner przed pierwszym skanem

Ikona VPN obok przeglądarki nie mówi nic o procesie, który wysyła pakiety skanowania. Jeśli konsola i skaner działają na różnych hostach, tunel przeglądarki to jedna ścieżka, a źródło skanowania to druga. Zacznij od punktu wykonania, a potem idź na zewnątrz: trasa, autoryzacja i dane logowania. Ten podział nie bez powodu jest pierwszym punktem listy.

To lista kontrolna przed uruchomieniem, a nie samouczek skanowania. Każdy krok daje fakt, który możesz zapisać w dokumentacji zlecenia, zanim jakikolwiek pakiet opuści skaner.

Punkt pierwszy: zlokalizuj proces, który wysyła sondy

Narysuj wyraźnie trzy role: przeglądarkę na laptopie A, konsolę skanowania na hoście B i prywatny cel C. Jeśli B uruchamia także silnik skanowania, przeglądarka potrzebuje tylko ścieżki do B. Jeśli pracę wykonuje osobne urządzenie skanujące, to urządzenie potrzebuje ścieżki do C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

Przeglądarka połączona z VPN może docierać do konsoli, podczas gdy skaner za nią nadal nie ma trasy do C. Możliwa jest też sytuacja odwrotna: skaner jest w sieci prywatnej, a konsola jest zdalna. Ustal, jaki układ faktycznie u ciebie działa, zanim zmienisz jakąkolwiek kontrolę sieciową. Wskaż urządzenie w konfiguracji skanowania, zanim obwinisz sieć.

Jeśli skaner działa na A, host przeglądarki i skaner dzielą kontekst, ale tylko dopóki ten proces zachowuje tę samą przestrzeń nazw i tę samą tablicę routingu. Kontener lub konto usługi może nie dziedziczyć tego, co widzi interaktywna przeglądarka. Konsola jest powierzchnią zarządzania, a nie silnikiem skanowania.

Punkt drugi: udowodnij trasę i DNS skanera

Uruchom sprawdzenie trasy na hoście skanera, nie na laptopie. Zapytaj jądro, jakiego interfejsu i bramy użyłoby dla adresu celu, a następnie powtórz to dla nazwy hosta celu. Trasa istniejąca dla adresu IP i nazwa rozwiązująca się na inny adres to dwie różne awarie.

Potwierdź adres źródłowy, który pojawi się w celu. Klient VPN może przydzielić adres inny niż oczekiwany przez zaporę celu, a urządzenie NAT może go ponownie przepisać. Właściciel celu potrzebuje zaobserwowanego źródła, a nie adresu wydrukowanego w profilu VPN.

Sprawdź także ścieżkę powrotną. Skaner, który dociera do celu, ale nie otrzymuje odpowiedzi, ma problem z routingiem lub zaporą w drodze powrotnej, a wygląda to identycznie jak niedostępny cel.

Punkt trzeci: uzyskaj autoryzację zakresu i punktu widzenia

Poproś właściciela celu o pisemne wskazanie systemów, usług, środowiska, źródła i okna czasowego. Zdecyduj, jaki punkt widzenia reprezentuje ocena: zewnętrzny użytkownik VPN, dopuszczony klient wewnętrzny czy konkretny segment skanera.

Prywatna trasa nie jest zgodą na testowanie sąsiednich sieci. Utrzymuj listę celów wąską, wymień wykluczone systemy i uzgodnij warunki zatrzymania oraz kontakt, który może przerwać przebieg. Skaner chętnie sprawdza wszystko, do czego dotrze, i właśnie dlatego zakres musi być jednoznaczny.

Zapisz zatwierdzone źródło w tym samym dokumencie. Jeśli zaobserwowane źródło skanera różni się od zatwierdzonego, przebieg nie reprezentuje uzgodnionego punktu widzenia, nawet gdy lista celów jest poprawna.

Punkt czwarty: dopasuj dane logowania do głębokości oceny

Sprawdzenie osiągalności i ocena z uwierzytelnianiem to różne testy. Odpowiedź portu dowodzi, że coś odpowiedziało; nie dowodzi, że uruchomiono testy z danymi logowania ani że aplikacja autoryzowała konto.

Używaj dedykowanych danych logowania tylko wtedy, gdy uzgodniony zakres wymaga testów uwierzytelnionych. Potwierdź uprawnienia i politykę blokady konta oraz ustal, jak wyniki będą przechowywane i udostępniane, zanim skan je wytworzy.

Jeśli dane logowania zawiodą, nie przechodź po cichu na przebieg nieuwierzytelniony i nie oznaczaj raportu jako zaplanowanej oceny. Wynik to inny test o innym znaczeniu, a ta różnica należy do raportu.

Punkt piąty: zapisz plan, potem uruchom świadomie

W przepływie skanowania Nessus wybór szablonu, konfiguracja ustawień oraz zapisanie lub uruchomienie skanu to osobne kroki. Wykorzystaj ten podział, aby przejrzeć listę celów, źródło i harmonogram, zanim rozpocznie się jakikolwiek ruch.

Zanim zatwierdzisz uruchomienie, sprawdź, jakie źródło dopuszcza VPN, jaki ruch przenosi i jak odzyskuje sprawność po zerwaniu tunelu. Nie poszerzaj dostępu przez zaporę tylko dlatego, że wstępne połączenie nie powiodło się; znajdź warstwę, która odmówiła, i napraw tę warstwę.

Po przebiegu zapisz host skanera, zaobserwowane źródło, listę celów i wszystkie testy, których nie udało się ukończyć. Raport sporządzony z innego źródła lub bez zamierzonych danych logowania nie reprezentuje pierwotnego planu, a powiedzenie o tym jest częścią dostarczanego wyniku.

Wycofaj dostępy zlecenia i obsłuż zachowane wyniki zgodnie z uzgodnionym procesem. Lista kontrolna kończy się dopiero wtedy, gdy dowody odpowiadają zatwierdzonej ścieżce, a nie wtedy, gdy skan po prostu zwrócił wyniki.