Questa sezione descrive come configurare le cose dal lato server, propongo prima questo poichè senza un server, il client è praticamente inutile.
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.
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 Linux Security HOWTO 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.
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.
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.
Qui si può vedere un tipico esempio di file /etc/passwd:
... 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 ...Nota che ho fatto molto di più che editare il secondo campo. Dirò di più a riguardo degli altri campi in seguito.
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 http://www.ssh.org/ 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.
sshd 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 /etc/sshd_config.
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
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.
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.
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 sopra 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 andare avanti se ti pare.
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
route e ipfwadm, potremo configurare il kernel per
instradare il traffico di rete nel modo più appropiato. Per ulteriori
informazioni su ipfwadm, ipchains e route vedi
Linux Networking HOWTO.
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 Kernel HOWTO. 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.
Per i kernel 2.0:
Per i kernel 2.2:
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.
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 ipfwadm, se d'altra parte stai usando un kernel 2.2,
usa l'utility chiamata ipchains.
Per configurare le regole con ipfwadm, lancialo con le opzioni
simile alle seguenti:
# /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
Per configurare le regole con ipchains, lancialo con le opzioni
simili alle seguenti:
# /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
Per quelli che usano il kernel 2.2, prego leggete questo.
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.
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.
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
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,
route sparerà fuori un errore (che ti converrà spedire a
/dev/null.)