[PLUTO-security] Log preoccupanti

[Fabio Panigatti]

Ho sentito un fremito nella Forza...

> Pero' mi suonano strani quei log di pacchetti RST con ID=0 (quelli del
> post originale), se non ricordo male windows non mette ID=0 ai pacchetti
> RST. Non e' che alla micro$oft ci siano dei server linux :-))) (ricordo 
> che l'host incriminato e' rad.msn.com)

Be', una volta sicuramente c'erano dei server freebsd :-)

C'e' qualche altro stack tcp/ip che risponde con ID=0 (Netware?) ma
nessuno di casa microsoft AFAIK. In ogni caso i linux che resettano
con ID=0 settano anche il flag DF, mentre l'host incriminato non lo
fa. E sicuramente non e' neanche un windows di qualche tipo: notare
che i reset sollecitati da pacchetti _direttamente_ indirizzati non
hanno SEQ=ACK, una caratteristica peculiare (quasi) degli stack del
mondo nt/2k/xp. Inoltre, la variabilita' degli IPID che emergono da
quell'host e' notevole e non e' certo da windows. C'e' qualcosa che
li randomizza. Anche la finestra tcp delle risposte di questo host,
benche' non sia molto significativa fuori dai SYN, e' inusuale, sia
per quello che si vede dai log, sia per quello che si vede tastando
l'ip.

Facendo diverse richieste http successive si nota, sia dagli header
http, sia dai contenuti delle risposte, che rispondono macchine con
nomi, configurazioni ed orologi (zone geografiche?) diverse.

Accendiamo la sfera di cristallo? Accendiamola...

D'ora in poi 207.68.178.238 sara' chiamato "lo scatolo".

Io penso che 207.68.178.238, con ogni probabilita', sia uno scatolo
coloratissimo della $BIGFIRM da [tanti] KEuro che esegue qualche OS
proprietario. Lo scatolo, probabilmente, come gia' detto da qualcun
altro, fa da load balancer per un qualche cluster di server web che
serve pagine di advertisement legate al mondo microsoft. Non e' poi
detto che 207.68.178.238 sia lo scatolo itself ma piuttosto che sia
una destinazione virtuale, gestita dal vero scatolo: notare che sia
scatolo, sia l'hop "precedente" sono alla stessa distanza apparente
da noi, se guardiamo gli handshake di chiusura ed apertura ed i RST
(che vengono quasi sicuramente da lui, non dai server alle spalle).
Lo scatolo media le sessioni tcp/ip con i veri server e li protegge
dall'acher cattivo che vuole fare i sinflud, ecc (spippolando anche
gli IPID, gia' che c'e'). Come puo' essere che i server del cluster
rispondan tutti quanti con lo stesso TTL? Una possibile risposta e'
il nome dell'hop prima dello scatolo, che dal mio punto di vista e'
"vlan813.tuk-6nf-4a.ntwk.msn.net": potrebbe esserci una vlan che fa
si che tutti gli host che vi appartengono compiano lo stesso numero
di hop tra loro e lo scatolo medesimo. Peccato che i TTL risultanti
siano un po' inusuali. Boh. Magari hanno, banalmente, riconfigurato
i TTL dei server web windows secondo le loro esigenze. Dall'analoga
analisi di 65.54.194.118, un altro ip che risponde in round robin a
rad.msn.com, i risultati son coerenti: distanza apparente di 13 hop
e ttl della sessione 115 (+13=128). Ma i TTL di queste macchine son
poco affidabili: notare che i SYN e i RST hanno TTL intorno al 243,
mentre il numero di hop che si attraversa e' 17 ;-) (farebbe un TTL
iniziale pari a 259... ovviamente impossibile) [1]. Sinceramente mi
sfuggono i meccanismi di routing e ridondanza ad alto livello, come
quelli che, probabilmente, sono implementati in casi come questi, e
quindi non potrei dire altro che un mucchio di stupidaggini. Ora e'
da considerare che, in fondo, _tutto_ quanto detto, potrebbe essere
un gran mucchio di stupidaggini: dare il peso opportuno al delirio.
Dopo tutto, non potete sapere se e, soprattutto, che cosa ho fumato
nell'ultimo quarto d'ora...


Fabio

[1] tutte cifre relative al mio "punto di vista" sulla rete; rifare
    i calcoli per il porprio punto di osservazione, nel caso.

PS:
    mi stavo dimenticando dell'ultima predizione! Leggendo il fondo
    del caffe, poco fa, ho intuito che i RST con ID=0 del primo log
    potrebbero essere emessi da qualche sistema che cerca d'evitare
    che rimangano sessioni tcp pendenti e le resetta. Detto sistema
    potrebbe essere in qualsiasi punto lungo il percorso, e/o avere
    un suo personalissimo ttl con cui sputare il suo traffico ip. E
    in ogni caso, capita con una certa frequenza che nei RST emessi
    da uno stack tcp/ip ci siano valori di TTL diversi dalla norma,
    quindi potrebbe essere lo stesso scatolo che resetta, ma con un
    diverso TTL (vedi pure linux). Tra l'altro, non sono inusuali i
    RST quando non si riceve un ACK ad un FIN, indipendetemente dal
    fatto che ci sia o meno un sistema aggiuntivo che implementi un
    simile accorgimento di chiusura delle sessioni. Qui la cosa che
    mi sembra strana e' il timeout tra le ritrasmisisoni ed il RST,
    che mi sembra un po' troppo breve.

PS1:
    FIN ritrasmessi sono frequenti quando ci sono configurazioni di
    questo tipo: server dietro load balancer che fanno nat e che si
    trovano a rispondere a richieste di host a loro volta nattati e
    con un sacco d'altre amenita' intermedie che si prendon l'onere
    di mediare e normalizzare le sessioni TCP tra i due. Ci sarebbe
    da chiedersi, piuttosto, come possano funzionare "quasi" sempre
    bene :-) Per avere altre info, metti sec o logsurfer in ascolto
    sui log di netfilter e fagli fare un netstat+iptstate quando ci
    sono delle ritrasmissioni di FIN, cosi' si puo' conoscere quale
    fosse lo stato delle sessioni tcp in quel momento. Occorre dare
    una occhiata anche al bridge, magari invocando un "iptstate -s"
    via ssh sempre pilotato da sec. Tutto quanto solo per la pura e
    semplice curiosita' di saper cosa succede, ovviamente: non c'e'
    nulla di preoccupante (IMHO) in quel traffico.