Re: Re: [ml] Ancora su iptables e situazioni pseudo-reali.

>Occhio che questa regola non viene applicata ristretta allìip 
>destinazione, ma a tutto il traffico entrante dalla >$INTERFACE_ESTERNA.
>Se questa ha più IP, li ridirige *tutti*.

Ho notato un problema del genere...in quel modo (ho mandato alcune mail ma non le vedo in ml :D) qualsiasi cosa usciva per poi rientrare da quella interf. veniva rediretta sempre alla 80 (ad esempio...) e mi bloccava anche il traffico che, invece, doveva essere reinstradato all'interno. Allora ho sistituito la regola con:

$IPTABLES -t nat -A PREROUTING -d $IP_INTERFACE_ESTERNA -p udp --dport 53 -j DNAT --to-destination $MACCHINA_DMZ:53 

e parrebbe andare...se non fosse che giustamente tu mi dici di "non fidarmi solo degli indirizzi ip" (da notare che, ad ogni modo, anche se non le ho scritte in ml, ho all'inizio della catena di INPUT e FORWARD delle regole anti-spoofing ben precise...). Quindi mi chiedevo se il modo più corretto per specificare regole del genere non fosse:

$IPTABLES -t nat -A PREROUTING -i $INTERFACE_ESTERNA -d $IP_INT_ESTERNA -p udp --dport 53 -j DNAT --to-destination $MACCHINA_DMZ:53 

Devo ancora provare se funziona...però a sto punto sembrerebbe la più corretta. Quello che + mi ha "stupito" (non mi viene altro termine...) è che con la regola:

$IPTABLES -t nat -A PREROUTING -i $INTERFACE_ESTERNA -p udp --dport 53 -j DNAT --to-destination $MACCHINA_DMZ:53 

non riuscissi ad instradare il traffico all'interno. Voglio dire, tutto ciò che entra da quella interfaccia viene controllato se destinato alla porta 53 (li c'è scritto 53 ma valo per 80, 22 etc...) e nel caso di una richiesta HTTP la dport nella richiesta è sicuramente 80, ma in entrata non DEVE essere + 80!!! Quindi perchè dovrebbe matchare quella regola in PREROUTING per i pacchetti di ritorno da connessioni HTTP inizializzate dalla LAN? Con ethereal ho notato, invece, che i pacchetti di ritorno per connessioni a server-web in rete venivano fatti matchare TUTTI con quella regola nella catena di PREROUTING e rediretti al web server interno! Invece dovevano andare ad una macchina in LAN che aveva fatto la richiesta!! Questo non mi era chiaro...levando -i e mettendo l'ip di destinazione, invece, sembra (e dico SEMBRA..) far anche i controlli sulla porta di destinazione e inoltrare i pacchetti all'interno correttamente.

> suppongo di dover gestire nella catena di FORWARD del firewall il 
> suddetto pacchetto esattamente come se fosse stato originariamente 
> buildato per raggiungere la macchina in DMZ no? Quindi dovrò 
> aggiungere cose del tipo:
>
> $IPTABLES -A FORWARD -p udp --dport 53 -d $MACCHINA_DMZ -m state 
> --state NEW -j ACCEPT

>Yep. Ma con un MA

>
> In questo modo, in una sola regola risolvo anche l'inoltro dei 
> pacchetti provenienti dalla 3° scheda (avevo assunto che aveva 3 
> interface il firewall...) che comunque avranno già di loro (provenendo 
> da una rete interna) l'indirizzo ip della macchina in DMZ come 
> destinazione.
>
> E' corretto il mio ragionamento? Manca qualcosa?

>Il MA. Ovvero una questione strettamente di approccio e >relativi dettagli.

>1) è in linea di massima sempre desiderabile verificare esplicitamente 
>le interfacce di ingresso/uscita del traffico. Affidarsi solo all'IP non è consigliabile.
>2) L'approccio di "applico il nat solo alle porte che servono" è 
>indispensabile solamente nel caso in cui tu abbia un solo IP pubblico 
>su cui devi far rispondere più macchine interne.
>Altrimenti è consigliabile nattare "tutto l'IP" e effettuare poi in FORWARD i check del caso.
>Questo evita da un lato di dover replicare il ruleset (una volta per il NAT e una volta per il filter), e dll'altro risparmia grossi mal di testa nel caso di protocolli multiporta, dove altrimenti ti ritrovi a dover inseguire le porte una a una.

1) Hai ragione ma non funzionava, come ho spiegato precedentemente. In merito alla regola con -i e -d potresti darmi qualche suggerimento?

2) Ho un solo ip pubblico...

>
> Ultima cosa: volendo far "passare" anche il traffico verso internet 
> sono necessarie regole particolari che controllano i tcp-flags dei 
> pacchetti o mi basta una cosa tipo:
>
> $IPTABLES -A FORWARD -s $NETDMZ -m state --state NEW,RELATED -j ACCEPT


>Questa funzionerebbe, ma manca il traffico ESTABLISHED, quindi non staresti lasciando passare le risposte al traffico NEW.
>Vale anche qui (*enormemente* qui, per come la hai scritta) la regoletta della interfaccia di ingresso/uscita. Una regola siffatta permette alla DMZ di entrare in LAN. Non credo sia quello che volevi.

Ho una regola che fa passare l'ESTABLISHED, prima di quella che ho scritto. Effettivamente, però, scritta così ha il difetto che dici tu ma questo è dovuto al fatto che quella regola viene da una SITUAZIONE + complessa con una DMZ con doppio firewall in cascata e indirizzi interni COMPLETAMENTE nattati...ci vorrebbero regole restrittive per verificare la provenienza dalle macchine in DMZ cmq ho capito l'inghippo :D TNX

>Se posso permettermi un po' di pubblicità, prova a dare una spizzata a 
>http://www.skullkrusher.net/linux/iptables.html e a 
>http://www.skullkrusher.net/linux/statemachine.html
>Premettendo che sono
>- datati
>- pensati come FAQ per newbie su di usenet

>Se vuoi un consiglio (e questo è in risposta parziale al richiamo che hai fatto al port-forwarding), dimentica per un po' quello che sai 
>dell'approccio seguito da altri vendor, e limitati a capire i concetti 
>di chain e state, insieme con l'ordine il percorso seguito dai 
>pacchetti nello stack.
>Se lo capisci e ragioni nei suoi termini, iptables/netfilter è 
>probabilmente il tool di filtering/nat più limpido che c'è in giro.

>Saluti.

Grazie del consiglio, ci sto provando hehehehe :D Grazie anche se vorrai continuare a rispondermi! :D

TNX ancora!

ciao!

ParAdox-D
---------------------------------------------------------------
Scegli il tuo dominio preferito e attiva la tua email! Da oggi
l'eMail di superEva e' ancora piu' veloce e ricca di funzioni!
http://webmail.supereva.it/new/
---------------------------------------------------------------