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.