Next Previous Contents

3. Server

Questa sezione descrive come configurare le cose dal lato server, propongo prima questo poichè senza un server, il client è praticamente inutile.

3.1 Sicurezza - tenere fuori gli altri

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.

Controlla i tuoi daemons

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.

Non permettere passwords

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.

3.2 Accesso degli utenti - far entrare la gente

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.

Configurazione di 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

3.3 Restrizione degli utenti

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.

sudo si o no

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.

3.4 Networking

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.

Il Kernel

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:

Regole di filtraggio

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.

Routing

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.)


Next Previous Contents