Sok vállalati hálózat dokumentációjában csak IPv4-címtartományok szerepelnek: VLAN-onként egy alhálózat, egy DHCP-kiszolgáló, a tűzfalon zónák és szabályok. A hálózaton ülő gépek közben IPv6-címet is viselnek, és az interfészek címlistájából vagy a gépek IPv6-szomszédtáblájából kiderül, hogy egymással ezen a protokollon is forgalmaznak.
Ehhez nem kell IPv6-bevezetési projekt, elég, hogy az operációs rendszerek alapból bekapcsolják. A tűzfalon, a kapcsolókon és a zónák között ezért akkor is van teendő, ha a cég IPv6-ot egyelőre nem akar használni.
Miért van jelen az IPv6 akkor is, ha senki nem tervezte
A mai asztali és szerver operációs rendszerek, a mobil eszközök és sok hálózati eszköz gyárilag mindkét protokollt futtatja. Az IPv6-ot (IETF RFC 8200) nem kell külön telepíteni vagy engedélyezni, a hálózati kártya bekapcsolásakor magától képez egy címet, amellyel a saját szegmensén belül azonnal kommunikálni tud.
Ha a gépnek IPv4- és IPv6-címe is van, és a célállomás neve mindkét címre feloldódik, a célcím-sorrend szabályai (IETF RFC 6724) globális IPv6-címnél az IPv6-ot teszik előre, egyedi helyi címnél viszont az IPv4-et. A Happy Eyeballs eljárás (IETF RFC 8305) szerint a gép előbb IPv6-on próbálkozik, és ha rövid időn belül nem kap választ, IPv4-en is elindítja a kapcsolódást, majd azt használja, amelyik előbb felépül. A gyakorlatban ez azt jelenti, hogy ahol a szegmensen globális IPv6-előtag is megjelenik, a belső gépek egymás közötti forgalmának egy része IPv6-on megy, anélkül, hogy erről bárki döntött volna. Előtag nélkül is lehet IPv6-forgalom: a helyi névfeloldó protokollok (mDNS, LLMNR) link-local címet is visszaadhatnak, és a gépek azon közvetlenül elérik egymást.
A kikapcsolás sem egyszerű kiút. Az operációs rendszerek egyes gyártói kifejezetten nem javasolják a protokoll teljes letiltását, mert a rendszer egyes komponensei számítanak rá, és a rendszert is bekapcsolt IPv6-tal tesztelik. Helyette azt ajánlják, hogy a gép az IPv4-et részesítse előnyben. Ha pedig csak a gépeken kapcsolnák ki, a hálózat attól még nem lesz IPv6-mentes: egy új eszköz, egy nyomtató vagy egy vendéglaptop ugyanúgy bekapcsolt IPv6-tal érkezik.
Címtípusok: link-local, egyedi helyi, globális
Az IPv6-cím 128 bites, hexadecimálisan, kettőspontokkal elválasztott csoportokban írják le, és az egymást követő nulla csoportokat egyszer a cím leírásában „::” helyettesítheti. Egy interfésznek egyszerre több címe is lehet, ez az IPv6-ban a megszokott állapot. A címzési architektúrát az IETF RFC 4291 írja le. Ugyanez a szabvány szünteti meg a broadcastot: amit IPv4-ben szórásos üzenet intézett el, azt IPv6-ban csoportcímre (multicast, ff00::/8) küldött üzenetek végzik.
| Címtípus | Előtag | Hatókör | Honnan jön |
|---|---|---|---|
| Link-local | fe80::/10 | Csak az adott szegmens, router nem továbbítja | Minden IPv6-ot futtató interfész magának képzi |
| Egyedi helyi (ULA) | fc00::/7, a gyakorlatban fd00::/8 | A szervezet belső hálózata, az interneten nem útválasztható | Router-hirdetésből vagy DHCPv6-ból, ha valaki beállította |
| Globális egyedi | 2000::/3 | Az interneten is útválasztható | A szolgáltatótól vagy regionális regisztrátortól kapott előtagból |
| Multicast | ff00::/8 | A cím hatókörmezőjétől függ | Szabványos csoportcímek, például ff02::1 (minden csomópont a szegmensen) |
Link-local címek
A link-local cím az, amely mindig jelen van. A gép a hálózati kártya bekapcsolásakor magának képzi, router és kiosztó kiszolgáló nélkül. Ezen zajlik a szomszédok felderítése és a routerekkel való kommunikáció, és ezen keresztül két gép ugyanabban a VLAN-ban akkor is elér egymást, ha IPv6-címet senki nem osztott nekik. Mivel minden interfésznek van fe80-as címe, egy több interfészes gépen a címhez a zónát is meg kell adni (például fe80::1%eth0, IETF RFC 4007). A zónák közötti tűzfal így ezt a forgalmat nem látja, a szegmensen belül viszont szabadon mozog.
Egyedi helyi címek
Az egyedi helyi cím (Unique Local Address, IETF RFC 4193) az IPv4 magáncímtartományainak feleltethető meg. Az előtagja fd-vel kezdődik, utána egy 40 bites, véletlenszerűen választott azonosító jön, ezért két szervezet ULA-tartománya nagy valószínűséggel nem ütközik, ha később össze kell kötni a hálózatukat. Az interneten nem útválasztható, belső szolgáltatásokhoz, laborhoz, elszigetelt szegmensekhez használható.
Globális címek
A globális egyedi cím az interneten is érvényes. Egy telephely jellemzően egy nagyobb előtagot kap, és ezt bontják /64-es alhálózatokra, VLAN-onként egyet. A RIPE közösség BCOP-dokumentuma (RIPE-690, 2017) üzleti előfizetőnek /48-at javasol. Ennél kisebb blokkot, vagyis /56-nál hosszabb előtagot egyetlen előfizetőnek sem ajánl.
Automatikus címkiosztás: SLAAC és DHCPv6
IPv4-ben a gépek jellemzően DHCP-ből kapnak címet, alapértelmezett átjárót és DNS-kiszolgálót. IPv6-ban ez két mechanizmus között oszlik meg, és a kettő együttműködését a router irányítja.
SLAAC
Az állapot nélküli címkonfiguráció (Stateless Address Autoconfiguration, IETF RFC 4862) lényege, hogy a router a szegmensen meghirdeti az előtagot, például egy /64-es alhálózatot, a gép pedig a cím hátsó 64 bitjét, az interfészazonosítót maga képzi hozzá. Mielőtt használni kezdi, ellenőrzi, hogy más nem használja-e már ugyanazt a címet (duplikált cím észlelése, DAD). Bérleti nyilvántartás nincs; azt, hogy melyik cím melyik géphez tartozik, csak a szomszédtáblákból lehet utólag összerakni.
Az interfészazonosító képzésére többféle eljárás létezik. A régebbi megoldás a hálózati kártya MAC-címéből számolta, így a gép bárhol a világon ugyanazzal az azonosítóval jelent meg. Sok mai rendszer alhálózatonként stabil, de a MAC-címből nem visszafejthető azonosítót használ (IETF RFC 7217), és emellett ideiglenes címeket is képez (IETF RFC 8981), amelyeket időnként lecserél, és a kimenő kapcsolatokhoz ezeket használja. Az adatvédelemnek ez jót tesz, a hibakeresésnek és a naplóelemzésnek kevésbé: ugyanaz a gép napközben több címről is forgalmazhat.
DHCPv6
A DHCPv6 (IETF RFC 8415) két üzemmódban működhet. Állapot nélküli módban csak kiegészítő adatokat ad, például DNS-kiszolgálót és keresési tartományt, a címet a gép SLAAC-kal képzi. Állapottartó módban a kiszolgáló osztja ki a címet is, és nyilvántartja, melyik géphez melyik tartozik. Van egy fontos különbség az IPv4-es DHCP-hez képest: a DHCPv6 alapértelmezett átjárót nem ad. Az átjárót a gépek mindig a router-hirdetésből tanulják meg.
Ki dönt a módról
A router-hirdetésben két jelzőbit szól a gépeknek (IETF RFC 4861): az M (managed) bit azt jelzi, hogy a címet DHCPv6-tól kérjék, az O (other) bit azt, hogy a kiegészítő beállításokat onnan vegyék. Az előtag mellett pedig egy jelző mondja meg, hogy a gépek képezhetnek-e belőle SLAAC-címet. A DNS-kiszolgáló a router-hirdetésben is közölhető (RDNSS, IETF RFC 8106), így DHCPv6 nélkül is teljes beállítást kaphat egy gép.
A gyakorlatban a kiszolgálók és a hálózati eszközök általában kézzel beállított, rögzített címet kapnak, a felhasználói gépek SLAAC-ot vagy DHCPv6-ot. A tervezésnél azzal is számolni kell, hogy egyes mobil operációs rendszerek az állapottartó DHCPv6-ot nem támogatják, így egy csak DHCPv6-tal címet osztó szegmensen ezek az eszközök nem kapnak globális IPv6-címet.
Router-hirdetések és a hamis útválasztó
A router-hirdetés (Router Advertisement, RA) a szomszédfelderítő protokoll (Neighbor Discovery, IETF RFC 4861) része. A router időnként és kérésre csoportcímre küldi a szegmensen, és benne szerepel az előtag, az M és O bit, valamint a router élettartama, amely azt is eldönti, hogy a gépek alapértelmezett átjárónak tekintsék-e. A gép a hirdetést alapból hitelesítés nélkül elfogadja.
Mi történik, ha más is hirdet
Bármelyik gép küldhet router-hirdetést a saját szegmensén. Ha egy rosszindulatú vagy egyszerűen rosszul beállított eszköz ezt teszi, a szegmens gépei elfogadják alapértelmezett átjárónak, és ahol a cél IPv6-on is elérhető, a forgalmukat felé küldik. Az IETF RFC 6104 (2011) ezt a problémát a hálózatüzemeltetési tapasztalatokból írja le: a hamis router-hirdetések egy része nem támadásból, hanem félrekonfigurált eszközökből, például internetmegosztást bekapcsolt gépekből ered.
A támadó számára ez átirányítási lehetőség, akkor is, ha a hálózaton IPv6 egyébként nincs használatban. Ha a hamis hirdetés DNS-kiszolgálót is közöl, a gépek névfeloldási kéréseinek egy része hozzá kerül, és a válaszaival a forgalmat olyan helyre terelheti, ahol lehallgathatja vagy módosíthatja. A sima IPv4-es hálózat ezt nem veszi észre, hiszen az IPv4-es átjáró és DHCP rendben működik, a forgalom a másik protokollon terelődik el. A valódi router címével küldött, nulla élettartamú hamis hirdetés arra is jó, hogy a valódi routert kiiktassa a gépek átjárólistájáról.
Védekezés a kapcsolón
A hozzáférési kapcsolókon az RA Guard (IETF RFC 6105) szűri a router-hirdetéseket: csak a router felé néző, megbízhatónak jelölt portokon engedi be őket, a felhasználói portokon eldobja. Az IETF RFC 7113 megvalósítási ajánlása arra figyelmeztet, hogy a hirdetést bővítőfejlécek és darabolás mögé rejtve egyes egyszerűbb szűrők átengedik, ezért a kapcsolónak a teljes fejlécláncot kell vizsgálnia. Ugyanezen az elven működik a DHCPv6-Shield (IETF RFC 7610): a nem megbízható portokon eldobja a DHCPv6-kiszolgálóüzeneteket, vagyis a DHCP snooping kiszolgálóüzenet-szűrő részének felel meg. A szomszédfelderítést hitelesítő SEND protokoll (IETF RFC 3971) régóta létezik, de a gépeken alig támogatott, a gyakorlatban a kapcsolóoldali szűrésre lehet építeni. Az IPv4-es megfelelőkről, a DHCP snoopingról és az ARP-ellenőrzésről a kapcsolók biztonsági funkcióiról szóló cikk ír.
Az RA Guard akkor is hasznos, ha a cég IPv6-ot nem használ. Ilyenkor egyetlen port sem megbízható, és a kapcsoló minden router-hirdetést eldob, így a gépek csak link-local címmel maradnak.
Kettős protokollú hálózat: szabályok mindkét protokollra
A kettős protokollú (dual-stack) hálózatban minden gép IPv4- és IPv6-címet is használ (IETF RFC 4213). Ez a szokásos átmeneti megoldás, és egyben az az állapot, amelyben a biztonsági szabályok a legkönnyebben elcsúsznak egymástól.
Két szabálykészlet, egy szándék
A tűzfalak és a zónák közötti szűrők a két protokollt sokszor külön szabálytáblában vagy külön objektumokkal kezelik. Ha a forgalmi mátrix csak IPv4-címekkel van kitöltve, a zónák közötti tiltás az IPv6-forgalomra nem vonatkozik. Ilyenkor vagy minden IPv6-forgalom átmegy, mert valahol egy általános engedélyező szabály maradt, vagy semmi, és a felhasználók késést tapasztalnak, mert a gépek előbb IPv6-on próbálkoznak, és csak a sikertelen kísérlet után váltanak IPv4-re. Az ellenőrzés kérdése ezért mindig ugyanaz: amit a szabálykészlet IPv4-en tilt, azt IPv6-on is tiltja-e, és amit engedélyez, azt ugyanazokra a forrásokra engedélyezi-e. A zónák közötti forgalom megtervezéséről a forgalmi mátrixról szóló cikk ír részletesebben.
Nincs NAT, ami takarna
IPv4-ben a belső gépek a címfordítás mögött ülnek, és ez mellékesen azt is jelenti, hogy kívülről kezdeményezett kapcsolat alapból nem jut be. IPv6-ban a belső gép globális címe kívülről is címezhető, ezért a határtűzfal alapállapota döntő. Az IETF RFC 6092 előfizetői eszközökre megfogalmazott ajánlása is ezt követi: a kifelé kezdeményezett kapcsolatok válaszai jöhetnek be, a kéretlen bejövő forgalom alapból tiltott. Létezik előtagfordítás (NPTv6, IETF RFC 6296), de kísérleti státuszú, és a szűrést nem helyettesíti.
Az ICMPv6-ot nem lehet egyszerűen tiltani
IPv4-ben sok helyen szokás az ICMP-t nagyrészt eldobni. IPv6-ban ez működési hibát okoz. A routerek útközben nem darabolnak (IETF RFC 8200), a küldő a „Packet Too Big” üzenetekből tudja meg, hogy kisebb csomagot kell küldenie (útvonal-MTU felderítés, IETF RFC 8201). Ha a tűzfal ezt eldobja, a kapcsolatok felépülnek, de nagyobb adatmennyiségnél elakadnak. A szegmensen belül a szomszédfelderítés is ICMPv6-üzenetekből áll. Az IETF RFC 4890 típusonként sorolja fel, melyik ICMPv6-üzenetet ajánlott átengedni, melyiket szabad korlátozni és melyiket ajánlott eldobni.
Alagutak a tűzfalon át
Ahol a hálózat nem ad IPv6-ot, ott egyes gépek alagúttal próbálhatnak IPv6-kapcsolatot szerezni. Az IPv4-be csomagolt IPv6 (6in4, 6to4) a 41-es IP-protokollszámot használja, a Teredo (IETF RFC 4380) UDP-n, a 3544-es porton indul. A 6to4-et az IETF RFC 7526 elavultnak nyilvánította, a Teredo pedig több elterjedt rendszerben alapból ki van kapcsolva, a tűzfalon mégis érdemes kifejezetten tiltani mindkettőt. Az IETF RFC 6169 az alagutak biztonsági kérdéseit foglalja össze: a beágyazott forgalom kikerülheti azokat a szűrőket, amelyek csak a külső fejlécet nézik.
Napló, leltár, felügyelet
A kettős protokoll a láthatóságot is érinti. Egy gép naplóbejegyzésekben, tűzfalnaplókban és a forgalomelemzésben IPv4- és több IPv6-címmel is felbukkanhat, és az ideiglenes címek miatt ezek idővel változnak. A címek és a gépek összerendeléséhez a kapcsolók és routerek szomszédtábláit érdemes rendszeresen begyűjteni, és a naplóelemzésnek mindkét címtípust ugyanahhoz az eszközhöz kell tudnia kötni. Ha a behatolásérzékelő vagy a hálózatfelügyelet csak IPv4-et elemez, az IPv6-forgalom vakfolt marad.
Bevezetés vagy tudatos tiltás
A félig bekapcsolt, tervezetlen állapotból kétféleképpen lehet rendezett állapotba jutni: tudatos tiltással vagy tervezett bevezetéssel.
Tudatos tiltás
Ha a cég egyelőre nem vezet be IPv6-ot, akkor is van teendő, mert a gépek a protokollt továbbra is futtatják:
- a hozzáférési kapcsolókon RA Guard és DHCPv6-Shield;
- a határtűzfalon és a zónák között kifejezett tiltás az IPv6-forgalomra, valamint a 41-es protokollszámra és a Teredo UDP 3544-es portjára;
- a gépeken, ahol a gyártó ezt javasolja, az IPv4 előnyben részesítése a protokoll teljes kikapcsolása helyett;
- a hálózatfelügyeletben riasztás, ha valahol mégis router-hirdetés vagy globális IPv6-cím jelenik meg.
A link-local forgalom a szegmensen belül ilyenkor is megmarad. Ez a VLAN-on belüli mozgás kérdése, amelyet a szegmentáció és a kapcsolók szűrése kezel, ugyanúgy, mint IPv4-ben.
Tervezett bevezetés
A bevezetés címterv készítésével indul. A kapott előtagot a telephelyek és zónák szerint érdemes felosztani, hogy a zóna a címből is látsszon, és a tűzfalszabályok előtagokra épülhessenek. A felosztás logikájáról az IP-címtervről és a VLAN-struktúráról szóló cikk ír. Ezt követi a szabálykészlet: minden IPv4-es zónaszabály IPv6-os párja, az ICMPv6 szükséges típusainak átengedése, a bejövő forgalom alapértelmezett tiltása a határon. Csak ezután jön a hirdetés bekapcsolása, szegmensenként, egy-egy tesztelésre kijelölt VLAN-nal kezdve.
Ahol az IPv4 kivezetése is cél, ott a csak IPv6-os szegmensek az IPv4-es szolgáltatásokat NAT64 és DNS64 (IETF RFC 6146 és RFC 6147) segítségével érhetik el.
Kapcsolódó szolgáltatás: Hálózati szegmentáció →
