<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>VPN HOWTO: Server</TITLE>
<LINK HREF="VPN-HOWTO-4.html" REL=next>
<LINK HREF="VPN-HOWTO-2.html" REL=previous>
<LINK HREF="VPN-HOWTO.html#toc3" REL=contents>
</HEAD>
<BODY>
<A HREF="VPN-HOWTO-4.html">Avanti</A>
<A HREF="VPN-HOWTO-2.html">Indietro</A>
<A HREF="VPN-HOWTO.html#toc3">Indice</A>
<HR>
<H2><A NAME="s3">3. Server</A> </H2>
<P>Questa sezione descrive come configurare le cose dal lato server,
propongo prima questo poichè senza un server, il client è praticamente
inutile.
<P>
<H2><A NAME="ss3.1">3.1 Sicurezza - tenere fuori gli altri</A>
</H2>
<P>La sicurezza è molto importante per una VPN. Questo perchè, in primo
luogo, la responsabilità della costruzione della VPN è tua, giusto? Bisogna tenere a
mente alcune cose mentre si configura il server.
<H3>Controlla i tuoi daemons </H3>
<P> Dal momento che questo server passa dati da entrambi i lati del
firewall, fino al traffico interno della rete, è una buona idea di rendere
sicura la VPN box il meglio che sia possibile. Puoi leggere molto più
sulla sicurezza di Linux in
<A HREF="/HOWTO/Security-HOWTO.html">Linux Security HOWTO</A> per i miei scopi ho eliminato tutti i
demoni che girano in background eccetto sshd e Roxen Web. Uso il server
web per scaricare un paio di file (i miei scripts, ecc) quando ho
l'occasione di configurare delle nuove macchine che accedono alla VPN. Non
uso un server FTP dal momento che è più difficile configurarlo che rendere
accessibili un paio di file tramite server web. In più, solo io devo
essere in grado di scaricare i files. Se si vuole realmente far girare
molteplici server sul gateway, si dovrebbe pensare ad un accesso ristretto
alle sole macchine sulla rete privata.
<H3>Non permettere passwords </H3>
<P>Con questo titolo ho avuto la tua attnezione, vero? No, non si devono
usare passwords, bisogna disabilitarle completamente. Tutta l'autenticazione
su questa macchina deve essere fatta attraverso un sistema di autenticazione a
chiave pubblica tipo ssh. In questo modo, solo chi possiede la chiave può
entrare, ed è praticamente impossibile ricordarsi una chiave binaria lunga 530
caratteri.
<P>Così cosa si deve fare? Bisogna editare il file /etc/passwd. Il secondo
campo contiene la stringa della password, o alternativamente 'x' significando
che il sistema di autentificazione lo si può trovare nel file /etc/shadow.
Quello che devi fare è cambiare il campo da leggere con '*'. Questo dice al
sistema di autentificazione che non ci sono password, e che non sono richieste.
<P>
<A NAME="passwd"></A>
Qui si può vedere un tipico esempio di file /etc/passwd:
<PRE>
...
nobody:x:65534:100:nobody:/dev/null:
mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash
joe:*:504:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd
bill:*:504:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd
frank:*:504:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd
...
</PRE>
Nota che ho fatto molto di più che editare il secondo campo. Dirò di più
a riguardo degli altri campi in seguito.
<H2><A NAME="ss3.2">3.2 Accesso degli utenti - far entrare la gente </A>
</H2>
<P>L'accesso degli utenti è eseguito tramite uno schema di autenticazione
ssh. Come detto sopra, questo è come gli utenti accedono al sistema,
mantenendo, nel contempo, un alto livello di sicurezza. Se non hai
familiarità con ssh, controlla
<A HREF="http://www.ssh.org/">http://www.ssh.org/</A>
Nota che io ho usato ssh versione 1, non la versione 2. C'è una grande
differenza, infatti la versione 1 è free mentre la 2 no.
<P>
<H3>Configurazione di <CODE>sshd</CODE> </H3>
<P>Ora si avrà bisogno di configurare sshd. Le seguenti opzioni dovrebbero
essere presenti. L'idea è di disabilitare l'autenticazione delle password e
l'autenticazione di rhosts. Le seguenti opzioni dovrebbero essere presenti nel
file <CODE>/etc/sshd_config</CODE>.
<P>
<P>
<PRE>
PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
</PRE>
<H2><A NAME="ss3.3">3.3 Restrizione degli utenti</A>
</H2>
<P>Ora che puoi tenere i "cattivi" fuori, e far accedere solo i "buoni", devi
assicurarti che i "buoni" si vedano tra loro. Questa è la cosa più facile in
assoluto poichè non devi fare null'altro oltre a lanciare pppd. Questo può
essere necessario o meno. Ho ristretto l'accesso degli utenti perchè il
sistema che mantengo è dedicato alla VPN, gli utenti non hanno nessuna
attività da fare su di esso.
<H3>sudo si o no </H3>
<P>Esiste un piccolo programma chiamato sudo che permette
all'amministratore di un sistema Unix di garantire a certi utenti la
possibilità di lanciare certi programmi come root. Questo è necessario nel
caso che pppd debba girare come root. Si avrà bisogno di usare questo metodo
se si vuole permettere l'accesso della shell agli utenti. Leggi come
configurare e usare sudo nelle pagine man relative a sudo stesso. L'uso di
sudo è la miglior cosa da fare su sistemi "multi-uso" che mantengono un
piccolo numero di utenti certificati e sicuri.
<P>Se si decide di non permettere a nessuno di accedere alla shell, allora
il modo migliore è tenerli fuori è di far in modo che la loro schell sia pppd.
Ciò può essere fatto nel file /etc/passwd. Puoi vedere qui
<A HREF="#passwd">sopra</A> quello che ho fatto per gli ultimi tre utenti.
L'ultimo campo del file /etc/passwd è la shell utente. Non hai bisogno di fare
nulla di speciale a pppd per far in modo che funzioni. Verrà eseguito come
root quando l'utente si connette. Questa è certamente la più semplice
configurazione che si possa fare, e anche la migliore e più sicura. Ho
descritto esattamente tutto quello che deve essere fatto più avanti nel
documento. Puoi
<A HREF="VPN-HOWTO-5.html#user-accounts">andare avanti</A> se ti pare.
<P>
<H2><A NAME="ss3.4">3.4 Networking</A>
</H2>
<P>Ora che gli utenti hanno accesso al sistema, dobbiamo essere sicuri che
abbiano anche accesso alla rete. Facciamo questo usando le impostazioni di
firewalling del kernel di Linux e la tabelle di routing. Usando i comandi
<CODE>route</CODE> e <CODE>ipfwadm</CODE>, potremo configurare il kernel per
instradare il traffico di rete nel modo più appropiato. Per ulteriori
informazioni su <CODE>ipfwadm</CODE>, <CODE>ipchains</CODE> e <CODE>route</CODE> vedi
<A HREF="http://www.linuxdoc.org/HOWTO/Linux-Networking-HOWTO.html">Linux Networking HOWTO</A>.
<P>
<H3>Il Kernel </H3>
<P>In modo che tutto ciò funzioni, si deve avere il kernel configurato
correttamente. Se non si sa come compilare il proprio kernel, allora può
essere una utile lettura il
<A HREF="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</A>. Hai bisogno di essere sicuro che le seguenti opzioni del kernel
siano attivate in aggiunta a quelle basilari sulla rete. Uso un kernel 2.0.38
nel mio sistema.
<P>Per i kernel 2.0:
<UL>
<LI>CONFIG_FIREWALL</LI>
<LI>CONFIG_IP_FORWARD</LI>
<LI>CONFIG_IP_FIREWALL</LI>
<LI>CONFIG_IP_ROUTER</LI>
<LI>CONFIG_IP_MASQUERADE (optional)</LI>
<LI>CONFIG_IP_MASQUERADE_ICMP (optional)</LI>
<LI>CONFIG_PPP</LI>
</UL>
<P>Per i kernel 2.2:
<UL>
<LI>CONFIG_FIREWALL</LI>
<LI>CONFIG_IP_ADVANCED_ROUTER</LI>
<LI>CONFIG_IP_FIREWALL</LI>
<LI>CONFIG_IP_ROUTER</LI>
<LI>CONFIG_IP_MASQUERADE (optional)</LI>
<LI>CONFIG_IP_MASQUERADE_ICMP (optional)</LI>
<LI>CONFIG_PPP</LI>
</UL>
<H3>Regole di filtraggio </H3>
<P>Primo, scriveremo delle regole di filtraggio per il firewall che
permetteranno ai nostri utenti di accedere alla nostra rete interna, mentre
restringeremo l'accesso a richieste che arrivano da internet. Se questo suona strano, pensalo in questo modo:
loro hanno già l'accesso ad internet, così perchè
usare il tunnel della VPN per accedere alla rete? E' uno spreco di banda e
tempo macchina.
<P>
<P>Le regole di filtraggio che useremo dipendono da quali reti interne
usiamo. Ma fondamentalmente diciamo: "Permettere che il traffico proveniente dalla VPN, e destinato alle
nostre reti interne, ci arrivi". Allora, come
dobbiamo farlo? Come sempre, dipende. Se è presente un kernel 2.0, si usa il
tool chiamato <CODE>ipfwadm</CODE>, se d'altra parte stai usando un kernel 2.2,
usa l'utility chiamata <CODE>ipchains</CODE>.
<P>
<P>Per configurare le regole con <CODE>ipfwadm</CODE>, lancialo con le opzioni
simile alle seguenti:
<P>
<P>
<PRE>
# /sbin/ipfwadm -F -f
# /sbin/ipfwadm -F -p deny
# /sbin/ipfwadm -F -a accept -S 192.168.13.0/24 -D 172.16.0.0/12
</PRE>
<P>Per configurare le regole con <CODE>ipchains</CODE>, lancialo con le opzioni
simili alle seguenti:
<P>
<P>
<PRE>
# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s 192.168.13.0/24 -d 172.16.0.0/12
</PRE>
<P>Per quelli che usano il kernel 2.2, prego leggete
<A HREF="VPN-HOWTO-6.html#ipv4forwarding">questo</A>.
<H3>Routing </H3>
<P>Così, ora i nostri utenti hanno il permesso di accedere alle nostre reti,
ora abbiamo bisogno di dire al kernel dove spedire i pacchetti. Sul mio
sistema, ho due schede ethernet, una è per la rete esterna, mentre l'altra è
la rete interna. Quasto aiuta a tenere le cose sicure, poichè il traffico per
l'esterno è mascherato dal nostro gateway, e qualsiasi traffico entrante è
filtrato e instradato dal router Cisco. Per la miglior configurazione possibile, il routing
dovrebbe essere semplice.
<P>Quello che facciamo è instradare tutto il traffico destinato per le
nostre reti private attraverso l'interfaccia interna, e tutto il resto
attraverso l'interfaccia esterna. I comandi specifici di instradamento
dipendono da quale rete interna stai usando. Sotto è presentato un esempio di
come dovrebbe essere fatto. Queste linee sono, naturalmente, in aggiunta agli
instradamenti base per le tue reti locali. Dubito, comunque, che userai tutti
e 3 i gruppi di numeri interni.
<P>
<PRE>
Assumendo che 172.16.254.254 sia il tuo gateway interno:
# /sbin/route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.254.254 dev
eth1
# /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.16.254.254
dev eth1
# /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.16.254.254
dev eth1
</PRE>
<P>Una nota addizionale sull'instradamento. Se stai usando due modi per
l'instradamento, ad esempio un ufficio remoto, allora avrai bisogno di fare
una cosa ulteriore. Avrai bisogno di configurare la tabelle di instradamento
sul server che ritorna sul client. Il modo più facile di far ciò è di lanciare
un job cron ogni minuto che silenziosamente setta all'indietro
l'instradamento. Non è una buona idea se il client non è connesso,
<CODE>route</CODE> sparerà fuori un errore (che ti converrà spedire a
<CODE>/dev/null</CODE>.)
<HR>
<A HREF="VPN-HOWTO-4.html">Avanti</A>
<A HREF="VPN-HOWTO-2.html">Indietro</A>
<A HREF="VPN-HOWTO.html#toc3">Indice</A>
</BODY>
</HTML>
