Gå til innhold
Trenger du hjelp med internett og nettverk? Still spørsmål her ×

Vil IPv6 være egnet for bruk i Industrielle Kontrollnettverk?


Anbefalte innlegg

4 hours ago, arne22 said:
21 hours ago, barfoo said:

Det er ikke et flagg i IP-headeren.

Liten bagatell, men de var der nå sist jeg kikket etter dem. I tillegg så husker brannmuren trafikken. I følge noe info jeg fant på nett så er dette et problem for IPv6 at datatabellene for IPv6 statefull inspection blir mye større enn for Ipv6.

Quote

A TCP connection between client and server first starts with a three-way handshake to establish the connection. One packet is sent from a client with a SYN (synchronize) flag set in the packet. The server receiving the packet understands that this is an attempt to establish a connection and replies with a packet with the SYN and ACK (acknowledge) flags set. When the client receives this packet, it replies with an ACK to begin communicating over the connection.

https://www.checkpoint.com/cyber-hub/network-security/what-is-firewall/what-is-a-stateful-firewall/

Se også her:

https://www.imperva.com/learn/ddos/syn-flood/

Dette sier nøyaktig det jeg sa. Jeg lenket til og med til Wikipedia, som har en definisjon av statefull firewall. Jeg er klar over hvordan det funker, og det er altså ikke et flagg i headeren som utgjør en statefull firewall. Det fungerer likt på IPv4 og IPv6.

Forøvrig er det jo lett ironisk at du henviser til en tekst om TCP: TCP er TCP er TCP. Uavhengig av om det er over IPv4 eller IPv6.

4 hours ago, arne22 said:

Med "bedre oversikt" så mener jeg rett og slett hvordan det fungerer rent praktisk med å bruke redskaper som NMAP, TCP-view og Wireskark. Da har man mye bedre oversikt over trafikken med IPv4. Med IPv4 så gikk det bra å få til å resolve alle adressene automatisk, slik at jeg kunne se hvor alle ip pakkene hørte hjemme. For IPv6 fikk jeg bare fram disse ganske lange og nokså uleselige adressene.

Herregud. Alle de verktøyene støtter IPv4 og IPv6. At den trafikken du så tilfeldigvis har Reverse DNS definert for IPv4, men ikke for IPv6 er ikke egenskaper ved IPv6 - det er valg som er gjort under oppsettet! Videre er en konsekvens av IPv6 at det er i praksis umulig å scanne hele subnet - et enkelt subnet er så stort at om du scanner IPv4-adresserommet på ett sekund (2^32 adresser) vil det ta deg 130 år å scanne et /64 subnet.

4 hours ago, arne22 said:

Det vil være bedre å diskutere regelverk og teknologi litt i dybden, i stedet for å diskutere person.

Det forutsetter at du er i stand til å ikke komme med underlige påstander femten ganger på rad, til tross for at flere personer forteller deg at du tar feil.

Endret av barfoo
  • Liker 2
Lenke til kommentar
Videoannonse
Annonse
3 hours ago, arne22 said:

Ville tro at den største praktiske forskjellen ligger i at alt fra scanning, til bruk av packet sniffer, resolving av ip adresser, lesing av logger, osv, osv, blir en heldel enklere med "ren IPv4".

Hvorfor tror du det? Hvorfor er logger med IPv6 vanskeligere å lese? Hvorfor er pakkesniffing vanskeligere på IPv6?

  • Liker 1
Lenke til kommentar
barfoo skrev (15 timer siden):

Hvorfor tror du det? Hvorfor er logger med IPv6 vanskeligere å lese? Hvorfor er pakkesniffing vanskeligere på IPv6?

Pakkesniffing kan faktisk være litt mer knotete med IPv6.
Dette fungerer fint med IPv4, men ikke med IPv6:

tcp[tcpflags] & (tcp-syn|tcp-fin) != 0

 

  • Liker 1
Lenke til kommentar
21 hours ago, sk0yern said:

Pakkesniffing kan faktisk være litt mer knotete med IPv6.
Dette fungerer fint med IPv4, men ikke med IPv6:


tcp[tcpflags] & (tcp-syn|tcp-fin) != 0

 

Interessant. Dette er vel et tcpdump fra Linux/Unix? Slik:

# tcpdump -i eth0 "tcp[tcpflags] & (tcp-syn|tcp-fin) != 0"

Dette skulle så liste alle pakker som enten forsøker å åpne eller å lukke en forbindelse. (Med syn eller fin flagg satt.)

Grunnen til at dette ikke fungerer er så vidt jeg kan forstå at headerformatet til IPv6 er forskjellig fra IPv4 slik at ingen av de "syntaks reglene" som sjekker på "tcpflags" vil fungere. De vil bare fungere for IPv4, men ikke for IPv6. Nok et eksempel på at mangt og mye vil være forskjellig for IPv4 og IPv6, når man kommer ned på et detaljnivå.

Har så langt ikke testet, men ser at det skal finnes en tilsvarende kommando til for Windows som heter "windump", som eventuelt kan installeres som "ekstrautstyr".

https://www.winpcap.org/windump/

Det kan se ut som at syntaksen er en del forskjellig fra tcpdump og at man kan sjekke for flagg ved å spesifisere bitnummer i header, for eksempel for IPv4:

windump -i 1 -w mycapture.pcap "tcp[13] & 2 != 0"

Skulle tro at dette skulle kunne modifiseres til å sjekke for flagg i IPv6 trafikk (?!)

Edit:

Googlet litt for fitrering for flagg med tcpdump og Ipv6 (Linux). Ser ut som at dette formatet kan fungere:

"ip6[6]=6 && ip6[53]&4!=0"

Her blir vel prinsippet det samme, å spesifisere bitnummer.

Eksempel: Sjekke om syn flag er satt for TCP-IPv6:

tcpdump -i eth0 "ip6[6]=6 and ip6[40] & 2 != 0"

Får ikke testet ut før jeg får i gang en linuxboks med IPv6. Men dette ser jo også ut til å være litt likt for tcpdump i Linux og windump i Windows (?!)

Endret av arne22
  • Innsiktsfullt 1
Lenke til kommentar

Knotet litt for å få windump opp å kjøre på grunn av feil i syntaks over. Her er en video som gir nødvendig info:

Her en noen kommandoer som skal sjekke for IPv6 trafikk med ulike flagg satt i Windows og i Linux. Har ikke fått sjekket 100% men det gir i alle fall ikke feilmelding.

For IPv6:

For SYN Flag set:
windump -i 1 "ip6[6]=6 and ip6[40] & 2 == 2"
tcpdump -i eth0 "ip6[6]=6 and ip6[40] & 2 == 2"

For ACK Flag set: 
windump -i 1 "ip6[6]=6 and ip6[40] & 2 != 0"
tcpdump -i eth0 "ip6[6]=6 and ip6[40] & 2 != 0"

For FIN flag set:
windump -i 1 "ip6[6]=6 and ip6[40] & 1 == 1"
tcpdump -i eth0 "ip6[6]=6 and ip6[40] & 1 == 1"

Har ikke IPv6 på PC akkurat nå. Hvis det er noen som kan teste, komme med forslag eller eventuelt rette feil, så er det utmerket.

Tilsvarende for IPv4:

For SYN flag set:
windump -i 1 "tcp[13] & 2 == 2"
tcpdump -i eth0 "tcp[13] & 2 == 2"

For ACK flag set:
windump -i 1 "tcp[13] & 2 != 0"
tcpdump -i eth0 "tcp[13] & 2 != 0"

For FIN flag set:
windump -i 1 "tcp[13] & 1 == 1"
tcpdump -i eth0 "tcp[13] & 1 == 1"

Det ser jo ellers ut som at filtreringen for tcpdump (Linux) og windump (windows) nå blir lik, men det blir jo i begge tilfeller litt forskjellig for IPv4 og IPv6.

Edit: Feilene for Windump/IPv4 over skal nå være rettet slik at dette kjører og gir fornuftig output.

Edit:

Har testet litt fram og tilbake med Windump på Windows PC og sammenlignet med litt Wireshark.

Det viser seg at Windump er noe forholdsvis knotete å holde på med, som krever tilpasning av mange tekniske detaljer. Wireshark på den annen side har kjempe god støtte både for IPv4 og IPv6, slik at Wireshark blir mye enklere å jobbe med, hvis man skal ha oversikt over trafikk i nettverket og inn og ut av PC. 

Skal man "plukke ut" IPv6 pakker med FIN flagg satt med Wireshark, så legger man i all enkelhet inn et filter slik:

ipv6 and tcp.flags.fin==1

Vanskelighetsgraden og antallet feilkilder blir jo nesten som dag og nett. Loggen er også mye lettere lesbar for Wireshark.

Det viser seg at det også er mulig å få til "automatisk resolving" av de lange IPv6 adressene, og man kan også se om PC kommuniserer ut med "IPv6 adresse tildelt fra MAC adresse" eller "temporary IPv6 adresse".

https://osqa-ask.wireshark.org/questions/37680/can-wireshark-automatically-resolve-the-ip-address-into-host-names/

Hvis man kombinerer TCP-view med Wireshark og Process Explorer, og kanskje noen dos kommandoer, da har man en ganske god kontrol i forhold til det som skjer på en PC, både hva angår IPv4 og IPv6.

Endret av arne22
Lenke til kommentar
10 hours ago, sk0yern said:

Eksemplene du skriver fungerer hvis man ikke har en eller flere extension headers satt.
Dermed risikerer man at filteret man tror skal fange opp f.eks alle SYN-pakker, faktisk ikke gjør dette.

Takker for tilbakemelding!

"Extension headers" det er vel det man kan kalle for en "konseptuell forskjell" mellom IPv4 og IPv6, altså noe nytt som IPv6 har og som IPv4 ikke har. Forutsetningen for at noe skal være "trygt" det er slik som jeg ser det at man har en full forståelse for den teknologien man holder på med. Når hackeren sitter med den kompetansen som lokal admin ikke har, da er det jo ikke alltid at det går så bra.

Er det vanlig å bruke "Extension headers" ifbm IPv6 traffikk? Vil man for eksempel vanligvis ha det i et vanlig hjemmedatanettverk, eller vil det være mer for "spesielle anvendelser"?

Hva med Wireshark, er det kjent om denne vil ha problemer eller stiller krav i forhold til "extension headers", eller vil fitrene til Wireshark (for SYN-pakker) fungere uavhengig av extension headers? 

Min possisjon i forhold til IPv6 det er nok ikke som "den som kan det", men heller som "den som forsøker å lære litt om det".

Førsteinntrykket er nok at overgangen fra IPv4 til IPv6 er overgang til noe som er "forholdvis enkelt", til noe som er ganske mye mer komplisert, mangfoldig og sammensatt( IPv6), selv om det altså er ganske mange som hevder at IPv6 er "mye enklere enn IPv4". 

Jeg har savnet en god framstilling som kan forklare på en noenlunde enkel og grei måte, hvordan IPv6 fungerer, sånn ut i fra grunnprinsipper og i forhold til "helheten". Synes endelig jeg fant en god framstilling utarbeidet av en privatperson i Bulgaria:

https://www.networkacademy.io/ccna/ipv6/what-is-ipv6

https://www.buymeacoffee.com/networkacademy

Her er også en ressurs for senere bruk. Inneholder ikke egentlig så mye om IPv6, men gir kanskje allikevell litt "helhet og oversikt". (For oss som ikke er godt nok oppdatert.)

* Nettverkskurs

 

 

Endret av arne22
Lenke til kommentar
23 hours ago, arne22 said:

Jeg har savnet en god framstilling som kan forklare på en noenlunde enkel og grei måte, hvordan IPv6 fungerer, sånn ut i fra grunnprinsipper og i forhold til "helheten".

Jeg sitter med en følelse av at det er her det svikter. For IPv4 og IPv6 fungerer på akkurat samme måte - rutere forwarder pakker mellom ulike nettverk. Det er ingen vesentlige forskjeller mellom IPv4 og IPv6 på dette planet. Opprinnelig hadde ikke IPv4 mekanismer som NAT, og adresser var globalt rutbare - akkurat som med IPv6.

Forskjellen er i detaljene. F.eks. at ARP er byttet ut med NDP. Men det er ikke nødvendig å vite for å kunne forklare hvordan IPv6 fungerer konseptuelt.

Forstår du hvordan IPv4 fungerer? Kjenner du til OSI-modellen? Forstår du forskjellen på IP og TCP/UDP?

  • Liker 2
Lenke til kommentar
2 hours ago, barfoo said:

Forstår du hvordan IPv4 fungerer? Kjenner du til OSI-modellen? Forstår du forskjellen på IP og TCP/UDP?

Da vi oppgraderte fra Novell NetWare 4.11 som kjørte IPX, så måtte vi nok sette oss litt inn i det temaet ja.

Jeg har opprettet en ny tråd, der man kan forklare på en enkel og grei måte hvordan IPv4 og IPv6 fungerer, rent praktisk. Når man har på plass en god og lettlest beskrivelse av de to, så kan man sammenligne og se på forskjellene.

 

 

Endret av arne22
Lenke til kommentar

Flott gjennomgang av NSA som dukket opp i går:

Sitat

Security issues associated with an IPv6 implementation will generally surface in networks that are either new to IPv6 or in early phases of the transition. This is because such networks will lack maturity in IPv6 configuration as well as likely lacking experience in IPv6 by the admins.

Organizations running both IPv4 and IPv6 simultaneously will have additional security risks, with further countermeasures needed to mitigate these due to the increased attack surface of having both IPv4 and IPv6, the document warns.

https://www.theregister.com/2023/01/25/nsa_ipv6_guidelines/

Lenke til kommentar
1 hour ago, arne22 said:

Da vi oppgraderte fra Novell NetWare 4.11 som kjørte IPX, så måtte vi nok sette oss litt inn i det temaet ja.

Hvordan er det et svar på det jeg spurte om?

Jeg kunne sikkert svart på mer, men jeg må innrømme at stilen din er ekstremt enerhverende og fremstår som lite konstruktiv.

 

Endret av barfoo
Lenke til kommentar
2 hours ago, barfoo said:

Hvordan er det et svar på det jeg spurte om?

Utfasingen av Novell Netware 4.11 det var vel sånn omtrent 25 år siden, og da konverterte vi fra IPX til TCP/IP. OSI modellen og TCP/IP er jo der man startet den gang. Hva med å formulere gode svar på den nye tråden som er linket opp, slik at vi kan komme litt over mot det litt mer "teknisk faglige"?

Når det gjelder OSI og TCP-IP så skummet jeg raskest gjennom denne websiden, og denne beskrivelsen må vel være god nok?

https://estudie.no/tcp-ip/

Det betyr vel at vi har enten IPv4 eller IPv6 eller IPv4 og IPv4 som layer protokoll 2 i denne TCP/IP modellen. hvis man bruker IPv4, IPv6 eller "dual stack". Enig? 

Endret av arne22
Lenke til kommentar
14 hours ago, arne22 said:

Enig? 

Nei.  Jeg tror du gaper over litt for mye.  Glem nettverk i denne omgang. Du trenger først og fremst et kurs i studieteknikk, slik at du klarer å tilegne det stoffet som blir presentert.

  • Liker 1
  • Hjerte 1
Lenke til kommentar
14 hours ago, arne22 said:

Når det gjelder OSI og TCP-IP så skummet jeg raskest gjennom denne websiden, og denne beskrivelsen må vel være god nok?

https://estudie.no/tcp-ip/

Nettsiden bommer fundamentalt på mange punkter, og viser til ting som ikke har vært tilfelle siden tidlig 90-tall (klassefulle nettverk), og ræler sammen IP og ICMP f.eks. Siden er enkelt og greit hverken korrekt eller oppdatert

14 hours ago, arne22 said:

Det betyr vel at vi har enten IPv4 eller IPv6 eller IPv4 og IPv4 som layer protokoll 2 i denne TCP/IP modellen. hvis man bruker IPv4, IPv6 eller "dual stack". Enig? 

Nei. Å kalle IP lag 2 vil nok veldig mange oppfatte som kontroversielt.

Lenke til kommentar
24 minutes ago, barfoo said:

Nettsiden bommer fundamentalt på mange punkter, og viser til ting som ikke har vært tilfelle siden tidlig 90-tall (klassefulle nettverk), og ræler sammen IP og ICMP f.eks. Siden er enkelt og greit hverken korrekt eller oppdatert

Kan brukes men brukes ikke lengre er vel en riktig formulering, men det endrer jo ikke på den tekniske virkemåten. Har du en bedre referanse som er mer oppdatert og som kan bidra til "sakens opplysning"?

26 minutes ago, barfoo said:

Nei. Å kalle IP lag 2 vil nok veldig mange oppfatte som kontroversielt.

Den gangen jeg brukte noe særlig tid på å lære TCP/IP som var når vi tok protokollen i bruk på lokalnettet for ca 25 år siden, så var "riktig latin" at TCP/IP hadde 4 lag. Problemet med TCP/IP v4, det er jo at det er så enkelt og fungerer så ekstremt bra, at man behøver stort sett ikke å tenke over saken mens årene går. (Så står man der med skjegget i postkassen når IPv6 kommer.)

Jeg har sett at enkelte implementeringer av TCP/IP v4 opererer med en 5 lags modell, og der kan det se ut som at IP adressene havner på lag no 3. Når man snakker om VLAN som fungerer ut i fra layer 2 eller 3 i OSI modellen, vil det ikke da være "praktisk" å bruke en TCP/IP modell, deler inn layer 2 og layer 3 "litt likt" i forhold til OSI modelen?

Har du noe nærmere dokumentasjon, info, opplysninger eller "syn på saken"?

 

Lenke til kommentar
28 minutes ago, arne22 said:

Kan brukes men brukes ikke lengre er vel en riktig formulering, men det endrer jo ikke på den tekniske virkemåten. Har du en bedre referanse som er mer oppdatert og som kan bidra til "sakens opplysning"?

https://datatracker.ietf.org/doc/html/rfc1519

Klassefulle nettverk kan mao ikke brukes lengre, og å nevne det i en lærebok produsert etter år 2000 er vranglære. Måten nettsiden du lenket til behandler IP, IGMP og ICMP er også direkte gal, og har ikke vært korrekt på noe tidspunkt.

Jeg tiltrer forøvrig @bmork sin observasjon.

13 minutes ago, arne22 said:

Det er nok noe av det første man lærer på VG1 ja. Men det ikke så mye om industrielle kontrollnettverk på dette klassetrinnet.

Det har med all respekt å melde ikke resten av dine påstander i denne tråden heller...

Endret av barfoo
  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...