Newsgroup: it.comp.sicurezza.varie
Titolo: Segments eccc..?

Scusate l'ignoranza..cmq le faq le ho lette:->...ho fatto netstat -snap tcp
ed ecco il responso:
Active opens                              71
Passive opens                           0
Failed connection attemps        3
Reset connections                      15
Current connections                     0
segments received                       576
segments sent                                676
segments retrasmitted                 21
Scusate l'ignoranza ma cosa sono le ultime 5 voci? Sono pacchetti di dati
che qualcuno ha mandato e preso dal mio computer..insomma che succede!?!?
Inoltre qualche tempo fa mi e' successo questo fatto:
aprendo outlook express, impostato per darmi subito la finestra per la
connessione, mi e' comparsa  alla voce "username" (dove solitamente compare,
appunto il mio username,ed io non devo far altro che digitare la password
nella voce "password"..)in bella mostra la password!!!Ora , voi avete
scritto che un hacker o un craker o quello che e', lascia sempre un segno..e
non vorrei fosse questo!!
Paranoia?
Grazie mille a tutti coloro che vorranno rispondermi
Mark

Paranoia?
Penso di si'. Ma non conosco molto Outlook, posso sbagliarmi con un
ampio margine di probabilita' 8-)
Leonardo
".signature": bad command or file name

ha preferito buttarli via e chiederti di rimandarli :-)
Ti ringrazio per le informazioni!!
Mark
P.S: Cos'e' un CRC brutto????

 wrote:


CRC = Cyclic Redundancy Check, un sistema (non troppo efficiente, ma
veloce) di sapere se un pacchetto contiene dati validi, o sputtanati
in transito. Un metodo ancora piu' banale e' il "parity check": ogni
pacchetto deve contenere un numero pari di "uni". Per assicurarsene,
aggiungi un bit al pacchetto; se di suo contiene un numero pari di 1
allora il bit lo metti a zero, se il numero e' dispari metti un 1 e,
cosi', il numero totale diventa pari.
Se il ricevente riceve un pacchetto con un numero dispari di uni, sa
che si e' corrotto e lo butta via.
Il parity check non e' molto furbo perche' se si svirgolano DUE uni,
ovviamente tutto torna e il pacchetto SEMBRA sano ma non lo e'. C'e'
il CRC che e' piu' difficile da far tornare "a caso" (corrompendo in
modo casuale un pacchetto, c'e' solo una possibilita' su 65mila o su
quattro miliardi che il CRC rimanga valido, a seconda del metodo che
si usa per il CRC).
Per evitare poi che un pacchetto (o qualsiasi cosa) venga stroncato,
e quindi riassemblato con un CRC falsificato, valido, anziche' usare
il CRC si usano algoritmo ancora piu' arrabbiati, basati (di regola)
sulla crittografia. In particolare (credo) l'MD5 [MD=Message Digest]
o la firma digitale.
Dovendo lavorare leggero e veloce, il TCP[IP] usa CRC16 e basta. Non
sono sicuro ma mi pare che il 'nuovo' TCP (IPv6, e TUBA) usi qualche
protocollo piu' sicuro del CRC.


 protocollo piu' sicuro del CRC.
IPv4 usa il classico checksum basato su di un accumulatore (sum) di
complementari ad 1. Prima viene settato a 0. Poi l'header viene
considerato come formato da parole a 16bit e se ne calcola il sum. Il sum
di questo appena calcolato viene inserito in ip.check
Quando il datagramma viene ricevuto si calcola il sum di quello nel
pacchetto. Siccome il check del ricevente calcolato contiene il check il
check contenuto dal pacchetto, sara' di tutti 1 se non ha subito
modificazioni. Altrimenti viene scartato. (RFC1071)
IPv6 contiene LO STESSO checksum. Ma non per l'header IP, solo per gli
header dei protocolli di layer superiore. In quanto essi contengono gia'
gli indirizzi IP (per il calcolo del check, non nell'header).
Nel caso di migliore controllo, si rende necessario l'uso di AH ed ESP
specificati in IPSec, mediante l'uso di algoritmi di autenticazione come
MD5 o di criptografia come 3DES.
invy
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------