01:29:04.656084 IP 1.2.3.4.55971 > 5.6.7.8.domain: 12337 op6%
[b2&3=0x3233] [13879a] [13365q] [14393n] [16706au][|domain]
01:29:04.656125 IP 1.2.3.4.55971 > 5.6.7.8.domain: 12337 op6%
[b2&3=0x3233] [13879a] [13365q] [14393n] [16706au][|domain]
5.6.7.8 ᅵ ovviamente la destinazione, con "domain" come protocollo
ovvero il dns, ma i numeri sulla destra cosa singnificano?
Un output tradizionale di tcpdump non li mostra ed ᅵ la
prima volta che li vedo.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ᅵ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.
Dalla man page di tcpdump:
UDP Name Server Requests
(N.B.:The following description assumes familiarity with the
Domain Service protocol described in RFC-1035. If you are not
familiar with the protocol, the following description will appear
to be written in greek.)
Name server requests are formatted as
src > dst: id op? flags qtype qclass name (len)
Davide
Giuro, avevo guardato prima di
postare. Lo giuro su di me.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
Vedere questo output non e' normale, per il traffico dns: tcpdump lo
usa quando ci sono anomalie nella decodifica del protocollo dns. op6
sta per "opcode 6", che non e' definito, e b2&3=0x3233 vuol dire che
i byte 2 e 3 hanno valori rispettivamente 32 e 33, quando dovrebbero
essere entrambi 0, in una query. Il significato degli altri campi lo
trovi nella man page (in una sezione che non e' proprio quella a cui
fa riferimento davide) e anche il loro valore e' privo di senso, per
una query dns.
Sembrerebbe traffico non dns in transito sulla 53/udp.
Fabio
Pienamente compatibile con la mia casistica.
Grazie per la "decodifica"
Dimenticavo, nel caso ricapitasse, con eventuali
"-vvv" riuscirei a vedere cosa sta transitando?
O devo usare degli elaboratori piᅵ avanziati tipo
tshark o simili?
A parte che la decodifica dns di tcpdump arriverebbe solo fino alla
verbosita' -vv, dici? :-) Lo escludo. Aumentare la verbosita' serve
ad approfondire la decodifica dei protocolli, ma qui non c'e' nulla
da decodificare.
> O devo usare degli elaboratori piᅵ avanziati tipo
> tshark o simili?
Basta tcpdump con -Xs0, in modo da vedere il contenuto di tutto il
datagramma, che, comunque, non sembrerebbe difficile da indovinare
per una parte non insignificante...
12337 op6% [b2&3=0x3233] [13879a] [13365q] [14393n] [16706au]
id = 12337 = 0x3031
ancount = 13879 = 0x3637
qdcount = 13365 = 0x3435
nscount = 14393 = 0x3839
arcount = 16706 = 0x4142
La stampa di ancount e qdcount e' invertita rispetto all'ordine nel
quale si presentano nell'header dns e i due byte 2 e 3 sappiamo che
hanno valore 0x3233. Quindi sembrerebbe che la parte del datagramma
che dovrebbe corrispondere all'header dns sia:
0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x41 0x42
Cioe', in ASCII:
0 1 2 3 4 5 6 7 8 9 A B
Ora, non sono un mago delle serie e la sfera di cristallo e' oramai
un po' appannata, ma quasi azzarderei che il seguito potrebbe anche
essere...
Fabio.
> La stampa di ancount e qdcount e' invertita rispetto all'ordine nel
> quale si presentano nell'header dns e i due byte 2 e 3 sappiamo che
> hanno valore 0x3233. Quindi sembrerebbe che la parte del datagramma
> che dovrebbe corrispondere all'header dns sia:
>
> 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x41 0x42
>
> Cioe', in ASCII:
>
> 0 1 2 3 4 5 6 7 8 9 A B
>
> Ora, non sono un mago delle serie e la sfera di cristallo e' oramai
> un po' appannata, ma quasi azzarderei che il seguito potrebbe anche
> essere...
Respect.
Come sempre...
--
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/