Newsgroup: it.comp.sicurezza.varie
Titolo: Traffico sospetto verso 41240/tcp

Da un paio di settimane a questa parte vedo regolarmente un po' questa 
roba:
 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)
Fino ad ora sono un centinaio di pacchetti in una decina di giorni, ma
il rate sembra in crescita. Per completezza riporto il primo pacchetto
che ho ricevuto due settimane fa:
 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)
Questi due pacchetti, come tutti gli altri, sono identici ad esclusione
di:
- TTL, che varia tra 102 e 108 in modo apparentemente casuale;
- IPID, che e' nel 90% dei casi 58793 ma a volte casualmente diverso.
Al 90% arrivati in orari compresi tra le 6 e le 24. <mioip> e' soltanto
uno degli host del range monitorato. Gli altri non ricevono nulla.
Vabbe'... pacchetto forgiato, fingente provenienza da macchina windows,
benche' grossolanamente. Fin'ora solo una curiosita', degna d'interesse
soltanto per il fatto d'essere mirata.
...oggi:
 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)
La cosa comincia a farsi un po' piu' interessante. Il primo e' un noto
open proxy, il secondo no. La cosa e' irrilevante, comunque, in quanto
il pacchetto proveniente da 68.76 presenta le stesse caratteristiche a
livello tcp e ip di quelli provenienti dall'ip riservato 126.123.252.5
e, quindi, non e' stato generato dal proxy ma dallo stesso tool che ha
generato i primi. Il secondo pacchetto ha porta sorgente diversa, ma i
campi rimanenti sono identici a quelli degli altri pacchetti (non puo'
essere una coindicenza). Questi due ultimi host hanno ip raggiungibili
e con una rapida occhiatina direi che il primo e' coperto da un packet
filter un po' grossolano (un "port unreachable" in risposta ad un echo 
request) mentre il secondo e' dietro ad un firewall che droppa tutto a
parte tcp. Entrambi rispondono con un ttl improbabile (rispettivamente 
149 e 42) e incoerente rispetto a quello del traffico sulla 41240/tcp. 
207.75.1.254 genera IP ID random, mentre l'altro mostra ID compatibili 
con una numerazione crescente in un host molto trafficato (e' un proxy
aperto, daltronde) ma non ho fatto molte prove. 
... insomma: pochi elementi per capire quali sistemi operativi abbiano
quegli host, ma abbastanza per capire che chi gestisce quelle macchine 
ha lavorato per offuscare le caratteristiche dello stack tcp/ip (e non
si tratta, quindi, di macchine di utenti ignari).
Nelle scorse settimane non c'e' mai stato traffico di nessun tipo da o
per questi host o su queste porte originato da <mioip>. <mioip> non ha
apparentemente nessuna backdoor a bordo che possa aver chiamato casa o
se ne ha, sono stealth e fatte su misura o molto recenti (win 2000 con
personal firewall e dietro a netfilter, no traffico NEW in entrata, un
antivirus real time + uno manuale).
Qualche ipotesi?
Fabio

> Qualche ipotesi?
Direi ... usa uno sniffer e vedi cosa "passa" sulla rete
poi magari con qualche dato in più in mano ne protremo
riparlare con calma; inoltre potresti usare TCPview che
trovi qui 
http://www.sysinternals.com/ntw2k/source/tcpview.shtml
per vedere quale programma sta "dialogando" (sospetto
che si tratti di IE ...) con quegli IP remoti
Ciao
-- 
* ObiWan
DNS "fail-safe" for Windows 2000 and 9X clients.
http://ntcanuck.com
408 XP/2000 tweaks and tips
http://ntcanuck.com/tq/Tip_Quarry.htm

 riparlare con calma; inoltre potresti usare TCPview che
Considerando il fatto che quelli che rileva sono syn, con uno sniffer ci
fai nulla, dato che non si va mai oltre il syn stesso, e dato che tutto
ciò che è contenuto nel syn è elencato dal log di netfilter.
Al limite puoi provare a rigirare quella porta su una honeypot, se
puoi/ti va.
Al momento - da casa - non ho modo di controllare il mio fido acidlab,
domani vedo se ho qualcosa in db...
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

 Al limite puoi provare a rigirare quella porta su una honeypot
Yup, buona idea, ovvio che anche in questo caso uno sniffer
è obbligatorio ... anche per "studiare" quello che accade :-)

 Direi ... usa uno sniffer e vedi cosa "passa" sulla rete
Credo che Fabio sia un po' piu' in la'. Cosi', a naso, senza conoscerlo
bene...
-- 
HappyCactus - Linux User #209744 - 
http://pngstego.sourceforge.net
 
 
www.google.com
 - 
groups.google.com
/* Ci sono 10 categorie di persone al mondo: quelle che capiscono */
/* il sistema binario e quelle che non lo capiscono.              */

 potrei ricordare male :-) ....
Non mi risulta ci sia pronto (ma potrei sbagliare). In compenso su
sikurezza.org
 se ne era parlato un po' di tempo fa, e qualcuno pare lo
volesse sviluppare.
Onestamente, penso che a conti fatti si siano resi conto che è una
boiata:
per passare il packet filter devi usare porte aperte, se le porte sono
aperte c'è qualcosa che ascolta, se c'è qualcosa che ascolta ottieni solo
di fargli un syn-flood.
Che poi ci siano condizioni in cui si può usufruire di 'sto genere di
traffico, ok.
Partire dal presupposto che *possa* essere attività di questo genere mi
pare eccessivo ;-)
Cmq, il mio db risponde picche: neanche un tentativo verso quella porta
nello storico (~ 3 mesi).
Byez


 Facci sapere, se hai ulteriori dettagli.
Mi aggancio qui per comodita' (o pigrizia?) per rispondendere a tutti 
senza scrivere troppi post .
-Questione sniffer e contenuto payload dei SYN- 
Come si puo' vedere dai log, quei SYN sono vuoti: si arriva ai 52 byte 
con le sole tcp options e il pad. In ogni caso, per non perdermi niente, 
c'e' gia da una settimana il logging tcpdump di tutto il traffico che e'
destinato a quella porta o proveniente da quell'ip (ora _quegli_). Non 
l'ho postato perche' non forniva ulteriori dettagli.
-Questione ackcmd-
Dubito che sia utile scrivere una versione di ackcmd che usi SYN invece 
di ACK: lo scopo principale del tool e' bypassare le acl dei firewall 
stateless che bloccano i SYN, e quindi... :-)
-Questione honeypot-
Fino a ieri era perfettamente inutile, visto l'ip sorgente del traffico. 
Da ieri, quando hanno cominciato a partecipare anche host raggiungibili, 
ho messo su una robetta semplice per vedere cosa succede se concludo il 
three way handshake, ma fin'ora ha chiamato solo 126.123.252.5.
-Considerazioni varie-
Se qualcuno mi descrivesse i meri sintomi "a ieri" gli avrei detto che 
era una malconfigurazione di un host mal-nattato in cui hanno inserito 
<mioip> invece di <myip>. Ora che il traffico non viene piu' solo da li 
gli direi che c'e' di mezzo una backdoor/trojano che ha chiamato casa e 
<mioip> e' entrato in qualche database. Alla luce delle analisi fatte
su <mioip> e sulla configurazione dell'host e della rete mi verrebbe da 
escludere queste possibilita', a meno che non sia una backdoor molto 
fica, ma anche qui mi verrebbe da chiedere: perche' proprio mioip? Non 
e' niente di speciale. Non tanto da giustificare, a mio parere, sforzi 
di questo tipo. Tra l'altro sforzi e competenze coinvolte sarebbero 
incompatibili con l'uso di quell'ip sorgente riservato, che si e' fatto 
sgamare subito. Sarebbe necessaria anche una buona conoscenza di
<mioip> per installare una backdoor stealth ma, ancora, questo sarebbe
in contraddizione col fatto che chi ha questa conoscenza saprebbe
anche che non puo' accedere a <mioip> da quella via a causa del fwall.
A proposito degli host remoti una possibile considerazione e' che questi
siano stati compromessi e abusati. In particolare quello che io vedo 
come 126.123.252.5 potrebbe essere un server dietro a un DNAT per cui 
non viene fatto anche uno SNAT e chi l'ha violato non se ne e' accorto 
(bah) e ha cominciato a ravanare <mioip>. Ma perche' non smette, visto 
che non riceve traffico di ritorno? Chiunque abbia messo l'eventuale 
backdoor, per i motivi detti sopra, dovrebbe anche sapere che <mioip> 
e' sempre su, e dovrebbe insospettirsi nel non vedere neanche un RST. 
Fabio

 three way handshake, ma fin'ora ha chiamato solo 126.123.252.5.
Lascialo girare x un pò e vedi se "becchi" qualcosa :-) in ogni caso..
suppongo che tu sia su IP statico, se così non fosse.. beh, potresti
provare a cambiare IP e vedere se il traffico cessa o se ricomincia
nel secondo caso .. hai qualcosa che lo "attira" !

 insospettirsi nel non vedere neanche un RST. 
cosa c'é prima/dopo il <tuoip>? magari cambiando qualche cifra?
Se fosse una backdoor/trojano con l'indirizzo hardcoded, e l'astvto 
coder lo avesse cannato?
Sento che non regge come ipotesi, ma oggi mi sento di azzardare 
assurdità.
Tranquillo, poi mi passa :)
D o z e r
-- 
Il mondo e' bello perche' e' avariato

Giusto un'idea ...
supponiamo che qualcuno abbia "bucato" le macchine
che vedi nei logs, questo qualcuno ha installato uno
shell script che gira con un cronjob, tale script utilizza
nMap per effettuare la scansione di blocchi subnet ad
intervalli regolari per trovare sistemi "vulnerabili" (ora
non mi chiedere a cosa) in questo caso installando un
honeypot sulla/sulle porte "testate" potresti avere una
qualche conferma, occhio cmq che -se- il tipo è stato
furbo lo script *non* farà direttamente la connex ma
"avvertirà" (e-mail o altro) il "capo" quindi la vera connex
potrebbe arrivare da un'ip diverso


 assurdità.
Non mi sembra affatto una assurdita', ma una tranquillizante
ipotesi da non scartare :-)
Fabio

 diverso
La honeypot e' su e il logging viene fatto sugli ip 
sorgente O sulel porte e quindi non dovrei perdermi 
niente.
Fabio

 nel secondo caso .. hai qualcosa che lo "attira" !
E' una buona idea. L'ip e' statico ma con poca fatica lo 
posso cambiare all'interno di un certo range, lasciando 
la honeypot in ascolto "virtuale" sul vecchio ip. Quando 
ho un attimo lo faccio e vedo se cambia qualcosa.
Fabio

 ho un attimo lo faccio e vedo se cambia qualcosa.
Ok ... poi fammi/facci sapere ... in ogni caso se veramente
"qualcosa" sta attirando quei tentativi dovresti vedere del
traffico in uscita ... mi viene un sospetto .. non č che hai una
delle macchine interne "bucata" ? In questo caso quella
macchina manderebbe "fuori" dei pacchetti tipo "sono qui"
ma poi i tentativi di raggiungerla verrebbero bloccati dal
firewall ...oppure potrebbe essere qualcuno che cerca di
usare un programma di filesharing p2p ...

 programma di filesharing p2p ...
Il SYN in ingresso non e' generato da uno stack tcp/ip noto ed e'
palesemente forgiato.
Fabio

  OPT (020405B40103030201010402)
Se a qualcuno interessa, su incidents c'e' un thread aperto stanotte in 
cui il poster lamenta traffico sospetto con pacchetti di cui riporta la 
traccia che quoto in calce. Lui vede traffico di questo tipo originato
da molte macchine e destinato a diversi dei suoi ip, con porte sorgente
e destinazione che sembrano avere una correlazione con gli indirizzi ip.
Non ho un link al sito web della mailning list, ma non dovrebbe essere
difficile trovarlo, per chi non e' iscritto. Il thread e' "Help with an
odd log file...", di sec_slave (chiocciolina) 
hushmail.com
. cerchero'
di partecipare nonostante il mio povero inglese.
Direi che da una rapida occhiata alla window size e alle tcp options 
non puo' sfuggire la somiglianza con il traffico diretto al mio host. 
Penso che possa essere tutto traffico originato dallo stesso tool. Se 
cosi' fosse decadrebbero le ipotesi dell'ip hardcoded, di Dozer, e la 
burla (ipotesi che stavo valutando).
Fabio che si puo' sapere che cavolo sta succedendo con questo bugbear?
------------------------------------------------------------------------
Internet Protocol, Src Addr: 155.128.250.228 (155.128.250.228), Dst 
Addr: XX6.X37.151.97 (XX6.X37.151.97)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 52
    Identification: 0xb82b
    Flags: 0x00
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 118
    Protocol: TCP (0x06)
    Header checksum: 0xc248 (correct)
    Source: 155.128.250.228 (155.128.250.228)
    Destination: XX6.X37.151.97 (XX6.X37.151.97)
Transmission Control Protocol, Src Port: 866 (866), Dst Port: 26469 
(26469), Seq: 1409168989, Ack: 0, Len: 0
    Source port: 866 (866)
    Destination port: 26469 (26469)
    Sequence number: 1409168989
    Header length: 32 bytes
    Flags: 0x0002 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 55808
    Checksum: 0xd5a2 (correct)
    Options: (12 bytes)
        Maximum segment size: 1460 bytes
        NOP
        Window scale: 2 (multiply by 4)
        NOP
        NOP
        SACK permitted
------------------------------------------------------------------------

 
Che due maroni... oggi per colpa di 'sti favoni si lavora poco :-/
-- 
Fabrizio "Hermooz" Ermini

 riservato. 
Perché ho risposto solo alla tua osservazione che si fosse "fatto
sgamare subito", pensando che con il riferimento all'ip tu volessi
intendere, per estensione, l'attività smodata del trojano/backdoor,
non l'ip in sè, anche se ho quotato più del necessario. 
Quindi ho immaginato che il tool si comportasse come chi non ha 
bisogno di tutelarsi per comunicare con una destinazione, proprio
perché crede sia quella giusta. Una ripetizione dell'idea che avevo
già avanzato prima.  
Rileggendo ora, forse non ho interpretato correttamente il
senso del tuo commento ed ho risposto troppo velocemente.
Ma sono un niubbo, e talvolta può capitare :) 


>OPT (020405B40103030201010402)
Indirizzo IP  | porta src
-------------------------
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
Questi ip mi hanno chiamato. La cosa apparentemente poco chiara e' che 
nessuno di questi host risponde ai SYN/ACK della honeypot, neanche con 
un RST (alla fine riporto una sessione tipo). Alcuni in questo momento
sono up e sono raggiungibili via TCP, altri no. Alcuni sembrano dialup
(adsl o di altro tipo) mentre altri... boh. Ogni host ha fatto un solo
tentativo, a parte 126.123.252.5 che continua a chiamare imperterrito.
1) le macchine erano giu', in quel momento, e il cattivone ha spoofato
   il loro ip dopo aver controllato che non fosse raggiungibile;
   1.a) il cattivone e' sul percorso del traffico e lo intercetta [1]
   1.b) il cattivone e' in qualsiasi altra parte del mondo;
        1.b.1) il cattivone se ne fotte del traffico di ritorno per i
               motivi piu' impescrutabili;
        1.b.2) il cattivone se ne fotte del traffico di ritorno perche'
               ha gia avuto il suo feedback con i primi scan e ora sta
               solo confondendo le acque con un po' di rumore;
2) le macchine erano su, in quel momento, ma droppavano il traffico in
   ingresso/uscita, per cui io non vedo nulla di ritorno.
Altro dettaglio: la porta sorgente dei SYN varia a con gli ip, mentre 
quella di destinazione no. Rimane da scoprire se quelle macchine hanno
ip fisso e/o se quelle che adesso rispondono erano o no le stesse che
possedevano quell'ip al momento dei fatti. Temo che dovro' corredare
la honeypot di un piccolo scanner real-time.
Fabio
[1] lo escluderei, in prima battuta
----------------------------------------------------------------------
06/06-16:50:11.764906 
217.208.230.223:33798
 -> <mioip>:41240
TCP TTL:107 TOS:0x38 ID:58793 IpLen:20 DgmLen:52
******S* Seq: 0x980D2856  Ack: 0x0  Win: 0xDA00  TcpLen: 32
TCP Options (6) => MSS: 1402 NOP WS: 2 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/06-16:50:11.765568 <mioip>:41240 -> 
217.208.230.223:33798
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:52 DF
***A**S* Seq: 0x6DB52C74  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/06-16:50:15.762590 <mioip>:41240 -> 
217.208.230.223:33798
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:52 DF
***A**S* Seq: 0x6DB52C74  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/06-16:50:21.762609 <mioip>:41240 -> 
217.208.230.223:33798
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:52 DF
***A**S* Seq: 0x6DB52C74  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/06-16:50:33.962555 <mioip>:41240 -> 
217.208.230.223:33798
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:52 DF
***A**S* Seq: 0x6DB52C74  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/06-16:50:57.962580 <mioip>:41240 -> 
217.208.230.223:33798
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:52 DF
***A**S* Seq: 0x6DB52C74  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/06-16:51:46.162567 <mioip>:41240 -> 
217.208.230.223:33798
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:52 DF
***A**S* Seq: 0x6DB52C74  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

ciao Fabio,
non ho letto con attenzione tutti i tuoi post, ma a prima vista mi 
sembra tanto una connessione effettuata da un qualche worm.
Avevo pensato ad uno scan, ma ho letto che dei tanti ip che hai in net, 
le connessioni avvengono solo ed esclusivamente verso quello, quindi lo 
scan č da scartare.
Potrebbero anche sembrare delle back-connections, cioč connessioni di 
ritorno di agent verso un eventuale server.
Non mi preoccuperei tanto della presenza dell'ip non routable, come hai 
detto tu potrebbe essere una rete privata non "snat-tata" a dovere.
Piuttosto, come č stata la tempistica? Prima solo connessioni da 
quell'ip, per quanto tempo? con che frequenza? quando sono cominciate le 
connessioni dagli altri host? e che frequenza hanno? quanti host ti hano 
contattato fin ora?
ciap

 quanti host ti hano contattato fin ora?
24, piu' o meno da tutto il mondo. Alcuni di questi erano su al momento 
in cui e' arrivato il SYN, ma non hanno risposto nulla al SYN/ACK pur 
essendo raggiungibili.
Ad esempio:
| 06/10-11:08:27.774904 -> type:0x800 len:0x42 
| 
213.219.141.140:1025
 -> <mioip>:41240 TCP TTL:109  
| TOS:0x38 ID:58793 IpLen:20 DgmLen:52
| ******S* Seq: 0x980D2856  Ack: 0x0  Win: 0xDA00  TcpLen: 32
| TCP Options (6) => MSS: 1460 NOP WS: 2 NOP NOP SackOK
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
| 06/10-11:08:27.775550 -> type:0x800 len:0x42 
| <mioip>:41240 -> 
213.219.141.140:1025
 TCP TTL:64 TOS:0x0 
| ID:0 IpLen:20 DgmLen:52 DF 
| ***A**S* Seq: 0x5AC72E48  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32 TCP 
| Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
La honeypot ha cercato di portare avanti l'handshake ma non ha ricevuto 
ne un ACK ne un RST. Cosa strana, visto che circa 30 secondi dopo...
| $ hping2 -c 1 -p 1025 -SA 213.219.141.140
| HPING 213.219.141.140 (eth2 213.219.141.140): SA set, 40 headers + 0 
| len=46 ip=213.219.141.140 flags=R seq=0 ttl=108 id=33135 win=0 
|
| --- 213.219.141.140 hping statistic ---
| 1 packets tramitted, 1 packets received, 0% packet loss
| round-trip min/avg/max = 130.1/130.1/130.1 ms
Notare la porta sorgente: questo e' uno dei rari casi in cui e' diversa 
dalla solita. La discussione su incidents e' andata avanti. Altre 
persone vedono questo traffico ed essendo amministratori di backbone o 
router di grosse reti, hanno maggiori informazioni a disposizione. 
Secondo le ultime supposizioni potrebbe essere una botnet e la 
combinazione di porte, tcp options e altri dettagli degli header ip e 
tcp potrebbero essere i comandi.
http://www.securityfocus.com/archive/75/323757/2003-05-30/2003-06-05/0
Loro sono piu' avvantaggiati perche' possono analizzare piu' traffico.
Io ho il vantaggio di avere per le mani uno degli host destinatari di 
questo traffico, anche se purtroppo dalle analisi non e' ancora emerso 
niente.
Fabio

 SYN/ACK pur essendo raggiungibili.
Avevano dati nel payload, per caso?


 tcp potrebbero essere i comandi.
Ok assumiamo che si tratti di una botnet (era anche uno dei
miei sospetti), ora, non so cosa ci sia "dietro" il tuo firewall
perciò ipotizzo... diciamo che uno degli utenti (o più di uno)
stia usando un pgm IRC (mIRC o simile) e che abbia preso
uno script che contiene un "bot nascosto", a questo punto
appena l'utente va in chat il bot si attiva ed inizia a notificare
la sua presenza questo fa si che il "controller" tenti di inviare
indietro al bot alcuni comandi che però vengono intercettati
e bloccati dal firewall ... un'idea potrebbe essere quella di
controllare il traffico interno e vedere se in corrispondenza
con i pacchetti in ingresso vedi del traffico IRC o simile in
uscita ... lo so che è più facile dirlo che farlo ma ...

 un "oggetto" che funzionava in modo simile, in qualche senso.
Finche' il traffico rilevato era solo il mio la botnet poteva essere 
una possibile ipotesi, ma non cosi scontata. Ora comincia ad essere 
l'unica spiegazione. Se e' cosi', deve esere una cosa piuttosto grossa, 
visto il volume di traffico che sta generando. Purtroppo, pur avendo per 
le mani un presunto nodo della botnet non riesco ancora capire quale 
possa essere il processo del bot. Sempre che ci sia qualcosa di
nascosto da scoprire, e che il presunto bot non sia, invece, altro che 
una applicazione apparentemente lecita. Bisognerebbe, a questo scopo,
verificare i dettagli sulle applicazioni installate sulle macchine 
destinatarie del traffico.
Fabio

 uscita ... lo so che è più facile dirlo che farlo ma ...
Si, e' un po' un casino ma lo sto gia' facendo: quell'host non puo' 
piu' uscire verso internet via ip forwarding, ma solo tramite l'uso
di un proxy per il solo traffico indispensabile, e tutti i tentativi
di uscire tramite il default gateway vengono loggati. Essendo una 
macchina di produzione per ora e' tutto quello che posso fare, sperando 
che se c'e' qualcosa di ben nascosto (o anche troppo ben in vista) che 
comunica fuori, questo non riesca da solo a scoprire il proxy da usare e 
la password e usare quello. Non penso, visto che tutto sembra basato su 
ben precise scelte nella composizione degli header tcp e ip, cosa 
impossible da mantenersi passando per un proxy socks. Per ora non ho 
visto nulla di sospetto.
Fabio

 Avevano dati nel payload, per caso?
No, ne nessun dato ne nei SYN ne nei pochi RST. In effetti non e' 
immediato il calcolo, ma se conti i byte occupati dalle tcpoptions 
vedi che la lunghezza dell'header tcp e' di 32 byte, e si arriva a
52 con l'header ip.
... ah, giusto, non l'avevo detto: in qualche raro caso sono arrivati 
dei RST in seguito ai SYN/ACK. Anche questi sono chiaramente forgiati 
e portano qualche punto all'ipotesi dello spoofing dell'indirizzo 
sorgente. Non ho ancora potuto verificare se vengono emessi anche
in caso di drop dei SYN. Forse fanno parte anche questi di un
fantomatico protocollo di comunicazione stealth.
| 06/10-10:28:49.210288 -> type:0x800 len:0x42
| 
68.65.241.80:38039
 -> <mioip>:41240 TCP TTL:99 TOS:0x38 ID:58793  
| IpLen:20 DgmLen:52
| ******S* Seq: 0x980D2856  Ack: 0x0  Win: 0xDA00  TcpLen: 32
| TCP Options (6) => MSS: 1460 NOP WS: 2 NOP NOP SackOK
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
| 06/10-10:28:49.210918 -> type:0x800 len:0x42
| <mioip>:41240 -> 
68.65.241.80:38039
 TCP TTL:64 TOS:0x0 ID:0 IpLen:20  
| DgmLen:52 DF
| ***A**S* Seq: 0xC3B06776  Ack: 0x980D2857  Win: 0x16D0  TcpLen: 32
| TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
| 06/10-10:28:50.969628 -> type:0x800 len:0x3C
| 
68.65.241.80:38039
 -> <mioip>:41240 TCP TTL:99 TOS:0x38 ID:41823  
| IpLen:20 DgmLen:40
| *****R** Seq: 0x980D2857  Ack: 0x980D2857  Win: 0x0  TcpLen: 20
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Una cosa curiosa e' che _tutti_ gli ip sorgente che ho potuto verificare 
si trovano apparentemente, nell'ipotesi di uso dei TTL di default, a un
hop in meno di distanza dalla presunta sorgente dei SYN e RST sospetti.
In pratica, se il SYN sulla porta 41240 ha TTL=x, il traffico di ritorno
delle prove dirette che faccio io su quell'ip arriva sempre con TTL=x-1.
Una volta ok, due va ancora bene... ma 8? Varie ipotesi ma nessuna che
valga la pena di riportare, per ora.
Fabio

 Avevano dati nel payload, per caso?
ho notato adesso la frase relativa alle options.
Si, e' una cosa cui avevo pensato. 
Sara' che ho avuto a che fare di recente con Stacheldraht...


 destinatarie del traffico.
eh gia'.
Hai provato a fare un replay dei pacchetti in arrivo alla tua macchina
sulla macchina apparentemente destinataria?


 macchina sulla macchina apparentemente destinataria?
Ho fatto una stupida applicazioncina con libpcap con cui ho iniettato 
in rete dei pacchetti forgiati sulla falsa riga di quelli sospetti, 
cambiati in alcune parti come il ttl (tirato giu di uno) e la porta 
destinazione (provate tutte le 0xFFFF porte) ma non hanno causato 
alcuna emissione di traffico dall'host, ne tdimon ha rilevato attivita' 
al layer tdi. Nessuna variazione apparente nella attivita' dei processi 
in esecuzione ma non so quale variazione si potrebbe mai vedere (penso 
che sarebbe comunque troppo basso l'aumento di uso della cpu del 
processo). Dovrei rifare la prova avviando qualcuna delle applicazioni 
teoricamente lecite e di uso saltuario che possono essere considerate 
"sospette". Sono prove un po' empiriche ma e' tutto quel che mi e' 
venuto in mente fino ad ora.
Fabio

 quindi, non penso che possa essere gestita attraverso irc,
E chi l'ha detto ?!? Il server IRC potrebbe anche non entrarci
nulla, piazzi un "bot" in una room, nel momento in cui lo script
si attiva .. fa un autojoin (nascosto) in tale room e posta il suo
IP a questo punto il "bot" controller riceve l'indirizzo e non fa
altro che provare a ricontattare il client, se è tutto ok (ossia se
ricevuto il pacchetto il client "scrive qualcosa" in room) il "bot"
controller provvede a fare "quanto programmato" .. so che può
sembrare arabo .. ma spero ti sia chiaro, inoltre questo spiega
l'uso di IP "spoofati" dato che in ogni caso non serve che arrivi
una risposta ... visto che arriverà in IRC nella room di controllo

 arriverà in IRC nella room di controllo
Non sono sicuro al 100% che _tutti_ gli ip siano spoofati.
Come vedi nella risposta a phasma, alcuni degli host a quegli 
ip erano su al momento in cui la honeypot ha risposto, ma non 
hanno resettato il mio traffico. Perche'? Una spiegazione
e' che l'abbiano droppato, ma questo implicherebbe che si
aspettavano di riceverlo (a meno che il pacchetto non sia
andato perso, ma mi sembrerebbe assai poco probabile). Non
ho una spiegazione su come gli host abbiano potuto droppare
solo quel pacchetto senza ipotizzare una notevole complessita'
del programma coinvolto, per ora mi limito a quel che vedo. 
Anche il ttl e' spesso troppo vicino a quello teorico (-1 hop, 
in genere) per ritenere, di primo acchito, che non vi sia alcuna 
cognizione della distanza tra la rete a cui appartiene l'ip 
sorgente e la destinazione. C'e' anche la questione dell'ip 
riservato che, fin'ora, e' stato l'unico a non ricevere, in 
teoria, una risposta ed e' l'unico che continua a chiamare. 
Bah. In ogni caso io, per ora, vedo ancora troppo poco
traffico per poter fare considerazioni di tipo statistico.
Fabio

 cpu del processo). 
Fare un timing accurato, in questo caso' mi pare particolarmente
difficile. Si potrebbe tentare una analisi media sui temi di risposta,
inviando pacchetti leciti a porte chiuse, a porte aperte, e pacchetti
"illeciti", e stimando il tempo di risposta, pero' isolando il sistema
su un unico segmento di rete - pc vs. pc  con cavo cross -. 
In questo modo dovresti avvertire differenze per via dei diversi
percorsi di esecuzione. Ma il test e' valido solo in condizioni
statistiche.



-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.1. C, C++ and ASM developers
                               and beta testers are welcome!

 statistiche.
Purtroppo non ho il tempo (tra cui metto anche quello per acquisire 
gli skill necessari) per preparare un simile testbed ed eseguire le
prove. Per ora vado con il test di cui sopra, poi vedro'. 
Intanto il traffico da 126.123.252.5 continua a crescere e cominciano
a cambiare sempre piu' di frequente alcuni campi degli header (come
l'IP ID). A questo punto gli unici campi invarianti, nel mio caso,
sono la porta di destinazione, il numero di sequenza e la struttura
delle tcp options, sempre le stesse ma con diverso valore di wss. Il 
traffico da altri ip e' calato. Quelli apparentemente raggiungibili 
sono sempre dei w2k, ma tra questi ce n'e' qualcuno con netbios non 
attivato. Uno che ho testato poco fa ha una caratteristica curiosa: 
risponde con ttl di 111 (apparentemente corretto) per tutto il traffico 
tranne per gli icmp, per cui vedo un ttl di 133, che dovrebbe 
corrispondere a un ttl iniziale di 150, cioe' esattamente lo stesso ttl 
con cui usciva il traffico icmp da una delle prime macchine che avevo 
testato nei primi giorni di indagini. Gli ip immediatamente adiacenti a 
questo rispondono con ttl corretti e, quindi, non dovrebbe essere un 
eventuale router a smaneggiare il ttl. Non so cosa possa significare 
questa coincidenza ed e' inutile fare fantasiose ipotesi, pero' e' 
curioso.
Fabio

 l'IP ID).
IANA reserved. Cio' mi fa pensare a fastweb... 
A proposito, gli ipid variano per macchina oppure variano anche
su ciascun ip? le options?
Altra domanda (non ricordo se te l'ho gia' fatta): c'e' stata attivita'
sospetta prima dell'inizio di queste connessioni?
HappyCactus con frequenti scan sulla porta zero...


 HappyCactus con frequenti scan sulla porta zero...
Sulla tua porta 0 o dalla porta sorgente 0? Di questi ultimi ne vedo una 
quantita' crescente negli ultimi mesi, quasi tutti alla ricerca di open
proxy. Diretti a una mia porta 0 non ne ho visti molti nelle ultime 
settimane (gli ultimi sono di un mesetto fa): tutti SYN vuoti, in genere
visti all'interno di sessioni di scanning alla ricerca di open proxy.
Fabio
[1] la deduco dal fatto che 126...ecc ha usato solo 3 wss per centinaia
    di syn mentre dalle poche decine di altre ip vedo in tutto 9 wss
    diverse.
------------------------------------------------------------------------
Allegati :-P
$ grep SRC=126.*DPT=41240 /var/log/messages|cut -f 15 -d ' '|sort -n \
  -t '=' +1
ID=2701
ID=4171
ID=6020
ID=7382
ID=8792
ID=9998
ID=10939
ID=11152
ID=22378
ID=24491
ID=25484
ID=26617
ID=27605
ID=29661
ID=29899
ID=30719
ID=32756
ID=33469
ID=37459
ID=41574
ID=41987
ID=42049
ID=43003
ID=43605
ID=43777
ID=44471
ID=45446
ID=47326
ID=47476
ID=50993
ID=52177
ID=52969
ID=53541
ID=54573
ID=55076
ID=55212
ID=56542
ID=58793
[...] < 109 x ID=58793
ID=58793
ID=60134
ID=60810
ID=60921
ID=63383
ID=64470
$ grep DPT=41240 /var/log/messages|grep -v SRC=126|cut -f 15 -d ' '|sort
  -n -t '=' +1
ID=24727
ID=57530
ID=58793
ID=58793
ID=58793
ID=58793
ID=58793
ID=58793
ID=58793
ID=65469

 open proxy.
Diretti alla mia porta 0, sempre da uno stesso host, porta sorgente
variabile, con frequenza random.
Purtroppo il mio IP da allora e' cambiato. pace.


 visualizzazione? qualche cosa che non so??? boh.
Non e' piu' TOS ma Differentiates Services: hanno mantenuto la vecchia
label nell'output di netfilter e snort ma i dati contenuti devono essere
interpretati secondo la rfc 2474.
 
Fabio

 wrote in message
news:MPG.195b9b9da...@powernews.libero.it...


 non ti aiuterà, ma:
hint: leggere tutto il thread.



Chi ha detto che non va di moda ? A quanto
ne so il kernel hacking č quello che viene
usato piů di frequente da Russi/Cinesi per
attaccare macchine "NT" e bypassare il
controllo di software AV/AT .. detto questo..
stavo leggendo
http://www.eweek.com/article2/0,3959,1130754,00.asp
sembra simile a quanto osservato da Fabio
anche se la porta č diversa ...

Dai un'occhiata qui
http://www.eweek.com/article2/0,3959,1130754,00.asp
ti ricorda nulla :-) ??

 ti ricorda nulla :-) ??
E' un po' datatino, ormai. Comunque si... mi ricorda qualcosa: che 
e' importante essere i primi a dire qualcosa anche se potrebbe non 
avere alcuna attinenza con quanto accade ;-) 
Io ritengo che il trojano che hanno individuato ed analizzato non
sia la causa di questo traffico.
Il trojano che hanno individuato loro:
- non implementa ne meccanismi di spreading, ne altre feature che
  giustifichino l'incremento del traffico osservato (tipo routine
  di attivazione da remoto o simili) ne sembra stato osservato in
  the wild come parte di piu' complessi worm;
- spoofa sempre l'ip sorgente in range riservati, mentre parte di
  questo traffico non sembra essere spoofato e spesso l'ip non e'
  in range riservati; 
- e' per piattaforma linux mentre il traffico che sembrerebbe non 
  spoofato proviene da macchine windows 2000/XP;
- contatta ip random mentre si nota traffico "one to one" o "many
  to one", come nel mio caso;
- ha lo scopo di eseguire un portscan distribuito e, quindi, deve
  contattare lo stesso host su diverse porte (il meccanismo viene
  spiegato in altri paper) mentre e' statisticamente rilevato che
  la porta di destinazione e' correlata all'ip di destinazione.
Giusto per dire le prime cose che mi quadrano poco. Senza contare
la presenza della stringa "day 0", che ha un aria incredibilmente
cool ma che nessuno ha mai visto in quei pacchetti: 55808->0xDA00 
e' la cosa che piu' gli somiglia, ma direi che anche qui scoop ci
cova.
Loro hanno lavorato su codice che gli e' stato inviato da terzi e
non si puo' escludere che si tratti di uno scherzo, o di tool che
sono stati codati dopo che la questione ha cominciato ad avere un
certo rilievo.
Fabio

 essere interpretati secondo la rfc 2474.
gia', errore mio.


 certo rilievo.
Beh su questo ti do completamente ragione, in ogni caso come ho
scritto sopra il mio voleva essere solo un "contributo" e null'altro, se
poi questo ti scoccia ... mi fermo qui e tanti saluti, nessun problema !

 poi questo ti scoccia ... mi fermo qui e tanti saluti, nessun problema !
Ogni contributo e' ben accetto. E' solo che la notizia di cui postavi
il link sopra era stata gia discussa su incidents la scorsa settimana
e poi superata da altri post con altre analisi dello stesso o simile
worm con commenti piu' cauti del tipo <<However, we do not believe 
that the specific trojan we have identified is the sole source of the 
traffic generated, and do not know that it is a primary source>>.
Fabio