Pierwszy serwer: jedna komenda i wynik w panelu

Seria „Od pierwszego serwera do raportu”, odcinek 2 z 9

Masz chwilę między zgłoszeniami i chcesz sprawdzić jeden serwer. Otwierasz panel, kopiujesz polecenie, uruchamiasz skrypt. Po zakończeniu widzisz maszynę i jej podatności. Można wrócić do innych zadań. Tylko czy następny wynik pojawi się sam?

Ten odcinek kończy się później niż na pierwszym wpisie w panelu. Najpierw pobranie i uruchomienie, potem ocena kompletności wyniku, a na końcu osobna decyzja o harmonogramie. W tytule jest jedna komenda uruchomienia. Sam panel rozdziela pobranie pliku od jego wykonania i tę kolejność zachowuję.

Z mojego doświadczenia ręczne pobranie i uruchomienie to mniej niż minuta aktywnej pracy. Usługa i timer z gotowca zajmują kolejną. Spokojnie mieszczę przygotowanie w dwóch minutach, do pięciu, jeśli chcę przeczytać, co się dzieje. To opis mojej pracy, nie benchmark ani obietnica czasu skanu. Pobieranie bazy, zawartość dysku i obciążenie serwera mogą wydłużyć oczekiwanie na wynik.

Wymagania i uprawnienia

Na początek wybierz jeden serwer Linux o znanej roli. Potrzebujesz Bash, curl i jq; do polecenia pobierania pokazanego w panelu także wget. Agent sprawdza obecność curl i jq, a gdy ich brakuje, kończy pracę z komunikatem. Uzupełnij zależności normalnym sposobem przyjętym dla swojej dystrybucji.

Jeżeli Trivy nie jest dostępne, skrypt podejmuje jego instalację. Pobieranie skanera oraz bazy wymaga dostępu sieciowego. Na serwerze z ograniczonym wyjściem nie zaczynaj od usuwania reguł zapory. Sprawdź, na którym etapie połączenie jest potrzebne, i uzgodnij dostęp. Gotowy skrypt nie zwalnia z zasad obowiązujących na produkcji.

Skan systemu plików wymaga odpowiednich uprawnień. Bez roota agent ostrzega, że część plików może pozostać niedostępna. Samo przejście polecenia do końca nie dowodzi pełnego odczytu. Poniższe przykłady zakładają zatwierdzoną sesję administracyjną na wybranym hoście.

Przed startem ustal również zasady nazw. Bez własnej etykiety skrypt używa krótkiego hostname. Zakres danych i próbę lokalną opisałem w pierwszym odcinku. Jeśli firma nie zgadza się na wysyłkę nazw, najpierw rozwiąż opisany tam problem kontraktu --no-hostname, zamiast kopiować domyślne uruchomienie z tej strony.

Pobranie i uruchomienie

Panel pokazuje pobranie skryptu przez token projektu, a następnie oddzielne uruchomienie z kluczem API. Wzorzec wygląda tak:

wget -O secvalis.sh "https://secvalis.eu/api/agent/install/INSTALL_TOKEN" && chmod +x secvalis.sh
./secvalis.sh YOUR_API_KEY

INSTALL_TOKEN i YOUR_API_KEY są placeholderami. Pobierz właściwe wartości z własnego projektu. Token w adresie pobierania nie zastępuje klucza do wysyłki wyników. Endpoint zwraca skrypt bez zaszytego klucza. Uruchomienie wymaga więc oddzielnego przekazania sekretu.

Najpierw przeczytaj pobrany plik, potem go uruchom. Wariant z kluczem w argumencie jest pokazem polecenia z panelu; prawdziwy sekret może w ten sposób trafić do historii powłoki albo być widoczny w argumentach procesu. Do cyklicznej pracy użyj pliku klucza opisanego niżej. Nie nagrywaj kopiowania sekretu na udostępnianym ekranie.

Pobranie z panelu nie weryfikuje podpisu ani sumy kontrolnej skryptu agenta.

Pierwszy skan

Na serwerze testowym obserwuj cały przebieg, nie tylko końcowy licznik. Skrypt sprawdza zależności, ustala system, zapewnia dostępność Trivy, wykonuje skan i wysyła wynik. Poszczególne etapy mogą zawieść z różnych powodów. Zapisz, który etap zakończył się poprawnie, zanim zaczniesz poprawiać konfigurację.

Dla powtarzalnej pracy umieść sprawdzony skrypt w stałym miejscu, na przykład /opt/secvalis.sh. Poniższy wariant zakłada właśnie tę ścieżkę oraz prawo wykonania pliku. W katalogu /etc/secvalis dostępnym tylko dla roota przygotuj plik key, należący do roota i z uprawnieniami 0600, o takiej zawartości:

SYSDEVOPS_KEY=YOUR_API_KEY

Wstaw prawdziwy klucz zatwierdzonym edytorem lub mechanizmem dostarczania sekretów. Nie nadpisuj istniejącego pliku bez sprawdzenia, do czego służy. Z takim plikiem ręczne uruchomienie może wyglądać następująco:

sudo bash -c 'set -a; . /etc/secvalis/key; exec /opt/secvalis.sh --low-priority'

Skrypt odczytuje SYSDEVOPS_KEY, gdy nie otrzyma klucza jako argumentu. Sekret nie jest wtedy literalną częścią argumentów polecenia. Plik nadal wymaga ochrony; nie publikuj go razem z konfiguracją. --low-priority obniża priorytet pracy skanera, ale nie daje obietnicy braku wpływu na produkcję. Pierwszą próbę wykonaj w uzgodnionym czasie.

Przykład przetestuj najpierw na jednym serwerze. Nie zakładaj, że skopiowanie go na całą flotę jest tylko większą wersją tego samego testu. Inne hosty mogą mieć kontenery, mniej wolnej pamięci albo odmienny dostęp do repozytoriów. Te różnice ujawniają się podczas wykonania, nie podczas czytania polecenia.

Jak rozpoznać kompletny wynik

Udana wysyłka HTTP oznacza przyjęcie żądania, a nie pełne powodzenie skanowania. Agent rozróżnia ok, partial i failed. Częściowy lub nieudany skan nie zamyka podatności w rejestrze. Ochrona przed wykrytym gwałtownym spadkiem znalezisk dodatkowo blokuje pochopne uznanie wcześniejszych pozycji za usunięte.

Po komunikacie o wysłaniu odczytaj także dalsze ostrzeżenia i kod zakończenia procesu. Obecny skrypt kończy niekompletny skan kodem 2, nawet jeśli udało się przesłać jego dane. Bezpośrednio po uruchomieniu sprawdzisz kod przez echo $?. Inne polecenie wykonane wcześniej nadpisze tę informację.

W panelu otwórz właściwą maszynę i historię skanów. Porównaj czas wykonania z próbą na serwerze oraz widoczne liczniki z oczekiwanym zakresem. Historia zestawia daty, liczby CVE według wagi i zmiany względem poprzedniego wyniku. Status techniczny skanu sprawdzaj również w wyjściu agenta; status maszyny nie jest jego zamiennikiem.

Komunikat o niezmienionych znaleziskach oznacza, że wynik jest taki sam jak poprzednio. Nie odczytuj go jako „zero podatności”. Podobnie pusty wynik bez sprawdzenia uprawnień i zakresu nie wystarcza do uznania serwera za sprawdzony. Na pierwszy odbiór wdrożenia składają się wynik lokalny i potwierdzenie po stronie panelu.

Harmonogram jest osobnym krokiem

Agent wykonuje skan raz. Przykłady harmonogramu wypisuje polecenie:

bash /opt/secvalis.sh --schedule-help

Pomoc pokazuje plik klucza, wariant cron oraz usługę i timer systemd. Niczego nie instaluje. W gotowcu usługa ma Type=oneshot, czyta EnvironmentFile=/etc/secvalis/key, a ExecStart wskazuje skrypt. Timer używa OnCalendar=daily, RandomizedDelaySec=1h i Persistent=true.

Przejrzyj ścieżkę w wygenerowanym ExecStart. Pomoc używa miejsca, z którego uruchamiasz skrypt. Jeżeli później go przeniesiesz, popraw jednostkę. Zachowaj też wybraną etykietę i potrzebne opcje. Harmonogram uruchamia zapisane polecenie, nie ostatnią komendę z Twojej sesji.

Dopiero po zapisaniu sprawdzonych plików jednostek można je aktywować:

sudo systemctl daemon-reload
sudo systemctl enable --now secvalis.timer
sudo systemctl start secvalis.service
sudo systemctl list-timers secvalis.timer
sudo journalctl -u secvalis.service

Dopasuj częstotliwość do własnego procesu. Przykład dzienny nie jest uniwersalnym wymaganiem prawnym. Przy migracji ze starego crona wyłącz poprzedni harmonogram, żeby nie uruchamiać dwóch skanów. Sprawdź też nowy wynik po rzeczywistym wywołaniu przez timer; ręczny sukces nie dowodzi, że środowisko usługi jest poprawne.

Diagnostyka błędów

Objaw	Pierwsza kontrola
Brak curl lub jq	Zależności na tym konkretnym hoście
Nieudane pobranie Trivy lub bazy	Dostęp sieciowy i komunikat etapu pobierania
HTTP 401	Poprawność klucza API
HTTP 403	Uprawnienie do wykonania skanu
HTTP 413	Rozmiar wysyłki i komunikat odrzucenia
HTTP 429	Odczekanie przed ponownym skanem zamiast pętli ponowień
partial, failed lub kod 2	Wcześniejsze ostrzeżenia skanera, dostęp do danych, pamięć i zakres
Ręcznie działa, z timera nie	Dziennik usługi, plik klucza i ścieżka ExecStart

W zgłoszeniu opisz etap, czas i komunikat bez sekretów. Nie wysyłaj całej historii terminala w ciemno. Tak przygotowana informacja pozwala odróżnić problem pobrania, skanera i przyjęcia wyniku przez API.

Czego to nie załatwia

Pierwszy skan nie oznacza poprawek zainstalowanych na serwerze. Secvalis wspiera zarządzanie podatnościami Linux i przygotowanie dowodów; decyzje o aktualizacji, testy i okno serwisowe nadal należą do zespołu. Nie obejmuje Windows, OT, PLC i SCADA ani wykrywania niezgłoszonych urządzeń.

Samo wdrożenie nie zapewnia zgodności z NIS2/KSC ani certyfikacji ISO 27001. Na tym etapie celem jest potwierdzony przepływ od serwera do panelu oraz działający, sprawdzony harmonogram. Tyle powinno znaleźć się w odbiorze pierwszej maszyny.

Potrzebujesz wsparcia przy wdrożeniu? Napisz do mnie: https://sysdevops.eu/kontakt. Zakres, poufność i formalności ustalimy indywidualnie.