La sfida è stata: "Scrivere un tcpdump / windump filtro che cattura pacchetti ICMPv6 Multicast Listener." Ho un ampio scrivere su ciò che rende la risposta così complessa. Se conosci IPv6 e vogliono solo la risposta, andare alla fine.

In primo luogo, alcuni di fondo

Steinar fatto alcuni commenti al post precedenti ed è stata del 100% in pista. Se le leggi e pensato "Wow, che suona davvero disordinato", si capisce la portata del problema pure.

Protocollo vs. Intestazione campo successivo

Con IPv4 abbiamo avuto il campo delle opzioni. Ciò potrebbe causare l'intestazione IP di crescere da 20 byte a grande come 60 byte di dimensione. Con IPv6, non c'è più un campo di opzioni e l'intestazione è di 40 byte di dimensione. Quando le opzioni sono necessari, usiamo le intestazioni di estensione per identificarli. Questo getta una palla interessante curva a noi perché con il campo protocollo IPv4 (byte 9) sarebbe (quasi) sempre identificare il trasporto di livello superiore (TCP, UDP, ecc.) Con IPv6 il campo di intestazione successivo (byte 6) potrebbe identificare il trasporto strato superiore, o potrebbe identificare un'intestazione di estensione che includerà un certo numero di opzioni.

Ecco un elenco di alcune intestazioni di estensione IPv6 si potrebbe incorrere in, così come la RFC che li definiscono:

IPv6 non limita il numero di intestazioni di estensione è possibile utilizzare in un packet.There singolo pubblicato è comunque un "ordine consigliato" di come le intestazioni dovrebbe essere steso. L'ordine è il seguente:

• IPv6 Header
• Hop-by-Hop Options
• Routing Header
• Fragment Header
• AH
• ESP
• Opzioni di destinazione
• Mobilità Header
• TCP/UDP/ICMPv6

Nota che questa lista è "raccomandato", ma non obbligatorio. Un host IPv6 deve essere in grado di elaborare le intestazioni in quello che mai nell'ordine in cui sono state ricevute. Questo significa che probabilmente troverete fornitori seguendo questa lista, ma non gli aggressori. Ho visto personalmente i dispositivi cominciare ad agire veramente strano quando si fa confusione con l'ordine di intestazione. In realtà ho imbattuto in un bel po 'di "codice IPv6 compatibile" che non può trattare se l'ordine preferito non viene utilizzato.

Chasing L'intestazione protocollo

Così, con IPv6 possiamo avere più intestazioni dietro l'intestazione IPv6. Se questo suona come un nuovo concetto, non è in realtà. In realtà probabilmente avete già lavorato con lui. Quando si distribuisce IPSec i due protocolli di sicurezza possibili sono ESP e AH. Questi sono stati effettivamente presi in prestito da IPv6 e massaggiato per lavorare su IPv4. Sia AH ed ESP comprende un campo accanto intestazione per identificare il tipo di pacchetto sono protecting.This viene indicato come concatenamento protocollo, come effettivamente hanno più intestazioni seduto dietro l'intestazione di livello 3 del protocollo.

Quindi, per capire cosa di trasporto di livello superiore (TCP, UDP, ecc) è in uso, potrebbe essere necessario cercare attraverso più intestazioni prima di trovare la risposta. Questo è denominato "inseguire l'intestazione" e tcpdump / windump ci danno un'opzione di filtro per eseguire questa operazione. Si può essere fimiliar con il filtro proto. Nel mondo IPv4, se dico:

ip proto tcp

Che filtrano legge "controllo byte 9 dell'intestazione IPv4 e se il valore è pari a 6 (valore protocollo TCP), incontro sul pacchetto". Questo filtro non è così efficace nel mondo IPv6, naturalmente, perché byte 6 dell'intestazione IPv6 potrebbe identificare il trasporto strato superiore, o potrebbe semplicemente identificare un header opzionale estensione che viene utilizzato. Per risolvere questo problema, il filtro protochain è stato introdotto. Di scrittura:

ip6 protochain tcp

Legge come "Verifica byte 6 dell'intestazione IPv6 per vedere se il valore è uguale a 6. Se invece si trova un valore che identifica un'intestazione opzionale estensione, verificare campo successivo colpo di testa l'intestazione di estensione per un valore di 6. Se si trova più intestazioni di estensione opzionale, continua a ripetere l'ultimo test fino a trovare l'intestazione ultima estensione ".

Abbastanza semplice da scrivere in inglese, ma questo è un incubo per implementare nel codice. Intestazioni di estensione più opzionali sono di lunghezza variabile che aggiunge solo per la complessità. Ho fatto alcuni test con Scapy e si può effettivamente vedere la differenza di prestazioni quando protochain viene invocato. In realtà probabilmente si potrebbe fare un buon lavoro di dosaggio un IDS / IPS, costringendola a processo un sacco di intestazioni di estensione inutile.

Scrittura nostro filtro

Quindi il nostro primo problema per iscritto il filtro sfida è che l'intestazione ICMPv6 potrebbero non apparire subito dopo l'header IPv6. Dobbiamo guardare fuori per le intestazioni di estensione opzionale. Infatti RFC 2710 afferma: "Tutti i messaggi MLD descritte in questo documento vengono inviati con un indirizzo link-local Fonte IPv6, un limite hop IPv6 pari a 1, e una opzione IPv6 Router Alert [RTR-ALERT] in un hop-by-hop Opzioni intestazione. "Questo significa il nostro pacchetto ascoltatore multicast è necessario per avere un hop-by-hop extension header con l'opzione router Alert. Con questo in mente, il nostro primo controllo deve essere:

ip6 protochain icmp6

Per garantire che stiamo solo guardando ICMPv6 pacchetti. Ora è solo una questione di controllo per vedere se il campo di tipo (byte 0) è impostato su 130 (Multicast Listener query) o 131 (Multicast Listener Report). Questo ci porta al nostro secondo problema però. Nel mondo IPv4 che posso fare un:

icmp [0] = valore <tipo di interest>

Se provo questo con icmp6 ottengo:

[Root @ fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 protocollo dello strato superiore non è supportata dal proto [x]

In altre parole, non posso utilizzare gli offset con icmp6 per la ricerca di valori specifici. Windump e tcpdump sono pubblicizzati come IPv6 compatibili, ma non aspettatevi di ottenere le stesse funzionalità che hai con IPv4. YUCK!

Allora cosa facciamo? Dovremo ripiegare su riferimento al valore da un ip6 offset. In altre parole, dovremo misurare attraverso l'intestazione IPv6, attraverso la richiesta Hop-by-Hop intestazione, e nell'intestazione ICMPv6 per vedere se il campo tipo è impostato su 130 o 131. Alcune cose da tenere in considerazione:

• Header IPv6 è fissata a 40 byte di dimensione
• Hop-by-Hop intestazione è variabile, ma 4 byte con Router Alert set
• Il campo tipo è 0 byte all'interno dell'intestazione ICMPv6

Ecco quello che finisce con:

ip6 protochain icmp6 e (ip6 [44] = 130 o ip6 [44] = 131)

Caspita! Abbiamo finalmente capito! O abbiamo fatto?

D: Cosa succede se il pacchetto ha intestazioni di estensione aggiuntiva?

R: Il nostro filtro non funziona.

D: Cosa succede se il hop-by-Hop testata ha più possibilità di impostare Router Alert?

R: Il nostro filtro non funziona.

D: Possiamo risolvere questi due problemi?

R: Non fino a tcpdump / windump filtraggio aggiunge IF / THEN supporto del ciclo.

Quindi, se vogliamo catturare il traffico normale ML, il filtro sopra funziona bene. Se però vogliamo assicurare prendiamo accorgimenti attaccante così, il filtro non sta per volare.

Che cosa succede se proviamo qualcosa di simile:

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

e poi basta utilizzare lo strumento text2cap Wireshark per convertirlo in formato libpcap? Il problema qui è che sarà solo ottenere le informazioni di intestazione. Grep corrisponderà la linea di sintesi che contiene la parola "multicast", ma poi saltare tutte le Hex sotto di essa che è il contenuto effettivo del pacchetto.

Quindi la risposta finale è: "Impossibile ottenere theya da haya"

Che importa se si ha realmente bisogno per poter vedere questo traffico? Fino a quando il supporto per IPv6 matura, l'unico metodo 100% è quello di catturare tutto il traffico ICMPv6 e poi ordinare manualmente attraverso di essa.

Almeno questa è la mia opinione su questo. Se qualcuno può effettivamente trovare una soluzione di lavoro al 100%, mi piacerebbe sentire.

OK, ecco un suggerimento per indicarvi la giusta direzione.

La sfida è stata: "Scrivere un tcpdump / windump filtro che cattura pacchetti ICMPv6 Multicast Listener".

Sembra facile, vero?

Con un piccolo aiuto da parte di Google vi accorgerete che il "tipo" per il Multicast Listener è di 130, e il campo di tipo ICMPv6 è il primo byte nell'intestazione. Quindi questo dovrebbe essere facile come:

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

tuttavia se si esegue il comando potrà tornare indietro:

tcpdump: IPv6 protocollo dello strato superiore non è supportata dal proto [x]

In altre parole, è possibile utilizzare "icmp6" per vedere tutti i pacchetti ICMPv6, ma non è possibile utilizzare per filtrare su uno dei campi di intestazione ICMPv6.

Quindi abbiamo bisogno di un "piano B". Capire piano B e hai risolto il problema.

Costruire la sfida IPv6 da ultima volta, ho uno nuovo per voi: Scrivere un tcpdump / windump filtro che cattura pacchetti ICMPv6 Multicast Listener.

Questo è tutto! Abbastanza facile, giusto?

Bene ora il suo Giovedi così ho pensato il suo tempo per inviare le risposte alle sfide dello scorso weekend.

In primo luogo, perché dovrebbe anche preoccuparsi IPv6 se non hai iniziato a distribuirlo? Ho sentito più o meno allo stesso modo fino a che ho trovato IPv6 viene utilizzato come canale di comunicazione nascosto all'interno della rete di un cliente. I dati sono stati poi essere spinto fuori a Internet tramite Teredo. Se non si ha familiarità con la tecnica, Scott Hogg ha alcuni post eccellente sull'argomento.

Quindi, anche se non si sta utilizzando IPv6, vale la pena di iniziare a tagliare la cura sulla tecnologia e guardare per esso sulla vostra rete locale.

Quindi, per esame, la sfida è stata:

Scrivi un filtro tcpdump o windump che catturerà tutto il traffico con un indirizzo di origine IPv6 del 2001: db8:: da 10 a 2001: db8:: 20.

Ci sono un paio di avvertimenti con la scrittura di questo filtro. I primi coperto nel post precedente. Quello finale, che io sapevo ma mai veramente pensato fosse un problema finchè ho iniziato a lavorare con IPv6 abbastanza pesante, è che tcpdump / windump solo consente di utilizzare 1, 2 o 4 byte maschere. Così, mentre ci piacerebbe risolvere questo problema con una prima presa di filtro "ip6 [8:14] =", non possiamo perché siamo limitati a 4 byte. Vi è infatti un modo per aggirare il problema, ma tornerò ad esso.

Quindi ecco il filtro che ho lavorato con:

(Ip6 [08:04] = 0x20010db8 e ip6 [00:04] = 0 e ip6 [16:04] = 0 e (ip6 [20:04]> = 0 × 0010 e ip6 [20:04] <= 0050 ))

Po 'lungo, ma funziona. Elisabetta si avvicinò con una soluzione che è molto più elegante di mio:

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

Questo cominciando con il formato libpcap, lei è in grado di coniugare i miei primi tre affermazioni in una sola. Di non essere una regina dimensioni, ma che la rende la soluzione è molto più breve del mio. In questo caso che è una buona cosa.

Questo è tutto. Io postare un altro tipo di sfida IPv6 domani.

Wow, il suono dei grilli è assordante. Sicuramente qualcuno ha le competenze per ottenere attraverso questo dilemma?

OK, alcuni consigli per ottenere attraverso la sfida. Cominciamo con la soluzione di questo come un indirizzo IPv4 e poi lavoreremo nostra strada verso IPv6. Assumere l'intervallo di indirizzi che vogliamo catturare è 192.168.1.10 - 192.168.1.20. Il grosso problema è la IP non sono su un confine ancora byte. Potremmo fare qualcosa di simile:

src net 192.168.1.0/27

ma che ci darebbe indirizzi ,0-0,31, più indirizzi IP di quello che effettivamente volevamo vedere. Per risolvere questo problema abbiamo bisogno di utilizzare alcuni operatori e primitive. Una possibilità è:

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

A partire dalla parentesi più interna, la dichiarazione di cui sopra si legge "byte 15 deve essere maggiore o uguale a 10, ma anche deve essere inferiore o uguale a 20. Se questa affermazione è vera, assicurarsi byte 12 è pari a 192, byte 13 è pari a 168 byte e 14 è uguale a 1. "

Possiamo ridurre questa espressione? Assolutamente! Prima di tutto dobbiamo convertirlo in Hex comunque. Perché Hex? Se scrivo una frase come "ip [00:02] =" tcpdump si assume che il risultato sarà un numero a 16 bit, non due numeri a 8 bit. È per questo che si può scrivere qualcosa del tipo "tcp [2:2] = 12345" e farli funzionare. tcpdump converte i due byte in un valore a 16 bit e lo confronta con il valore specificato. Con la conversione in esadecimale abbiamo evitare questo problema. Così:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Ora dobbiamo semplicemente scrivere la nostra espressione:

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

Questo è tutto quello che c'è da fare.

Mentre IPv4 utilizza 4 byte indirizzi, IPv6 utilizza 16 byte. Perché gli indirizzi sono così lunghi, che scriveremo in esadecimale per risparmiare spazio. Così gli indirizzi che ti ho dato nella sfida sono stati:

2001:0 db8: 0000:0000:0000:0000:0000:0010

2001:0 db8: 0000:0000:0000:0000:0000:0020

Si noti che inizialmente non li scrivono in quel modo. Ci sono alcune convenzioni è possibile utilizzare per risparmiare spazio quando si scrive un indirizzo IPv6. In primo luogo, siamo in grado di troncare zeri iniziali. Così:

2001:0 db8: 0000:0000:0000:0000:0000:0010

diventa:

2001: db8: 0000:0000:0000:0000:0000:10

Ora, vedere tutti quei zeri in mezzo? Possiamo tagliare troppo. Quando si vede "::" che vuol dire riempire quello spazio con zeri a sufficienza per espandere l'indirizzo di nuovo fuori a 16 byte. Quindi, aggiungere in questo trucco, come bene e otteniamo:

2001: DB8:: 10

Molto più facile da scrivere. L'avvertenza è che si può rimuovere solo un gruppo di zeri con il trucco di due punti. Si consideri il seguente indirizzo:

2001:: 1234:: 10

Non abbiamo idea di dove posizionare la sequenza di byte "1234" nell'indirizzo. Avviarlo dovunque da byte da 6 a 12 byte.

Quando si lavora con IPv4, tcpdump e windump utilizzare la parola chiave protocollo "ip", come mostrato negli esempi precedenti. Il complimento IPv6 che è "ip6". Dov'è il campo dell'indirizzo di origine nell'intestazione IPv6? Beh io non posso darti tutto quello che c'è risposte o non è più una "sfida"