J'ai écrit cette page pour aider les débutants qui voudraient, comme moi,
créer un serveur indépendant sur une machine locale. Les différents services
que j'ai mis en places sont :
J'ai installé le système GNU-Linux Debian Lenny à partir d'un CD netinstall.
Il y a beaucoup de possibilités dans l'étape de partitionnement, par exemple
utiliser 2 disques durs en mirroir (RAID 1 logiciel) pour une fiabilité des
données accrue.
Je vais passer directement à l'installation des différents logiciels, en
supposant que l'installation du système est faite.
Le systeme Debian fonctionne avec le gestionnaire de paquets apt-get. Pour installer un programme, il faut executer la commande (avec l'utilisateur root):
apt-get install nom_du_paquet
Pour que le serveur fonctionne, il doit avoir une connection internet permanente.
De plus, elle doit accepter les connexions entrantes, c'est-à-dire qu'on doit
pouvoir l'appeller depuis internet.
En gros, les clients vont appeller le serveur depuis internet par son nom,
et ce nom doit correspondre à une adresse ip qui doit pointer d'une manière ou d'une autre
sur la machine hôte (notre serveur).
Ma machine est connectée derrière une livebox qui fonctionne avec une IP dynamique ! Il semble bien que si mon IP change régulièrement, mon serveur ne puisse pas être accessible depuis le net. Pour contourner le problème, il faut s'enregistrer sur un site de DNS dynamique. Le principe est simple : lorsqu'on veut faire une requête au serveur, on appelle le site avec le nom qu'il nous a atribué, et lui redirige la requête vers notre machine serveur. Il suffit ensuite de prévenir ce site dès qu'on change d'ip.
J'utilise DynDNS (www.dyndns.com), et j'ai configuré la livebox pour qu'elle
mette à jour l'ip dynamique sur ce site.
Modifier le fichier :
/etc/network/interfaces
# Boucle locale
auto lo
iface lo inet loopback
# Adresse ip statique
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
# Adresse ip dynamique (désactivée)
#auto eth0
#iface eth0 inet dhcp
Ce fichier définit la configuration des interfaces réseau de débian. Ici,
On configure une ip locale statique : 192.168.1.2
Il faut vérifier que la box possède bien l'adresse 192.168.1.1
Sinon, on peut adapter notre ip, par exemple 192.168.0.1
Une petite astuce : le fichier /etc/resolv.conf
contient des ip de serveurs DNS à rechercher. J'ai créé ce fichier pour aider
mon système à passer par le DNS de la box :
/etc/resolv.conf
nameserver 192.168.1.1
Ajouter cette ligne de code dans le fichier .bashrc de root
/root/.bashrc
. /etc/bash_completion
Rien de plus simple : il suffit d'utiliser l'outil de gestion de paquets apt-get
apt-get install fortune fortunes-fr
Pour avoir une petite fortune en accueil lors de la connection, il faut ajouter au fichier .bashrc
~/.bashrc
# lance la commande fortune
fortune
Même système : apt-get...
Note : le paquet fail2ban n'est pas indispensable, mais je l'ai installé
pour des raisons de sécurité. Il sert à empêcher l'attaque dite "dictionnaire"
ou "force brute" en bannissant pour un temps l'ip d'un utilisateur qui échoue
à entrer le bon mot de passe 5 fois d'affilée (par défault).
apt-get install openssh-server fail2ban
Pour configurer fail2ban :
/etc/fail2ban/jail.conf
On peut configurer ssh pour permettre la connexion au serveur via des clefs RSA, au lieu de taper le mot de passe à chaque fois. Il faut créer une paire de clefs sur la machine cliente :
ssh-keygen -t rsa
Le chemin par défault ~/.ssh/id_rsa fonctionne très bien. Il faut ensuite transférer la clef publique du client dans le fichier ~/.ssh/authorized_keys du serveur.
scp .ssh/id_rsa.pub utilisateur_serveur@192.168.1.2:~/.ssh/nom1.pub
ssh utilisateur_serveur@192.168.1.2
cat .ssh/nom1.pub >> .ssh/authorized_keys
nom1.pub est le fichier contenant la clef publique de l'utilisateur 1. On peut utiliser ces commandes plusieurs fois pour permettre à plusieurs utilisateurs de se connecter.
On installe les programmes nécéssaires :
apt-get install postfix procmail courier-imap courier-imap-ssl
C'est ici que ça se complique. J'ai commencé par configurer le serveur pour qu'il reçoive les mails qui lui sont destinés et qu'on puisse les récupérer grâce au protocole IMAPS (le S signifie sécurisé avec SSL) depuis internet. J'ai aussi configuré le protocole IMAP (sans S, non sécurisé) sur la machine locale pour pouvoir faire fonctionner un programme de webmail plus tard.
Il faut configurer le MTA Postfix. C'est le logiciel qui reçoit les mails d'internet. Sa configuration est compliquée, et pour l'instant je m'occupe des paramètres nécessaires à la seule réception de courrier. On verra après que c'est aussi postfix qui envoie les mails sur internet.
etc/postfix/main.cf
mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
home_mailbox = Maildir/
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
mydomain = mondomaine.com
inet_interfaces = all
inet_protocols = all
Il faut remplacer mondomaine.com par le nom de domaine approprié. Par exemple,
Si l'adresse mail est moi@chezmoi.org, il faut utiliser chezmoi.org
je vous invite à consulter les commentaires de mon fichier de configuration (lien en dessous)
pour des explications sur les différents paramètres.
Voiçi mon fichier de configuration principal de postfix :
Les mails sont stockés par défault dans le dossier /var/mail. Pour changer ça, on va utiliser procmail, qui sera lancé par postfix à chaque fois que le serveur recevra un mail, et qui traitera le mail (filtre de spam, virus, etc) avant de le stocker. Il faut donc créer un fichier de configuration de procmail pour chaque utilisateur.
/home/nom_utilisateur/.procmailrc
SHELL=/bin/bash
MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
ORGMAIL=$MAILDIR
LOCKFILE=$HOME/lockfile.lock
DEFAULT=$HOME/Maildir/
JUNKMAIL=$HOME/Maildir/.junkmail/
TRASH=$HOME/Maildir/.Trash
#LOGFILE=/var/log/procmailrc.log
#VERBOSE=yes
#LOGABSTRACT=all
# Filtres à rajouter...
Il faut une "boîte aux mails" pour chaque utilisateur : Je l'ai créée avec Maildirmake.
cd /home/nom_utilisateur
maildirmake Maildir
maildirmake -f Sent Maildir
maildirmake -f Queue Maildir
maildirmake -f junkmail Maildir
maildirmake -f virus Maildir
maildirmake -f Drafts Maildir
maildirmake -f Trash Maildir
chown -R nom_utilisateur Maildir
La dernière commande donne le dossier Maildir (la "boîte aux mails") à l'utilisateur nom_utilisateur. C'est très important, car sinon le dossier ne pourra pas être ouvert, et les mails ne seront pas accessibles. Il faut toujours se méfier des problèmes de droits quand on utilise debian, ou tout autre système Linux ou UNIX.
La configuration par default de courier-imap permet directement l'accès aux
mails par le protocole IMAP (vu le nom du programme, on s'en doutait). Et
la configuration de courier-imap-ssl permet l'utilisation de IMAPS (c'est à
dire la version sécurisée SSL du protocole IMAP).
Donc, tout fonctionne. Or lors de la connexion au serveur IMAP, l'utilisateur
envoie son login et son mot de passe à travers le réseau. Celà ne pose pas de
problèmes dans le cas de l'interface iterne à la machine (adresse 127.0.0.1)
car les données ne peuvent être interceptées,
ni dans le cas où le protocole est sécurisé (IMAPS) car les données sont
cryptées et le mot de passe ne peut pas être intercepté.
Tout ça pour dire qu'il vaut mieux limiter l'accès en IMAP à l'interface
127.0.0.1 pour raisons de sécurité. Il faut modifier le fichier de configuration
de courier-imap :
/etc/courier/imapd
address=127.0.0.1
Configuration de base de postfix. J'avais dit qu'on y reviendrait! Il faut ajouter des paramètres :
/etc/postfix/main.cf (re)
myorigin = /etc/mailname
#myorigin = $mydomain
mynetworks = 127.0.0.0/8
#mynetworks = 127.0.0.0/8, 192.168.1.0/24
relayhost = smtp.exemple.org
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
Le paramètre relayhost correspond au serveur smtp vers lequel tous les mails
sortants seront redirigés (optionnel). Il est utile parce que beaucoup de
serveurs considèreront notre courrier comme du spam, car nous ne sommes pas
sur les "listes blanches". Du coup il faut mettre le smtp de notre FAI (fournisseur
d'accès internet) qui, lui, nous connait.
myorigin correspond au domaine par défault de l'adresse d'envoi.
smtpd_recipient_restrictions permet d'empêcher n'importe qui d'utiliser le
serveur pour envoyer des mails. C'est un paramètre très important qui permet
de ne pas être un "open relay", par lequel pourrait circuler tous les spams
de la terre. Ici, on autorise les mails provenant de clients autentifiés par
sasl (à configurer, voir en dessous) et les mails provenant des réseaux définis
par le paramètre mynetworks.
Elle permet l'envoi de mails en ligne de commande depuis le serveur (par exemple en utilisant ssh). Utile pour tester l'envoi des mails. Il faut installer le paquet "mailx".
apt-get install mailx
Celà permet d'être reconnu par le serveur par un système de login/mot de passe.
On pourra envoyer des mails après s'être autentifé, alors que le serveur
rejettera les envois de mails venant de l'exterieur et d'utilisateurs qu'il
ne connait pas.
Il y a beaucoup de manières de le faire. On peut utiliser une base de donnée,
un fichier dans lequel on stocke les utilisateurs... J'ai choisi la méthode
qui m'a paru la plus simple (car mon serveur n'hébergera pas des milliers
d'utilisateurs mails) : on autentifie les utilisateurs UNIX du serveur.
On installe les paquets et on créé le fichier de config aproprié.
apt-get install libsasl2-2 libsasl2-modules sasl2-bin
touch /etc/postfix/sasl/smtpd.conf
/etc/postfix/sasl/smtpd.conf
log_level: 3
pwcheck_method: authdaemond
mech_list: PLAIN LOGIN
Il faut modifier la conf du demon saslauthd, car postfix se lance en mode "chroot", c'est à dire qu'il ne peut pas lire les fichiers en dehors du dossier /var/spool/postfix. On modifie donc le fichier :
/etc/default/saslauthd
START=yes
OPTIONS="-m /var/spool/postfix/var/run/saslauthd"
Quelques manips pour que ça fonctionne (donner les bons droits, créer les dossiers nécéssaires, modifier la configuration de postfix...)
mkdir -p /var/spool/postfix/var/run/saslauthd
rm -fr /var/run/saslauthd
chgrp sasl /var/spool/postfix/var/run/saslauthd
adduser postfix sasl
/etc/postfix/main.cf (encore)
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_authenticated_header = yes
broken_sasl_auth_clients = yes
Ces lignes sont à ajouter dans le fichier.
L'autentification sasl nous permet maintenant d'envoyer des mails à distance
sans toutefois être un "open relay". Mais ça créée un problème au niveau de
la sécurité. En effet, lors de l'autentification, le login et le mot de passe
système de l'utilisateur sont envoyés à travers le réseau sans protection.
On va donc activer le cryptage SSL de la communication pour pouvoir s'autentifier
tranquillement.
La première étape est de créer un certificat tls pour postfix. J'ai récupéré
ça, mais j'avoue ne pas savoir expliquer le pourquoi du comment. Enfin, ça
créée un certificat, quoi...
apt-get install openssl
cd ~
export OPENSSL_CONF="/etc/ssl/openssl.cnf"
/usr/lib/ssl/misc/CA.pl -newca
/usr/lib/ssl/misc/CA.pl -newreq
/usr/lib/ssl/misc/CA.pl -signreq
mkdir /etc/postfix/tls
mkdir -p /var/cache/postfix
cp ./{demoCA/cacert.pem,newkey.pem,newcert.pem} /etc/postfix/tls/
rm ./{newreq.pem,newkey.pem,newcert.pem}
cd /etc/postfix/tls
openssl x509 -in cacert.pem -out ca.crt
openssl x509 -in newcert.pem -out server.crt
openssl rsa -in newkey.pem -out server.key
rm ./{cacert.pem,newkey.pem,newcert.pem}
chmod 400 /etc/postfix/tls/server.key
On adapte la configuration de postfix :
/etc/postfix/main.cf (l'incontournable)
smtpd_tls_security_level = may
smtpd_tls_CAfile = /etc/postfix/tls/ca.crt
smtpd_tls_cert_file = /etc/postfix/tls/server.crt
smtpd_tls_key_file = /etc/postfix/tls/server.key
smtpd_tls_session_cache_database = btree:/var/cache/postfix/smtpd_tls_session_cache
smtpd_tls_loglevel = 2
smtpd_tls_auth_only = yes
invoke-rc.d postfix restart
invoke-rc.d saslauthd restart
invoke-rc.d courier-imap restart
invoke-rc.d courier-imap-ssl restart
Le logiciel logwatch permet de recevoir par mail les différentes informations contenues dans les logs du serveur. Il n'est évidement pas indispensable, mais c'est un bon outil pour garder un oeil sur les attaques.
apt-get install logwatch
apt-get install proftpd
config : le fichier /etc/proftpd/proftpd.conf
La configuration que j'ai permet la connexion en ftp de 2 manières différentes :
le premier mode est "anonymous", c'est-à-sdire sans autentification (pas de login
ni de mot de passe). L'utilisateur a dans ce cas uniquement le droit de télécharger
les fichiers du dossier /home/ftp. Le deuxième
mode permet aux utilisateurs système de se connecter et d'accéder en
lecture et écriture à leur dossier personnel
(/home/nom_utilisateur ou ~).
Or je voulais que les utilisateurs puissent écrire dans le dossier
/home/ftp, et ainsi mettre des documents à disposition
de tout le monde. Pour cela, j'ai trouvé une astuce : on monte le dossier
/home/ftp dans le dossier personnel de chaque
utilisateur. Et on s'occupe des droits, toujours le même problème...
mkdir /home/nom_utilisateur/ftp
chown nom-utilisateur /home/nom_utilisateur/ftp
addgroup utilisateurs
adduser nom_utilisateur utilisateurs
chown ftp:utilisateur /home/ftp
chmod 770 /home/ftp
mount --bind /home/ftp /home/nom_utilisateur/ftp
Un peu d'explications... Je créé un groupe "utiisateurs" (commande addgroup) dans lequel j'inclus tous les utilisateurs du ftp (chez moi, tous les utilisateurs UNIX). Dans l'exemple, j'y ajoute simplement l'utilisateur "nom_utilisateur", (commande adduser) qui représente le compte avec lequel on pourra tester le fonctionnement du ftp. Je donne ensuite le dossier /home/ftp à l'utilisateur "ftp" et au groupe "utilisateurs" (commande chown). Je définis les droits de lecture/écriture/execution pour l'utilisateur et le groupe (commande chmod). Enfin, je fais le montage (commande mount). Chez moi, j'ai écrit un petit script qui me fait automatiquement le montage au démarrage du système.
Autre possibilité (que j'utilise maintenant) : créer un utilisateur dédié aux connexions ftp. En effet, comme le mot de passe circule de toutes façons en clair, il vaut mieux compromettre la sécurité d'un seul utilisateur générique, à qui l'on donne peu de droits, plutôt que de mettre en péril les mots de passe des "vrais" utilisateurs du serveur (mots de passes valables pour le mail et le ssh). J'ai donc créé l'utilisateur "tous" et j'ai mis dans son dossier personnel (/mnt/data/stock -accessible en ftp privé-) le dosier accessible depuis la connexion anonyme (/home/ftp -accessible en ftp public-). J'utilise pour cela la commande:
mount --bind /home/ftp /mnt/data/stock/ftppublic
On relance le serveur ftp pour appliquer les changements
invoke-rc.d restart proftpd
Note : le protocole ftp n'est pas sécurisé, les mots de passe circulent donc en clair. Pas très propre!
apt-get install apache2
Le protocole http doit fonctionner de base, sans changement de configuration.
Pour le https (encore SSL!), on va créer un certificat de la même manière que pour
postfix :
apt-get install openssl
cd ~
export OPENSSL_CONF="/etc/ssl/openssl.cnf"
/usr/lib/ssl/misc/CA.pl -newca
/usr/lib/ssl/misc/CA.pl -newreq
/usr/lib/ssl/misc/CA.pl -signreq
mkdir /etc/apache2/ssl
cp ./{demoCA/cacert.pem,newkey.pem,newcert.pem} /etc/apache2/ssl/
rm ./{newreq.pem,newkey.pem,newcert.pem}
cd /etc/apache2/ssl
openssl x509 -in cacert.pem -out ca.crt
openssl x509 -in newcert.pem -out server.crt
openssl rsa -in newkey.pem -out server.key
rm ./{cacert.pem,newkey.pem,newcert.pem}
chmod 400 /etc/apache2/ssl/server.key
On va activer le mode sécurisé. a2enmod pour le mode ssl en tant que tel,
et a2ensite pour activer le fichier de configuration du virtualhost du site
sécurisé par défault.
Note : il est possible de ne pas activer default-ssl et de stocker toutes les
configurations dans /etc/apache2/sites-availables/default.
On peut aussi avoir plusieurs virtualhosts...
a2enmod ssl
a2ensite default-ssl
On peut modifier les fichiers de configuration des deux sites par default : /etc/apache2/sites-availables/default et /etc/apache2/sites-availables/default-ssl. On peut aussi rajouter un site différent dans un autre fichier virtual host, par exemple /etc/apache2/sites-availables/nouveau-site. Il faudrait ensuite lancer la commande :
a2ensite nouveau-site
On va installer les supports php et msql. Je n'ai pas eu besoin de toucher à la configuration : ça fonctionne très bien par défault.
apt-get install php5
apt-get install mysql-server mysql-common
invoke-rc.d apache2 restart
apt-get install squirrelmail squirrelmail-locales squirrelmail-decode
Configuration de squirrelmail : je l'inclus dans mon site web par default. L'autre moyen est de créer un nouveau virtual host, mais c'est plus compliqué.
ln -s /usr/share/squirrelmail /var/www
mv /var/www/squirrelmail /var/www/webmail
/usr/sbin/squirrelmail-configure
Pour se connecter au webmail, on envoie un identifiant et un mot de passe. Donc, il faut une connexion sécurisée. Pour le forcer, on ajoute dans le fichier de configuration (dans le virtualhost):
/etc/apache2/sites-available/default
redirect /webmail https://mondomaine.org/webmail
Ajouter dans le fichier de configuration :
/etc/apache2/sites-available/default-ssl
<Directory /var/www/webmail>
php_flag register_globals off
</Directory>
Modifier le fichier :
/usr/share/squirrelmail/functions/i18n.php
$languages['fr_FR']['LOCALE'] = 'fr_FR';
Dans l'outil de configuration de squirrelmail, configurer la langue. Choisir 10 language, Default Language : fr_FR
/usr/sbin/squirrelmail-configure
Si celà ne fonctionne pas, vérifier les langues locales de debian par la commande
locale
Au besoin, installer le paquet locales-all :
apt-get install locales-all
Il faut commencer par installer mailman :
apt-get install mailman
Je précise que ma configuration permet d'utiliser des listes sur le nom de
domaine du serveur, exemple : nom_de_liste@domaine.org
Il est possible d'avoir des listes utilisant des sous noms de domaine, du
type nom_de_liste@liste.domaine.org, mais je n'ai pas choisi cette possiblité.
Il faut changer la configuration de mailman, la ligne suivante doit être décommentée :
/etc/mailman/mm_cfg.py
MTA = ’Postfix’
On va permettre à mailman d'utiliser ses aliases.
/var/lib/mailman/bin/genaliases
chmod 666 /var/lib/mailman/data/aliases
chmod 666 /var/lib/mailman/data/aliases.db
On reconfigure mailman pour activer l'interface en français (on va pas se laisser em**** par ces anglophones indécrotables!). Choisir la langue voulue :
dpkg-reconfigure mailman
Encore un petit coup de configuration de postfix (ça manquait!)
/etc/postfix/main.cf (on ne s'en débarrassera jamais)
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases
On créé la première liste. Elle permettra d'administrer l'ensemble des listes du serveur.
newlist mailman
Mailman possède une interface de gestion web. Il faut donc lui permettre de fonctionner sur le serveur. Je donne ici les modifications de la configuration d'apache nécessaires pour faire fonctionner l'interface web d'administration de mailman :
/etc/apache2/sites-available/default
ScriptAlias /cgi-bin/mailman/ /usr/lib/cgi-bin/mailman/
# And the public archives:
Alias /pipermail/ /var/lib/mailman/archives/public/
# Logos:
Alias /images/mailman/ /usr/share/images/mailman/
<Directory /usr/lib/cgi-bin/mailman/>
AllowOverride None
Options ExecCGI
AddHandler cgi-script .cgi
Order allow,deny
Allow from all
</Directory>
<Directory /var/lib/mailman/archives/public/>
Options Indexes FollowSymlinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<Directory /usr/share/images/mailman/>
AllowOverride None
Order allow,deny
Allow from all
</Directory>>
Il faut faire un reload d'apache. L'interface est ensuite disponible à l'adresse :
http://domaine.org/cgi-bin/mailman/listinfo
invoke-rc.d apache2 reload
On peut supprimer une liste de diffusion mailman. La commande à lancer :
/var/lib/mailman/bin/rmlist -a nom_liste
Pour que chaque utilisateur système ajouté puisse utiliser les services du
serveur, il faut que son dossier personnel contienne les dossiers et fichiers
que l'on a créé pour le premier utilisateur. Pour celà, j'ai utilisé le dossier
de configuration /etc/skel dans lequel on peut
mettre des informations qui seront automatiquement copiées dans le dossier
personnel du nouvel utilisateur.
cp /home/premier_utilisateur/Maildir /etc/skel
cp /home/premier_utilisateur/.procmailrc /etc/skel
cp /home/premier_utilisateur/accueil /etc/skel
cp /home/premier_utilisateur/ftp/ /etc/skel
cp /home/premier_utilisateur/.bashrc /etc/skel