Pivoting w sieci i Chisel w testach penetracyjnych

Pivoting w sieci to przejście z jednego hosta na inny, do którego ten pierwszy ma dostęp. Ruch do wewnętrznego segmentu nie wychodzi więc z internetu, lecz przechodzi przez maszynę pośrednią — serwer w strefie zdemilitaryzowanej, host z dwiema kartami sieciowymi albo stację roboczą widzącą sieć biurową i produkcyjną.

Dla zespołu ofensywnego pivot odpowiada na pytanie „co jeszcze da się osiągnąć z tego miejsca”, dla obrońcy — czy segmentacja z dokumentacji istnieje naprawdę. Ten materiał opisuje obie strony, ale wyłącznie w kontekście autoryzowanego testu penetracyjnego albo własnego laboratorium.

Czym jest pivoting w sieci

Wyobraźmy sobie typową firmę: strefa publiczna z serwerem webowym, sieć biurowa i sieć wewnętrzna z bazami. Z internetu widać tylko pierwszy element. Jeśli jednak serwer webowy ma swobodny ruch wychodzący i widzi sieć wewnętrzną, staje się punktem zaczepienia.

Pivot nie jest podatnością sam w sobie. To skutek zaufania skonfigurowanego kiedyś wygodnie i bez analizy: „tymczasowa” reguła zapory, wspólny VLAN dla wszystkich usług, konto z szerokimi uprawnieniami. Test sprawdza, jak daleko to zaufanie sięga.

Dlaczego segmentację trzeba testować, a nie zakładać

Dokumentacja architektury opisuje stan zamierzony, a rzeczywistość zmienia się szybciej: zespoły dodają maszyny, otwierają porty na czas wdrożenia i zapominają je zamknąć, przenoszą aplikacje do chmury z domyślnymi regułami, a hosty z dwiema kartami trafiają do środowiska bez nadzoru.

Efekt jest przewidywalny: sieci, które na papierze mają pięć stref, w praktyce tworzą jedną płaską przestrzeń. Pivoting mierzy realny zasięg ruchu, a nie intencje administratora.

Od przekierowania portu do tunelu warstwy trzeciej

Wszystkie techniki pivoting opierają się na tym samym pomyśle: host pośredni przekazuje ruch dalej. Różnią się poziomem, na którym to robią, i tym, ile pracy wymagają od atakującego oraz od obrońcy.

Przekierowanie portu

Najprostszy wariant przekierowuje jeden port. Tunel SSH z lokalnym przekierowaniem sprawia, że port na maszynie testera łączy się z wybranym portem widzianym z hosta pośredniego. Zaleta to precyzja, wada — każdy nowy port wymaga nowego tunelu.

Proxy warstwy aplikacji

Drugi wariant tworzy proxy SOCKS na hoście pośrednim. Narzędzia obsługujące to proxy łączą się z dowolnym adresem i portem osiągalnym z tej maszyny, więc jedno połączenie wystarcza do przeglądu całej wewnętrznej przestrzeni adresowej.

Tunele odwrotne

Trzeci wariant odwraca kierunek: host w sieci wewnętrznej łączy się na zewnątrz, z serwerem testera, i utrzymuje to połączenie. Działa, gdy zapora blokuje ruch przychodzący, ale przepuszcza wychodzący — a to najczęstsza konfiguracja w firmach.

Gdzie w tym obrazie jest Chisel

Chisel to narzędzie w języku Go, które buduje tunel przez HTTP i WebSocket. W testach liczy się prostota: jeden plik binarny, brak zależności i ruch wyglądający jak zwykłe HTTPS na porcie 443, więc przechodzący przez filtry, które nie zaglądają w treść.

Cecha	Tunel SSH	Chisel
Wymaga usługi SSH na hoście	Tak	Nie
Protokół w sieci	SSH, często na niestandardowym porcie	HTTP i WebSocket, zwykle 443
Konfiguracja	Klient w systemie, klucze, uprawnienia	Dwa pliki binarne i jeden parametr
Typowe zastosowanie w teście	Szybki dostęp do jednego portu	Trwały tunel odwrotny i proxy SOCKS

Dla obrońcy różnica jest istotna: blokada SSH na brzegu nie zatrzymuje tunelu po HTTP, a reguła „tylko 443 na zewnątrz” nie wystarcza, jeśli nie sprawdza się, dokąd ten ruch idzie.

Co Chisel pozwala sprawdzić w autoryzowanym zleceniu

W dobrze zaplanowanym teście narzędzie jest narzędziem pomiaru. Chisel pozwala odpowiedzieć na cztery pytania, których nie rozstrzygnie skan z zewnątrz: czy host w strefie publicznej ma swobodny ruch wychodzący, czy segmentacja między strefami istnieje, czy kontrola aplikacyjna rozpoznaje tunelowany ruch i czy monitoring widzi długotrwałe połączenie do nieznanego adresu.

Każde ustalenie trafia do raportu jako obserwacja z dowodem: znacznikiem czasu, adresami i zrzutem konfiguracji. Bez dowodu zostaje opinia, a opinia nie pomaga naprawić sieci.

Konfiguracja w laboratorium

Układ opisany poniżej uruchamiamy wyłącznie w sieci laboratoryjnej albo w środowisku klienta objętym umową. Adresy 10.10.10.0/24 są przykładowe i powinny być inne niż w infrastrukturze produkcyjnej.

Strona serwera

Serwer stawiamy na maszynie, do której mamy legalny dostęp, najlepiej w wydzielonym segmencie laboratoryjnym. Uruchamiamy go w trybie odwrotnym i wskazujemy port nasłuchu:

chisel server --reverse --port 8443

W ćwiczeniu warto wymusić TLS, ograniczyć dostęp regułą źródłowego adresu IP i prowadzić log połączeń. Bez tego zbudujemy narzędzie, którego nie kontrolujemy.

Strona klienta

Klient działa na hoście, który w scenariuszu odgrywa rolę pivota. Parametr zdalnego proxy tworzy tunel SOCKS po stronie serwera, dzięki czemu narzędzia testera mogą kierować ruch przez host pośredni:

chisel client https://twoj-serwer:8443 R:socks

Port i adres to dane konfiguracyjne, nie stałe: w zleceniu zależą od tego, co wolno uruchomić na danym hoście i jakie reguły ruchu wychodzącego obowiązują w sieci klienta.

Wykorzystanie tunelu

Ruch narzędzi kierujemy na lokalny port proxy. Skanowanie odbywa się w granicach zakresu zapisanego w umowie:

proxychains nmap -sT -Pn 10.10.10.0/24

Zakres jest tu najważniejszy: skanowanie adresów spoza uzgodnionego zakresu, nawet przypadkowe, jest naruszeniem umowy i prawa.

Bezpieczne środowisko ćwiczeń

Zanim uruchomicie pierwszy tunel, warto przygotować laboratorium tak, żeby pomyłka nie miała konsekwencji.

Izolacja. Osobny segment bez trasy do sieci produkcyjnej, najlepiej za osobnym interfejsem i z jawną regułą blokującą ruch do reszty infrastruktury.
Wersjonowanie. Snapshoty maszyn wirtualnych przed każdym ćwiczeniem, żeby po zakończeniu wrócić do stanu wyjściowego w kilka minut.
Dane. Wyłącznie dane testowe. Żadnych kopii bazy klientów, żadnych prawdziwych dokumentów, żadnych kluczy produkcyjnych.
Zakres. Zapisana lista adresów i hostów objętych ćwiczeniem, wywieszona obok konsoli.
Rejestr. Notatka z datą, godziną, użytymi parametrami i wynikiem — bez tego ćwiczenie nie da się powtórzyć ani opisać.

Jak wyglądają wyniki z prawdziwego zlecenia

Wynik testu nie jest listą narzędzi, a opisem tego, co da się zrobić z danego miejsca i co to znaczy dla bezpieczeństwa firmy.

Słaba segmentacja

Typowe ustalenie: host w strefie publicznej widzi całą sieć wewnętrzną na wszystkich portach. W raporcie to ryzyko wysokie, bo jedno przejęcie serwera webowego zamienia się w dostęp do baz. Rekomendacja jest architektoniczna: strefy, reguły domyślnie blokujące, przegląd hostów z wieloma interfejsami.

Ruch wychodzący bez kontroli

Drugie ustalenie dotyczy ruchu wychodzącego: serwer aplikacji łączy się z dowolnym adresem w internecie, więc tunel da się zbudować bez otwierania portów na zaporze. Naprawa to lista dozwolonych celów, proxy z uwierzytelnianiem i logowanie nazw domenowych.

Brak wykrywalności

Trzecie ustalenie bywa najdroższe: długotrwałe połączenie do nieznanego adresu nie wywołuje alertu. To nie znaczy, że monitoring pracuje źle — znaczy, że nikt nie zdefiniował, jak takie połączenie ma wyglądać w danych.

Wnioski dla obrońców

Domyślnie blokuj ruch wychodzący. Lista dozwolonych celów dla każdej klasy hosta jest nudna, ale zamyka całą rodzinę scenariuszy.
Nie ufaj strefie. Segmentacja musi obowiązywać także w ruchu wschód-zachód, nie tylko na wejściu z internetu.
Inwentaryzuj hosty z dwiema kartami. Jeden nieewidencjonowany serwer z dostępem do dwóch sieci potrafi znieść cały podział na strefy.
Patrz na czas trwania połączeń. Tunel to długie, stabilne połączenie do jednego adresu, a nie seria krótkich sesji.
Rejestruj DNS. Zapytania o nazwy spoza firmowej strefy są jednym z najtańszych sygnałów wczesnego ostrzegania.
Testuj regularnie. Reguły zapory dryfują z każdym wdrożeniem, więc wynik sprzed roku nie opisuje dzisiejszej sieci.

Granica prawna i etyczna

Pivoting jest techniką neutralną. Czy jego użycie jest legalne, zależy wyłącznie od zgody właściciela infrastruktury i zakresu, na który jej udzielił.

W praktyce to kilka warunków, których nie da się obejść. Potrzebna jest pisemna umowa określająca zakres adresów, hostów i systemów, okres testu i osobę kontaktową po stronie klienta, a także zgoda na metody inwazyjne. Potrzebny jest plan postępowania z danymi: nie wywozimy ich, nie kopiujemy i nie przechowujemy dłużej, niż wymaga raport.

Warto zapisać warunki zatrzymania: co robimy, gdy natrafimy na dane osobowe, system medyczny albo infrastrukturę dostawcy. Testowanie systemów osób trzecich bez ich zgody jest bezprawne, nawet jeśli klient twierdzi, że „to jego dostawca”. Ustalenia krytyczne zgłaszamy natychmiast.

Narzędzia takie jak Chisel nie dają gwarancji powodzenia i nie zwalniają z tych obowiązków. Zmieniają tylko sposób przejścia ruchu przez sieć — odpowiedzialność zostaje po stronie człowieka, który je uruchamia.

Najczęstsze błędy początkujących

Uruchamianie tunelu w infrastrukturze produkcyjnej bez zapisu w umowie. Ćwiczenie zamienia się w incydent, a zespół klienta widzi nieplanowany ruch.
Pominięcie rejestracji. Bez znaczników czasu i parametrów wynik jest relacją, nie dowodem.
Skanowanie szerszego zakresu niż zapisany. Najczęstsze źródło sporów po zakończeniu zlecenia.
Zapominanie o sprzątaniu. Otwarte tunele, pozostawione pliki i procesy w tle zostawiają klienta w gorszym stanie niż przed testem.
Traktowanie narzędzia jako celu. Napisanie, że użyto konkretnego programu, nie jest wnioskiem. Wnioskiem jest to, co ten program pozwolił zobaczyć.

Najczęściej zadawane pytania

Czym różni się pivoting od eskalacji uprawnień?

Eskalacja uprawnień to zdobycie większych praw na tej samej maszynie. Pivoting to przejście na inną maszynę lub do innego segmentu, do którego dostęp ma host pośredni. W praktyce oba etapy często następują po sobie.

Czy Chisel jest legalnym narzędziem?

Tak samo jak każdy program do obsługi sieci: legalne jest jego użycie w sieci, do której masz prawo dostępu, i w zakresie, na który masz zgodę. Nielegalne jest użycie go wobec systemów, których właściciel takiej zgody nie udzielił.

Czy tunel HTTP zawsze omija zaporę?

Nie. Przechodzi przez zapory filtrujące wyłącznie porty i adresy, ale zatrzymują go rozwiązania analizujące nazwy domenowe, certyfikaty i zachowanie połączeń. Dlatego test ma sprawdzić, co w firmie działa, a co jest założeniem.

Od czego zacząć naukę pivoting?

Od własnego laboratorium: dwie maszyny wirtualne w izolowanym segmencie, jeden serwer i jeden host pośredni. Dopiero po opanowaniu tego układu warto przejść do środowiska klienta, zawsze pod nadzorem osoby odpowiedzialnej za zakres.

Czy z raportu usuwamy szczegóły techniczne?

Nie usuwamy, ale zmieniamy proporcje. Szczegóły potrzebne do odtworzenia ustalenia zostają w załączniku technicznym, a część zarządcza opisuje ryzyko, wpływ i rekomendację językiem zrozumiałym dla osób decyzyjnych.

Jeśli chcesz sprawdzić, jak daleko sięga zaufanie między segmentami Twojej sieci — w kontrolowanym, umówionym zakresie — porozmawiaj z zespołem.

Pivoting w sieci: pierwsze kroki z Chisel