jedną z zalet posiadania (i oswojenia) IPv6 jest to, że jest to zupełnie osobny protokół w stosunku do IPv4.

pozwolę Wam rozważyć to zdanie w myślach przez chwilę. zwróćcię uwagę na słowa zupełnie osobny protokół. w razie wątpliwości, przeczytajcie powyższe zdanie jeszcze raz, tym razem wolniej.

można robić mądre miny lub zapisać sobie to zdanie i użyć go podczas najbliższego panelu dla dyrektorów i prezesów, wymawiając poszczególne słowa z głębokim namaszczeniem.

praktyczne efekty w pouczającym przykładzie

sytuacja autentyczna, sprzed paru godzin.

mała sieć, z routerem Cisco serii 800 zapewniającym dostęp do internetu, QoS oraz stanowy firewall (ZBFW). wszystko działa pięknie, do czasu gdy Ambitny Administrator (w tej roli ja, pracujący zdalnie przez SSH…) postanawia “doszczelnić” mechanizmy bezpieczeństwa i poprawić ACLkę założoną na interfejs wewnętrzny. “tradycyjnie”, typowa ACLka dla domowego środowiska, w którym pracują komputery z Windowsem wygląda mniej więcej tak:

!
interface Vlan10
 description Interfejs LAN
 ip address 192.168.0.1 255.255.255.0
 ip verify unicast source reachable-via rx
 ip access-group acl-lan-fw in
!
ip access-list extended acl-lan-fw
 deny   tcp any any range 135 139
 deny   udp any any range 135 139
 deny   tcp any range 135 139 any
 deny   udp any range 135 139 any
 deny   tcp any any eq 445
 deny   udp any any eq 445
 deny   tcp any eq 445 any
 deny   udp any eq 445 any
 permit ip any any
!

większość oprogramowania złośliwego używa do inicjowania sesji do swoich serwerów C&C portów 80 i 443 (a czasem 53), ale nadal zdarza się masa śmieci, które próbują generować ruch na innych, dziwnych portach.

z tego powodu, istnieje cała koncepcja filtrowania ruchu, która zakłada, że ruch wychodzący do internetu również filtrujesz z ruchu niepożadanego a nie pozwalasz każdemu dowolnemu pakietowi tworzyć nową chronioną sesję.

w ramach właśnie takich “prac”, w powyższej ACLce przed wpisem permit znalazła się taka sekwencja:

[...]
    deny tcp any any range 0 chargen
    deny udp any any range 0 19 
    deny tcp any any range 26 52
    deny udp any any range 26 52
    deny tcp any any range 54 finger
    deny udp any any range 54 79 
[...]

widzicie problem? ja go przeoczyłem.

bramka do internetu z usługami

oczywiście ponieważ to jedyny router w promieniu paru kilometrów, oprócz usług bezpieczeństwa zapewnia tak wygodne dla sieci lokalnej usługi DHCP, czyli dynamicznego przydziału i rezerwacji adresów. DHCP jest protokołem, który nieszczęśliwie dla powyższego przykładu, używa portów 67 i 68.

tak się złożyło, że w ramach “zdalnych prac”, do routera podłączone zostały dwa punkty dostępowe Cisco oparte o autonomiczny system IOS. oba w domyślnej konfiguracji próbują przyznać sobie adres za pomocą DHCP (podobnie zresztą jak inne APeki z innymi systemami - tutaj nie ma żadnej niespodzianki). zanim jeszcze zdalni użytkownicy zdążyli zamarudzić, że nagle nie działa im “internet”, zauważyłem że za nic nie jestem w stanie ustalić adresów IP tych APeków ponieważ… go nie mają.

ponieważ APeki połączone były bezpośrednio do routera, mogłem sprawdzić za pomocą CDP jaki adres otrzymały (poniżej dla jasności tylko jeden APek):

rtr#sh cdp neighbors detail
-------------------------
Device ID: ap1.zdalny.home
Entry address(es):
  IPv6 address: FE80::DB53:44FF:FE5A:C948  (link-local)
Platform: cisco AIR-SAP3702I-E-K9,  Capabilities: Trans-Bridge Source-Route-Bridge IGMP
Interface: GigabitEthernet5,  Port ID (outgoing port): GigabitEthernet0
Holdtime : 157 sec

Version :
Cisco IOS Software, C3700 Software (AP3G2-K9W7-M), Version 15.3(3)JPK1, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2021 by Cisco Systems, Inc.
Compiled Tue 30-Mar-21 12:05 by prod_rel_team

advertisement version: 2
Duplex: full
Power drawn: 15.400 Watts
Power request id: 18976, Power management id: 0
Power request levels are:16800 15400 13000 0 0

jak to nie ma IPv4?!

sprawa na pierwszy rzut wydawała mi się dziwna i oczywiście w tym momencie można usiąść, rozpłakać się i poprosić użytkownika o odesłanie sprzętu do rekonfiguracji, albo samemu zapakować się w samochód gdyby nie… domyślna konfiguracja interfejsów BVI na APekach Cisco, która wygląda dla przypomnienia w ten sposób:

!
interface BVI1
 ip address dhcp client-id GigabitEthernet0
 ipv6 address dhcp
 ipv6 address autoconfig
 ipv6 enable
!

dzięki niej, AP próbuje uzyskać adresy IP w dwóch protokołach niezależnie - IPv4 i IPv6. dzięki temu, w powyższym zrzucie z CDP pojawił się autoskonfigurowany adres IPv6:

rtr#sh cdp neighbors detail
[...]  
   IPv6 address: FE80::DB53:44FF:FE5A:C948  (link-local)
[...]

router nie posiadał nawet tunelu IPv6, ale wystarczyło na wewnętrznym interfejsie dokonfigurować adres IPv6:

rtr#conf t
rtr(config)#interface vlan 10
rtr(config-if)#ipv6 enable
rtr(config-if)#^Z

…a następnie zalogować się na APek używając jego adresu link-local:

rtr#telnet FE80::DB53:44FF:FE5A:C948 /source-interface vlan 10
Trying FE80::DB53:44FF:FE5A:C948 ... Open

User Access Verification

Username: login
Password: password

ap1.zdalny.home>

dopiero w tym momencie zorientowałem się, że skoro działa komunikacja IPv6, a nie działa przydział adresu IPv4 coś musi być filtrowane… i poprawiłem reguły ruchowe na routerze.

APek (oraz inni użytkownicy) bez problemu otrzymali adresy IPv4 i mogli zacząć normalnie funkcjonować. ponieważ lokalny dostawca nie udostępnia adresów IPv6, od razu dokonfigurowałem też tunel IPv6 z Hurricane Electric

IPv6 FTW!

tak czy inaczej - włączajcie IPv6, sprawdzajcie stosy sieciowe swoich urządzeń i oczywiście zadbajcie o jego bezpieczne filtrowanie. automaty szukające ofiar “już umieją w IPv6” i usługi wystawione do internetu po IPv6 też potrafią odnaleźć i skompromitować. swoją drogą, NAT dla IPv4 też nie jest i nie był nigdy ochroną.