Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Security en IPv6 over IPv4 tunnels

 

Computable Expert

Martijn Bellaard
Lead Architect, TriOpSys. Expert van Computable voor het topic Security.

Tijdens het ontwerpen van IPv6 hebben ze nagedacht over hoe je IPv6 zou kunnen transporteren over een IPv4 netwerk. De verwachting was namelijk dat we IPv6 zou gaan gebruiken terwijl er nog netwerken op IPv4 zitten, maar hoe veilig zijn deze tunnels nu eigenlijk?

Om IPv6 over IPv4 te transporteren hebben ze een aantal tunnel protocollen bedacht. Dit zijn tunnel protocollen die automatisch een tunnel maken vanaf een IPv6/IPv4 host naar een IPv6 router of host. Je kunt hierbij denken aan protocollen zoals 6to4, Isatap en Teredo. Het is hartstikke mooi dat deze tunnels automatisch gemaakt worden, maar daarin zit nu juist een security risico. Zijn deze tunnel technieken geactiveerd op een server of werkstation, dan loop je het risico dat er automatisch een tunnel gemaakt wordt naar een router op internet. Als je Firewall IPv6 niet snapt en het gewoon doorlaat heb je dus een groot security gat.

Iemand vanaf het internet kan nu zo een connectie maken naar een server of werkstation. Het is dan zelfs mogelijk om deze server of werkstation in te zetten als router en op die manier het gehele interne netwerk bloot te stellen aan het internet. De meeste moderne operating systems hebben deze tunnels geactiveerd. Dus zonder dat je iets doet maak je gebruik van een deze tunnels.

In een6to4 test met wat collega’s zag ik dat al snel 50 procent van alle providers een 6to4 router hebben. Deze test kun je zelf ook doen door te pingen naar 192.88.99. Krijg je een reactie dan kun je een 6to4 server bereiken. Beschik je over een publiek IPv4 adres, dan kan je computer een 6to4 tunnel 'spontaan' gaan opzetten.

De noodzaak voor deze technieken is erg discutabel, het is verstandiger om ze uit te zetten op een server. Alleen als het niet mogelijk is om IPv6 native te routeren kun je gaan werken met deze technieken.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5005714). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Hoi Martijn,

Het eigenlijke probleem ligt toch bij de Firewall die IPv6 nog niet snapt? Dus in plaats van vanalles uit te zetten kun je toch beter zorgen dat de Firewal up to date is? Of zie ik dat verkeerd?

6to4 verkeer gebruikt IPv4 protocol 41. Als je firewall dit zonder reden doorlaat zou ik de firewall beheerder uitzetten in plaats van 6to4 op de server.

Als security expert had ik iets meer diepgang verwacht dan dit artikel. Het advies om het maar uit te zetten brengt ons niet dichter bij de massive adoption van ipv6.
Zo zijn er verschillende aspecten qua security als je naar de tunnel methoden kijkt.
Zo staat Teredo te boek als onveilig maar de andere in mindere mate.

Hoi Martijn,

Kort artikel, maar de kern geef je weer in je laatste alinea. Je moet dit helemaal niet willen. Alleen op die plekken waar het niet kan zou je ipv4 over ipv6 willen tunnelen, maar niet andersom.

@Willem, het artikel is meer een melding of constatering dan een wens om een lang verhaal te schrijven.
Ik hoop dat er wat meer reacties loskomen, IP6 lijkt een beetje een doodgeboren kindje met als voornaamste reden dat niemand werkelijk de moeite neemt om uit te zoeken wat IP6 nu werkelijk inhoud en welke consequenties dit met zich mee brengt.
Daar zit het voornaamste gevaar in... vergelijkbaar met het inzetten van allerlij technieken, die je middels drie muisklikken aan de gang hebt maar waarvoor relevante kennis verder ontbreekt.
De gevolgen daarvan lezen we vrijwel dagelijks op diverse websites.

Pascal: Precies!

Het IPv6 levert namelijk niets op vanuit (eind)gebruikers perspectief en is daarbij wel complex om goed te begrijpen.

Daarnaast lijkt IPv6 op SEPA door die lange IBAN nummers. IP 4 adressen kun je makkelijk onthouden en pingen, met IPv6 moet je kopieren en plakken. Met IP4 kun je makkelijk instellen wat "binnen" en "buiten" is, IPv6 lijkt alles "buiten".

Daarnaast ontbreken ook heldere websites over hoe en wat van IPv6. Het lijkt alsof de mensen met kennis, zij deze voor zichzelf houden.

Ook in mijn "clouds" ben ik voornamelijk met IP4 bezig, er is ook geen noodzaak vooralsnog om dit anders te doen.

Henri,

IPv6 levert wel iets op als je geen publiek adres meer krijgt. Denk aan Afrika en andere toekomstige internet gebruikers. Of vindt jij dat ons "westerse" recht?

Als je kennis hebt van IPv6 dan zijn IPv6 adressen logisch opgebouwd in logische blokken.
namelijk een routing prefix, subnet id en interface identifier. Dat is dus 1 extra blok tov een ipv4 adres. Wat binnen of buiten is wordt net zoals bij ipv6 door het subnet id bepaald.

Als je op zoek bent naar websites over IPv6 nou ik ken er wel een paar:
Gratis en voor niks.

@ Ripe net https://www.ripe.net/lir-services/training/material
@ Nist net http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf

Kortom je argumenten raken nog kant nog wal en jet lijkt alsof je uitspraken en feiten probeert neer te leggen zonder dat je echt kennis hebt van zaken.

Waar ik me aan irriteer is de grote bedrijven die vroeger, voordat de NAT technologie gemeengoed was, enorme IPv4 blokken hebben gekregen.
Kijk b.v. naar ons Nederlandse Philips, die hebben als begin 130.138.0.1 en als eind 130.147.255.255 in hun bezit. Dat zijn 10 X 255 X 255 publieke adressen = 650250 adressen. Ik vind dat bedrijven hun huidige publics moeten verantwoorden. Voortschrijdend inzicht ondermijnd namelijk de rechten van de uitgiftes die gedaan zijn in het verleden.



victoire22, dank voor de links. Ik heb me inderdaad niet dieper in IPv6 verdiept omdat ik mijn aandacht moet verdelen en IPv6 nu eenmaal nog steeds geen noodzaak is.

"IPv6 levert wel iets op als je geen publiek adres meer krijgt. Denk aan Afrika en andere toekomstige internet gebruikers. Of vindt jij dat ons "westerse" recht? "

Dit is een verkeerde redenatie. Wat levert het me functioneel op? NAT is namelijk ook een oplossing en zolang alle mijn apparaten werken, waarom zou ik me dan druk om IPv6 maken? (even vanuit een gebruiker geredeneerd)

Dat je Afrika erbij trekt slaat in mijn ogen dus weer nergens op.

Goed dat je irriteert en ik ben er mee eens dat in tijden van schaarste opnieuw gekeken moet worden naar de verdeling en de rechtvaardiging daarvan, maar uiteindelijk is het niet "fout" dat Philips deze blokken heeft, dus vind ik wel dat je iets te idealistisch bent en daarnaast, al geeft bijvoorbeeld Philips de blokken vrij, dan is het probleem niet van de baan en alleen maar uitgesteld.

Dus nogmaals IPv6 boeit in feite niemand zolang je devices het maar doen en dat verklaard dus alles.

Er zijn uiteraard wel partijen die het WEL interesseert en dat is omdat ze er geld aan kunnen verdienen (uitrol, security, et cetera)

Afrika heb ik alleen genoemd om een potentieel gebied aan te duiden waar nu een lage internet dekking is, maar dit had ook een ander gebied kunnen zijn vandaar de opmerking "andere toekomstige internet gebruikers". Om internet te kunnen routeren heb je nu eenmaal een publiek adres nodig. Het laatst klasse A blok is in gebruik genomen.
Daarna valt er NIETS meet uit de delen behalve ipv6.

Als je denkt dat IPv6 een drive is voor ICT providers om er geld aan te kunnen verdienen denk ik dat de motivatie ook evengoed andersom kan zijn.

Opkomende gebieden hebben dus alleen maar de mogelijkheid het internet te benaderen op basis van IPv6 als IPv4 vergeven is. ALs jij dan met je cloudjes wil vasthouden aan ipv4 dan denk ik dat je klanten niet blij zullen zijn met de misgelopen inkomsten doordat je de ipv6 gebieden niet verstaat. Ik denk dat je baas of je klanten je wel gaan dwingen de zaken met ipv6 te koppelen als de belangen groot genoeg zijn.


@Ripe NCC : http://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-receives-final-8-of-ipv4-address-space-from-iana

Ik vind het te makkelijk ipv6 af te schilderen als iets wat niet noodzakelijk is. Juist om bovengenoemde redenen.

NAT is niet de oplossing want aan NAT kleven veel nadelen.
(B.V. Uitgaande Source adressen worden bv gebind op 1 ip adres met een theoretische limiet van 64K - 32K = 32K source ports op bv windows, dat is voor thuis geen probleem maar voor MKB bedrijven al vaak wel)
http://ipv6.com/articles/nat/NAT-Pros-and-Cons.htm

Philips is maar als voorbeeld gesteld. Dit geldt ook voor IBM, HP etc als deze partijen hun blokken rechtvaardig herverdelen weet ik zeker dat we er veel klasse A blokken voor terug krijgen en we veel langer vooruit kunnen.

victorie22 :

"NAT is niet de oplossing want aan NAT kleven veel nadelen."

Ah, zou je NAT kunnen vervangen door HTML ? :-) Dat iets niet ideaal is betekent niet dat het niet gebruikt gaat worden. Betamax was ook veel beter dan VHS.

Ook je argument over cloud en IP4 is in mijn ogen niet terecht. Uiteindelijk communiceer je van buiten met een cloud dmv URL's en de buitenkant van je cloud kan prima IPv6 praten, aan de binnenkant zijn good old IP4 in mijn ogen nog goed genoeg. Ik ga ervan uit dat als IPv6 noodzakelijk wordt, en let op het woordje ALS, het omarmen daarvan gefaciiteerd wordt door mijn cloud provider zodat een transitie / migratie geen pijn doet.

Ik zie de mooie kanten van IPv6 best, maar de drive om erin nu te investeren ontbreekt en daarin zit de crux waardoor de adoptie traag gaat.


Tja dan heb je dus een tunnel en zijn we weer terug bij het begin van de discussie ;-). Een tunnel verhoogt het veiligheidsrisico. Een dual stack oplossing zou dan beter zijn. Je kan dan native ipv4 blijven gebruiken maar ook native ipv6 verstaan.

Dual IP stack implementation

Dual-stack (or native dual-stack) refers to side-by-side implementation of IPv4 and IPv6. That is, both protocols run on the same network infrastructure, and there's no need to encapsulate IPv6 inside IPv4 (using tunneling) or vice-versa. Dual-stack is defined in RFC 4213.[43]

Although this is the most desirable IPv6 implementation, as it avoids the complexities and pitfalls of tunneling (such as security, increased latency, management overhead, and a reduced PMTU),[44] it is not always possible, since outdated network equipment may not support IPv6. A good example is cable TV-based internet access. In modern cable TV networks, the core of the HFC network (such as large core routers) is likely to support IPv6. However, other network equipment (such as a CMTS) or customer equipment (like cable modems) may require software updates or hardware upgrades to support IPv6. This means cable network operators must resort to tunneling until the backbone equipment supports native dual-stack.

Victorie22, bedankt voor je goede input en links, ik heb ze meegenomen.

Echter heb ik het niet over tunnels maar over een scheiding. De wereld praat tegen mijn webservers, de webserver praat met de interne (database) servers. Daar komt geen tunnel aan te pas. Het is niet zo dat een IPv6 client verder komt dan de webserver.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×