Benytter Altibox seg av Carrier Grade NAT?

[process]

4 minutes ago, arne22 said:

Nei, det stemmer ikke i det hele tatt. Når man verifiserer at en brannmur er konfigurert rett, så kontrollerer man da selvfølgelig at dette ikke er mulig.

Hva er det som ikke stemmer med mitt utsagn?

Snakker man om verifisering av v6 brannmur gjøres dette på mer eller mindre samme måten, men du kan ikke flytte målstengene slik, det blir bare flåsete. 

[arne22]

3 hours ago, process said:

Det er praktisk talt akkurat de samme regelsettene. 

Regelsettene sier vel ikke så mye. Det er jo bare et abstraksjonslag inn mot brannmurens "operativsystem".

Man behøver også en full dokumentasjon og oversikt over IPV6 pakkenes struktur og oppbygging, akkurat slik som man har det for IPV4 pakkene.

[arne22]

15 minutes ago, process said:

Hva er det som ikke stemmer med mitt utsagn?

Har i alle fall bygd opp og konfigurert nat routere ved hjelp av Linux kernet og IPtables så lenge IPtables har eksistert.

Hvis man bygger opp en nat router slik at den ikke samtidig virker som en brannmur så synes jeg at man gjør noe ganske rart.

Man sjekker selvfølgelig at det ikke er mulig å sette opp trafikk fra utsiden og inn.

I Linux kernel som benytter/inneholder Netfilter, så kjører pakkene gjennom kernel på denne måten og da vil man normalt konfigurere natroutere som også fungerer som brannmurer, som default.

https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.html

(Netfilter fungerer slik at trafikk via NAT må passere gjennom forwarding chain, og dit kommer den ikke uten at det aktivt settes opp forwarding rules. Når input chain holdes stengt så har man ikke tilgang til det. Derfor så fungerer dette default dom en brannmur.) 

Fra 2.2 og tidligere så fungerte dette helt annerledes.

Dette er jo Linux og Netfilter/Iptables, men det er vel ingen grunn til å bruke brannmurer/nat-routere som er dårligere enn det.

Endret 3. januar 2023 av arne22

[sk0yern]

arne22 skrev (17 minutter siden):

Regelsettene sier vel ikke så mye. Det er jo bare et abstraksjonslag inn mot brannmurens "operativsystem".

Man behøver også en full dokumentasjon og oversikt over IPV6 pakkenes struktur og oppbygging, akkurat slik som man har det for IPV4 pakkene.

Det du skriver gir mindre og mindre mening...

[arne22]

10 hours ago, sk0yern said:

Det du skriver gir mindre og mindre mening...

Hvis man går gjennom dokumentasjonen for klassisk TCP/IP basert på IPV4, Netfilter og IPtables, så henger det i alle fall godt nok sammen for Linux verden. Så langt null problemer etter litt over 20 år med Linux servere. Har aldri opplevd noen gang at det har kommet uønsket trafikk gjennom Netfilter firewall. Det er jo sikkerhet på dette nivået som man har, når man bruker denne forholdsvis gamle teknologien. 

Brukte denne boken da jeg i sin tid lærte meg Linux brannmur og Netfilter. Tror boken ble gitt ut i 2001 eller noe slikt. Kontaktet også Robert Ziegler og fikk en godt del hjelp og forklaringer. Og så har det kjørt i litt over 20 år uten problemer av noen art.

https://www.thriftbooks.com/w/linux-firewalls-2nd-edition-landmark_robert-ziegler/1243194/#edition=3710860&idiq=3738863

Skal man skifte over til IPV6, så bør man jo være sikker på at man oppnår et like bra sikkerhetsnivå.

Her er ellers et eksempel på konfigurering av IPV6 for Netfilter, ja det ligner på IPV4 konfigureringen, men som sagt syntaksen for IPV6 konfigurering av Netfilter, gir ingen fullgod forklaring på hva som skjer inne Linux kjernen når man router eller filtrerer IPV6 pakker gjennom kjernen. Det har man kontroll på ved bruk av IPV4.

https://www.linux.com/topic/networking/iptables-rules-ipv6/

Edit:

For Linux Netfilter, som et eksempel på en brannmur, så kan man styre dataflow og filtrering i detalj, enten via IPTABLES grensesnitt for konfigurering eller om man ønsker det så kan man laste ned kildekoden til Netfilter og endre på det man ønsker og så kompilere denne kjernemodulen på nytt. (Gjennom de første årene med Netfilter, så var dette forholdsvis vanlig.) Man har detaljert kontroll, og det har eksistert en omfattende dokumentasjon som går i dybden og som har blitt oppgradert i mer enn 20 år.

https://www.netfilter.org/

Det finnes en forholdsvis enkel og lett forståelig beskrivelse av hvordan IPV4 pakkene er bygd opp, og det er også enkelt å gå inn og kikke på disse pakkene ved hjelp av en packet sniffer som Wireshark eller lignende.

https://www.ipxo.com/blog/ipv4-packet-header/

Her er også litt mer generell info om IPV4 vs IPV6:

https://www.ipxo.com/blog/ipv6-adoption/

https://www.ipxo.com/blog/ipv4-vs-ipv6/

https://www.ipxo.com/blog/common-ipv6-issues/

Uten at man har den samme "i dybden kontroll" og "i dybden dokumentasjon og forståelse" for hvordan "packet traversal" og filtrering skjer på et kernelnivå, så har man jo i praksis ingen god nok sikkerhetsmessig kontroll.

Hvor er den dokumentasjon og hvor er det kursopplegget som beskriver dette på et brukbart nivå for IPV6?

Har for eksempel kikket litt rundt hos Cisco Netacad, og har da et inntrykk av at det fortsatt er IPV4 som er "hovedprinsipp" her også.

Konklusjon: Stiller man høye krav til sikkerhet, så er det fortsatt IPV4 som gjelder, inntil noen har lagt ut linker eller dokumentasjon, eller kursopplegg for hvordan man kan kan ivareta sikkerheten på tilsvarende nivå for IPV6.

(Men her får man jo sånn litt etter hvert uansett en problemstilling rundt "dual-stack" på gateway og kanskje på lokalnettet også.)

Først så må man forstå. Og så kan man bruke.

Det er mange nye problemstillinger: 

https://blog.apnic.net/2019/03/18/common-misconceptions-about-ipv6-security/

Endret 4. januar 2023 av arne22

[process]

10 hours ago, arne22 said:

Har i alle fall bygd opp og konfigurert nat routere ved hjelp av Linux kernet og IPtables så lenge IPtables har eksistert.

Hvis man bygger opp en nat router slik at den ikke samtidig virker som en brannmur så synes jeg at man gjør noe ganske rart.

Man sjekker selvfølgelig at det ikke er mulig å sette opp trafikk fra utsiden og inn.

I Linux kernel som benytter/inneholder Netfilter, så kjører pakkene gjennom kernel på denne måten og da vil man normalt konfigurere natroutere som også fungerer som brannmurer, som default.

https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.html

(Netfilter fungerer slik at trafikk via NAT må passere gjennom forwarding chain, og dit kommer den ikke uten at det aktivt settes opp forwarding rules. Når input chain holdes stengt så har man ikke tilgang til det. Derfor så fungerer dette default dom en brannmur.) 

Fra 2.2 og tidligere så fungerte dette helt annerledes.

Dette er jo Linux og Netfilter/Iptables, men det er vel ingen grunn til å bruke brannmurer/nat-routere som er dårligere enn det.

Jeg snakket om NAT teknologien i seg selv, setter du opp en brannmur har du jo en brannmur, men kan akseptere at noe har gått tapt i kommunikasjonen. 

Uklart hvilken dokumentasjon du mener mangler, har du sett på https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks? Det er samme greia som v4, bare annen family. See også https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families

Default drop og så legger du på input rules etter behov. Nøyaktig på samme måte du ville gjort det på en brannmur når du har et offentlig v4 subnett med flere maskiner på offentlige ip adresser bak. 

Dette er ikke nytt med v6, men om man bare har håndtert nat på v4 er det ikke sikkert det er intuitivt.

[sk0yern]

arne22 skrev (10 timer siden):

Det er mange nye problemstillinger: 

https://blog.apnic.net/2019/03/18/common-misconceptions-about-ipv6-security/

Her finner du vel egentlig svar på flere av tingene du lurer på.

Sitat

There are two big misconceptions about IPv6 security:

IPv6 is more secure than IPv4
IPv6 is less secure than IPv4

Neither are true. Both assume that comparing IPv6 security with IPv4 security is meaningful. It is not.

Sitat

No NAT makes IPv6 insecure

One of the most common misconceptions regarding IPv6 security is that the lack of NAT makes IPv6 less secure. NAT44 is often seen as a security feature in IPv4 networks. The use of public addresses in IPv6 and the restoration of end-to-end connectivity is of great concern to many IPv4 network administrators.

Confusing brokenness with security is a mistake. Firewalls can easily provide equivalent and better protection than NAT without breaking end-to-end connectivity. Ironically, NAT44 and its associated myriad of NAT-traversal techniques have many security issues of their own.

 

[arne22]

2 minutes ago, sk0yern said:

Her finner du vel egentlig svar på flere av tingene du lurer på.

Dette er jo ikke noen "svar". Det er bare en pekepinne for hvordan man kan starte prosessen med å finne svar. Før man har en god nok forståelse for teknologien, så har man ingen sikkerhet.

[process]

 

9 minutes ago, arne22 said:

Dette er jo ikke noen "svar". Det er bare en pekepinne for hvordan man kan starte prosessen med å finne svar. Før man har en god nok forståelse for teknologien, så har man ingen sikkerhet.

Jeg er enig i at man bør forstå teknologien av sikkerhetshensyn men er helt uenig med et blanket statement på at v4 er så mye sikrere.  Det er lett å misforstå kommentarene dine når du skriver at "Før man har en god nok forståelse" at du mener at det er en generell påstand om at v6 ikke er forstått. 

Jeg skjønner nå at det bør være "Før jeg har en god nok forståelse", så god lesning    I utgangspunktet er det bare å tenke v4 konsepter på akkurat samme måte, med untak for adressetildeling og NDP.

Endret 4. januar 2023 av process
La til NDP

[arne22]

15 minutes ago, process said:

Jeg snakket om NAT teknologien i seg selv, setter du opp en brannmur har du jo en brannmur, men kan akseptere at noe har gått tapt i kommunikasjonen. 

Uklart hvilken dokumentasjon du mener mangler, har du sett på https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks? Det er samme greia som v4, bare annen family. See også https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families

Default drop og så legger du på input rules etter behov. Nøyaktig på samme måte du ville gjort det på en brannmur når du har et offentlig v4 subnett med flere maskiner på offentlige ip adresser bak. 

Dette er ikke nytt med v6, men om man bare har håndtert nat på v4 er det ikke sikkert det er intuitivt.

Interessant. Første artikkel om "Netfilter Hooks" ser jo nokså identisk lik ut, i forhold til hvordan tingene fungerte for 20 år siden. (Ser ikke noen forskjeller umiddelbart, hva skulle de eventuelt være?)

Link no 2 gir jo bare en slags overfladisk start på en forklaring. Det er ingen forklaring som går i dybden.

Har kikket litt på dokumentasjonen rundt netfilter/iptables og IPv6 men finner ingen ting som går tilstrekkelig i dybden, til at man kan si at det gir en brukbar teknisk forståelse.

Det man jo kan gjøre det er å sette opp en testlab og så gjennomføre en systematisk uttesting. Det var jo det jeg for min del gjorde da jeg i sin tid tok i bruk Netfilter for IPv4. Ser for meg at en tilsvarende uttesting med IPv6 vil medføre en enorm arbeidsmengde. (På den annen side så har vi jo virtualisering og slikt i dag som kan "rasjonalisere".)

[arne22]

11 minutes ago, process said:

"Før jeg har en god nok forståelse",

Det er nok det som er meningen ja 😀

Tviler egentlig ikke på at de som drifter Internett kan få det til å fungere sikkert nok.

Innenfor spesielle løsninger og nettverk som for eksempel ICS, så har man nok også "mye gammelt og rart" kjørende, som vanskelig lar seg forene med IPv6, slik at man i praksis blir hengende med IPv4 (for bedriftsinterne nett) gjennom mange år framover i tid.

Endret 4. januar 2023 av arne22

[process]

1 hour ago, arne22 said:

Interessant. Første artikkel om "Netfilter Hooks" ser jo nokså identisk lik ut, i forhold til hvordan tingene fungerte for 20 år siden. (Ser ikke noen forskjeller umiddelbart, hva skulle de eventuelt være?)

Link no 2 gir jo bare en slags overfladisk start på en forklaring. Det er ingen forklaring som går i dybden.

Har kikket litt på dokumentasjonen rundt netfilter/iptables og IPv6 men finner ingen ting som går tilstrekkelig i dybden, til at man kan si at det gir en brukbar teknisk forståelse.

Det man jo kan gjøre det er å sette opp en testlab og så gjennomføre en systematisk uttesting. Det var jo det jeg for min del gjorde da jeg i sin tid tok i bruk Netfilter for IPv4. Ser for meg at en tilsvarende uttesting med IPv6 vil medføre en enorm arbeidsmengde. (På den annen side så har vi jo virtualisering og slikt i dag som kan "rasjonalisere".)

Ja, det var lab jeg gjorde selv, men har vært heldig og hatt native IPv6 i snart 15 år. Så har det vært ymse prosjekter oppigjennom hvor jeg har erstattet eller skrevet om brannmursreglene hvor jeg har lært litt til 🙂

Jeg vil påstå at det ikke er et gigantisk prosjekt dersom man har grei nettverkskunnskap, men det er helt klart en bratt læringskurve i starten og noen nye paradigmer - igjen spesielt i forhold til at adressetildeling er stateless (benytter ikke dhcpv6). Det virker mer komplekst enn det er i starten.

Ikke hjulpet av at enkelte ISP har "kreative" implementasjoner selv. 

[process]

1 hour ago, arne22 said:

Det er nok det som er meningen ja 😀

Tviler egentlig ikke på at de som drifter Internett kan få det til å fungere sikkert nok.

Innenfor spesielle løsninger og nettverk som for eksempel ICS, så har man nok også "mye gammelt og rart" kjørende, som vanskelig lar seg forene med IPv6, slik at man i praksis blir hengende med IPv4 (for bedriftsinterne nett) gjennom mange år framover i tid.

Det var kanskje en unødvendig kommentar der fra min side, men greit å klargjøre ettersom vi diskuterer på internett 😅

Sikkert nok blir det aldri, avhengig av hva den størrelsen betyr.

Det er helt klart ikke tilrådelig å kjøre noe annet en dualstack.  Selv k8s fikk dualstack støtte som GA og default først i fjor.  Det er dog noen interessante muligheter med k8s og IPv6 - det er allerede en haug med lagvise sdn som kan skape en del problemer på IPv4 i større miljø.

[arne22]

12 minutes ago, process said:

adressetildeling er stateless

Visste ikke helt hva dette er, men ser det står en liten forklaring her:

https://it.hiof.no/datanettverk/lab/Lab8-2019.html

Mulig man skulle i gang med en IPV6 lab, men har så langt "uffet meg vekk" fra å komme i gang med et. Å åpne en IPv6 pakke i Wireshark for å kikke på den, det høres nesten ut som en form for sjøsyke. (Nei, har aldri prøvd.)

Det er jo midlest talt veldig mye som skal læres på nytt. Kan vanskelig se for meg at fordelene med IPv6 lokalnett vil oppveie de ulempene som følger med med økt kompleksitet, men som man sier: "Ti me vil sjå."

[HawP]

Stateless er vel kort fortalt at klientene selv genererer en "vilkårlig" adresse og bruker NDP (neighbor discovery protocol) til å sjekke om noen andre klienter på samme nett allerede bruker den adressen. Stateless oppsett vil vanligvis også generere nye adresser jevnlig som et "privacy"-tiltak, slik at adressen klienten bruker typisk vil variere over tid.

"Motsatsen" er vel stateful, hvor adressen tildeles fra en dhcpv6. En kan også ha kombinasjonen stateless+stateful, hvor klienten både genererer en adresse og mottar fra dhcpv6. Jeg kjører kombinasjonen, siden mine klienter ikke registrerer sin stateless adresse i dns, så da bruker jeg dhcpv6 til å få den registrert slik at jeg kan nå de med navn.

Nå er ikke jeg noen ekspert på nettverk/nettverksikring, så jeg lurer på hvilken nytte eller læring du sikkerhetsmessig får ved å kikke på en ipv6-pakke i Wireshark, om det er noe vesentlig jeg har gått glipp av?

 

Sitat

Det er jo midlest talt veldig mye som skal læres på nytt. Kan vanskelig se for meg at fordelene med IPv6 lokalnett vil oppveie de ulempene som følger med med økt kompleksitet, men som man sier: "Ti me vil sjå."

Siden du da vil måtte ha 4-til-6 (og evt. 6-til-4) konvertering for kontakt med evt. nettsteder/klienter som har blitt ipv6-only, så er det ikke utenkelig at konfigurering av noe slikt fort kan "ødelegge" fordelen du har ved å unngå den "økte kompleksiteten" med ipv6 lokalt. For jeg ser ikke for meg at en ISP vil gjøre dette for deg.

Og jeg synes at det gjennomgående i de fleste av linkene du har gitt ang. ipv6 og "sikkerhetsutfordringer" dreier seg om at utfordringen først og fremst går på ikke nok kjennskap til/kunnskap om ipv6. Og siden ipv6 høyst sannsynlig uansett vil "komme for fullt" på et tidspunkt, er det vel like greit å "hoppe i det" først som sist?

Endret 4. januar 2023 av HawP

[process]

6 minutes ago, HawP said:

Stateless er vel kort fortalt at klientene selv genererer en "vilkårlig" adresse og bruker NDP (neighbor discovery protocol) til å sjekke om noen andre klienter på samme nett allerede bruker den adressen. Stateless oppsett vil vanligvis også generere nye adresser jevnlig som et "privacy"-tiltak, slik at adressen klienten bruker typisk vil variere over tid.

"Motsatsen" er vel stateful, hvor adressen tildeles fra en dhcpv6. En kan også ha kombinasjonen stateless+stateful, hvor klienten både genererer en adresse og mottar fra dhcpv6. Jeg kjører kombinasjonen, siden mine klienter ikke registrerer sin stateless adresse i dns, så da bruker jeg dhcpv6 til å få den registrert slik at jeg kan nå de med navn.

"Vilkårlig" ja 🙂 En host vil få samme adresse hver gang, privacy extensions er på utgående forbindelser som kommer i tillegg til en forutsigbar en. Akkurat det med dns er noe jeg har køla litt med på IPv6. Endte med å benytte tsig nøkler som kan oppdatere et gitt vertsnavn i bind / dns servere. Uten god automasjon og konfigurasjonsstyring er dette upraktisk, men det har fungert knirkefritt i mange år.

[HawP]

process skrev (36 minutter siden):

"Vilkårlig" ja 🙂 En host vil få samme adresse hver gang, privacy extensions er på utgående forbindelser som kommer i tillegg til en forutsigbar en.

Har ikke sjekket så nøye hvilke adresser som stateless genererer på mine klienter, så jeg vet egentlig ikke om den lager 1 mer eller mindre "fast" og et antall varierende (privacy extensions) eller kun disse varierende. Jeg har bare antatt den faste er "fra stateful" uten å sjekke nærmere.
For dhcpv6-serveren i openwrt bruker by default mac for å "velge" en ip å tildele (hvis jeg ikke husker feil), så kan det være at dersom stateless sin også genereres basert på mac blir den lik dhcp-serveren sin og at jeg derfor ender opp med kun én "fast" og disse varierende (privacy ext.) i tillegg?

Sitat

Akkurat det med dns er noe jeg har køla litt med på IPv6. Endte med å benytte tsig nøkler som kan oppdatere et gitt vertsnavn i bind / dns servere. Uten god automasjon og konfigurasjonsstyring er dette upraktisk, men det har fungert knirkefritt i mange år.

Jeg bruker som nevnt også stateful, og dermed dhcpv6, og har derfor ikke hatt noe problem med dns som jeg kan huske. Men er ikke sikker på om det da er dhcpv6-serveren eller klienten selv som registrerer i dns, antar det er dhcp-serveren ...
Forsøkte aldri noe registrering i dns den korte tida jeg testet med kun stateless.

[arne22]

13 hours ago, HawP said:

Nå er ikke jeg noen ekspert på nettverk/nettverksikring, så jeg lurer på hvilken nytte eller læring du sikkerhetsmessig får ved å kikke på en ipv6-pakke i Wireshark, om det er noe vesentlig jeg har gått glipp av?

Det er da også en ganske interessant problemstilling. 

Når jeg jobber med en problemstilling som har med datakommunikasjon eller sikkerhet å gjøre, for eksempel konfigurering av brannmur eller ved gjennomgang av servere som har blitt "hacket" så vil jeg normalt benytte meg av et antall "tools". En packetsniffer som Wireshark er en av dem, men det er kanskje ikke det viktigste "tool" nå i dag.

Vel så viktig er vel ulike typer prosesseksplorere og trafikkmonitorer, som gjør at man kan se nokså eksakt hva som kjører av trafikk og hvorfor denne trafikken kjører, eller eller hvorfor denne trafikken ikke kjører, hvilken bruker trafikken tilhører, osv enten det er på server, gateway eller klient.

Et annet tool er jo en portscanner og selvfølgelig ulike "tools" til å lese loggene.

Tror det må være "det viktigste".

Packetsnifferen synes jeg fungerer nærmest som et "forstørrelsesglass" for å se nørmere på en eller annen detalj for "kjørende trafikk", som man vanligvis først finner i en annen sammenheng. 

Jeg for min del synes at det er en liten utfordring at mengden av "normal trafikk" har blitt så stor at det kan være vanskelig å filtrere godt nok, slik at man klarer å hente ut de dataene som man ønsker fra en packetsniffer, slik at packetsnifferen kanskje først og fremst var noe som man brukte før i tiden. Den kan da fortsatt være relevant for å se på detaljer.

13 hours ago, HawP said:

Og jeg synes at det gjennomgående i de fleste av linkene du har gitt ang. ipv6 og "sikkerhetsutfordringer" dreier seg om at utfordringen først og fremst går på ikke nok kjennskap til/kunnskap om ipv6. Og siden ipv6 høyst sannsynlig uansett vil "komme for fullt" på et tidspunkt, er det vel like greit å "hoppe i det" først som sist?

Forutsetningen for det må jo være at de tools man benytter for "sjekke trafikk og sikkerhet" fungerer like bra for IPV6 som for IPV4, men gjør de det?

For IPv4 så er det da forholdvis enkelt å skaffe seg en noenlunde "total oversikt" over "hva er det som kjører på serveren?", "hva er det som kjører på gatewayen?" og "hva er det som kjører på klienten?", men hele tiden så dreier det seg jo om "tools" som er basert på IPv4, og hvordan gjør man så dette innefor IPv6?

Ser for meg at det å holde en oversikt over brukere, prosesser og "den kommunikasjon som kjører" må bli utrolig komplisert eller uoversiktelig ved bruk av IPv6 adressering.

Bruken av alls slike tools må jo etableres på nytt og tilpasses IPv6 og egentlig en langt mer "komplisert virklighet".

Bare det å lese loggen etter et angrep på en server, må jo bli til en mye mer komplisert prosess, "hvem er det som angriper", "hvordan skjer angrepet", "ble det oppnådd tilgang til filer", osv, osv, alt dette må da bli mye mer komplisert når man skal forholde seg til IPv6 adressering?! 

I år 2000 så lærte man jo to ting. Det ene var at om noen måneder så kjører all TCP/IP trafikk med IPv6 og så bruker alle Linux som desktop PC. Så langt skjedde det ikke. At fordelene med IPv6 på lokalnett og bedriftinterne nett vil oppveie ulempene i forhold til IPv4, det er jeg nok ikke helt overbvist om.

Hva er det man oppnår ved overgang fra IPv4 til IPv6 for lokalnett, og bedriftsinterne nett, hva er fordelene og ulempene, og hva koster det?

Edit:

Her er det faktisk en liten beskrivelse, vedrørende "security audit for IPv6", men det er jo bare et hint om starten på en utviklingsprosess, og et "spytt i havet" i forhold til det man behøver for et OK sikkerhetsmessig opplegg for IPv6.

https://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch19s03.html

 

Endret 5. januar 2023 av arne22

[process]

13 hours ago, arne22 said:

Forutsetningen for det må jo være at de tools man benytter for "sjekke trafikk og sikkerhet" fungerer like bra for IPV6 som for IPV4, men gjør de det?

Alle de "tools" jeg benytter gjør det helt supert; tcpdump, lsof, ss/netstat, nmap etc.  Benytter ikke andre verktøy for v6 vs v4. Wireshark fungerer også fint. 

13 hours ago, arne22 said:

For IPv4 så er det da forholdvis enkelt å skaffe seg en noenlunde "total oversikt" over "hva er det som kjører på serveren?", "hva er det som kjører på gatewayen?" og "hva er det som kjører på klienten?", men hele tiden så dreier det seg jo om "tools" som er basert på IPv4, og hvordan gjør man så dette innefor IPv6?

Jeg er litt usikker på hvorfor dette er annerledes?  Verktøyene er ikke basert på en adressefamilie, det aller meste har støtte nå.  Av og til må du spesifisere en '-6'

13 hours ago, arne22 said:

Ser for meg at det å holde en oversikt over brukere, prosesser og "den kommunikasjon som kjører" må bli utrolig komplisert eller uoversiktelig ved bruk av IPv6 adressering.

Hvorfor ser du for deg det? Det er bare adresser.  Privacy extentions kan komplisere ting, men i slike miljø ville jeg ikke benyttet det.  Her har du en fordel ved at adressen til en gitt enhet er satt med EUI-64 og vil aldri endre seg som ved v4 og dhcp. 

13 hours ago, arne22 said:

Bruken av alls slike tools må jo etableres på nytt og tilpasses IPv6 og egentlig en langt mer "komplisert virklighet".

Det er langt på vei gjort, det er ingen verktøy jeg kan komme på som ikke har v6 støtte, med mindre du kjører veldig gamle løsninger og da har du andre sikkerhetsproblemer

13 hours ago, arne22 said:

Hva er det man oppnår ved overgang fra IPv4 til IPv6 for lokalnett, og bedriftsinterne nett, hva er fordelene og ulempene, og hva koster det?

Det blir jo nødvendigvis en bedriftsøkonomisk og behovsrettet diskusjon.  For et nett med arbeidstasjoner er v4 tilkobling nødvendig, men rene v6 nett kunne gi langt flere offentlige ip adresser.  I dag er det praktisk talt tomt hos RIR'ene og prisene øker raskt.  v6 er langt billigere. Du får også større rutingtabeller da subnett brytes opp mer og mer.  NAT i seg selv forårsaker også problemer, NAT tabeller vokser, du må benytte 1-1 NAT (ugh), NAT-T skaper problemer etc.   Det å ha en stateful NAT tabell midt i nettverkstrømmene dine er ikke elegant, men jeg skal inrømme at det stort sett fungerer fint (inntil du får gleden av å oppleve en full NAT tabell).

Etterhvert vil enkelte ting bli kun tilgjengelig over v6 - men her regner jeg med at det viktigste vil være dekket av v4 i lang tid fremover.  

På min arbeidsplass, som primært er b2b, drives v6 adopsjon av at våre kunder (fortune 500 og mye telecom) etterspør det.  I store, globale miljøer er v4 problematisk med privatadressering - det er rett og slett ikke nok rfc1918 plass.  Mange av disse selskapene er mer fremtidsrettet og benytter en del tid på R&D, men det er helt klart behov, spesielt innen telco og edge.

Om man ikke ønsker å føre dette på CV'en eller om man jobber i en small/medium business uten globale eller distribuerte systemer er det strengt tatt ikke nødvendig.

Pris, umm… sikkert rundt 5,82.  

13 hours ago, arne22 said:

Her er det faktisk en liten beskrivelse, vedrørende "security audit for IPv6", men det er jo bare et hint om starten på en utviklingsprosess, og et "spytt i havet" i forhold til det man behøver for et OK sikkerhetsmessig opplegg for IPv6.

https://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch19s03.html

Tok en titt på revisjonshistorikken for å se hva som var ment med "currently".  Ser ut som det ble skrevet i 2002, altså rundt den tiden norske universitet begynte å rulle ut wifi…  Nessus har v6 støtte.

Endret 5. januar 2023 av process

[arne22]

10 hours ago, process said:

Alle de "tools" jeg benytter gjør det helt supert; tcpdump, lsof, ss/netstat, nmap etc.  Benytter ikke andre verktøy for v6 vs v4. Wireshark fungerer også fint. 

Her var det jammen mye super interessant informasjon. Mange takk!

Sannheten er jo den at jeg aldri har testet ut IPv6 i noe særlig omfang. Man er jo litt bortskjemt med den gamle IPv4 teknologien som jo egentlig for en stor del er utrolig enkel og robust.

Hva framtiden vil bringe av utvikling, "i det store og det brede" det er det jo bare framtiden selv som vet, men det er jo klart at man bør lære seg den forholdsvis nye IPv6 teknologien (Ny i forhold til utbredelse og "market share").

Synes at det er litt problematisk å finne gode online læringsressurser for en litt mer helhetlig praktisk anvendelse av IPv6. Det har lett for å handle om adressering og grunnleggende egenskaper ved IPv6, og så stanser det der, mens at det gamle rundt IPv4 går i dybden "i alle retninger".

Går ut i fra at det ikke kan ha så mye for seg å sette opp et LAN basert på IPv6, hvis man ikke har tilgang til Internett med IPv6.

Skulle tro at en "farbar vei" er å sette opp et par virtuelle servere og/eller desktop'er i nettskyen, for eksempel MS Azure, og så teste ut på den måten?  (Via RDP eller lignende.)

Da kan man jo ha tilgang til "full IPv6 funkjsonalitet og egenskaper" selv om man rent fysisk befinner seg bak en CGNAT. (Og så får man også dratt dette innlegget inn under rammene av, og faktisk midt i senter av det som denne tråden faktisk skulle handle om, he, he...)

... Men så var det dette med RDP fra IPv4 til IPv6 .. Kanskje det enkleste vil være å sette opp virtuell Windows maskin i nettskyen med to nettverksadaptere, en for IPv4 og RDP og en for IPv6 og all annen internettrafikk??

.. Eller med en "RDP server in the midle", Teamviwer eller lignende, så skulle det vel også fungere med "native IPv4 i den ene enden" og "native Ipv6 i den andre enden"?

Endret 6. januar 2023 av arne22