Newsgroup: it.comp.sicurezza.windows
Titolo: UDP

cari amici,
grazie per le risposte, ma... con tutte le metafore sui telefoni e la
posta non ho capito nulla di UDP  :-(((
qualcuno vuole riprovare.. e dirmi anche come mai essendo meno
affidabile un hacker mandi pacchetti UDP come nel caso sotto indicato?
Regola "Blocco predefinito Hack 'A' Tack" bloccata
(151.20.140.121,31789). Dettagli:
Pacchetto UDP in entrata 
Indirizzo locale, servizio (151.20.140.121,31789)
Indirizzo remoto, servizio (212.141.84.93,31790)
Nome processo "N/A"
grazie e ciao

affidabile un hacker mandi pacchetti UDP come nel caso sotto indicato?
I protocolli TCP e UDP servono per cose diverse. UDP serve quando e'
piu' utile che i dati arrivino al momento giusto, e non importa se i
dati precedenti vengono persi.
Ad esempio, l'audio via Internet di norma si trasmette via UDP. Dato
che, mandandolo in TCP, se perdi un pacchetto si ferma tutto finche'
quel pacchetto non e' arrivato; ed il tutto fa schifo; in UDP, perdi
un pacchetto, senti un "click", ma la musica continua.
Nel caso poi di TCP, viene stabilito un circuito virtuale, e quindi,
sul tuo PC, tu potresti vedere facilmente l'altra estremita', e dare
il via alle danze (denunce, contrattacchi ecc. ...). In UDP, invece,
vedi solo la tua estremita', a meno di beccare l'istante preciso nel
quale arriva un pacchetto dall'esterno... ed avere uno strumento che
lo capti e te lo dica.
Leonardo
".signature": bad command or file name

 
Leonardo, scusa ma ancora non riesco a comprendere neanche io.
puoi fare ulteriori esempi?
Grazie
T.




Il protocollo TCP *garantisce* che o i dati arrivano, o la connessione
viene resettata ma, in entrambi i casi, tutte e due le estremita' sono
messe a conoscenza del fattaccio.
Se ti mando dati in TCP, io so per certo che ti sono arrivati, oppure,
so per certo che NON ti sono arrivati. Quello che non so, a priori, e'
quanto tempo ci impiegheranno quei dati ad arrivare.
Da un canale TCP non uscira' mai il pacchetto B se prima non e' uscito
il pacchetto A. Se A non arriva, la connessione va in stallo.
In UDP, invece, ogni pacchetto fa storia a se', e se io ti mando A B C
e' perfettamente possibile che ti arrivi C B A.
Il fatto che un pacchetto si perda non "stalla" tutta la connessione.
Inoltre, dato che il ricevente NON manda conferma al trasmittente, UDP
si presta alla trasmissione "cieca". Io trasmetto un segnale, mettendo
come "mittente" un indirizzo fasullo; il ricevente riterra' il segnale
valido.
In TCP, posso farlo lo stesso, ma il ricevente inviera' una conferma a
questo indirizzo inesistente e se l'indirizzo inesistente non conferma
la conferma, la trasmissione non va avanti (posso falsificare anche la
seconda conferma, ma non in generale). In TCP quindi e' MOLTO... MOLTO
piu' difficile effettuare trasmissioni "trojan" senza che il ricevente
possa rintracciare facilissimamente il trasmittente.


 puoi fare ulteriori esempi?
TCP e' come un treno: dalla stazione A parte, e il primo "pezzo" a
uscire e' la locomotiva, poi il primo vagone, poi il secondo, fino al
vagone di coda. Nella stazione B il primo "pezzo" a entrare e' la
locomotiva, poi il primo vagone, poi il secondo, fino al vagone di coda,
nello stesso ordine con cui sono usciti dalla stazione A.
UDP e' come un pacchetto di lettere. Tu imbuchi la numero 1, poi la
numero 2, poi la numero 3, fino alla numero N. Al destinatario arriva
prima la numero 1, poi la 2, poi la 4, poi arriva la 5, poi la 3, la 6
non arriva, la 8 e 9 arrivano dopo la 10 e prima della 7. Il
destinatario si preoccupa di rimetterle in ordine e di gestire la
mancanza della 6.
-- 
Attenzione: questo messaggio ti e' arrivato dalla rete e
in qualche modo si e' insinuato nel tuo hard disk...
SecurFaq             : 
http://members.xoom.com/gouldukat/
Biancorossi Siamo Noi: 
http://www.tifonet.it/free/ancona/

lo capti e te lo dica.
A cosa ti riferisci, esattamente? Se il mittente mi manda un IP fasullo, ho
comunque qualche possibilita' di rintracciarlo? E soprattutto, come posso
capire se l'IP non e' il suo?
Saluti,
    Mardy

 mancanza della 6.
Grazie, molto esauriente
T.

 Leonardo
CRISTALLINO.
Grazie
T.

E soprattutto, come posso capire se l'IP non e' il suo?
Anche qui, dipende. Per esempio, se ho un tot di messaggi IRC con
connessione diretta, posso vedere il TTL dei pacchetti in arrivo;
se Pippo mi sta messaggiando con TTL nel range 17-22 e nel canale
c'e' un infame da Hong Kong con TTL 39, e mi arriva cacca a firma
Pippo con TTL 38 di cui Pippo afferma di non sapere niente:
a) O Pippo e' particolarmente bravo ed astvto (non so se esistano
   utilita' per skript kidz per modificare il TTL d'un nuke senza
   simultaneamente spararsi nei cogl... ehm... senza provocare un
   tot di effetti indesiderabili alla propria connessione...)
b) O il colpo arrivava da altrove, ed il cinese e' in prima linea
   nella lista delle canaglie.


   tot di effetti indesiderabili alla propria connessione...)
Ne approfitto altre due (multiple :-) ) domande: il TTL e' il tempo di
validita' del pacchetto che invio, giusto? Se si', che svantaggi ci
sarebbero nell'inviare pacchetti con TTL piu' alto?
Inoltre: il TTL viene impostato dai singoli progz oppure dipende solo
dall'accesso remoto? Nel secondo caso, si puo' settare con regedit?
TIA! :-)
Saluti,
    Mardy

 Nel secondo caso, si puo' settare con regedit?
Certo. Mi pare che si debba aggiungere una chiave per cambiare il
valore di default, piuttosto che modificarne una esistente.
Bye Krmel che non si ricorda quale