Da MAC Address a IP Address

[ryan79]

Ciao a tutti!
C'è un modo che consenta di ricavare l'indirizzo IP partendo dall'indirizzo MAC?

Devo trovare l'IP di un host nella lan. Ho utilizzato Angry IP Scanner, ma nell'intervallo di scansione che comprende tutti gli altri ip della rete non si trova l'host 'fantasma'! Mi viene il sospetto che qualcuno abbia modificato l'IP inserendo un 'tipo' di indirizzo diverso da quello della LAN.

[Harry_Callahan]

Ciao a tutti!
C'è un modo che consenta di ricavare l'indirizzo IP partendo dall'indirizzo MAC?



hai l'accesso al router della rete?

[Gennarino]

Prova con CAIN (www.oxid.it)

[nuovoUtente86]

Le vie sono diverse, più o meno pratiche, più o meno efficienti.
Ti è stato già consigliato uno sniffer (meglio wireshark), ma funziona (senza altri armeggi) solo su reti hubbed. L' altra soluzione è costituita dal protocollo rarp che permette da risoluzione inversa di mac in IP. Ora non mi sovvengono software in grado di operare con tale protocollo, perchè io preferisco una terza via, ovvero l' utilizzo dei raw socket con scanner della rete.

[OUTATIME]

Le vie sono diverse, più o meno pratiche, più o meno efficienti.
Ti è stato già consigliato uno sniffer (meglio wireshark), ma funziona (senza altri armeggi) solo su reti hubbed. L' altra soluzione è costituita dal protocollo rarp che permette da risoluzione inversa di mac in IP. Ora non mi sovvengono software in grado di operare con tale protocollo, perchè io preferisco una terza via, ovvero l' utilizzo dei raw socket con scanner della rete.
Non basterebbe wireshark con i 3/4 pacchettini che la scheda di rete invia in broadcast all'accensione?
Questo ovviamente se la rete non e suddivisa in sezioni e se il nostro amico sa l'ora di accensione del PC da trovare....

[ryan79]

hai l'accesso al router della rete?

Sì.

[Harry_Callahan]

Sì.

cerca l'host nell'ARP Table

[ryan79]

Grazie a tutti per le informazioni, ho provato con wireshark, ma non trova niente.:cry:

[lupin 3rd]

apri wireshark,avvia lo sniffer,fai un ping all'indirizzo ip dell' host(ovviamente l' indirizzo ip dev' essere presente nella tua stessa rete altrimenti vedresti l' ip del router gateway)e dopo aver ricevuto il pacchetto di risposta vedi il source mac....

[Harry_Callahan]

fai un ping all'indirizzo ip dell' host

leggi bene la richiesta dell'utente

lui vuole ricavare l'IP partendo dal MAC

se ha l'accesso al router basta verificare l'ARP Table(logicamente l'host deve avere il router come gateway). Se l'host è in una rete diversa si può provare a vedere il MAC address table(router permettendo)

[lupin 3rd]

leggi bene la richiesta dell'utente

lui vuole ricavare l'IP partendo dal MAC

se ha l'accesso al router basta verificare l'ARP Table(logicamente l'host deve avere il router come gateway). Se l'host è in una rete diversa si può provare a vedere il MAC address table(router permettendo)

già ho capito male...deve accedere al gateway...oppure per un pò di tempo(mezza giornata),siccome l' aggiornamento della tabella arp è frequente,deve aspettare che il pc anonimo invii una richiesta "who has xxx.yyy.zzz.kkk?tell to xx.yy.zz.jj.kk.ww" (chiaramente l' altro pc deve avere wireshark attivo)solo che non so se questa richiesta va solo al router oppure a tutti gli host della rete...

[nuovoUtente86]

già ho capito male...deve accedere al gateway...oppure per un pò di tempo(mezza giornata),siccome l' aggiornamento della tabella arp è frequente,deve aspettare che il pc anonimo invii una richiesta "who has xxx.yyy.zzz.kkk?tell to xx.yy.zz.jj.kk.ww" (chiaramente l' altro pc deve avere wireshark attivo)solo che non so se questa richiesta va solo al router oppure a tutti gli host della rete...

mezza giornata per un rarp....noooooooo
I pacchetti in unicast, inoltre viaggiano su tutte le porte solo nel momento in cui la mac table non ha una entry.

[nuovoUtente86]

Non basterebbe wireshark con i 3/4 pacchettini che la scheda di rete invia in broadcast all'accensione?
Questo ovviamente se la rete non e suddivisa in sezioni e se il nostro amico sa l'ora di accensione del PC da trovare....

no perchè vedrebbe come source ip 0.0.0.0. Una soluzione è il traffico netbios,ma se il pc è malevolo, ovviamente è disabilitato.

[lupin 3rd]

mezza giornata per un rarp....noooooooo
I pacchetti in unicast, inoltre viaggiano su tutte le porte solo nel momento in cui la mac table non ha una entry.

al router che ho io,wireshark non sniffa mai pacchetti rarp ma solo arp ad intervalli di 5 minuti..poi il router deve supportare e dev' essere abilitato sul router il rarp...se lo supporta si potrebbe creare un pacchetto con programmi tipo colasoft packet builder per esempio(mi sa ke nn supporta rarp) che generi il pacchetto rarp,ma il router deve rispondere alla richiesta...

l' altenativa(poco intelligente però) è quella di trovare la subnetmask oppure cercare il range della propria rete,fare un bel file .bat con tante istruzioni ping per ogni indirizzo ip della rete,sniffare il tutto con wireshark ed abilitare il filtro su wireshark in base all' indirizzo mac che possiede...

altrimenti semplicemente avvia wireshark dalla mattina,imposta un filtro con il mac come ho detto prima,ad intervalli di mezz' ora se non trova l' ip cancella la cache(perchè questa occupa ram) e tiene wireshark in ascolto fino a quando l' host sconosciuto non comunica con l' host suo...

[nuovoUtente86]

al router che ho io,wireshark non sniffa mai pacchetti rarp ma solo arp ad intervalli di 5 minuti..poi il router deve supportare e dev' essere abilitato sul router il rarp...se lo supporta si potrebbe creare un pacchetto con programmi tipo colasoft packet builder per esempio(mi sa ke nn supporta rarp) che generi il pacchetto rarp,ma il router deve rispondere alla richiesta...

In tutto questo discorso il router non c' entra nulla : è una questione host- to -host e del tipo di rete che sta in mezzo (nel caso un centro-stella, alias uno switch), cosi come non c' entra il supporta rarp : rarp è un protocollo ietf (rfc 903) e come tale chiunque implementi uno stack tcp/ip deve renderlo disponibile : eventualmente lo si inibisce a livello firewall, ma è un altro discorso.Quello che tu sniffi è una richiesta gateway, ma ha poco a che fare con questo discorso, essendo un pacchetto unicast.

l' altenativa(poco intelligente però) è quella di trovare la subnetmask oppure cercare il range della propria rete,fare un bel file .bat con tante istruzioni ping per ogni indirizzo ip della rete,sniffare il tutto con wireshark ed abilitare il filtro su wireshark in base all' indirizzo mac che possiede...

se qualcuno ha interesse a nascondere la propria identità, disabilità icmp.


altrimenti semplicemente avvia wireshark dalla mattina,imposta un filtro con il mac come ho detto prima,ad intervalli di mezz' ora se non trova l' ip cancella la cache(perchè questa occupa ram) e tiene wireshark in ascolto fino a quando l' host sconosciuto non comunica con l' host suo...a quel punto basterebbe guardare la cache arp del proprio host, ma funziona solo nel caso in cui l' host cercato abbia interesse a comunicare con il computer specifico.

[lupin 3rd]

In tutto questo discorso il router non c' entra nulla : è una questione host- to -host e del tipo di rete che sta in mezzo (nel caso un centro-stella, alias uno switch), cosi come non c' entra il supporta rarp : rarp è un protocollo ietf (rfc 903) e come tale chiunque implementi uno stack tcp/ip deve renderlo disponibile : eventualmente lo si inibisce a livello firewall, ma è un altro discorso.Quello che tu sniffi è una richiesta gateway, ma ha poco a che fare con questo discorso, essendo un pacchetto unicast.

non è obbligatorio rendere disponibile il rarp...dal pc si può provare ad inviare la richiesta rarp,ma bisogna trovare un buon costruttore di pacchetti chepermetta di creare pacchetti rarp


se qualcuno ha interesse a nascondere la propria identità, disabilità icmp.

non è detto che questo qualcuno sia esperto a disabilitare icmp...non solo,se è l' unico della rete che lo abbia disabilitato è cmq facile risalire al suo ip visto che è stato l' unico che non ha risposto al ping


a quel punto basterebbe guardare la cache arp del proprio host, ma funziona solo nel caso in cui l' host cercato abbia interesse a comunicare con il computer specifico.

dove si trova la cache arp nel proprio host?io sapevo che la tabella di corrispondenza è presente solo nel router.
E' chiaro che se non c'è e non ci potrà essere alcuna comunicazione diretta tra il pc di ryan79 e il pc anonimo,l' unica strada percorribile rimarrebbe quella di risalire all' ip tramite l' accesso al router(sempre che il router disponga della funzionalità di visualizzazione della tabella)

[nuovoUtente86]

non è obbligatorio rendere disponibile il rarp...dal pc si può provare ad inviare la richiesta rarp,ma bisogna trovare un buon costruttore di pacchetti chepermetta di creare pacchetti rarp
conosci il significato di rendere disponibile un protocollo e di rfc per chi implementa uno stack. Non mi pare, comunque, per farla breve sta a significare che chiunque partli TCP/IP, ha l' obbligo di trattare richieste effettuate attraverso determinati protocolli, ed rarp è uno di questi. Quello che poi si può fare a livello firewall è un' altra cosa.



non è detto che questo qualcuno sia esperto a disabilitare icmp...non solo,se è l' unico della rete che lo abbia disabilitato è cmq facile risalire al suo ip visto che è stato l' unico che non ha risposto al ping
basta il piu scarso dei firewall per inibire icmp. Inoltre per avere la certazza di cui parli, è necessario che tutto il range ip, meno 1, sia saturo ma a quel punto è banale sapere l' ip senza neppure accendere un pc.


dove si trova la cache arp nel proprio host?io sapevo che la tabella di corrispondenza è presente solo nel router.
E' chiaro che se non c'è e non ci potrà essere alcuna comunicazione diretta tra il pc di ryan79 e il pc anonimo,l' unica strada percorribile rimarrebbe quella di risalire all' ip tramite l' accesso al router(sempre che il router disponga della funzionalità di visualizzazione della tabella)
prova a dare il comando arp-a e poi ne riparliamo (esiste un ulteripre modo, su macchine windows). Guardacaso, anche i router hanno tale cache (riferita ovviamente alle richieste gateway), e sai perchè...semplicemente perchè un router è un dispositivo ip, esattamente come un pc.

[lupin 3rd]

conosci il significato di rendere disponibile un protocollo e di rfc per chi implementa uno stack. Non mi pare, comunque, per farla breve sta a significare che chiunque partli TCP/IP, ha l' obbligo di trattare richieste effettuate attraverso determinati protocolli, ed rarp è uno di questi. Quello che poi si può fare a livello firewall è un' altra cosa.

non ho parlato di firewall,sto dicendo che rarp non è obbligatorio;il router memorizza la corrispondenza tra indirizzo ip e mac per vedere a quale pc inviare i frame.


basta il piu scarso dei firewall per inibire icmp. Inoltre per avere la certazza di cui parli, è necessario che tutto il range ip, meno 1, sia saturo ma a quel punto è banale sapere l' ip senza neppure accendere un pc.

hai ragione che per fare una cosa del genere tutto il range sia saturo,ma supponendo che sia saturo come fai a sapere l' ip senza neppure accendere un pc?


prova a dare il comando arp-a e poi ne riparliamo (esiste un ulteripre modo, su macchine windows). Guardacaso, anche i router hanno tale cache (riferita ovviamente alle richieste gateway), e sai perchè...semplicemente perchè un router è un dispositivo ip, esattamente come un pc.

non c' entra:il protocollo ip è di livello rete (3o livello nello stack iso/osi) mentre il protocollo rarp e arp sono di livello datalink(2o livello nello stack iso/osi);e poi ci sono router e router,il mio router che possiede anche la porta usb per rendere una stampante accessibile a tutti dalla rete locale o per condividere un hard disk usb supporta anche il protocollo di alto livello ipp e smb.

[nuovoUtente86]

non ho parlato di firewall,sto dicendo che rarp non è obbligatorio;il router memorizza la corrispondenza tra indirizzo ip e mac per vedere a quale pc inviare i frame.
ancora, qui di router non se ne parla, perchè non c' entra nulla. Il protocollo rarp,che fa parte del livello datalink, è obbligatorio per chiunque implementi uno stack TCP/IP, in quanto costituisce il mezzo inverso alla risoluzione arp. Poi che un client abbia un modo più o meno agevole (a livello applicativo) di fare tale richiesta, non importa (cosi come non importa che la risposta sia droppata a livello firewall). Le specifiche ci dicono che se un host dialoga IP, deve essere in grado di accettare e processare richieste arp/rarp.




hai ragione che per fare una cosa del genere tutto il range sia saturo,ma supponendo che sia saturo come fai a sapere l' ip senza neppure accendere un pc? perchè se il range è saturo, si avrà un piano di indirizzamento statico o al più basta controllare le entry del dhcp server.



non c' entra:il protocollo ip è di livello rete (3o livello nello stack iso/osi) mentre il protocollo rarp e arp sono di livello datalink(2o livello nello stack iso/osi);

certo, è un protocollo di mappatura ip-indirizzo fisico, trasportato direttamente a livello datalink, ma non capisco dove sia il problema, visto che ogni dispostivio IP, deve essere in grado di tradurre tale indirizzo logico in uno valido nel proprio dominio fisico. Hai detto che non era possibile conoscere la cache Arp da un host, e ti ho dimostrato il contrario. Vogliamo continuare?
e poi ci sono router e router,il mio router che possiede anche la porta usb per rendere una stampante accessibile a tutti dalla rete locale o per condividere un hard disk usb supporta anche il protocollo di alto livello ipp e smb.[/QUOTE]
e quindi? la definizione di dispositivo Ip è rigorosa e riguarda qualunque dispositivo sia in grado di trattare almeno il livello rete: se scrivo uno stack in grado di elaborare Ip su una macchinetta del caffe, sarà sempre un dispositivo Ip, in grado di fare anche un ottimo caffe, ma ciò poco importa.

[lupin 3rd]

ancora, qui di router non se ne parla, perchè non c' entra nulla. Il protocollo rarp,che fa parte del livello datalink, è obbligatorio per chiunque implementi uno stack TCP/IP, in quanto costituisce il mezzo inverso alla risoluzione arp. Poi che un client abbia un modo più o meno agevole (a livello applicativo) di fare tale richiesta, non importa (cosi come non importa che la risposta sia droppata a livello firewall). Le specifiche ci dicono che se un host dialoga IP, deve essere in grado di accettare e processare richieste arp/rarp.

come di router non se ne parla?forse non ti è molto chiara la comunicazione all' interno di una rete come avviene:nel momento in cui devo comunicare con un pc all' interno della rete locale devo sapere il suo indirizzo mac perchè il sistema operativo dovrà partire dal livello più alto fino a quello data-link in cui metterà l'indirizzo mac di destinazione...dopo di che consegnerà i frame data-link alla scheda di rete che si occuperà di trasmetterli tramite il cavo di rete in segnali binari;quando i pacchetti arrivano al router questo prende l' indirizzo ip di destinazione e fa il confronto con la subnetmask,in particolare fa l' operazione di end fra i bit...se il valore dell' end è lo stesso della subnet mask convertita in binario,allora l' ip di destinazione appartiene alla rete locale,viene trovata la corrispondenza nella arp cache ,il router converte in frame e questi vengono inviati al pc di destinazione;se invece l'ip non appartiene alla rete locale,il router(nel caso di una rete domestica)invia il pacchetto al router dell' isp e poi questo verrà instradato in base agli algoritmi di routing;lo scopo del pc di sapere il mac del pc di destinazione è quello nel caso in cui in una rete non c'è un router ma solo uno switch;in questo caso lo switch legge il mac di destinazione del frame e lo inoltra alla rispettiva porta;è cosi che funziona soprattutto perchè in molti casi per risparmiare il lavoro ai router nelle reti locali vengono usati gli switch come smistatori(in modo che al router giungano solo i pacchetti destinati all' esterno)...adesso,a parte il fatto che io ho provato ad avviare wireshark sul pc fisso e ad inviare un file al portatile e ho sniffato solo pacchetti smb e arp e quindi nessun pacchetto rarp,mi spieghi poi a cosa servirebbe in tutto il discorso che ti ho detto il protocollo rarp?


perchè se il range è saturo, si avrà un piano di indirizzamento statico o al più basta controllare le entry del dhcp server.

e anche avendo un piano di indirizzamento statico mi spieghi come faresti a risalire al mac anche a pc spenti? al max potresti usare le entry del dhcp server sempre che questo renda visualizzabile l' associazione ip locale-mac

[nuovoUtente86]

come di router non se ne parla?
di router non se ne parla, o meglio (per essere più corretti), se ne parla nella misura in cui l' host specifico genera traffico diretto ad internet, alis viene effettuata una richiesta al gateway


forse non ti è molto chiara la comunicazione all' interno di una rete come avviene:

veramente pensi di poter disquisire con me (o insegnare) di reti... no non ci siamo, ma andiamo avanti, giusto per fare due risate.


nel momento in cui devo comunicare con un pc all' interno della rete locale devo sapere il suo indirizzo mac perchè il sistema operativo dovrà partire dal livello più alto fino a quello data-link in cui metterà l'indirizzo mac di destinazione...dopo di che consegnerà i frame data-link alla scheda di rete che si occuperà di trasmetterli tramite il cavo di rete in segnali binari;quando i pacchetti arrivano al router questo prende l' indirizzo ip di destinazione e fa il confronto con la subnetmask,in particolare fa l' operazione di end fra i bit...se il valore dell' end è lo stesso della subnet mask convertita in binario,allora l' ip di destinazione appartiene alla rete locale,viene trovata la corrispondenza nella arp cache ,il router converte in frame e questi vengono inviati al pc di destinazione;se invece l'ip non appartiene alla rete locale,il router(nel caso di una rete domestica)invia il pacchetto al router dell' isp e poi questo verrà instradato in base agli algoritmi di routing;lo scopo del pc di sapere il mac del pc di destinazione è quello nel caso in cui in una rete non c'è un router ma solo uno switch;in questo caso lo switch legge il mac di destinazione del frame e lo inoltra alla rispettiva porta;è cosi che funziona soprattutto perchè in molti casi per risparmiare il lavoro ai router nelle reti locali vengono usati gli switch come smistatori(in modo che al router giungano solo i pacchetti destinati all' esterno)...

Analizziamo quello che dici, ovvero che ogni pacchetto, sia esso destinato ad un indirizzo locale che remoto, viene inviato al router e da questi consegnato poi all' host specifico (o inoltrato ad un altro router). No le cose non funzionano esattamente cosi.
Quando un pacchetto ip è pronto per essere inviato, si effettua l' anding (ne hai sentito parlare, senza capire bene il momento e il posto in cui viene effettuato) tra l' indirizzo ip destinazione e la maschera di rete dell' interfaccia di uscita. Se il match è positivo si effettua una seziona arp (avente come obiettivo del mapping l' ip destinazione) al fine di ottenere l' indirizzo fisico della macchina per potergli consegnare il frame. Se,viceversa, il confronto fallisce, occorre (in questo caso si) fare capo al gateway che provvederà all' inoltro dei pacchetti attraverso reti remote.
Il tuo ragionamento astruso, ha inoltre 3 buchi clamorosi:
-mancherebbe il modo di indirizzare fisicamente il router
-le reti punto-punto, hubbed e switched non funzionerebbero senza la presenza di un router
-la presenza di un router/gateway è trasparente agli host (l' impostazione default gateway è ininfluente) che conoscono solo la propria subnet.
Per cui, in defnitiva, la arp cache di un router contiene i mapping di quegli host che hanno (o hanno avuto al timeout) connessioni attive sulla internet.
Ma andiamo avanti
è quello nel caso in cui in una rete non c'è un router ma solo uno switch;in questo caso lo switch legge il mac di destinazione del frame e lo inoltra alla rispettiva porta;è cosi che funziona soprattutto perchè in molti casi per risparmiare il lavoro ai router nelle reti locali vengono usati gli switch come smistatori(in modo che al router giungano solo i pacchetti destinati all' esterno)...

switch e router non sono dispositivi intercambiabili a piacere, e senza fare troppe discussioni, lo si può vedere dalle definizioni formali : uno switch è un dispositivo datalink in grado di dividere i domini di collisione, un router (livello rete) segmenta i domini di broadcast.





adesso,a parte il fatto che io ho provato ad avviare wireshark sul pc fisso e ad inviare un file al portatile e ho sniffato solo pacchetti smb e arp e quindi nessun pacchetto rarp,mi spieghi poi a cosa servirebbe in tutto il discorso che ti ho detto il protocollo rarp?

come volevasi dimostrare non sai cosa vuol dire supportare un protocollo, nonostante lo abbia spiegato nel post precedente. Significa semplicemente che producendo una richiesta a quel protocollo, ne riceverò (eventualmente) risposta o almeno lo staack è in grado di processare la richiesta stessa. Ciò non vuol dire che sulla rete transiti obbligatoriamente quel tipo di traffico. Per altro su una rete switched il rarp non è sniffabile in quanto circola in unicast.


e anche avendo un piano di indirizzamento statico mi spieghi come faresti a risalire al mac anche a pc spenti? al max potresti usare le entry del dhcp server sempre che questo renda visualizzabile l' associazione ip locale-mac
qui in networking non c' entra nulla, è solo questione di logica : se ho assegnato tutti gli ip tranne uno, a meno di overlapping e spoofing, l' ip utilizzato sarà l' unico disponibile.

[nuovoUtente86]

e giusto per essere precisi
end fra i bit...se il valore dell' end è lo stesso della subnet mask
l' operazione binaria si chiama and e non end (fine). Inoltre il risultato prodotto dall' anding tra destination ip e subnet mask è confrontato con il subnet address e non con la maschera (e del resto non avrebbe senso).

[Spectrum7glr]

Il protocollo rarp,che fa parte del livello datalink, è obbligatorio per chiunque implementi uno stack TCP/IP, in quanto costituisce il mezzo inverso alla risoluzione arp.

occhio che non è propriamente così: il RARP non è l'InARP (che tra l'altro è roba da frame realy)...il RARP serve ad uno scopo differente che è quello di ricavare il proprio IP a partire dal MAC e la richiesta viene esaudita se e solo se sulla rete c'è un server che tratta questo genere di richieste (nessun host "comune" risponde ad una rarp request: l'host fa la richiesta ed un server se dipsonibile risponde).

[nuovoUtente86]

occhio che non è propriamente così: il RARP non è l'InARP (che tra l'altro è roba da frame realy)...il RARP serve ad uno scopo differente che è quello di ricavare il proprio IP a partire dal MAC e la richiesta viene esaudita se e solo se sulla rete c'è un server che tratta questo genere di richieste (nessun host "comune" risponde ad una rarp request: l'host fa la richiesta ed un server se dipsonibile risponde).

Quello che dici è corretto ma è solo uno degli utilizzi del RARP, ovvero nelle vecchie implementazioni in assenza dei server DHCp si utilizzavano i server RARP, in cui ogni host privo di ip ne chiedeva il mapping con una richiesta a codice 3. Ma in ogni caso, seppur obsoleto, il protocollo resto obbligatorio per la suite TCP/IP. Tra l' altro l' rfc stabilisce che, a discrezione dell' implementazione, le reply rarp e arp possano essere considerate equivalenti e quindi messe nella medesima cache.

[Spectrum7glr]

Quello che dici è corretto ma è solo uno degli utilizzi del RARP, ovvero nelle vecchie implementazioni in assenza dei server DHCp si utilizzavano i server RARP, in cui ogni host privo di ip ne chiedeva il mapping con una richiesta a codice 3. Ma in ogni caso, seppur obsoleto, il protocollo resto obbligatorio per la suite TCP/IP.

non dico che quello sia l'unico utilizzo possibile del RARP...dico solo che tra i suoi utilizzi non è conteplata la risoluzione inversa di un arp (se non il proprio: un PC che implementa il RARP* non risponde alle rarp request e si limita a farle), quindi obbligatorio o meno che sia non è utilizzabile per risolvere il quesito del nostro amico :)

*tra l'altro chi risponde al RARP risponde fornendo l'indirizzo IP del richiedente e non fornendo l'indirizzo IP proprio.

[nuovoUtente86]

non dico che quello sia l'unico utilizzo possibile del RARP...dico solo che tra i suoi utilizzi non è conteplata la risoluzione inversa di un arp (se non il proprio: un PC che implementa il RARP non risponde alle rarp request e si limita a farle), quindi obbligatorio o meno che sia non è utilizzabile per risolvere il quesito del nostro amico :)

ed invece qui sbagli, perchè è utilizzabile in quanto chi implementa rarp non si limita solo alle richieste, ma deve rispondere con un reply 4 (secondo alcune implementazioni in broadcast) qualora conasca il mapping (ovvero la macchina stessa, se ovviamente ha già l' ip assegnato in altro modo, ed eventualmente chi ha il dato in arp cache). Ovviamente il pacchetto di richiesta va costruito adeguatamente.

[nuovoUtente86]

tra l'altro chi risponde al RARP risponde fornendo l'indirizzo IP del richiedente e non fornendo l'indirizzo IP proprio
certo risponde fornendo l' ip mappato sul target MAC.

[Spectrum7glr]

ed invece qui sbagli, perchè è utilizzabile in quanto chi implementa rarp non si limita solo alle richieste, ma deve rispondere con un reply 4 (secondo alcune implementazioni in broadcast) qualora conasca il mapping (ovvero la macchina stessa, se ovviamente ha già l' ip assegnato in altro modo, ed eventualmente chi ha il dato in arp cache). Ovviamente il pacchetto di richiesta va costruito adeguatamente.

il pacchetto richiesta potrà anche essere costruito adeguatamente ma se leggi la sezione motivation sulla RFC 2390 (InARP) ti accorgi che RARP non è implementato con quell'utilizzo...il RARP era stato proprosto come candidato per la risoluzione inversa ma poi si è preferito seguire un'altra strada (anche perchè il THA in base alla RFC 903 non è il destinatario diretto della richiesta: è poco efficiente sfruttare un protocollo che richiede un broadcast quando conosciamo il mac del destinatario) per cui allo stato attuale è molto probabile che un server RARP (ammesso che esista sulla rete: cosa tutt'altro che scontata nel 2010) nemmeno tratti una richiesta in cui il SHA è diverso dal THA.

[nuovoUtente86]

il pacchetto richiesta potrà anche essere costruito adeguatamente ma se leggi la sezione motivation sulla RFC 2390 (InARP) ti accorgi che RARP non è implementato con quell'utilizzo...il RARP era stato proprosto come candidato per la risoluzione inversa ma poi si è preferito seguire un'altra strada (anche perchè il THA in base alla RFC 903 non è il destinatario diretto della richiesta: è poco efficiente sfruttare un protocollo che richiede un broadcast quando conosciamo il mac del destinatario) per cui allo stato attuale è molto probabile che un server RARP (ammesso che esista sulla rete: cosa tutt'altro che scontata nel 2010) nemmeno tratti una richiesta in cui il SHA è diverso dal THA.

Concordo sul fatto che possa essere poco efficiente utilizzare un protocollo la cui ultima revisione è datata 1984, ma continui a dire che non funziona, quando non è cosi, seppur se uno degli utilizzi principi (mostrati nel 930) del protocollo è di natura totalmente differente. Ed il perchè funziona risiede proprio nel fatto che non è prevista alcuna verifica di corrispondenza tra target e sorgente.

[Wolfhwk]

Ma di quali dispositivi si parla? Di cisco Catalyst forse?
Se di questo si tratta posso fornire la procedura con linea di comando...
In effetti i catalyst renderebbero superfluo il wireshark e altre utility.

[nuovoUtente86]

Ma di quali dispositivi si parla? Di cisco Catalyst forse?
Se di questo si tratta posso fornire la procedura con linea di comando...
In effetti i catalyst renderebbero superfluo il wireshark e altre utility.

ma puoi farlo solo in un caso, di cui si è già parlato ovvero quando venga generato traffico unicast verso un' interfaccia IP del dispositivo, di cui si va a vedere la arp table.

[Spectrum7glr]

ma puoi farlo solo in un caso, di cui si è già parlato ovvero quando venga generato traffico unicast verso un' interfaccia IP del dispositivo, di cui si va a vedere la arp table.

bè, se hai un catalyst, puoi anche mettere una porta in modalità mirroing/promiscua (SPAN credo si chiami in casa Cisco) ed (al limite) tutto il traffico che attraversa lo swith può essere buttato fuori sulla porta in questione...con sw come wireshark a quel punto puoi riuscire a beccare l'ip incriminato. Ovvio che rischi di mandare lo switch in blocco, però in condizioni di carico normali è un'operazione perfettamente possibile.

[nuovoUtente86]

bè, se hai un catalyst, puoi anche mettere una porta in modalità mirroing/promiscua (SPAN credo si chiami in casa Cisco) ed (al limite) tutto il traffico che attraversa lo swith può essere buttato fuori sulla porta in questione...con sw come wireshark a quel punto puoi riuscire a beccare l'ip incriminato. Ovvio che rischi di mandare lo switch in blocco, però in condizioni di carico normali è un'operazione perfettamente possibile.

Lo si può fare, in maniera non difficile anche con poisoning, ma si tratta in ogni caso di sniffare esternamente allo switch. Per poterlo fare amministrativamente è necessario che ci siano interfacce IP coinvolte attivamente.

[Spectrum7glr]

guarda per me è arabo :fagiano: ...io mi sono limitato a dire che con un catalyst (o switch con funzionalità similari) è una cosa possibile :).

Rimangono due dubbi:
1)l'utente che ha cominciato il thread si sta curando minimamente delle risposte? :stordita:
2)che cavolo fa un dispositivo con un ip fuori dal range della sottorete?comunicare con altri dispositivi non può... non è che magari sulla rete c'è un qualche cavolo di dispositivo assolutamente innocuo (come uno switch managed) che semplcemente è mal configurato (è stato lasciato a default su una sottorete differente)?

[nuovoUtente86]

guarda per me è arabo :fagiano: ...io mi sono limitato a dire che con un catalyst (o switch con funzionalità similari) è una cosa possibile :).

Rimangono due dubbi:
1)l'utente che ha cominciato il thread si sta curando minimamente delle risposte? :stordita:
2)che cavolo fa un dispositivo con un ip fuori dal range della sottorete?comunicare con altri dispositivi non può... non è che magari sulla rete c'è un qualche cavolo di dispositivo assolutamente innocuo (come uno switch managed) che semplcemente è mal configurato (è stato lasciato a default su una sottorete differente)?
L' Ip in questione dovrebbe interdersi appartenente alla subnet. In ogni caso, tutto questo discorso (quindi di tecniche piu o meno funzionanti) nasce dal supporre che la macchina che ha interesse a stare nascosta non produca richieste ARP (altrimenti basterebbe analizzarle, essendo le stesse in broadcast e conteneti il mapping ip-mac della sorgente), il che è alquanto strano normalmente in quanto può verificarsi perchè :
- l' host non produca traffico unicast
- abbia tutti i mapping degli altri host settati in maniera statica
-utilizzi raw packet

[Baboo85]

Si' gente ma quindi? Stavo leggendo il topic ma nessuno ha dato una risposta...

Se uno conosce il mac address, come si risale all'indirizzo ip? Chiedo COME, perche' sono sicuro al 99,999% che il modo c'e'...

[nuovoUtente86]

Si' gente ma quindi? Stavo leggendo il topic ma nessuno ha dato una risposta...

Se uno conosce il mac address, come si risale all'indirizzo ip? Chiedo COME, perche' sono sicuro al 99,999% che il modo c'e'...

La risposta è proprio nel post precedente : se il client in questione non ha interesse a nascondere la propria presenza
richieste ARP (altrimenti basterebbe analizzarle, essendo le stesse in broadcast e conteneti il mapping ip-mac della sorgente)

[Dumah Brazorf]

Apri il prompt del dos.

arp -a

[Baboo85]

Apri il prompt del dos.

arp -a

Mmmmh bello, ma non e' abbastanza. Mi serviva per un indirizzo mac esterno col quale dovevo fare una cosa particolare (niente di illegale, anzi... E' esattamente il contrario) e sarebbe stato bello arrivare all'indirizzo ip sapendo il mac di quella macchina (ad esempio: sono al lavoro, so il mac address del mio router ma non so l'indirizzo ip (perche' e' dinamico per esempio): come risalgo al suo ip attuale?).

Grazie lo stesso :)

[nuovoUtente86]

Mmmmh bello, ma non e' abbastanza. Mi serviva per un indirizzo mac esterno col quale dovevo fare una cosa particolare (niente di illegale, anzi... E' esattamente il contrario) e sarebbe stato bello arrivare all'indirizzo ip sapendo il mac di quella macchina (ad esempio: sono al lavoro, so il mac address del mio router ma non so l'indirizzo ip (perche' e' dinamico per esempio): come risalgo al suo ip attuale?).

Grazie lo stesso :)

Il mac address ha visibilità locale, fuori dal dominio broadcast non ha valore, in quanto sostituito da quello del gateway e dei dispositivi intermedi.

[Baboo85]

Il mac address ha visibilità locale, fuori dal dominio broadcast non ha valore, in quanto sostituito da quello del gateway e dei dispositivi intermedi.

Azz, e' vero, non ci avevo pensato... Quindi nada, grazie mille lo stesso :)

[nuovoUtente86]

Apri il prompt del dos.

arp -a

questo funziona solo nel caso in cui si faccia una richiesta arp diretta, ma nel caso in esame è qualquanto difficile, o comunque l' host potrebbe non rispondere.

[Dumah Brazorf]

E' esattamente il contrario) e sarebbe stato bello arrivare all'indirizzo ip sapendo il mac di quella macchina (ad esempio: sono al lavoro, so il mac address del mio router ma non so l'indirizzo ip (perche' e' dinamico per esempio): come risalgo al suo ip attuale?).

Dyndns.

[Baboo85]

Dyndns.

:confused:

Che c'entra questo?

[Dumah Brazorf]

Beh se non puoi arrivare al router fai sì che sia il router a farsi vivo.

[nuovoUtente86]

:confused:

Che c'entra questo?

Se tu vuoi arrivare su un dispositivo remoto devi farlo a livello logico, non fisico.

[Baboo85]

Beh se non puoi arrivare al router fai sì che sia il router a farsi vivo.

Se tu vuoi arrivare su un dispositivo remoto devi farlo a livello logico, non fisico.

Ma non devo arrivare al router mio :doh: era solo un esempio dimostrativo di quello che mi serviva fare...

Se e' per quello tra Team Viewer e No-Ip gia' sono a posto sinceramente e altre cose non mi servono...

Vabbe', ciao a tutti...

[nuovoUtente86]

Ma non devo arrivare al router mio :doh: era solo un esempio dimostrativo di quello che mi serviva fare...

Se e' per quello tra Team Viewer e No-Ip gia' sono a posto sinceramente e altre cose non mi servono...

Vabbe', ciao a tutti...

qualsiasi cosa ti serve fare, fuori dalla tua rete non ti serve il mac address. Se l' host si trova nella tua rete, è già stato spiegato cosa fare.
Non ci sono altre combinazioni di utilizzo.

[cionci]

Se questo PC è visibile in rete, è comunque possibile usare nbtscan ;)
http://unixwiz.net/tools/nbtscan.html