Newsgroup: it.comp.os.linux.sys
Titolo: Nattare solo per alcuni IP offerti da DHCP

Buongiorno a tutti, avrei necessità di installare una macchina linux
con la quale nattare alcuni pc di una LAN verso Internet.
Quello che vorrei fare è abilitare il NAT solo su un piccolo range di
IP forniti dal server DHCP ed inoltre fare in modo che il pc possa
venire nattato solo se i suoi parametri di rete sono stati configurati
dal DHCP. Vorrei cioè evitare che i pc possano navigare se impostati
con indirizzi ip statici.
Si può fare una cosa del genere?
C.

 Si può fare una cosa del genere?
Scusa ma... perché? Se anche uno si assegnasse staticamente l'IP che il
DHCP gli assegnerebbe, che differenza ti fa? Sempre quell'IP ha. Il
problema semmai è che assegnarsi staticamente un IP appartenente a un
pool di competenza del DHCP è una boiata, e andrebbe picchiato col gatto
a nove code chi lo fa, perché la volta che il DHCP decide di far scadere
il lease dell'indirizzo e assegnargliene un altro, passando quello
precedente a un altro utente, dopo viene fuori una fenomenale collisione...
-- 
Massimo Bacilieri AKA Crononauta

 iptables -A FORWARD -d 1.2.3.4 -j MASQ
E di questa proprio non si capisce il senso, se 1.2.3.4 è un ip della
LAN.

 Si può fare una cosa del genere?
Non puoi impedire, in maniera banale, che qualcuno si assegni un ip del range
assegnato dal dhcp in maniera manuale.

 LAN.
I pacchetti come tornano (do per scontato che la catena di FORWARD abbia
policy DROP)?


 
Io continuo a rimanere assai basito dal fatto che dopo quasi 10 anni di 
iptables ci sia ancora un sacco di gente che lo usa senza stati...
-- 
http://bofhskull.wordpress.com/

 policy DROP)?
Uh?
Riscriviamo il tutto.
Per il masquerading in uscita:
iptables -t nat -A POSTROUTING -m iprange --src-range $primo_ip-$ultimo-ip \
-o $interfaccia_internet -j MASQUERADE
Abilitiamo il forwarding:
echo "1">/proc/sys/net/ipv4/ip_forward
che possiamo abilitare al boot in /etc/sysctl.conf (in debian, almeno)
così:
net.ipv4.ip_forward=1
Impostiamo a DROP la policy di FORWARD?
Ok:
iptables -P FORWARD DROP
Accettiamo i pacchetti verso internet dal range stabilito:
iptables -A FORWARD -i $interfaccia_lan -o $interfaccia_internet \
-m iprange --src-range $primo_ip-$ultimo-ip -j ACCEPT
Accettiamo tutti i pacchetti con stato ESTABLISHED e RELATED:
iptables -I FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT

 iptables ci sia ancora un sacco di gente che lo usa senza stati...
Anche perchè, non appena inserisco una qualsivoglia regola di nat, i moduli
di conntracking vengono caricati automaticamente...:-)

 iptables -I FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT
Ah beh allora ok.


 iptables ci sia ancora un sacco di gente che lo usa senza stati...
Il concetto è che una regola per il ritorno la devi mettere, che sia il
FORWARD -d $LAN o che sia un -m state --state ESTABLISHED,RELATED i
pacchetti di ritorno vanno abilitati, non è che passano da soli.
Poi se esteticamente sia più bello usare -m state vabbè non discuto... :-)


 Poi se esteticamente sia più bello usare -m state vabbè non discuto...
Non è questione estetica, ma pratica, direi. :)

DHCP gli assegnerebbe, che differenza ti fa? Sempre quell'IP ha.
Intanto grazie a tutti per le risposte :)
Il motivo per cui vorrei evitare che qualcuno impostasse un IP statico
č dovuto al fatto che in un secondo momento vorrei mettere in piedi
delle regole di QoS specifiche per alcuni IP della LAN e rendere piů
difficile la vita a chi tenta di fare il furbo (in soldoni, si
tratterebbe di evitare l'abuso di una ADSL ai furboni che usano dei
P2P).
Si potrebbe in qualche modo controllare se il mac address dell'ip che
viene nattato sia contenuto nella tabella del DHCP e in caso negativo
fermarlo per un pň o metterlo in black-list?

 fermarlo per un pò o metterlo in black-list?
Ma fammi capire perché uno che sa che gli indirizzi assegnati via DHCP
sono abilitati a uscire su internet, debba impostarsi un IP staticamente
all'interno di quello stesso range che gli attribuirebbe il DHCP :-O
...prende l'IP dal DHCP e fine dei suoi problemi... no?


 ai furboni che usano dei P2P).
Inibisci il traffico che non ti aggrada e basta.
Più semplice, direi.

Più semplice, direi.
A saperlo fare, di sicuro :)
Mi stai consigliando di implementare qualcosa a layer 7 per il
filtraggio del traffico? 

all'interno di quello stesso range che gli attribuirebbe il DHCP :-O
Mha, non lo so... forse perchè è una prova che io tenterei di fare per
sfuggire alla limitazione di banda.

 sfuggire alla limitazione di banda.
Il DHCP assegna IP, e basta.
Quando un client si presenta con IP 1.2.3.4, che questo arrivi da un
lease DHCP o da un'assegnazione statica, non cambia piů niente a livello
di traffico, cioč č soggetto esattamente agli stessi filtri, se questi
agiscono sull'IP.
Ma se hai di questi problemi, non č meglio mettere su un bel proxy, e
invece del nat fare solo il pat dei servizi che vuoi ammettere (tipo che
so la posta)?


 filtraggio del traffico?
Non necessariamente.
Dipende da cosa devono poter usare i tuoi utenti.

Dipende da cosa devono poter usare i tuoi utenti.
Essenzialmente dovrebbero poter fare tutto escluso il P2P.

agiscono sull'IP.
Si, certo questo č chiaro. Il film che mi ero fatto era quello di
assegnare sempre lo stesso IP via DHCP ad alcune macchine (quelle di
cui sono sicuro fare P2P) e impostare delle regole di QoS. Se l'utente
si cambia l'IP invece i filtri non funzionano piů.
Certo, potrei anche applicarli a tutti, perň mi piaceva di piů l'idea
di regolare direttamente i furbetti :)

 assegnato dal dhcp in maniera manuale.
beh non banalissima ma semplice.
Poi ti vai a perdere però i vantaggi del DHCP.
Basterebbe assegnare col DHCP sempre lo stesso IP alla stessa macchina
(tramite MAC address, ed è una cazzata da fare).
Poi sul gateway, con ARP, accoppi perennemente il MAC all'IP.
Ovvio che non è il massimo della flessibilità...
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 DHCP gli assegnerebbe, che differenza ti fa? Sempre quell'IP ha.
Anch'io mi sono trovato davanti ad un problema del genere. Perché se il DHCP 
assegna gli IP in base ai MAC qualcuno potrebbe fare il furbo e mettersi 
staticamente un IP che non gli competerebbe.
Ad esempio mi ricordo che ai tempi delle superiori avevamo diverse subnet 
per ogni laboratorio (
172.16.1.0/24
, 
172.16.2./24
, ecc...)
e poi c'era la subnet 
172.16.0.0/24
 che era "riservata" ai computer dei 
professori ed aveva accesso ad internet. Gli IP erano assegnati in DHCP in 
base al MAC, ma ovviamente bastava mettersi un IP statico nella classe 
172.16.0.0/24
 per navigare.
In questo caso sarebbe comodo dire ad esempio al DHCPd di far partire uno 
script ogni volta che assegna un IP, lo script ovviamente serebbe la regola 
di iptables che natta quel particolare indirizzo (ovviamente dovrebbe poi 
cancellare la regola al release). 

 anche uscire su internet. 
Quindi bastava connettersi ad una porta attestata sulla net dei professori 
per navigare liberamente.
L'unica soluzione valida è quella di mettere un captive firewall.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

Carlo ha scritto:



per ottenere ciň potresti compilare e caricare il modulo ipp2p.
Bluto
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 L'unica soluzione valida è quella di mettere un captive firewall.
uhm... sì, è un'utile aggiunta. Però scommetterei che allora qualche
studente inizierebbe a giocare con degli sniffer... :-O


 studente inizierebbe a giocare con degli sniffer... :-O
Arriveremo al momento in cui la rete sarà talmente blindata che useranno
un'antenna wifi per scroccare la connessione al vicino :-P
Enrico

 L'unica soluzione valida è quella di mettere un captive firewall.
...o 802.1x in accesso alla rete.

 studente inizierebbe a giocare con degli sniffer... :-O
Beh, su una rete switched dovrebbe fare qualcosa in più, ovvero arp
spoofing *e* sniffing, a la ettercap.
E anche MITM su https, se l'autenticazione captive fosse, come spesso
accade, fosse in https...:-)