Small Business Server (Italiano)

From ArchWiki
Revision as of 08:39, 2 November 2007 by Steno (Talk | contribs) (Mail Server)

Jump to: navigation, search

Contents

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

Buona lettura, e sentitevi liberi di correggere e contribuire alla guida.

Operazioni Preliminari

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 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 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 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 DNS (Domain Name System) e 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 dnsmasq e offre, ma non solo, le seguenti funzionalità :

  1. La configurazione del DNS di macchine "dietro" al firewall è semplice e non dipende dai DNS del provider.
  2. I client che interrogano il DNS quando, ad esempio, il collegamento internet non è disponibile ricevono immediatamente il timeout, senza inutili attese.
  3. 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.
  4. 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.
  5. Dnsmasq esegue il [i]caching[/i] degli indirizzi internet (A records e AAAA records e PTR records), aumentando le performance della rete.
  6. 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 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 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 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.