Newsgroup: it.comp.sicurezza.varie
Titolo: il broadcast del TCP/IP

Ciao a tutti,
ho visto che alcuni programmi di monitor della LAN possono effettuare
un richiesta in broadcast che forza tutti i PC/apparti collegati
in rete con TCP/IP a rispondere con il loro IP e relativo
MAC address.
SI PUO' IMPEDIRE che un PC connesso in rete risponda a questa
richiesta restando quindi nascosto???
Grazie e ciao
-- 
Togliete "bloccaspamm" dall'indirizzo per rispondere via e-mail

 richiesta restando quindi nascosto???
Se e' Unix si, se e' Windows non credo, Se viene da fuori della LAN
il traffico broadcast puo' (e DEVE) essere bloccato dal router.
Tieni presente che impedire la risposta a un broadcast MAC da una
macchina puo' far si che i router e le altre macchine in LAN non 
la "vedano" piu' e causare molti grattacapi.
Ritornando alla domanda: per unix/Linux/NetBSD/etc "man ipf", per
Windows sei offtopic su tutti e tre i gruppi dove hai postato: prova
uno dei gruppi specifici di Windows.
Ciao,
-- 
Andrea

richiesta restando quindi nascosto???
Non c'entra TCP/IP: quello che dici tu somiglia di piu' ad ARP (Address
Resolution Protocol). Il pacchetto ARP e' alternativo ad IP. Quando uno
host riceve un broadcast ARP, ed il suo IP e' quello specificato (YOUR_
ADDR), allora risponde. Il pacchetto ARP e' all'incirca
[HW][PROTO][OP]
[HWADDR_LEN][PROTOADDR_LEN]
[YOURHW_ADDR][YOUR_ADDR]
[MYHW_ADDR][MY_ADDR]
(garantisco freschezza, non verita')
Per esempio:
go:/root # (sleep 10;arp -d kazzimazzi;ping -c 1 kazzimazzi >/dev/null) &
[1] 4419
go:/root # tcpdump -i eth0 arp
tcpdump: listening on eth0
18:18:49.906683 arp who-has kazzimazzi tell 
go.screw.it
18:18:49.906683 arp reply kazzimazzi is-at 0:40:5:32:6b:5f
2 packets received by filter
0 packets dropped by kernel
...in questo caso quando 
go.screw.it
 si e' accorto di non sapere chi fosse lo
host kazzimazzi (in realta' 
tar.kazzimazzi.screw.it
, ma e' un altro discorso)
ha mandato una query ARP. Questo, dopo che il DNS gli ha detto che kazzimazzi
faceva parte della sua subnet (almeno voglio credere & sperare).
Fare in modo che il PC stia zitto... mah. Non so se convenga. Di norma, credo
che il terminal server debba agire da proxy ARP e non far passare NIENTE da o
per il tuo PC (se e' al modem che stai pensando). Negli altri casi ARP e RARP
servono a qualcosa, e interromperne il funzionamento vuol dire cercarsi rogne
con il lanternino.
In genere: se la query ARP viene dalla tua sottorete, DEVI rispondere. Se non
viene dalla tua sottorete, prendi chi t'ha venduto il router e ti lamenti, in
quanto non e' previsto che tu ti debba sorbire tutta la ***** dall'esterno.
Ho letto di recente proprio qui di un software che verifica chi altri c'e' su
un dato TS; non so se usi ARP, SNMP o cos'altro, ma non dovrebbe funzionare a
meno del solito provider "cantinaro" ((C)Marco d'Itri). Oltretutto, via modem
il MAC del PPP dovrebbe essere 00-00-00-00-00-00 (che dice WinIpCfg?). Ma non
so se ti interessa il _modem_ o la rete in generale.
Tornando all'accecamento di ARP - riuscirci con Linux e' abbastanza semplice,
vai dentro 
	/usr/src/linux/net/ipv4/arp.c
cerchi una funzione che si chiama
	int arp_rcv
e subito dopo le dichiarazioni aggiungi:
	kfree_skb(skb, FREE_READ);
	return EXIT_SUCCESS;
dopodiche' ricompili e aspetti lo schianto, che non tardera' :-)
In Windows, e' uguale: vai dentro
	C:\DEVEL\SOURCE\NETWORK\TCPIP\PROTO\LOWLEVEL\ARP.C
cerchi una funzione che si chiama
	int llnetARP_Read
e subito dopo le dichiarazioni aggiungi:
	return 0;
dopodiche' ricompili (tanto non si ricompila) e aspetti lo schianto, ammesso,
naturalmente, che si possa distinguerlo da quelli soliti.
Altri sistemi di "broadcast reply" sarebbero il PING (o meglio, smurf), pero'
anche qui se il provider non e' un cantinaro non te lo fa fare. E non conosci
comunque il MAC del ricevente.
Leonardo
".signature": bad command or file name