Masz już IPv6 w sieci, choć o tym nie wiesz

Gdy pada pytanie, czy sieć firmowa obsługuje IPv6, odpowiedź większości administratorów jest krótka: „Nie wdrażaliśmy”. I, technicznie rzecz biorąc, mają rację. Nikt nie konfigurował routera brzegowego do rozgłaszania prefiksu IPv6. Nikt nie stawiał serwera DHCPv6. Nie ma żadnej polityki adresowania w tej przestrzeni. Problem w tym, że IPv6 nie czeka na zaproszenie. Jest on domyślnie włączony we wszystkich popularnych systemach operacyjnych.

Adres, który zawsze tam jest

Zanim zrozumiemy, skąd bierze się IPv6 w sieci, którą „nie zarządzamy”, warto zacząć od mechanizmu najbardziej podstawowego. Każdy interfejs sieciowy z włączonym stosem IPv6 automatycznie generuje sobie adres z zakresu fe80::/10. Taki adres nazywamy link-local i nie wymaga do swojego powstania żadnego serwera, żadnego routera ani żadnej zewnętrznej konfiguracji. System operacyjny konstruuje go samodzielnie, łącząc prefiks fe80:: z identyfikatorem interfejsu. Historycznie identyfikator bywał wyprowadzany z MAC metodą EUI-64, ale współczesne systemy często używają stabilnych lub tymczasowych identyfikatorów, które nie ujawniają adresu MAC. Adres link-local ma zasięg ograniczony do segmentu sieciowego i nie jest routowalny poza interfejsem, na którym powstał. To pozorne ograniczenie sprawia, że wielu administratorów w ogóle nie bierze go pod uwagę. Tymczasem komunikacja link-local jest w pełni funkcjonalna i używana do wielu ważnych protokołów, w tym do NDP (Neighbor Discovery Protocol), który w IPv6 zastępuje ARP. Od momentu uruchomienia systemu, jeszcze zanim uruchomi się jakikolwiek klient DHCP, interfejs sieciowy aktywnie komunikuje się z otoczeniem właśnie przez te adresy. Cały ten ruch jest normalnie niewidoczny dla kogoś, kto analizuje wyłącznie ruch IPv4.

SLAAC, czyli autokonfiguracja bez serwera

Adres link-local to dopiero punkt startowy. Jeśli w segmencie sieciowym istnieje router z włączonym IPv6, sytuacja szybko staje się ciekawsza. Router cyklicznie lub w odpowiedzi na Router Solicitation wysyła Router Advertisement (RA), czyli komunikat zawierający m.in. prefiks sieciowy oraz flagi informujące hosty, jak mają postępować z adresacją. Gdy flaga A (Autonomous) w komunikacie RA jest ustawiona, hosty używają mechanizmu SLAAC (Stateless Address Autoconfiguration). Polega on na tym, że system operacyjny samodzielnie konstruuje pełny adres globalny, łącząc ogłoszony prefiks z własnym identyfikatorem interfejsu. Żaden serwer nie przydziela adresu, żaden serwer nie przechowuje stanu (stąd właśnie „stateless” w nazwie). Z perspektywy administratora, który nie skonfigurował DHCPv6 i nie planuje IPv6, może być to zupełne zaskoczenie: hosty mają globalne (lub co najmniej unique local [ULA]) adresy IPv6 i mogą się między sobą komunikować na ich podstawie.

Warto przy tym wspomnieć, że w środowiskach dual-stack wybór między IPv6 i IPv4 wynika z mechanizmów preferowania konkretnej adresacji oraz zachowania samych aplikacji. W praktyce natywne IPv6 bywa preferowane. Oznacza to, że nawet jeśli rekord A w DNS jest dostępny, system najpierw spróbuje użyć rekordu AAAA, o ile takowy istnieje. Taki ruch idzie potencjalnie inną ścieżką i nie każde narzędzie do monitoringu za nim podąża.

Tunele, których nikt nie zamawiał

Nawet w sieciach, gdzie żaden router nie rozgłasza RA, IPv6 może być aktywny dzięki mechanizmom tunelowania. Historycznie Windows wspierał mechanizmy 6to4, ISATAP i Teredo, ale we współczesnych wersjach systemu są one domyślnie wyłączone lub wygaszane. Teredo to usługa wbudowana w Windows, która pozwala na uzyskanie globalnego adresu IPv6 przez UDP nad IPv4. Klient kontaktuje się z publicznym serwerem Teredo (historycznie były to serwery Microsoft, teraz możliwe jest też wskazanie własnych) i otrzymuje adres z zakresu 2001::/32. Co istotne: cały ruch IPv6 odbywa się wówczas przez zewnętrzny serwer, przekraczając granicę sieci firmowej w sposób, który może pozostać niezidentyfikowany przez firewall IPv4 jako ruch IPv6.

6to4 to mechanizm oparty na prefiksie 2002::/16, który enkapsuluje IPv6 w IPv4 i pozwala na bezpośrednią komunikację z innymi hostami obsługującymi 6to4. Choć Teredo i 6to4 są dziś rzadziej spotykane niż kilka lat temu, częściowo dlatego, że wiele sieci blokuje odpowiednie porty i protokoły, to nadal pojawiają się w skanach jako aktywne. ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) to z kolei mechanizm zaprojektowany właśnie dla środowisk korporacyjnych, pozwalający na tunelowanie IPv6 w obrębie sieci czysto IPv4 bez wymiany sprzętu. Tu warto zaznaczyć, że Microsoft usunął obsługę ISATAP z Windows 10 (od wersji 1803) i Windows Server 2019. W nowoczesnych środowiskach korporacyjnych jest praktycznie nieobecny.

Ślepa plama

Wszystko powyższe byłoby jedynie ciekawostkami, gdyby nie jeden zasadniczy problem: w wielu organizacjach monitoring i polityki bezpieczeństwa dla IPv6 są mniej dojrzałe niż dla IPv4, co tworzy realną ślepą plamę operacyjną. Zespoły SOC pracują z alertami opartymi na regułach napisanych dla IPv4. Systemy IDS/IPS mają reguły sygnatur skalibrowane pod IPv4. Logi firewalli zawierają wpisy dla IPv4. SIEM przetwarza to, co wpada do logów, a tam wpada to, co ktoś skonfigurował do logowania. Atakujący, który wie o tym, może świadomie korzystać z IPv6 do poruszania się po sieci. Ruch lateralny między hostami komunikującymi się przez adresy link-local może być całkowicie niewidoczny dla systemu monitorującego sieć na poziomie warstwy 3 IPv4. Jeśli na hoście działa usługa nasłuchująca na wszystkich interfejsach (wildcard bind), to usługi nasłuchujące na IPv6 mogą być dostępne także po adresach IPv6, w tym link-local, jeśli aplikacja i polityka hosta na to pozwalają.

Tunelowanie przez Teredo stwarza zaś jeszcze poważniejszy problem: ruch opuszcza sieć firmową. Nie jako sesja TCP do konkretnego adresu docelowego, którą można łatwo zidentyfikować na firewallu, ale jako UDP do serwera relay, po czym kontynuuje jako IPv6. Tradycyjna inspekcja może tego po prostu nie wychwycić.

Co z tym zrobić?

Po pierwsze, trzeba zrozumieć, jak działa protokół IPv6 i jak funkcjonalności związane z IPv6 są implementowane w systemach operacyjnych, na urządzeniach sieciowych oraz w protokołach i usługach sieciowych. Kolejnym krokiem zaś jest audyt, czyli sprawdzenie, co faktycznie dzieje się w sieci z ruchem IPv6, po którym powinna nastąpić świadoma konfiguracja zezwalająca lub blokująca IPv6 w sieci. 

Jeżeli zaś firma zdecyduje się na wdrażanie nowego protokołu, to powinno to nastąpić w sposób bezpieczny i na wszystkich płaszczyznach, tak jak robimy to w przypadku usług opartych na protokole IPv4.

Wszystkich zainteresowanych tematyką bezpieczeństwa IPv6 zapraszam już 21 kwietnia na swoje szkolenie Bezpieczeństwo IPv6 – od podstaw protokołu do hardeningu infrastruktury. Link do zapisów macie w ramce na początku artykułu.

~Piotr Wojciechowski (CCIE #25543)