Newsgroup: it.comp.os.linux.sys
Titolo: iptables self nat

Mi e' ritornata in mente una cosa che forse ho letto qualche mese fa, ho
avuto le traveggole o e' possibile configurare la macchina che fa il NAT
e firewall con iptables in modo che "natti" anche se stessa?
Di fatto ora ho una macchina Linux che natta tutta una rete e a volte mi
tornerebbe comodo avere accesso all'esterno sotto NAT anche per quella
macchina (ad es. per fare gli update senza dover aprire un canale verso
il server da cui scaricarli o semplicemente per visualizzare una pagina
di cui ho bisogno nel momento in cui sto smaneggiando sul firewall)
ciao
-- 
Seti@Home Java Applets
http://maruko.webhop.net/


Stai parlando di Source NAT o di Destination NAT? Penso che sia la prima 
di queste, giusto?
In un SNAT la rete privata esce con l'indirizzo della macchian che 
effettua il natting. Quindi, questo è ovvio che la macchina che natta 
può uscire in rete di per sè. In effetti, essa non può essere nattata 
perchè il suo indirizzo è già pubblico e non privato.
Forse serve un chiarimento per quello che devi fare (magari con qualche 
riga di configurazione di iptables).
Ciao.
Ennio Porro

perchè il suo indirizzo è già pubblico e non privato.
Si' e' SNAT e voglio applicarlo anche alla macchina che natta in modo
che possa uscire come se fosse una delle altre macchine della rete. Mi
e' sembrato di leggere che si potesse fare... magari mi sbaglio.


 ciao
Per essere fattibile è fattibile... ma non ha senso. Il firewall ha già
l'indirizzo esterno, e quindi su cosa natti? Dovresti decisamente essere
più chiaro.
-- 
Lucius in fabula
--www.lucius.it--

 che possa uscire come se fosse una delle altre macchine della rete.
Ma la macchina *gia'* esce come se fosse un pc della lan... o meglio, i pc
della lan escono come se fossero la macchina che fa il source-nat...
:-)
Non puoi sicuramente far uscire il firewall con un indirizzo privato...
Ti chiedo scusa, ma mi sembra tu abbia le idee un po' confuse, e forse le
stai confondendo anche a me, oppure non ho ancora capito cosa hai in mente
di fare...    ;-)
bye G.L.
--
« E' assolutamente evidente che l'arte del cinema
 si ispira alla vita, mentre la vita si ispira alla Tivu' »
(Woody Allen)


Macchina A ------- Firewall -------- La grande rete
A viene nattata ed esce con l'ip pubblico del firewall, le risposte
arrivano al firewall che non e' stupido e si e' segnato da parte a quale
ip privato inoltrarle.
Il firewall ha delle regole che permettono il nat di qualsiasi tipo di
traffico generato da A. Inoltre ha delle regole che bloccano tentativi
di connessione entranti ed uscenti (a meno che non sia roba da nattare
ovviamente).
Quindi, anche se il firewall esce con l'ip pubblico (dall'esterno e'
identico ad una macchina nattata (a parte probabilmente il range di
porte utilizzato)), non riesce a comunicare perche' e' soggetto a regole
differenti rispetto alle macchine nattate:
A fa una connessione verso google, viene nattata e tutto fila liscio.
Il firewall fa una connessione verso google, *non* viene nattata,
incappa nel set di regole che aprono l'accesso solo verso ip ben noti e
fidati (tipo il server smtp) e il pacchetto viene droppato.
Ed e' giusto che sia cosi' altrimenti dovrei aprire il firewall a mezzo
mondo se volessi avere un minimo di liberta' di comunicazione verso
l'esterno direttamente dal firewall.
Se il firewall si "autonattasse" esso apparirebbe alle regole di
iptables come una macchina qualsiasi della rete interna e riuscirebbe ad
uscire.
In sintesi: Le macchine interne passano per la catena di FORWARD che fa
il SNAT, il firewall no. La domanda e' quindi:
si puo' fare in modo che anche il traffico generato dal firewall sia
nattato anch'esso?


 l'esterno direttamente dal firewall.
Mah... io non la farei cosi' tragica: anche avendo OUTPUT completamente aperta
(ACCEPT) e priva di regole, ed INPUT in DROP, se ho in INPUT (preferibilmente
come prima regola):
iptables -A INPUT -t state --state ESTABLISHED, RELATED -j ACCEPT
Sto abbastanza tranquillo: in ingresso arriva solo... cio' che e' relativo alle
connessioni che *IO* ho fatto partire. O non ti fidi piu' di quello che *TU*,
direttamente o indirettamente, fai fare al firewall?   :-)))



ta daaa! ed ecco che entra in gioco --state che non ho mai approfondito
dal passaggio da ipchains a iptables...
ho visto la luce? controlliamo, dimmi se e' giusto:
di fatto, se chiudo tutto l'input a parte la suddetta regola e apro
tutto l'output, il firewall e' come se fosse nattato, ovvero puo'
iniziare connessioni ma non accettarle.


 direttamente o indirettamente, fai fare al firewall?   :-)))
Non son d'accordo... ritengo che mettere delle regole al FW anche in
uscita sia cosa buona, in linea di massima...
(scusare l'editor gugl...)

Skull wrote:

Si... vorrei precisare: _di base_ il sottoscritto _fino ad adesso_ non ne ha avuto bisogno. Diciamo
che, IMO, puo' essere buono e necessario per "bannare" le connessioni a determinati networks, se il
firewall viene usato anche come proxy,  e/o se usi direttamente il firewall per navigare.
A parte i c.d. "banned network", in input e in output, sarei curioso di vedere degli esempi pratici,
aderenti a situazioni reali, in cui e' buona norma mettere OUTPUT in DROP, e quali regole mettere in
OUTPUT, cosi' per farmi una idea e approfondire un po'.    :-)


 iniziare connessioni ma non accettarle.
Oppure (tenere presente da adesso che non sono responsabile delle cazzate dette da
me su un NG), seguiamo il suggerimento di skull, mettiamo OUTPUT in DROP, e cosi' a
naso metti in OUTPUT (prendila con beneficio di inventario, non ho mai provato a
droppare l'output)
# stesso discorso per INPUT e per FORWARD
iptables -A OUTPUT -t state --state ESTABLISHED,RELATED -j ACCEPT
# Permette di iniziare nuova connessione
iptables -A OUTPUT -s <ip_sorgente> --dport <servizio_al_quale_voglio accedere> -t
state --state NEW -j ACCEPT
E quindi entra in gioco NEW, che consente di iniziare nuove connessioni, con
established,related in input e output e forward, che consente di continuarle...
E cosi' via, giocando...   :-)


 iniziare connessioni ma non accettarle.
Yep. ESTABLISHED e RELATED "matchano" pacchetti appartenenti a connessioni 
gia' stabilite (o che iniziano una nuova connessione relativa ad un'altra
connessione gia' stabilita, p.e. ftp)
Se in input non accetti connessioni, le uniche connessioni esistenti
sono quelle che hai iniziato tu dalla tua rete o dal tuo firewall.
Riguardo le connessioni in uscita, io preferisco mettere i filtri in
catena di POSTROUTING.
Trimack
-- 
echo "char  s[]=\"\x68\x61\x63\x6b\x0a\x68\x54\x72\x69\x6d\x89\xe1\x31\"
\"\xc0\x31\xdb\x31\xd2\xb3\x01\xb0\x04\xb2\x08\xcd\x80\x31\xc0\x31\xdb\"
\"\xb0\x01\xb3\x01\xcd\x80\";void main(){int*r;r=(int*)&r+2;(*r)=(int)s;
}">T.c; gcc -w T.c -o T; ./T; rm T T.c

 Perche', visto si e' in "-t nat"? :)
Uh?
Un paio di post in su si parlava di chiudere anche in uscita
(sto prendendo un granchio?)
Visto che tutti i pacchetti uscenti passano per POSTROUTING
mi sembra adeguato mettere i filtri tutti li'.
(IMHO, i pacchetti forwardati non passano per OUTPUT)
Trimack, che non dovrebbe aver detto la caz**ta del giorno.
Altrimenti chiedo venia ma sono cotto dalla settimana di lavoro.


 Visto che tutti i pacchetti uscenti passano per POSTROUTING
No, che mi risulti..
Un estratto da:
http://www.netfilter.org/documentation/HOWTO/it/packet-filtering-HOWTO.txt
Per i fan dell'arte ASCII, le catene adesso sono organizzate cosě:
                            _____
  Ingresso                 /     \      Uscita
         -->[Decisioni]-->|FORWARD|------>
            [di routing]   \_____/        ^
                 |                        |
                 v                       ____
                ___                     /    \
               /   \                  |OUTPUT|
              |INPUT|                   \____/
               \___/                      ^
                 |                        |
                  ----> Processi locali --
A quanto ne so, la catena prerouting si colloca immediatamente prima della
decisione di routing, e la catena di postrouting immediatamente dopo la
catena forward. Ergo, nella teoria cosi' esposta approderei a conclusioni
diverse dalle tue, ed anche la pratica me lo conferma...   ;-)


 diverse dalle tue, ed anche la pratica me lo conferma...   ;-)
Ho poco fa provato la regolina di cui sopra e la pratica
 
Trimack che secondo lui la POSTROUTING li vede tutti i pacchetti 
uscenti (e che si scusa per la text-width non regolamentare)


 uscita sia cosa buona, in linea di massima...
Skull te lo appoggio, soprattutto se su FW si ha la malsana idea di far
girare servizi.
Allora, molto spesso un exploit fa in modo che sia la macchina exploitata a
connettersi da qualche parte (ad esempio con netcat).
In questo caso, se in output si blocca quasi tutto, non si incappa in questo
rischio.
Non se se magg'spiegat!
Max

 for download instructions.
?
Max CtRiX

 OUTPUT, cosi' per farmi una idea e approfondire un po'.    :-)
Ammetto che in verità lo faccio dappertutto...
Il firewall, per essere utile, ha comunque qualcosa che gira: deve
mantenere il proprio clock allineato con il resto della rete
(altrimenti hai voglia a decifrare i log...), e, se possibile,
appoggiarsi ad un syslog server esterno per inviare i log a questo,
anzichè tenerseli su disco.
Probabilmente avrai anche altro, ma dipende dall'installazione-tipo che
utilizzi.
In ogni caso, visto che comunque il firewall deve comunicare con la tua
rete (se non addirittura con l'esterno), è imho auspicabile che possa
farlo *solo* per le funzionalità necessarie e verso gli host necessari.
Come CtRiX faceva notare, un primo vantaggio palese è quello di limitare
le posibilità di exploit : se anche qualcuno dovesse riuscire ad
ottenere una compromissione approfittando di uno dei client ivi
residenti (immaginiamo per caso ntpdate, che, dovendo aggiornare il
clock di sistema, gira come utente privilegiato), avrà le sue belle
difficoltà ad avere una shell remota inversa, fintantochè il kernel
droppa le proprie connessioni...
Magari sono paranoie inutili, ma per quello che costa preferisco così...
Byez...
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

 ne' quelli forwardati.
Ok. Ho detto cazzate...


 rischio.
Mah... in questo caso io ragionerei cosi': se te l'hanno exploitata, e sono in
grado di fare un netcat, allora sono probabilmente in grado di fare anche un
flush di OUTPUT...   ;-)


 droppa le proprie connessioni...
Vero... anche quello. E' una filosofia che per il momento adotto solo per
gli host in dmz. Se me ne exploitano uno, non puo' comunque uscire. Puo'
essere utile, magari, adottarla anche per le connessioni iniziate dal
firewall.


 flush di OUTPUT...   ;-)
Pardon, ritiro tutto, non avevo capito la tecnica di exploit. OK.    :-)


 catena di POSTROUTING.
<< POSTROUTING: This is where we do SNAT as described earlier. It is 
   suggested that you don't do filtering here since it can have side 
   effects, and certain packets might slip through even though you set 
   a default policy of DROP. >>
(...ahem...)
Fabio

 (...ahem...)
Trimack, che deve rivedere alcune sue convinzioni.
[1] Ho sempre pensato di poter riunire i filtri nella catena POSTROUTING
che e' l'unica attraversata sia dai pacchetti forwardati che da quelli
locally genereted.
Evidentemente mi sbagliavo.
Grazie per la precisazione.


 locally genereted.
Infatti sembrava molto intelligente la tua soluzione, meno regole nelle 
chain e probabilmente attraversamento piu' veloce; infatti pareva molto 
strano non aver mai sentito menzionare un discorso come il tuo , andro' 
anch'io a documentarmi sul problema mostrato da Fabio.
Comunque l'idea era ottima, imho. :-)
-- 
Sono un servitore del Fuoco Segreto, e reggo la fiamma di Anor.
A nulla ti servira' il fuoco oscuro, fiamma di Udun.
Torna nell'Ombra! Non puoi passare.

 locally genereted.
Se non ho capito male, il problema nasce dal fatto che dalla
POSTROUTING passa soltanto il primo pacchetto d'una sessione
mentre i successivi no. E' un aspetto che non mi e' chiaro e
che non ho mai avuto tempo di approfondire. Visto che io non
filtro nella POSTROUTING [1], me lo sono segnato nell'elenco
to-do-low-priority.txt.
Il documento da cui l'ho appreso e' proprio quello che citi.
Mi sembra ben scritto e uno dei piu' completi e dettagliati,
tra quelli che si mantengono a livello sistemistico e non di
sviluppo. Mi fiderei, pur riservandomi di verificare qualche
aspetto (come questo).
Fabio
[1] difficile che mi serva filtrare con regole simili sia il
    traffico in uscita sia il traffico in transito.

 aspetto (come questo).
Vero. E' anche nella mia documentazione di iptables, anche se 
l'ho guardato superficialemente, preferendogli la doc 
ufficiale di 
netfilter.org
Trimack, per adesso senza sign