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"

Ecco un'altra sfida per testare le tue abilità wienie po ':

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. Abbastanza facile, giusto? Se non hai provato, la vostra intenzione di scoprire che tcpdump / windump lancia un paio di curve a voi.

Per controllare il tuo lavoro, ecco un file di cattura:

ipv6-icmp

Il file contiene un mix di indirizzi IPv6 di origine. Ovviamente il filtro deve visualizzare solo il campo di indirizzi specificato.

Il vincitore ottiene di ispirare rispetto e ammirazione in meno geek.

Se questa sfida sembrava più difficile di quanto dovrebbe essere, siete sulla strada giusta.

Mi sono imbattuto in questo problema quando si scrive il mio decodifica dei pacchetti strumento. Devo dire, era un esercizio di freddo per me, come non ho mai pensato di creare filtri tcpdump e Wireshark per ogni possibile IP, TCP, UDP e ICMP campo e / o valore. Di gran lunga il campo delle opzioni TCP è il più "spezzata" da una prospettiva di decodifica dei pacchetti rispetto a qualsiasi altro campo IP.

Prima di tutto parliamo di come le opzioni TCP avrebbe dovuto essere attuata. Se si guarda al campo IPv4 opzioni, inizia con un identificatore "Tipo". Se siete interessati a una soluzione IP specifico, è solo una questione di controllare questo campo per la combinazione po 'a destra. Aveva le opzioni TCP stata implementata in questo modo, la sfida sarebbe stata piuttosto semplice.

Quasi tutte le opzioni TCP hanno un "Tipo" e un campo "Lunghezza", che sono entrambi 1 byte di dimensione. Le eccezioni sono "End of Option List" e "No-Operation", che hanno solo un campo Tipo, e quindi sono un byte di dimensione. Ecco una lista delle opzioni comuni TCP:

Pagina 15 di RFC 793 ci dice "L'header TCP (anche uno comprese le opzioni) è un numero intero di 32 bit." In altre parole, la dimensione in byte di intestazione TCP deve essere divisibile per quattro (20 byte, 24 byte, ecc.) Se guardate l'elenco delle opzioni TCP, solo "dimensione massima del segmento" è divisibile per quattro. Quindi l'uso di tutte le altre opzioni stanno andando a richiedere imbottitura.

Come l'imbottitura deve essere applicato è un po 'poco chiara. Se guardiamo alla pagina 26 della RFC 1323 troviamo questo:

  APPENDICE A: SUGGERIMENTI DI ATTUAZIONE

    I layout sono consigliati i seguenti per l'invio di opzioni in materia di non-SYN
    segmenti, per ottenere il massimo allineamento possibile dei 32-bit e 64-bit
    macchine.

        +--------+--------+--------+--------+
        | PON | PON | TSopt | 10 |
        +--------+--------+--------+--------+
        Timestamp TSval | |
        +--------+--------+--------+--------+
        | Timestamp TSecr |
        +--------+--------+--------+--------+ 

Nota l'imbottitura PON appare prima l'opzione timestamp, non alla fine come ci si potrebbe aspettare. Si noti inoltre l'RFC dice espressamente questo è per "non-SYN segmenti" e che è "raccomandato", non richiesto. Sembra tuttavia che la maggior parte dei sistemi operativi seguire questa raccomandazione e sempre luogo imbottitura prima del tipo byte e Lunghezza. Ho controllato Windows, Linux, Mac, hardware vari, ecc e tutti hanno messo l'imbottitura all'inizio.

Così possiamo contare su questo essere "standard", giusto? Non proprio. Pagina 17 di RFC 793 descrive NOP in questo modo:

  Questo codice opzione può essere utilizzata tra le opzioni, ad esempio, per
         allineare l'inizio di una successiva opzione su un confine di parola.
         Non c'è garanzia che il mittente utilizzerà questa opzione, in modo
         ricevitori deve essere preparato a processo opzioni, anche se lo fanno
         Non iniziare su un confine di parola. 

In altre parole, non è solo che NOP può o non può presentarsi all'inizio, NOP non potrebbe essere utilizzato a tutti! E 'del tutto legale per il layout del campo di opzione TCP senza imbottitura PON e basta usare Fine della lista di opzioni come riempitivo alla fine per raggiungere il confine corretta.

Allora cosa facciamo finire con un filtro? Se contiamo sul PON prima l'opzione di cui finisce con un filtro che assomiglia a questo:

tcp [13] e 2 = 2 e tcp [12] e 240> 80 e ((tcp [20] = 1 e tcp [21:02] = 0 × 0303) o (tcp [24] = 1 e tcp [25:2 ] = 0 × 0303) o (tcp [28] = 1 e tcp [29:2] = 0 × 0303) o (tcp [32] = 1 e tcp [33:2] = 0 × 0303) o (tcp [ 36] = 1 e tcp [37:2] = 0 × 0303) o (tcp [40] = 1 e tcp [41:2] = 0 × 0303) o (tcp [44] = 1 e tcp [45:2 ] = 0 × 0303) o (tcp [48] = 1 e tcp [49:2] = 0 × 0303) o (tcp [52] = 1 e tcp [53:2] = 0 × 0303) o (tcp [ 56] = 1 e tcp [57:2] = 0 × 0303))

Per abbattere questo filtro che sta facendo:

• Le operazioni di controllo SYN e SYN / ACK: tcp [13] e 2 = 2
• Header TCP è maggiore di 20 byte (le opzioni sono impostati): tcp [12] e 240> 80
• Verificare il primo byte di ogni confine quattro byte per NOP: tcp [20] = 1, tcp [24 = 1, ...
• Controllare i prossimi due byte per vedere se Tipo = 3 e lunghezza = 3: tcp [21:02] = 0 × 0303, tcp [25:2] = 0 × 0303, ...

Se però vogliamo fare in modo di cogliere tutte le possibilità nel caso in cui un sistema non implementa PON si finisce con:

tcp [13] e 2 = 2 e tcp [12] e 240> 80 e (tcp [20:02] = 0 × 0303 o tcp [21:02] = 0 × 0303 o tcp [22:02] = 0 × 0303 o tcp [23:02] = 0 × 0303 o tcp [24:2] = 0 × 0303 o tcp [25:2] = 0 × 0303 o tcp [26:2] = 0 × 0303 o tcp [27:2] = 0 × 0303 o tcp [28:2] = 0 × 0303 o tcp [29:2] = 0 × 0303 o tcp [30:2] = 0 × 0303 o tcp [31:2] = 0 × 0303 o tcp [32:2] = 0 × 0303 o tcp [33:2] = 0 × 0303 o tcp [34:2] = 0 × 0303 o tcp [35:2] = 0 × 0303 o tcp [36:2] = 0 × 0303 o tcp [37:2] = 0 × 0303 o tcp [38:2] = 0 × 0303 o tcp [39:2] = 0 × 0303 o tcp [40:2] = 0 × 0303 o tcp [ 41:2] = 0 × 0303 o tcp [42,2] = 0 × 0303 o tcp [43:2] = 0 × 0303 o tcp [44:2] = 0 × 0303 o tcp [45:2] = 0 × 0303 o tcp [46:2] = 0 × 0303 o tcp [47:2] = 0 × 0303 o tcp [48,2] = 0 × 0303 o tcp [49:2] = 0 × 0303 o tcp [50 : 2] = 0 × 0303 o tcp [51:2] = 0 × 0303 o tcp [52:2] = 0 × 0303 o tcp [53:2] = 0 × 0303 o tcp [54:2] = 0 × 0303 o tcp [55:2] = 0 × 0303 o tcp [56:2] = 0 × 0303 o tcp [57:2] = 0 × 0303 o tcp [58:2] = 0 × 0303)

La differenza con questo filtro è che stiamo verificando Tipo = 3 e lunghezza = 3 tutto il percorso attraverso il campo di opzioni (come Elisabetta suggerito).

Può uno di questi filtri generare falsi positivi? Assolutamente! Due possibilità:

1. Il valore di Timestamp può corrispondere al modello che stiamo cercando.
2. Il filtro si assume un 40 campo di opzione byte. Potrebbe essere meno con questi valori nel payload.

Quindi, quale filtro dovrebbe utilizzare? Il primo genererà un minor numero di falsi positivi, ma perdere i sistemi che siano conformi RFC ma diversi dalla norma. Il secondo sarà sempre prendere Scala finestra se è stato impostato, ma la probabilità di un falso positivo è più alto.

Ho intenzione di designare Elisabetta come il vincitore della sfida. Pochi altri sono stati altrettanto vicino ma era l'unico ad avere il coraggio di inviare la sua linea di pensiero nei commenti. Ho intenzione di assegnare un secondo premio a Jeff che è venuto su con questa soluzione in parte scherzando:

tcpdump-nn | grep 'wscale'> wscale-matches.txt

Questo non genera un reale acquisizione del pacchetto, ma si potrebbe fare:

tcpdump-nn-X-s 0 | grep 'wscale'> wscale-matches.txt

E quindi eseguire l'uscita attraverso txt2cap per tornare indietro in formato pcap. Egli non ha seguito la sfida in particolare, ma hai devi dare complimenti per pensare fuori dagli schemi come questo risolve tutti i problemi di falsi positivi.

Elizabeth e Jeff, sarò contattarvi sia via e-mail. Complimenti!

Ho avuto un posto filo e quattro le e-mail che sono mooooolto vicino alla risposta giusta. Ecco un ultimo indizio per arrivare si spera gente oltre l'ostacolo finale.

Ho citato il comando utile tshark. Ecco l'output:

C: \ test> tshark-n-r linux-syn.cap T-campi-e tcp.options
02:04:05: b4: 04:02:08:0 a: 2:47:04 a: a8: 00:00:00:00:01:03:03:05

Quindi quello che hai sopra è la sezione TCP opzioni (byte 20 e superiore) del pacchetto di prova. L'opzione Scala finestra è l'ultima opzione nella lista.

So che scrivendo questo filtro non è facile. Infatti è per questo che l'ho trasformato in una sfida. E 'possibile comunque.