arne22

Nei, det er ikke i bruk hjemme hos meg. Det var når jeg kom på hytta, jeg oppdaget at der var det IPv6. Hjemme er det IPv4. Ca 4 uker siden sist jeg var her på hytta.

Ja, det er akkurat det. Av akkurat den grunn så vil det nok gå "utrolig tregt". Det kan nok være at standarder og prinsipper er "teknologiuavhengige" men for en praktisk implementering så må man ta utgangspunkt i "det utstyret som finnes i virkeligheten". "Cyber security for operasjonell teknologi" det var jo noe som man stort sett ikke tenkte på, men plutselig så ble det veldig aktuelt ved at flere industrielle anlegg faktisk ble hacket, med store økonomiske kostnader og tap som resultat. Mye av det gamle "rakleverket" som finnes ute i industrien det lar seg nok sannsynligvis ikke sikre "på normal måte", slik at man endre opp med å "sikre omgivelsene" i større grad enn utstyret selv. Et kjempeinteressant tema. Er ikke kjent med at det finnes noen utdanning i Norge som er spesifikt rettet mot "Cyber Security for OT".

En til off-topic tråd:

Det skjer jo nå en del omlegging fra IPv4 til IPv6, rundt omkring, og det er jo ganske interessant å sette seg inn i hvordan dette fungerer. Ved en tilfeldighet, så oppdaget jeg akkurat nå at jeg hadde fått IPv6 tilkobling til Internett, uten at jeg hadde gjort noe for å få det, det bare plutselig var der, og nei det fungerte ikke slik som jeg trodde. Jeg er på hytta og internetttilkoblingen er trådløs via ICE sitt 4G nett og modemet er en vanlig ganske ny Android mobiltelefon. Når jeg pinger diskusjon.no, vg.no og dagbladet.no så resolver den i alle tilfeller til IPv6 adresser. Når jeg kjører traceroute til de aktuelle målene. så ser det ut som at den kjører IPv6 allerde inne på lokalnettet og helt inn til den aktuelle serveren. myip.dk sier også at jeg er på Internett via en IPv6 adresse. Ipconfig viser at lokal PC (den jeg jobber på nå) har både IPv4 og IPv6 adresse. (Som den har fått fra telefonens DHCP server.) Når jeg pinger eller kjører tracert opp mot min egen server som bare har IPv4 så ser det ut som at den kjører IPv4 allerede fra lokal klient og hele veien fram til server. Konklusjon: Det kan se ut som at både lokal Windows PC, router (mobiltelefon) og hele "kommunikasjonslinjen" fram til server kjører "dual stack". Skulle man kunne forvente eller legge til grunn at det er slik IPv6 på hjemmedatanettverk vil fungere, som "full dual stack" helt fra klient, via LAN og fram til servere? Fant ellers en "testside" som kan sjekke om servere er satt opp for å kjøre IPv6: https://geekflare.com/tools

Kommer tilbake til saken om litt. Gikk akkurat gjennom et par lærebøker og noen masteroppgaver om Cyber Security for Industrielle kontrollnettverk. Vil hente dem fram igjen. Interessant å se om det sies noe om saken.

Dette blir vel noså off-topic i forhold til denne tråden, men ganske interessant. Opprettet en ny tråd i tilfellet det skulle la seg gjøre å få noen til å bli med på den interessante diskusjonen.

Det pågår i dag mye diskusjon omkring overgang fra IPv4 til IPv6 nettverk. Vil man måtte regne med at industrielle kontrollnettverk fortsatt vil fungere ut i fra IPv4 eller er det en sannsynlighet eller en mulighet for at det vil skje en overgang til IPv6? Hva vil dette eventuelt ha å si for sikkerheten i ICS nettverkene? Er den såkalte Perdue modellen fortsatt relevant nå i dag, og vil den være det i framtiden? https://www.zscaler.com/resources/security-terms-glossary/what-is-purdue-model-ics-security Bare en tråd for å samle litt info om dette interessante temaet, i det tilfellet at det også er noen andre som har interesse av dette temaet.

Men nå var det vel Altibox og hjemmenettverk, dette egentlig handlet om?

Har da driftet internettservere i litt over 20 år sammenhengende. Alt sammen på IPv4. Så langt ingen problemer med det som går på nettverk og sikkerhet. Synes nok at det som kjører på IPv4 kjører ganske problemfritt. Har jo forsøkt å holde meg oppdatert gjennom disse 20 årene, men når det sommer til IPv6 så synes jeg ikke at det er så lett å finne kursopplegg som gir noen særlig god oversikt. Jo det kan da godt være at det er noe interessant her 🙂 Når det gjelder det som går det som går på risko og sikkerhet, så har jeg et forholdvis enkelt syn på saken. Det er det som de skriver om i Telenor sin sikkerhetsblogg: https://telenorsoc.blogspot.com/ Det er ikke alle beskrivelser som akkurat går i dybden, men hvis man følger med fortløpende og undersøker litt videre, så ser man jo hva det går i.

Men hr process, du som har greie på ting... Denne tråden handler jo om Altibox som har begynt å brueke CGNAT for noen kunder, og da lurer jeg jo litt på: Er det noe mer som disse kundene kan gjøre med situasjonen, for å få alle tingene til å fungere slik som de ønsker? En løsning det må jo være "fast IP", for da har man jo ikke lengre CGNAT, man har i stedet "god gammel nat". En annen mulighet det skulle jo være å sette opp en VPN tunell med en unik global IP og så portforwarding inn gjennom tunellen, slik at klinenten blir tilgjengelig på Internett fra denne globake IP'en. Jeg er 100% sikker på at dette kan fungeremed manuell portforwarding, for det har jeg satt opp manuelt tidligere. (Tror det var OpenVPV som ble brukt og det tok litt lang tid å finne ut av.) Spørsmålet blir jo da: Finnes det noen tilbydere av VPN tjenster som kan levere en unik global IP i kombinasjon med port forwarding? (Inn til klienten.) Prøvde å google litt og har inntrykk av at tjenesten finnes, men det er vel ikke akkurat sikkert at det blir billigere enn "fast IP". (Og for VPN så er vi vel stadig vekk over i "gammel IPv4")

Ville nok tro at risikoen er vanligvis størst i hjemmedatanettverk og at fo eksempel mange "botnet" kjører mye "hjemmefra". https://www.techtarget.com/searchsecurity/definition/botnet Konsekvensene kan nok bli større i et bedriftsnettverk.

Det har du helt rett i. Pleier bestandig å deaktivsere UPnP. Dette kan jo være aktivsert eller deaktivisert i en NAT router. Det er jo en slags "automatisk portforwarding" som kan fungere med NAT men ikke CGNAT. Synes at UPnP er såpass sikkerhetsmessig uakseptabelt i bruk, at jeg glemte i farta, at det i det hele tatt finnes. Rent sikkerhetsmessig så skal man faktisk ikke se bort i fra at CGNAT faktisk medfører en del fordeler., hvor fraværet av UPnP er en av dem.

Det er vel litt uklart med hva man mener med "å åpne porter". De fleste NAT routere med enkelt oppsett har jo alle porter åpne for trafikk satt opp fra innsiden og ut, og så åpner NAT routern dynamisk for returtrafikken. For trafikk som initiereres fra utsiden, så er det motsatt. NAT-routeren er stengt, og fungerer på et vis som en "enveisventil". I prinsipp så skal dette fungere likt med CGNAT som er hva man kan kalle en "dobbelnat" eller to NAT routere koblet i serie. I praksis aå er det vel slik at i noen sammenhenger, og for visse anvendelser, som for eksempel visse spill, så fungerer det ikke med CGNAT og dynamisk åpning for returtrafikk. Når man abonerer på " en fast ip", så har man jo i utgangspunktet ikke "åpnet for noen flere porter", men man har en "enkeltnat" i stedet for en "dobbelnat" der "mekanismen for automatisk åpning for returtrafikk" fungerer bedre. I prasis så betyr bare "fast ip" i første omgang at "CGNAT mekanismen" er koblet ut. Abonerer man på en fast IP, og så setter opp en "portforwarding", da er man over i noe annet. Da åpner man opp for trafikk som initieres og settes opp fra utsiden. (Og så finnes det automatiske scannere på internett som melder i fra til hackermiljøene at nå er det åpnet en inngående port på ip x.x.x.x port x, nå er det bare å sette i gang å angripe, slik at det å åpne for trafikk initiert fra utsiden ikke er helt ufarlig.) Hvis man bare skal ha den "automatiske mekanismen" får åpning for returtrafikk til å fungere, så åpner man egentlig ingen porter, man bare sørger for en "enkeltnat" som medfører at den automatiske åpningen for returtrafikk fungerer 100%. Slik fungerer det for IPv4 og CGNAT og NAT, men hvordan det tilsvarende fungerer for IPv6, det er ikke så enkelt å ha en helt detaljert oversikt over. Sikkerhetsmessig, så fungerer IPv4 meget bra, og det er egentlig ganske enkelt å konfigurere og ha "full kontroll" på det hele. Appropos spørsmål som var stilt et sted over. Hva kan man bruke en "packet sniffer til"? Man kan for eksempel gå inn i den enkelte "datapakke" og se på om "flaggene" er satt for trafikk initiert fra innsiden, eller det dreier seg om trafikk initiert fra utsiden, eller "spoofede" (forfalskede) pakker fra en hacker som forsøker å komme forbi "mekanismene" for automatisk åpning av returtrafikk i NAT routeren. (Når det dreier seg om IPv4). Hvis man skaffer seg fast ip og åpner for trafikk initiert fra usiden, ved å sette opp "port forwarding" så kan man også bruke packetsnifferen, til å hente ut detaljer omkring hvordan hackerangrepene blir utført, så snart som disse kommer i gang.

Denne tråden handler jo om at Altibox skal ha begynt å levere denne type Internettilkobling. Regner med at jeg vil teste ut en virtuell desktop i løpet av den nærmeste framtid og at det vil fungere både i forhold til "fast IPv4 og fast IPv6." Har egentlig bare bruk for IPv6 for testing og læring, en gang i blant, så løsningen med virtuell desktop bør fungere ok for meg. (Hvis det nå virker da.)

Takker for fenomenalt bra informasjon. Da har vi kanskje løst noe av trådens tema: Hvordan komme i gang med unik IPv4 og unik IPv6 adresse fra en posisjon bak CGNAT? Svar: Man oppretter bare en en virtuel desktop i nettskyen og så konfigurere man dobbelt med IPv4 og IPv6 og så logger man seg på med RDP eller lignende. Alle problemer løst 🙂 (Med mindre man driver med spill eller noe slik som ikke passer for desktop i nettskyen.)

Interessant. Kjente ikke til denne. Ser ut som at man må ha en unik IPV4 adresse, slik at det ikke vil fungere bak CGNAT (?!)

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"?

Testet MIT App Inventor for en tid tilbake. Ble positivt overrasket og fikk laget den appen som jeg hadde bruk for.

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. 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

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å."

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.

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".)

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.

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/

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.