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: |
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.
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.
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):
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>.
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 :)
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>
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 2146Lo stesso vale anche per le ACL (liste di controllo degli accessi) basate sui nomi o sugli indirizzi IP.
<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>
|
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:
|
2000-04-28, generated by lfparser version 1.5