Newsgroup: it.comp.os.linux.sys
Titolo: Un aiutino su iptables

Siccome ho cambiato gestore telefonico e quindi anche per l'adsl, il 
nuovo gestore mi ha mandato il "tostapane" praticamente bloccato sulla 
configurabilitï¿œ.. Ora.. siccome questo "tostapane" ha il dhcp attivato e 
non posso disattivarlo in alcun modo, avevo pensato di bloccarne i 
pacchetti in ingresso, ma non ci riesco.. I comandi che passo con 
iptables sono i seguenti:
iptables -A INPUT -s 192.168.1.1 -i eth0 -p udp --dport 67:68 -j DROP
iptables -A OUTPUT -d 192.168.1.1 -o eth0 -p udp --sport 67:68 -j DROP
Dove sbaglio ?


Specifico: trattasi della vodafone station, e siccome ï¿œ collegato al 
wrt54gl che ho giï¿œ configurato a dovere sulla la mia rete e ha il dhcp 
attivo e perfettamente funzionante, da qui nasce la necessitï¿œ di 
disattivare quello sulla "vs" per evitare conflitti.
Saluti a tutti e scusate se non mi sono spiegato bene nel primo post, ma 
la fretta non mi ha permesso di concludere il concetto.

 Dove sbaglio ?
Nel considerare che i pacchetti DHCP che passano attraverso il tuo wrt 
passino attraverso le catene di input e output.
E nel pensare che il DHCP cominci le sue transazioni con pacchetti che 
contengono un IP sorgente/destinazione della tua subnet.

 Davide
Ciao.. Mi sta bene, ma se io copio pari pari questa regola che ho 
trovato sulla guida di gentoo:
http://www.gentoo.org/doc/it/gentoo-mips-faq.xml
nella fattispecie:
iptables -I INPUT 1 -p udp --dport 67:69 -j ACCEPT
e modifico la policy in DROP direttamente sul pc dove sto operando ora, 
perch� continua a ricevermi il dhcp del router ?

 contengono un IP sorgente/destinazione della tua subnet.
Capito anche questo, ma prima di aprire il thread ho googlato un po' e 
ho trovato delle regole scritte che hanno per politica ACCEPT; quindi le 
ho prese, modificate per la mia lan e la sto provando sul portatile, 
dove in questo momento l'obiettivo è scartare la richiesta del dhcp del 
"tostapane" e permettere quella del wrt54gl, ma tutte quelle che ho 
provato (è brutto sparare nel mucchio, ma quando non ne vieni a capo fai 
qualsiasi cosa) non funzionano... Non mi pare che debba riavviare 
qualcosa.. imho..
Questi sono i link dove mi sono consultato;
http://tinyurl.com/3yurcr9
http://tinyurl.com/367ozjw
 , e da qui ho prelevato le seguenti righe
iptables -A FORWARD -p udp --dport 67 -j ACCEPT
iptables -A FORWARD -p udp --dport 68 -s 172.16.105.5 -j ACCEPT
modificando l'ip con quello del router da bloccare, la policy FORWARD in 
INPUT e sostituendo ACCEPT con DROP.
Da come mi hai risposto, posso anche pensare che non sia un compito di 
iptables, ma allora sono sbagliati tutti i riferimenti su cui mi sono 
basato.. oppure come più probabile è che a me sfugge qualcosa di 
macroscopico.. :-)
Ciao, Davide.

 la fretta non mi ha permesso di concludere il concetto.
Scusa, se hai il tuo bravo router che funziona ed è già collegato alla tua 
rete, non basta disattivare il DHCP Relay sul tuo router?


Il dhcp sul wrt54gl deve rimanere attivo, mentre voglio disattivarlo 
sulla vodafone station ma purtroppo non è possibile perché è bloccato 
secondo una precisa politica del gestore... aggiungo del tutto stile 
cino-coreana, ma mi fermo qui perché non è il canale adatto per fare 
della polemica; da qui l'idea di "bannarlo" tramite iptables, ma non 
riesco a venirne fuori.
Ciao, Davide.

> Dove sbaglio ?
La wodafone station e' collegata alla port wan del ruter e i tuoi pc alla wifi e alle porte dello switch ok?
Tu vuoi che la porta wan prenda un ip dal dhcp di vodafone o la imposti tu ad un certo ip statico ?
E le macchine dietro il router dovono appartenere all stessa net della porta wan o possono essere considerate dietro NAT?
Giulia

 porta wan o possono essere considerate dietro NAT?
No.. Tutti i pc devono stare sulla net del wrt lato lan.. In pratica 
come lo è adesso, ma sto aspettando che mi disattivino il vecchio 
gestore per passare a quello nuovo e intanto volevo prepararmi alla 
nuova configurazione. Questo è lo schema;
modem/adsl -- wrt54gl -- wrt54g(repeater) -- macchine
In questa configurazione l'unico che ha il dhcp attivo è il wrt54gl.. 
Oddio.. Se l'esistenza del dhcp sulla "vs" non crea problemi quando 
metto le macchine in rete non è che sia un gran problema, ma ho letto in 
lungo e in largo che due dhcp presenti sulla stessa lan sono spesso 
causa di conflitti.. Tra l'altro sul wrt ho filtrato l'accesso tramite 
mac-address e solo tre mac-address hanno un ip che il router gli assegna 
in modo statico.. Se ciò non crea conflitti posso anche lasciarlo 
attivo, ma non vorrei che quando collego uno dei pc con quel mac-address 
mi prenda l'ip della net della vs.
Ciao e grazie, Davide.

 Dove sbaglio ?
Nel kernel il protocollo dhcp parte a un livello piï¿œ basso di iptables; 
ecco perchï¿œ non si riesce a bloccare le richieste che arrivano sulla 
porta 67.. Dovrei specificare il diniego sul file dhclient.conf, ma mi 
devo studiare la distro per vedere dove va a leggere il file, ma non ï¿œ 
questo l'obiettivo che mi ero prefissato.
Dal wrt54gl probabilmente dovrei farcela impostando delle regole in modo 
forward e negare che questi pacchetti transitino sulla lan.. e CtRiX ha 
detto giustamente..
Ciao e grazie a tutti, Davide.

 porta 67.. 
Cioè stai dicendo che non è possibile bloccare il dhcp tramite iptables?
Se è così, è sbagliato, l'ho faccio praticamente su ogni firewall senza 
problemi.
O, più probabilmente, non ho capito il tuo discorso.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 porta 67.
No, non hai capito. Il DHCP funziona a livello 4 dato che è UDP e netfilter
opera ai livelli 3 e 4. Quindi non è quello il problema.
Il tuo problema è che la richiesta dhcp è fatta via broadcast e che la
catena che lavora, se il pacchetto attraversa l'apparato, è quella di forward.
iptables -A FORWARD -p udp --dport 67:68 -j DROP
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)


Ne ho discusso stamattina con una persona, il quale, sfogliando il 
kernel, mi ha fatto notare che il dhcp viene caricato direttamente dal 
kernel.. Io non me ne intendo.. sono sincero e ammetto il mio limite, 
quindi qualsiasi cosa scrivete per me è fonte di conoscenza acquisita, 
però dalle prove che faccio io sembrerebbe confermare l'ipotesi che ho 
espresso.. In pratica; se io, da un client (e non dal router), come il 
notebook su cui sto lavorando ora, volessi impedire che il server dhcp 
con ip 192.168.1.1 mi rilasci un ip, piuttosto che usare iptables, devo 
farlo mediante il file dhclient.conf (o chi per lui), altrimenti non 
riesco a bloccare la richiesta.. Se invece uso iptables sul router (nel 
mio caso il wrt54gl), allora posso bloccare il transito dei pacchetti 
diretti sulle porte 67, 68 e 69 mediante iptables. Questo è ciò che mi 
ha spiegato.


Si.. ok.. sicuramente vi ho messo fuori strada io.. Al momento io non 
stavo lavorando sul router, ma sul client (un portatile) e stavo 
tentando, mediante iptables, di bloccare la negoziazione dhcp senza però 
riuscirci.. E' vero che poi la regola l'avrei dovuta inserire sul 
router, e quindi è giusta la chain FORWARD, ma prima di agire sul router 
volevo fare qualche prova sul portatile per verificare il funzionamento, 
ma devo constatare che le configurazioni sono diverse.. Come ho risposto 
a Gandalf, la mia preparazione su questa materia è del tutto 
autodidattica e quindi qualsiasi cosa voi scrivete, per me è solo fonte 
di conoscenza acquisita, però dalle prove fatte sembra dar ragione alla 
persona con cui ho parlato stamattina... Difatti ora, mettendo la regola 
sul router, la negoziazione dhcp non avviene più sulla rotta per la 
vodafone station..
Ma tanto prima o poi la sbloccherò.. già mi sono messo alla ricerca di 
una j-tag adatta allo scopo.. :-)
Ciao, Davide.

 riuscirci..
Si fa anche sul client comunque senza problemi:
iptables -I INPUT -p udp --dport 68 -j DROP
iptables -I OUTPUT -p udp --dport 67 -j DROP
Riguardo all'altro post di pure al tuo amico che si riguardi come funziona
il networking su Linux. E' vero che anche il kernel supporta
l'autoconfigurazione con DHCP, ma, come peraltro è scritto nella doc del
kernel, tale autoconfigurazione va usata solo per permettere a workstation
diskless di funzionare in un ambiente dhcp, anche perché quel "client dhcp"
è notevolmente più limitato di quelli comunemente usati in userspace.
Sulle distro comunemente si trova il client dhclient di ISC.


Dimenticavo: le regole di iptables che ti ho dato bloccato tutti i DHCP
server. Se vuoi bloccare uno specifico DHCP server puoi usare questa:
iptables -I INPUT -s <IpDelDhcpServer> -p udp --dport 68 -j DROP


 richiesta.. Se invece uso iptables sul router 
scusa ma non capisco una cosa: tu puoi usare iptable sul router, ma non
puoi disabilitare il DHCP? Are you sure?
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"


Ok.. allora sono io che sbaglio.. e quindi passiamo al dettaglio:
Distribuzione Fedora 13 con NetworkManager che gestisce le connessioni:
Io ora ho staccato il plug sulla ethernet, pulito tutte le regole 
iptables e impostato le due regole che hai postato nel post precedente 
(che erano quelle che utilizzavo io)... In questo momento voglio 
bloccare tutte le richieste e quindi non vado a specificare l'ip:
Riattacco il plug e e il pc acquisisce l'indirizzo ip ignorando la 
policy di iptables
Dove sbaglio ?
Davide.


No.. Su questo "tostapane" non puoi:
cambiare ip;
cambiare nome ssid;
cambiare password wpa
aggiornare il firmware (lo può fare solo il gestore, previa mia 
autorizzazione (speriamo.. sic)
Per sbloccarlo, serve saldatore a stagno e schedina j-tag e tanto tanto 
coraggio :-)
Ciao, Davide.

 Il 13/11/2010 19:06, Max_Adamo ha scritto:

scusa, ma iptables sul router come lo usi? Hai accesso root ad una
console? E se da quella console lanci un kill sul demone dhcp?


 console?
Lavoro solo su console...
E se da quella console lanci un kill sul demone dhcp?
Uh?! ..Dici ?.. Spetta che provo..


Niente da fare.. killato sia network manager che dhclient, caricato le 
regole e poi riattivato nm e dhclient, ma è come se le regole non ci 
fossero affatto.. eppure ci sono..
[root@ws1a ~]# iptables -L -n -v
Chain INPUT (policy ACCEPT 708 packets, 92015 bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 DROP       udp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           udp dpt:68
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
Chain OUTPUT (policy ACCEPT 705 packets, 84422 bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 DROP       udp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           udp dpt:67

 policy di iptables
Sei sicuro che abbia ignorato le regole di iptables e che non sia piuttosto
una lease precedentemente assegnata?
Aggiungi un po' di logging:
iptables -F INPUT
iptables -P INPUT ACCEPT
iptables -A INPUT -p udp --dport 67 -j LOG --log-prefix IN67
iptables -A INPUT -p udp --dport 68 -j LOG --log-prefix IN68
iptables -A INPUT -s<IpDelDhcpServer>  -p udp --dport 68 -j DROP
iptables -A INPUT -p udp --dport 68 -j LOG --log-prefix IN68POST
iptables -F OUTPUT
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p udp --dport 67 -j LOG --log-prefix OUT67
iptables -A INPUT -p udp --dport 68 -j LOG --log-prefix OUT68



Questo è quello che mi dice iptables:





Ora provo con quello che mi hai postato..

 Niente da fare.. killato sia network manager che dhclient, 
ma tu stai usando iptables sul tuo client... .va buo': ora ci siamo
capiti. Pensavo fossi sul router, e che questo router ....



Ehm.. Un po' mi vergogno a dirlo, ma dove si leggono i log di iptables ?
In /var/log non c'è e nemmeno dentro kern.log e messages.. spunti presi 
dopo aver googlato..
Davide.

 dopo aver googlato..
Su Fedora non so. Però puoi fare un dmesg.



Allora credo che non li stampi perché non li registra proprio.. Anche su 
dmesg non c'è niente.. Questo è quello che mi registra messages per 
quanto riguarda il servizio dhcp
ov 13 23:14:26 ws1a kernel: b44 ssb0:0: eth0: Flow control is off for TX 
and off for RX
Nov 13 23:14:26 ws1a kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes 
ready
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> (eth0): carrier now ON 
(device state 2)
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> (eth0): device state 
change: 2 -> 3 (reason 40)
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
starting connection 'System eth0'
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> (eth0): device state 
change: 3 -> 4 (reason 0)
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 1 of 5 (Device Prepare) scheduled...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 1 of 5 (Device Prepare) started...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 2 of 5 (Device Configure) scheduled...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 1 of 5 (Device Prepare) complete.
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 2 of 5 (Device Configure) starting...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> (eth0): device state 
change: 4 -> 5 (reason 0)
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 2 of 5 (Device Configure) successful.
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 3 of 5 (IP Configure Start) scheduled.
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 2 of 5 (Device Configure) complete.
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 3 of 5 (IP Configure Start) started...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> (eth0): device state 
change: 5 -> 7 (reason 0)
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Beginning DHCPv4 transaction (timeout in 45 seconds)
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> dhclient started with 
pid 3068
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 3 of 5 (IP Configure Start) complete.
Nov 13 23:14:26 ws1a dhclient[3068]: Internet Systems Consortium DHCP 
Client 4.1.1-P1
Nov 13 23:14:26 ws1a dhclient[3068]: Copyright 2004-2010 Internet 
Systems Consortium.
Nov 13 23:14:26 ws1a dhclient[3068]: All rights reserved.
Nov 13 23:14:26 ws1a dhclient[3068]: For info, please visit 
https://www.isc.org/software/dhcp/
Nov 13 23:14:26 ws1a dhclient[3068]:
Nov 13 23:14:26 ws1a dhclient[3068]: Listening on LPF/eth0/00:16:d4:af:92:53
Nov 13 23:14:26 ws1a dhclient[3068]: Sending on   LPF/eth0/00:16:d4:af:92:53
Nov 13 23:14:26 ws1a dhclient[3068]: Sending on   Socket/fallback
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> (eth0): DHCPv4 state 
changed nbi -> preinit
Nov 13 23:14:26 ws1a dhclient[3068]: DHCPREQUEST on eth0 to 
255.255.255.255 port 67
Nov 13 23:14:26 ws1a dhclient[3068]: DHCPACK from 192.168.0.50
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> (eth0): DHCPv4 state 
changed preinit -> reboot
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 4 of 5 (IP4 Configure Get) scheduled...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 4 of 5 (IP4 Configure Get) started...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info>   address 192.168.0.100
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info>   prefix 24 
(255.255.255.0)
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info>   gateway 192.168.0.50
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info>   hostname 'LAN-WS1A'
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info>   nameserver 
'192.168.0.50'
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 5 of 5 (IP Configure Commit) scheduled...
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 4 of 5 (IP4 Configure Get) complete.
Nov 13 23:14:26 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 5 of 5 (IP Configure Commit) started...
Nov 13 23:14:26 ws1a avahi-daemon[1093]: Joining mDNS multicast group on 
interface eth0.IPv4 with address 192.168.0.100.
Nov 13 23:14:26 ws1a avahi-daemon[1093]: New relevant interface 
eth0.IPv4 for mDNS.
Nov 13 23:14:26 ws1a avahi-daemon[1093]: Registering new address record 
for 192.168.0.100 on eth0.IPv4.
Nov 13 23:14:26 ws1a dhclient[3068]: bound to 192.168.0.100 -- renewal 
in 857797181 seconds.
Nov 13 23:14:28 ws1a NetworkManager[1269]: <info> (eth0): device state 
change: 7 -> 8 (reason 0)
Nov 13 23:14:28 ws1a dnsmasq[1775]: reading /etc/resolv.conf
Nov 13 23:14:28 ws1a dnsmasq[1775]: using nameserver 192.168.0.50#53
Nov 13 23:14:28 ws1a NetworkManager[1269]: <info> Policy set 'System 
eth0' (eth0) as default for IPv4 routing and DNS.
Nov 13 23:14:28 ws1a NetworkManager[1269]: <info> Updating /etc/hosts 
with new system hostname
Nov 13 23:14:28 ws1a avahi-daemon[1093]: Registering new address record 
for fe80::216:d4ff:feaf:9253 on eth0.*.
Nov 13 23:14:28 ws1a NetworkManager[1269]: <info> Activation (eth0) 
successful, device activated.
Nov 13 23:14:28 ws1a NetworkManager[1269]: <info> Activation (eth0) 
Stage 5 of 5 (IP Configure Commit) complete.
Nov 13 23:14:28 ws1a nm-dispatcher.action: nm_dispatcher_action: Invalid 
connection: '(null)' / 'connection setting not found' invalid: 1
Nov 13 23:14:29 ws1a ntpd[1425]: Listen normally on 5 eth0 192.168.0.100 
UDP 123
Nov 13 23:14:29 ws1a ntpd[1425]: Listen normally on 6 eth0 
fe80::216:d4ff:feaf:9253 UDP 123
Nov 13 23:14:31 ws1a ntpd_intres[1435]: DNS 
0.fedora.pool.ntp.org
 -> 
93.62.230.241
Nov 13 23:14:31 ws1a ntpd_intres[1435]: DNS 
1.fedora.pool.ntp.org
 -> 
62.101.81.203
Nov 13 23:14:32 ws1a ntpd_intres[1435]: DNS 
2.fedora.pool.ntp.org
 -> 
62.101.81.205
Nov 13 23:17:46 ws1a ntpd[1425]: 0.0.0.0 c615 05 clock_sync
Nov 13 23:40:13 ws1a kernel: npviewer.bin[7224]: segfault at 418 ip 
01048b66 sp bffcef88 error 6 in libflashplayer.so[dfa000+b2c000]
Nov 13 23:40:13 ws1a abrt[8989]: saved core dump of pid 7224 
(/usr/lib/nspluginwrapper/npviewer.bin) to 
/var/spool/abrt/ccpp-1289688013-7224.new/coredump (26714112 bytes)
Nov 13 23:40:13 ws1a abrtd: Directory 'ccpp-1289688013-7224' creation 
detected
Nov 13 23:40:14 ws1a abrtd: Blacklisted package 'nspluginwrapper'
Nov 13 23:40:14 ws1a abrtd: Corrupted or bad crash 
/var/spool/abrt/ccpp-1289688013-7224 (res:2), deleting

 dmesg non c'è niente.. 
Ma i moduli di netfilter sono caricati? Perché è impossibile che ti venga
assegnato un indirizzo IP senza che venga registrato nulla con quella conf
di iptables, a meno che l'IP non ti venga assegnato in altro modo anche se
dai log non parrebbe.



Imho se non fossero caricati, iptables restituirebbe un errore.. 
Comunque ho provato a bloccare la porta ssh e l'operazione ha successo.. 
Ora provo a loggarla e poi controllo dove la va a scrivere :-)

 Ora provo a loggarla e poi controllo dove la va a scrivere :-)
E infatti questo è l'estratto del file kern.log
Nov 14 07:27:34 ws1a kernel: IN22IN=lo OUT= 
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 
DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40702 DF PROTO=TCP 
SPT=38777 DPT=22 WINDOW=32792 RES=0x00 SYN URGP=0
Nov 14 07:27:34 ws1a kernel: IN22IN=lo OUT= 
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 
DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=40703 DF PROTO=TCP 
SPT=38777 DPT=22 WINDOW=513 RES=0x00 ACK URGP=0
Nov 14 07:27:34 ws1a kernel: IN22IN=lo OUT= 
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 
DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=40704 DF PROTO=TCP 
SPT=38777 DPT=22 WINDOW=513 RES=0x00 ACK URGP=0
Nov 14 07:27:34 ws1a kernel: IN22IN=lo OUT= 
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 
DST=127.0.0.1 LEN=73 TOS=0x00 PREC=0x00 TTL=64 ID=40705 DF PROTO=TCP 
SPT=38777 DPT=22 WINDOW=513 RES=0x00 ACK PSH URGP=0
Nov 14 07:27:34 ws1a kernel: IN22IN=lo OUT= 
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 
DST=127.0.0.1 LEN=900 TOS=0x00 PREC=0x00 TTL=64 ID=40706 DF PROTO=TCP 
SPT=38777 DPT=22 WINDOW=513 RES=0x00 ACK PSH URGP=0

 Scusa, ma quando vedo scritto NetworkManager mi vengono i conati di vomito.
Accade anche a me quando lo vedo in funzione su altre distro, ma ti 
assicuro che su fedora ï¿œ assolutamente impeccabile.
Davide.

 iptables -A OUTPUT -d 192.168.1.1 -o eth0 -p udp --sport 67:68 -j DROP
Ho scritto sul forum di fedora (a questo punto mi ï¿œ sembrato doveroso) 
ed ho avuto questa risposta.. La pubblico per dovuta conoscenza, avendo 
aperto inizialmente il thread qui.
---
Il DHCP lavora ad un livello diverso rispetto a iptables. Iptables ti 
blocca i pacchetti tcp/udp in base alle regole che hai stabilito, ma nel 
momento in cui c'ï¿œ un lease da parte del dhcp, il client non ha ancora 
un indirizzo ip su cui iptables potrebbe filtrare qualcosa. Forse (ma 
sottolineo il forse) c'ï¿œ qualche opzione di ebtables per farlo (bho!)
Se vi interessa la discussione, si trova qui..
http://tinyurl.com/34yyr9x
Saluti, Davide.

 il networking su Linux.
In realtï¿œ, c'ï¿œ del vero.
Il dhcp ISC usa raw socket e bypassa quindi del tutto netfilter.
C'ï¿œ speranza che il team netfilter infili, prima o poi, un hook
ad hoc, come dichiarato nell'ultimo netfilter workshop:
http://workshop.netfilter.org/2010/wiki/index.php/Schedule_Proposals#Netfilter_vs._dhcpd_vs._raw_sockets

 client non ha ancora un indirizzo ip su cui iptables potrebbe filtrare qualcosa. Forse (ma sottolineo il forse) c'è qualche opzione di ebtables per farlo (bho!)
Ci hanno beccato, ma sbagliando del tutto il motivo.
Il fatto che il device in quel momento non abbia ancora indirizzo ip è del tutto ininfluente.
E' il client dhcp che bypassa del tutto il "normale" stack tcp/ip.

 E' il client dhcp che bypassa del tutto il "normale" stack tcp/ip.
libpcap?


 
http://workshop.netfilter.org/2010/wiki/index.php/Schedule_Proposals#Netfilter_vs._dhcpd_vs._raw_sockets
Ti ringrazio.. ho riportato il link nel forum di fedora citandoti per 
averlo trovato.. :-)
Ho risolto settando il file dhclient.conf.. che poi su fedora il file 
corretto è dhclient-eth0.conf.. mettendo come regola "reject 
192.168.1.1", e adesso le richieste vengono bloccate correttamente.
Grazie a tutti, Davide.

 ha scritto nel messaggio 
news:ibpcho$fuf$1...@posted-at.bofh.it...

Scusa, ho visto che il trhead e' lungo e non ho voglia di leggerlo tutto ma 
non comprendo questa affermazione ne le regole sopra.
Il dhcp funziona su due porte: il server ascolta e parla sulla 67 il client 
ascolta e parla sulla 68. Il client manda un broadcast per cui la seconda 
linea verrebbe ignorata non mappando l'ip. Il server risponde con un 
broadcast che comunque verrebbe intercettato dalla prima regola. Insomma le 
due regole sopra creano una continua comunicazione monca.
Non si riuscira' ad avere l'assegnazione dell'ip ma non capisco cosa intendi 
con bypassa lo stack tcp/ip (ma forse sono stanco e facevo meglio ad andare 
a dormire).
Ciao
-- 
 ************** (.)_(.)  **************
 Un amico è uno che sa tutto di te e,
 nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 

 ha scritto:

il wiplash è tosto quando parla di queste cose.
Ti posto il link che ha inviato nell'altro messaggio:
http://workshop.netfilter.org/2010/wiki/index.php/Schedule_Proposals#Netfilter_vs._dhcpd_vs._raw_sockets


 ma non comprendo questa affermazione ne le regole sopra.
Ciao.. Visto che l'ho aperto io, mi prendo l'onere di mandarti il link 
pubblicato da whiplash :-)
http://tinyurl.com/2g9uc8w

 a dormire).
Da quanto ho capito per come è fatto dhclient non utilizza lo stack tcp/ip
del kernel. Sniffa quel che passa in rete come fa libpcap e crea pacchetti
grezzi iniettandoli in rete bypassando di fatto netfilter.


 
Raw socket, il risultato, in fase di acquisizione pacchetti, è lo stesso.

 il wiplash è tosto quando parla di queste cose.
E' solo l'averci sbattuto, a suo tempo, le corna...
$netstat -nap | grep dhcpd3 | grep raw
raw        0      0 
0.0.0.0:1
               0.0.0.0:*               7           30835/dhcpd3


http://workshop.netfilter.org/2010/wiki/index.php/Schedule_Proposals#Netfilter_vs._dhcpd_vs._raw_sockets
Ho fatto bene allora a non andare a dormire. Ho imparato qualcosa anche oggi 
:-)
Grazie
-- 
 ************** (.)_(.)  **************
 Un amico č uno che sa tutto di te e,


> Il dhcp ISC usa raw socket e bypassa quindi del tutto netfilter.
Eh, gia'... almeno in *bsd usa /dev/bpf e lo capisci subito. Poi, dopo 
che ci hai perso un po' di tempo, ci pensi: ma come potrebbe mai usare
un socket, se sull'interfaccia... non e' ancora configurato il tcp/ip?
Fabio
PS: frase di corollario, giusto per sentirsi piu' scemi: <<aah... ecco
    perche' non avevo mai dovuto prevedere un'esclusione dai log per i
    broadcast DHCP "droppati" dalle regole catchall di iptables !!>>

> dal kernel.. Io non me ne intendo.. sono sincero e ammetto il mio
Quello che ti ha mostrato, molto probabilmente è legato ad una delle 
possibilità di boot del kernel.
Necessario per il BOOT on NFS o similari.
 

> dhclient.conf (o chi per lui), altrimenti non riesco a bloccare la
Che è gestito da un processo in userland, quindi molto dopo...