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

Una domanda banalissima: il ping dovrebbe funzionare così:
x invia "ciao" ad y
y risponde con "ciao" a x
Ma su che porta avvengono gli scambi? Non sono proprio riuscito a capirlo!!!
:)
Azathoth, il Signore del Caos.
ICQ 18899317


porta 7 (echo), se non ricordo male

 Ma su che porta avvengono gli scambi? Non sono proprio riuscito a capirlo!!!
Nessuna.. perche' il protocollo ICMP usato da ping non va su nessuna porta.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
<<   Available PGP keys: DSS/DH                   >>

Ma su che porta avvengono gli scambi?
il protocollo ICMP non usa porte.
A volte, cmq, viene identificato con la porta 0.
ciao
Buttha
-----------------------------------------------------------------------
* Per rispondere rimuovere i
* PGP Key: RSA & DH/DSS
* 
http://members.tripod.com/buttha/
-----------------------------------------------------------------------

 :)
su nessuna porta. PING utilizza il protocollo ICMP che non fa uso di porte
per recapitare i suoi messaggi. Se cerchi info su ICMP puoi guardare la
man page di ping e traceroute, altrimenti puoi leggiucchiarti il buon
vecchio RFC792
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------

 porta 7 (echo), se non ricordo male
non ricordi male per la 7==echo :) ma col PING non c'entra una cippa :)
prova pure a collegarti a qualche sistema sulla porta 7 e vedrai cosa fa.


 A volte, cmq, viene identificato con la porta 0.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
?!


?!
eh si. Ce lo metterei pure io un bel ?!. Ma non riesco a trovare altra
spiegazione: facevo degli scan per trovare dei wingate ed il mio
firewall e' stato tempestato di pacchetti udp sulla porta 0 ?!?
Che potrebbe essere? Io l'ho chiesto su ICSV ma nessuno mi ha
risposto. L'unica cosa che mi e' venuta in mente e' che si potesse
trattare di risposte ICMP. Ovviamente mi piacerebbe sentire le tue
ipotesi.


Ma su che porta avvengono gli scambi? Non sono proprio riuscito a capirlo!!!
Nessuna. Il protocollo ICMP, usato da PING, non ha "porte".
Leonardo
".signature": bad command or file name

 ipotesi.
beh il fatto che fossero UDP automaticamente comporta che non fossero
risposte ICMP ..... ad ogni modo trovare porte TCP/UDP 0 aperte e' stato
spesso sintomatico di macchine IRIX della SGI. Altra banale ipotesi e' che
fosse un semplice flood UDP.
Arrivavano da piu' IP ? dallo stesso ? da quelli che scannavi alla ricerca
di wingate ?


di wingate ?
allora. Le cose stanno cosi': uso @guard che non supporta il
protocollo ICMP. Dietro ad @guard ci sta nukenabber: ho messo una rule
che lo blocca, ma cosi' mi viene notificato quando ci sono tentativi
di comunicazione a queste porte:
[05/08/1999 11:27:17.290 GMT+0200] Scansione ICMP supportata ma non
assegnata.
[05/08/1999 11:27:17.340 GMT+0200] Attivo sulla porta 5000 (tcp).
[05/08/1999 11:27:17.340 GMT+0200] Attivo sulla porta 20034 (tcp).
[05/08/1999 11:27:17.400 GMT+0200] Attivo sulla porta 555 (tcp).
[05/08/1999 11:27:17.400 GMT+0200] Attivo sulla porta 5001 (tcp).
[05/08/1999 11:27:17.400 GMT+0200] Attivo sulla porta 80 (tcp).
[05/08/1999 11:27:17.450 GMT+0200] Attivo sulla porta 139 (tcp).
[05/08/1999 11:27:17.450 GMT+0200] Attivo sulla porta 138 (tcp).
[05/08/1999 11:27:17.510 GMT+0200] Attivo sulla porta 137 (tcp).
[05/08/1999 11:27:17.510 GMT+0200] Attivo sulla porta 31337 (udp).
[05/08/1999 11:27:17.560 GMT+0200] Attivo sulla porta 61466 (tcp).
[05/08/1999 11:27:17.560 GMT+0200] Attivo sulla porta 50505 (tcp).
[05/08/1999 11:27:17.560 GMT+0200] Attivo sulla porta 12345 (tcp).
[05/08/1999 11:27:17.620 GMT+0200] Attivo sulla porta 12346 (tcp).
bene. Ogni volta che nukenabber vorrebbe avvertirmi, lo faccio
bloccare dal firewall e cosi' il firewall mi notifica i tentativi.
Allora, se io faccio un wingate scan senza nukenabber attivo, non
succede nulla.
Se faccio uno scan senza @guard attivo, anche in questo caso non
succede nulla (nukenabber tace).
Se, invece, sono attivi sia @guard che nukenabber... ecco un esempio:
faccio un wingate scan sulla subnet 212.216.100.*
Allora vengo inondato da queste cose:
Rule "NukeNabber" blocked (0.0.0.0,0).  Details:
Inbound UDP packet 
Local address,service is (0.0.0.0,0)
Remote address,service is (151.99.103.250,0)
Process name is "C:\PROGRAMMI\NUKENABBER\NUKENABBER.EXE"
l'IP e' sempre 151.99.103.250, la porta 0 il protocollo UDP.
Se provo a fare uno scan su una subnet completamente diversa,
continuano ad arrivare sempre i pacchetti sulla porta 0 udp, ma da un
IP diverso (per es 151.99.5.203).
Bene, questo e' quanto.


 l'IP e' sempre 151.99.103.250, la porta 0 il protocollo UDP.
visto che 212.216.100. e' una subnet di Tin e 151.99.103.250 e' un router
di Tin direi che cominciamo a capirci qualchecosa. Anche 151.99.5.203 e'
una macchina con IP fisso di Tin ..... sarei curioso di sapere come stai
eseguendo lo scan .... evidentemente i tuoi pacchetti triggerano risposta
da parte di tin.
Che sistema usi per lo scan ? Come assembla i pacchetti ? Dove li manda ?
Tu eri su TIN quando hai effettuato lo scan ? Quei due IP sono sulla route
tra il tuo IP e quelli che scannavi ? ......


tra il tuo IP e quelli che scannavi ? ......
vedro' di fare un tracert (lo prendo come un compito per casa)


 0... mah
questo puo' anche voler semplicemente dire che NN ha bisogno che gli si
diano  i dati necessari su linea di comando o da dialogbox. E che non
accetti valori NULL per le porte ... in questo caso far specificare 0
all'utente finale sarebbe un comodo escamotage per l'autore del software,
che non dovrebbe quindi considerare la porta come necessaria solo in
presenza di `!ICMP` .... [cmq non ho mai manco visto una schermata di NN]
per il compito a casa ..... prova ad eseguire telnet su porte 23 su host
che siano al di la' dei due IP suddetti e su altre macchine TIN che invece
non siano al di la' .... giusto per vedere come si comportano.


non siano al di la' .... giusto per vedere come si comportano.
allora: fatto un telnet su 212.216.100.234, ho ricevuto il solito:
Rule "NukeNabber" blocked (0.0.0.0,0).  Details:
Inbound UDP packet 
Local address,service is (0.0.0.0,0)
Remote address,service is (151.99.103.133,0)
Process name is "C:\PROGRAMMI\NUKENABBER\NUKENABBER.EXE"
eccoti la parte interessante:
**************
C:\>tracert 212.216.100.234
Rilevazione instradamento verso 212.216.100.234 su un massimo di 30
punti di passaggio
  1   246 ms   127 ms   236 ms  
a-go3.interbusiness.it
[151.99.103.182]
  2   125 ms   120 ms   141 ms  151.99.103.181
  3   133 ms   116 ms   121 ms  
r-ts6-go1.interbusiness.it
[151.99.103.133]
  4  
r-ts6-go1.interbusiness.it
 [151.99.103.133]  rapporti: Host di
destinazione  irraggiungibile.
Rilevazione completata.
***************
quindi e' il router prima dell'host che mi comunica che
212.216.100.234 non e' online.
Ho fatto poi un telnet sulla 23 di
  2   125 ms   120 ms   141 ms  151.99.103.181
ed ho ottenuto un connection refused, senza alcun pacchetto 0 udp.


firewall e' stato tempestato di pacchetti udp sulla porta 0 ?!?
Ah, dev'essere stato un programma... Come cavolo si chiamava? Me l'hanno
spedito in mail tempo fa. Un flooder anti-Windows. Piccolo, sui 25 K.
Forse "netbomb"?


 ed ho ottenuto un connection refused, senza alcun pacchetto 0 udp.
cmq non c'e' nesso tra la rilevazione di host unreach da parte di tracert
ed UDP su 0 .... non hai per caso un analizzatore di rete (leggi sniffer)
per vedere i pacchetti, invece di quei programmi tipo @guard ? mi chiedo
se non mostri come UDP IP:0>IP:0 un ICMP [ovvero un errore da parte di
@guard nel dumping dei pacchetti]


@guard nel dumping dei pacchetti]
a questo punto lo credo anch'io, visto che @guard non gestisce l'ICMP.
Provero' con qualche sniffer.


su nessuna porta. PING utilizza il protocollo ICMP che non fa uso di porte
da non confondere con il "cosiddetto" ping bo che invece...
=ciao=
Nebbia