GVM (Greenbone Vulnerability Management) – Kompletny Przewodnik

Czym jest GVM? Słyszałeś o OpenVas?

Greenbone Vulnerability Management (GVM) to otwartoźródłowy pakiet narzędzi do skanowania i zarządzania podatnościami w sieciach komputerowych. Projekt ten narodził się jako OpenVAS (Open Vulnerability Assessment System) – pierwotnie sam skaner podatności wywodzący się z otwartej wersji Nessusa. Z czasem firma Greenbone rozbudowała go o dodatkowe komponenty (zarządzanie wynikami, bazę danych, interfejs WWW) i przemianowała cały ekosystem na GVM, począwszy od wersji po OpenVAS 9.

Obecnie GVM stanowi pełnoprawne rozwiązanie do zarządzania podatnościami, integrujące skanowanie z bazą wiedzy o podatnościach oraz narzędziami do raportowania i harmonogramowania skanów.

Jako projekt open-source GVM jest dostępny bez opłat licencyjnych i rozwijany przez społeczność przy wsparciu Greenbone Networks. Od strony procesu bezpieczeństwa, GVM pełni rolę skanera podatności – automatycznie identyfikuje znane luki w zabezpieczeniach hostów i usług w sieci. Wyniki skanowania (lista wykrytych podatności z ich krytycznością) są następnie wykorzystywane w procesie zarządzania podatnościami do priorytetyzacji i usuwania tych zagrożeń. Dzięki integracji komponentów GVM można nie tylko wykonać skan, ale też zarządzać wynikami w czasie (śledzić status podatności, generować raporty, planować ponowne skany po wdrożeniu poprawek itp.), co czyni go kompleksowym rozwiązaniem w cyklu identyfikacji i obsługi podatności.

Związek GVM z dawnym OpenVAS: Należy podkreślić, iż termin OpenVAS bywa przez cały czas potocznie używany – często jako synonim skanera GVM. W rzeczywistości obecne wydanie to cała platforma GVM, w której OpenVAS Scanner stanowi tylko jeden z komponentów (silnik skanujący). Po 2017 roku nazwa projektu została ujednoznolicona – darmowa wersja open-source jest określana jako Greenbone Community Edition (wcześniej GSE – Greenbone Source Edition), a komercyjne appliance jako Greenbone Enterprise. W tym przewodniku skupiamy się na Community Edition, czyli właśnie otwartoźródłowym GVM (dawnym OpenVAS).

Architektura GVM – z czego się składa?

Schemat architektury GVM (Greenbone Community Edition) w wersji 22.4. Na architekturę składają się główne usługi skanera (OpenVAS), menedżera podatności (gvmd) oraz asystenta bezpieczeństwa (GSA/gsad), komunikujące się ze sobą i z bazą danych.

Architektura GVM jest modułowa i dzieli się na kilka kluczowych komponentów, z których każdy pełni odrębną rolę w systemie:

• Greenbone Vulnerability Manager Daemon (gvmd) – centralna usługa zarządcza, często nazywana po prostu Greenbone Vulnerability Manager. Gvmd odpowiada za konsolidację wyników skanowania i nadanie im kontekstu zarządzania podatnościami To właśnie gvmd utrzymuje bazę danych (PostgreSQL) ze wszystkimi ustawieniami, celami skanowań, zadaniami i rezultatami. Gvmd pośredniczy między skanerem a interfejsem użytkownika – kontroluje skanery (np. OpenVAS) poprzez protokół OSP oraz udostępnia API (XML) zwane Greenbone Management Protocol (GMP) do zdalnego zarządzania. Ponadto gvmd obsługuje zarządzanie użytkownikami (role, uprawnienia) i posiada wewnętrzny mechanizm harmonogramowania zadań (zaplanowane skany, powiadomienia itp.).
• OpenVAS Scanner – to adekwatny silnik skanujący wykonujący testy podatności (VT – Vulnerability Tests) na wskazanych systemach. Skaner OpenVAS korzysta z codziennie aktualizowanej bazy testów podatności, dostępnej w dwóch wariantach feedów: darmowym Greenbone Community Feed oraz płatnym Greenbone Enterprise Feed o szerszym zakresie. Silnik skanera składa się w tej chwili z demona ospd-openvas (który implementuje protokół skanera OSP) oraz modułu openvas-scanner wykonującego faktyczne testy. Gvmd komunikuje się ze skanerem przez OSP – zleca uruchomienie skanu, przekazuje listę testów do wykonania i odbiera wyniki. Sam skaner podczas działania ładuje tysiące skryptów testujących (NVT) i może wykorzystywać do działania zewnętrzne narzędzia (np. Nmap do skanowania portów). Warto dodać, iż od najnowszych wersji GVM wprowadzono także dodatkowy skaner o nazwie Notus do wydajniejszego sprawdzania lokalnych podatności (nasłuchuje on wersji zainstalowanego systemu i porównuje z listą podatnych wersji zamiast uruchamiać tradycyjne skrypty NASL). Notus przejmuje część testów (tzw. Local Security Checks) od OpenVAS, przyspieszając skanowanie systemów pod kątem znanych CVE.
• Greenbone Security Assistant (GSA) i gsad – GSA to webowy interfejs użytkownika (konsola) do zarządzania GVM, a gsad (Greenbone Security Assistant Daemon) to serwer WWW udostępniający ten interfejs. GSA umożliwia wygodne tworzenie celów skanowania, uruchamianie zadań, przeglądanie raportów i konfigurację systemu dzięki przeglądarki. Gsad komunikuje się z gvmd za pośrednictwem protokołu GMP – w praktyce więc każda akcja wykonana w GUI jest tłumaczona na komendy dla gvmd. Domyślnie gsad nasłuchuje lokalnie na porcie 9392 (HTTP) i wymaga zalogowania się użytkownika GVM. Dzięki GSA użytkownik może obsługiwać całe rozwiązanie bez użycia linii komend.
• Baza danych (PostgreSQL) – centralna baza danych, w której gvmd przechowuje konfiguracje, definicje celów, harmonogramy oraz wyniki wszystkich skanów. PostgreSQL zapewnia trwałość danych i możliwość ich przeszukiwania czy filtrowania (np. wyniki według daty, hosta, podatności). Przy pierwszej instalacji GVM tworzy strukturę tabel i niezbędne rozszerzenia bazy (m.in. do obsługi indeksowania wyników skanów).
• Redis – pamięciowa baza klucz-wartość pełniąca rolę magazynu tymczasowego dla skanera OpenVAS. Wykorzystywana jest do cache’owania załadowanych skryptów NVT i wyników podczas działania skanera, co znacząco przyspiesza skanowanie kolejnych hostów. OpenVAS domyślnie komunikuje się z lokalną instancją Redis poprzez socket UNIX (np. /run/redis-openvas/redis.sock). Wymagane jest odpowiednie skonfigurowanie Redisa (uprawnienia do socketu) tak, by proces skanera mógł z niego korzystać – inaczej pojawią się błędy typu „redis connection error: Permission denied” podczas inicjalizacji skanera. Poprawna konfiguracja zakłada, iż Redis działa z socketem dostępnym dla grupy użytkownika GVM (zwykle gvm lub _gvm) i iż ten użytkownik jest dodany do grupy Redisa.
• Mosquitto (MQTT broker) – najnowsze wersje GVM wykorzystują także broker komunikatów MQTT (domyślnie Mosquitto na porcie 1883) do wewnętrznej komunikacji między komponentami (np. przekazywanie informacji o aktualizacjach feedów lub synchronizacja działania skanera OpenVAS z Notus). jeżeli broker MQTT nie jest uruchomiony, usługa skanera (ospd-openvas) będzie zgłaszać ostrzeżenia o braku połączenia z brokerem. Standardowo w instalacjach community Mosquitto jest wykorzystywany lokalnie – warto upewnić się, iż jest zainstalowany i uruchomiony, aby uniknąć takich błędów.
• GVM Tools / API – uzupełniająco istnieje pakiet narzędzi gvm-tools, który umożliwia zewnętrzne sterowanie GVM poprzez API GMP lub OSP. Składają się na niego m.in. klient gvm-cli oraz biblioteka Python (python-gvm), pozwalające pisać skrypty automatyzujące pracę GVM. To jednak komponenty opcjonalne z punktu widzenia architektury – korzysta się z nich głównie w kontekście integracji z innymi systemami (więcej w sekcji o automatyzacji).

Podsumowując architekturę: GVM to wieloskładnikowy system działający typowo na serwerze linuksowym, gdzie współpracują ze sobą usługi skanera (OpenVAS), menedżera (gvmd) i interfejsu webowego (gsad/GSA), wspomagane przez bazę danych (PostgreSQL), cache Redis oraz broker komunikatów (Mosquitto). Takie rozdzielenie zapewnia elastyczność – np. możliwe jest uruchomienie skanerów na zdalnych hostach i połączenie ich z centralnym menedżerem (tzw. architektura master-slave), a także umożliwia skalowanie i integrację GVM w większych środowiskach SOC.

Dlaczego warto używać GVM?

Brak kosztów licencyjnych: GVM jest projektem open-source udostępnianym na licencji GPL, co oznacza, iż można z niego korzystać bezpłatnie, także w środowiskach firmowych. W odróżnieniu od komercyjnych skanerów (jak Nessus czy Qualys), tutaj nie musimy się martwić opłatami za licencje czy ograniczeniami liczby hostów w darmowej wersji – Community Edition pozwala skanować dowolną liczbę urządzeń. Dla małych i średnich firm, dla których koszty komercyjnych narzędzi są barierą, GVM jest więc atrakcyjnym rozwiązaniem. Dodatkowo, jako oprogramowanie wolnodostępne, GVM daje pełną wgląd w kod źródłowy, co bywa istotne dla instytucji publicznych i entuzjastów bezpieczeństwa ceniących transparentność.

Regularne aktualizacje bazy podatności: Greenbone udostępnia darmowy Greenbone Community Feed zawierający dziesiątki tysięcy testów podatności (NVT) oraz powiązane informacje (CVE, CPE, OVAL, certyfikaty) – jest on aktualizowany codziennie, dzięki czemu GVM nadąża za nowo odkrytymi podatnościami. W praktyce oznacza to, iż skanując przy użyciu GVM, otrzymujemy wyniki oparte o najświeższą wiedzę o lukach (np. nowe CVE publikowane przez producentów). Aktualizacje obejmują nie tylko same skrypty testujące, ale również dane konfiguracyjne (np. listy portów, wzorce wykrywania systemów, polityki skanowania) dostarczane w feedzie GVMD_DATA. W efekcie, choć narzędzie jest darmowe, jego skuteczność w wykrywaniu podatności jest porównywalna z komercyjnymi rozwiązaniami – szczególnie przy częstym aktualizowaniu feedu (o mechanizmach aktualizacji więcej w rozdziale 9).

Bogata baza testów i informacji: GVM integruje wiele źródeł informacji o podatnościach. Każdy test w bazie NVT jest powiązany z unikalnymi identyfikatorami CVE, klasyfikacją CVSS, a także może zawierać odnośniki do baz OVAL, danych o produktach (CPE) czy biuletynów CERT. Dzięki temu raporty z GVM prezentują nie tylko listę luk, ale też ich kontekst – ocenę skali ryzyka (CVSS), opis podatności, rekomendacje od vendorów i linki do zewnętrznych źródeł. Taka kompleksowa informacja ułatwia analitykom bezpieczeństwa zrozumienie i priorytetyzację wykrytych problemów.

Integracja z innymi narzędziami bezpieczeństwa: GVM został zaprojektowany z myślą o elastyczności – posiada dobrze udokumentowane API (Greenbone Management Protocol), co umożliwia integrację z systemami zewnętrznymi. Przykładowo, wyniki skanów można zautomatyzować i przesyłać do systemów SIEM lub SOAR w celu korelacji zdarzeń czy automatycznego tworzenia ticketów naprawczych. Dostępne narzędzia, takie jak pakiet gvm-tools, pozwalają wywoływać operacje GVM z poziomu skryptów Pythona lub linii poleceń. Dzięki temu GVM można włączyć w istniejące procesy – np. wyzwalać skan po wdrożeniu nowej aplikacji (CI/CD), eksportować raporty do systemu zgłoszeń (Jira, ServiceNow) bądź zaciągać listy podatności do SIEM (np. Splunk, Wazuh) celem korelacji z logami ataków. Integracja GVM z innymi elementami ekosystemu bezpieczeństwa zwiększa wartość skanów – pozwala szybciej reagować na wykryte luki i łączyć informacje o podatnościach z aktywnymi zagrożeniami.

Skalowalność i wszechstronność: GVM sprawdza się zarówno w małych sieciach, jak i w większych organizacjach. Może być wdrożony na pojedynczym serwerze skanującym kilkanaście hostów, ale również jako część Security Operations Center (SOC), gdzie skanuje setki adresów w harmonogramie tygodniowym. Dzięki modelowi klient-serwer i obsłudze wielu skanerów, można rozproszyć obciążenie – np. mieć centralny serwer GVM oraz kilka sensorów (skanerów OpenVAS) w różnych lokalizacjach, komunikujących się z nim. W odróżnieniu od niektórych darmowych wersji skanerów (ograniczających zakres użycia), GVM Community Edition nie ma sztucznych limitów co do liczby skanowanych IP czy częstotliwości skanów. Oczywiście wraz ze wzrostem skali rosną wymagania sprzętowe, ale o tym w kolejnym rozdziale.

Społeczność i ciągły rozwój: Jako projekt open-source, GVM czerpie z wkładu globalnej społeczności. Błędy są na bieżąco zgłaszane i poprawiane przez użytkowników na forum Greenbone, a co rok udostępniane są nowe wersje (odzwierciedlane w numeracji np. 21.04, 22.04, 22.10 itp.). Użytkownicy mają dostęp do obszernej dokumentacji, a także wsparcia na forach. Greenbone ze swojej strony zapewnia „silnik” rozwoju – utrzymuje feed podatności oraz wydaje wersje korporacyjne. Można więc liczyć, iż narzędzie będzie aktualne i wspierane w kolejnych latach.

Podsumowując, warto używać GVM, ponieważ oferuje on profesjonalny skaner podatności za darmo, z aktualną bazą zagrożeń i możliwością dostosowania do własnych potrzeb. Trzeba być jednak świadomym, iż brak kosztów licencji rekompensujemy własnym nakładem pracy – instalacja i utrzymanie GVM wymagają pewnej wiedzy technicznej i zasobów (serwer, konfiguracja). Dla wielu organizacji jest to jednak opłacalny kompromis, zwłaszcza jeżeli dysponują ograniczonym budżetem na bezpieczeństwo, a jednocześnie chcą mieć skuteczny proces wykrywania podatności.

Wymagania systemowe i środowiskowe

System operacyjny: GVM jest rozwiązaniem przeznaczonym głównie dla systemów Linux. Oficjalnie wspierane i najczęściej używane dystrybucje to m.in. Debian (wersje stabilne, np. Debian 11/12), Ubuntu LTS (np. 22.04, 24.04) oraz dystrybucje z nich pochodne (Kali Linux, Linux Mint). Istnieją również pakiety dla Fedory i CentOS Stream 9. W środowisku Kali Linux GVM jest dostępny bezpośrednio z repozytoriów (pakiet gvm), co wskazuje, iż ta dystrybucja jest przygotowana do jego obsługi. Systemy Windows nie są wspierane jako platforma instalacji GVM (choć istnieje możliwość uruchomienia gotowej maszyny wirtualnej z GVM). W praktyce zaleca się instalację na serwerze z Ubuntu/Debian lub skorzystanie z gotowego kontenera Docker, który Greenbone udostępnia (dla zaawansowanych użytkowników).

Wymagania sprzętowe: Pełna instalacja GVM (menedżer + skaner + bazy danych) ma dość wysokie wymagania jak na oprogramowanie open-source. Minimalna zalecana konfiguracja to 2 vCPU, 4 GB RAM oraz ok. 20 GB wolnego miejsca na dysku. Taka specyfikacja pozwoli na podstawowe skany pojedynczych hostów. W środowiskach produkcyjnych lub przy skanowaniu większych zakresów zdecydowanie rekomenduje się mocniejszy sprzęt: 4 rdzenie CPU, 8 GB RAM (lub więcej) i ok. 50–60 GB dysku na pliki bazy, skrypty NVT i logi. Pamięć RAM jest szczególnie istotna, ponieważ skaner OpenVAS wczytuje do pamięci dziesiątki tysięcy testów – przy zbyt małej pamięci może dochodzić do spowolnień lub przerywania skanów. Przykładowo, sam feed NVT może zajmować ~200 MB na dysku, baza danych również rośnie wraz z liczbą skanów. Ponadto Redis jako cache trzyma struktury danych w RAM (kilka gigabajtów przy pełnym feedzie). Z doświadczeń użytkowników wynika, iż absolutne minimum 4 GB RAM pozwala uruchomić GVM, ale komfort pracy (zwłaszcza przeglądania raportów w trakcie skanowania) daje dopiero 8 GB i więcej. Nie należy też zapominać o obciążeniu CPU – skanowanie intensywnie korzysta z procesora (szyfrowanie, skanowanie portów, przetwarzanie skryptów NASL). Przy wielu równoległych skanowanych hostach, dodatkowe rdzenie skracają czas trwania zadania.

Połączenie z internetem: Niezbędne jest zapewnienie dostępu do internetu (przynajmniej jednokierunkowo – z serwera GVM do sieci) w celu aktualizacji feedów podatności. Podczas inicjalizacji i codziennych synchronizacji GVM łączy się z serwerami Greenbone (domeny *.greenbone.net) i pobiera aktualizacje dzięki rsync/HTTPS. jeżeli instalujemy GVM w odciętym środowisku (bez dostępu do sieci), istnieje możliwość offline’owej aktualizacji poprzez manualne przenoszenie paczek feedu, ale jest to proces skomplikowany – zaleca się jednak zapewnienie połączenia sieciowego. Poza aktualizacjami, dostęp do internetu może być potrzebny w trakcie skanów dla niektórych testów (np. sprawdzanie odwołań HTTP, pobieranie informacji o certyfikatach CRL itp.), ale większość testów opiera się na lokalnej bazie.

Konto i uprawnienia: GVM powinien działać pod dedykowanym użytkownikiem systemowym (zwykle o nazwie gvm lub _gvm). Instalacja z pakietów lub skryptów zwykle zakłada utworzenie takiego konta i grupy, a także skonfigurowanie odpowiednich uprawnień do folderów (np. /var/lib/gvm/ na pliki feedu, /var/log/gvm/ na logi). Niewskazane jest uruchamianie usług GVM na koncie root. Użytkownik GVM musi mieć możliwość uruchamiania niektórych komend z podwyższonymi uprawnieniami (np. openvas Scanner może być konfigurowany w sudoers, aby miał dostęp do pewnych operacji sieciowych lub narzędzi systemowych jak nmap). Instalator bądź skrypt instalacyjny zwykle sam to konfiguruje (np. dodaje wpisy do /etc/sudoers.d/ pozwalające użytkownikowi gvm uruchamiać skaner). Wymagane jest również dodanie użytkownika GVM do grup takich jak redis (aby czytać socket Redis) czy postgres (czasem do obsługi bazy, zależnie od konfiguracji dostępu). W kontekście bazy danych PostgreSQL – GVM potrzebuje bazy i użytkownika (np. o nazwie gvmd), z odpowiednimi uprawnieniami (tworzenie tabel, zapisy).

Sieć i zapora: Domyślnie po instalacji interfejs webowy GSA (gsad) nasłuchuje lokalnie na porcie 9392/tcp (tylko na 127.0.0.1, protokół HTTP). Oznacza to, iż interfejs jest dostępny tylko z poziomu lokalnej maszyny (co zwiększa bezpieczeństwo domyślnej konfiguracji). Aby zalogować się do konsoli z innego hosta (np. ze swojej przeglądarki na komputerze), trzeba albo przekierować port (np. tunel SSH), albo skonfigurować gsad do nasłuchu na interfejsie zewnętrznym (adres 0.0.0.0) – jak to zrobić, omawiamy w sekcji o problemach. jeżeli zamierzamy udostępnić UI w sieci, warto również zadbać o szyfrowanie (HTTPS) – domyślnie gsad startuje na HTTP, ale można mu podać certyfikat TLS. Poza portem 9392, inne istotne porty to 5432 (domyślny PostgreSQL), 6379 (domyślny Redis – choć w GVM używany bywa socket zamiast portu), 1883 (Mosquitto MQTT), ewentualnie 9390 (często używany port dla HTTPS gsad, gdy włączymy SSL). o ile serwer GVM stoi za firewallem, należy otworzyć co najmniej port 9392 jeżeli chcemy mieć dostęp do panelu z innych maszyn. W przypadku wdrażania sensorów skanujących, komunikacja gvmd–ospd odbywa się zwykle po gniazdach UNIX lub przez sieć (OSP używa protokołu TCP na porcie konfigurowalnym, domyślnie 9390 dla połączeń master-slave, ale to zaawansowany scenariusz).

Zależności programowe: Przed instalacją GVM warto upewnić się, iż system ma zainstalowane pewne pakiety: m.in. Python 3, libraries GLib/GMP, kompilatory (jeśli budujemy ze źródeł), narzędzia sieciowe typu nmap. Brak np. nmap może skutkować tym, iż skany nie wykryją żadnych portów (a w konsekwencji podatności) – to częsty problem, gdy instalacja była niekompletna. W przypadku korzystania z gotowych paczek instalator zwykle pobiera wszystkie potrzebne zależności (w tym nmap, gnutls, libxml2, gnupg, nsis do Windows LSC itp.). W razie kompilacji manualnej, dokumentacja Greenbone wymienia listę wymaganych pakietów deweloperskich (cmake, gcc, libglib2.0-dev, libgnutls28-dev, libpq-dev, redis-server, mosquitto itp.). Podsumowując, GVM najlepiej instalować na świeżym, zaktualizowanym systemie, który spełnia minimalne wymagania – pozwoli to uniknąć problemów wydajnościowych i konfiguracyjnych.

Instalacja GVM krok po kroku (na przykładzie Ubuntu 22.04)

Instalacja GVM może być przeprowadzona na dwa sposoby: za pomocą gotowych pakietów (jeśli są dostępne dla danej dystrybucji) lub poprzez kompilację ze źródeł. W przypadku Ubuntu 22.04 istnieje wygodna opcja skorzystania z nieoficjalnego repozytorium PPA przygotowanego przez społeczność, które zawiera najnowszą stabilną wersję GVM 22.04. Poniżej opisujemy instalację krok po kroku z użyciem tego PPA – jest to dość prosty i sprawdzony sposób na uruchomienie GVM na Ubuntu:

Krok 1: Instalacja bazy danych PostgreSQL. GVM korzysta z PostgreSQL, więc najpierw zainstalujmy serwer bazy (jeśli nie pozostało zainstalowany). W Ubuntu wykonujemy: sudo apt update && sudo apt install postgresql – upewniając się, iż baza startuje (domyślnie powinna uruchomić się automatycznie na porcie 5432). Możemy utworzyć użytkownika i bazę dla GVM, ale pakiety PPA zrobią to za nas podczas instalacji. Po instalacji Postgresa warto sprawdzić, czy usługa działa: systemctl status postgresql. (Domyślnie baza będzie nasłuchiwać tylko lokalnie – co jest ok dla naszych potrzeb).

Krok 2: Dodanie repozytorium GVM (PPA). Autor PPA (Mohammad Razavi) przygotował paczki GVM-22.04 dla Ubuntu 22.04. Dodajemy repozytorium poleceniem: sudo add-apt-repository ppa:mrazavi/gvm. Spowoduje to dodanie źródła pakietów do systemu apt. Następnie zaktualizuj listy pakietów: sudo apt update.

Krok 3: Instalacja pakietu GVM. Po dodaniu PPA instalujemy cały zestaw poleceniem: sudo apt install gvm. Pakiet metapaczki gvm powinien automatycznie zainstalować wszystkie wymagane komponenty: gvmd, openvas-scanner, ospd-openvas, gsad, notus-scanner (opcjonalnie), gvm-libs, greenbone-feed-sync itp. Podczas instalacji mogą pojawić się pytania (np. czy utworzyć certyfikaty, użytkownika) – akceptujemy domyślne akcje. Po pomyślnej instalacji, w systemie powinny być zarejestrowane usługi systemd: gvmd, ospd-openvas, gsad (i ewentualnie notus-scanner), gotowe do uruchomienia jako demony.

Krok 4: Inicjalizacja i synchronizacja feedów. Po zainstalowaniu GVM, zanim zaczniemy z niego korzystać, musimy pobrać bazę testów podatności i danych zabezpieczeń. W pakietach dostarczone jest narzędzie greenbone-feed-sync (dawniej oddzielne skrypty greenbone-nvt-sync, openvas-scapdata-sync itp.). Na Ubuntu z PPA zaleca się wykonać następujące komendy (jako użytkownik gvm lub z użyciem sudo do tego użytkownika):

sudo -u gvm greenbone-nvt-sync sudo -u gvm greenbone-feed-sync --type CERT sudo -u gvm greenbone-feed-sync --type SCAP sudo -u gvm greenbone-feed-sync --type GVMD_DATA

Uwaga: Na tym etapie może pojawić się problem który będzie objawiać się otrzymaniem informacji błędu:

receiving incremental file list rsync: [Receiver] mkdir "/var/lib/notus" failed: Permission denied (13) rsync error: error in file IO (code 11) at main.c(791) [Receiver=3.2.7]

Stwórz wtedy katlog /var/lib/notus oraz zmień właściciela katalogu chown gvm:gvm i następnie uruchom ponownie komende sudo -u gvm greenbone-nvt-sync.

Uwaga: Możesz się spotkać również z komunikatem /var/lib/gvm/feed-update.lock is locked by another process. Waiting 5 seconds before next try. wtedy należy zastopować deamon gvmd sudo systemctl stop gvmd i następnie uruchomić synchronizacje ponownie.

Pierwsza komenda pobierze z serwerów Greenbone całą kolekcję NVT (testów podatności). Kolejne trzy zsynchronizują dodatkowe bazy: certyfikaty CERT (np. alerty CERT-Bund), dane SCAP (dane o podatnościach z bazy CVE, OVAL) oraz dane menedżera (np. domyślne konfiguracje skanowania, listy portów itp.). Uwaga: Pełna synchronizacja za pierwszym razem może potrwać choćby kilkadziesiąt minut, zależnie od łącza internetowego. Narzędzia nie pokazują intensywnego logu, ale można w innej konsoli obserwować np. tail -f /var/log/gvm/gvmd.log – gvmd zacznie importować dane zaraz po pobraniu feedu (można tam zobaczyć komunikaty o importowaniu plików SCAP, CVE itp.). Zanim przejdziemy dalej, upewnijmy się, iż wszystkie sync zakończyły się sukcesem. W interfejsie webowym GSA jest też strona Administration > Feed Status pokazująca status – powinny tam pojawić się daty aktualizacji zamiast komunikatu „Update in progress”.

Krok 5: Rebuild bazy i uruchomienie usług. W niektórych przypadkach (zwłaszcza przy aktualizacji lub reinstalacji) zaleca się przebudować cache NVT w bazie gvmd, aby upewnić się, iż wszystkie testy są załadowane. Pakiet PPA dostarcza skrypt, który to ułatwia. Można to zrobić komendą:

sudo -u gvm gvmd --rebuild

(jeśli pojawi się błąd o braku połączenia do bazy, należy załadować zmienne środowiskowe komendą export $(sudo cat /etc/default/gvmd-pg) i ponowić polecenie). Przy pierwszej instalacji jednak zwykle nie jest to konieczne – gvmd sam zaimportuje dane feedu.

Teraz startujemy (o ile jeszcze nie wystartowały) usługi GVM:

sudo systemctl start ospd-openvas sudo systemctl start gvmd sudo systemctl start gsad

Można też sprawdzić ich status: sudo systemctl status gvmd ospd-openvas gsad – wszystkie powinny być active (running). jeżeli któraś usługa nie wystartowała, trzeba sprawdzić logi (/var/log/gvm/ospd-openvas.log, /var/log/gvm/gvmd.log) w poszukiwaniu błędów.

Krok 6: Dostęp do interfejsu webowego GSA. Po uruchomieniu usług, interfejs Greenbone Security Assistant jest dostępny domyślnie pod adresem: http://localhost:9392. Ponieważ gsad nasłuchuje tylko lokalnie, aby otworzyć go zdalnie, na tym etapie najprościej jest skorzystać z przeglądarki w środowisku graficznym na serwerze (jeśli to maszyna z GUI) lub wykonać tunel SSH (np. ssh -L 9392:127.0.0.1:9392 user@server). Zakładamy na razie dostęp lokalny. Przy pierwszym uruchomieniu zalogować się można używając domyślnego konta administracyjnego:

• Username: admin
• Password: admin

Asystent bezpieczeństwa Greenbone po pierwszym zalogowaniu

Te dane dostępowe są tworzone automatycznie przez pakiety PPA. Ważne: system wymusi zmianę domyślnego hasła przy pierwszym logowaniu (w nowszych wersjach pojawia się monit). Należy ustawić silne hasło dla użytkownika admin. Gdy już się zalogujemy, naszym oczom ukaże się panel Greenbone Security Assistant – możemy zacząć konfigurować skany.

Jeśli wszystkie powyższe kroki przebiegły pomyślnie, mamy działającą instalację GVM. Na Ubuntu 22.04 z PPA proces ten jest dość zautomatyzowany – pakiety tworzą użytkownika _gvm, konfigurują usługi systemd oraz przygotowują środowisko (certyfikaty, foldery, wpisy sudo itp.). Powyższe polecenia synchronizacji feedu trzeba wykonywać manualnie (bądź skonfigurować automatyczną aktualizację – o tym w sekcji 9).

Wskazówka praktyczna: jeżeli napotkamy problemy, przydatne logi to:

• /var/log/gvm/gvmd.log – logi usługi menedżera (tu pojawią się np. błędy bazy, brak skanerów, problemy z feedem).
• /var/log/gvm/ospd-openvas.log – logi skanera (błędy Redisa, brak MQTT, problemy podczas skanowania).
• /var/log/gvm/gsad.log – logi interfejsu web (np. błędy certyfikatów).

Można też skorzystać z narzędzia diagnostycznego gvm-check-setup, które sprawdza kompletność instalacji. Dla wersji 22.4 komenda sudo gvm-check-setup przechodzi przez kolejne etapy i zgłasza co ewentualnie jest nie tak (np. brak NVT, nieaktywny demon itp.). W przykładzie z Kali Linux, output gvm-check-setup pokazuje wszystkie komponenty jako OK, co potwierdza poprawną instalację.

Alternatywa: kompilacja ze źródeł i skrypty instalacyjne. o ile wolimy mieć pełną kontrolę lub używamy systemu bez gotowych pakietów, można zainstalować GVM budując każdy komponent manualnie (gvm-libs, openvas-scanner, gvmd, gsad, gvm-tools itd.). Proces ten jest dość złożony i czasochłonny, aczkolwiek Greenbone udostępnia instrukcje krok po kroku w dokumentacji „Building from Source”. Istnieją też społecznościowe skrypty automatyzujące kompilację. Przykładowo, projekt OpenVAS-Installation (Kastervo/OpenVAS-Installation) na GitHub dostarcza skrypt bash dla Debiana 12/Ubuntu, który pobiera źródła najnowszej wersji, weryfikuje GPG, kompiluje i instaluje wszystkie komponenty, tworzy użytkownika gvm, generuje certyfikaty SSL i rejestruje usługi systemd. Taki skrypt ustawia również bezpieczne domyślne uprawnienia (zasada najmniejszych uprawnień) i loguje przebieg instalacji, co bywa bardzo pomocne. jeżeli więc oficjalne pakiety nie są dostępne dla naszej platformy, warto rozważyć skorzystanie z takiego skryptu lub kontenerów Dockera od Greenbone.

Podsumowując, na Ubuntu 22.04 najprostszą drogą jest użycie PPA i apt – w kilkanaście minut otrzymujemy działający system. Po zalogowaniu do GSA możemy przejść do konfiguracji skanów. W kolejnych sekcjach założymy, iż mamy już GVM uruchomiony i połączymy się przez interfejs webowy w celu dalszych ustawień.

Konfiguracja i pierwsze kroki

Po pomyślnej instalacji GVM i zalogowaniu się do interfejsu Greenbone Security Assistant (GSA) naszym pierwszym zadaniem będzie utworzenie użytkownika (jeśli nie korzystamy z domyślnego) i skonfigurowanie podstawowych elementów: celów skanowania oraz zadań skanujących.

Konto administracyjne: W większości przypadków instalacja z pakietów tworzy użytkownika admin. Możemy korzystać z niego, ale dobrą praktyką jest utworzenie dodatkowych kont dla poszczególnych operatorów skanera (np. osobne konto dla wszystkich pentestera czy członka zespołu SOC). W GSA możemy to zrobić w zakładce Administration > Users – jako admin dodajemy nowego użytkownika, przypisując mu rolę (Admin lub User) i ewentualnie grupę. W środowisku testowym często jednak pozostajemy przy koncie admin (zmieniając domyślne hasło!). Warto też zajrzeć do ustawień polityki haseł (plik pwpolicy.conf), gdyż przy domyślnej pustej polityce GVM będzie ostrzegał o braku wymagań co do złożoności hasła.

Tworzenie targetu (celu skanowania): Target definiuje, co chcemy skanować. Może to być pojedynczy host (adres IP lub domena), cała podsieć (np. 192.168.1.0/24) lub lista adresów/zakresów. W GSA przechodzimy do zakładki Configuration > Targets, klikamy przycisk „New Target”. W formularzu podajemy nazwę (Name) – np. „Moja Sieć Testowa” – oraz sposób definicji hostów. Najczęściej wybieramy Manual i wpisujemy adresy IP albo zakresy. Przykładowo, dla jednego hosta wpisujemy 192.168.6.2, dla zakresu można użyć notacji CIDR (np. 192.168.6.0/24). W opcjach targetu znajduje się także ustawienie Alive Test – domyślnie ICMP Echo. To mechanizm, który OpenVAS używa, by sprawdzić czy host jest aktywny przed adekwatnym skanowaniem. jeżeli nasze hosty nie odpowiadają na ping (bo np. zapora blokuje ICMP), warto zmienić Alive Test na Consider Alive (traktuj hosty jako aktywne bez testu) lub np. spróbować testu ARP/Netstat (w przypadku skanowania z wewnątrz sieci). Po skonfigurowaniu adresów zapisujemy target (Save). Zostanie on dodany do listy dostępnych celów. Możemy utworzyć wiele targetów – np. osobno dla serwerów produkcyjnych, osobno dla sieci biurowej itp.

Tworzenie zadania skanu (Task): Mając zdefiniowany target, możemy utworzyć Task, czyli zadanie skanowania. Zadanie łączy target z konkretną konfiguracją skanowania (Scan Config) i ewentualnie harmonogramem lub credencialami. Przechodzimy do zakładki Scans > Tasks, klikamy „New Task”. W formularzu nadajemy nazwę zadania (np. „Skan tygodniowy sieci biurowej”), wybieramy z listy Target utworzony przed chwilą (np. „Moja Sieć Testowa”), a także Scan Config, czyli profil skanowania. Domyślnie dostępnych jest kilka profili – najważniejsze z nich to:

• Full and Fast (Pełny i szybki) – domyślny profil, wykonuje większość testów z bazy, ale w sposób zoptymalizowany (np. pomija pewne powolne testy lub ogranicza głębokość, używa wyników skanowania portów do doboru testów). Daje dobry kompromis między czasem skanu a pokryciem podatności – zalecany na początek.
• Full and very deep / Full and very deep ultimate – profile najbardziej dogłębne, wykonujące wszystkie testy, choćby te inwazyjne i czasochłonne. „Ultimate” oznacza brak jakichkolwiek skrótów: skanowane są wszystkie porty, wszystkie usługi i wszystkie testy bez warunków. Taki profil może wykryć więcej drobnych podatności, ale trwa bardzo długo i obciąża mocno sieć/cel. Stosujemy go, gdy chcemy całkowicie przeskanować system lub podejrzewamy, iż jest zainfekowany (forensics).
• Discovery / Host Discovery – profile służące tylko do wykrywania aktywnych hostów i otwartych portów, bez uruchamiania szczegółowych testów podatności. Przydatne, gdy chcemy najpierw mapować sieć, a potem skanować szczegółowo tylko znalezione hosty.
• System Discovery – profil pośredni, identyfikujący systemy operacyjne i podstawowe info (też bez pełnych testów luk).

W najnowszych wersjach GVM, niektóre zaawansowane profile (Full and Fast Ultimate, Full and very deep ultimate) mogą być dostępne tylko z komercyjnym feedem – natomiast standardowe Full/Fast i Full/Deep są w Community Feed. Do naszego pierwszego skanu najlepiej pozostawić Full and fast (domyślny), który zapewnia dobre pokrycie i rozsądny czas. W formularzu Task możemy również ustawić Schedule (harmonogram) – np. aby skan uruchamiał się co tydzień o określonej porze. Na razie jednak zostawmy Schedule jako „None” (zadanie manualne). Inne opcje to np. Alerts (powiadomienia po skanie), Credential (dane uwierzytelniające do skanów uwierzytelnionych, np. SNMP community, konto SSH – to temat na osobny rozdział, domyślnie brak). Po ustawieniu nazwy, targetu i profilu klikamy Save – nowe zadanie pojawi się na liście z statusem „Queued” lub „New”.

Uruchomienie pierwszego skanu: Aby wystartować zadanie, zaznaczamy je na liście Tasks i klikamy ikonę „Start” (trójkąt „Play”). Status zadania zmieni się na „Running” albo „Queued” (jeśli inny skan akurat działa). GSA pokaże pasek postępu i procent wykonania. Teraz należy cierpliwie poczekać – w zależności od wielkości targetu i wybranego profilu skan może trwać od kilku do kilkudziesięciu minut (a w skrajnych przypadkach wiele godzin). Dla pojedynczego hosta Full&Fast często kończy się w 5-15 minut, dla /24 może to być parę godzin, zwłaszcza jeżeli hostów jest dużo i mają wiele otwartych portów. Możemy obserwować na bieżąco częściowe wyniki – GSA umożliwia podgląd raportu choćby w trakcie skanowania (klikając w odnośnik w kolumnie Report lub na pasek postępu). Zwróćmy uwagę, iż pierwszy skan po świeżej instalacji może być wolniejszy, gdyż skaner w locie kompiluje i optymalizuje skrypty NASL. Kolejne skany (przy ciepłym cache Redis) często są szybsze.

Przykładowy wynik skanu: Po zakończeniu zadania, status zmieni się na Done, a w kolumnie Severity zobaczymy sumaryczny wynik (np. High, Medium – odpowiadający najwyższej znalezionej podatności). Klikamy nasz raport (np. Report: Moja Sieć Testowa) aby zobaczyć szczegóły. Raport GVM dzieli wyniki per host – dla wszystkich przeskanowanego adresu IP mamy listę wykrytych podatności oraz otwartych portów i usług. Każda wykryta podatność ma przypisany poziom zagrożenia (Severity) – na podstawie skali CVSS: zwykle Low (niski), Medium (średni), High (wysoki) lub Critical (krytyczny). W raporcie widoczna jest też skala CVSS (np. 5.0, 7.5, 9.8) oraz unikalny identyfikator CVEs powiązanych z podatnością, jeżeli dotyczy znanych luk. Klikając konkretną podatność, rozwijamy szczegółowy opis: znajduje się tam opis podatności, jej możliwe konsekwencje, zalecenia (Solution/Fix) oraz odnośniki (References) – np. linki do stron CVE, do biuletynów bezpieczeństwa producenta, exploit-db, itp. Przykładowo, skanując stary serwer WWW, możemy znaleźć podatność „Apache HTTP Server <2.4.49 Path Traversal (CVE-2021-41773)” oznaczoną jako High z CVSS 7.5 – w szczegółach będzie informacja o możliwości przejęcia systemu, zalecenie aktualizacji Apache do nowszej wersji i link do oficjalnego advisory.

Eksport i zapis wyników: GVM umożliwia zapisanie raportu w różnych formatach. Z poziomu widoku raportu można kliknąć ikonę „Download Report” i wybrać format: dostępne są m.in. PDF, HTML, XML, CSV. Format PDF jest przydatny do podzielenia się raportem z kierownictwem lub załączenia do dokumentacji – generowany jest plik PDF z podsumowaniem graficznym i listą wykrytych luk. CSV lub XML są z kolei użyteczne, gdy chcemy zaimportować wyniki do innego narzędzia (np. SIEM, arkusz kalkulacyjny lub inne skanery). Istnieje również format tzw. JSON (tutaj w API GMP), ale najczęściej używa się wymienionych. Po wybraniu formatu następuje generowanie i pobranie pliku. Warto wspomnieć, iż w razie bardzo dużych raportów generowanie PDF może obciążyć serwer i trwać dłużej – GVM radzi sobie z kilkuset stronami raportu, ale przy tysiącach wyników lepiej eksportować do CSV/XML i dalej obrabiać.

Integracja z procesem zarządzania podatnościami: Samo wykrycie podatności to dopiero początek – ważne jest, co zrobimy z tymi informacjami. GVM ułatwia dalszą pracę poprzez funkcje zarządzania: możemy dodawać Statusy i Notatki do poszczególnych wyników (np. oznaczyć, iż dana podatność została przekazana do działu IT do naprawy, albo iż to false positive po weryfikacji). Możemy też wykorzystać funkcję Alerts, aby np. po skanie automatycznie wysłać email z raportem, albo uruchomić skrypt (np. integrujący z systemem ticketowym). W praktyce, w profesjonalnym środowisku po każdym skanie generuje się listę najważniejszych podatności, tworzy zgłoszenia naprawcze, monitoruje ich usunięcie, a następnie ponownie skanuje weryfikując, czy podatność zniknęła. GVM wspiera te etapy o tyle, iż pozwala łatwo filtrować wyniki (np. pokaż tylko High/Critical), grupować je i eksportować. Co więcej, poprzez API można zautomatyzować wyciąganie np. wszystkich nowych podatności odkrytych od ostatniego skanu i przekazywać je do zewnętrznego systemu. Ostatecznie celem jest poprawa bezpieczeństwa: GVM dostarcza informacji (raportów), które włączamy w cykl zarządzania podatnościami – od wykrycia, przez priorytetyzację (np. na podstawie CVSS i kontekstu biznesowego), po remediację i ponowną weryfikację.

Analiza wyników – jak czytać raporty?

Raport wygenerowany przez GVM może początkowo onieśmielać ilością informacji, ale jest zorganizowany w przejrzysty sposób. Zrozumienie struktury raportu i priorytetów ułatwi nam skuteczne wykorzystanie danych. Oto najważniejsze elementy, na które należy zwrócić uwagę:

Klasyfikacja podatności według surowości (Severity): GVM przypisuje każdej wykrytej podatności poziom surowości oparty na skali CVSS (Common Vulnerability Scoring System). Domyślnie używana jest skala CVSS v3.0/3.1, a poziomy prezentowane w interfejsie to: Low (niski, zwykle CVSS 0.1–3.9), Medium (średni, CVSS 4.0–6.9), High (wysoki, CVSS 7.0–8.9) oraz Critical (krytyczny, CVSS 9.0–10.0). W raporcie GSA zobaczymy sumaryczną ocenę dla wszystkich hosta – np. o ile choć jedna podatność ma status High, to host będzie oznaczony kolorem czerwonym z najwyższą znalezioną wartością CVSS. Pozwala to od razu identyfikować najbardziej zagrożone maszyny. Oprócz tego, przy każdej podatności podany jest dokładny wynik CVSS (base score) oraz wektor, co pozwala ocenić szczegółowo, jak dana ocena została wyliczona (np. AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H dla CVSS 9.8).

Podział wyników według hostów: Raport jest domyślnie pogrupowany per adres IP/nazwa hosta. Dla każdej maszyny najpierw wyświetlane są informacje ogólne (System Information) – np. wykryty system operacyjny, otwarte porty, usługi, wersje – a następnie lista podatności wykrytych na tym hoście. Taka struktura jest wygodna, gdy audytor odpowiedzialny jest za konkretny serwer – od razu widzi wszystkie problemy dotyczące jego systemu. Istnieje możliwość zmiany widoku (np. pogrupowanie według podatności globalnie, ale rzadziej się to stosuje). Przy każdym hoście podawana jest też liczba wykrytych luk w podziale na High/Med/Low/Info.

Szczegóły podatności: Najwięcej informacji kryje się po kliknięciu konkretnej pozycji na liście podatności. Każda podatność posiada unikalny VT ID (identyfikator testu) oraz nazwę opisową. Po rozwinięciu zobaczymy sekcje: Summary (krótki opis podatności, np. „Usługa SSH umożliwia uwierzytelnianie dzięki pustego hasła”), Detection Result (co dokładnie skaner znalazł – np. baner wersji, ciąg świadczący o podatności), Impact (jakie mogą być skutki wykorzystania luki), Solution (zalecenia naprawcze, np. „Zaktualizuj oprogramowanie do wersji X lub wyłącz podatną funkcję”), Vulnerability Insight (dodatkowe techniczne szczegóły), Affected Software/OS (jeśli dotyczy konkretnego softu), CVSS Scores (wraz z wektorem), References (tu znajdują się linki do źródeł). W referencjach najważniejsze to linki do CVE – np. CVE-2021-41773 – które prowadzą do bazy MITRE/NVD z pełnym opisem. Mogą być też linki do Exploit-DB (jeśli istnieje publiczny exploit), do poradników konfiguracji, standardów (OWASP, CWE) itp. Wszystkie te dane pochodzą z feedu Greenbone. Dzięki nim raport GVM jest samowystarczalny informacyjnie – analityk nie musi osobno googlować danej luki, bo podstawowe info i linki ma pod ręką. Przykładowo, przy podatności „SSL/TLS: Poodle Attack (CVE-2014-3566)” Summary wyjaśni, iż protokół SSLv3 jest podatny na atak Poodle, Impact opisze iż możliwe jest odszyfrowanie ruchu, Solution poradzi wyłączenie SSLv3, a Reference zawiera CVE i link do bloga Google Security Team.

Wyniki informacyjne: W raporcie oprócz podatności mogą pojawić się pozycje o niskiem lub zerowym poziomie surowości (Severity: Log/Info). Są to informacje, które nie stanowią podatności same w sobie, ale mogą być użyteczne – np. otwarty port, dostępny baner wersji usługi, certyfikat SSL z pewnymi adekwatnościami, konfiguracja serwera SSH. Takie informacje GVM zwraca jako logi, by administrator wiedział np. iż serwer pokazuje wersję systemu (co może być wykorzystane przez atakującego w rekonesansie). Można je często odfiltrować w widoku (np. pokazując tylko Medium+High). Niemniej podczas analizy raportu warto przejrzeć i te sekcje – bywają tam rzeczy jak „Host does not respond to ICMP – marked as dead” (co wyjaśni czemu host był pominięty w skanie) lub np. „OS Detection: Windows 10” (przydatne do inwentaryzacji).

Filtry i wyszukiwanie: GSA pozwala dynamicznie filtrować wyniki raportu. U góry strony raportu jest pole Filter. Przykładowe filtry: severity>=High (pokaż tylko poważne i krytyczne), cvss_base>=7 (podobnie), qod<100 (Quality of Detection mniejsze niż 100 – czyli potencjalnie false positive). Filtrowanie jest bardzo przydatne, gdy mamy ogromny raport – skupiamy się najpierw na najpoważniejszych problemach. Filtry można też zapisywać jako predykaty.

Ocena wyników: Po zapoznaniu się z raportem, należy ocenić, które luki są najpilniejsze do usunięcia. Tu oprócz surowości warto wziąć pod uwagę kontekst: np. krytyczna podatność na serwerze testowym odciętym od internetu może poczekać, a średnia podatność na serwerze publicznym powinna być zrobiona od razu. GVM dostarcza CVSS Temporal score jeżeli dostępne (uwzględnia np. czy exploit jest publiczny), co może pomóc w priorytetyzacji. Przydatną metryką jest też QoD (Quality of Detection) – określa na ile pewne jest stwierdzenie podatności. 100% QoD oznacza bezpośrednie potwierdzenie (np. wersja systemu znana jako podatna), niższe np. 70% może oznaczać poszlakę (heurystyka).

Eksport i dalsza obróbka: Omówiony wcześniej eksport raportu do PDF/CSV pozwala nam pracować z wynikami poza GVM. PDF jest czytelny dla menedżerów, natomiast CSV można zaimportować do Excela lub narzędzi typu vulnerability management platform, aby śledzić statystyki (np. liczba luk wysokich na host). Format XML (tzw. XML report zgodny ze schematem OpenVAS) umożliwia wymianę danych między skanerami – np. niektóre narzędzia (TheHive, Metasploit) potrafią wczytać raport XML z OpenVAS i wygenerować z tego case’y/incydenty lub ataki.

Integracja z procesem zarządzania podatnościami (ciąg dalszy): Po przeanalizowaniu raportu, dobre praktyki nakazują podjąć działania. W systemie GVM można oznaczyć wyniki jako False Positive (jeśli wiemy, iż dana detekcja jest błędna) lub Accepted Risk (świadomie akceptujemy ryzyko, np. nie możemy wyłączyć danej usługi). Można to zrobić przez dodanie tzw. Override – wtedy przy kolejnym skanie ta konkretna luka nie będzie już podnosić alarmu (lub zmieni kolor na akceptowany). Trzeba jednak używać tego ostrożnie, by nie zatuszować realnych problemów. W dużej organizacji raporty GVM mogą zasilać np. system Ticketowy: każde znalezisko High generuje ticketa dla adminów z terminem na załatanie. GVM nie posiada własnego systemu śledzenia napraw, ale poprzez integracje API lub alerty email można ten proces zautomatyzować. Wreszcie, po usunięciu podatności (np. zaktualizowano wadliwy serwer), uruchamiamy ponowny skan (można skorzystać z opcji Escalator lub po prostu kolejnego zadania) i potwierdzamy, iż dziura zniknęła z raportu. Tak zamyka się pętla zarządzania podatnościami. GVM jako narzędzie zapewnia nam solidne dane wejściowe do tej pętli – raporty bogate w informacje i możliwości ich obróbki.

Automatyzacja i API

Jedną z mocnych stron GVM jest otwartość – możemy go kontrolować i integrować przy użyciu API oraz narzędzi skryptowych. Dzięki temu możliwa jest automatyzacja skanowania oraz włączenie GVM w ciągłe procesy DevOps/SecOps.

Greenbone Management Protocol (GMP): Jest to protokół oparty na XML, udostępniany przez usługę gvmd. GMP pozwala wykonywać praktycznie wszystkie operacje, które normalnie robimy w interfejsie – tworzenie użytkowników, targetów, zadań, uruchamianie skanów, pobieranie raportów, modyfikowanie ustawień. Protokół ten jest podstawą integracji – korzysta z niego chociażby wspomniany gsad (UI) komunikując się z gvmd. My również możemy bezpośrednio wysyłać komendy GMP. Aby ułatwić to zadanie, dostępne są gvm-tools – zestaw narzędzi i biblioteka w Pythonie przygotowane przez Greenbone. Najważniejsze składniki to:

• gvm-cli – klient wiersza poleceń, którym można np. połączyć się do gniazda GMP i przesłać żądanie XML. Obsługuje połączenie lokalne (Unix socket) lub TCP (np. zdalnie do gvmd). Przykład: gvm-cli socket --xml "<get_version/>" zwróci wersję API GMP, o ile gvmd nasłuchuje na sockecie. Możemy też dzięki gvm-cli uruchamiać skany: np. napisanie skryptu, który automatycznie tworzy target z adresem podanym w parametrze, a potem tworzy zadanie i je startuje.
• Python GVM API (python-gvm) – biblioteka Python pozwalająca wywoływać komendy GMP z poziomu skryptu Pythona w bardziej wygodny sposób (obiektowo). Za jej pomocą możemy np. pobrać listę wszystkich wyników skanu o danym ID (get_results(task_id)), wyfiltrować je i zapisać do bazy, itp..
• Przykładowe skrypty – gvm-tools zawiera kolekcję gotowych skryptów automatyzujących typowe czynności. Np. create_task.py – utworzenie zadania, start_task.py – wystartowanie go, export-pdf-report.gmp.py – eksport raportu do PDF. Skrypty te można używać jako budulec do własnych automatyzacji.

Dzięki GMP/API możemy osiągnąć następujące scenariusze automatyzacji:

• Integracja z CI/CD: Możemy w pipeline CI (np. GitLab CI, Jenkins) dołożyć etap, który po wdrożeniu aplikacji na środowisko testowe wywoła GVM, by przeskanował to środowisko. Przykładowo, w GitLab możemy użyć gvm-cli z parametrami (wcześniej generując konto API w GVM do autoryzacji) – istnieją dyskusje i rozwiązania tego typu na forum Greenbone. W ten sposób każda nowa wersja aplikacji przechodzi automatyczny skan bezpieczeństwa jako część pipeline (DevSecOps). Wyniki można automatycznie analizować – np. pipeline może sprawdzić czy nie pojawiła się nowa podatność krytyczna i na tej podstawie np. przerwać wdrożenie (tzw. security gate). Co ważne, wyniki skanów są przez cały czas dostępne w GVM (skan prowadzimy normalnie, tylko wyzwolenie jest z CI) – więc analityk może je przeglądać w GSA.
• Harmonogram skanów (cron vs scheduler): GVM ma wbudowany mechanizm scheduler (w GUI można ustawić np. zadanie co poniedziałek 3:00). Jednak czasem wygodniej użyć systemowego Crona dla pełnej kontroli. Możemy np. stworzyć skrypt Bash/Python który o określonej godzinie wywoła gvm-cli i uruchomi dany Task. Ewentualnie, script może najpierw sprawdzić czy poprzedni skan się zakończył, usunąć stare raporty, potem wystartować nowy. Cron może też posłużyć do automatycznego aktualizowania feedu – np. codziennie w nocy. W sekcji 9 omawiamy to szerzej, ale tu wspomnę: instalacja GVM czasem sama dodaje wpis do cron (użytkownika gvm) który co noc odpala greenbone-feed-sync, ale jeżeli nie – warto samemu dodać taki wpis.
• Integracja z SIEM/SOAR: Wiele organizacji chce, by dane o podatnościach trafiały np. do Splunk, QRadar czy otwartego SIEM-a (Wazuh, ELK). GVM tego nie robi out-of-the-box, ale przy pomocy API i eksportów jest to realne. Np. można napisać skrypt, który po każdym skanie pobiera raport w XML/JSON i parsuje go do formatu logów, po czym wysyła do SIEM jako zdarzenia (gdzie każde zdarzenie to np. „Host X – podatność Y – CVSS Z”). Inna opcja: integracja z platformą SOAR – można zbudować playbook, który korzystając z API GVM pobiera listę nowych krytycznych podatności i automatycznie tworzy incydent w systemie reagowania (np. TheHive). Pewien użytkownik na forum pytał o integrację z Wazuh i rozwiązanie polegało właśnie na wyciąganiu raportów poprzez GMP i wczytywaniu ich do Wazuh jako logi analizy podatności. Niektóre narzędzia mają dedykowane moduły: np. istnieje wtyczka OpenVAS do Wazuh, która potrafi współpracować z GVM – wymaga to skonfigurowania IP i danych uwierzytelnienia do GVM w Wazuh, a następnie Wazuh może cyklicznie wywoływać skan lub odbierać wyniki, by wyświetlać je na swoim dashboardzie. Taka integracja daje jednolity widok: w Wazuh widać zarówno alerty z IDS, jak i podatności z GVM (co pozwala np. ocenić ryzyko – czy atak, który właśnie wykrył IDS, dotyczy luki, którą mamy niezałataną).
• CLI dla administratorów: choćby bez pisania skryptów, samo istnienie gvm-cli i narzędzi takich jak gvmd (binarka menedżera) umożliwia pewne szybkie akcje skryptowe. Przykłady: masowe dodanie adresów do targetu (przez CSV import lub API), masowe usunięcie starych raportów starszych niż X dni (API delete_report w pętli), generowanie zestawienia podatności w formie tabelarycznej (wyciągamy CSV i obrabiamy w skrypcie awk/python). GVM posiada też narzędzie komand-line ospd-openvas (Open Scanner Protocol Daemon), ale ono jest używane głównie wewnętrznie – służy do integracji z innymi skanerami OSP, co raczej wychodzi poza nasze potrzeby (np. można by zewnętrzny skaner wpiąć do GVM, ale to rzadkie).

Reasumując, automatyzacja w GVM stoi otworem dzięki jego protokołom i narzędziom. W odróżnieniu od niektórych rozwiązań komercyjnych, tutaj mamy pełny dostęp do API bez dodatkowych opłat czy ograniczeń. Możemy to wykorzystać do integracji GVM w nasze procesy DevSecOps (skanowanie ciągłe), do budowy własnych raportów i alertów, a także do integracji z ekosystemem bezpieczeństwa (SIEM, SOAR, ticketing). Trzeba pamiętać o bezpieczeństwie samego API – jeżeli włączamy komunikację po TCP (np. otwieramy GMP na porcie, by zdalnie sterować GVM), należy zadbać o szyfrowanie (GMP over TLS) lub tunel VPN, by nie przekazywać wrażliwych danych (wyniki skanów, hasła) w sieci w otwartej formie. Alternatywnie, można ograniczyć sterowanie do lokalnych skryptów na serwerze GVM (np. wywoływanych przez cron).

Przykładowy scenariusz automatyzacji: co niedzielę o 2:00 w nocy skrypt bash uruchamia zadanie skanu całej sieci, a po ukończeniu wywołuje API, aby wyeksportować raport do CSV i zapisuje go na udziale sieciowym, jednocześnie wysyłając powiadomienie e-mail do administratorów. Taki skrypt może też analizować raport i jeżeli znajdzie nowe krytyczne luki, od razu wysłać dodatkowy alarm. To wszystko jest do zrealizowania właśnie dzięki dostępności API i elastyczności GVM.

Aktualizacje i utrzymanie GVM

Utrzymanie GVM w dobrej kondycji sprowadza się głównie do regularnych aktualizacji feedów podatności oraz monitorowania działania usług. W odróżnieniu od typowych systemów, gdzie aktualizujemy oprogramowanie do nowszych wersji, w GVM dużo częściej będziemy aktualizować dane, na podstawie których działa skaner.

Aktualizacje feedów (NVT, SCAP, CERT, GVMD_DATA): Jak wspomniano, Greenbone codziennie aktualizuje Community Feed o nowe testy i informacje. Aby nasz skaner wykrywał najnowsze podatności, musimy te aktualizacje pobierać. Standardowo robi się to komendami, które już poznaliśmy: greenbone-nvt-sync (pobranie i aktualizacja testów NVT) oraz greenbone-feed-sync --type <SCAP/CERT/GVMD_DATA>. Przy pierwszej instalacji wykonaliśmy pełną synchronizację; potem warto to powtarzać co najmniej raz dziennie. Najlepiej zautomatyzować – np. dzięki Crona. W wielu instalacjach pakiety tworzą zadanie cron dla użytkownika gvm, ale nie zawsze działa to out-of-box. Możemy manualnie dodać wpis do crontaba roota, który np. o 3:00 w nocy wykona skrypt aktualizujący feed. Przykład (crontab root):

0 3 * * * sudo -u gvm /usr/local/bin/greenbone-update.sh

gdzie greenbone-update.sh to skrypt zawierający kolejno polecenia sync dla NVT, GVMD_DATA, SCAP i CERT. Po takiej aktualizacji w logach gvmd lub w interfejsie (Feed Status) powinniśmy zobaczyć aktualne daty przy feedach (np. „2025-07-20” zamiast „0T” oznaczającego brak danych).

Warto wspomnieć, iż Community Feed jest w pełni darmowy i obejmuje większość istotnych podatności, choć jest trochę mniej „obszerny” niż komercyjny Greenbone Security Feed (ten płatny dostaje np. nieco szybciej testy na najnowsze luki, ale różnice nie są duże dla przeciętnego użytkownika). jeżeli jednak organizacja potrzebuje najlepszych możliwych aktualizacji, można wykupić licencję – wiąże się to z używaniem urządzenia Greenbone lub subskrypcją, co wykracza poza zakres tego artykułu.

Aktualizacje systemu GVM: Same komponenty GVM (gvmd, openvas, gsad itd.) nie aktualizują się automatycznie – należy je zaktualizować poprzez system pakietów lub ponowną kompilację, gdy wychodzi nowa wersja. Nowe wersje wprowadzają często ulepszenia bazy (trzeba robić migrację bazy poleceniem gvmd --migrate po aktualizacji) oraz poprawki błędów. Typowy cykl wydawniczy to dwie główne wersje na rok (np. 22.4, 22.10, 23.4 itd.). Użytkownik open-source może zdecydować, czy chce aktualizować od razu, czy pozostać na dłużej na stabilnej wersji. Warto śledzić komunikaty na forum Greenbone – jeżeli dana wersja osiąga EOL (koniec życia feedu), zalecana jest aktualizacja. Np. w połowie 2023 feed dla GVM 21.4 został zamknięty i trzeba było przejść na 22.4, inaczej skaner zaczął wyświetlać komunikat „Scan Engine Out of Life – migrate to new version”. Wtedy nie ma wyjścia – trzeba zaktualizować.

Monitorowanie logów i stanu usług: Administrator GVM powinien regularnie zaglądać do logów systemu, by wychwycić ewentualne problemy. Wspomniane logi w /var/log/gvm/ są pierwszym miejscem do sprawdzania przy kłopotach. Znaki ostrzegawcze to np. powtarzające się błędy w gvmd.log (błędy SQL, problemy z feedem) czy w openvas.log (błędy Redisa, błędy komunikacji ze skanerem). jeżeli skany zaczynają się kończyć od razu z zerowym wynikiem, zajrzenie do logów zwykle wyjaśnia przyczynę (np. brak NVT lub „failed to connect to scanner”). Greenbone zaleca sprawdzanie szczególnie logów ospd-openvas.log oraz gvmd.log w razie problemów – tam znajdziemy większość ostrzeżeń i błędów.

Ponadto, dobrze jest monitorować zużycie zasobów przez GVM. Proces gvmd i openvas mogą być pamięciożerne – narzędzia jak top pomogą stwierdzić, czy np. nie brakuje RAM (co objawia się intensywnym swapowaniem). Redis również może sygnalizować w logu, gdy zabraknie mu pamięci (wtedy ubija skrypty NVT – skany będą niepełne). Warto więc ustawić monitoring np. w Zabbiksie/Prometheusie na podstawowe metryki – CPU, RAM, dostępność portu 9392.

Ręczna konserwacja bazy: Przy długotrwałym używaniu GVM, baza PostgreSQL może puchnąć (gdy trzymamy tysiące raportów). Warto co jakiś czas usuwać stare raporty i zadania, których nie potrzebujemy, aby odciążyć bazę. GSA umożliwia zaznaczenie i usunięcie wybranych raportów. Alternatywnie można zrobić to komendą GMP (delete_report). Po większych czystkach lub aktualizacjach sensowne jest wykonanie gvmd -- vacuum (lub standardowych komend vacuumdb dla PostgreSQL), aby zredukować rozmiar DB.

Backup: Nie sposób nie wspomnieć – jeżeli używamy GVM produkcyjnie, wykonujmy kopie zapasowe bazy danych (gvmd) oraz kluczowych katalogów (np. CA w /var/lib/gvm/CA, pliki konfiguracyjne). W razie awarii można postawić nowy serwer i wgrać bazę, by odzyskać wszystkie wyniki skanów i ustawienia. Backup bazy PostgreSQL można robić pg_dumpem (przed wyłączeniem gvmd, bo inaczej będzie lock), lub prościej – zatrzymać usługi GVM na chwilę i skopiować pliki bazy.

Aktualizacja systemu a GVM: jeżeli aktualizujemy system operacyjny (np. dystrybucję), musimy pamiętać, iż GVM jest dość zależny od wersji bibliotek (zwłaszcza Postgresa). Często przy skoku dystrybucji trzeba wykonać migrację bazy Postgresa do nowej wersji (np. z 13 do 14) – jeżeli tego nie zrobimy, gvmd nie wystartuje (będzie oczekiwał konkretnej wersji, co potrafi sprawdzić gvm-check-setup i wyświetlić błąd). Dlatego duże upgrade’y planujmy ostrożnie i konsultujmy dokumentację migracji (np. migracja z GVM-21 do GVM-22 wymagała flushowania Redisa i zaktualizowania feed owner ID).

Podsumowanie utrzymania: W praktyce, codzienne utrzymanie GVM sprowadza się do: pilnowania aktualizacji feedu (najlepiej automatycznej), sprawdzania logów czy wszystko działa prawidłowo i dbania o zasoby (czy nie brakuje pamięci/dysku). Od czasu do czasu aktualizujemy też samo GVM do nowszej wersji, aby mieć wsparcie nowych funkcji i poprawek (i kompatybilny feed). W razie problemów, pierwszą pomocą jest dokumentacja (rozdział Troubleshooting w Community Docs) oraz forum Greenbone, gdzie wiele typowych błędów zostało omówionych przez społeczność. Przykładowo, jeżeli gwmd nie startuje po update – forum wskazuje by zajrzeć w log gdzie wprost napisze czemu (najczęściej kwestia migracji bazy albo nieaktualnego wpisu do scanner). Ważne jest także monitorowanie metryk feedu – jeżeli np. w GSA > Administration zobaczymy, iż NVT Feed Last Update ma datę sprzed kilku tygodni, to znak, iż coś jest nie tak z auto aktualizacją (może klucz API wygasł, może problem z DNS/Internetem). Aktualne daty (lub current) oznaczają, iż jesteśmy na bieżąco z definicjami zagrożeń.

Najczęstsze problemy i rozwiązania

Mimo dołożenia starań przy instalacji, w praktyce użytkownicy GVM często napotykają pewne typowe problemy konfiguracyjne. Poniżej lista najczęstszych bolączek wraz z potencjalnymi przyczynami i sposobami naprawy:

Problem 1: Brak wyników skanowania (raport pusty). Objawia się to tym, iż skan kończy się błyskawicznie i raport nie zawiera żadnych wykrytych podatności, choćby jeżeli spodziewaliśmy się znaleźć luki. Możliwe przyczyny:

• Brak skanowania portów (Nmap): GVM używa Nmap (lub jego skryptów NASL) do wykrycia otwartych portów i aktywnych hostów. jeżeli Nmap nie jest zainstalowany lub nie jest w PATH, skaner może nie sprawdzić żadnego portu i uznać host za nieosiągalny. Rozwiązanie: upewnij się, iż pakiet nmap jest zainstalowany i dostępny. Sprawdź też w ustawieniach skanu (Scan Config) czy w rodzinie „Port scanners” włączone są skrypty „Nmap (NASL wrapper)” i „Ping Host” – w profilach domyślnych są, ale w niestandardowym mogło zabraknąć.
• Test aktywności hosta (Alive Test) blokowany: Domyślnie GVM pinguje hosty przed skanem. jeżeli firewalle blokują ICMP Echo, skaner uzna host za wyłączony i pominie testy (raport będzie pusty z informacją „Host seems to be dead”). Rozwiązanie: przy definiowaniu targetu ustaw Alive Test: Consider Alive albo inny tryb (ARP dla sieci LAN). Alternatywnie w globalnych ustawieniach skanowania zmień wartość domyślną Alive Test. Można też ustawić w Scan Config parametr „Report about unrechable Hosts: yes”, by choć odnotował, iż host był nieosiągalny.
• SELinux lub inne zabezpieczenia systemowe: Na niektórych systemach (np. CentOS) SELinux może blokować działanie skanera (dostępy do socketów, raw socket potrzebny do SYN scan). Objawia się to przerwaniem skanu lub brakiem wyników. Rozwiązanie: jeżeli to środowisko testowe, wyłącz SELinux (setenforce 0) lub skonfiguruj odpowiednie wyjątki polityki. W Ubuntu AppArmor może podobnie bruździć – warto sprawdzić logi systemowe.
• Niekompletny feed lub brak uprawnień do skanowania: jeżeli np. użytkownik GVM nie ma przypisanego Scan Config (przy ręcznym dodaniu usera) albo feed GVMD_DATA nie został zaimportowany, skan może nie działać. Częsty błąd przy tworzeniu pierwszego zadania na nowym użytkowniku to komunikat „Failed to find config 'daba56c8-73ec-11df-a475-002264764cea’” – oznacza brak dostępu do domyślnego profilu Full and Fast (to ID właśnie tego profilu). Rozwiązanie: trzeba dać uprawnienia do używania profilów skanu temu użytkownikowi albo wykonać override ustawienia Feed Import Owner. Można to zrobić gwałtownie poleceniem: gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value admin (gdzie admin to nasz użytkownik) – to przypisze własność zaimportowanych obiektów feedu adminowi.
• Host w ogóle nie był skanowany: Zdarza się, iż w raporcie pewne hosty są pominięte bez wyjaśnienia. Powodem może być błąd podczas skanowania (zawieszenie) lub zbyt mały czas oczekiwania. Sprawdź logi gvmd/openvas – może tam być wskazówka (np. segmentation fault skanera). Czasem restart usługi openvas pomaga.
• Zbyt restrykcyjna lista portów: Każdy target używa tzw. Port List – definicji, które porty skanować. Domyślna to „All IANA assigned” (prawie wszystkie). jeżeli jednak ktoś ustawi port list ograniczoną (np. tylko 80,443), skan może ominąć podatności na niestandardowych portach. Upewnij się, iż port list jest sensowna lub użyj domyślnej.

Podsumowując, gdy raport jest pusty a nie powinien – sprawdź czy host był osiągalny (ping, firewall), czy nmap działa, czy profil skanu zawiera skanowanie portów i czy feed się załadował (patrz Administration > Feed Status). W razie wątpliwości odpal gvm-check-setup – jeżeli coś kluczowego jest nie tak, test pokaże (np. brak nmap, brak uprawnień).

Problem 2: Błąd Redis (nie można połączyć z Redis, permission denied). Ten błąd pojawia się zwykle w logu openvas (/var/log/gvm/ospd-openvas.log) lub w openvas.log. Typowa treść: “redis connection error to /run/redis-openvas/redis.sock: Permission denied. Failed to initialize nvti cache.”. Oznacza to, iż skaner nie może otworzyć socketu Redisa – w efekcie nie załaduje bazy NVT do pamięci i skanowanie się nie powiedzie. Przyczyny:

• Użytkownik GVM nie ma dostępu do socketu Redis. W systemie Debian/Ubuntu konfiguracja Redis dla OpenVAS tworzy socket /run/redis-openvas/redis.sock należący do użytkownika redis:redis z uprawnieniami 770. Aby GVM mógł z niego korzystać, użytkownik (np. _gvm) musi należeć do grupy redis. Sprawdź to komendą groups _gvm – jeżeli nie ma redis, dodaj: sudo usermod -aG redis _gvm i zrestartuj redis + openvas. Można też zmienić właściciela socketu na gvm: w pliku konfiguracyjnym Redis (np. /etc/redis/redis-openvas.conf) ustawić user gvm i group gvm dla socketu i dać 770.
• Redis nie działa lub zły socket. Upewnij się, iż usługa redis-server@openvas (lub podobna) jest uruchomiona. W PPA jest to zwykle usługa redis-openvas. Sprawdź też czy ścieżka socketu pokrywa się z tą w pliku /etc/openvas/openvas.conf (parametr db_address). Log gvm-check-setup pokazuje m.in. czy Redis jest OK i czy socket ma adekwatne uprawnienia – szukaj linii “OK: redis-server is running and listening on socket: …”.
• Start openvas przed Redisem. jeżeli ospd-openvas startuje zanim Redis zdąży utworzyć socket przy boocie, może nastąpić fail. Rozwiązanie: dodać w definicji unit systemd openvas zależność na redis (After=redis.service).
• Inny proces korzysta z Redis sock. Raczej rzadkie, ale jak mamy dwa skanery na jednej maszynie, mogłyby kolidować – upewnij się, iż tylko jedna instancja openvas używa tego samego socketu.

Rozwiązanie zwykle sprowadza się do: dodania usera gvm do grupy redis i restartu. Po tym w logach openvas nie powinno być już błędów “permission denied”. W razie dalszych problemów, można spróbować czy użytkownik gvm manualnie ma dostęp: sudo -u gvm redis-cli -s /run/redis-openvas/redis.sock ping – powinien zwrócić PONG, jeżeli jest OK.

Problem 3: Niedostępny GSAD (interfejs WWW niedziała zdalnie). Sytuacja: mamy uruchomiony gsad, ale nie możemy się połączyć z web UI z innej maszyny, albo przeglądarka zgłasza błąd połączenia. Najczęstsza przyczyna to fakt, iż gsad działa tylko na 127.0.0.1 (localhost). Widać to choćby w output ss -ltn – gsad nasłuchuje na 127.0.0.1:9392. W takiej konfiguracji próby wejścia na http://<IP-serwera>:9392 spoza serwera będą odrzucane. Rozwiązania są dwa:

• Zezwolić gsad na nasłuch na interfejsie zewnętrznym: Można to zrobić edytując plik konfiguracyjny. W systemach Debian/Ubuntu jest to zwykle /etc/default/gsad lub plik unit systemd. W starych wersjach edytowało się /etc/gvm/gsad.conf albo uruchamiało gsad z parametrem. W PPA 22.04 zaleca się edycję pliku default – dodajemy tam np. GSA_ADDRESS=0.0.0.0 albo DAEMON_OPTS="--listen=0.0.0.0 --port=9392". Po zmianie restartujemy gsad. Alternatywnie, można zmodyfikować plik unit systemd: /lib/systemd/system/gsad.service dodając w ExecStart parametr -a 0.0.0.0 (co odpowiada listen all interfaces). Po takiej zmianie UI będzie dostępne po IP serwera. Uwaga: od tego momentu interfejs będzie wystawiony w sieci – KONIECZNIE należy skonfigurować TLS lub ograniczyć dostęp np. firewallem tylko dla uprawnionych osób, bo inaczej hasła i dane lecą czystym tekstem.
• Użycie reverse proxy lub tunelu: Bardziej bezpieczna metoda to zostawić gsad na localhost i postawić np. serwer Nginx, który będzie proxy na zewnątrz z SSL. Scott, którego blog cytowaliśmy, zaleca właśnie użycie Nginx jako reverse proxy zamiast grzebania w gsad – bo jednym ruchem rozwiązuje brak SSL i listening na localhost. W praktyce: instalujemy Nginx, generujemy cert (np. Let’s Encrypt), konfigurujemy vhost: listen 443, proxy_pass http://127.0.0.1:9392, do tego podstawowa autoryzacja albo ograniczenie IP. Wtedy użytkownicy łączą się po https do Nginx, a on przekazuje ruch do gsad lokalnie.
• Certyfikat i błąd TLS: Inną odmianą problemu gsad jest, gdy próbujemy włączyć go w trybie HTTPS (port 9390 z domyślnym certem) i dostajemy błąd – często w logu gsad: „Could not load private SSL key … Permission denied”. To wynika z praw do plików w /var/lib/gvm/CA/. Rozwiązanie: upewnić się, iż klucz serverkey.pem jest czytelny dla użytkownika gvm (czasem trzeba zmienić właściciela na gvm:gvm). Ewentualnie skorzystać z narzędzia gvm-manage-certs do ponownego wygenerowania certów – choć w wątku na forum sugerowano, iż w nowszych wersjach to polecenie bywa problematyczne i ręczna zmiana uprawnień jest prostsza.
• GSAD nie uruchamia się wcale: Sprawdź systemctl status gsad – jeżeli jest błąd, zobacz log: journalctl -u gsad. Czasem brak jakiejś biblioteki (np. lib microhttpd). W PPA raczej to nie występuje, ale przy kompilacji samodzielnej – trzeba doinstalować brakujące dependency.

Po rozwiązaniu kwestii dostępu do GSAD, strona logowania powinna wyświetlić się po wejściu na odpowiedni URL. jeżeli używamy proxy, to np. https://scanner.moja-domena.local/ pokaże Greenbone Security Assistant. Pamiętajmy zmienić hasło admina i najlepiej włączyć logowanie tylko po HTTPS dla bezpieczeństwa.

Problem 4: Skany przerywane, wydajność słaba. Bywa, iż skan zawsze zatrzymuje się na jakimś etapie (np. 1%, 40%) i trwa bardzo długo lub zawiesza. Najczęściej to kwestia wydajnościowa – np. za mało RAM i system zaczyna intensywnie swapować, praktycznie zamrażając skan. Albo CPU 100% i nie wyrabia z obsługą tysięcy wątków testów. Rozwiązanie: obserwuj htop podczas skanu – jeżeli pamięć zajęta w 99%, rozważ dodanie RAM lub zmniejszenie równoległości skanu (w configu OpenVAS można ustawić max threads, ale to zaawansowane). Sprawdź też, czy nie skanujesz zbyt dużego zakresu jednym zadaniem – lepiej podzielić np. /16 na mniejsze kawałki po /24. jeżeli problem występuje zawsze przy określonym teście (np. wiszenie na skanowaniu Oracle DB), można wykluczyć dany test z configu (klient GMP: <modify_config> z exclude rodziną testów).

Problem 5: Błędy integracji z bazą (gvmd). jeżeli usługa gvmd nie startuje po aktualizacji i w logu gvmd.log widzimy np. błędy migracji bazy – np. „database is missing some migrations” – trzeba wykonać migrację: gvmd --migrate. Innym razem może być komunikat „role postgres does not exist” – to oznacza, iż skrypt bazy nie utworzył użytkownika (sprawdź /etc/default/gvmd-pg). Rozwiązaniem może być usunięcie bazy i ponowna instalacja. Jeszcze inny błąd: „md manage:WARNING: … failed to connect to /run/ospd/ospd.sock” – oznacza, iż gvmd nie może dogadać się ze skanerem (ospd). Może to być spowodowane padnięciem usługi ospd-openvas (sprawdź systemctl status ospd-openvas). W logach ospd widać np. error MQTT (patrz Problem 2) – jeżeli broker nie działa, skaner nie wystartuje, a wtedy gvmd co 10s próbuje się łączyć i ostrzega w logu. Naprawa broker/redis rozwiąże i to.

Każdy system bywa kapryśny – kluczem jest czytanie logów. GVM stara się dość czytelnie logować problemy. W razie wątpliwości, warto przejrzeć oficjalne FAQ i forum Greenbone. Wątek „Najczęstsze błędy” tamże pokazuje, iż większość problemów to właśnie te omówione: brak dostępu do Redis, brak nmap, config feed owner, certyfikat gsad. Dobrą wiadomością jest, iż gdy już przejdziemy przez okres „niemowlęcy” instalacji i konfiguracji, GVM działa stabilnie. A gdy pojawi się nowy problem – np. wygasanie feedu – społeczność gwałtownie podpowiada rozwiązanie (jak migracje do nowszej wersji).

Przykłady zastosowań GVM w organizacjach

Aby lepiej zobrazować możliwości GVM, przyjrzyjmy się jak może on być wykorzystany w różnych środowiskach i scenariuszach:

DevSecOps i ciągła integracja (CI/CD): W nowoczesnych procesach wytwarzania systemu bezpieczeństwo jest włączane już na etapie budowania i testowania aplikacji. GVM można zintegrować z pipeline CI/CD, by automatycznie skanować nowe wersje aplikacji lub środowiska testowe. Na przykład, zespół devops może przygotować etap w Jenkinsie, który po wdrożeniu aplikacji na serwer testowy wywoła skrypt korzystający z API GVM do przeskanowania tego serwera. jeżeli pipeline wykryje w raporcie GVM podatność krytyczną, może oznaczyć build jako nieudany – tym samym zapobiegając wdrożeniu aplikacji z poważną luką (tzw. security gate). Deweloperzy dostają natychmiastową informację zwrotną o problemie bezpieczeństwa, co umożliwia szybką poprawę (shift-left security). Oczywiście takie wdrożenie wymaga pewnej infrastruktury: np. uruchomienia kontenera z GVM skanującego tymczasowe środowisko lub posiadania stale działającego skanera, do którego pipeline będzie się łączył. Są firmy, które do skanowania aplikacji web w CI używają OWASP ZAP, a do skanowania infrastruktury – właśnie OpenVAS/GVM. Zaletą GVM jest to, iż może on skanować szeroki zakres technologii (nie tylko aplikacje web, ale też bazy, usługi, konfiguracje systemów) w sposób zautomatyzowany. Dzięki integracji z narzędziami takimi jak Docker, można np. uruchamiać GVM w kontenerach dedykowanych do testów (Greenbone udostępnia oficjalne obrazy Community Edition). Podsumowując – w środowisku DevSecOps GVM pełni rolę „strażnika” infrastruktury testowej, zapewniając iż nowe komponenty nie wprowadzają znanych dziur.

Skanowanie środowisk chmurowych (AWS, Azure, itp.): Coraz więcej firm hostuje swoje systemy w chmurach publicznych. GVM można wykorzystać do okresowego skanowania instancji chmurowych (np. EC2 w AWS). Można to zrobić na dwa sposoby: albo uruchomić serwer GVM wewnątrz chmury (np. jako maszyna EC2 w tej samej sieci co skanowane hosty), albo skanować zewnętrznie przez internet (jeśli nasza maszyna GVM stoi on-premise). Pierwsza opcja jest zwykle lepsza ze względów wydajności i bezpieczeństwa – stawiamy maszynę (lub kontener ECS/Kubernetes) z GVM w VPC i dajemy jej uprawnienia do skanowania wewnątrz tej chmury. Np. firma może mieć GVM w regionie AWS, który co noc skanuje wszystkie instancje w ramach danego VPC. Rezultaty mogą być wysyłane do centralnego SOC. Dzięki temu wykrywamy np. iż ktoś uruchomił nową maszynę z nieaktualnym Ubuntu i jest tam OpenSSH podatny na wyciek kluczy – zanim zrobi to atakujący. W środowiskach multi-cloud, GVM można wdrożyć w każdej chmurze, lub skanować z jednej lokacji przy założeniu, iż adresy IP są osiągalne. Trzeba tylko uważać na koszty ewentualnego ruchu wychodzącego i ograniczenia chmury (niektóre chmury mogą interpretować intensywny skan portów jako działanie niepożądane – warto sprawdzić politykę dostawcy). W przypadku AWS, dobrze jest wykorzystać mechanizmy tagowania – np. tagować instancje, które mają być skanowane, a GVM zintegrować z AWS API by dynamicznie pobierał listę adresów do skanowania. Choć GVM nie ma natywnej wtyczki do AWS, można to osiągnąć skryptowo (AWS CLI + GMP API). Taka automatyzacja zapewnia, iż zawsze skanujemy aktualny stan środowiska, choćby gdy instancje dynamicznie przybywają/ubywają.

Wykorzystanie w SOC (Security Operations Center): W dużych organizacjach GVM może być elementem ekosystemu SOC jako tańsza alternatywa dla komercyjnych skanerów. Przykładowo, SOC może zainstalować GVM do skanowania sieci wewnętrznych, podczas gdy drogie narzędzie zostawia do zewnętrznych audytów. W modelu tygodniowym, analitycy SOC mogą zaplanować skanowanie różnych segmentów sieci w cyklu rotacyjnym – np. poniedziałki: skan sieci serwerów baz danych, wtorki: skan stacji roboczych działu X, itd. Wyniki są zbierane i analizowane pod kątem zmian – czy pojawiły się nowe luki, czy ktoś zainstalował nieautoryzowany serwer, itp. GVM dostarcza mechanizm delta report (porównania raportów), który może być przydatny. SOC może też wykorzystywać GVM do walidacji alertów z SIEM: np. SIEM zgłasza ruch wskazujący na exploit SMB – analityk może od razu przeskanować tę maszynę GVM-em pod kątem MS17-010 (EternalBlue) by potwierdzić, czy jest podatna. Takie proaktywne podejście zwiększa skuteczność reagowania (Threat Hunting). Innym zastosowaniem w SOC jest integracja GVM z platformą TheHive (system zarządzania incydentami). Można skonfigurować alerty GVM tak, by każda krytyczna podatność tworzyła automatycznie case w TheHive – co zostanie przydzielone do analityka do zbadania. Narzędzia typu TheHive mają API, więc integracja może polegać np. na skrypcie wywoływanym z alert GVM (Alert typu Run a program), który używając API TheHive zakłada sprawę z załączonym raportem. Dzięki temu proces zarządzania podatnościami staje się częścią obsługi incydentów.

Integracja z narzędziami bezpieczeństwa (SIEM, WAF, EDR): GVM może współdziałać z innymi systemami, dostarczając im kontekst podatności. Przykładowo, integracja z Wazuh (SIEM) – jak wcześniej wspomniano – umożliwia budowę scentralizowanego kokpitu bezpieczeństwa. W jednym miejscu widzimy logi zdarzeń i informacje o tym, czy dane hosty są podatne. Wazuh może automatycznie generować alarm wyższej rangi, jeżeli wykryje exploit w logach i host jest podatny według GVM. Podobnie EDR (Endpoint Detection & Response) może skorzystać – niektóre EDR-y pozwalają importować listę luk i priorytetyzować alerty na tej podstawie. Wreszcie, systemy ticketingowe: integracja GVM z Jira lub ServiceNow – tu raczej nie ma gotowych pluginów, ale przez API możliwe. Wyobraźmy sobie skrypt: pobiera z GVM listę wszystkich otwartych podatności krytycznych i sprawdza, czy istnieje w Jira odpowiadający ticket; jeżeli nie – tworzy go automatycznie z opisem i przypisaniem do właściciela systemu. Taki skrypt można np. odpalać co tydzień. To znacząco usprawnia workflow – podatność nie „zginie” w raporcie, tylko trafi do workflow naprawczego.

Studium przypadku – cotygodniowy skan infrastruktury: Załóżmy firmę średniej wielkości z infrastrukturą ~200 hostów (serwery, VM, urządzenia sieciowe). Wdrażają GVM na jednej maszynie wirtualnej (8 vCPU, 16GB RAM). Poniedziałek: skan sieci serwerowej (profile Full&Fast), wtorek: skan stacji roboczych (profil lżejszy, by nie wywoływać alarmów AV, np. Discovery lub ograniczony do pewnych portów), środa: skan urządzeń sieciowych (routery, switche – często SNMP i sprawdzanie wersji firmware), czwartek: skan aplikacji web (profil skoncentrowany na port 80/443 i testy OWASP). Każde zadanie jest zaplanowane w GVM jako cykliczne (Schedule weekly). Raporty są automatycznie wysyłane mailem do zespołu bezpieczeństwa (Alert w GVM typu E-Mail). W piątki analityk przegląda raporty, porównuje z poprzednimi tygodniami, wyłuskuje nowo odkryte luki i tworzy zgłoszenia dla administratorów. Dzięki takiemu cyklowi, organizacja posiada ciągły ogląd swojego poziomu podatności i może gwałtownie reagować na pojawiające się problemy (np. nowy serwer deweloperski postawiony bez twardych polityk, który GVM wykrywa i zgłasza). Taki model, choć oparty na darmowym narzędziu, znacznie poprawia cyberhigienę firmy. Ważne jest jedynie, by dedykować czas na obsługę wyników i ich weryfikację – samo skanowanie nie zwiększa bezpieczeństwa, dopiero działanie na podstawie skanów to robi.

Podsumowując, GVM znalazł zastosowanie zarówno w małych firmach (gdzie skanuje kilka serwerów raz na jakiś czas), jak i w poważnych operacjach bezpieczeństwa jako element ekosystemu (otwartość i brak licencji sprzyja pomysłowym wdrożeniom na dużą skalę). W dobie rosnącej świadomości bezpieczeństwa, choćby firmy dysponujące drogimi narzędziami trzymają GVM jako drugą opinię – np. wykonują skan GVM-em obok skanu Nessusem i porównują, czy coś nie zostało pominięte (czasem się uzupełniają). GVM bywa też używany w celach audytowych przez firmy konsultingowe – ponieważ jest darmowy, mogą one odpalić go u klienta bez żmudnych ustaleń licencyjnych, przeprowadzić jednorazowy skan sieci klienta i przekazać wyniki (przy poszanowaniu kwestii prawnych, oczywiście).

Na koniec tego rozdziału warto zauważyć, iż GVM jako narzędzie open-source doskonale wpisuje się w trend budowania open-source’owych ekosystemów bezpieczeństwa (obok takich projektów jak Wazuh, TheHive, MISP, SecurityOnion). Integracja tych elementów pozwala, przy niskim budżecie, zbudować całkiem zaawansowany system ochrony organizacji.

Alternatywy dla GVM – porównanie

Na rynku istnieje wiele skanerów podatności – zarówno komercyjnych, jak i open-source. Warto wiedzieć, jak GVM (OpenVAS) wypada na tle najpopularniejszych alternatyw i w jakich scenariuszach to właśnie GVM będzie najlepszym wyborem. Poniżej porównamy GVM z kilkoma innymi rozwiązaniami:

RozwiązanieLicencja i kosztZaletyOgraniczenia

GVM (Greenbone/OpenVAS)	Open-source (GPL), darmowy.	– Brak opłat licencyjnych (dowolne użycie, również komercyjne). – Regularne aktualizacje darmowego feedu podatności (codzienne sync). – Bogate możliwości integracji (API GMP, skrypty) – łatwe włączenie w procesy CI/CD, SIEM. – Elastyczność: możliwość dostosowania skanów, własne skrypty NASL, skalowanie poziome (sensory). – Społeczność wsparcia (forum) i przejrzystość działania (wgląd w kod).	– Instalacja i konfiguracja bardziej złożona (wymaga odpowiedniego środowiska Linux, db) w porównaniu do narzędzi „out-of-the-box”. – Wymagające zasobów: potrzebuje ≥4 GB RAM i mocnego CPU dla sprawnego działania. – Nieco mniejszy zasięg wykrywanych podatności vs liderzy rynkowi – szacunkowo ~10% mniej pokrytych CVE niż Nessus (np. ~4.6% mniej krytycznych CVE). – Brak oficjalnego supportu SLA – wsparcie tylko poprzez community (chyba iż wykupi się wersję Enterprise).
Nessus Essentials	Własnościowy (Tenable), darmowy dla użytku niekomercyjnego (limit 16 IP).	– Bardzo dopracowany skaner z intuicyjnym interfejsem – szybki start bez skomplikowanej konfiguracji. – Wysoka skuteczność i pokrycie podatności: Nessus ma nieco większą bazę testów – pokrywa około 41.8% CVE vs 37.4% przez OpenVAS (co przekłada się na ~5000 więcej sprawdzanych CVE ogółem). Szczególnie wyróżnia się pokrycie krytycznych luk (Nessus sprawdza ~258 więcej krytycznych CVE niż GVM). – Niższy odsetek false-positive dzięki dopracowanym skryptom i weryfikacjom (wg niezależnych testów). – Profesjonalne wsparcie producenta (dla wersji płatnych) i regularne aktualizacje (co prawda feed jest automatyczny). – Ekosystem Tenable – integracja z platformą Tenable.sc, skanery agentowe itp.	– Darmowa edycja Essentials ma ograniczenie do 16 hostów i licencję wykluczającą użycie komercyjne(dobra tylko do użytku domowego, labów). – Pełna wersja (Nessus Professional) jest płatna – koszt to ok. kilka tys. USD rocznie za licencję. – Zamknięty kod – brak możliwości własnych modyfikacji testów (chociaż możliwe jest tworzenie skryptów NASL, to cały silnik jest czarną skrzynką). – Nessus koncentruje się głównie na skanowaniu – brak wbudowanego zarządzania podatnościami (raportowanie jest, ale np. brak w nim workflow użytkowników, ról – to oferuje droższy Tenable.io/Tenable.sc).
Rapid7 Nexpose / InsightVM (Community)	Własnościowy (Rapid7), dostępna wersja Community za darmo (limit 32 hosty). Pełna wersja InsightVM – płatna subskrypcja.	– Łatwe wdrożenie: gotowe instalatory i appliance, gwałtownie skanuje po wyjęciu z pudełka (domyślne polityki). – Dobrze integruje się z innymi produktami Rapid7 – np. z Metasploit (eksport podatności do automatycznego testu exploitów) czy z SIEM Rapid7. Jest to część platformy Insight, co zapewnia szeroki ekosystem (agenty na hostach, skan kontenerów itp.). – Bogate funkcje raportowania i zarządzania: InsightVM (następca Nexpose) ma rozbudowane dashboardy, możliwość śledzenia trendów, integrację z JIRA, bardzo użyteczny risk scoring uwzględniający kontekst (np. czy exploit istnieje). – Wersja Community pozwala poznać narzędzie za darmo (choć limit 32 IP to tylko małe testy).	– Limit 32 hostów w Community Edition czyni darmową wersję jedynie pokazową – do poważniejszego skanowania wymaga zakupienia licencji. – Koszt InsightVM jest wysoki (model subskrypcyjny od liczby zasobów) – dla budżetowych zastosowań może być nieosiągalny. – Dość duże wymagania sprzętowe – w testach Nexpose bywa cięższy niż Nessus i OpenVAS (appliance Rapid7 zaleca 8+ GB RAM, SSD). – Zamknięty ekosystem: brak możliwości modyfikacji własnych skanów poza tym, co udostępni Rapid7 (choć API jest dostępne w wersji komercyjnej). – Wersja on-prem (Nexpose) nie jest już rozwijana na równi z InsightVM (cloud), przez co użytkownicy community mogą mieć ograniczone funkcje w porównaniu z chmurową ofertą.

Kiedy wybrać GVM? GVM wygrywa przede wszystkim tam, gdzie koszty są kluczowe – dla małych firm, start-upów, organizacji non-profit czy entuzjastów, którzy nie mogą sobie pozwolić na płatne skanery. Sprawdza się także, gdy cenimy otwartość i elastyczność – np. chcemy zintegrować skaner ściśle z niestandardowym procesem albo potrzebujemy dodać własne testy (NASL jest udokumentowany i można pisać swoje skrypty). GVM będzie dobrym wyborem również w środowiskach edukacyjnych i testowych – studenci bezpieczeństwa uczą się na nim budowy skanera, mogą obserwować jak działają poszczególne testy, co jest niemożliwe w komercyjnych narzędziach.

Kiedy lepiej wybrać alternatywę? jeżeli jesteśmy dużą korporacją, która potrzebuje dedykowanego wsparcia, gwarancji aktualizacji, certyfikacji (niektóre standardy wymagają użycia określonych narzędzi) – Nessus czy Qualys mogą być bardziej odpowiednie. GVM, mimo iż skuteczny, może nie mieć tak dopracowanych raportów czy niskiego odsetka false positives jak produkty za miliony dolarów – w środowisku gdzie liczy się każda minuta analityka, narzędzie komercyjne może przyspieszyć workflow (np. wbudowany mechanizm bazy assetów, integracja z CMDB itd.). Nessus jest często chwalony za użyteczność – w kilkanaście minut można go zainstalować na Windowsie i przeskanować całą podsieć, bez znajomości Linuxa. Dlatego organizacje bez wyspecjalizowanego personelu *nix również mogą woleć Nessusa lub podobny skaner.

Trzeba też rozważyć skalę: o ile mamy tysiące hostów do regularnego skanowania i potrzebujemy rozproszonych skanerów z centralną konsolą, to komercyjne rozwiązania oferują gotowe architektury Master/Scanner i optymalizację synchronizacji. Wprawdzie GVM też daje radę – można postawić kilka instancji i nimi zarządzać osobno lub próbować trybu federacyjnego – ale wymaga to więcej zachodu. Rapid7 InsightVM czy Tenable.io natomiast zostały zaprojektowane do skalowania (wiele skanerów raportujących do chmury).

Pod kątem wykrywalności: Według cytowanych analiz, Nessus ma przewagę nad OpenVAS w liczbie sprawdzanych unikalnych CVE o kilka tysięcy. W praktyce może to oznaczać, iż Nessus znajdzie np. pewne niszowe podatności, których GVM nie wychwyci. Z drugiej strony, GVM ma pewne testy unikalne (np. niektóre lokalne testy linuksowe Notus, które Nessus może pomijać). W ogólnym rozrachunku oba wykrywają większość powszechnych luk. Różnice objawiają się głównie przy egzotycznych systemach lub najnowszych CVE (Tenable często reaguje bardzo gwałtownie na krytyczne CVE wydając plugin, Greenbone czasem z kilkudniowym opóźnieniem). jeżeli więc firma potrzebuje najwyższego możliwego poziomu wykrywania i minimalnego opóźnienia – zainwestuje w komercyjne feedy i narzędzia.

Powyższa tabela i omówienie skupiają się na Nessus i Nexpose jako iż zostały wymienione. Warto wspomnieć, iż innymi alternatywami są np. QualysGuard (skaner chmurowy – zaleta: nic nie instalujemy, minus: cena, dane w chmurze), darmowy Nmap + NSE (nieco inna kategoria, bo to bardziej skryptowe skanowanie, bez bazy CVE), czy też specjalistyczne skanery jak OpenSCAP (sprawdza zgodność konfiguracyjną, uzupełniający wobec GVM). Jednak GVM jako jedyny pełny open-source do skanowania podatności nie ma bezpośredniego odpowiednika o takiej kompletności. Jedynie stary projekt NessusWX (dawny Tenable) i jego odnogi, ale one już dawno wygasły.

Podsumowanie porównania: GVM oferuje 90% funkcjonalności komercyjnych skanerów za 0% ich ceny, kosztem większego nakładu własnego i nieco mniejszej ergonomii. Dla wielu zastosowań to wymiana bardzo opłacalna. Nessus i inne płatne narzędzia wciąż prowadzą pod względem wygody i pewnych aspektów technicznych (szczególnie supportu i pewności działania). Wybór zależy więc od potrzeb i zasobów organizacji. Nic nie stoi na przeszkodzie, by korzystać hybrydowo: np. używać GVM do częstych wewnętrznych skanów, a raz na kwartał wynająć audyt z użyciem innego skanera dla pewności – jeżeli coś nowego wyjdzie, można wtedy dodać odpowiedni test do GVM.

Na zakończenie tej sekcji należy podkreślić: niezależnie od wyboru narzędzia, skaner podatności jest tak dobry, jak proces, który wokół niego zbudujemy. choćby najlepszy Nessus zda się na nic, jeżeli nikt nie analizuje raportów i nie wdraża poprawek. W tym kontekście GVM może być równie efektywnym elementem strategii bezpieczeństwa, o ile jest odpowiednio wykorzystywany.

Podsumowanie

Greenbone Vulnerability Management (GVM) to kompletny, darmowy skaner podatności, który z powodzeniem może konkurować z komercyjnymi produktami. Jego open-source’owy rodowód oznacza brak kosztów licencyjnych, dużą elastyczność i przejrzystość działania. GVM wywodzący się z projektu OpenVAS rozwinął się w pełnoprawną platformę zarządzania podatnościami – od skanowania, przez raportowanie, po integrację z innymi narzędziami bezpieczeństwa.

Do najważniejszych zalet GVM należą:

• Bezpłatność i dostępność: można go wdrożyć w dowolnym środowisku bez ograniczeń, co czyni bezpieczeństwo bardziej demokratycznym (ważne dla organizacji z małym budżetem).
• Aktualna baza zagrożeń: codziennie uaktualniany Community Feed gwarantuje, iż skaner jest na bieżąco z nowymi podatnościami. Ponad 50 tysięcy testów pokrywa szerokie spektrum CVE, CVE, konfiguracji – dając zaufanie, iż większość luk zostanie wykryta.
• Wszechstronność zastosowań: GVM sprawdza się w różnych rolach – od jednorazowych audytów, przez ciągły monitoring bezpieczeństwa w firmie, aż po integrację w pipeline DevOps. Może skanować sieci firmowe, chmurowe, urządzenia IoT, a wyniki mogą zasilać proces zarządzania ryzykiem i incydentami.
• Bogate funkcje zarządzania: wbudowany interfejs GSA ułatwia organizację pracy – wielu użytkowników, podział na zadania, harmonogramy, alerty. Raporty z GVM są szczegółowe i dostarczają nie tylko listę luk, ale też kontekst i wskazówki do ich usunięcia.
• Automatyzacja i integracja: API GMP i narzędzia gvm-tools otwierają ogromne możliwości automatyzacji – od autopilotów skanów po zaawansowane integracje z SIEM/SOAR. Dzięki temu GVM może stać się częścią większego ekosystemu obronnego, a nie działać w oderwaniu.
• Społeczność i transparentność: dostęp do kodu źródłowego oraz aktywne forum użytkowników oznaczają, iż błędy są znajdowane i łatane stosunkowo szybko. Użytkownicy dzielą się skryptami instalacyjnymi, poradami – co zmniejsza barierę wejścia.

Oczywiście, GVM to nie cudowny lek – posiada też pewne wyzwania:

• Trudność początkowej konfiguracji i wyższe wymagania administracyjne – potrzebna jest wiedza z zakresu Linux, baz danych, czasem debugowania, by w pełni wykorzystać potencjał GVM. Dla osób nietechnicznych proces instalacji bywa przeszkodą (choć rozwiązują to np. gotowe maszyny wirtualne demo lub kontenery).
• Większe zapotrzebowanie na zasoby sprzętowe – żeby dorównać wydajności komercyjnych rozwiązań, GVM musi działać na solidnym serwerze. Uruchomienie go na słabym VPS może skutkować powolnym działaniem lub zawieszaniem skanów.
• Nieco mniejsze pokrycie i niekiedy wolniejsze wsparcie dla najświeższych CVE – choć różnice tu zacierają się (Greenbone intensywnie rozwija feed). W krytycznych sytuacjach (np. log4shell) patche do feedu pojawiają się szybko, ale w przypadku mało znanych podatności można poczekać dłużej niż u konkurencji.
• Brak formalnego wsparcia technicznego – chyba iż przejdziemy na ofertę komercyjną Greenbone. W środowiskach korporacyjnych, gdzie wymagane jest SLA, może to być argument przeciw GVM (choć nic nie stoi na przeszkodzie wykupić np. support u firm trzecich specjalizujących się w OpenVAS).
• Konieczność zbudowania procesu dookoła – GVM, jak i inne skanery, nie naprawia podatności, a jedynie je wykrywa. Dlatego jego sukces zależy od tego, czy organizacja ma gotowość na obsłużenie tych danych (czyli zainwestuje czas w analizę raportów i dystrybucję zadań naprawczych).

Dla kogo GVM będzie najlepszym wyborem? Na pewno dla ekip bezpieczeństwa i administratorów, którzy mają ograniczone fundusze, ale duże potrzeby skanowania. Również dla integratorów i pentesterów, którzy cenią możliwość dostosowania narzędzia do własnych metodologii (np. dołączenia skanera do własnego frameworku testów). Świetnie pasuje do środowisk akademickich i laboratoriów edukacyjnych (darmowe narzędzie do nauki). W małych i średnich firmach GVM może być głównym narzędziem skanowania i dostarczyć znaczną poprawę bezpieczeństwa bez naruszania budżetu. W dużych organizacjach GVM może pełnić rolę uzupełniającą (druga opinia) lub jako system do skanowania wewnętrznego, gdzie drogie skanery są wykorzystywane tylko do zewnętrznych testów i compliance.

Kończąc przewodnik, warto podkreślić, iż Greenbone Vulnerability Management rozwija się dynamicznie. Regularne wydania przynoszą ulepszenia wydajności, nowe typy testów (np. Notus wprowadzony niedawno zwiększył szybkość lokalnych sprawdzeń) oraz ulepszenia interfejsu. Społeczność stale dostarcza nowych pomysłów i zgłasza błędy – co czyni narzędzie coraz dojrzalszym. Już teraz GVM w wersji 22.4/22.10 jest dużo bardziej przyjazny i stabilny niż dawniejsze OpenVAS 8 czy 9. o ile więc ktoś miał w przeszłości mieszane doświadczenia z OpenVAS (np. problemy z konfiguracją, długie czasy skanowania), warto dać GVM kolejną szansę – projekt ten ewoluował i z pewnością pozostanie ważnym punktem na mapie narzędzi bezpieczeństwa IT.

Czy warto wdrożyć GVM? jeżeli Twoja organizacja potrzebuje rozwiązania do okresowych skanów podatności, a priorytetem jest niski koszt i kontrola nad danymi – odpowiedź brzmi: tak. GVM dostarcza zaawansowane możliwości porównywalne z wiodącymi skanerami, wymagając w zamian jedynie zaangażowania w jego utrzymanie. Dla wielu firm i zespołów bezpieczeństwa ta wymiana jest bardzo korzystna. Poprzez użycie GVM dołączamy też do społeczności open-source dbającej o bezpieczeństwo – wspólnymi siłami czyniącej internet bezpieczniejszym miejscem.

Na zakończenie – niezależnie od narzędzia, pamiętajmy iż bezpieczeństwo to proces. GVM jest potężnym narzędziem w tym procesie, ale to od naszych działań zależy, czy przełoży się na realną ochronę. Wybierając GVM, inwestujemy w wiedzę i budowę kompetencji wewnątrz organizacji, co w dłuższej perspektywie może być cenniejsze niż kupno czarnej skrzynki od dostawcy. GVM daje nam wiedzę – a w bezpieczeństwie wiedza o własnych podatnościach to fundament do dalszych kroków.

Wskazówka: Zawsze upewniaj się, iż korzystasz z aktualnych źródeł informacji – projekt GVM jest aktywny i pewne szczegóły (np. komendy) zmieniały się na przestrzeni wersji. Ten przewodnik opiera się na stanie wiedzy na rok 2024/2025 (GVM w wersjach 21.4, 22.4, 22.10). W przyszłych wydaniach mogą pojawić się nowe funkcje bądź ulec zmianie nazwy komponentów. Dlatego warto śledzić wspomniane wyżej kanały (dokumentacja, forum) aby być na bieżąco.

TEN ARTYKUŁ JEST AKLTUALNY NA DZIEŃ 22.07.2025

Pozostaje życzyć powodzenia w korzystaniu z GVM! Mamy nadzieję, iż ten kompletny przewodnik ułatwił Ci zrozumienie i wdrożenie tego darmowego skanera podatności. Dzięki niemu zyskasz lepszy wgląd w bezpieczeństwo swojej infrastruktury i wykonasz kolejny krok ku bardziej odpornej sieci. Pamiętaj – najważniejsze to działać na podstawie uzyskanych informacji. Powodzenia w polowaniu na podatności!

Bibliografia