Haasteena oli: "Kirjoita tcpdump / windump suodatin joka poimii ICMPv6 Multicast Listener paketteja." Minulla on laaja kirjoittaa ylös mitä tekee vastata niin monimutkaisia. Jos tiedät IPv6 ja haluavat vain vastauksen, siirry loppuun.

Ensinnäkin eräät Tausta

Steinar teki muutamia kommentteja edelliseen virkaa ja oli 100% raiteilleen. Jos luet niitä ja ajattelin "Vau, se kuulostaa todella sotkuinen", ymmärrät ongelman laajuutta samoin.

Pöytäkirja Vs. Seuraava ylätunnistekenttien

IPv4: n kanssa meillä oli vaihtoehtoja kenttään. Tämä voi aiheuttaa IP-otsikko kasvavan 20 tavua yhtä suuri kuin 60 tavua. IPv6 ei ole enää vaihtoehtoja kenttä ja otsikko on vahvistettu 40 tavua. Kun vaihtoehdot ovat tarpeen, käytämme laajennus otsikot tunnistamisessa. Tämä heittää mielenkiintoinen käyrä pallo meille koska IPv4 protokollan kenttä (byte 9) olisi (melkein) aina tunnistaa ylemmän tason liikenteen (TCP, UDP, jne.). Kanssa IPv6 seuraavaan otsikkoon kenttään (tavu 6) voitaisiin nimetä ylempi kerros kuljetus, tai se saattaa tunnistaa laajennus otsikko, joka sisältää joitakin useita vaihtoehtoja.

Tässä lista muutamista IPv6 laajennus otsikot saatat törmätä sekä RFC jotka määrittävät heille:

IPv6 ei määrää rajoitetaan laajennus otsikoita voit käyttää yhden packet.There on kuitenkin julkaistu "suositeltava", miten otsikoita olisi vahvistettava ulos. Järjestys on:

• IPv6 Header
• Hop-by-Hop Options
• Reititys Header
• Fragment Header
• AH
• ESP
• Destination Options
• Mobility Header
• TCP/UDP/ICMPv6

Huomautus Tämä luettelo on "suositeltava" mutta ei pakollista. IPv6 isäntä on pystyttävä käsittelemään otsikot mitä ikinä jotta ne on saatu. Tämä tarkoittaa, huomaat todennäköisesti toimittajat seuraavat tässä luettelossa mutta ei hyökkääjät. Olen henkilökohtaisesti nähnyt laitteita alkaa käyttäytyä todella outoa, kun sotku otsikon järjestyksessä. Itse olen törmännyt aika vähän "IPv6-yhteensopiva koodi", jota ei käsitellä, jos haluttuun järjestykseen ei käytetä.

Chasing pöytäkirja Header

Joten IPv6 voimme olla useita otsikoita takana IPv6 header. Jos tämä kuulostaa uusi käsite, se ei oikeastaan ​​ole. Itse olet luultavasti tehnyt sen kanssa jo. Kun IPSeciä kaksi mahdollista suojausprotokollia ovat ESP ja AH. Nämä olivat todella lainattu IPv6 ja hierotaan työskennellä IPv4. Sekä AH ja ESP sisältyy seuraavaan otsikkoon kentän tunnistaa millaista paketin ne protecting.This kutsutaan pöytäkirjan ketjuttamalla kun tosiasiassa useita otsikoita istuu takana Layer 3 protokollaa otsikkoa.

Joten selvittää, mitä ylemmälle tasolle kuljetus (TCP, UDP, jne.) on käytössä, saatat joutua etsiä useita otsikoita ennen kuin löydät vastauksen. Tämä kutsutaan "jahtaavat header", ja tcpdump / Windump meille suodin tähän tehtävään. Saatat olla fimiliar kanssa proto suodatin. Vuonna IPv4 maailmassa, jos sanon:

IP proto tcp

Tämä suodatin lukee "check tavu 9 IPv4 otsikon ja jos arvo on 6 (protokolla vastinetta TCP), ottelun paketti". Tämä suodatin ei ole yhtä tehokas IPv6 maailmassa tietenkin koska tavun 6 IPv6 header voisi tunnistaa ylemmän kerroksen liikennettä, tai se voi vain tunnistaa Valinnainen laajennettu otsikko, jota käytetään. Tämän ongelman ratkaisemiseksi, protochain suodatin otettiin käyttöön. Kirjoittaminen:

ip6 protochain tcp

Kuuluu "Check tavu 6 IPv6 header nähdä, jos arvo on yhtä kuin 6. Jos sen sijaan löytää arvo, joka tunnistaa Valinnainen laajennettu otsikko, tarkista laajennus otsikon seuraava otsikko-kenttään arvo 6. Jos löydät valinnainen laajennettu otsikot, toistamaan viimeisen testin kunnes löydät viimeinen laajennus otsikon ".

Melko helppo kirjoittaa Englanti, mutta tämä on painajainen toteuttaa koodia. Useimmat valinnainen laajennettu otsikot vaihteleva pituus, joka vain lisää monimutkaisuutta. Olen tehnyt joitakin kokeita Scapy ja voit itse nähdä ero suorituskyvyssä, kun protochain saa vedota. Itse voisit ehkä tehdä melko hyvää työtä annostelun IDS / IPS pakottamalla sitä prosessia paljon hyödytön laajennus otsikot.

Kirjoitamme myös suodatin

Niinpä meidän ensimmäinen ongelma kirjallisesti haaste suodatin on, että ICMPv6 otsikko ei välttämättä näy heti IPv6 header. Meidän täytyy varoa Valinnainen laajennettu otsikot. Itse RFC 2710 todetaan: "Kaikki MLD viestejä tässä asiakirjassa lähetetään kanssa paikallisesti linkitetty IPv6-Source Address, IPv6 Hop raja on 1, ja IPv6-reitittimen Alert vaihtoehto [RTR-alert] in Hop-by-Hop Vaihtoehdot header. "Tämä tarkoittaa meidän multicast kuuntelija paketti vaaditaan Hop-by-Hop laajennus otsikon reitittimen Alert vaihtoehto asetettu. Tässä mielessä, ensimmäinen tarkastus olisi:

ip6 protochain icmp6

Varmistaa, että olemme vain katsot ICMPv6 paketteja. Nyt on vain kysymys tarkistaa, onko tyyppi kentän (tavu 0) on asetettu 130 (Multicast Listener Query) tai 131 (Multicast Listener Report). Tämä tuo meidät toiseen ongelmaan kuitenkaan. Vuonna IPv4 maailmassa voin tehdä:

ICMP [0] = <Kirjoita arvo interest>

Jos yritän tätä icmp6 saan:

[Root @ Fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 ylemmän kerroksen protokolla ei tue proto [x]

Toisin sanoen, en voi käyttää vastikkeiden kanssa icmp6 etsiä tiettyjä arvoja. Windump ja tcpdump mainostetaan IPv6-yhteensopivia, mutta älä odota saada kaikki samat toiminnot sinulla on IPv4: n kanssa. Yäk!

Joten mitä me teemme? Meidän täytyy turvautua viitataan arvon ip6 offset. Toisin sanoen meidän täytyy mitata läpi IPv6 header kautta vaaditut Hop-by-Hop header, ja osaksi ICMPv6 otsikon nähdä, jos kenttä ei ole asetettu 130 tai 131. Jotkut asiat otettava huomioon:

• IPv6 header on vahvistettu 40 tavua
• Hop-by-Hop otsikko vaihtelee, mutta 4 tavua reititin Alert asetettu
• Kenttä ei ole tavu 0 sisällä ICMPv6 header

Joten tässä on mitä päädymme:

ip6 protochain icmp6 ja (ip6 [44] = 130 tai ip6 [44] = 131)

Vau! Olemme vihdoin sain sen! Tai emmehän?

K: Mitä tapahtuu, jos paketti on ylimääräinen pääte otsikot?

: Meidän suodatin ei toimi.

Kysymys: Entä jos Hop-by-Hop header on enemmän vaihtoehtoja, kuin reititin Alert?

: Meidän suodatin ei toimi.

Kysymys: Voimmeko korjata edellä kaksi ongelmaa?

: Vasta tcpdump / Windump suodatus lisää IF / sitten silmukka tukea.

Joten jos haluamme kaapata normaali ML liikenne, edellä suodatin toimii hienosti. Jos kuitenkin haluamme vakuuttaa olemme kiinni hyökkääjän trickiness samoin, suodatin ei aio lentää.

Mitä jos yritämme jotenkin näin:

tcpdump-nn-s 1500-x ip6 protochain icmp6 | grep-i multicast> multicast.txt

ja sitten vain käyttää Wireshark n text2cap työkalu muuntaa sen libpcap muotoon? Ongelmana tässä on saamme vasta header tiedot. Grep täsmää yhteenvetorivillä joka sisältää sanan "Multicast" Mutta sitten ohittaa kaikki Hex sen alla, joka on todellinen paketin sisällön.

Joten lopullinen vastaus on: "ei voi saada theya mistä Haya"

Entä jos todella täytyy pystyä näkemään tätä liikennettä? Kunnes tuki IPv6 kypsyy, vain 100% tapa on napata kaikki ICMPv6 liikenne ja sitten manuaalisesti lajitella sen.

Ainakin se on minun käsitys. Jos joku voi todella keksiä 100% käyttöliuos, haluaisin kuulla sen.

OK, tässä vihje kohta sinua oikeaan suuntaan.

Haasteena oli: "Kirjoita tcpdump / windump suodatin joka poimii ICMPv6 Multicast Listener paketteja."

Kuulostaa helpolta, eikö?

Hieman apua Google huomaat, että "tyyppi" multicast-kuuntelija on 130, ja ICMPv6 kenttä ei ole ensimmäinen tavu otsikossa. Joten tämä on näin helppoa:

tcpdump-nn-p-v-s 0 icmp6 [0] = 130

Kuitenkin jos suoritat komennon saat takaisin:

tcpdump: IPv6 ylemmän kerroksen protokolla ei tue proto [x]

Toisin sanoen, voit käyttää "icmp6" nähdä kaikki ICMPv6 paketteja, mutta et voi käyttää sitä suodattaa millään ICMPv6 otsikkokentät.

Joten tarvitsemme "Plan B". Selvittää suunnitelma B ja olet ratkaissut haaste.

Pohjalta IPv6 haasteen viime kerralla, minulla on uusi sinulle: Kirjoita tcpdump / windump suodatin, joka vangitsee ICMPv6 Multicast Listener paketteja.

Siinä kaikki! Melko helppoa, eikö?

No sen nyt torstai niin olen tajunnut sen aikaa lähettää vastauksia viime viikonlopun haaste.

Ensinnäkin, miksi sinun pitäisi edes välitä IPv6 jos et ole aloittanut käyttöönottaminen? Tunsin paljon samalla tavalla kunnes löysin IPv6 käytetään peiteltynä viestintäkanavana sisällä asiakkaan verkkoon. Aineisto sitten työnnetty ulos Internetiin Teredo. Jos et ole perehtynyt tekniikka, Scott Hogg on joitakin erinomaisia ​​viestiä aiheesta.

Joten vaikka et tällä hetkellä käytä IPv6, kannattaa aloittaa leikkaamalla parantaa olevasta tekniikasta sekä katsomassa sen lähiverkossa.

Joten tarkistaa, haaste oli:

Kirjoita tcpdump tai Windump suodatinta, joka tallentaa kaiken liikenteen kanssa lähde IPv6-osoite 2001: DB8:: 10 kautta 2001: DB8:: 20.

On olemassa pari varoituksista kanssa kirjallisesti tätä suodatinta. Ensimmäiset I käsitellään viimeiseen viestiin. Lopulliseksi, jonka tiesin mutta koskaan ajatellut oli ongelma kunnes aloin työskennellä IPv6 melko raskaasti, että tcpdump / Windump vain voit käyttää 1, 2 tai 4 tavun maskeja. Joten vaikka me haluamme ratkaista tämän kanssa aluksi suodatin ilmoitus "ip6 [08:14] =", emme voi, koska olemme vain 4 tavua. On itse asiassa tapa kiertää tätä, mutta tulen takaisin se.

Joten tässä on suodattimen olen työskennellyt:

(Ip6 [08:04] = 0x20010db8 ja ip6 [12:04] = 0 ja ip6 [16:4] = 0 ja (ip6 [20:4]> = 0 × 0010 ja ip6 [20:4] <= 0050 ))

Hieman pitkä, mutta se toimii. Elizabeth keksi ratkaisun, joka on paljon enemmän tyylikäs kuin omani:

src net 2001: DB8:: / 122 ja ip6 [23]> = 0 × 10 & & ip6 [23] <= 0 × 20

Joten aloittamalla libpcap muodossa, hän pystyy yhdistämään ensimmäinen kolme lausumaa yhdeksi. Ei kokoa kuningatar, mutta joka tekee hänen ratkaisu on paljon lyhyempi kuin minun. Tässä tapauksessa se on hyvä asia.

Se siitä. Laitan toiseen IPv6 tyyppinen haaste huomenna.

Vau, ääni sirkat on korvia huumaava. Varmasti joku on taitoja saada meidät läpi tämän ongelman?

OK, joitakin vinkkejä saada sinut läpi haaste. Aloitetaan ratkaisemaan tätä IPv4-osoite ja sitten meidän täytyy harjoitella tietämme IPv6. Oletetaan osoitealue haluamme kaapata on 192.168.1.10 - 192.168.1.20. Suuri ongelma on IP eivät ole edes tavu rajan. Voisimme tehdä jotain:

src net 192.168.1.0/27

mutta se antaisi meille osoitteet 0.0-0.31, enemmän IP kuin meillä todella olisi halunnut nähdä. Tämän ongelman ratkaisemiseksi meidän täytyy käyttää joidenkin operaattoreiden ja perusalkioiden. Yksi mahdollisuus on:

(Ip [12] = 192 ja ip [13] = 168 ja ip [14] = 1 ja (ip [15]> = 10 ja ip [15] <= 20))

Alkaen sisempi eniten suluissa edellä esitetyt lukee "tavu 15 on oltava suurempi tai yhtä suuri kuin 10, mutta se myös on oltava pienempi tai yhtä suuri kuin 20. Jos tämä väite oikein, varmista, tavu 12 on yhtä kuin 192, tavu 13 on yhtä kuin 168 ja tavu 14 on 1. "

Voimmeko lyhentää tätä ilmaisua? Ehdottomasti! Ensin meidän täytyy muuntaa se Hex kuitenkin. Miksi Hex? Jos kirjoitan esimerkiksi maininnalla "ip [12:02] =" tcpdump olettaa, että tulos on 16-bittinen numero, ei kaksi 8-bittistä numeroa. Siksi voit kirjoittaa jotain "tcp [02:02] = 12345" ja saa sen toimimaan. tcpdump muuntaa kaksi tavua osaksi 16-bittinen arvo ja vastaa sitä arvoa vastaan ​​olet määrittänyt. Muuntamalla Hex vältämme tämän ongelman. Joten:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Nyt yksinkertaisesti kirjoittaa lauseke:

ip [12:04]> = 0xC0A8010A ja ip [12:04] <= 0xC0A80120

Tämä kaikki on sitä.

Vaikka IPv4 käyttää 4 byte osoitteet, IPv6 käyttää 16 tavua. Koska osoitteet ovat niin pitkiä, me kirjoitamme ne Hex säästää tilaa. Joten osoitteet annoin sinulle haaste olivat:

2001:0 DB8: 0000:0000:0000:0000:0000:0010

2001:0 DB8: 0000:0000:0000:0000:0000:0020

Huomaa etten aluksi kirjoittaa ne sellaisina. Löytyy muutama yleissopimusten voit säästää tilaa, kun kirjoitat IPv6-osoite. Ensinnäkin voimme katkaista johtava nollia. Joten:

2001:0 DB8: 0000:0000:0000:0000:0000:0010

tulee:

2001: DB8: 0000:0000:0000:0000:0000:10

Nyt, katso kaikki nollaa keskellä? Voimme pilkkoa niitä liikaa. Kun näet "::" se tarkoittaa täyttää tuo tila, jossa on tarpeeksi nollia laajentaa osoitteeseen takaisin ulos 16 tavua. Joten Lisää tässä temppu niin hyvin ja saamme:

2001: DB8:: 10

Paljon helpompi kirjoittaa. Toteamus on, voit vain poistaa yhden ryhmän nollat ​​kaksinkertainen kaksoispiste temppu. Mieti seuraavaan osoitteeseen:

2001:: 1234:: 10

Meillä ei ole aavistustakaan mihin paikkaan tavu peräkkäin "1234" osoite. Se alkaa missä tahansa tavun 6 kautta tavu 12.

Työskenneltäessä IPv4, tcpdump ja Windump käyttää pöytäkirjaa Hakusanalla "ip", kuten käy ilmi edellä mainitut esimerkit. IPv6 kohteliaisuus, että on "ip6". Missä lähde osoitekentän IPv6 header? No en voi antaa teille kaikille siellä vastauksia tai sitä ei enää "haaste"