Newsgroup: it.comp.reti.locali
Titolo: Bridge firewall

In una rete con tutti IP pubblici vogliamo mettere un firewall per non 
rendere accessibili le macchine dall'esterno eccetto che per pochi IP e 
relativi protocolli. Non vogliamo cambiare gli IP delle macchine per il 
momento.
Non possiamo riconfigurare il gateway del provider, che tuttavia si 
attacca allo switch più a monte con un solo cavo ethernet.
Avevo pensato ad un bridge linux con firewall basato su ebtables da 
infilare fra il gateway e il primo switch, cosa ne pensate?
E' stabile il bridging di linux?

cric ha scritto:

Ciao, per una situazione davvero simile alla tua
ho impiegato linux con configurazione proxy-arp e
regolo il traffico con il classico iptables e la
catena di FORWARD.
Un'altra soluzione che ho provato è
http://www.pfsense.com/
in configurazione bridge con firewall.
In entrambi i casi le macchine sono in piedi da un
paio d'anni e non hanno mai dato un problema.
Saluti
-- 
principio di Napoleone: non attribuire a
malintenzione cio' che puo' essere semplicemente
spiegato come imbecillita'
MaoX Blog:
Problemi e soluzioni di un sistemista informatico:
http://blog.maurizio.proietti.name
Personal site:
http://www.maurizio.proietti.name

 E' stabile il bridging di linux?
Vedi tu: ho un cliente (molto, molto grosso) con 32 firewall linux in 
bridging composti di un numero variabile tra 6 e 15 NIC ciascuno. Son lě 
che giran da 4 anni, mai avuto problemi.
-- 
http://bofhskull.wordpress.com/

 catena di FORWARD.
Mi hai risolto la situazione perchè con la soluzione che dicevo io con 
ebtables ho capito che non sarei riuscito a concedere connessioni TCP 
nemmeno uscenti per gli host non visibili da fuori.
Riguardo al proxy-arp che non conoscevo, ho pensato di seguire questo 
tutorial:
http://www.sjdjweis.com/linux/proxyarp/
Ho solo due dubbi
- Primo dubbio:
dove dice di fare:
ip route add x.x.x.33 dev eth0
ip route add x.x.x.32/27 dev eth1
Chiaramente il secondo comando è per una sottorete che include anche il 
primo indirizzo perchè il .33 fa parte del x.x.x.32/27 . Il motivo per 
cui Linux manda i pacchetti per .33 al eth0 è perchè ho scritto la prima 
riga prima della seconda?
Oppure perchè il primo comando è per un host e il secondo per una net 
quindi matcha più fortemente l'host perchè è più restrittivo?
Oppure questa tecnica non è affidabile e mi potrebbe matchare la seconda 
riga per il .33 (e se succede chiaramente sono fregato)?
- Secondo dubbio:
In questa pagina
http://lartc.org/howto/lartc.bridging.proxy-arp.html
fa notare che gli host hanno ancora in cache l'indirizzo ARP del 
gateway e che si può usare il meraviglioso "arping" per forzarli a 
cambiare la cache.
Questo è fondamentale per me perchè quando infilo il firewall non posso 
certo aspettare che scada la cache di ARP di tutti i computer del 
palazzo prima che continuino a navigare.
Però non ho capito COME si usa arping per ottenere questo refresh della 
cache qualcuno può aiutarmi? Come lo lancio?
Grazie

 E' stabile il bridging di linux?
Sì.

 la catena di FORWARD.
Puoi tranquillamente fare a meno del proxy arp, volendo.

 ebtables.
A quanto capisco non si può usare iptables se uso il bridging
non credo che i pacchetti ethernet passino da iptables, ci deve essere 
un routing in mezzo per farglieli passare
proxy-arp provoca un routing ed era il modo per farglieli passare


No.
E ebtables ti serve solamente se vuoi smanacciare anche a L2 oltre che a 
L3 (es: brouting), altrimenti non serve.
-- 
http://bofhskull.wordpress.com/

 No.
Tu mi stai dicendo che in un bridge normale senza proxy-arp, dopo essere 
passati da ebtables i pacchetti passano anche da iptables?
Mi fai un esempio di regola iptables per concedere TCP uscenti (iniziati 
da dentro) ma non entranti per una certa macchina nella situazione che 
dico io, con un bridge?
supponi che la rete sia 1.2.3.x con gateway a 1.2.3.1 e la macchina da 
filtrare sia 1.2.3.5 e il bridge linux senza proxy-arp sia collocato 
subito a valle di 1.2.3.1

 dico io, con un bridge?
Assumendo che eth1 sia quella attaccata al router e eth0 alla LAN:
# Prima di tutto gli stati...
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCPET
# Concedi a 1.2.3.5 di uscire a contattare i DNS, quindi sia UDP che TCP
iptables -A FORWARD -m physdev --physdev-in eth0 --physdev-out eth1 -s 
1.2.3.5 -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A FORWARD -m physdev --physdev-in eth0 --physdev-out eth1 -s 
1.2.3.5 -p tcp --dport 53 -m state --state NEW -j ACCEPT
# Suvvia, falla anche pingare...
iptables -A FORWARD -m physdev --physdev-in eth0 --physdev-out eth1 -s 
1.2.3.5 -p ICMP --icmp-type echo-request -m state --state NEW -j ACCEPT
# Sega il resto del traffico di 1.2.3.5
iptables -A FORWARD -m physdev --physdev-in eth0 --physdev-out eth1 -s 
1.2.3.5 -m state --state NEW -j DROP
#Sega il traffico dall'esterno diretto a chiunque all'interno
iptables -A FORWARD -m physdev --physdev-in eth1 --physdev-out eth0 -m 
state --state NEW -j DROP
Bye.
-- 
http://bofhskull.wordpress.com/

 Assumendo che eth1 sia quella attaccata al router e eth0 alla LAN:
 >
 > [CUT regole]
Oh mitico, non sapevo/ricordavo del --physdev-xxx !
ok allora sì che è possibile...
E' stato introdotto nel kernel 2.5.22 vedo.
Adesso che hanno introdotto questo physdev, il proxy-arp ha ancora 
ragione di esistere? c'è qualche use-case in cui serve ancora veramente 
il proxy-arp?
Grazie

 il proxy-arp?
Sostanzialmente sì: lo scopo per cui è nato...
Ovvero: consentire a macchine con netmask a farfalle di ignorare 
l'esistenza di subnetting. ;-)
Cmq, scherzi (neanche troppo) a parte, i risultati ottenibili con 
bridging e proxy-arp possono sembrare simili, ma dal punto di vista 
concettuale (e del layering) c'è un abisso nel mezzo.
Ad esempio, proxy arp funziona per ottenere "routing trasperente" anche 
tra due media che abbiano MTU diverse (es tipico: RAS ppp), liddove 
invece il bridging non può (non esiste alcun meccanismo di gestione 
frammentazione a L2...).
-- 
http://bofhskull.wordpress.com/

 passati da ebtables i pacchetti passano anche da iptables?
Già.

 modo per farglieli passare
http://l7-filter.sourceforge.net/PacketFlow.png