Newsgroup: it.comp.sicurezza.varie
Titolo: Dos UDP su porta 2002 HDSL telecom

Da un giorno un flusso continuo a 400Kbit di pacchetti UDP diretti su porta 
2002 e provenienti da mezza internet (Presumo che il source sia generato a 
caso) sono diretti ad un mio server. Il nostro firewall sta scartando tutto 
ma questi proseguono imperterriti...
Visto che l'offerta Full Business Company di Telecom prevede pagamento a 
traffico presumo che mi troverò un bel conto sto mese. Nessuno ha avuto 
casi analoghi? Gli operatori rispondono che loro non possono "fermare" 
quello che succede su internet (avevo chiesto un semplice filtro del 
traffico UDP su porta 2002) e mi dicono di fare dununcia alla polizia 
postale contro ignoti.
Telecom ha inoltre affermato che se dovessimo ricevere troppo traffico una 
denuncia alla polizia postale può servire a chiedere lo storno del traffico 
effettuato da questi hacker biricchini...
Se qualcuno può condividere con me esperienze analoghe ne sarei grato.
Abbiamo staccato tutta la notte il modem HDSL ma al mattino tutto è 
ripreso...
Saluti...

Dario Rigolin wrote:

io continuo a ricevere da alcuni giorni pacchetti sulle porte  1214/tcp 
(kaaza) e 1717/udp (fj-hdnet).
a mio parere dipende dal fatto che chi aveva quell' IP il giorno precedente 
utilizzava uno di quei servizi e il martellamento continuo arriva dai 
server ai quali si era connesso.
forse anche nel tuo caso qualcuno aveva un server su quella porta 
precedentemente?

guglielmo wrote:

Nel mio caso sono ho una subnet di IP statici, nessuno stava usando quei 
servizi prima. 

 porta 2002 e provenienti da mezza internet 
strano. cercare la 2002/tcp aperta e' uno che cerca un reverse telnet sul
tuo router, ma in udp ... da mezza internet ... che sta scritto nel
payload dei pacchetti?
poi un flusso continuo a 400Kb/s .... sembra flood ... ma fatto da uno
messo male e che non ha molto senso ...
la porta semra assegnata al servizio globe, di cui non trovo traccia.
ma potrei non averla fiutata guardando velocemente.
 qlcn ha maggiori dettagli in merito?
un mayhem che le prime ricerche su google stranamente non daano risultati
e lui ha troppo sonno
-- 
Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
SPP  wpage: 
http://www.spippolatori.com
Hacklab VR: 
http://www.m2net.it.eu.org
Remove ME to reply

 servizi prima.
Penso che se la Telecom volesse davvero collaborare potrebbe fare una 
ricerca sui router a monte del tuo IP, per controllare da dove viene 
effettivamente il traffico anomalo. In questo modo si riuscirebbe ad 
aggirare il problema dell'IP-spoofing dei pacchetti.
Non sono mai stato nella situazione di dover fare questo tipo di ricerche, 
ma direi che questa analisi dovrebbe dare risultati.
-- 
Luca

Salve a tutti, aggiungo altre informazioni sperando che possano risultare di 
aiuto ad altri del gruppo.
Ho fatto denuncia alla Polizia Postale della cosa ma per loro è la prima 
volta che hanno a che fare con "flood" o come l'ho definito io "UDP Packet 
Storm".
Il server oggetto dell'attacco era una macchina senza firewall fino ad un 
mese fa (gestita da un nostro partner...) e forse era stata catalogata in 
qualche "hacker's database" come facile da forzare. Infatti se si disattiva 
il firewall per qualche secondo (Ho provato a verificare se per caso questo 
attacco avesse come scopo ottenere l'accesso alla macchina sfruttando 
qualche overflow buffer o cose simili) in pochi secondi il kernel esaurisce 
la "neighborhood table" e tutte le operazioni di rete diventano lente e 
alla fine il server non riesce a lavorare correttamente.
Spulciando i log della macchiana delle settimane passate era evidente la 
presenza di tentativi di attachi diretti a RPC, NFS e Portmap che appunto 
sono UDP based. Non ho trovato la presenza di rootkit o BO vari.
Sto anche catalogando gli IP sorgenti per passarli a DShield.org e 
verificare se i source siano PC zonbie Window$ o un qualche flusso casuale. 
Credo che vista la totale assenza di informazioni di rilievo nei nostri 
server in realtà siamo un tassello di una operazione di "flood" più ampia 
visto che disponiamo di una 2Mbit e il tutto avrà un qualche scopo in un 
progetto più ampio di disturbo.
Da DSchield.org ho notato che la porta 2002 ha avuto un picco di attacchi 
durante questi ultimi giorni (dal 12/13 di Settembre) confermando che a 
livello mondiale una qualche azione di disturbo è in atto.
L'operatrice Telecom ha confermato che la denuncia alla PP permette di 
iniziare una procedura di "Reclamo & Accertamento" presso Telecom Italia 
che potrebbe portare allo storno del traffico in eccesso. Il condizionale 
qui è d'obbligo.
Vi terrò informati...

 edo <

 aggirare il problema dell'IP-spoofing dei pacchetti.
Sarei molto curioso di sapere come...
HappyCactus e forse alla telecom hanno le palle di cristallo...
-- 
HappyCactus - Linux User #209744 - LFS User #6046 - >>> SMSPM950 <<<
 
Ci sono 10 categorie di persone al mondo: quelle che capiscono
il sistema binario e quelle che non lo capiscono.

 effettuato da questi hacker biricchini...
E tu falla, altrimenti ricadi proprio nella ragione per cui io non
prendero' mai una hdsl a traffico: NON puoi fermare i pacchetti a bordo
rete, se prima non li hai pagati.
E ne avevamo parlato ampiamente proprio all'inizio dell'avventura hdsl
in italia: telecom NON filtra, e chi e' connesso paga anche per i flood.
-- 
          |Save our planet!
   Ciao   |Save wildlife!
  roberto |For your E-MAIL use ONLY recycled Bytes  !!
          |roberto poggi   
rpo...@softhome.net

Dario Rigolin wrote:
Fine della storia...
Confermo che siamo vittima di attacchi flood provenienti dal nuovo Worm che 
attacca Linux/Apache/OpenSSL/Mod_SSL. Scorrendo la lista degli IP ho scelto 
un paio di IP appartenenti a società italiane e li ho contattati, entrambi 
hanno confermato l'infezione di server. Purtroppo essendo partito tutto il 
fine settimana pochi sysadm erano pronti ad arginare il traffico.
Stamane il flusso era di soli 5kbit/s.
Quanto al problema telecom, il ministero delle telecomunicazioni mi ha 
confermato che non sarà facile ottenere storni anche se dovrebbe essere 
compito degli ISP che forniscono connettività con tariffazione a traffico 
la segmentazione dello stesso in modo da permettere al cliente di giudicare 
cosa è desiderato e cosa non lo è.
Grazie a tutti per la collaborazione.

 
Sembra che sia possibile.
http://www.nc-india.com/workshop/stories/36132.html
-- 
Luca

..
Finally, most anti-virus vendors have released engine updates to
detect Slapper. Administrators should contact their anti-virus
vendor for the latest virus definitions.

 
http://www.nc-india.com/workshop/stories/36132.html
C'entra nulla.
Se un pacchetto e' spoofato l'unico modo per sapere chi lo invia e' 
quello di risalire, router per router, il percorso del pacchetto, 
purtroppo non tutti i router sono sotto il tuo controllo e quindi ciccia. 
Non solo: una volta passato, il pacchetto, come puoi sapere che percorso 
ha fatto?
Tu puoi solo sapere che quel pacchetto e' entrato attraverso una certa 
interfaccia. Puoi supporre con una certa probabilita' che sia spoofato. 
stop.


Salve io ho un problema molto piu grave tuute le volte che mi collego
a internet nonostante abbia ip dinamico sono bombardato da un tcp
flood costante sulle porte 1214 5555 8888 1243 9999 6666, ho un
abbonamento BBB telecom e non avendo virus e avendo formattato
numerose volte sono sicuro dipenda dalla linea adsl che è senza dubbio
sotto HACK. infatti la cosa è indipendente dal fatto che io cambi ip
iquanto se mi scollego e riconnetto con un ip diverso riprende senza
sosta. Volevo fare i complimeti alla telecom, mi sapete spiegare come
posso denunciare questo fatto?

 stop.
E anche su questo. Se proviene da un'interfaccia dalla quale non dovrebbe 
passare, si può supporre che sia il prodotto di uno spoofing.
Visto che non sono espertissimo (quasi per nulla a dire il vero!) di questo 
tipo di indagini ho ritenuto, in base ad alcuni articoli letti, e in base 
anche alla man page di nmap, che ci fossero metodi abbastanza consolidati 
per poter risalire con ragionevole precisione alla fonte dei pacchetti. Si 
parla in particolare di 'router  path  tracing' (che a dire il vero è 
piuttosto generico come termine) e 'response-dropping'.
Se trovo documentazione che mi dia indicazione in tal senso la posterò 
senz'altro sul NG.
-- 
Luca

 flood costante sulle porte 1214 5555 8888 1243 9999 6666, ho un
A parte che questo messaggio l'avevi gia' postato e ti si e' gia' 
risposto, perche' parli di syn flood, di porte, di hack, se non sai di 
cosa stai parlando?
Prima di accusare qualcuno (telecom), leggiti le securfaq, fatti una idea 
di cosa stai parlando, quindi disabilita gli alert e vivi felice.


 piuttosto generico come termine) e 'response-dropping'.
No, il manuale di nmap parla di metodi per capire se un pacchetto e' 
spoofato e quindi risalire per eliminazione a quale degli IP da cui 
sembra provenire il port-scanning e' quello vero.
In pratica, tu lanci un 
nmap -sS -O -v -D ip1,ip2,ip3,me,ip4,ip5,ip6 dst-ip
Io, che sono sotto scanning, vedo arrivare i pacchetti da ip(1..6) e dal 
tuo vero ip. 
Ip1-6 possono essere in qualche modo scartati, ad esempio:
	controllando se a ipn fa capo una macchina raggiungibile
		(ma potresti avere la tua macchina in stealth)
	controllando il numero di hop tra me e ipn e confrontandolo
		con il TTL dei pacchetti (devo supporre pero' di
		conoscere il TTL di partenza: pero' posso fare una 
		ipotesi in base ad altri dati. Tu pero' potresti
		aver modificato il ttl di partenza)
	analisi statistiche?
Pero' se il pacchetto spoofato fa parte di altro (esempio: UDP. Non mi 
interessa avere la risposta, quindi...) allora non posso sapere (AFAIK) 
da dove arriva tale pacchetto.
Insomma i metodi di cui parla nmap (e solo lui: con google quei termini 
non sembrano fornir nulla di utile) servono solo a discriminare i 
pacchetti evidentemente spoofati...


 In tal modo, posso michiare non male le carte in tavola.
Si, così sarebbe molto più difficile risalire, credo che l'unica cosa che si 
potrebbe accertare sarebbe la contraffazione dei TTL. O sbaglio?
-- 
luca

 potrebbe accertare sarebbe la contraffazione dei TTL. O sbaglio?
Beh: se uno stesso IP cambia TTL puo' voler dire che il pacchetto ha 
cambiato route. In ogni caso, non riesci a discriminare quali pacchetti 
sono spoofati solo dall'analisi del TTL, anzi.
Certo, se il cambio del TTL e' frequente, ha intervalli notevoli (arriva 
una volta con 248 e una volta con 62) e lo riscontri anche su altri IP... 
a meno di route fortemente incasinate (loops, load balancing, 
eccetera............)


 In tal modo, posso michiare non male le carte in tavola.
miSchiare? Sminchiare? miNchiare? ... be', una vale l'altra :)
Nmap ci pensa gia' da solo a incasinare un poco le cose: il TTL
di partenza dei decoy scan varia tra 37 e 64. Il roblema e' che
varia tra una sessione di scanning e l'altra ma non all'interno
della stessa scansione. E' un po' quello che farebbe ipt_TTL in
netfilter. E' comunque sufficiente per rendere il trace back un
po' piu' difficoltoso. Sarebbe stato meglio, comunque, poter in
qualche modo impostare il TTL a manina o randomizzarlo anche in
una stessa sessione. Attualmente, infatti, bisogna stare un po'
attenti al TTL quando si fanno le scansioni da Linux e da altri
OS con TTL iniziale di default uguale a 64 perche' se il caso o
la sfiga vogliono che il TTL scelto random sia proprio... 64 :)
Fabio

 pacchetti evidentemente spoofati...
Forse si riferiscono alle tecniche di backtracing in generale o anche
all'usso di quei protocolli router2router che sono stati proposti per
incorporare nei pacchetti alcune informazioni sul percorso fatto. Non
in tutti: si proponeva di incorporarle una tantum nei flussi sospetti
o taggati in qualche altro modo (un po' come i proiettili traccianti:
uno ogni 5 o 10 pacchetti:)). Pensavo di avere dei documenti relativi
a 'sta roba ma non li trovo piu'... forse era apparsa su bugtraq? Non
mi ricordo.
Fabio

della stessa scansione.
Mi domandavo... siano IP0 e IP1 due host. IP0 mi invia pacchetti
di "decoy scan" dall'indirizzo di IP1, piu' i suoi, veri, usando
un TTL random in entrambi i casi.
Io posso sapere a quanti hop stanno sia IP0 che IP1, usando ping
o traceroute (IP0 puo' falsificarmi il traceroute; ma, se uso in
simultanea traceroute e ping, lo scopro -- e si autodenuncia).
A questo punto, se IP0 e IP1 hanno due hopcount diversi, *credo*
che sia possibile stabilire statisticamente qual e' il decoy. Il
fatto che il TTL di partenza non vari mi semplifica la vita, ma,
forse, posso fare anche senza.
E, poi, se il TTL e' diverso da quello "regolare", so che costui
o e' un decoy o e' uno scanner. Magari posso ignorare comunque i
pacchetti.
Leonardo mumble mumble
-- 
Questo messaggio è NAGWARE. Per disattivare ironia trita, giochi
di parole, volgarita' gratuite ed inviti a rileggersi i messaggi
gia' passati e/o consultare 
http://groups.google.com
, effettuare
un versamento di 25 euro come tariffa di registrazione helpdesk.

uscenti?
Meglio ancora. Ho un traceroute che mi mostra IP0 a 7 hops, ma i
pacchetti con TTL=8 svirgolano. Per IP1 ho 12 hops e i pacchetti
con TTL=13 non svirgolano.
A quel punto capisco che IP0 ha qualcosa di strano, e m'incazzo.
Bisognerebbe usare, come decoy, degli IP raggiungibili ma capaci
di negare il ping, oppure firewallati molto presto (questa penso
funzioni meno).
Altrimenti, se IP1 risponde sempre con TTL=12 sui ping che mando
io, e contemporaneamente mi arriva fuffa da IP1, si ritorna alla
possibilita' di usare analisi statistiche.
La meglio e' se l'amico Fritz usa un decoy della sua stessa rete
- cosi' si confonde di piu', e il TTL "vero" e' uguale.
Leonardo


> Bisognerebbe usare, come decoy, degli IP raggiungibili ma capaci
Raggiungibili, up and running e senza firewall. Adrebbe sempre fatto,
altrimenti rischi di creare un SYN flood al bersaglio del portscan.
Faboi

 con iptables, con particolare riferimento al proprio ip? :-p
Acc... e come fai. Mi devo essere perso quella patch :) Forse
si puo' fare qualcosa usando piu' di un match random e usando
come destinazione diversi mangle TTL, ma lo spazio in cui far
variare il ttl non sara' molto ampio (a patto di non scrivere
chili di regole). Forse la soluzione migliore e' quella dello
switch per nmap: secondo me qui' piu' di uno sarebbe in grado 
di scrivere l'apposita patch per nmap e sottoporla a fyodor.
Fabio

 pacchetti.
Questo si, ma non mi dice chi e' l'uno e chi e' l'altro (che e' la
questione da risolvere).
 
In ogni caso con nmap il ttl e' sempre random, anche quando non si
usano i decoy, e quindi l'hopcount non torna mai (per la cronaca).
Fabio

questione da risolvere).
 
Ah si', quando l'ho scritto stavo pensando alla terza possibilita',
cioe' avere un client legittimo per il servizio. Per es., su POP3.
In questo senso, intendevo "ignorare i pacchetti": chiudo fuori sia
il decoy (che non lo sapra' mai) sia lo scanner.
Leonardo
-- 
Says I, "My young lassie, I canna' weel tell ye,
The road and the distance I canna' weel gie,
But if you'll permit me tae gang a wee bittie,
I'll show you the road an' the miles tae Dundee".

:

global_structures.h@239
+	int	spreadttl;
tcpip.ip@569
- ip->ip_ttl = myttl;
+ ip->ip_ttl = o.spreadttl ? ((get_random_uint()%23)+37) : myttl;
nmap.c@211
+ {"spread_ttl", required_argument, 0, 0},
 
nmap.c@247
-  if (strcmp(long_options[option_index].name, "max_rtt_timeout") == 0) {
+  if (strcmp(long_options[option_index].name, "spread_ttl") == 0)
+  	o.spreadttl = 1;
+  elseif (strcmp(long_options[option_index].name, "max_rtt_timeout")==0){
Leonardo e un tentativo in economia di codice


Scusi, magister, non osero' piu'...:-p
"Era per vedere se stavate attenti".
Ed ora scusami: ho scritto una keyword di Visual Basic e devo andare a
fare seppuku, per prudenza.
Leonardo che non si sa mai


 precedentemente?
stesso problema riscontrato da me.. indagare ?