Traffico sospetto sulla porta 41240/tcp

Da un paio di settimane ricevo traffico sospetto diretto verso la porta
41240/tcp di un mio host posto dietro un firewall netfilter. All'inizio
i pacchetti provenivano solo da un ip riservato (due esempi):

 May 21 03:00:25 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=126.123.252.5 
 DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=105 ID=58793 PROTO=TCP SPT=
 38039 DPT=41240 SEQ=2550999126 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0 
 OPT (020405B40103030201010402)

 Jun 3 14:11:23 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=126.123.252.5 
 DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=106 ID=58793 PROTO=TCP SPT=
 38039 DPT=41240 SEQ=2550999126 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0 
 OPT (020405B40103030201010402)

Ne sono sono arrivati un centinaio nell'arco di circa due settimane, in
prevalenza durante le ore diurne e serali della nostra zona geografica.
I pacchetti sono tutti identici l'uno all'altro ai livelli ip e tcp, se
si esclude il TTL (che varia tra 102 e 108) e l'IP ID, che in due o tre
casi e' diverso. <mioip> e' solo uno degli host dietro al firewall, che
hanno tutti ip adiacenti e non sono coinvolti. Questo traffico, quindi,
e' mirato.

Il pacchetto e' apparentemente forgiato e non appartiene, a prima vista,
a nessuno stack tcp/ip noto. Fino a questo punto pensavo a qualche poco
nota appliance di rete malconfigurata, in cui era stato inserito il mio
ip per errore al posto di quello d'un qualche device di management, log
server su porta inusuale o chissa' cos'altro.

Poi arrivano questi:

 Jun 2 08:25:59 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=68.76.86.82 
 DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=109 ID=58793 PROTO=TCP SPT=
 38039 DPT=41240 SEQ=2550999126 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0 
 OPT (020405AC0103030201010402)

 Jun 2 15:34:58 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=207.75.1.254 
 DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=104 ID=58793 PROTO=TCP SPT=
 23657 DPT=41240 SEQ=4057633743 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0 
 OPT (020405640103030201010402)

Seguono nuove (e meno tranquilizzanti) ipotesi. A questo punto metto su
una semplice honeypottina, visto che partecipano anche ip routabili, al
fine di vedere cosa succede completando il 3-way handshake. Inutile: un
discreto numero di host ha contattato l'honeypot ma nessuno ha risposto
al mio SYN/ACK, neanche con un RST. Questo e' l'elenco degli altri host
che ho visto:

                       IP address   | src port
                       -----------------------
                       198.68.128.8      29301
                       205.251.214.254   38039
                       211.170.36.114     7325
                       217.208.230.223   33798
                       219.165.104.24    38039
                       62.110.19.3        6174
                       64.146.4.132      38039
                       64.219.62.94      38039
                       81.48.67.20        1025

Ogni host ha contattato la mia honeypot una sola volta, escludendo l'ip
riservato che continua a inviare pacchetti con una frequenza in leggera
crescita. La porta sorgente cambia, a volte, con l'ip sorgente ma tutti
gli altri campi dell'header sono uguali a quelli gia' osservati. Questi
ip si differenziano dai primi (riportati nei log di netfilter): sono in
apparenza dei dialup/adsl e quelli "su" in questo momento sono macchine
win2k/xp con stack tcp/ip in configurazione di default. I primi, invece
erano macchine diverse: entrambe dietro a packet filter ed entrambe con
uno stack tcp/ip alterato (ttl non di default). Uno dei due e' anche un
noto open proxy ma il traffico arrivato fino a me non e' stato generato
dal demone del proxy, ritengo.

La scorsa settimana c'e' stato un post su incidents ("Help with odd log
file...") che ho ritenuto essere inerente: la porta di destinazione del
traffico osservato da questa altra persona e' diversa ma le analogie in
parti significative dell'header ip e tcp non possono essere casuali. Ai
nostri post non e' stato dato un seguito significativo, fin oad ora.

L'argomento e' gia' stato affrontato su it.comp.sicurezza.varie e sulla
gia' citata mailing list. Riporto i link ai thread per gli interessati,
visto che su questi post sono recuperabili ulteriori dettagli o ipotesi
che qui snono state omesse per amor di brevita'.

http://google.it/groups?selm=MPG.1946f030fe2db00a989e86%40powernews.libero.it
http://www.securityfocus.com/archive/75/323757/2003-05-30/2003-06-05/0

Sono sgraditi commenti sul mio inglese :-)

Le ipotesi fin'ora valutate sono:

1)  trojan/backdoor su <mioip> che ha chiamato casa, entrando poi in un
    database; POCO PROBABILE: <mioip> e' una win2k pro molto "hardened"
    e da ricerche approfondite non e' emerso nulla di sospetto;
2)  trojan/backdoor con l'ip di casa hardcoded ma scritto male: i coder
    hanno scritto, per sbaglio, il mio ip invece del loro, e ora questa
    backdoor invia a me info sulle sue locazioni; BOCCIATO dopo il post
    su incidents;
3)  scherzo di qualche buontempone, amico mio o no che sia; BOCCIATO in
    seguito al post su incidents.

-- Alcuni aspetti valutati --

A)  l'ip riservato: potrebbe essere dovuto al fatto che il traffico che
    vedo e' generato da un server posto dietro a un DNAT o loadbalancer
    stateful, che non fa SNAT per il traffico non originato in risposta
    a connessioni iniziate dall'esterno; un eventuale attacker potrebbe
    averlo violato, grazie al DNAT, ma poi il traffico generato dal suo
    tool in esecuzione sul server esce con l'ip sbagliato perche' manca
    lo SNAT.
B)  mancanza di risposta ai SYN/ACK: gli host a quegli ip sono giu', in
    realta', mentre vedo questi pacchetti, e l'attaccante sta spoofando
    l'ip dopo aver verificato che all'indirizzo non risponda nesuno (ma
    perche'? Per fare un po' di rumore? Ha gia' verificato quel che gli
    serviva da uno dei primi due ip che ho loggato con netfilter giunti
    mentre non era in esecuzione l'honeypot, ed ora vuole solo generare
    un po' di confusione?).
C)  mancanza di risposta ai SYN/ACK: l'applicazione remota s'aspetta un
    SYN/ACK che e' in realta' un cookie, avente precise caratteristiche
    a livello tcp o ip quando emesso dalla parte remota di un'eventuale
    backdoor. Non ricevendo il cookie, il client droppa il traffico.
D)  la porta destinazione sembra essere poco rilevante, a giudicare dai
    post su incidents: le porte src e dst sembrano legate gli ip.
    
...vabbe': il post sta diventando un po troppo lungo. Qualche dettaglio
in piu', come dicevo, si puo' trovare nei thread su usenet e incidents.
Sono disponibile per altre spiegazioni su eventuali parti poco chiare.

Grazie


Fabio

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List