La Voice facile avec Trixbox !

Trixbox en quelques mots :

Trixbox (connu auparavant sous le nom d’ Asterisk@Home) est un logiciel libre d’ autocommutateur téléphonique privé (PBX) ou IPBX basé sur le logiciel libre Asterisk.

Trixbox a été offert initialement sous le nom d’Asterisk@Home. En octobre 2006, le produit a été renommé Trixbox après que Digium, l’éditeur du produit Asterisk, eut demandé que le mot « asterisk » ne soit pas utilisé dans le nom du produit.
Le changement de nom était d’autant plus justifié que le produit avait à cette époque beaucoup plus de fonctionnalités qu »Astérisk.

Trixbox CE est le logiciel qui a été téléchargé le plus souvent dans la liste des projets réalisés à partir du logiciel libre Asterisk selon Sourceforge.net.

Trixbox CE est 100 % libre et sous licence GPLv2. Les membres fondateurs du projet Trixbox CE sont Kerry Garrison et Andrew Gillis.

Il existe également une version PRO de Trixbox, déclinée sous plusieurs versions  :

  • Standard Edition (SE) ;
  • Enterprise Edition (EE) ;
  • Call Center Edition (CCE) ;
  • Unified Agent Edition (UAE).

Le CD Trixbox inclut le noyau CentOS pour le système d’exploitation, Asterisk pour la partie IPBX et interface web, et Flash Operator Panel (FOP) pour la partie graphique de l’interface web.

Une fois le produit installé, l’administration de Trixbox est entièrement réalisée depuis une interface web. Seul un accès SSH peut être parfois utile lors de l’ajout de nouveaux modules fonctionnels, comme par exemple les modules de gestion des téléphones SIP de Aastra Technologies.

Source : wikipedia.org

Enoncé de l’exercice:

Vous disposez de la plage d’adresses IP 192.168.X.0 / 24X est un chiffre choisit aléatoirement (disons ici 1).

Configuration basique 

  1. Vous mettez en place deux IP-PBX en machine virtuelle « Trixbox » :
  2. Sur la trixbox1, vous créez deux extensions 101 et 102
  3. Sur la trixbox2, vous créez trois extensions 201 202 et 203
  4. 201 et 202 savent s’appeler et communiquer ensemble
  5. 101 et 102 savent s’appeler et communiquer ensemble

Coova Chilli

Coova Chilli, à quoi ça sert ?

Coova Chilli n’est rien d‟autre qu’ un portail captif, open-source sous la licence GPL. Un portail captif consiste à forcer les clients http d‟un réseau à afficher une page web dans un but d‟authentification avant de pouvoir avoir accès à internet.
Cela est obtenu en interceptant tous les paquets quelles que soient leurs destinations jusqu’à ce que l’utilisateur ouvre son navigateur web et essaie d’accéder à Internet. Le navigateur est alors redirigé vers une page web qui peut demander une authentification et/ou un paiement ou tout simplement demander d’accepter les conditions d’utilisation du réseau. Cette technique est souvent employée pour les accès Wi-Fi et peut aussi être utilisée pour l’accès à des réseaux filaires (ex. hôtels, campus etc.).

Ce dont nous avons besoin :

Afin de faire fonctionner notre Coova-chilli, toute une infrastructure autour de lui doit être mise au point.
Nous aurons besoin d‟une Debian (ou une autre distribution), d’un service Web (apache2), de freeradius, de MySQL, d‟un service DNS, de phpMyAdmin, de daloradius et bien évidemment de Coova-chilli.

Note : Cette manipulation ayant été testée il y a quelques temps, quelques changements peuvent apparaître. 

Le début des hostilités :

Nous allons commencer par configurer les interfaces réseaux.

Dans /etc/network/interfaces, nous allons déclarer 2 interfaces en statiques, eth4 sera l‟interface pour le WAN et eth5 pour le LAN (afin d‟utiliser coova-chilli dans les meilleures conditions) :

# interface vers WAN 
allow-hotplug eth4 
iface eth4 inet static 
   address 192.168.0.5 
   netmask 255.255.255.0 
   gateway 192.168.0.1
# interface vers LAN 
allow-hotplug eth5 
iface eth5 inet static 
   address 10.0.2.1
   netmask 255.255.255.0

Nous allons maintenant procéder au téléchargement des différents paquets qui nous seront utiles :

# apt-get install ssh bind9 apache2 mysql-server phpmyadmin php5 perl build-essential ssl-cert freeradius freeradius-mysql

Un mot de passe pour MySQL nous sera demandé. Dans cette démonstration, le mot de passe « mysqladminsecret » a été choisi.

  • Freeradius :

Dans cette étape nous allons travailler avec le paquet freeradius (qui sera notre serveur d‟authentification) et le paquet freeradius-mysql (qui va travailler avec MySQL pour comptabiliser et authentifier les utilisateurs).

Créons tout d‟abord une base de données dans MySQL, qu‟on appellera « radius » :

# mysql –u root –p
 Enter password : mysqladminsecret
 mysql > CREATE DATABASE radius;
 mysql > quit

Après ça, on va devoir rajouter les tables afin que freeradius puisse fonctionner avec la base de données « radius » :

# mysql –u root –p radius </etc/freeradius/sql/mysql/schema.sql
Enter password : mysqladminsecret
# mysql –u root –p radius < /etc/freeradius/sql/mysql/nas.sql
Enter password : mysqladminsecret

Rajoutons un utilisateur et donnons-lui les privilèges sur la base de données “radius”. Appelons cet utilisateur : « radius » :

# mysql –u root –p
Enter password : mysqladminsecret
mysql > GRANT ALL PRIVILEGES ON radius.* TO 'radius'@'localhost' IDENTIFIED BY'mysqlsecret';
mysql > FLUSH PRIVILEGES;
mysql > quit

Il va falloir configurer 5 fichiers : clients.conf, radiusd.conf, sql.conf, user et default.
Les 4 premiers se trouvent tous dans /etc/freeradius, le dernier dans /etc/freeradius/sites-available/default.

Ces fichiers vont servir à préciser certaines informations à freeradius, afin que celui-ci puisse se connecter à la base de données.

On se rend dans le fichier sql.conf :

# nano /etc/freeradius/sql.conf

On modifie la ligne « password » : puisqu’on a choisi mysqlsecret comme mot de passe pour radius.

On laisse les autres lignes comme elles sont :

database = « mysql »
 Définit le type de base de données (mysql, mssql, oracle, postgresql)
server = « localhost »
 Définit l‟ip du serveur sql (ici localhost puisque nous sommes sur le même serveur)
login = « radius »
 Définit le login permettant de se connecter au serveur sql
Et on décommente la ligne readclient = yes.

Rendons nous dans le fichier clients.conf :

Ce fichier va permettre d‟autoriser certaines personnes à se connecter.

# nano /etc/freeradius/clients.conf

On trouve la ligne contenant le mot « secret » et on la modifie comme suit :

secret = radiussecret

Le mot de passe par défaut est « testing123 » pour des raisons de sécurité, nous l’avons changé.

Il est possible que le serveur radius ne soit pas sur la même machine que les autres services, dans ce cas on pourra autoriser une ip / un hôte / un range d’ip. Pour configurer cela, il faut se rendre a la fin du fichier de configuration et décommenter les paramètres nécessaires.

On se rend dans le fichier default :

# nano /etc/freeradius/sites-available/default

Dans ce fichier, on retrouve de nombreux paragraphes. Ceux qui nous intéressent sont les suivants : « authorize », « accounting » et « session ».
Il va falloir décommenter dans ces paragraphes les lignes « sql » (afin que freeradius sache qu‟on va utiliser sql).

On va maintenant modifier le fichier radiusd.conf :

# nano /etc/freeradius/radiusd.conf

On y décommente la ligne 680 : $INCLUDE sql.conf
Seule cette ligne est à décommenter pour indiquer à freeradius qu‟il doit prendre en compte le fichier sql.conf afin de pouvoir se connecter à une base de données sql.

Cinquième et dernier fichier à modifier (users):

Dans ce fichier de configuration on entre des utilisateurs autorisés.

A Ligne 90, il existe déjà un exemple de configuration pour un utilisateur (John Doe).

Il suffit donc de recopier les 2 lignes d‟exemple en modifiant le nom d‟utilisateur et le mot de passe.

Dans notre cas, ce n’est utile que dans le cadre du test de freeradius avec la commande « radtest« .
Lorsque ces fichiers ont été modifiés, on peut tester notre serveur freeradius afin de vérifier qu‟il tourne correctement :

# echo “INSERT INTO radcheck(UserName, Attribute, Value) VALUES (‟usercheck‟, ‟Password‟, ‟passcheck‟); “ | mysql –u radius –p radius
Enter password : mysqlsecret

On redémarre le service et on peut utliser la commande radtest:

# /etc/init.d/freeradius restart
# radtest usercheck passcheck 127.0.0.1 0 radiussecret

On doit normalement obtenir quelque chose comme ça :

Nous avons bien un « access-accept » en réponse.

  • Coova-chilli

Voici l‟étape qui nous intéresse le plus. Nous tenterons donc d’être le plus précis possible.

Retournons dans le répertoire root :

# cd /root
# wget http://ap.coova.org/chilli/coova-chilli_1.2.2_i386.deb

On va se servir de dpkg pour installer coova-chilli :

# dpkg –i coova-chilli_1.2.2_i386.deb

Pour pouvoir configurer le serveur apache (dans l’étape suivante), on va devoir mettre en place certains fichiers :

# cp /etc/chilli/defaults /etc/chilli/config
# mkdir /var/www/hotspot
# cd /var/www/hotspot
# cp /etc/chilli/www/* /var/www/hotspot
# mkdir /var/www/hotspot/images
# cp /var/www/hotspot/coova.jpg /var/www/hotspot/images/
# mkdir /var/www/hotspot/uam
# cd /var/www/hotspot/uam
# wget http://ap.coova.org/uam/
# wget http://ap.coova.org/js/chilli.js

Occupons-nous maintenant du fichier chilli.js. A l‟aide de la commande sed, nous allons remplacer facilement une chaine de caractère dans ce fichier.

# sed –i 's/ap.coova.org\/js\/chilli.js/10.0.2.1\/uam\/chilli.js/g' /var/www/hotspot/uam/index.html
# sed –i 's/192.168.182.1/10.0.2.1/g' /etc/chilli/www/ChilliLibrary.js
# sed –i 's/192.168.182.1/10.0.2.1/g' /var/www/hotspot/ChilliLibrary.js

La première commande va permettre de modifier index.html en remplaçant ap.coova.org/js/chilli.js par 10.0.2.1/uam/chilli.js.
Les deux autres commandes vont permettre de remplacer 192.168.182.1 par la bonne adresse IP (10.0.2.1) dans les différents fichiers.
Le s/ signifie substitution c’est-à-dire que la commande va changer toutes les occurrences de l‟expression régulière dans une nouvelle valeur.
Le /g signifie global, ce qui indique que toutes les occurrences dans chaque ligne doivent être remplacées.

On se rend ensuite dans le fichier chilli :

# nano /etc/default/chilli

Et on va mettre un 1 (à la place du 0) à la ligne « START_CHILLI », ce qui va permettre à chilli de démarrer sans reboot.

Nous pouvons démarrer coova-chilli :

# /etc/init.d/chilli start

Une fois le service lancé, on constate que l‟interface tun0-00 est apparue :

Nous pouvons maintenant nous occuper du fichier le plus important :

# nano /etc/chilli/config

Explication de ce fichier:

HS_WANIF=eth4 : Interface menant à Internet
HS_LANIF=eth5 : Interface reliée aux clients
HS_NETWORK=10.0.2.0 : L’adresse réseau du Hotspot
HS_NETMASK=255.255.255.0 : Le masque réseau du Hotspot
HS_UAMLISTEN=10.0.2.1 : L’adresse IP du Hotspot
HS_UAMPORT=3990 : C’est le port TCP qui est lié à l‟authentification des clients, si un client non   authentifié tente de se rendre sur internet, il sera redirigé sur ce port-là, à l‟adresse IP spécifiée plus haut.
HS_UAMUIPORT=4990 : Port permettant de contacter le portail captif
HS_DNS1=10.0.2.1 : L’adresse IP du DNS
HS_DNS2=10.0.2.1 : Puisqu’on utilise un seul DNS, on met le même ici
HS_NASID=nas01 : L’identifiant du serveur d‟accès réseau, par défaut nas0
HS_RADIUS=127.0.0.1 : On marque ici l‟adresse IP du serveur d‟authentification
HS_RADIUS2=127.0.0.1 : On réécrit la même chose
HS_UAMALLOW=10.0.2.0/24 : On reprend ici l’adresse réseau et le masque
HS_RADSECRET=radiussecret : On précise le mot de passe qu’on avait choisi précédemment
HS_UAMSECRET=uamsecret : Secret partagé en le serveur UAM et Chilli
HS_UAMALIASNAME=chilli : Alias pour les services UAM
HS_UAMSERVER=$HS_UAMLISTEN : URL du serveur WEB à utiliser pour authentifier les clients (ici 10.0.2.1)
HS_UAMFORMAT=http://\$HS_UAMLISTEN:\$HS_UAMUIPORT/www/login.chi : Définit l‟url du portail captif
HS_UAMHOMEPAGE=http://\$HS_UAMLISTEN:\$HS_UAMPORT/www/coova.html : L’url de la page d‟accueil pour les utilisateurs non authentifiés
HS_UAMSERVICE=https://10.0.2.1/cgi-bin/hotspotlogin.cgi : Permet d’aller rechercher chez un utilisateur ses informations de connexion et donc lui donner la possibilité de passer d’un AP à un autre sans avoir besoin d’avoir à se connecter au portail captif

HS_TCP_PORTS= »81″ : On ouvre un port, par exemple le 81 si on veut que les utilisateurs puissent s‟inscrire eux-mêmes
HS_LOC_NAME= »My Hotspot » : Permet de mettre un petit nom au Coova-Chilli

On rajoute ensuite le module haserl qui permettra d’exécuter des scripts dans une page web :

 # cd /usr/src
 # wget

http://downloads.sourceforge.net/project/haserl/haserldevel/

 0.9.26/haserl-0.9.26.tar.gz?use_mirror=ovh
 # tar xvf haserl-0.9.26.tar.gz
 # cd haserl-0.9.26
 # ./configure
 # make
 # make install

On modifie un fichier dans Coova-Chilli pour qu‟il sache où se trouve haserl :

# nano /etc/chilli/wwwsh

On remplace cette ligne : haserl=$(which haserl 2>/dev/null)
Par cette ligne-ci : haserl=/usr/local/bin/haserl (emplacement où se trouve haserl)

Et on va également modifier les règles de firewall (qui seront appliquées lorsqu‟un user se connectera avec succès à notre hotspot) :

# nano /etc/chilli/up.sh

On rajoute tout au bout de ce fichier :

[ -e “/var/run/chilli.iptables” ] && sh /var/run/chilli.iptables
iptables –A POSTROUTING –t nat –o $HS_WANIF –j MASQUERADE (cette commande permet d‟activer le NAT)
  • Apache

On place avant tout le fichier hotspotlogin.cgi au bon endroit.

# mkdir –p /var/www/hotspot/cgi-bin
# zcat –c /usr/share/doc/coova-chilli/hotspotlogin.cgi.gz | tee /var/www/hotspot/cgi-bin/hotspotlogin.cgi
# chmod a+x /var/www/hotspot/cgi-bin/hotspotlogin.cgi

On l‟édite :

# nano /var/www/hotspot/cgi-bin/hotspotlogin.cgi

On supprime/commente cette ligne :

$uamsecret=‟"ht2eb8ej6s4et3rg1ulp"

On installe le paquet suivant :

# apt-get install libapache2-mod-auth-mysql

On crée le dossier qui contiendra le certificat :

# mkdir /etc/apache2/ssl

(Il est préférable de vérifier le nom de la machine avant de créer le certificat : # hostname –f, ici debian)

On crée ensuite le certificat :

# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

Lorsqu’il est demandé le nom de la machine, on vient mettre ce qu‟on a obtenu via hostname.

On ajoute le module ssl à apache et on le restart :

# a2enmod ssl
# /etc/init.d/apache2 restart

On peut maintenant créer un nouveau site nommé hotspot :

# nano /etc/apache2/sites-available/hotspot

On le remplit par :

NameVirtualHost 10.0.2.1:443

<VirtualHost 10.0.2.1:443>
ServerAdmin webmaster@domain.org
DocumentRoot "/var/www/hotspot"
ServerName "10.0.2.1"

<Directory "/var/www/hotspot/">
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

ScriptAlias /cgi-bin/ /var/www/hotspot/cgi-bin/

<Directory "/var/www/hotspot/cgi-bin/">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>

ErrorLog /var/log/apache2/hotspot-error.log
LogLevel warn
CustomLog /var/log/apache2/hotspot-access.log combined
ServerSignature On
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

On active ensuite ce nouveau site :

# a2ensite hotspot
# /etc/init.d/apache2 reload

On modifie ensuite le fichier ports.conf :

# nano /etc/apache2/ports.conf

Il ne doit contenir que ceci :

Listen *:443
Listen *:80
Listen *:81

Ensuite on ouvre ce fichier :

# nano /etc/apache2/sites-available/default

Et on y rajoute en première ligne :

NameVirtualHost *:80

On se rend sur le fichier apache2.conf :

# nano /etc/apache2/apache2.conf

Et on rajoute à la fin de ce fichier :

ServerName 10.0.2.1

On ouvre le fichier hosts :

# nano /etc/hosts

Et on rajoute à la suite des 2 premières lignes :

10.0.2.1 debian debian

(si la machine ne s’appelait pas debian, il suffirait de mettre le nom de la machine éventuellement suivi du domaine dans lequel elle est)

On redémarre le serveur apache et on peut éventuellement redémarrer la machine :

# /etc/init.d/apache2 restart
# reboot

Notre HotSpot est prêt à fonctionner. Nous pouvons déjà vérifier que coova-chilli fonctionne sans erreur en nous rendant dans le navigateur, on tape http://www.google.be. Nous devrions être redirigés automatiquement sur le page de coova.

Coova

  • Daloradius

  # cd /usr/src
  # wget http://downloads.sourceforge.net/project/daloradius/daloradius/dalor  adius-0.9-8.tar.gz?use_mirror=ovh
  # tar xvf daloradius-0.9-8.tar.gz
  # cp daloradius-0.9-8/ /var/www –R
  # chmod 644 /var/www/daloradius-0.9-8/library/daloradius.conf.php
  # mysql –u root –p radius </var/www/daloradius-0.9-
  8/contrib/db/mysql-daloradius.sql
  Enter password : mysqladminsecret

On configure daloradius :

 # nano /var/www/daloradius-0.9- 8/library/daloradius.conf.php

On modifie ce fichier (user=radius, pass=mysqlsecret,
database=radius), il doit alors ressembler à ça :

Daloradius Configuration de la base de données :

$configValues[‘CONFIG_DB_ENGINE’] = ‘mysql';
 Définit le type de base de données (mysql, mssql, oracle, postgresql)
$configValues[‘CONFIG_DB_HOST’] = ‘127.0.0.1’;
 Définit l‟ip du serveur sql (ici 127.0.0.1 puisque nous sommes sur le même serveur)
$configValues[‘CONFIG_DB_USER’] = ‘radius';
 Définit le login permettant de se connecter au serveur sql
$configValues[‘CONFIG_DB_PASS’] = ‘mysqlsecret';
 Définit le mot de passe permettant de se connecter au serveur sql
$configValues[‘CONFIG_DB_NAME’] = ‘radius';
 Définit le nom de la base de données
$configValues[‘CONFIG_PATH_DALO_VARIABLE_DATA’] = ‘/var/www/daloradius/var';
 Définit le chemin vers le dossier „var‟ de daloradius

$configValues[‘CONFIG_MAINT_TEST_USER_RADIUSSERVER’] = ‘127.0.0.1’;
 Définit l‟ip du serveur Radius (ici 127.0.01 puisque nous sommes sur le même serveur)
$configValues[‘CONFIG_MAINT_TEST_USER_RADIUSSECRET’] = ‘radiussecret';
 Définit le secret partagé par tous les clients radius

On rajoute également le paquet suivant :

# apt-get install php-pear  

# pear install DB

On configure ensuite apache afin d‟accéder à daloradius de manière conviviale : # nano /etc/apache2/httpd.conf

On y rajoute :

Alias /daloradius ‟‟/var/www/daloradius-0.9-8/‟‟
<Directory /var/www/daloradius-0.9-8/>
Options None
Order deny,allow
deny from all
allow from all
</Directory>

Il faut également restart apache2.

On peut maintenant accéder à daloradius via le lien : http://10.0.2.1/daloradius (le nom d‟utilisateur de base pour daloradius est « administrator » et le mot de passe est « radius »).

DaloDola 3

Et voilà qui est fait…

FTPS, Active Directory et …

Partie 0 : Brève explication

Avant d’entrer dans le vif du sujet, nous devrons tout d’abord intégrer notre machine (ici Debian 6.0.3) dans l’Active Directory afin que les utilisateurs de celui-ci puissent également accéder au FTPS qui sera mis en place.

Le domaine sera : test.local

Le contrôleur de domaine : ldap.test.local

Le contrôleur intègre un serveur DNS.

Partie 1 : Intégration AD

Nous partirons du principe que notre Active directory est déjà présent et qu’il tourne parfaitement sur notre machine Windows 2008 R2.

Les paquets à installer sont les suivants : libkrb53 krb5-config krb5-user samba winbind ntpdate ntp

Etant donné que nous utiliserons le protocole Kerberos, nous devons nous assurer d’avoir une parfaite synchronisation des horloges systèmes.

# ntpdate ldap.test.local

Passons maintenant au fichier /etc/krb5.conf (il ne faut rien mettre d’autre dans ce fichier):

[logging]
default = FILE:/var/log/krb5.log

[libdefaults]
ticket_lifetime = 24000
clock_skew = 300
dns_lookup_realm = false
dns_lookup_kdc = true

[realms]
TEST.LOCAL = {
kdc = ldap.test.local:88
admin_server = ldap.test.local
default_domain = TEST.LOCAL
}

[domain_realm]
.test.local = TEST.LOCAL
test.local = TEST.LOCAL

Nous allons ouvrir un ticket kerberos avec ce compte en tapant la commande :

# kinit Administrator@TEST.LOCAL

La console affiche ce message : Password for Administrator@TEST.LOCAL:
On entre alors le password et si la console nous rend la main sans message d’erreur on peut s’assurer du succès de l’ouverture du ticket en tapant:

 # klist

La console nous renvoie alors : Ticket cache: FILE:/tmp/krb5cc_0Default principal: Administrator@TEST.LOCAL avec la date de création et d’expiration.

Il faut maintenant se rendre dans le fichier de configuration de Samba.

Samba va permettre de faire communiquer une machine Windows et avec une machine Unix, Winbind permet de récupérer les utilisateurs et les groupes du  domaine Windows.

# nano /etc/samba/smb.conf

On y copie EXACTEMENT les lignes suivantes :

  [global]
  security = ads
  realm = TEST.LOCAL
  password server = 172.16.10.1
  # note that workgroup is the \'short\' domain name
  workgroup = test
  winbind separator = /
  idmap uid = 10000-20000
  idmap gid = 10000-20000
  winbind enum users = yes
  winbind enum groups = yes
  template homedir = /home/%D/%U
  template shell = /bin/bash
  client use spnego = yes
  client ntlmv2 auth = yes
  encrypt passwords = yes
  winbind use default domain = yes
  restrict anonymous = 2
  # to avoid the workstation from
  # trying to become a master browser
  # on your windows network add the
  # following lines
  domain master = no
  local master = no
  preferred master = no
  os level = 0

Maintenant que nous avons modifié le fichier, un redémarrage des différents services est nécessaire :

  # /etc/init.d/samba stop
  # /etc/init.d/winbind stop
  # /etc/init.d/samba start
  # /etc/init.d/winbind start

Il faut maintenant que nous configurions le système d’authentification.

    • Rendons nous dans le fichier /etc/nsswitch.conf et ajoutons les lignes suivantes :
  # nano /etc/nsswitch.conf
  # Example configuration of GNU Name Service Switch functionality.
  # If you have the `glibc-doc-reference' and `info' packages installed, try:
  # `info libc "Name Service Switch"' for information about this file.
  passwd:         compat winbind
  group:          compat winbind
  shadow:         compat
  hosts:          files dns
  networks:       files
  protocols:      db files
  services:       db files
  ethers:         db files
  rpc:            db files
  netgroup:       nis
  bootparams:     files
  automount:      files
  aliases:        mount
    • Dans le fichier /etc/pam.d/common-account, nous devons rajouter la ligne suivante :
account sufficient      pam_winbind.so

C’est-à-dire qu’au final, le fichier doit contenir ces 2 lignes :

account sufficient      pam_winbind.so
account sufficient      pam_unix.so
    • Modifions maintenant le fichier /etc/pam.d/common-auth :
auth sufficient pam_winbind.so krb5_auth krb5_ccache_type=FILE
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required pam_deny.so
    • Dernier fichier à modifier, /etc/pam.d/common-session :
session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel

Nous allons à présent modifier les fichiers /etc/hostname, /etc/hosts et /etc/resolv.conf. Commençons par le premier :

     # nano /etc/hostname

On ajoute dans ce fichier le nom de la machine suivi du suffixe :

ftps.test.local

Dans le fichier /etc/hosts, on rassemble l’ensemble des noms pouvant être utilisés pour identifier la machine :

127.0.0.1 localhost
127.0.0.1 ftps.test.local ftps
172.16.10.1 ldap.test.local ldap
172.16.10.42 ftps.test.local ftps

Dans /etc/resolv.conf :

nameserver 172.16.10.1

Nous allons à présent intégrer notre Debian au domaine, pour cela on utilise la commande suivante :

# net ads join -S LDAP.TEST.LOCAL -U Administrator

Le mot de passe nous est demandé, on le rentre. On obtient ceci en réponse : 

Using short domain name – TEST
Joined 'ftps to realm 'TEST.LOCAL’

On peut tester que nous avons bien rejoint le domaine :

# wbinfo –u (liste des utilisateurs du domaine)
# wbinfo –g (liste des groupes du domaine)
# getent passwd (renvoi l’ensemble des utilisateurs utilisables)
# getent group (renvoi l’ensemble des groupes utilisables)

Partie 2 : FTPS

Pour une question d’affinité, j’ai décidé de travailer avec vsftpd.

vsFTPd, forme raccourcie de Very Secure FTP Daemon, est un serveur FTP libre simple et sécurisé.

Il a été développé dans l’optique de la meilleure sécurité possible afin de combler les failles des serveurs FTP classiques. Il bénéficie de toutes les options habituelles des serveurs FTP classiques (proFTPd, Pure-FTPd,…) et prend en charge l’IPv6 ainsi que SSL.

Afin d’installer vsftpd, nous allons utiliser le célèbre apt-get install :

# apt-get install vsftpd

On se rend maintenant dans le fichier de configuration :

# nano /etc/vsftpd.conf

On supprime l’entièreté du fichier et on copie :

#### GENERAL CONFIGURATION ####
listen=YES
connect_from_port_20=YES
pam_service_name=vsftpd
#ftpd_banner=Bienvenue sur le serveur ftp.
dirmessage_enable=YES
xferlog_enable=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
#deny_email_enable=YES
#banned_email_file=/etc/vsftpd.banned_emails
use_localtime=YES
#dirlist_enable=NO
idle_session_timeout=600
data_connection_timeout=12

#### RIGHTS CONFIGURATION #####
local_enable=YES
write_enable=YES
anonymous_enable=NO
#anon_upload_enable=YES
#anon_mkdir_write_enable=YES
chroot_local_user=YES
chroot_list_file=/etc/vsftpd/user_list
local_umask=077
#chown_uploads=YES
#chown_username=whoever
secure_chroot_dir=/var/run/vsftpd/empty
#async_abor_enable=YES
#ascii_upload_enable=YES
#ascii_download_enable=YES
#ls_recurse_enable=YES
setproctitle_enable=YES

#### VIRTUAL USER CONFIGURATION #####
virtual_use_local_privs=YES
user_sub_token=$USER
local_root=/home/TEST/$USER
hide_ids=YES # SUPER IMPORTANT
#########

##### SECURE CONFIGURATION #####
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES
# require_ssl_reuse=NO # Certains clients FTP necessitent cette ligne
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
rsa_cert_file=/etc/ssl/private/vsftpd.cert.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.key.pem
pasv_enable=YES
pasv_promiscuous=NO
pasv_min_port=40000
pasv_max_port=40100pasv_address=127.0.0.1
#ou domaine.com avec pasv_addr_resolve=YES
port_promiscuous=NO
#rsa_cert_file=/etc/ssl/private/vsftpd.pem
###########

Il faut maintenant sécuriser le protocole (car de base, il ne l’est pas). On va alors créer un certificat :

# apt-get install openssl
# openssl req -x509 -nodes -days 730 -newkey rsa:1024 -keyout vsftpd.pem -out vsftpd.pem

Il nous est alors demandé de renseigner plusieurs champs, le plus important : Common Name (eg, YOUR name) []

On copie le fichier généré dans le répertoire /etc/ssl/certs/ :

# cp vsftpd.pem /etc/ssl/certs

On sécurise le certificat :

# chown root:root /etc/ssl/certs/vsftpd.pem
# chmod 600 /etc/ssl/certs/vsftpd.pem

Nous ajoutons les lignes suivantes dans notre fichier de configuration (déjà présente dans le fichier du dessus) :

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES
 
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES

On redémarre le service :

# /etc/init.d/vsftpd restart

Partie 3 : Répertoire personnel

Un problème se pose, pour que l’utilisateur de l’Active Directory ait un répertoire personnel créé automatique, il faut normalement se connecter avec celui-ci sur la Debian, nous ne pouvons procéder ainsi.

La solution trouvée est de créer un script qui va vérifier l’existence ou nom pour chaque utilisateur du domaine d’un répertoire personnel, si le répertoire n’existe pas il sera créé.

# nano script.sh

On rajoute :

#!/bin/sh
 for user in $( wbinfo -u );
 do
         if [ ! -d /home/TEST/$user ]
         then
                 /bin/mkdir /home/TEST/$user
                 /bin/chown -R $user:"domain users" /home/TEST/$user
         fi
 done
 /etc/init.d/winbind restart

On sauvegarde et on rend exécutable le script :

# chmod +x (777) script.sh

Maintenant, nous devons faire en sorte que ce script soit automatisé toutes les minutes :

# nano /etc/crontab

On y ajoute :

*/1 * * * * root   /root/script.sh

On redémarre le service avec un petit /etc/init.d/cron restart

Partie 4 : Bloquer SSH

Pour une question de sécurité, seul root sera autorisé à utiliser ssh. Nous allons rajouter une ligne dans le fichier /etc/ssh/sshd_config :

AllowUsers root

Partie 5 : Clé publique / Clé privée

Dans PuTTYGen, nous cliquons sur « Generate » puis on remue la souris dans l’encadré rouge afin de générer la clé.

On copie alors la clé publique et on la colle dans le fichier .ssh/authorized_key

# mkdir –p .ssh
# nano .ssh/authorized_keys

On clique ensuite sur “save private key”, nous répondons “oui” à la question « Are you sure you want to save this key without a passphrase to protect it ». On choisit alors un emplacement ou sauver la clé.

Dans PuTTY, on va dans “Connection” puis “Data”, on renseigne le champ « Auto-login username »

Dans « Connection » à « SSH » à « Auth », on clique sur « browse » et on va rechercher la clé privée.

Et pour une question de meilleure lisibilité, on peut se rendre dans « Window » puis « Translation » et choisir «UTF-8»

Pour terminer, on retourne dans « Session », on ajoute l’adresse IP (ou l’Host Name). On donne un nom à la session dans « Saved Sessions », on sauvegarde et on clique sur « Open ».

Partie 6: Client FTP

Le client FTP utilisé ici sera FileZilla. Quelques petites modifications sont à faire afin qu’il fonctionne correctement.

On clique sur « Ouvrir le gestionnaire des sites »

On crée un nouveau site et on y ajoute les champs suivants :

ftp 2ftp

L’identifiant et le mot de passe correspondent à un utilisateur de l’Active Directory.

 

Le serveur mail de A à Z

Ce serveur mail a été réalisé sur une Ubuntu 10.04.3 LTS mais le développement reste le même sur une Debian. Nous supposerons que le DNS est bien configuré (présence d’un enregistrement MX valable) et prêt à remplir correctement son rôle.

Pour ceux qui débuteraient dans le domaine, quelques explications s’imposent:

Un utilisateur est abonné chez domaine1.com et a comme adresse e-mail expediteur@domaine1.com. Un autre est abonné chez domaine2.org avec comme adresse e-mail destinataire@domaine2.orgexpediteur souhaite envoyer un e-mail à destinataire.

Voici ce qu’il va se passer :

    1. expediteur rédige le message avec son client de messagerie (appelé aussi Mail User Agent). Lorsque le message a été rédigé, expediteur l’envoie par le biais de son MUA;
    2. Le serveur smtp.domaine1.com (correspondant au MTA, Mail Transfert Agent) reçoit alors le message, il constate que le destinataire n’est pas dans son domaine. Il va donc chercher l’enregistrement MX dans le DNS de domain2.org.
      Il envoie le message à smtp.domaine2.org ;
    3. Le serveur smtp.domaine2.org reçoit à son tour le message et constate que le destinataire est bien dans son domaine. Il range le message dans la boîte aux lettres de destinataire par l’intermédiaire du MDA (Mail Delivery Agent).
    4. Lorsque destinataire décidera de regarder s’il a des nouveaux messages, il enverra une requête à son serveur imap.domain2.org au moyen de son client de messagerie;
    5. Le client de messagerie va chercher sur le serveur IMAP et consulte la boîte aux lettres de destinataire et constate qu’il y a un message dedans;
      Le message est visible dans le MUA.

Voici les différents outils qui seront utilisés:

  • Postfix (le serveur SMTP)
  • Courier-IMAP (le serveur IMAP)
  • Procmail (le MDA)
  • Amavis avec SpamAssassin et ClamAV (Antispam et Antivirus)

Postfix:

Installons tout d’abord le paquet nécessaire à l’utilisation de Postfix:

# apt-get install postfix

Normalement, quelques questions nous sont demandées:

General Type of configuration? --> Internet
Site Where should mail for root go--> On laisse blanc
Mail name? --> mail.server.be
Other destinations to accept mail for? (blank for none) --> mail.server.be, localhost
Force synchronous updates on mail queue ? --> No
Local networks ? --> 127.0.0.0/8
Use procmail for local delivery--> Yes
Mailbox size limit --> 0
Local address extension character? --> +
Internet protocols to use --> all

Il se peut parfois, lors de l’installation qu’aucune information ne soit demandée, il est possible de répondre à ces questions ultérieurement, en utilisant la commande suivante :

# dpkg-reconfigure postfix

Ensuite, nous devons modifié l’un des 2 fichiers essentiels au bon fonctionnement de Postfix, à savoir main.cf (le 2ème fichier est master.cf, ce fichier contient des informations diverses sur le comportement de Postfix et sa façon de faire résider les différents daemons ):

# nano /etc/postfix/main.cf
myhostname = mail.server.be
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname

mydestination = mail.server.be, localhost.server.be ,localhost
relayhost =
mynetworks = 127.0.0.0/8, 172.23.0.0/16, 192.168.0.0/16
#mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/ # Si pas précisé, les mails iront dans /var/mail

Ce fichier contient la configuration principale de Postfix.

Quelques explications sur les différentes lignes de ce fichier: 

myhostname = mail.server.be

Cette option doit contenir le nom de domaine (FQDN) du serveur.

alias_database = hash :/etc/aliases

Fichier de type hash contenant une table d’alias mail. Celle-ci est éditable dans /etc/aliases, puis régénérée en hash grâce à la commande newaliases qui produit le fichier /etc/aliases.db
Cette étape est indispensable pour prendre en compte les changements.

myorigin = /etc/mailname

Cette option va indiquer le fichier qui contient une seule ligne décrivant le nom de domaine utilisé.
Dans ce cas-ci, /etc/mailname contient mail.server.be.
Il est essentiel de vérifier l’exactitude du contenu de ce fichier. Il faut que le nom de domaine soit bon sinon on aura quelques soucis.

mydestination = mail.server.be, localhost.server.be, localhost

Liste des domaines pour lesquels le serveur doit accepter le courrier.

mynetworks = 127.0.0.0/8, 172.23.0.0/16, 192.168.0.0/16

Contient la liste des réseaux locaux autorisés.

mailbox_command = /usr/bin/procmail

Commande pour utiliser Procmail comme MDA. Pas utilisé pour l’instant, on le commente.

mailbox_size_limit = 0

Limite de taille en octets pour les boîtes aux lettres, un zéro signifie qu’il n’y a pas de réstriction.

recipient_delimiter = +

Séparateur entre le nom d’utilisateur et les extensions d’adresse (par défaut le signe +).

inet_interfaces = all

Interfaces réseaux sur lesquelles le serveur va écouter.
Ici, on écoute sur toutes les interfaces.

Nous allons maintenant créer une adresse e-mail. Rien de plus simple, il suffit de créer un nouvel utilisateur:

# adduser test

On répond aux différents champs et on fixe un mot de passe pour l’utilisateur.

Pour tester si tout fonctionne correctement avant de continuer, essayons d’envoyer un mail à test:

# echo "Ceci est le contenu de mon mail" | mailx -s "ceci est le sujet" test@mail.server.be

Le mail sera automatiquement déposé dans le répertoire Maildir situé dans le répertoire personnel de test. S’il n’existe pas, le dossier Maildir sera automatiquement créé.

On peut s’assurer que le mail est arrivé en se rendant dans le répertoire personnel ou en utilisant les logs :

# cat /var/log/mail.log

Pour augmenter la sécurité du serveur de manière significative, il faut à présent parler des notions de TLS et de SASL (SSL).

Cette partie est assez délicate à réaliser, une minuscule erreur et on peut passer toute sa journée à essayer de trouver où est le problème.

Installons les paquets nécessaires:

# apt-get install libsasl2 sasl2-bin libsasl2-modules

Générons ensuite les certificats SSL auto signés pour Postfix :

# mkdir /etc/postfix/ssl
# cd /etc/postfix/ssl/
# openssl genrsa –des3 –rand /etc/hosts –out smtpd.key 1024

Nous devons choisir un passphrase (permet de sécuriser la clé privée).

Ensuite, il faut changer les permissions d’accès à l’aide d’un chmod :

# chmod 600 smtpd.key
# openssl req -new -key smtpd.key -out smtpd.csr

Quelques questions nous sont posées et comme d’habitude, on fait bien attention au Common Name. Il doit impérativement correspondre à mail.server.be.

Utilisons, à présent, les commandes suivantes (un passphrase est à nouveau demandé):

# openssl x509 -req -days 3650 -in smtpd.csr -signkey smtpd.key -out
smtpd.crt
# openssl rsa -in smtpd.key -out smtpd.key.unencrypted
# mv -f smtpd.key.unencrypted smtpd.key
# openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

Maintenant que les certificats ont été générés, modifions la configuration de Postfix en ajoutant quelques lignes dans le fichier main.cf pour activer le TLS (ou s’assurer que les lignes suivantes y sont déjà):

smtpd_use_tls= yes
smtpd_tls_auth_only = no
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Ajoutons quelques lignes (toujours dans main.cf) concernant la partie SASL (permettant une authentification):

smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous 
broken_sasl_auth_clients = yes

Le daemon d’authentification utilisé sera saslauthd:

# mkdir -p /var/spool/postfix/var/run/saslauthd
# rm –rf /var/run/saslauthd

Cette commande est très importante pour éviter d’avoir des erreurs lors du test avec testsaslauthd.

# ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd
# chgrp sasl /var/spool/postfix/var/run/saslauthd
# adduser postfix sasl
# nano /etc/default/saslauthd

Dans ce fichier précédemment créé, on ajoute/vérifie les lignes suivantes :

START=yes
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Ensuite, allons dans le fichier smtpd.conf:

# nano /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
mech_list: login plain

Dans ce fichier, j’ai dû préciser quelle méthode et quel format allaient être utilisés.
Concernant le deuxième fichier de Postfix, le master.cf, il suffit juste de décommenter les lignes suivantes (et de commenter celle concernant le port 25 afin d’autoriser uniquement l’envoi d’emails de manière sécurisée):

smtps inet n - - - - smtpd
 -o smtpd_tls_wrappermode=yes
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,
reject

Il ne reste plus qu’à démarrer salsauthd et redémarrer Postfix pour prendre en compte la nouvelle configuration :

# /etc/init.d/saslauthd start
# /etc/init.d/postfix restart

On peut ensuite tester le bon fonctionnement grâce à la commande :

# testsaslauthd -u test -p Password

Courier-IMAP:

On procède à l’installation des paquets nécessaires:

# apt-get install courier-imap courier-authdaemon

Nous devons modifier une ligne dans le fichier de configuration de Courier-IMAP. Ce fichier se situe dans /etc/courier et se nomme imapd.
Il s’agit de celle concernant le MAILDIRPATH, c’est-à-dire le chemin pour accéder aux boîtes aux lettres.

On retourne alors dans le dossier de notre utilisateur et on fait :

# maildirmake Maildir

Cette commande va créer une boîte aux lettres complète chez un utilisateur. On aura un utilisateur par boîte mail.
A partir d’ici, tout est normalement fonctionnel et on peut tester avec notre logiciel de messagerie (comme Thunderbird par exemple).

Pour ce qui est de la sécurité, installons les paquets suivants :

# apt-get install courier-imap-ssl

Il faut alors modifier le fichier imapd-ssl par défaut qui se trouve dans /etc/courier/ :

TLS_CERTFILE=/etc/postfix/ssl/mail.combined.npw.pem
IMAP_TLS_REQUIRED=1
MAILDIRPATH=Maildir

Utilisons la commande suivante pour supprimer le passphrase sur le certificat cakey.pem (si ce n’est pas fait, une erreur sera visible dans les logs):

# openssl rsa –in cakey.pem -out cakey.nopw.pem

Ici, il y a une subtilité à prendre en compte. Contrairement à Postfix, le daemon IMAP exige que le certificat et la clé privée soient combinés en un même fichier.

On concatène:

# cat cacert.pem cakey.nopw.pem >> mail.combined.npw.pem
# openssl dhparam 1024 >> mail.combined.npw.pem

Il faut ensuite exécuter 2 commandes afin d’éviter une erreur « error:0906D06C:PEM routines:PEM_read_bio:no start line » dans les logs :

# chmod 400 mail.combined.npw.pem (ou 777 si cela est vraiment nécessaire)
# chattr +i mail.combined.npw.pem

Un petit redémarrage s’impose :

# /etc/init.d/courier-authdaemon restart
# /etc/init.d/courier-imap restart
# /etc/init.d/courier-imap-ssl restart

Procmail, Amavis et SpamAssassin :

Nous installons, comme toujours, les paquets nécessaires:

# apt-get install procmail amavisd-new clamav clamav-daemon spamassassin
spamc

Pour pouvoir utiliser Procmail, il faut créer un fichier dans le dossier de notre utilisateur test :

# touch .procmailrc

C’est donc dans ce fichier que seront placées les règles de filtrages. Il faut être très vigilent pour le faire fonctionner et faire très attention au droit mis sur ce fichier.
Il faut s’assurer que l’utilisateur en question soit propriétaire de ce fichier, si ce n’est pas le cas :

# chown test:test .procmailrc

Pour ce qui est des droits d’accès sur le fichier :

# chmod 600 .procmailrc

Ce qui va fixer les permissions à rw——-.
C’est-à-dire que le propriétaire aura accès en lecture et écriture (rw-) et les membres du groupe et les autres n’auront pas d’autorisation ().

En ce qui concerne ClamAV et Amavis , après l’installation chacun crée de son côté un utilisateur et un groupe. Afin que ClamAV puisse accéder aux pièces jointes décompressées par Amavis, il faut le rajouter au groupe amavis :

# addgroup clamav amavis

Pour autoriser le filtrage de ClamAV et SpamAssassin, éditons le fichier 15-content_filter_mode qui se trouve dans /etc/amavis/conf.d/:

@bypass_virus_checks_maps = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

Pour que des e-mails lui soient confiés, ajoutons ceci dans le fichier main.cf :

content_filter = scan:127.0.0.1:10024

On se rend alors dans l’autre fichier master.cf pour rajouter :

smtp-amavis unix - - y - 2 smtp
 -o smtp_data_done_timeout=1200
 -o disable_dns_lookups=yes

scan unix - - n - 16 smtp
-o smtp_send_xforward_command=yes

127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes

A présent, il faut s’assurer que SpamAssassin se lance au démarrage du système, ouvrons le fichier /etc/default/spamassassin et modifions la valeur de ENABLED :

ENABLED=1

Ensuite, on modifie la ligne concernant le nombre maximum de processus à exécuter :

OPTIONS= “--max-children 5 –helper-home-dir”

–max-children correspond au nombre d’enfants à lancer par spamd (le daemon de SpamAssassin). Aucun autre enfant ne sera lancé tant qu’un des 5 actuels ne sera pas mort. Cette option sert à éviter que trop de processus soient lancés en même temps afin de préserver la mémoire.

La configuration de SpamAssasin se fait dans le fichier local.cf présent dans /etc/spamassassin.
Dans ce fichier, il est possible de déterminer le message devant apparaitre en avant de l’en-tête :

rewrite_header Subject *****SPAM*****

Ainsi que le score au-delà duquel le message sera considéré comme spam :

required_score 10.0

Redémarrage pour prendre en compte la configuration:

# /etc/init.d/amavis restart
# /etc/init.d/clamav-daemon restart
# /etc/init.d/spamassassin restart
# /etc/init.d/postfix restart

Maintenant que les étapes nécessaires au bon fonctionnement de ces outils sont accomplies, passons au comportement souhaité de ceux-ci.

C’est dans le fichier de Procmail que tout va se passer.
Pour les spams, le comportement sera différent suivant le score, si c’est un virus, on aura aussi un comportement différent.

Il est nécessaire de créer le fichier .procmailrc dans le Home Directory de chaque utilisateur.

Au début du fichier, il faut impérativement ceci :

SHELL=/bin/sh
#PATH=${HOME}/bin:/usr/bin:/bin
DEFAULT=$HOME/Maildir/
MAILDIR=$HOME/Maildir
#LOGFILE=$HOME/.procmail.log
VERBOSE=yes
DROPPRIVS=yes
#LOGABSTRACT=all
#LOCKFILE=${HOME}/.procmail/lock

A la suite de ceci, on peut commencer à écrire nos règles :

# Permet de suivre l’email au travers du daemon spamc
# (l’interface de SpamAssassin)
:0fw
| /usr/bin/spamc
# Si l’email obtient un score de 20  supprimé
:0
* ^X-Spam-Level: *\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null
# Si l’email obtient un score de 10
#  placé dans spam
:0
* ^X-Spam-Level: *\*\*\*\*\*\*\*\*\*
$MAILDIR/.spam/
# Si l’email est détecté comme virus
#  placé dans virus
:0:
* ^X-Amavis-Alert: INFECTED
$MAILDIR/.virus/
# Si l’email est à la fois un virus et un spam
:0:
* ^X-Amavis-Alert: INFECTED
* ^X-Spam-Status: Yes
/dev/null
# on le supprime

Haute disponibilité avec Pacemaker et Corosync

Tout d’abord un bref descriptif de la haute disponibilité:

On appelle « haute disponibilité » (en anglais « high availability ») toutes les dispositions visant à garantir la disponibilité d’un service, c’est-à-dire assurer le bon fonctionnement d’un service 24H/24.

Le terme « disponibilité » désigne la probabilité qu’un service soit en bon état de fonctionnement à un instant donné.

Pacemaker and Corosync

Nous allons tout d’abord installer les 2 outils qui seront nécessaires:  Corosync et Pacemaker.

Corosync va permettre de mettre les serveurs utilisés en cluster et Pacemaker va s’occuper de la gestion des ressources. 

# apt-get install corosync
# apt-get install pacemaker

Passons maintenant à la configuration de Corosync. Le fichier de configuration devra être le même sur chaque noeud

 # nano /etc/corosync/corosync.conf

Il va falloir faire quelques modifications afin d’éviter l’apparition d’erreurs:

token: 5000
token_retransmits_before_loss_const: 20
join: 1000
consensus: 7500
max_messages: 20
secauth: on # We use a key to allow a node to connect to the cluster

Nous allons maintenant définir une interface réseau qui autorisera la communication entre les différents noeuds:

interface {
 ringnumber: 0
 bindnetaddr: 10.10.10.0 // Adresse réseau à adapter selon le cas
 mcastaddr: 226.94.1.1
 mcastport: 5405
 }

Intégrons maintenant le service Pacemaker au cluster de Corosync. 
Assurons nous que le fichier de configuration de Corosync contienne bien les lignes suivantes:

service {
 # Load the Pacemaker Cluster Resource Manager
 ver: 0
 name: pacemaker
}

On va maintenant s’occuper de l’authentification. Une clé a été générée durant l’installation des packages, il est possible d’en recréer une de cette manière:

# corosync-keygen

Ensuite on va envoyer la clé à/aux autre(s) noeud(s) (dans notre cas nous n’aurons que 2 serveurs, donc 2 noeuds):

# scp /etc/corosync/authkey root@My_other_node:/etc/corosync

La configuration du cluster étant terminée, il faut maintenant activer Corosync:

# nano /etc/default/corosync

On redémarre alors le service:

# /etc/init.d/corosync start

Passons maintenant à la configuration de Pacemaker:

Note : Pour se connecter à la console de Pacemaker, on se contente d’utiliser la commande suivante:  crm_mon -1

Sur n’importe lequel des noeuds, on va se connecter au CLI (Common-Line Interface) pour configurer le cluster de Pacemaker (afin de définir le comportement désiré):

# crm

Il est possible de connaître notre configuration déjà existante en utilisant la commande suivante :

# configure
# show

On exécute ensuite la commande suivante (toujours en mode configure):

# property stonith-enabled="false" no-quorum-policy="ignore"

Stonith est un composant de Pacemaker qui permet au système de redémarrer le serveur qui a échoué. Dans notre cas, ce composant est désactivé. Nous allons également ignoré la perte du quorum  (le nombre minimum de noeuds en ligne afin de permettre la validation  d’une décision). Avec un cluster de 2 noeuds, il n’y a pas de quorum quand un noeud est perdu. L’opération par défaut quand il n’y a pas de quorum est de couper toutes les ressources.

On peut s’assurer de la bonne configuration en utilisant la commande show.
On doit alors forcer la prise en compte des changements sur tous les noeuds en utilisant la commande commit.

Service Actif/Passif

Le service sera lancé et supervisé par Pacemaker, pas besoin de le lancer au démarrage du système. Pour désactiver ce lancement sur une Debian (Squeeze):

# insserv –r –v service

Le service qui sera supervisé devra être installé et configuré de la même manière sur chacun des noeuds.

Le VIP est l’adresse virtuelle utilisée pour accéder aux service avec haute disponibilité. Cette adresse sera ajoutée comme une seconde adresse sur l’interface de notre choix.

Les commandes suivantes doivent être réalisées sur les 2 noeuds (l’adresse IP sera modifiée selon le cas):

# crm configure
# primitive VIP1 ocf:heartbeat:IPaddr2 \
params ip="192.168.1.100" broadcast="192.168.1.255" nic="eth0" cidr_netmask="24" iflabel="VIP1" \
op monitor interval="30s" timeout="20s"
# commit

Une nouvelle interface, appelée eth1: VIP1, vient d’être ajoutée.

Nous allons à présent ajouter le service. Nous nous occuperons ici d’Apache, mais le processus est le même pour d’autres services.
Toujours en mode configure (et sans oublier le commit à la fin), nous ajoutons:

# primitive APACHE ocf:heartbeat:apache \
params configfile="/etc/apache2/apache2.conf" \
op monitor interval="30s" timeout="20s" \
op start interval="0" timeout="40s" \
op stop interval="0" timeout="60s"

Malheureusement, en utilisant la commande show, on peut voir que VIP1 est lancé sur un serveur et qu’Apache l’est sur l’autre. Il faut qu’ils soient lancés sur le même.

Certains changements doivent être faits.
Il faut que le service tourne sur un des noeuds et qu’en cas de perturbation du service, celui-ci passera sur l’autre noeud (après 3 tentatives).

# crm configure
# group APACHE-HA VIP1 APACHE meta migration-threshold="3"
# commit
APACHE and VIP1 are grouped in the APACHE-HA group.

Nous désactivons également l’auto-failback. Le noeud restera en mode passif même lorsque le problème aura été résolu.

# crm configure
# property default-resource-stickiness= « 10 »
# commit

Les tests

On coupe le serveur qui fait tourner le service, les ressources sont transmises à l’autre serveur et reste actives sur celui-ci même si le serveur (anciennement actif) et redémarré.

On pourrait aussi couper Apache. Après la 3ème tentative pour le relancer, le sercice est lancé sur l’autre noeud.
Il faudra alors remettre à zéro le compteur sur le noeud qui a rencontré des erreurs:

# crm resource cleanup APACHE-HA