![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Precedente: Network Address Translation] [Indice] [Successivo: Ottimizzazione delle regole di configurazione]
Vediamo un esempio:
rdr on tl0 proto tcp from any to any port 80 -> 192.168.1.20
Questa regola effettua il reindirizzamento del traffico TCP sulla porta 80 (web server) a un'host della rete locale con IP 192.168.1.20. Così anche se il 192.168.1.20 è dietro il gateway e all'interno della rete locale risulta accessibile dal mondo esterno.
La parte from any to any della regola rdr può essere abbastanza utile. Se si conoscono quali indirizzi o subnet devono avere accesso alla porta 80 del web server si può restringere il campo di indirizzi:
rdr on tl0 proto tcp from 27.146.49.0/24 to any port 80 -> \
192.168.1.20
Questa regola effettuerà il reindirizzamento della sola subnet specificata. Questo implica che è possibile specificare il reindirizzamento del traffico in ingresso proveniente da differenti host, al di la del gateway, su diverse workstation della rete locale. Questo può essere molto utile. Per esempio, conoscendo semplicemente il loro IP di connessione si potrebbero avere utenti che da remoto accedono ognuno al proprio computer desktop connettendosi tutti allo stesso IP e alla stessa porta del gateway:
rdr on tl0 proto tcp from 27.146.49.14 to any port 80 -> \
192.168.1.20
rdr on tl0 proto tcp from 16.114.4.89 to any port 80 -> \
192.168.1.22
rdr on tl0 proto tcp from 24.2.74.178 to any port 80 -> \
192.168.1.23
Con le stesse regole si può eseguire il reindirizzamento di un range di porte:
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 6000
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 7000:*
Questi esempi mostrano che le connessioni alle porte da 5000 a 5500 compresi vengono indirizzati al 192.168.1.20 nella prima regola, la porta 5000 è reindirizzata alla 5000, 5001 alla 5001, ecc. Nella seconda regola l'intero range di porte è reindirizzato alla porta 6000. E nella terza regola la porta 5000 è reindirizzata alla 7000, la 5001 alla 7001, ecc.
La sola eccezione a questa regola si ha quando la keyword pass è usata con la regola rdr. In questo caso i pacchetti reindirizzati oltrepasseranno il firewall: le regole di filtraggio non saranno applicate a questi pacchetti. Questa è una comoda scorciatoia per evitare di aggiungere regole pass di filtraggio per ogni regola di reindirizzamento. E' come se fosse una normale regola rdr (senza la keyword pass) associata a una regola pass di filtraggio con la keyword keep state. Comunque, se si desiderassero abilitare più opzioni specifiche di filtraggio come synproxy, modulate state, ecc. occorrerebbe utilizzare una regola pass dedicata a queste opzioni perchè esse non rientrano nelle regole di reindirizzamento.
Inoltre bisogna fare attenzione al fatto che la traslazione avviene prima del filtraggio, quindi il firewall vedrà i pacchetti traslati dalla regola rdr in indirizzo IP e/o porta di destinazione. Consideriamo questo scenario:
Regola di reindirizzamento:
rdr on tl0 proto tcp from 192.0.2.1 to 24.65.1.13 port 80 \
-> 192.168.1.5 port 8000
Pacchetto prima dell'rdr:
Pacchetto dopo l'rdr:
Il firewall vedrà il pacchetto IP come appare dopo l'avvenuta traslazione.
Questo rischio può essere minimizzato tenendo gli accessi esterni al sistema, strettamente confinati su una rete separata. Questa rete è spesso definita Zona Demilitarizzata (DMZ) o Private Service Network (PSN). In questo modo se il server web dovesse essere compromesso, l'effetto può essere limitato alla rete DMZ/PSN purchè esistano opportune regole di filtraggio per e da DMZ/PSN.
server = 192.168.1.40
rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server \
port 80
Ma quando la regola di reindirizzamento è testata da un client sulla LAN non funziona. La ragione è che le regole di reindirizzamento si applicano solo a pacchetti che attraversano l'nterfaccia di rete specificata ($ext_if, l'interfaccia esterna nell'esempio). Connettendosi all'indirizzo esterno del firewall da un host sulla LAN, non significa comunque che i pacchetti passino attraverso l'interfaccia esterna. Lo stack TCP/IP sul firewall confronta l'indirizzo di destinazione dei pacchetti entranti con il suo stesso indirizzo e gli alias determinando connessioni a se stesso non appena i pacchetti attraversano l'interfaccia di rete interna. Questo tipo di pacchetti non attraversano fisicamente l'interfaccia esterna e lo stack non simula in nessun modo questo passaggio. Così, PF non vede mai questi pacchetti sull'interfaccia esterna e le regole di reindirizzamento specifiche per l'interfaccia esterna non vengono applicate.
Anche aggiungendo una seconda regola di reindirizzamento sull'interfaccia di rete interna non ha comunque l'effetto desiderato. Quando il client locale si connette all'indirizzo esterno del firewall, il pacchetto iniziale del TCP handshake raggiunge il firewall attraverso l'interfaccia interna. La regola di reindirizzamento viene applicata e l'indirizzo destinazione viene sostituito con quello del server interno. Il pacchetto viene trasferito indietro attraverso l'interfaccia interna e raggiunge il server. Ma l'indirizzo sorgente non è traslato e contiene ancora l'indirizzo del client locale, così il server invia le sue risposte direttamente al client. Il firewall non vede mai le risposte e non c'è possibilità di effettuare in modo appropriato la traslazione inversa. Il client riceve una risposta da un host inaspettato e getta via i pacchetti. Quindi l'handshake fallisce e non si stabilisce alcuna connessione.
E' comunque consigliabile al client della LAN di connettersi in modo trasparente al server interno come un client esterno. Ci sono diverse soluzioni a questo problema:
E' possibile configurare il server DNS per rispondere in modo differente alle richieste da host interni rispetto a quelle provenienti dall'esterno, fornendo agli host locali, durante la risoluzione dei nomi, direttamente l'indirizzo del server interno. Essi saranno quindi connessi direttamente al server locale e il firewall non sarà coinvolto. Questo riduce il traffico locale dato che i pacchetti non devono essere inviati attraverso il firewall.
Aggiungendo un'ulteriore interfaccia di rete al firewall si crea una network dedicata (DMZ) dove spostare il server e alla quale reindirizzare le connessioni dal client proprio come un reindirizzamento di connessioni esterne. L'uso di network separate ha diversi vantaggi, tra i quali il miglioramento della sicurezza dovuto all'isolamento del server dal resto degli host locali. Se mai il server (raggiungibile da Internet) dovesse essere compromesso, non si potrà accedere direttamente ad altri host locali dato che tutte le connessioni devono passare attraverso il firewall.
Un generico TCP proxy può essere configurato sul firewall sia ascoltando sulla porta che sarà reindirizzata oppure stabilendo connessioni con l'interfaccia interna reindirizzata alla porta che ascolta. Quando un client locale si connette al firewall, il proxy accetta la connessione, stabilisce una seconda connessione al server interno e trasferisce i dati tra le due connessioni.
Semplici proxy possono essere creati usando inetd(8) e nc(1). La seguente riga di /etc/inetd.conf crea un socket in ascolto limitato all'indirizzo di loopback (127.0.0.1) e alla porta 5000. Le connessioni sono trasferite alla porta 80 del server 192.168.1.10.
127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w \
20 192.168.1.10 80
La seguente regola di reindirizzamento trasferisce il traffico sulla porta 80 dell'interfaccia interna al proxy:
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
127.0.0.1 port 5000
Con un'ulteriore regola di NAT sull'interfaccia interna si può risolvere il problema legato alla mancanza della traslazione dell'indirizzo sorgente descritta precedentemente.
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
$server
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $server port 80 -> \
$int_if
Questo causa un'ulteriore traslazione del pacchetto che dal client raggiunge il firewall e nuovamente viene trasferito indietro all'interfaccia interna sostituendo l'indirizzo sorgente del client con l'indirizzo interno del firewall. Il server interno risponderà al firewall, il quale effettuando entrambe le traslazioni NAT e RDR sarà in grado di trasferire i pacchetti al client locale. Questa soluzione è abbastanza complicata perchè crea due stati separati per ogni connessione riflessa. Occorre fare attenzione a prevenire che la regola di NAT venga applicata ad altro traffico, per esempio a connessioni originate da host esterni (attraverso altri reindirizzamenti) o dal firewall stesso. C'è da notare che la regola rdr vista sopra consente allo stack TCP/IP di vedere pacchetti in arrivo sull'interfaccia interna con un indirizzo destinazione appartenente alla rete locale.
In generale si dovrebbero usare le soluzioni viste precedentemente.
[Precedente: Network Address Translation] [Indice] [Successivo: Ottimizzazione delle regole di configurazione]
![[back]](../../../images/back.gif){kind=small}
www@openbsd.org