Difference between revisions of "Small Business Server (Italiano)"

From ArchWiki
Jump to: navigation, search
(Mail Server)
Line 15: Line 15:
 
Per ultimo un consiglio, anche se sembrerà una cosa ovvia io ve lo dico lo stesso: non mettete le guide in pratica a pappagallo, cercate di capire almeno a grandi linee quello che state facendo. Se stiamo installando il servizio DNS o LDAP almeno documentatevi prima su cosa diavolo siano. Non installate un server in una azienda non capendo gli argomenti trattati, altrimenti (come spesso succede) alla prima difficoltà non saprete che pesci pigliare e meledicerete il momento in cui avete deciso di installare un server con ArchLinux (o Linux in generale).
 
Per ultimo un consiglio, anche se sembrerà una cosa ovvia io ve lo dico lo stesso: non mettete le guide in pratica a pappagallo, cercate di capire almeno a grandi linee quello che state facendo. Se stiamo installando il servizio DNS o LDAP almeno documentatevi prima su cosa diavolo siano. Non installate un server in una azienda non capendo gli argomenti trattati, altrimenti (come spesso succede) alla prima difficoltà non saprete che pesci pigliare e meledicerete il momento in cui avete deciso di installare un server con ArchLinux (o Linux in generale).
  
Buona lettura, e sentitevi liberi di correggere e contribuire alla guida.
+
Gli articoli provengono dal [http://www.stenoweb.it/taxonomy/term/6 Blog di Steno], pubblicati con licenza [http://creativecommons.org/licenses/by-sa/2.5/it/deed.it CC Attribution-ShareAlike].
  
= Operazioni Preliminari =
+
Sentitevi liberi di contribuire, magari iniziando da una traduzione in inglese per rendere più visibile la guida.
 +
 
 +
= Indice della guida =
 +
Questa è la lista degli articoli pubblicati, buona lettura, e sentitevi liberi di correggere e contribuire alla guida.
 +
#[[ArchSBS001|Operazioni Preliminari]]
 +
#[[ArchSBS002|LDAP Server]]
 +
#[[ArchSBS003|DNS dinamico e DHCP]]
 +
#[[ArchSBS004|Firewall]]
 +
#[[ArchSBS005|File server domain controller]]
 +
#[[ArchSBS006|Mail Server]]
  
 
Iniziamo la configurazione del nostro ArchLinux SBS con delle operazioni preliminari per rendere la nostra box pronta al via.
 
Iniziamo la configurazione del nostro ArchLinux SBS con delle operazioni preliminari per rendere la nostra box pronta al via.
 
== Convenzioni ==
 
*eth0 sarà la scheda ethernet collegata alla nostra LAN. Verrà fornita di un indirizzo IP statico.
 
*eth1 sarà la scheda ethernet collegata a internet (o alla WAN). Avrà un indirizzo IP statico (se disponibile) o assegnato dal provider con DHCP. Attenzione: se volessi configurare la mia box come server VPN un indirizzo statico è consigliato.
 
*192.168.20.0/24 è la mia rete interna
 
*192.168.20.1 è l'indirizzo IP statico assegnato a eth0
 
*il nostro server si chiama ''archi'' (che fantasia!)
 
*il nostro dominio sarà ''mede.it''
 
*il nostro utente amministrativo sarà ''admin''
 
 
Iniziamo a preparare il nostro '''''archi.mede.it ''''' :)
 
 
== Preparare il sistema ==
 
 
=== Aggiornamento pacchetti ===
 
Prima di iniziare rendiamo la nostra installazione aggiornata alle ultime versioni dei pacchetti disponibili.
 
pacman -Syu
 
=== Pacchetti aggiuntivi indispensabili ===
 
==== yaourt ====
 
yaourt è un pacchetto che, con una sintassi uguale a pacman, ci permette di installare direttamente anche da AUR. Naturalmente questa opzione và usata con cautela, ma nel proseguo della nostra guida ci sarà indispensabile.
 
Creiamo una directory "yaourt" nella home e posizioniamoci ("mkdir yaourt" e cd "yaourt" insomma) e scarichiamo i files necassari :
 
wget http://aur.archlinux.org/packages/yaourt/yaourt/PKGBUILD
 
wget http://aur.archlinux.org/packages/yaourt/yaourt/yaourt.install
 
e creiamo il pacchetto :
 
makepkg
 
finita l'installazione vi troverete il pacchetto pronto. Installiamolo con
 
pacman -A yaourt-0.8.4-1-i686.pkg.tar.gz
 
ora abbiamo il pacchetto pronto all'uso.
 
 
Per utilizzare anche gli ultimi aggiornamenti CVS/SVN/mercurial installiamo anche versionpkg
 
pacman -S versionpkg
 
 
=== Rimozione pacchetti inutili ===
 
Facciamo "dimagrire" il più possibile la nostra installazione rimuovendo tutti i pacchetti per noi inutili. Meno pacchetti significa meno problemi di sicurezza e maggior velocità negli aggiornamenti. Perchè tenere quello che non  mi serve ? Cominciamo con eliminare eventuali pacchetti orfani, pacchetti, cioè, che non sono utilizzati da nessuno e che possono quindi essere fatti scomparire.
 
 
Comuque diamo prima un occhio ai nostri pacchetti orfani :
 
pacman -Qe | less
 
Se ci sono dubbi con un
 
pacman -Qi <nome pacchetto>
 
ho delle info aggiuntiva sullo stesso. Spariti i miei dubbi eliminiamo tutti gli orfani (si fà per dire :D)
 
pacman -Qer
 
Ora potrei eliminare tutti quei pacchetti che non mi servono, una buona lista da cui partire potrebbe essere questa :
 
* hwd: Dal momento che conosco il mio hardware ...
 
* lshwd: una dipendenza di hwd
 
* pcmciautils: Non credo che il nostro server utilizzi hardware PCMCIA/Cardbus.
 
* grub / lilo: Eliminiamo quello che non viene usato.
 
* nano / vim: Tenete il vostro editor preferito. Se siete come me che non ha mai imparato ad usare vim (vergogna!), rimuovetelo e tenetevi nano. Tanto per complicare le cose io uso joe come editor ..
 
* raidtools: serve solo se utilizzate RAID. Altrimenti raus !
 
* e2fsprogs / jfsutils / reiserfsprogs / xfsprogs: tenere solo il pacchetto corrispondente al filesystem usato.
 
* wireless_tools: se non intendete fare un wireless gateway rimuovetelo pure.
 
 
Per rimuoverli completamente :
 
 
pacman -Rn pacchetto1 pacchetto2 pacchetto3
 
 
== Amministrazione remota con OpenSSH ==
 
Se vogliamo amministrare remotamente il nostro server dobbiamo installare e configurare openssh. Non vorrete mica ogni volta andare davanti alla console ! :D
 
 
=== Installazione ===
 
Installazione e avvio del servizio :
 
pacman -S openssh
 
 
/etc/rc.d/sshd start
 
Se ora tento di connettermi da un'altra macchina via rete ottengo un bel "Connection refused". Devo editare il file /etc/hosts.allow e aggiungere gli hosts abilitati. Per ora (orrore!) abilitiamo tutti:
 
nano /etc/hosts.allow
 
e aggiungiamo la riga :
 
sshd sshd1 sshd2 : ALL : allow
 
Ora '''qualunque host/Indirizzo IP''' può tentare di connettersi remotamente. Non è una buona idea, internet è pieno di "cattivi" meglio ridurre al minimo i rischi.
 
=== Configurazione ===
 
Per ridurre (magari si potesse azzerarli) i rischi di sicurezza editiamo il file di configurazione :
 
nano /etc/ssh/sshd_config
 
e inseriamo (o togliamo il commento) almeno queste voci:
 
# Cambiamo la porta di default (da 22 a 2223) e accettiamo solo connessioni dalla rete interna
 
# Se, come capita spesso, dovete remotamente amministrare il vostro server da internet mettete solo Port 2223
 
# a questo punto scegliete una password "robusta" per il vostro utente amministratore
 
ListenAddress 192.168.10.1:2223
 
# Abilitiamo solo il nostro utente a collegarsi (esempio admin da ovunque, foobar solo dall'host 192.168.10.20)
 
AllowUsers admin foobar@192.168.10.20
 
# Rifiutiamo le connessioni con l'utente root. Meglio usare admin e poi su se non ho abilitato sudo
 
# Se ho installato sudo e disabilitato root non serve
 
DenyUsers root
 
PermitRootLogin no
 
# Abilita solo il protocollo ssh2 molto più sicuro di ssh1
 
Protocol 2
 
e riavviamo il servizio con
 
/etc/rc.d/sshd restart
 
Ora non ci resta che editare il nostro rc.conf per abilitare il daemon sshd ad ogni riavvio:
 
nano /etc/rc.conf
 
e modificare la riga DAEMONS aggiungendo sshd
 
DAEMONS=(... ... ... ... ... sshd ... ... ...)
 
 
== Configurazione schede di rete ==
 
Editiamo ancora una volta il nostro /etc/rc.conf e nella sezione network config impostiamo gli indirizzi IP delle schede. Ne nostro esempio per la rete interna connessa a eth0 la classe C completa :
 
*network address : 192.168.20.0
 
*gateway : 192.168.20.1
 
*netmask : 255.255.255.0
 
*broadcast : 192.168.20.255
 
lo="lo 127.0.0.1"
 
eth0="eth0 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255"
 
eth1="dhcp"
 
Nell'esempio eth1 dispone di un indirizzo IP dinamico assegnato dal provider. Se disponiamo di un indirizzo statico inseriamolo qui nella riga "eth1".
 
 
== Sudo ==
 
=== Introduzione ===
 
Nei sistemi operativi Unix/Linux c'è un utente particolare, detto super utente e contraddistinto dall'avere un UID (User ID) uguale a 0 e nome utente '''root''', che ha totale accesso al sistema senza nessuna restrizione, è l' amministratore del sistema.
 
 
Nella maggior parte dei sistemi GNU/Linux, l'amministratore del computer non usa l'utente amministratore (per motivi di sicurezza) ma usa un utente normale per svolgere il lavoro quotidiano. Quando ha la necessità di svolgere mansioni di amministrazione apre un terminale e avvia una sessione come utente root, oppure se si trova già in un terminale come utente normale usa il comando '''su''' per diventare utente root.
 
 
Io preferisco usare un approccio diverso per svolgere mansioni amministrative, basato sull'utilizzo del comando '''sudo'''. Qui esistono diverse scuole di pensiero in merito alla sicurezza di '''sudo''' rispetto a '''su'''.
 
 
In ognuno dei due modelli, sudo e su, ci sono vantaggi e svantaggi.
 
 
Siccome sudo costringe l'esecuzione controllata di singoli comandi ha questi vantaggi:
 
*Riduce il tempo in cui gli utenti sono nel sistema come root e quindi riduce i rischi di lanciare inavvertitamente comandi dannosi per il sistema.
 
*Aumenta la possibilità di ricerca e analisi sul sistema grazie al log dei comandi.
 
 
Di contro, se qualcuno scopre la password di un utente abilitato all'utilizzo di sudo come root in effetti può ottenere accesso come root. Nel caso di utilizzo di sudo bisogna prestare una maggiore attenzione alla scelta della password utente.
 
I sostenitori del modello su, cioè account di root abilitato e utilizzo di una shell di root per compiti amministrativi, sostengono che su sia più sicuro in quanto il livello di root si ottiene dopo l'inserimento di due password, la password utente e la password di root.
 
D'altra parte, chi cerca di entrare in un sistema ha la necessità di scoprire due cose, il nome utente e la password. Con l'account di root abilitato, una delle due è già nota, serve solo scoprire la password. Con sudo si devono scoprire entrambe (nome utente e password).
 
Quando in un sistema alcuni compiti amministrativi sono assegnati a vari utenti, l'utilizzo di sudo evita di dover dare la password di root a più utenti. L'amministratore può assegnare a qualsiasi utente, temporaneamente, privilegi particolari, eliminandoli o limitandoli quando non vi è più necessità.
 
 
=== Il comando sudo ===
 
'''sudo''' (superuser do) consente di eseguire un comando come se si fosse un altro utente. Effettua una specie di sostituzione, previa autorizzazione, tra l'utente attuale (colui che esegue il comando sudo) e l'utente target (colui che esegue l'effettivo comando). Mentre con il comando '''su''' si cambia utente fino al termine della sessione del terminale, sudo assegna i privilegi dell'utente target al solo processo (e ai suoi processi figli) che viene con esso avviato.
 
 
Per eseguire dei comandi con privilegi d'amministrazione è sufficiente digitare sudo e successivamente il comando che si desidera eseguire come utente root, come nel seguente esempio:
 
 
sudo nano /etc/rc.conf
 
 
Una volta digitato il comando, il sistema chiederà la password dell'utente attuale e non la password dell'utente target. La password viene chiesta la prima volta e memorizzata per un certo lasso di tempo, quindi è possibile usare il comando sudo più volte consecutive senza dover inserire ogni volta la password.
 
 
Con sudo l'amministratore del sistema può assegnare privilegi particolari a qualsiasi utente, definire quali comandi far eseguire e quali no e avere il log (/var/log/auth.log) di tutte le operazioni effettuate su tentativi di accesso non autorizzati.
 
 
=== Creazione di un utente amministrativo ===
 
A me piacciono i sistemi "rootless", cioè privi dell' utente "root" che tanti problemi di sicurezza può causare. Quindi creiamo un utente amministrativo con una solida password. In seguito a questo utente assegneremo privilegi particolari per poter disabilitare root e amministrare il sistema.
 
Siccome sono a corto di idee chiamo questo utente "admin"
 
adduser admin
 
Lasciamo le impostazioni di default e assegniamo una bella password '''che naturalmente non si deve dimenticare''' e proseguiamo.
 
 
=== Installazione di sudo ===
 
 
Per installare sudo :
 
pacman -S sudo
 
 
=== Configurazione ===
 
 
Per abilitare il nostro utente "admin" a svolgere i compiti amministrativi utilizzando sudo devo aggiungerlo al file /etc/sudoers. Per editare questo file '''devo''' utilizzare il comando :
 
visudo
 
che apre il file utilizzando l'editor vim (che io conosco ben poco...). visudo controlla quanto scrivete su questo importantissimo file evitando possibili errori di sintassi. Se non conoscete vim vediamodi arrangiarci lo stesso :)
 
*spostatevi nella sezione "User privilege specification" ci dovrebbe essere una riga con 'root'
 
*premete il tasto '''i''' (insert) create una riga vuota e scrivete :
 
admin ALL=(ALL) SETENV: ALL
 
*premete '''ESC''' (con cui uscite dal modo insert)
 
*digitate ''':x''' per salvare e uscire
 
 
Ora l'utente "admin" dovrebbe essere abilitato al comando "sudo". Prima di proseguire provate a loggarvi sulla console con l'utente admin e poi provate, ad esempio:
 
sudo nano /etc/rc.conf
 
dopo aver digitato la password di admin provate a salvare il file, se non vi dà errore tutto è filato liscio.
 
 
=== Disabilitare l'utente root ===
 
Quando siete sicuri che admin abbia i privilegi di amministrazione attraverso sudo possiamo disabilitare l'utente root:
 
sudo passwd -l root
 
In caso di pentimento potete riabilitarlo con:
 
sudo passwd root
 
Il nostro sistema "rootless" è pronto. Da ora in avanti ci loggheremo alla console con il nostro utente admin e utilizzeremo sudo per i compiti amministrativi.
 
 
== Operazioni aggiuntive ==
 
Non dimenticate di :
 
*assegnare un nome al vostro server (sempre su /etc/rc.conf, ma serve dirlo ?)
 
*aggiungere il nome del server al file /etc/hosts accanto a localhost
 
127.0.0.1 localhost archi
 
*impostare il nome del dominio ed eventualmente il DNS nel caso non vi venga assegnato dal provider in /etc/resolv.conf
 
search mede.it
 
nameserver xxx.xxx.xxx.xxx
 
 
Bene. Terminata questa sezione non abbiamo ancora fatto niente :D.
 
Ma chi ben inizia ...
 
 
= LDAP Server =
 
== Introduzione ==
 
Il server LDAP è essenzialmente un database gerarchico che viene utilizzato per la memorizzazione dei dati degli utenti, e di tutto quanto si desideri gestire tramite una base dati condivisibile via rete tra più sistemi. Per maggiori informazioni potete leggere la definizione che ne da [http://it.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol wikipedia].
 
Perchè installiamo questo servizio ? Per la sua grande versatilità e comodità. La recente normativa sulla privacy impone (tra le altre cose) di cambiare periodicamente la password degli utenti. Oltretutto ogni utente deve poter cambiare la propria password in modo autonomo. Non vorrete mica ogni volta aggiornare manualmente prima la password nel pc, poi della condivisione poi della mail, poi ...
 
Installando un server LDAP (nel nostro caso OpenLDAP) abbiamo la possibilità di centralizzare tutto (o quasi). Cambiando la password nel pc dell'utente questa verrà salvata nell'albero LDAP e tutti i servizi saranno sincronizzati. Signori e Signore ecco il Single Signon, il santo graal di ogni amministratore di rete.
 
== Installazione ==
 
Preleviamo ed installiamo i pacchetti che ci servono :
 
sudo pacman -S openldap openldap-clients nss_ldap pam_ldap
 
pacman provvederà ad installare eventuali dipendenze.
 
 
== Configurazione ==
 
OpenLDAP è un progetto complesso, qui non fornirò nessuna informazione "supplementare" a questo servizio, come sempre date una occhiata al [http://www.openldap.org sito di riferimento] per maggiori informazioni.
 
=== Server ===
 
 
Configuriamo la parte server
 
 
==== /etc/openldap/slapd.conf ====
 
La parte server di openLDAP và fatta editando per primo il file /etc/openldap/slapd.conf
 
sudo nano /etc/openldap/slapd.conf
 
 
#
 
# See slapd.conf(5) for details on configuration options.
 
# This file should NOT be world readable.
 
#
 
include        /etc/openldap/schema/core.schema
 
include        /etc/openldap/schema/cosine.schema
 
include        /etc/openldap/schema/inetorgperson.schema
 
allow bind_v2
 
password-hash {md5}
 
pidfile  /var/run/slapd.pid
 
argsfile  /var/run/slapd.args
 
database        bdb
 
suffix          "dc=mede,dc=it"
 
rootdn          "cn=Manager,dc=mede,dc=it"
 
# Per la password usa il comando
 
# slappasswd -h {MD5} -s passwordstring
 
# e copia il risultato
 
rootpw          {MD5}En3fj26GwP2ni1HHJHe1KA==
 
directory      /var/lib/openldap/openldap-data
 
index  objectClass    eq
 
index  uid    eq
 
Attenzione al parametro rootpw: la stringa che vedete corrisponde all' hash MD5 della password che ho deciso, nel mio caso ''archimede'', che ho ottenuto così:
 
slappasswd -h {MD5} -s archimede
 
decidete la vostra password e mettetela come parametro di rootpw.
 
 
==== /etc/nsswitch.conf ====
 
 
Il file del Network Services Switch /etc/nsswitch.conf determina l'ordine delle ricerche effettuate quando viene richiesta una certa informazione, proprio come il file /ets/host.conf che determina il modo in cui effettuare le ricerche degli host. Per esempio la riga:
 
hosts: files dns ldap
 
specifica che le funzioni di ricerca degli host dovrebbero prima guardare nel file locale /etc/hosts, di seguito fare una richiesta al servizio dei nomi di dominio DNS ed infine utilizzare il server ldap. A quel punto, se nessuna corrispondenza è stata trovata, viene riportato un errore. Questo file deve essere leggibile da ogni utente!
 
Per ovviare ad un fastidioso baco di udev (o di nsswitch, non saprei) creiamo due file che poi scambieramo al boot (vedi più avanti).
 
Prima il file che non utilizza ldap :
 
sudo nano /etc/nsswitch.file
 
 
# Begin /etc/nsswitch.conf
 
passwd: files
 
group: files
 
shadow: files
 
publickey: files
 
netmasks: files
 
bootparams: files
 
automount: files
 
sendmailvars: files
 
hosts: files dns
 
networks: files
 
protocols: db files
 
services: db files
 
ethers: db files
 
rpc: db files
 
netgroup: db files
 
# End /etc/nsswitch.conf
 
e poi il file che invece lo utilizza:
 
sudo nano /etc/nsswitch.ldap
 
 
# Begin /etc/nsswitch.conf
 
passwd: files ldap
 
group: files ldap
 
shadow: files ldap
 
publickey: files
 
netmasks: files
 
bootparams: files
 
automount: files
 
sendmailvars: files
 
hosts: files dns ldap
 
networks: ldap [NOTFOUND=return] files
 
protocols: ldap [NOTFOUND=return] db files
 
services: ldap [NOTFOUND=return] db files
 
ethers: ldap [NOTFOUND=return] db files
 
rpc: ldap [NOTFOUND=return] db files
 
netgroup: ldap [NOTFOUND=return] db files
 
# End /etc/nsswitch.conf
 
 
==== /etc/rc.sysinit ====
 
Per ovviare al [http://bugs.archlinux.org/task/3369 fastidioso bug] menzionato sopra che fà bloccare il nostro server al boot durante l'avvio di udev, applichiamo un (non molto bello) workaround che per lo meno mi permette di non buttare tutto alle ortiche.
 
Prima editiamo il nostro file menu.lst di grub per montare il file system in scrittura al boot :
 
sudo nano /boot/grub/menu.lst
 
e cambiamo la riga kernel sostituendo "ro" (read only) con "rw" (read write).
 
# (0) Arch Linux
 
title  Arch Linux
 
root  (hd0,0)
 
kernel /vmlinuz26 root=/dev/sda3 rw
 
initrd /kernel26.img
 
Ora editiamo il file di inizializzazione:
 
sudo nano /etc/rc.sysinit
 
andiamo nella sezione di udev dove vedete scritto:
 
status "Starting UDev Daemon" /etc/start_udev init
 
e facciamola diventare così:
 
status "Stopping LDAP authentication" /bin/cp /etc/nsswitch.file /etc/nsswitch.conf
 
status "Starting UDev Daemon" /etc/start_udev init
 
status "Starting LDAP authentication" /bin/cp /etc/nsswitch.ldap /etc/nsswitch.conf
 
come possiamo vedere disabiliamo le modifiche a /etc/nsswitch.conf prima che parta udev e subito dopo le ripristiniamo.
 
Se qualcuno ha notizia su come si possa far meglio me lo comunichi subito !
 
 
==== PAM ====
 
PAM (Pluggable Authentication Modules) è un meccanismo per integrare più schemi di autenticazione a basso livello in un'unica API ad alto livello, permettendo a programmi che necessitino di una forma di autenticazione, di essere scritti indipendentemente dallo schema di autenticazione sottostante utilizzato.
 
Ora modifichiamo i nostri file di configurazione di PAM per fargli utilizzare anche LDAP. I seguenti file non sono "la verità assoluta" ma nel mio caso funzionano e sono una buona base di partenza. Per maggiorni informazioni rivolgetevi alla documentazione ufficiale. I nomi dei file dovrebbero già far capire a che servizio ci si riferisce. Fate sempre una copia dei vostri file originali prima di applicare le modifiche.
 
===== /etc/pam.d/login =====
 
auth            requisite      pam_securetty.so
 
auth            requisite      pam_nologin.so
 
auth            sufficient      pam_ldap.so
 
auth            required        pam_unix.so nullok
 
auth            required        pam_tally.so onerr=succeed file=/var/log/faillog
 
account        required        pam_access.so
 
account        required        pam_time.so
 
account        required        pam_unix.so
 
account        sufficient      pam_ldap.so
 
password        sufficient      pam_ldap.so
 
session        required        pam_unix.so
 
session        required        pam_env.so
 
session        required        pam_motd.so
 
session        required        pam_limits.so
 
session        optional        pam_mail.so dir=/var/spool/mail standard
 
session        sufficient      pam_ldap.so
 
session        optional        pam_lastlog.so
 
===== /etc/pam.d/shadow =====
 
auth            sufficient      pam_rootok.so
 
auth            required        pam_unix.so
 
auth            sufficient      pam_ldap.so use_first_pass
 
account        required        pam_unix.so
 
account        sufficient      pam_ldap.so
 
session        required        pam_unix.so
 
session        sufficient      pam_ldap.so
 
password        sufficient      pam_ldap.so
 
password        required        pam_permit.so
 
===== /etc/pam.d/passwd =====
 
password        sufficient      pam_ldap.so
 
password        required        pam_unix.so shadow nullok
 
===== /etc/pam.d/sshd =====
 
auth            required        pam_nologin.so
 
auth            sufficient      pam_ldap.so
 
auth            required        pam_env.so
 
auth            required        pam_unix.so use_first_pass
 
account        sufficient      pam_ldap.so
 
account        required        pam_unix.so
 
account        required        pam_time.so
 
password        required        pam_ldap.so
 
password        required        pam_unix.so
 
session        required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
 
session        required        pam_unix_session.so
 
session        sufficient      pam_ldap.so
 
session        required        pam_limits.so
 
I file /etc/pam.d/su e /etc/pam.d/sudo preferisco lasciarli come stanno.
 
==== /etc/hosts.allow ====
 
Per ultima cosa ricordiamoci di abilitare il permesso a contattare il server attraverso il protocollo LDAP, altrimenti (come per sshd) non funzionerà niente.
 
sudo nano /etc/hosts.allow
 
e aggiungiamo la riga
 
slapd : ALL : allow
 
==== Database di OpenLDAP ====
 
Diamo una configurazione di base al database di OpenLDAP copiando il suo file di esempio che a noi và più che bene:
 
sudo cp /var/lib/openldap/openldap-data/DB_CONFIG.example /var/lib/openldap/openldap-data/DB_CONFIG
 
Passiamo ora alla parte client.
 
 
=== Client ===
 
Ora dobbiamo configurare la parte client, e si fà editando quattro file di configurazione:
 
==== /etc/openldap/ldap.conf ====
 
Questo file definisce quale server contattare (URI) e quale struttura dell'albero (BASE)
 
sudo nano /etc/openldap/ldap.conf
 
impostiamo i seguenti parametri :
 
BASE    dc=mede, dc=it
 
URI    ldap://localhost
 
nel parametro URI potreste usare anche (se avete correttamente impostato il vostro file /etc/hosts) anche il nome completo :
 
URI    ldap://archi.mede.it 
 
la sostanza non cambia.
 
==== /etc/pam_ldap.conf e /etc/nss_ldap.conf ====
 
Questi file sono identici e sinceramente il motivo mi sfugge :) indagherò sul motivo, ma comunque accetto dritte. Limitiamoci a renderli identici.
 
host archi.mede.it
 
base dc=mede,dc=it
 
uri ldap://archi.mede.it/
 
ldap_version 3
 
rootbinddn cn=Manager,dc=mede,dc=it
 
scope sub
 
timelimit 5
 
bind_timelimit 5
 
nss_reconnect_tries 2
 
pam_login_attribute uid
 
pam_member_attribute gid
 
pam_password md5
 
pam_password exop
 
nss_base_passwd dc=mede,dc=it?sub
 
nss_base_shadow dc=mede,dc=it?sub
 
==== /etc/ldap.secret ====
 
Creiamo questo file e scriviamoci la password (in chiaro) per collegarci al server LDAP nel nostro caso "archimede".
 
sudo nano /etc/ldap.secret
 
 
archimede
 
 
e proteggiamolo da occhi indiscreti.
 
sudo chmod 600 /etc/ldap.secret
 
== Avvio del servizio ==
 
Bene, dovremmo aver finito (per ora) la parte ldap del nostro server e dovremmo poter avviare il servizio senza errori
 
sudo /erc/rc.d/slapd start
 
per vedere se funziona provate a lanciare il comando  :
 
ldapsearch -x
 
se non ottenete errori ma una lista (vuota) LDIF siete a cavallo e potete inserirlo nella vostra riga DAEMON in /etc/rc.conf in modo che il servizio parta ad ogni avvio:
 
DAEMONS=(... ... ... ... ... slapd ... ... ...)
 
Per ora così come è stato fatto openLDAP non server a niente :D, in quanto non ci sono utenti nel suo database, ma appena configureremo il file server con Samba ci ritorneremo su.
 
 
= DNS Dinamico e DHCP =
 
I servizi [http://it.wikipedia.org/wiki/Domain_Name_System DNS (Domain Name System)] e [http://it.wikipedia.org/wiki/DHCP DHCP (Dynamic Host Configuration Protocol)] oramai da tempo sono diventati una soluzione obbligata in una rete locale, e considerando che i nostri client di rete saranno tutti (o quasi) Windows XP che utilizzano il DNS come protocollo primario di risoluzione dei nomi sulla rete, non possiamo assolutamente tralasciarli.
 
Vi è mai capitata una rete di PC peer to peer con Windows XP e accesso ad internet condiviso in cui il ''browsing della rete'' locale era lentissimo ? A me parecchie volte, ed è uno dei motivi per cui non ci si dovrebbe cimentare in queste cose senza capire quello che si stà facendo. Il browsing della rete era lentissimo perchè XP prima interroga il DNS per conoscere il nome dell'host e solo dopo usa il suo simpatico broadcast o il file HOSTS. Bene, considerate che il DNS della rete era quello del provider e comincerete a capire perchè era così lento ... :D.
 
In GNU/Linux i pacchetti che la fanno da padrone in questo campo sono bind e dhcpd, ma data la semplice natura della nostra rete optiamo per pacchtto più semplice che integra tutto quello che ci server: DNS dinamico, DHCP e Caching. Ottenere la stessa cosa con bind e dhcpd è un po' più complicato e magari ci torneremo su.
 
Il pacchetto che utilizzeremo si chiama [http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] e offre, ma non solo, le seguenti funzionalità :
 
 
# La configurazione del DNS di macchine "dietro" al firewall è semplice e non dipende dai DNS del provider.
 
# I client che interrogano il DNS quando, ad esempio, il collegamento internet non è disponibile ricevono immediatamente il timeout, senza inutili attese.
 
# Dnsmasq ricava i nomi dal file /etc/hosts file del firewall: se il nome della macchina locale richiesta viene trovato, si viene immediatamente indirizzati alla stessa senza il bisogno di mantenere il file hosts in ogni macchina.
 
# Il servizio DHCP server integrato supporta DHCP leases statici e dinamici e IP ranges multipli. Le macchine configurate con DHCP vengono automaticamente inserite nel DNS, e i nomi possono essere specificati in ogni macchina o centralmente associando il nome al MAC address nel file di configurazione di dnsmasq.
 
# Dnsmasq esegue il [i]caching[/i] degli indirizzi internet (A records e AAAA records e PTR records), aumentando le performance della rete.
 
# Dnsmasq supporta i records di tipo MX e SRV e può essere configurato per fornire il record MX per alcune o tutte le macchine della rete locale.
 
 
== Installazione ==
 
Il pacchetto (tanto per cambiare) lo si installa così:
 
sudo pacman -S dnsmasq dnsutils
 
 
== Configurazione ==
 
Editiamo il file di configurazione :
 
sudo nano /etc/dnsmasq.conf
 
Il file è ben commentato. Impostiamo i seguenti parametri :
 
local=/mede.it/
 
interface=eth1
 
expand-hosts
 
domain=mede.it
 
dhcp-range=192.168.20.50,192.168.20.150,12h
 
dhcp-option=option:router,192.168.20.1
 
dhcp-option=44,192.168.20.1  # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
 
dhcp-option=45,192.168.20.1  # netbios datagram distribution server
 
dhcp-option=46,8            # netbios node type
 
dhcp-option=47              # empty netbios scope.
 
dhcp-options=6,192.168.20.1
 
mx-host=mede.it,50
 
mx-target=mede.it
 
localmx
 
log-queries
 
log-dhcp
 
Per vedere tutti i parametri "dhcp-options" possibili eseguite il comando :
 
dnsmasq --help dhcp
 
Per le spiegazioni sui singoli parametri fate riferimento alla guida in linea
 
man dnsmasq
 
oppure ai commenti dello stesso file di configurazione.
 
 
Ora modifichiamo il nostro file /etc/resolv.conf
 
sudo nano /etc/resolv.conf
 
che deve contenere i DNS che il server interroga, cioè se stesso e in seconda battuta il DNS del provider di cui farà la cache (ad esempio 151.99.125.1)
 
search mede.it
 
nameserver 127.0.0.1
 
nameserver 151.99.125.1
 
Se voglio utilizzare degli indirizzi statici basta inserirli nel file /etc/hosts nella solita forma (senza dominio, quello lo fornisce dnsmasq). Ad esempio per un altro server con IP fisso :
 
192.168.20.2  myserver
 
dnsmasq fornirà la risoluzione di myserver o myserver.mede.it a tutte le macchine della rete.
 
 
Ora possiamo avviare il servizio:
 
sudo /etc/rc.d/dnsmasq start
 
e modificare la riga DAEMONS aggiungendo dnsmasq
 
 
DAEMONS=(... ... ... ... ... dnsmasq ... ... ...)
 
 
Fatto ! Il mio DNS/DHCP è bello che pronto. Alle macchine della rete verrà fornito un indirizzo IP, il gateway, il DNS e il WINS tramite DHCP. Nello stesso momento verrà registrata sul DNS, così tutte le altre macchine potranno puntare in modo univoco alla stessa senza più preoccuparsi dell'indirizzo fisico TCP/IP.
 
 
= File Server Domain Controller =
 
== Premessa ==
 
 
Questa parte della guida è, secondo me, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui.
 
 
Con GNU/Linux ho diverse possibilità di scelta, ma naturalmente io considererò solo la soluzione '''Samba''' che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.
 
 
Prima di proseguire ho voluto sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.
 
 
=== Cos’e Samba ? ===
 
 
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.
 
Samba offre servizi di autenticazione e condivisione file e stampanti per client Microsoft Windows. Questi servizi possono essere offerti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.
 
 
=== Cos’e’ questa guida ? ===
 
 
Ricordo ancora che questa guida NON è una guida completa a  Samba e OpenLDAP, oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.
 
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.
 
 
=== Samba Server è meglio di Windows Server ? ===
 
 
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.
 
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.
 
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.
 
 
=== Ma allora perché usare Samba ? ===
 
 
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :
 
*Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.
 
*Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.
 
*Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.
 
*Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.
 
 
=== E’ più facile usare/amministrare Windows o Linux/Samba ? ===
 
 
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una PESSIMA IDEA.
 
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.
 
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.
 
 
=== Sostituisco i miei server Windows con Linux/Samba ? ===
 
 
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.
 
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.
 
 
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.
 
 
Bene, ora possiamo iniziare.
 
 
== Installazione ==
 
 
== Configurazione ==
 
 
== Avvio del servizio ==
 
 
= Mail Server =
 
 
== Postfix SMTP ==
 
 
== Dovecot POP3 e IMAP ==
 
 
== Antispam & Antivirus ==
 
 
=== Spamassassin ===
 
 
=== ClamAV ===
 
 
= Proxy cache + content filter =
 
 
= Fax Server =
 
 
= VPN Server =
 
 
== PPTP ==
 
 
== OpenVPN ==
 
 
= Backup =
 
 
== Mondo Rescue ==
 
 
== Amanda ==
 
 
== Bacula ==
 
 
= Firewall =
 
 
Un firewall è un sistema designato alla prevenzione di accessi non autorizzati alla o dalla tua rete privata (che può anche essere solo il sistema stesso). I firewall possono essere implementati sia con hardware dedicato, con software o con una combinazione di entrambi. Nel caso che tratteremo il nostro piccolo server tuttofare sarà il firewall della nostra azienda.
 
 
I firewall sono utiltizzati in special modo per prevenire che utenti esterni alla nostra rete possano accedere alla nostra rete locale, ma anche per l'opposto motivo: prevenire che utenti "interni" possano accedere a servizi internet non autorizzati.
 
 
Ogni messaggio che entra o esce dalla nostra rete sarà analizzato dal firewall che, in base ai criteri di sicurezza impostati, potrà abilitare (allow) o negare (deny) la richiesta.
 
 
== Shorewall ==
 
Shoreline Firewall, più comunemente conosciuto come "Shorewall", è un tool ad alto livello per configurare Netfilter. Le "regole" del firewall sono descritte usando dei file di configurazione testuale relativamente semplici da capire ed interpretare nascondendo la complessità insita in iptables. Shorewall legge questi file di configurazione e, con l'aiuto dell'utility iptables, configura Netfilter secondo le tue esigenze. Shorewall può essere utilizzato sia in un sistema dedicato che in un sistema GNU/Linux standalone. Vista la sua completezza e la sua ottima [http://www.shorewall.net/Documentation.html documentazione] è di certo una ottima soluzione.
 
 
=== Installazione ===
 
Installiamo Shorewall. E' nel repository [community] che dovrebbe essere attivato in /etc/pacman.conf
 
pacman -S shorewall
 
Pacman provvederà anche ad installare correttamente le dipendenze iptables e iproute
 
 
=== Configurazione ===
 
Il file di configurazione primario di Shorewall possiamo editarlo così :
 
sudo nano /etc/shorewall/shorewall.conf
 
il file è ben documentato, per il momento controlliamo solo che questi valori siano corretti :
 
IP_FORWARDING=On # Per le funzionalità di gateway
 
STARTUP_ENABLED=Yes # Ricordarsi di mettere "Yes" !
 
Shorewall viene fornito con dei file di esempio già quasi pronti all'uso. i file si trovano in /etc/share/shorewall/Samples. Li possiamo anche trovare così:
 
  pacman -Ql shorewall | grep Sample
 
Noi abbiamo un classico server con due interfacce (eth0 e eth1), dunque quelli che a noi interessano ti trovano in /usr/share/shorewall/Samples/two-interfaces e ce li copiamo in /etc/shorewall :
 
sudo cp /usr/share/shorewall/Samples/two-interfaces/* /etc/shorewall/
 
Ora bisogna leggere la relativa [http://www.shorewall.net/two-interface.htm guida] per configurare correttamente i file. Leggere '''con attenzione''' la guida, è molto importante!.
 
Comunque possiamo fare un semplice sunto della questione andando a vedere i file di configurazione che ci servono.
 
 
==== /etc/shorewall/interfaces ====
 
Qui devo definire gli "alias" delle mie interfacce che poi saranno usati negli altri file di configurazione. Per noi sarà così :
 
#ZONE  INTERFACE BROADCAST        OPTIONS
 
net    eth1      detect          tcpflags,nosmurfs
 
loc    eth0      detect          dhcp,tcpflags,routefilter,nosmurfs,logmartians
 
Quindi da questo momento la mia scheda "interna" la chiamerò 'loc', quella esterna 'net'. Per le opzioni si veda la guida.
 
 
==== /etc/shorewall/zones ====
 
Shorewall vede la rete dove sta girando come composta da zone. nella configurazione di esempio ''two-interface'' sono usate i seguenti nomi di zona definiti nel file /etc/shorewall/zones :
 
#ZONE  TYPE    OPTIONS                IN                      OUT
 
#                                        OPTIONS                OPTIONS
 
fw      firewall
 
net    ipv4
 
loc    ipv4
 
Notate che Shorewall assegna una zona anche al firewall stesso: quando il file /etc/shorewall/zones viene processato, il nome della zona firewall viene memorizzato nella variabile shell '''$FW''' che può essere usata per riferirsi al firewall nei file di configurazione.
 
 
Quindi abbiamo (anzi era già ok) tre zone:
 
 
net -> internet
 
fw -> il firewall ossia il server stesso
 
loc -> la rete locale
 
 
Ricordiamoci questo, perchè quando definiremo le regole (Rules) per abilitare (allow) o negare (deny) il traffico tra le interfacce faremo sempre riferimento alle zone. Ad esempio voglio collegarmi al server dalla rete locale via ssh ? Dovrò creare una regole apposita da loc -> $fw. Oppure voglio accedere a internet dal firewall stesso ? Dovrò creare una regola da $fw -> net
 
 
==== /etc/shorewall/policy ====
 
Questo file serve per le '''policy di dafault''' del nostro server. In file è autodocumentato e dovrei capire il meccanismo che usa shorewall per configurare il firewall. Ad esempio contiene :
 
#SOURCE    DEST        POLICY      LOG LEVEL    LIMIT:BURST
 
loc        net        ACCEPT
 
net        all        DROP        info
 
La zona "all" non esiste in /etc/shorewall/zones, viene usata per riferirsi a tutte le zone. Dunque di dafault il mio firewall farà passare il traffico dalla rete interna a internet (loc net ACCEPT) e bloccherà tutto quello che arriva dall'esterno. Per abilitare il server/firewall ad accedere a internet (altrimenti non funzioneranno nemmeno gli aggiornamenti!!) e i pc della rete locale ad accedere ai servizi del server devo aggiungere/modificare queste policy :
 
#SOURCE    DEST        POLICY      LOG LEVEL    LIMIT:BURST
 
$FW        net        ACCEPT
 
loc        $FW        ACCEPT
 
$FW        loc        ACCEPT
 
Ora anche il mio server può collegarsi a internet, e dalla rete locale posso collegarmi al server (ad esempio con ssh).
 
 
==== /etc/shorewall/rules ====
 
In questo file vengono definite le '''eccezioni''' alle policy di dafault definite in /etc/shorewall/policy
 
Editando il file possiamo notare che si commenta da solo. Solo un appunto. Questo file fà uso delle cosiddette macro, delle configurazioni predefinite che shorewall fornisce già pronte. Le posso vedere in /usr/share/shorewall e sono tutti quei file che iniziano con "macro.".
 
Ad esempio guardiamo macro.DNS e macro.HTTP :
 
#ACTION SOURCE  DEST    PROTO  DEST    SOURCE  ORIGINAL        RATE    USER/
 
#                              PORT    PORT(S) DEST            LIMIT  GROUP
 
PARAM  -      -      udp    53
 
PARAM  -      -      tcp    53
 
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
 
 
#ACTION SOURCE  DEST    PROTO  DEST    SOURCE  ORIGINAL        RATE    USER/
 
#                              PORT    PORT(S) DEST            LIMIT  GROUP
 
PARAM  -      -      tcp    80
 
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
 
 
vediamo che shorewall definisce per il DNS le porte UDP e TCP 53 così nel mio file di  configurazione basta che metta:
 
#ACTION        SOURCE          DEST            PROTO  DEST    SOURCE
 
DNS/ACCEPT      $FW            net
 
HTTP/ACCEPT    loc            $FW
 
Anzichè
 
#ACTION        SOURCE          DEST            PROTO  DEST    SOURCE
 
ACCEPT          $FW            net            tcp    53
 
ACCEPT          $FW            net            udp    53
 
ACCEPT          loc            $FW            tcp    80
 
Per ultimo blocchiamo il PING dall'esterno e lo abilitiamo all'interno:
 
Ping/ACCEPT    loc            $FW
 
Ping/REJECT    net            $FW
 
ACCEPT          $FW            loc            icmp
 
ACCEPT          $FW            net            icmp
 
 
Comodo e più facile da leggere :)
 
 
=== IP Masquerading (SNAT) ===
 
 
Le reti delle classi
 
*192.168.0.0
 
*172.16.0.0 - 172.31.0.0
 
*10.0.0.0
 
sono riservate alle reti locali e non vengono instradate mai su internet. Per permettere ad uno dei nostri utenti sulla rete locale di connettersi ad un host su internet deve intervenire il firewall facendo credere all'host remoto che la richiesta arrivi da lui. Quando riceve risposta dall' host remoto il firewall gira i pacchetti sul computer interno che ha generato la richiesta. Questo processo prende il nome di "Network Address Translation (NAT)".
 
 
Nei sistemi GNU/Linux, questo processo è anche conosciuto come "IP Masquerading" oppure a volte è usato anche il termine "Source Network Address Translation (SNAT)". Shorewall segue la seguente convenzione con Netfilter:
 
*Masquerade descrive il caso in cui il firewall trova automaticamente l'indirizzo dell'interfaccia esterna
 
*SNAT il caso in cui viene specificato in modo esplicito l'indirizzo
 
 
In Shorewall, entrambi Masquerading e SNAT sono configurati con il file /etc/shorewall/masq. Normalmente si usa Masquerading se l'indirizzo dell'interfaccia esterna eth1 ha un indirizzo IP dinamico e SNAT se l'indirizzo IP è statico.
 
 
Per noi il file /etc/shorewall/masq dovrebbe essere così :
 
 
#INTERFACE              SOURCE          ADDRESS
 
eth1                    eth0           
 
 
Se l'indirizzo esterno è statico lo possiamo inserire nella terza colonna del file /etc/shorewall/masq. Probabilmente funzionerà lo stesso anche omettendo questa configurazione ma il processo SNAT (specificando l'indirizzo) dovrebbe essere più efficente.
 
 
Naturalmente le possibilità sono molte, come ad esempio permettere sono a determinati host di navigare su internet, oppure specificare particolari porte. Per i dettagli vi rimando alla guida di shorewall.
 
 
=== Port Forwarding (DNAT) ===
 
Spesso capita di dover "girare" le richieste sulle porte del firewall ad una macchina interna della nostra rete. Supponiamo ad esempio di avere un web server sulla macchina interna con IP 192.168.20.10 che vogliamo far raggiungere dall'esterno quando "puntano" il browser sul mio server/firewall sulla posta 8080. Basta mettere in /etc/shorewall/rules :
 
 
DNAT        net        loc:192.168.20.10:80        tcp        8080
 
 
Cosa c'e' di più facile ? :D
 
 
=== Avvio del servizio ===
 
Prima siicuriamoci che il parametro del file /etc/shorewall/shorewall.conf
 
STARTUP_ENABLED=Yes
 
sia correttamente impostato, poi posso avviare il firewall in due modi. Con il classico
 
sudo /etc/rc.d/shorewall start
 
Oppure con la sua utility
 
sudo shorewall start
 
La sua utility ha anche funzionalità aggiuntive come ad esempio
 
sudo shorewall status
 
che mi mostra lo stato del firewall. Diamo un occhio alle altre opzioni (reset, save, show ...) che vedo con
 
sudo shorewall --help
 
che sono utilissime in fase di definizione delle regole.
 
Solo a configurazione ultimata lo posso far partire nel modo tradizionale.
 
Se non ricevo messaggi di errore è giunta l'ora di mettere anche shorewall nella riga "DAEMONS" del file /etc/rc.conf
 
DAEMONS=(... ... ... ... ... shorewall ... ... ...)
 
così ad ogni riavvio del server il mio firewall sarà up and running.
 
 
=== Problemi ? ===
 
A volte si pastrocchia un po' con shorewall, ma spesso basta dare un occhio al file di LOG :
 
sudo tail -f /var/log/messages.log | grep Shorewall
 
mentre si tenta "qualcosa". Vedrete subito i motivi del blocco.
 

Revision as of 09:35, 29 January 2008

Introduzione

Benvenuti nella guida ArchLinux Small Business Server (SBS per gli amici). Questa guida contiene informazioni su come installare e configurare diversi servizi su ArchLinux allo scopo di realizzare un piccolo server tuttofare nella vostra azienda. È una guida passo-passo, orientata verso i processi per configurare e personalizzare il sistema. Le varie sezioni non vanno necessariamente eseguite in ordine ma secondo esigenza (comunque all'inizio di ogni articolo sono indicati i requisiti). La guida presuppone che :

  • Abbiate già eseguito una installazione base di ArchLinux sul vostro server, magari seguendo la guida ufficiale.
  • La rete sia configurata e funzionante. Per realizzare il firewall di cui avete sicuramente bisogno dovete installare almeno due adattatori di rete, uno collegato alla vostra rete interna e uno al router ADSL. In caso di problemi consultate la relativa guida. Mi raccomando, per il vostro server utilizzate indirizzi IP statici.
  • Una connessione ad internet funzionante
  • Una conoscenza almeno di base su ArchLinux e sugli argomenti trattati

Preciso che questa NON è una guida completa ai servizi utilizzati, per approfondirne la conoscenza vi rimando alle guide ufficiali dei pacchetti stessi. Lo scopo principale è dare una traccia principale da seguire, le possibili combinazioni sono talmente tante che è praticamente impossibile trattare ogni singola esigenza.

Nella filosofia Arch, vi avviso che non verrà utilizzata nessuna GUI per configurare il sistema, utilizzerete solo una shell bash. Se questo non fà per voi fermatevi immediatamente qui. Usando una shell per configurare il tutto avrete il grande vantaggio di poter amministrare e risolvere gran parte dei problemi del vostro server da remoto.

Per ultimo un consiglio, anche se sembrerà una cosa ovvia io ve lo dico lo stesso: non mettete le guide in pratica a pappagallo, cercate di capire almeno a grandi linee quello che state facendo. Se stiamo installando il servizio DNS o LDAP almeno documentatevi prima su cosa diavolo siano. Non installate un server in una azienda non capendo gli argomenti trattati, altrimenti (come spesso succede) alla prima difficoltà non saprete che pesci pigliare e meledicerete il momento in cui avete deciso di installare un server con ArchLinux (o Linux in generale).

Gli articoli provengono dal Blog di Steno, pubblicati con licenza CC Attribution-ShareAlike.

Sentitevi liberi di contribuire, magari iniziando da una traduzione in inglese per rendere più visibile la guida.

Indice della guida

Questa è la lista degli articoli pubblicati, buona lettura, e sentitevi liberi di correggere e contribuire alla guida.

  1. Operazioni Preliminari
  2. LDAP Server
  3. DNS dinamico e DHCP
  4. Firewall
  5. File server domain controller
  6. Mail Server

Iniziamo la configurazione del nostro ArchLinux SBS con delle operazioni preliminari per rendere la nostra box pronta al via.