Czy już czas na IPv6?

IPv6 – szansa, konieczność czy zagrożenie?

Kilka lat temu w Internecie dużą popularnością cieszyły się liczniki prezentujące topniejącą pulę dostępnych adresów IPv4. Czym bliżej zera zbliżała się wartość na liczniku, tym większe wzbudzała zainteresowanie nową wersją protokołu – IPv6. Producenci urządzeń sieciowych, systemów operacyjnych oraz dostawcy Internetu w krótkim czasie zintensyfikowali swoje działania mające na celu przygotować ich do pracy w nowej rzeczywistości. Lekcje zostały przez nich w mniejszym lub większym stopniu odrobione. Liczniki IPv4 dobiły do zera i… nic się praktycznie nie zmieniło. Zarówno w domowych, jak i firmowych zastosowaniach o IPv6 na poważnie mało kto myślał. O ile bowiem IANA rozdała ostatnie dostępne pule adresów IPv4 rejestrom regionalnym (RIR), o tyle dla użytkowników końcowych nie stanowiło to większego problemu. Rejestry regionalne posiadały bowiem pewne zapasy przestrzeni adresowej na kolejne lata. Z czasem jednak i te zaczęły topnieć i dobijać do zera. Sytuacja się powtórzyła, jednak tym razem rolę bufora z zapasową przestrzenią adresową przejęły rejestry lokalne (LIR), czyli w głównie duzi dostawcy Internetu. Poskutkowało to zaostrzeniem polityk przyznawania adresów IPv4 na poziomie rejestrów regionalnych. Europejski RIPE przestał np. rejestrować nowe AS-y (Autonomous Systems) klientom ubiegającym się o adresację PI (provider independet) w wersji 4. Organizacjom, które nie są jeszcze przygotowane na IPv6 pozostaje więc wiązać się na stałe z dostawcami Internetu, którzy mają do zaoferowania własne adresy z puli przydzielonych im jako LIR-om. Taki stan rzeczy utrzymuje się od 2012 roku. Pomimo, iż jest to już naprawdę ostatni etap przed rzeczywistym wyczerpaniem się adresów IPv4, mało kto interesuje się kwestiami wdrożenia, a przede wszystkim odpowiedniego zabezpieczenia infrastruktury pracującej na IPv6.

Nie używam IPv6, czy problem mnie dotyczy?

Praktyka pokazuje, że masowe stosowanie translacji adresów pozwala nawet dużym organizacjom utrzymywać swoją infrastrukturę przy stosunkowo małych pulach publicznych adresów IPv4. Sporo firm występując o adresację zawyżało też swoje rzeczywiste zapotrzebowanie na publiczne adresy w celu zagwarantowania sobie większego zapasu oraz możliwości elastycznego rozwijania infrastruktury. Konieczność wdrożenia IPv6 dotyczy więc na chwilę obecną głównie organizacji ubiegających się o nową, publiczną adresację PI (providers independent) i chcących zarejestrować własnego AS-a (autonomous system) w celach np. multihostingu BGP.
Co zatem z całą resztą, której wystarczają posiadane zasoby IPv4? Czy organizacje te nie muszą się zajmować bezpieczeństwem IPv6? Wręcz przeciwnie. Systemy z zaimplementowanym nowym protokołem, czy tego potrzebujemy, czy nie od dawna są obecne w naszych sieciach. Każdy system od czasów Windowsa 7, a w przypadku Linuksów jeszcze wcześniej, posiada domyślnie uruchomiony stos IPv6. Co więcej, pewne charakterystyczne cechy tego protokołu, jak np. zdolność do autokonfiguracji bez obecności serwera DHCP, sprawiają, że może on z powodzeniem działać w naszej sieci bez szczególnego udziału administratorów, a nawet bez ich wiedzy.

Czy zagrożenie jest realne?

Wszelkie rozwiązania mające na celu zapewnienie bezpieczeństwa usług sieciowych zorientowane są na konkretny protokół komunikacyjny. Zapory sieciowe, serwery proxy, bramki skanujące pocztę, bramy VPN i wszystkie inne mechanizmy budowane z myślą o zabezpieczeniu protokołu IPv4 nie mają żadnego zastosowania w przypadku IPv6, o ile ten protokół nie został na nich zaimplementowany i odpowiednio skonfigurowany. Zapora systemowa, która blokuje ruch wchodzący dla IPv4 pozostanie obojętna dla ruchu IPv6, o ile nie zostanie włączony jej odpowiednik z regułami dla tegoż protokołu. Poniżej przykład skanowania portów serwera linuksowego, na którym firewall (iptables) blokuje cały ruch przychodzący:

> nmap 10.10.0.22

Nmap scan report for 10.10.0.22
Host is up (0.00025s latency).
All 1000 scanned ports on 10.10.0.22 are filtered

Nmap done: 1 IP address (1 host up) scanned in 21.43 seconds

Co się jednak stanie gdy ten sam serwer przeskanujemy przy użyciu protokołu IPv6?

> nmap -6 20a2:54:200:21::2

Nmap scan report for 20a2:54:200:21::2
Host is up (0.00043s latency).
Not shown: 991 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
443/tcp  open  https
993/tcp  open  imaps
995/tcp  open  pop3s
9876/tcp open  sd

Nmap done: 1 IP address (1 host up) scanned in 7.39 seconds

Jak widać zablokowanie całego ruchu przy użyciu standardowych reguł firewalla w żaden sposób nie blokuje dostępu do usług na poziomie protokołu IPv6. W przypadku Linuksa w celu zablokowania tego ruchu konieczne byłoby użycie odpowiednika iptables dedykowanego dla ruchu IPv6, czyli ip6tables. Przykład reguły blokującej ruch przychodzący na port 22 (ssh) widoczny jest poniżej:

/sbin/ip6tables -A INPUT -p tcp -s 0/0 -d 20a2:54:200:21::2 --dport 22 -j REJECT -i eth0

Jak widać poza samym poleceniem oraz formatem adresu IP reguła ta ma identyczną składnię jak reguły iptables dla IPv4. W celu odpowiedniego zabezpieczenia usług nie jest zatem potrzebna żadna ekspercka wiedza wymagająca poznawania nowych narzędzi. Konieczna jest natomiast świadomość zagrożeń. Dużym błędem jest zakładanie, iż nie potrzebujemy się martwić o bezpieczeństwo IPv6 jeżeli go nie używamy. Jak wspomniano powyżej protokół ten jest już obecny w naszych sieciach i systemach niezależnie od tego, czy wdrożyliśmy go świadomie, czy też znalazł się tam wyniku przeoczenia. Często popełnianym błędem jest też przyjmowanie, iż w celu ochrony przed zagrożeniami wystarczy wyłączyć IPv6 na interfejsach sieciowych. Działanie takie ograniczy komunikację ze światem zewnętrznym ale nie wyłączy obsługi protokołu w jądrze systemu. Co się stanie gdy zapingujemy nasz host przy wyłączonym IPv6 na interfejsach?

> ping6 ::1
PING ::1 56 data bytes
64 bytes from ::1 icmp_seq=1 ttl=64 time=0.017 ms
64 bytes from ::1 icmp_seq=2 ttl=64 time=0.027 ms
64 bytes from ::1 icmp_seq=3 ttl=64 time=0.026 ms
64 bytes from ::1 icmp_seq=4 ttl=64 time=0.025 ms

Jak widać komunikacja za pomocą interfejsu loopback (::1 stanowi odpowiednik 127.0.0.1) jest w dalszym ciągu możliwa. Możliwy jest więc również lokalny dostęp do usług za pomocą IPv6 pomimo jego wyłączenia na interfejsach sieciowych.

A jak przygotowani są intruzi?

Brak naszej świadomości i zaangażowania w proces ochrony komunikacji z użyciem protokołu IPv6 to tylko jeden z czynników składających się na zagrożenie. Innym z nich jest powstanie i ciągły rozwój narzędzi wykorzystywanych do badania i ewentualnego naruszania bezpieczeństwa. Przykładem pakietu skupiającego zestaw takich narzędzi może być „The Hacker Choice’s IPv6 Attack Toolkit” (aka thc-ipv6). Po jego zainstalowaniu w systemie dostępna jest całkiem pokaźna lista narzędzi, których już same nazwy brzmią groźnie:

atk6-address6            atk6-dnsrevenum6         atk6-extract_networks6   atk6-fake_mldrouter6     atk6-flood_mld26         atk6-four2six            atk6-kill_router6        atk6-redirsniff6         atk6-trace6
atk6-alive6              atk6-dnssecwalk          atk6-fake_advertise6     atk6-fake_pim6           atk6-flood_mld6          atk6-fragmentation6      atk6-ndpexhaust26        atk6-rsmurf6             
atk6-covert_send6        atk6-dos_mld             atk6-fake_dhcps6         atk6-fake_router26       atk6-flood_mldrouter6    atk6-fuzz_dhcps6         atk6-ndpexhaust6         atk6-sendpees6           
atk6-covert_send6d       atk6-dos-new-ip6         atk6-fake_dns6d          atk6-fake_router6        atk6-flood_redir6        atk6-fuzz_ip6            atk6-node_query6         atk6-sendpeesmp6         
atk6-denial6             atk6-dump_dhcp6          atk6-fake_dnsupdate6     atk6-fake_solicitate6    atk6-flood_router26      atk6-implementation6     atk6-parasite6           atk6-smurf6              
atk6-detect-new-ip6      atk6-dump_router6        atk6-fake_mipv6          atk6-firewall6           atk6-flood_router6       atk6-implementation6d    atk6-passive_discovery6  atk6-thcping6            
atk6-detect_sniffer6     atk6-exploit6            atk6-fake_mld26          atk6-flood_advertise6    atk6-flood_rs6           atk6-inject_alive6       atk6-randicmp6           atk6-thcsyn6             
atk6-dnsdict6            atk6-extract_hosts6      atk6-fake_mld6           atk6-flood_dhcpc6        atk6-flood_solicitate6   atk6-inverse_lookup6     atk6-redir6              atk6-toobig6

Warto przyjrzeć się powyższym narzędziom i ich możliwościom aby uzmysłowić sobie skalę pewnych zagrożeń i związane z nimi ryzyko.

Mam nadzieję że niniejszym artykułem rzuciłem pewne światło na problematykę związaną z ochroną IPv6. Jeżeli temat okaże się interesujący, być może w kolejnych częściach dokonamy wspólnie przeglądu narzędzi z pakietu thc-ipv6 i pokażemy możliwości ich zastosowania w celu zwiększenia bezpieczeństwa własnych sieci i systemów.