Come si contrasta un conflitto d'indirizzo ip?
Jst
autoassegni un indirizzo ip già esistente come lo si può contrastare per
evitare problemi di conflitti con altre macchine? Thanks
Rm.
Lorenzo Mainardi
O si cambia l'ip oppure si usa un dhcp
--
"Le opinioni dei fanatici prescindono dai fatti"
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"
Linux Registered User: 461615
Jst
l'obiettivo non è cambiare il mio ip ma contrastare chi se ne è
impossessato, non posso usare il dhcp.
morph3us
> l'obiettivo non è cambiare il mio ip ma contrastare chi se ne è impossessato,
> non posso usare il dhcp.
ma viene fatta di proposito per disturbare questa cosa?
magari prova ad usare tu un ip 'strano' es 192.168.1.123 (se la subnet
è 255.255.255.0), cosi ridurrai la probabilità di un conflitto voluto.
Luca
stellare lun 15 set 2008 07:28:02p dicendo:
> l'obiettivo non è cambiare il mio ip ma contrastare chi se ne è
> impossessato.
Se Tizio, che ha i diritti di amministrazione della sua macchina, sceglie
coscientemente di assegnarsi un IP esistente, tu, dalla tua parte della
sedia, non puoi farci niente. Dalla SUA parte della sedia invece puoi:
a) dirgli di non farlo
b) togliergli i diritti di administrator
c) togliergli il cavo di rete
d) impiccarlo col suddetto cavo di rete
Non necessariamente in quest'ordine... :-)
Jst
> coscientemente di assegnarsi un IP esistente, tu, dalla tua parte della
> sedia, non puoi farci niente. Dalla SUA parte della sedia invece puoi:
E' un policlinico universitario di diversi edifici diversi migliaia di
client, non è facile individuarlo. Il tipo in questione ha volutamente
scelto un ip di un server interno creando non pochi problemi, forse realizza
il tutto con un notebook. La sua macchina è anche ben protetta. Esiste una
possibilità di risalire alle porte del router/switch da dove lui si
connette? Gli apparati sono dei cisco non proprio nuovissimi.
Luca
> E' un policlinico universitario di diversi edifici diversi migliaia di
> client, non è facile individuarlo. Il tipo in questione ha volutamente
> scelto un ip di un server interno creando non pochi problemi, forse
> realizza il tutto con un notebook. La sua macchina è anche ben
> protetta. Esiste una possibilità di risalire alle porte del
> router/switch da dove lui si connette? Gli apparati sono dei cisco non
> proprio nuovissimi.
Se i Cisco in questione sono managed e ne hai accesso, ci puoi provare.
Fai una arp request per quell'IP, verificando che ti risponda più di un
mac address. Quello del server (che conosci perchè puoi leggerlo sulla
macchina) lo escludi, e cominci a cercare switch per switch in quale arp
table trovi il mac address incriminato a colpi di SHO ARP. Una volta
trovata l'interfaccia, puoi seguirla ed applicare il punto c e d del
messaggio precedente :-)
Se gli switch non sono managed, condoglianze... :-/
tacci_tua
"Luca" <nom...@invalid.default.com> ha scritto nel messaggio
news:Xns9B1AD1F753B7F...@194.177.98.144...
>
> Se i Cisco in questione sono managed e ne hai accesso, ci puoi provare.
> Fai una arp request per quell'IP, verificando che ti risponda più di un
> mac address. Quello del server (che conosci perchè puoi leggerlo sulla
> macchina) lo escludi, e cominci a cercare switch per switch in quale arp
> table trovi il mac address incriminato a colpi di SHO ARP. Una volta
> trovata l'interfaccia, puoi seguirla ed applicare il punto c e d del
> messaggio precedente :-)
>
> Se gli switch non sono managed, condoglianze... :-/
Anche tracert potrebbe aiutarlo... credo...
Omero
é un po da pazzi comunque non appogiarsi al dhcp (magari + radius) in
una struttura così grande.
così tanti pc saranno in parecchie sotto reti credo. quindi non so
come sei configurato ma non è che hai una sotto rete per piano o
suddivisa in qualche modo che ti possa far restringere gli switch dove
può essersi collegato?
un tracert?
e senò appunto apparato per apparato ma poi quando lo trovi una bel
taglio con la forbice al cavo di rete.
ma questo pc rimane sempre acceso?
se si collega dopo che il server si è ripreso il suo ip lui non può
più entrare.
hai provato un semplice \\ip per vedere se ha condiviso qualche cosa?
Ciao
Jst
Sono aziende pubbliche dove si mischia obsolescenza con innovazione, pensa
che esistono ancora vivi e vegenti un paio di Windows 3.1! Sě esistono tante
sottoreti, per piano per edificio. Il tracert non credo riesca a tornarmi
utile forse piů l'idea dell'arp request e poi indagare switch per switch.
Non ha condiviso niente perchč č un furbo il sospetto č che sia un
dipendente interno dato che non č casuale la scelta proprio dell'ip in
questione. Ovviamente deve avere un notebook con un sistema server
installato perchč non subisce il respingimento dei sistemi operativi di
livello superiore.
Omero
> >...
>
> Sono aziende pubbliche dove si mischia obsolescenza con innovazione, pensa
> sottoreti, per piano per edificio. Il tracert non credo riesca a tornarmi
> Non ha condiviso niente perchè è un furbo il sospetto è che sia un
> dipendente interno dato che non è casuale la scelta proprio dell'ip in
> questione. Ovviamente deve avere un notebook con un sistema server
> livello superiore.
il tracert dobrebbe farti vedere i salti di sotto rete, se non hai
bloccato l'icmp a livello di switch.
ma non avrai mica il routing completamente aperto?
da me se mi metto in uno switch con una certa sotto rete non posso
impostare una sotto rete diversa in una macchina o meglio lo posso
fare ma lo switch di piano non mi fa uscire dal piano e rimago
isolato, i server sono in una sotto rete diversa e è il centro stella
a fare il routing tra le sottoreti, in questo modo nessuno può
impostarsi un ip di un server. Ma è un'altra configurazione......
Pensa cosa ti succede se ti fanno un bel port to port in uno switch
(chi capisce capisce meglio non fare troppa publicità).
Ciao
Ciao
Valerio Vanni
>Sono aziende pubbliche dove si mischia obsolescenza con innovazione, pensa
>che esistono ancora vivi e vegenti un paio di Windows 3.1! Sě esistono tante
>sottoreti, per piano per edificio.
Allora puoi intanto capire la sottorete e quindi il piano.
>Ovviamente deve avere un notebook con un sistema server
>installato perchč non subisce il respingimento dei sistemi operativi di
>livello superiore.
Di cosa stai parlando?
--
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.
Luca Sasdelli
> E' un policlinico universitario di diversi edifici diversi migliaia di
> client
"Diverse migliaia di client" significa un enorme rischio in termini di
sicurezza; credo sia indispensabile impiegare un sistema in grado di
gestire il traffico, altrimenti son dolori. Dai un'occhiata a Dragon di
Enterasys, e comunque andrebbe preso in considerazione un sistema che
intervenga a livello sia di MAC che di protocollo (es. il client con
MAC xxx ha accesso solo a servizi di tipo yyy).
Ciao
Luca
Jst
> considerazione un sistema che intervenga a livello sia di MAC che di
> protocollo (es. il client con MAC xxx ha accesso solo a servizi di tipo
> yyy).
Ancor prima di questo basterebbe implementare un dhcp, dominio e policy
robuste, per essere ad un livello di molto superiore ma la spesa è ingente e
non so' perchè ma l'informatica finisce sempre per essere scavalcata da
altro. Alle volte c'è un abisso tra privato e pubblica amministrazione.
Comunque se la questione si risolve vi terrò informati con un post. Grazie a
tutti per gli utili consigli.
Andrea D'Amore
Valerio Vanni <valeri...@inwind.it> wrote:
> Di cosa stai parlando?
Fremo di curiosità anche io.
Andrea D'Amore
morph3us <morph...@gmail.com> wrote:
> ma viene fatta di proposito per disturbare questa cosa?
Se non ho capito male è uno che si attacca col computer, ha provato un
ip address a cazzo per non perdere tempo a chiedere l'autorizzazione e
naviga lieto ignaro del fastidio che crea al server legittimo.
Omero
Sicurezza DPS e legge sulla privacy in un'ospedale sono il diritto del
cittadino, vedi cosa li fanno al primo dirigente appena succede
qualche cosa.
Per non parlare della possibilità di furto di dati da parte di
chiunque infili un portatile in rete.
3.11 forse solo in qulche appa. elettromedicale si può ancora
accettare ma per altri usi bisognerebbe bandire tutto fino al 2000
pro.
L'abisso non c'è dapertutto....
Ciao facci sapere.
Andrea B.
> é un po da pazzi comunque non appogiarsi al dhcp (magari + radius) in
E' un po da pazzi lasciare che il primo venuto possa maneggiare sulle
impostazioni di rete.
--
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa
scrittura, non so per chi, non so piů intorno a che cosa...
U. Eco
Luca
stellare lun 15 set 2008 09:23:17p dicendo:
> se si collega dopo che il server si è ripreso il suo ip lui non può
> più entrare.
E cosa glielo impedirebbe? La dialog di allarme di windows che segnala IP
duplicato? ;-)
Lorenzo Mainardi
>
> Se gli switch non sono managed, condoglianze... :-/
La vedo buia lo stesso...
Qui ci vorrebbe una riprogettazione dell'intera rete da zero.
Comunque potresti anche mettere uno switch con una porta in span e
cercare con tcpdump e un po' di filtri di capire da dove viene, chi è e
che tipo di traffico sta facendo
Luca
> Nel mezzo del cammin di nostra vita, mi ritrovai con Luca che diceva:
> > Se gli switch non sono managed, condoglianze... :-/
> La vedo buia lo stesso...
Beh dai, è effettivamente difficile e ci vuole anche un pizzico di
fortuna, ma si può fare. Certo, essendoci il "dolo" dipende da quanto
è sveglio il "cacciatore" e da quanto lo è la "preda".
A me è successo una volta sola (in una realtà dimensionalmente simile,
e non avevo neanche accesso all'infrastruttura di rete) e ci ho messo
una settimana facendo le trace direttamente sugli armadi di piano...
(era l'epoca degli hub, gli switch erano ancora poco diffusi) ma alla
fine l'ho beccato... ha passato un brutto quarto d'ora... e intendo
dire PRIMA di essere buttato fuori a calci. :-)
Infinity
Jst (<48cea69f$0$40315$4faf...@reader5.news.tin.it>) ha scritto:
>E' un policlinico universitario di diversi edifici diversi migliaia di
>client, non č facile individuarlo. Il tipo in questione ha volutamente
>scelto un ip di un server interno creando non pochi problemi
Aggiungo un dettaglio.
Il rompiscatole non ha scelto un IP qualunque. Non ha scelto un IP libero
e disponibile, che sarebbe passato inosservato.
Ha scelto l'IP di un SERVER.
Ed il suo notebook, da quello che dici, sembra ben protetto.
Non credi che voglia farci qualcosa, con quel server?
Magari IMPERSONARE il server, per intercettarne il traffico, o per
modificarne i dati?
Non so cosa ci sia, su quel server, ma se fossi in te, inizierei un
controllo A TAPPETO della correttezza dei dati che transitano su quel
server, per escudere eventuali manomissioni.
Se vuoi sbattere fuori definitivamente l'intruso (ed anche tutti quelli
futuri) occorre lavorare sulla sicurezza della rete, e quindi:
1- Attivare il controllo del MAC address dei client collegati.
2- Attivare l'autenticazione dei client collegati
3- Possibilmente, usare un server Radius per l'autenticazione.
Con un sistema di questo tipo, gli accessi indesiderati scompaiono. :-)
Ciao! :-)
--
-----
| NFINITY is so far as you want to see.
-----
Codice-Wii: 0474-9673-2703-9448
Se vuoi rispondermi in E-Mail, sopprimi la politica. ;-)
Mirko Borsari
tra sistemi windows è il secondo che arriva con lo stesso ip a
rimanere fuori, non il primo. Quindi se il server è attivo il client
con lo stesso ip rimane fuori (tra l'altro per trovare il MAC basta
guardare nel event viewer).
Non so cosa succede usando linux
--
MirkoB. ne...@bsi-net.it
Motoretta BMW R1150R Nera...
L'indirizzo em@il non è da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente.
Luca
direttiva in data stellare mer 17 set 2008 08:42:26p dicendo:
> tra sistemi windows è il secondo che arriva con lo stesso ip a
> rimanere fuori, non il primo.
> Quindi se il server è attivo il client con lo stesso ip rimane fuori
Tra sistemi di qualunque tipo, al di la del warning, nessuno "rimane
fuori" per intervento divino. Se non esiste sulla rete una entità in grado
di sezionare il traffico a livello 3, puoi mettere sulla LAN tremila
macchine con lo stesso indirizzo IP (beh no diciamo con almeno due
indirizzi diversi) e con le dovute arp entries farle persino funzionare.
Sotto windows il fatto che il driver di sistema ti blocca se tenti di
assegnare un IP già esistente è irrilevante, basta NON usare un driver di
sistema.
Sotto linux, a memoria non ho mai ricevuto un warning di IP duplicato.
Mirko Borsari
>> tra sistemi windows è il secondo che arriva con lo stesso ip a
>> rimanere fuori, non il primo.
>> Quindi se il server è attivo il client con lo stesso ip rimane fuori
>
> Tra sistemi di qualunque tipo, al di la del warning, nessuno "rimane
> fuori" per intervento divino. Se non esiste sulla rete una entità in grado
ho semplicemente detto che con sistemi windows normali e senza
impostazioni particolari il secondo che entra con ip identico
all'altro rimane fuori dalla rete (con relativa segnalazione e log del
MAC, anche un ipconfig te lo conferma).
Non è un intervento divino, è windows che funziona così (normalmente e
senza interventi particolari).
> Sotto windows il fatto che il driver di sistema ti blocca se tenti di
> assegnare un IP già esistente è irrilevante, basta NON usare un driver di
> sistema.
ripeto che io parlavo della normalità, se poi uno si va a modificare
lo stack tcp-ip è un discorso diverso.
Poi, per curiosità, mi indicheresti un "driver non di sistema" per
fare 2 prove?
Luca
> ho semplicemente detto che con sistemi windows normali e senza
> impostazioni particolari il secondo che entra con ip identico
"dolo"... e quando c'è la volontà di aggirare determinati meccanismi
che si danno per scontati, di solito ci si fa male.
> > Sotto windows il fatto che il driver di sistema ti blocca se tenti di
> > assegnare un IP già esistente è irrilevante, basta NON usare un driver di
> > sistema.
> ripeto che io parlavo della normalità, se poi uno si va a modificare
> lo stack tcp-ip è un discorso diverso.
Eh ma secondo te uno che cerca di sostituirsi ad un server è "la
normalità"? :-)
> Poi, per curiosità, mi indicheresti un "driver non di sistema" per
> fare 2 prove?
Non direttamente. Quelli che ho installato io su una delle macchine
che uso per lo sviluppo, che sono "development version" di un noto
produttore di schede di rete, accettano tranquillamente un IP
esistente senza neanche avvisare.
Ed inoltre, per come windows gestisce la ricerca degli IP, ci sono
buone possibilità che se tu prendi il tuo PC, stacchi il cavo di rete,
gli assegni un IP duplicato, e poi riattacchi il cavo di rete, quello
che indicherà IP duplicato non sarà il tuo.
Mirko Borsari
>> ho semplicemente detto che con sistemi windows normali e senza
>> impostazioni particolari il secondo che entra con ip identico
> Lo so benissimo, ma ricordati sempre che in questo caso c'è il
> "dolo"... e quando c'è la volontà di aggirare determinati meccanismi
chi ha detto che c'è il dolo? Potrebbe essere ma non ne abbiamo la
certezza, nemmeno l'OP! Non ci sarebbe nulla di strano, che
assegnandosi un IP solo per scroccare un po' di banda con il portatile
personale vadano a beccare giusto quello di un server.
>> ripeto che io parlavo della normalità, se poi uno si va a modificare
>> lo stack tcp-ip è un discorso diverso.
> Eh ma secondo te uno che cerca di sostituirsi ad un server è "la
> normalità"? :-)
il tipo, per ora, è "semplicemente" uno che si è autoassegnato un IP a
caso. Che volesse sostituirsi è da vedere.
> Ed inoltre, per come windows gestisce la ricerca degli IP, ci sono
> buone possibilità che se tu prendi il tuo PC, stacchi il cavo di rete,
> gli assegni un IP duplicato, e poi riattacchi il cavo di rete, quello
> che indicherà IP duplicato non sarà il tuo.
Il secondo rimane comunque fuori. Già provato.
Luca
> chi ha detto che c'è il dolo? Potrebbe essere ma non ne abbiamo la
> certezza, nemmeno l'OP! Non ci sarebbe nulla di strano, che
> assegnandosi un IP solo per scroccare un po' di banda con il portatile
> personale vadano a beccare giusto quello di un server.
volutamente
scelto un ip di un server interno creando non pochi problemi" ...
"Volutamente" IMHO significa che l'ha fatto apposta... e quindi c'è il
dolo.
> > Ed inoltre, per come windows gestisce la ricerca degli IP, ci sono
> > buone possibilità che se tu prendi il tuo PC, stacchi il cavo di rete,
> > gli assegni un IP duplicato, e poi riattacchi il cavo di rete, quello
> > che indicherà IP duplicato non sarà il tuo.
> Il secondo rimane comunque fuori. Già provato.
Hai circa una possibilità su due. Già provato decine di volte,
comprese un paio di volte in cui per un problema sulle configurazioni
delle sottoreti, via DHCP è stato assegnato ad una macchina un IP già
assegnato ad un'altra regolarmente connessa. Quella ad essere "buttata
fuori" è stata la macchina che aveva preso l'indirizzo in precedenza.
Infatti anni fa, prima che sistemassimo una volta per tutte la
questione degli IP e delle sottoreti, non era raro vedere al mattino
l'avviso di IP duplicato **sui server** che avevano IP statico ed
erano accesi e connessi sempre, perchè qualcuno era arrivato col
portatile che aveva mantenuto un IP sbagliato. In effetti erano i
tempi di NT server, per cui magari adesso le cose sono cambiate.
Comunque il discorso resta valido: se VUOI prenderti un IP doppio, lo
fai.
Mirko Borsari
>> chi ha detto che c'è il dolo? Potrebbe essere ma non ne abbiamo la
>> certezza, nemmeno l'OP! Non ci sarebbe nulla di strano, che
>> assegnandosi un IP solo per scroccare un po' di banda con il portatile
>> personale vadano a beccare giusto quello di un server.
> Veramente l'OP ha scritto testuali parole "Il tipo in questione ha
> volutamente
> scelto un ip di un server interno creando non pochi problemi" ...
> "Volutamente" IMHO significa che l'ha fatto apposta... e quindi c'è il
> dolo.
si certo, ma se l'op fosse certo della cosa saprebbe anche chi è il
personaggio in questione.
Lui immagina che se lo sia preso volutamente... ma non ne è certo!
Fermo restando che il tipo è da "punire" non possiamo essere certi che
voglia fare dei danni volutamente.
>> Il secondo rimane comunque fuori. Già provato.
> Hai circa una possibilità su due. Già provato decine di volte,
> comprese un paio di volte in cui per un problema sulle configurazioni
> delle sottoreti, via DHCP è stato assegnato ad una macchina un IP già
> assegnato ad un'altra regolarmente connessa. Quella ad essere "buttata
> fuori" è stata la macchina che aveva preso l'indirizzo in precedenza.
Via DHCP non ho mai provato, quindi non so come si comportano.
Potrebbe anche essere il server che revoca il lease.
> Infatti anni fa, prima che sistemassimo una volta per tutte la
> questione degli IP e delle sottoreti, non era raro vedere al mattino
> l'avviso di IP duplicato **sui server** che avevano IP statico ed
> erano accesi e connessi sempre, perchè qualcuno era arrivato col
Fino a win2000 sicuramente, l'avviso avviene anche sul primo pc
correntemente connesso alla rete, ma comunque rimane in rete.
> Comunque il discorso resta valido: se VUOI prenderti un IP doppio, lo
> fai.
questo è palese, rimane comunque il dubbio che la cosa sia voluta o
meno.
Luca
> > "Volutamente" IMHO significa che l'ha fatto apposta... e quindi c'è il
> > dolo.
> si certo, ma se l'op fosse certo della cosa saprebbe anche chi è il
> personaggio in questione.
> Lui immagina che se lo sia preso volutamente... ma non ne è certo!
> Fermo restando che il tipo è da "punire" non possiamo essere certi che
> voglia fare dei danni volutamente.
Vero. A questo punto dato che non possiamo contare su un reparto "pre-
crimine" in stile Minority Report, possiamo solo sperare che l'OP
becchi il fedifrago e ci tenga aggiornati. Io punto i miei 2 cents
sulla malafede... :-)
Omero
>
> >> tra sistemi windows è il secondo che arriva con lo stesso ip a
> >> rimanere fuori, non il primo.
> >> Quindi se il server è attivo il client con lo stesso ip rimane fuori
>
> > Tra sistemi di qualunque tipo, al di la del warning, nessuno "rimane
> > fuori" per intervento divino. Se non esiste sulla rete una entità in grado
>
> ho semplicemente detto che con sistemi windows normali e senza
> impostazioni particolari il secondo che entra con ip identico
> all'altro rimane fuori dalla rete (con relativa segnalazione e log del
> MAC, anche un ipconfig te lo conferma).
> Non è un intervento divino, è windows che funziona così (normalmente e
> senza interventi particolari).
>
> > Sotto windows il fatto che il driver di sistema ti blocca se tenti di
> > assegnare un IP già esistente è irrilevante, basta NON usare un driver di
> > sistema.
>
> ripeto che io parlavo della normalità, se poi uno si va a modificare
> lo stack tcp-ip è un discorso diverso.
> Poi, per curiosità, mi indicheresti un "driver non di sistema" per
> fare 2 prove?
>
> --
> Motoretta BMW R1150R Nera...
>
> L'indirizzo em@il non è da considerarsi pubblico,
> ma utilizzabile solo per temi inerenti il NG corrente.
Anche io ho sempre saputo così infatti mi chiedevo come è possibile
che un server che rimane sempre acceso si perde l'ip (nel senso che
qualcuno riesce a trovare un momento dove il server e offline per
prendere il suoposto)
Ciao
Mirko Borsari
scritto:
>
> Anche io ho sempre saputo cosě infatti mi chiedevo come č possibile
> che un server che rimane sempre acceso si perde l'ip (nel senso che
> qualcuno riesce a trovare un momento dove il server e offline per
> prendere il suoposto)
a me qualcosa non torna in sta storia...
--
MirkoB. ne...@bsi-net.it
Motoretta BMW R1150R Nera...
L'indirizzo em@il non č da considerarsi pubblico,