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à:
- Il valore di Timestamp può corrispondere al modello che stiamo cercando.
- 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!
