Newsgroup: it.comp.sicurezza.varie
Titolo: Strani UDP

tutti diretti alla mia porta 1 (uno) (sockets de troie???).
sicuramente si è trattato del classico "scambio di IP":
L'utente che prima di te aveva attiva la connessione probabilmente era
impegnato in una trasmissione P2P... e il timeout della connessione
non era ancora caduto, quando tu ti sei connesso.
--
Ciao!
Davide
[DAOC PG]Armorgod Troll Sciamano - Midgard Vortigern[/DAOC PG]

La porta 1 e' per il servizio tcpmux (TCP port service multiplexer), trovi
lumi nel rfc1078.
Quello che non capisco e' che diavolo di attacco o scansione e' stata
tentata. Puoi allocare uno sniffer tipo ethereal e tentare di decodificare
il pay-load dei pacchetti ? E' la prima volta che m'imbatto in un attacco
(se mai fosse un attacco) del genere. E poi, altra cosa strana, sono le
porte di origine, 308 (novastorbackup) e 309 (entrusttime). Ma sei sicuro
del report del tuo firewall ? :-/
root@id3fix:~# cat /etc/services | grep 309
entrusttime 309/tcp
entrusttime 309/udp
root@id3fix:~# cat /etc/services | grep 308
novastorbakcup 308/tcp #novastor backup
novastorbakcup 308/udp #novastor backup
Non conosco attacchi mirati alla porta 1 con queste due porte sorgenti, del
resto non conosco proprio attacchi mirati alla porta 1. Certo e' che se il
tizio si e' confezionato un pacchetto su misura, magari con hping, ha solo
tentato di sapere se per caso la porta fosse aperta, ma a che pro ? Misteri
della rete -_- ...
Quindi, suggerimento personale ? Direi di rimanere in ascolto sulle porte
con Ethereal e lasciare che il tizio smanetti, enojy sniffing :-)
--------------------------------
Inviato via 
http://usenet.libero.it

 tutti diretti alla mia porta 1 (uno) (sockets de troie???).
Qualche altra info in piu' potrebbe essere utile. Qualche suggerimento:
ip sorgente, _ip_destinazione_, ttl, dimensione del pacchetto... se poi
riesci a postare qualche riga dei log completa... Comunque, proprio nei
giorni scorsi, c'e' stato un aumento delel scamnsioni sulla porta 1/udp
ma non so se siano collegate al [vecchio] trojano icq che hai citato (e 
comunque arrivano da porte alte).
Fabio

 con Ethereal
Questo si.
Fabio


cat /etc/services | grep 1 ----> 1/tcp #(TCP Port service multiplexer)
                                 1/udp #(TCP Port service multiplexer)
ecco perche' ho citato il servizio, uguale per entrambi stando al services
di un comune unix.
Cmq, vorrei capire l'utilita' di spedire un pacchetto ad una porta che non
eroga alcun servizio, per di piu' un datagram connectionless, tipo DNS, SNMP
o Trivial FTp che utilizzano generalmente UDP.
Attendo lumi :-) grazie



Domanda...ma il "vecchio Sockets des troie" non spediva datagrammi alla
porta 5001 ?


Sorry, ho trovato una URL proprio in libero che elenca i trojan e le porte
su cui lavorano, come ricordavo io "Sockets des troie" lavorava sulla porta
5001 il setup e sulla 5000 il trojano. Quindi la porta 1 non centra proprio
nulla.
Sempre piu' sconcertato...
http://digilander.libero.it/joe8012/Sicurezza%20in%20rete/elencotrojan.htm


 DNS, SNMP o Trivial FTp che utilizzano generalmente UDP.
Non capisco bene a cosa ti riferisci. Mi sembra evidente che per vedere 
se eroga o meno un servizio devi verificare se e' in ascolto o no, e per 
verificare che sia in ascolto... devi mandare un datagramma udp diretto 
a quella porta (in linea di massima).  Ma immagino che non fosse questa
la tua domanda, o no? A cosa ti riferisci con questo commento?
Fabio

 centra proprio nulla.
Non esattamente. Se non ricordo male la connessione tcp con cui il trojan
lavorava era inversa. Bindava la 1 udp della macchina "posseduta" e
aspettava datagrammi.
L'attaccante inviava un udp a questa porta specificando il proprio ip e la
propria porta (forse), e a questo punto il "posseduto" chiamava
l'attaccante.
Le porte che citi tu erano tcp e erano la sorgente o la destinazione della
connessione "attiva" non della fase di idle (non ricordo bene...).
cmq potrei ricordare sbagliato...
-- 
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)

 non centra proprio nulla.
http://www.glocksoft.com/trojan_port.htm
Non ho mai usato quel trojano, ne ci ho mai avuto a che fare. In ogni
caso non e' detto che non ne esistano diverse varianti, o che usi 
diverse porte per diverse funzioni.
L'ipotesi della scansione alla ricerca di quel trojano, o d'una sessione
col trojano interrotta dalla disconnessione di una macchina, comunque,
e' solo _una_ delle possibili spiegazioni. Forse se Gadaido posta altri 
dati si possono fare ipotesi diverse.
Fabio

 diverse porte per diverse funzioni.
trovato questo:
http://www.issgroup.com/security_center/static/4105.php
Byez


> 
http://www.issgroup.com/security_center/static/4105.php
Sulla [scarna] pagina di glocksoft potevo avere qualche dubbio 
ma direi che con questo abbiamo tagliato la testa al toro. Sul
funzionamento del trojano, ovviamente, ma non sulla natura del
traffico rilevato da gadaido.
Fabio

 dati si possono fare ipotesi diverse.
Non pensavo di destare tutta questa curiosita' :-), purtroppo cascate 
abbastanza male in fatto di informazioni aggiuntive.
Il mio e' un router casalingo senza pretese, l'ho messo su per imparare
qualcosa, i log del firewall non li guardo praticamente mai e non ho IDS 
installati.
Comunque posto tutto, spero serva.
Pc con FreeBSD 4.8 con IPNAT e IPFW
In ip-up ho uno script che:
1) spedisce la posta (tramite provider)
2) scarica la posta 
3) scarica le news 
Altre operazioni non ne ho fatte
I pezzi di log:
primo contatto da 308
01:09:22 Deny UDP 
213.140.18.198:308
 
62.98.65.216:1
 in via tun0
terzo e ultimo contatto da 308
01:10:48 Deny UDP 
213.140.18.198:308
 
62.98.65.216:1
 in via tun0
questo stava li' in mezzo (tre volte) 
01:12:27 Deny TCP 
205.140.184.220:1044
 
62.98.65.216:445
 in via tun0
primo contatto da 309
01:13:34 Deny UDP 
213.140.18.198:309
 
62.98.65.216:1
 in via tun0
ultimo dei 50 (contat[t]i) da 309
01:22:00 Deny UDP 
213.140.18.198:309
 
62.98.65.216:1
 in via tun0
La regola violata e' quella residuale
deny ip from any to any
<gnewgnew>
Neanche sono riuscito bene a capire a chi appartenga quell'IP!
</gnewgnew>
Ancora un particolare... ho tcpdumpato (manaccia solo alla fine) 
l'interfaccia e ricordo che le righe finivano con udp 111.
Ciao a tutti e grazie
--
---------------------------------
l'indirizzo contiene qualcosa di troppo


Un trojan simile su freeBSD ? Umh, lo escludiamo a questo punto. Pero' il
traffico rimane sospetto, come gia' avete detto. L'ipotesi della scansione a
sto punto pare valida a meno che il lamer che invia sti benedetti datagram
non e' un cerebroleso e non si e' preoccupato di rilevare che OS sta
tentando di scansionare.
Non lo so, sono al buio, mi occupo pochissimo dei trojan, non me ne sono mai
preoccupato per le mie macchine. Indi per cui, chiedo ulteriori lumi a voi.


 l'interfaccia e ricordo che le righe finivano con udp 111.
Mi spiace, ma non ti so dire cosa sia. Al limite, con una discreta
approssimazione, posso dirti cosa _non_ e'.Quel 111 e' la dimensione in 
byte dei dati nel payload del datagramma udp. E' una informazione di 
qualche rilievo, compresa in quelle che avevo chiesto di postare nel 
primo reply, e consente di fare qualche ipotesi in piu'. Infatti, 
normalmente, per un mero port scanning si usano dei datagrammi vuoti
o piccoli  mentre una scansione diretta alla ricerca del trojan 
precedentemente citato dovrebbe contenere al max 29 byte (la stringa 
"/udp/ connect " seguita da un ip). Quindi, a questo punto, si potrebbe 
ragionevolmente scartare la prima ipotesi (anche per altri motivi) e, 
con maggior certezza, anche la seconda. 
Ah... la prossima volta mettici un -X  :-)
Fabio

 Ah... la prossima volta mettici un -X  :-)
e magari anche un -s 1500 ... ;-)


 Ah... la prossima volta mettici un -X  :-)
Ok, alias modificato. Buono per la prossima volta.
Grazie comunque a tutti per l'interessamento, 
e' un piacere discutere con voi.
Ciao
--
