Home Mappa Indice Ricerca News Archivi Link A proposito di LF
[Barra superiore]
[Barra inferiore]
[Foto dell'Autore]
di Atif Ghaffar

Notizie sull'autore:

Vivo e lavoro in Svizzera come webmaster ed amministratore unix. Le mie passioni includono Linux, unix, Perl, Apache e i software GPL. Altre notizie su di me si trovano sulla mia homepage

Contenuto:

Come usare la direttiva ProxyPass di Apache per accedere a server dietro un Masquerading host

[Illustrazione]

Sommario:

Mantengo una piccola LAN a casa, "mascherata" con Linux usando ip masquerading e ip firewall. Benché tutte le macchine della mia rete possano accedere a tutte le informazioni su internet, solo la macchina che fa il mascheramento è visibile da internet. Nel mio ultimo articolo su Apache, vi ho mostrato come riciclare gli indirizzi ip; in questo articolo vi mostro come rendere visibile un server web dietro un firewall su internet senza cambiare le regole del firewall o compromettere la sicurezza. In questo artiolo vedremo come usare la direttiva ProxyPass di Apache per raggiungere questo obiettivo. Questo articolo è indirizzato agli Amministratori di Sistema e a chiunque stia installando una LAN di piccole o medie dimensioni a casa o al lavoro.



 

Il problema del mascheramento IP

Per un lungo periodo nella mia LAN, il router (la macchina che si occupava del masquerading/firewall) ha funto anche da server web, server mail, server ftp, server dns e tutto.
Un giorno ebbi la necessità di rendere accessibili contenuti web da un'altra macchina posta dietro il firewall.
Volevo anche rendere accessibili alcuni documenti da una SGI IRIX posta dietro la rete (un server video per filmati). Questa macchina aveva acesso pieno a internet, ma gli utenti di internet non potevano connettersi alla macchina. Sebbene non avessi intenzione di collegare questa macchina IRIX alla rete, era necessario che ci si potesse connettere al servizio web messo a disposizione da questa macchina.

Stavo affrontando lo stesso problema a lavoro con una rete simile ed un firewall.
Ogni volta qualcuno voleva che un server web di sviluppo fosse reso visibile da internet per scopi dimostrativi, le regole sul firewall dovevano essere cambiate e bisognava dare alla macchina un indirizzo IP esterno compromettendo la sicurezza della rete.

 

Un aiuto da Apache: la direttiva ProxyPass

Dopo aver valutato diverse soluzioni ne ho implementato una con Apache e la sua direttiva ProxyPass.
ProxyPass richiede che mod_proxy sia incluso nel vostro server Apache, oppure caricato come modulo.
Ecco la definizione della direttiva ProxyPass (tratta dal manuale di Apache):

ProxyPass

Sintassi: ProxyPass <percorso> <url>
Valore predefinito: Nessuno
Contesto: configurazione del server, host virtuale
Override: Non applicabile
Stato: Base
Modulo: mod_proxy
Compatibilità: ProxyPass è disponibile solo in Apache 1.1 e successivi.

Questa direttiva consente a server remoti di essere ricollocati nello spazio del server locale; il server locale non agisce come proxy nel senso convenzionale, ma appare come un mirror del server remoto. <percorso> è il nome di un percorso virtuale locale; <url> è una URL parziale per il server remoto.

Supponiamo che il server locale abbia l'indirizzo http://wibble.org/; allora la direttiva

   ProxyPass /mirror/foo/ http://foo.com/
farà si che una richiesta locale del tipo <http://wibble.org/mirror/foo/bar> sia internamente convertita in una richiesta proxy ad <http://foo.com/bar>.

 

Un esempio concreto

Ricollocazione del server video interno nel server web esterno.
Rete interna: hometranet.home 192.168.1.0/255.255.255.0
(nel paradigma di internet, intranet, extranet, chiamo la mia rete domestica hometranet)
Rete esterna: developer.ch 193.192.254.50

Il server video (interno) è in esecuzione sull'host cam.hometranet.home e fornisce
filmati video dalla url http://cam.hometranet.home:5555/cams/sony/stream
e
immagini statiche dalla telecamera alla url http://cam.hometranet.home:5555/cams/sony/image
I risultati di quelle url dovevano essere visibili visitando
http://mozilla.developer.ch/stream
e
http://mozilla.developer.ch/image
Questo risultato è facilmente ottenibile con la direttiva ProxyPass di Apache semplicemente aggiungendo le seguenti linee nel file httpd.conf o srm.conf

ProxyPass /video http://cam.hometranet.home:5555/cams/sony/stream
ProxyPass /video http://cam.hometranet.home:5555/cams/sony/stream
A questo punto, riavviando il server web (se mod_proxy era disponibile), all'indirizzo http://mozilla.developer.ch/image risponde il server web della telecamera.
Per l'utente che visita il sito è totalmente trasparente, e in queto modo la sicurezza è stata salvaguardata quasii* completamente.
*Dico quasi, perché non esiste la sicurezza totale su internet :)

 

Ricollocazione di Server Virtuali

Il trucco della direttiva proxypass può essere usato per ricollocare interamente un host virtuale su un'altra macchina.
Per esempio:
docs.sun.developer.ch ricollocato in solsparc.hometranet.home

NameVirtualHost 193.192.254.50
<VirtualHost 193.192.254.50>
     ServerName sun.docs.developer.ch
     ProxyPass / http://solsparc.hometranet.home/
     TransferLog /net/www/logs/sun.docs.access
     ErrorLog    /net/www/logs/sun.docs.errror
</VirtualServer>
il reindirizzamento può anche essere effettuato tramite indirizzo IP
<VirtualHost 193.192.254.50>
     ServerName sun.docs.developer.ch
     ProxyPass / http://192.168.1.7/
     TransferLog /net/www/logs/sun.docs.access
     ErrorLog    /net/www/logs/sun.docs.errror
</VirtualServer>
 

Avvertimenti

Visto che il server web principale genera richieste a quelli interni a nome degli utenti di quella macchina, non è possibile effettuare dei monitoraggi significativi sugli host di destinazione; tutte le richieste dovranno essere registrate sull'host sorgente.
Nel caso appena visto tutte le registrazioni vengono fatte sull'host principale sun.docs.developer.ch invece che su solsparc.hometranet.home
Registrazioni su sun.docs.developer.ch (fittizie)

197.0.22.3 - - [05/Nov/1999:22:09:04 +0100] "GET /index.html HTTP/1.0" 304 -
187.0.45.67 - - [05/Nov/1999:22:09:04 +0100] "GET /navi.html HTTP/1.0" 304 -
177.0.5.45 - - [05/Nov/1999:22:09:04 +0100] "GET /entrees.html HTTP/1.0" 304 -
227.0.9.67 - - [05/Nov/1999:22:09:15 +0100] "GET /complets.html HTTP/1.0" 304 -
137.0.7.23 - - [05/Nov/1999:22:09:19 +0100] "GET /menu_poisson.html HTTP/1.0" 200 841
193.192.245.73 - - [05/Nov/1999:22:09:25 +0100] "GET /volailles.html HTTP/1.0" 304 -
192.167.0.1 - - [05/Nov/1999:22:09:44 +0100] "GET /agneau.html HTTP/1.0" 304 -                                                            
Registrazioni su solsparc.hometranet.home
192.168.1.1 - - [05/Nov/1999:22:09:04 +0100] "GET /index.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:04 +0100] "GET /navi.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:04 +0100] "GET /entrees.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:15 +0100] "GET /complets.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:19 +0100] "GET /menu_poisson.html HTTP/1.0" 200 841
192.168.1.1 - - [05/Nov/1999:22:09:25 +0100] "GET /volailles.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:44 +0100] "GET /agneau.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:56 +0100] "GET /desserts_ind.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:10:00 +0100] "GET /cocktails.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:10:10 +0100] "GET /cgi-bin/commande.cgi HTTP/1.0" 200 2146        

Lo stesso vale anche per le ACL (liste di controllo degli accessi) basate sui nomi o sugli indirizzi IP.
Se si vuole bloccare alcuni host o indirizzi IP, a dare accesso a certi indirizzi IP ad aree speciali, allora occorre operare sul server principale (quello visibile dall'esterno) invece che su quello locale.
Inoltre non è possibile discriminare gli utenti in base alla Directory.
E' comunque possibile usare le direttive Location o Files o FilesMatch.
Il seguente esempio riguarda alcune di esse. Esempio:
<VirtualHost 193.192.254.50>
     ServerName sun.docs.developer.ch
     #this rule only allows users from good.host.com domain
     <Location /private>
          order deny,allow
          deny from all
          allow from good.host.com
     </Location>
     #This rule deny's the uncool Microsoft's monopoly helper browser.
     BrowserMatch MSIE uncool_browser
     <Location /coolpages>
         order allow,deny
         allow from all
         deny from env=uncool_browser
     </Location>
     #This rule only allows users that are in your passwd.httpd file
     <Location /coolpages>
         AuthName "only for registered users"
         AuthType Basic
         AuthUserFile "/etc/httpd/passwd.httpd"
         <Limit GET>
              require valid-user
         </Limit>
     </Location>

     ProxyPass / http://192.168.1.7/
     TransferLog /net/www/logs/sun.docs.access
     ErrorLog    /net/www/logs/sun.docs.errror
</VirtualServer>

 

Altre Risorse

[Documentazione del mod_proxy di Apache]
http://www.apache.org/docs/mod/mod_proxy.html
[Supporto di Apache agli Host Virtuali basati sui nomi]
http://www.apache.org/docs/vhosts/name-based.html
[Documentazione di Apache agli Host Virtuali]
http://www.apache.org/docs/vhosts/index.html
 

Commenti per questo articolo

Ogni articolo ha la sua pagina dei commenti. Su questa pagina possibile inviare un commento o leggere i commenti degli altri lettori:
 Pagina dei commenti 

Pagine web mantenute dal Team degli Editori di LinuxFocus
© Atif Ghaffar
LinuxFocus.org 2000

Clicca qui per segnalare un errore o per inviare un commento a Linuxfocus
Informazioni sulla traduzione:
en -> -- Atif Ghaffar
en -> it Antonio Schifano

2000-04-28, generated by lfparser version 1.5