Newsgroup: it.comp.sicurezza.varie
Titolo: Dubbi---portscanner---porta

Volevo tentare di risolvere alcuni dubbi grazie all'aiuto di chi ne sa più
di
me e spero di non essere  ot ....
Ho postato anche su it.comp.sicurezza.windows ....
Innanzi tutto volevo sapere se ad esempio qualcuno stessa facendo una
scansione delle mie porta in questo momento che uso il newsreader
risulterebbe ad esempio che ho la porta 1342 aperta connessa con
xxx.xxx.xxx.xxx:nntp ??? ( Probabilmente non riuscirebbe a capire che sono
connesso con il server news del mio provider ma cmq vedrebbe quella porta
aperta ?! )
Quindi che so notando che ho la porta 110 aperta, potrebbe intuire che io
sto scaricando la posta ( a meno che non abbia associato il servizio ad
un'altra porta ) ???
Il punto insomma è mentre le mie porta sono connesse a determinati servizi,
come risultano ad un eventuale scansione da parte di un portscanner esterno
?! Aperte ? Chiuse ? Occupate ?!
Scusate l'ignoranza e vi ringrazio in anticipo per le eventuali rispote
Grazie
saluti
Marco

aperta ?! )
no. una porta in uso che non abbia richiesto esplicitamente di essere
adibita all'ascolto di connessioni, rispondera' come una porta non utilizzata.
ovvero il computer inviera' un pacchetto tcp con flag RST.
invy

 ?! Aperte ? Chiuse ? Occupate ?!
Quelle porte non sono in listening.
Quindi il problema non si pone.
BTW, se stai scaricando posta, e' la 110 del tuo provider, non la tua
ad essere "impegnata".
Quindi sarebbe comunque difficile risalire a che tipo di
operazione tu sia intento...

 ad essere "impegnata".
Hai ragione si ho sbagliato la mia porta che si collega alla 110 del server
pop.tiscalinet.it
  non è certo la 110 ....
Cmq le porta che sono in Time Wait, sono le porte in fase di chiusura ?!
Come risultano ad un portscanner ?!
Grazie ancora


Ti ringrazio per la risposta, cosa č un flag RST ?!
Grazie ancora
Saluti

No scusa in riferiemento alla mia domanda precedente .... c'è anche Closing
.... allora Time Wait cosa rappresenta ?!
Grazie ancora e scusa il disturbo
Saluti
Marco

 Come risultano ad un portscanner ?!
Time-wait...sono per l'appunto "in attesa" :-)
Ribadisco: le porte non in listening risultano chiuse.

 Ti ringrazio per la risposta, cosa è un flag RST ?!
Si dovrebbe partire da com'e' fatto un pacchetto TCP...
Se vuoi approfondire, vedi la RFC 793, disponibile, ad
esmpio, all'URL 
http://www.faqs.org/rfcs/rfc793.html
In sintesi, un paccheto con flag RST resetta la connessione.
Nella fattispecie, quel flag dice allo scanner che la porta e' chiusa.
La differenza tra una porta chiusa ed una filtrata sta proprio in
questo.
Una porta filtrata non risponde affatto.

.... allora Time Wait cosa rappresenta ?!
TIME_WAIT non identifica porte in fase di chiusura. Sono gia' chiuse.
Ma la porta non e' allocabile in un nuovo socket, in quanto in attesa del
doppio del tempo MSL, o Maximum Segment Lifetime, quindi 2*MSL.
Senza entrare nel tecnico, cosa che credo confonderebbe non poco, si tratta
di un espediente per evitare che pacchetti desincronizzati del peer inviino
ulteriori dati alla porta stessa.
invy

 Una porta filtrata non risponde affatto.
Ti ringrazio ancora per la spiegazione e per il link
Per filtrata intendi protetta da un Firewall ?!
 .... mi documento un poco .....
Grazie
Ciao
Marco

 invy
Ti ringrazio ancora per le spiegazioni, per non gravarti di 12.000 questiti
cerco qualche informazione a riguardo anche per capire meglio il fatto del
MSL e dei pacchetti desincronizzati .....
Ciao a presto
Marco

 doppio del tempo MSL, o Maximum Segment Lifetime, quindi 2*MSL.
Si sta cioe' assicurando che l'host remoto abbia recepito
la richiesta di chiusura della connessione, vero?

la richiesta di chiusura della connessione, vero?
NO. Quello che dici tu e' FIN_WAIT_1 nel caso di chi ha inviato FIN ed
aspetta l'ack corrispettivo, ricevuto il quale passa in FIN_WAIT_2. Se
riceve invece il FIN del peer, invia un ACK e passa in CLOSING, per poi
andare in TIME_WAIT. Ma in TIME_WAIT ci va anche senza passare da CLOSING
se riceve l'ack al suo FIN, il FIN del peer, e manda un ACK per il FIN
del peer.
Al di la' dello sciogli-lingua l'RFC che hai consigliato i questo thread
leggilo un po' di volte :) .. non e' affatto immediato ne' facilmente
memorizzabile le prime volte.
invy

     termination request.
Cioe', lui mi ha mandato un FIN, io gli rispondo con ACK
ed aspetto un tempo sufficiente ad assicurare che l'host
remoto abbia ricevuto questo acknowledgment, giusto? :-)

remoto abbia ricevuto questo acknowledgment, giusto? :-)
Questa tua domanda dalla definizione dell' RFC mi ricorda una cosa.
Non avevo mai capito benissimo i vari stati del TCP prima di leggere
un testo quale quello di Stevens, ed aver dato un occhio al suo
bellissimo .ps degli stati.
Come lui spiega, ed a questo punto mi pongo il dubbio, non e' tanto quello.
Ovvero anche, ma non solo. Il problema sostanziale e' aspettare che proprio
NON ci siano piu' segmenti della connessione che usino quelle due porte.
Per esempio immagina che questo stato non ci sia, e dopo aver chiuso una
connessione, tu ne apra un'altra, la quale, guarda caso, riapre subito la
medesima porta effimera come sorgente. Se arrivassero dati od ack dalla
precedente connessione, c'e' la, seppur rara, possibilita' di 'doppioni'
in corso.
Invece, passato il doppio del MSL, questo NON dovrebbe accadere. Tutto qui.
Quindi il tempo che si aspetta, 2*MSL, non e' solo per assicurarsi che
abbia ricevuto il mio ack al suo fin ...
Trovi il .ps fenomenale, su 
http://www.kohala.com/start/
invy

 abbia ricevuto il mio ack al suo fin ...
Grazie per gli spunti di riflessione e per i link.
Ce ne dovrebbero essere piu' spesso di discussioni cosi'...

Ce ne dovrebbero essere piu' spesso di discussioni cosi'...
Eh, gia', ma di invy ce n'e' uno solo. :-)
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net