De Wiki de la communauté Mandriva.

Aller à : Navigation, rechercher

Mandriva est réputée être une distribution orientée bureau. Bien souvent, on peut lire des articles déconseillant l'utilisation de La distribution pour un serveur LAMP dédié. Pourtant, une fois quelques réflexes acquis, cette distribution se trouve être au moins équivalente à d'autres distributions "dédiées" à cette usage au niveau de l'installation ... voir même plus simple à utiliser et sécuriser (même sans interface graphique).

Ce tutoriel s'adresse à un utilisateur ayant déjà utilisé la console sous linux et sachant éditer des fichiers texte dans la console (avec vi par exemple), typiquement un utilisateur d'une autre distribution linux qui voudrait connaître les spécificités de Mandriva. Si les termes partitions, scripts, DNS, registrar et vi vous sont familiers, ce tutoriel est fait pour vous. Dans le cas contraire, vous pouvez suivre pas à pas le tutorial, en cherchant à chaque difficulté à approfondir et comprendre le point de blocage, ou encore expérimenter d'autres tutoriels avant de revenir ici (comme Le shell sans peine).

Il permet d'installer rapidement un serveur dédié Mandriva permettant la mise en oeuvre d'un "LAN virtuel" pour une petite communauté (famille, amis, ...) ou une petite entreprise, doublé de logiciel PIM à la sauce Web 2.0. Il permet de découvrir certaines spécificités de Mandriva et de s'initier aux arcanes de cette excellente distribution. Il prouve également la polyvalence de la distribution linux, qui ne demande qu'à être installée correctement pour se transformer selon les usages.

Il a également vocation à servir de "best practice" en termes d'installation de ce type de serveur. Il peut donc être utilisé par administrateur confirmé comme pense bête lors d'une installation.

Attention !
Ce tutoriel fonctionne uniquement pour la Mandriva 2007.1. Mandriva fournit des paquetages qui sont pré-configurés de manière fonctionnelle et sécurisée. Les configurations par défaut des autres distributions linux pourraient être insuffisantes dans le cadre de ce tutoriel, qui pourrait laisser le système vulnérable à certaines attaques. Donc, n'utiliser ce tutoriel QUE sur Mandriva.

Sommaire

1 Cas d'utilisation du serveur
2 Installation et configuration du système de base
3 Sécurité, sécurité ...
4 Configuration du réseau
- 4.1 Configuration du réseau et du nom de machine
- 4.2 Configuration du service de réseau privé virtuel (VPN IPSEC)
5 Service de synchronisation d'horloge (NTPD) : toujours à l'heure
6 Configuration du serveur de noms (DNS - BIND)
7 Service LAMP
8 Configuration du service d'annuaire (LDAP)
9 Configuration du service Mail
10 Echanger des fichiers via le VPN (SAMBA)
- 10.1 Configuration de Samba
- 10.2 Configuration des SambaLDAP Tools
11 Les services Webs de base (EGROUPWARE)
12 Serveur de fichiers proftpd
13 La téléphonie (ASTERIX, TEAMSPEEK)
14 Fonctionnement courant
- 14.1 Ajouter un site
- 14.2 Sauvegarder et restaurer le serveur

Cas d'utilisation du serveur

Le serveur est hébergé chez un fournisseur. Il est connecté directement à internet (ou un réseau insécurisé).

Comme le montre ce schéma, nous supposons que le réseau constitué de plusieurs réseaux et ordinateurs connectés sur internet :

Un réseau local privilégié, qui a accès notamment à certains outils (configuration, gestion ...) de manière spécifique et privilégiée. Les connexions de ce réseau sont réalisées via un routeur/firewall (un ordinateur mandriva dédié par exemple).

Un réseau local invité, par exemple le réseau local d'un ami.

Des ordinateurs portables qui peuvent se connecter à des réseaux non sécurisés (vous quand vous accédez au réseau d'entreprise.

Les adresses IP de ces différents réseaux sont notées respectivement xxx.xxx.xxx.xxx, yyy.yyy.yyy.yyy et zzz.zzz.zzz.zzz.

Le serveur dédié, dont l'adresse internet est sss.sss.sss.sss hébergera plusieurs domaines internet :

un domaine principal (principal.com) qui permettra, en plus d'accéder aux services suivants :
- un site internet publique,
- un site intranet privé qui permettra d'accéder à des pages de configuration et de maintenance du serveur,
- un service de courrier électronique qui centralise les mails de plusieurs adresses,
- un gestionnaire de carnets d'adresses,
- un gestionnaire d'agendas électroniques,
- un gestionnaire de liens (bookmark),
- un service de téléphonie IP (teamspeake),
- un service de mise à disposition de fichiers (scans de documents importants comme la dernière feuille d'impots, la carte d'identité, etc)
- des serveurs de jeux.
Des domaines secondaires, hébergé sous différents noms de domaine.

Le serveur domestique aura un accès en administration complet au serveur dédié. Les autres ordinateurs auront des restrictions d'accès aux outils de configuration du serveur dédié.

Le tout devra permettre de gérer plusieurs groupes d'utilisateurs, des droits d'accès et de partages (agendas, etc) de manière centralisée, sur le serveur dédié, créant ainsi un intranet.

L'intranet sera sécurisé via des tunnels cryptés (VPN) marqués en grisé sur le schéma ci-dessus. Le VPN permettra également de faire communiquer plusieurs réseaux locaux connus ou des ordinateurs autonomes (portables) pour, par exemple, échanger des fichiers de manière sécurisée, partager des répertoires et imprimantes sur le serveur ou sur tout ordinateur d'un des sous-réseaux locaux connectés, etc.

Les réseaux du VPN seront nommés et pourront utiliser le serveur comme nom de domaine privé de manière à faire communiquer simplement des machines de sous-réseaux différents. Le reste du WEB n'aura accès qu'à quelques noms publics, comme par exemple www.principal.com.

En bref, le cas d'utilisation est un super serveur regroupant toutes les fonctionnalités de Google et plus, sur un seveur dédié et sécurisé, et permettant de faire vivre une petite communauté d'amis, de travail, ou une entreprise de taille conséquente (filiales...).

Installation et configuration du système de base

Installation du système

Je me place volontairement dans le cas où le serveur est situé chez un hébergeur. Plusieurs hébergeurs proposent des services de location de serveurs dédiés tout à fait abordable pour des particuliers, les offres les moins chères débutant à partir d'environ 20 euros mensuels. Suivant la solution d'hébergement retenue, vous aurez ou n'aurez pas accès directement à une installation Mandriva 2007.1. Dans le cas ou vous avez accès à une installation Mandriva 2006 (ce qui fut mon cas), il vous suffira juste de faire une mise à jour. Sinon, vous aurez besoin d'installer la distribution sur une partition alternative. Dans les deux cas, je vous propose dans un premier temps d'étudier le schéma de partitionnement d'un serveur réseau, qui vous permettra une installation propre et fiable du système.

Cette partie pourra vous permettre de faire vos premières armes avec URPMI, le système de gestion de paquetages de Mandriva. Il est notamment en charge de la gestion des sources d'installation (l'endroit ou l'on peut trouver les paquetages à installer) et plusieurs autres aspects de la gestion (gestion des dépendances lors de l'installation d'un paquetage, recherche de paquetages, etc). C'est un complément indispensable de RPM. Si vous voulez approfondir vos connaissance de ce système, vous pouvez le faire sur http://wiki.mandriva.com/fr/Urpmi .

Option Raid

TODO

Partitionnement d'un serveur

Lors de l'installation, il vous sera demandé de créer des partitions sur le disque dur de votre serveur. Ce partitionnement peut être vu comme le fractionnement quasi matériel de votre disque dur en disques "virtuels" de plus petites tailles.

Une question vient tout de suite à l'esprit : pourquoi partitionner le disque ?

Plusieurs réponses peuvent être fournies. Le partitionnement permet de séparer sur plusieurs disques les données personnelles des utilisateurs, les données de configuration du système, les données temporaires, les informations nécessaires aux services du système et les programmes des utilisateurs. Ainsi, il est possible de réinstaller, voir de supprimer le système sans corrompre les données utilisateurs. Il est aussi possible d'installer plusieurs systèmes sur des partitions différentes en mutualisant certaines parties du disque. Les disques ont une limite de taille qui ne peut être dépassée : un programme utilisant toutes les ressources temporaires ne limitera pas l'espace utilisateur si ceux-ci sont sur deux partitions différentes.

La manière de partitionner dépend du type d'utilisation du système. En règle générale, il est recommandé de partitionner le disque d'un serveur le plus possible. Ceci, bien que contraignant à l'usage, empêchera des dysfonctionnements dus au manque de ressources disque. La liste des partitions que j'utilise pour un serveur doté d'un disque de 160Go est :

Point de montage	Taille conseillée	Système de fichiers conseillé (FS)	Commentaires
/boot	40Mo	ext2	Ce répertoire contient les noyaux des systèmes linux et les paramètre de Grub, le gestionnaire de démarrage . Il est pratique d'utiliser la même partition boot quand on a plusieurs systèmes linux installés sur sa machine.
swap	2 Go	swap	La partition swap du système.
/	300 Mo	ext3	La racine du système Mandriva 2007.1, qui contient les données de configuration du système et les programmes d'administration de base.
/usr	2 Go	ext3	Contient les programmes utilisateurs et les services du système.
/var	2 Go	ext3	Contient les données nécessaires au bon fonctionnement des services du système (DNS, sites web, bases de données, ...). Mandriva installe par défaut certains logiciels Webs dans celle-ci, comme phpMyAdmin, phpLDAPAdmin et EGroupware.
/tmp	5 Go	ext3	Contient les données temporaires du système.
/home	La taille restante	ext3	Contient les données personnelles des utilisateurs et les données des sites hébergés.

Comme noté, j'utilise ext3 pour toutes les partitions sauf le swap et la partition /boot.

Ce schéma peut être adapté. Si vous possédez plusieurs systèmes sur la machine, vous pouvez ajouter une partition pour l'utiliser. Vous pouvez également réduire ou augmenter la partition /var si vous le souhaitez. La taille est laissée volontairement faible car je projette d'utiliser /home pour abriter les différents sites.

Une fois le partitionnement choisi, on peut continuer l'installation. Nous considérons ici qu'une "vieille" distribution mandriva a été installée. Si la dernière version est installée, vous pouvez directement passer le paragraphe suivant.

Mise à jour depuis une Mandriva 2006

C'est ce mode que j'ai utilisé, mon hébergeur n'installant (hélas) que la Mandriva 2006. Les instructions suivantes devraient également être valides pour mettre à jour depuis une distribution plus récente.

Les tailles, noms et système de fichiers des différentes partitions du système de base à l'installation sont indiqués dans la section relative au partitionnement.

Vous avez alors plusieurs solutions pour passer à la 2007.1. Je vais ne parler que de celle que j'ai utilisée.

Une fois la 2006 installée par votre hébergeur, il faut mettre à jour la distribution. Pour ce faire, on ajoute une source de la 2006 obtenue depuis le site http://easyurpmi.zarb.org/ .J'ai choisi la source proxad (free) ce qui me donne les commandes :

urpmi.addmedia --update updates ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/updates/2006.0/main_updates/ with media_info/hdlist.cz
urpmi --auto-select --auto

Une fois mise à jour, je vous conseille d'obtenir une première fois le système minimal en vous reportant à la section Système minimal. Cela accélèrera la mise à jour. Après vous être assuré que vous avez un système minimal, vous pouvez suivre directement les instructions du paragraphe Mise à jour du système ce qui mettra à jour la version installée en version 2007.1.

Le système minimal

Ici, on cherche a supprimer les paquetages du système de manière à ne garder que les paquetages strictement nécessaires au fonctionnement du serveur. Ceci permet un accroissement de la sécurité (moins de paquetages = moins de vulnérabilités), une maintenance plus facile et une accélération des mises à jour.

Le système minimal est installé avec le paquetage basesystem qui contient toutes les dépendances des autres paquetages liés. On a en plus besoin de urpmi pour gérer les sources des paquetages et de openssh-server pour accéder au serveur (ce serait une mauvaise idée de l'enlever ;o), msec pour la sécurité et les locales française locales-fr.

Comment vérifier que le système minimal est installé ?

Mandriva propose une commande tout à fait utile pour faire cela. La commande urpmi_rpm-find-leaves permet d'afficher les paquetages RPM installés qui n'apparaissent dans aucune dépendance d'autres RPM installés (à ne pas confondre avec rpm -qa qui affiche tous les paquetages installés, y compris les paquetages dépendant d'autres paquetages installés). En clair, la suppression de ces paquetages ne provoquera pas de suppression d'autres paquetages en cascade. Cette liste correspond finalement à la liste minimale des paquetages composant le système, les autres étant installés par le jeu des dépendances.

Avant de poursuivre l'installation, on veut donc tout simplement être sûr que urpmi_rpm-find-leaves affiche la liste : basesystem, urpmi, openssh-server, msec, locales-fr.

Ceci peut être réalisé par un petit script bash comme celui ci-après. Il prend en entrée une liste de paquetages. Puis, à chaque itération, il examine le système installé (urpmi_rpm-find-leave) pour retirer de la liste des paquetages tous les paquetages qui ne font pas partie de la liste entrée initialement. Cette opération est réitérée tant que des paquetages sont retirés. Ainsi, le système est laissé dans un état où la commande urpmi_rpm-find-leave n'affiche que des paquetages de la liste, en excluant toutefois les paquetages dépendants d'autres paquetages installés.

#!/bin/sh list="basesystem urpmi openssh-server msec locales-fr" echo $list > mini.tmp cont="T" while [ $cont = "T" ] do cont="F" system=`urpmi_rpm-find-leaves` for pak in $system do if grep -q "\<$pak\>" mini.tmp then echo "Keeping $pak" else if urpme $pak then cont="T" fi fi done done

Ce fichier doit être copié sur le serveur et ses permissions doivent être positionnées de manière à rendre le script exécutable (chmod u+x system_filter, system_filter étant le nom du fichier texte écrit).

Le fichier s'invoque de la manière suivante : ./system_filter.

Mise à jour de la distribution

Plusieurs étapes permettent la mise à jour du système.

On va tout d'abord configurer les sources de la distribution, c'est à dire l'endroit où la distribution va chercher les logiciels et paquetages à installer et à mettre à jour.

On efface dans un premier temps toutes les anciennes sources :

urpmi.removemedia -a

On peut alors ajouter les nouvelles sources. Une méthode simple et efficace consiste à se rendre sur le site http://easyurpmi.zarb.org/. Celui-ci permet de générer les commandes de configuration en fonction du miroir choisi. Par exemple, si on choisi ftp.free.fr, les commandes générées ressemblent à :

urpmi.addmedia main ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/main/release with media_info/synthesis.hdlist.cz
urpmi.addmedia --update main_updates ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/main/updates with media_info/synthesis.hdlist.cz
urpmi.addmedia main_backports ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/main/backports with media_info/synthesis.hdlist.cz
urpmi.addmedia contrib ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/contrib/release with media_info/synthesis.hdlist.cz
urpmi.addmedia --update contrib_updates ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/contrib/updates with media_info/synthesis.hdlist.cz
urpmi.addmedia contrib_backports ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/contrib/backports with media_info/synthesis.hdlist.cz
urpmi.addmedia non-free ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/non-free/release with media_info/synthesis.hdlist.cz
urpmi.addmedia --update non-free_updates ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2007.1/i586/media/non-free/updates with media_info/synthesis.hdlist.cz

On peut alors mettre à jour :

urpmi --auto-select --auto

Lors d'une première installation, on épure une deuxième fois la distribution avec la même liste de RPMs initiaux. En effet, des paquetages (tels que wireless-tools) étaient apparemment dans la liste des dépendances d'un des RPMs et n'y sont plus en 2007.1. De la même manière, certains paquetages sont intallés par défaut après la mise à jour et peuvent être supprimés (comme libxorg-x11). Là, le système est bien propre ... enfin presque ! Les fichiers de configuration ont certainement évolués d'une version à l'autre. Les fichiers des configuration contenus dans les RPMs mis à jour n'écrasent (heureusement) pas par défaut les fichiers de configuration existant. Il faut pourtant les faire évoluer aussi, sous peine d'avoir un système non fonctionnel (c'est arrivé à quelques personnes sur les forums).

La commande find /etc -name "*rpmnew" permet d'afficher tous les fichiers terminants par rpmnew dans le répertoire /etc. Ces fichiers doivent servir de base pour faire évoluer vos fichiers de configuration.

Je n'ai mis à jour que les fichiers suivants :

mv /etc/pam.d/system-auth.rpmnew /etc/pam.d/system-auth
mv /etc/pam.d/su.rpmnew /etc/pam.d/su
mv /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config
mv /etc/sysctl.conf.rpmnew /etc/sysctl.conf
mv /etc/nsswitch.conf.rpmnew /etc/nsswitch.conf

Mise à jour automatique

Maintenant, on va installer un script qui met à jour automatiquement tous les jours : /etc/cron.daily/system_update

#!/bin/sh
LOG=/var/log/updates
echo "Running updates on `date`" >> $LOG
urpmi.update updates >> /var/log/updates 2>&1
urpmi --media updates --auto-select --auto >> /var/log/updates 2>&1

(ce script pourrait être amélioré si les services mis à jour étaient redémarrés automatiquement). Vous devez rendre le fichier exécutable :

chmod 755 /etc/cron.daily/system_update
service crond restart

Quelques paquetages bien utiles avant de continuer

urpmi bash-completion 
urpmi vim-enhanced

Changer le noyau (kernel)

On va changer le noyau vers le noyau entreprise de Mandriva :

urpmi kernel-enterprise-latest

Il y a un petit problème avec l'installation, le lien vers l'initrd du kernel-entreprise n'est pas créé. Alors :

ln -s /boot/initrd-2.6.17-13mdventerprise.img /boot/initrd-entreprise.img

Puis, dans /boot/grub/menu.lst, il suffit d'ajouter :

title linux-entreprise kernel (hd0,0)/vmlinuz-entreprise root=/dev/sda3 acpi=ht splash=silent vga=788 initrd (hd0,0)/initrd-entreprise.img

Assurez-vous que default démarre bien sur le bon noyau. Il suffit alors de faire /boot/grub/install.sh et on est prêt à redémarrer en tapant reboot.

Pour mettre à jour vers un noyau normal, il suffit de faire :

urpmi kernel-latest

Il faut vérifier que le noyau chargé par défaut au démarrage est bien celui-ci (/boot/vmlinuz) et de recharger grub par le biais de la commande /boot/grub/install.sh.

Sécurité, sécurité ...

Avant d'aller plus loin, il est nécessaire de sécuriser le serveur. Sur une distribution Mandriva, cela ne demande (hereusement) pas de formation poussée en sécurité ou la manipulation de commandes ésotériques et bizarres qui peuvent vous faire prendre pour un extra-terrestre auprès de vos proches, les ingénieurs de Mandriva ayant mis à disposition une série d'outils remarquables pour le faire...

Sécuriser ssh

D'abord, configurons tcpwrapper. Qu'est ce que c'est ? C'est un système qui est activé sur Mandriva (à partir du niveau de sécurité 4, voir ci-dessous) et qui permet de filtrer les connexions à des ports particuliers selon l'adresse IP source de la connexion.

Pour cela, il faut éditer le fichier /etc/host.allow et y ajouter la ligne

sshd: xxx.xxx.xxx.xxx, yyy.yyy.yyy.yyy

où xxx.xxx.xxx.xxx et yyy.yyy.yyy.yyy sont deux adresses depuis lesquelles vous vous connecterez à l'aide de ssh.

Alternativement, on peut mettre ALL à la place d'une ou de plusieurs adresses, mais cela est plutôt limite en termes de sécurité, quoique flexible. A vous de voir. Vous pouvez utiliser quelques bons conseils, comme par exemple ceux sur http://wiki.mandriva.com/en/Docs/SysAdmin/Networking/SSH.

C'est une bonne idée d'interdir les logins root via ssh. Cela force de se connecter sur un compte local avant de pouvoir accéder via la commande su au compte root. Il y a donc 2 mots de passe à connaître pour être super utilisateur. De la même manière, je vais interdire le renvoi de terminaux graphiques X via ssh (le serveur est contrôlé en mode texte). Pour cela, on édite /etc/ssh/sshd_config et on vérifie que les lignes suivantes sont positionnées :

... PermitRootLogin no ... PubkeyAuthentication yes ... PermitEmptyPasswords no ... X11Forwarding no ...

Pour n'autoriser que certains utilisateurs à se connecter par ssh, vous pouvez utiliser AllowUsers ou AllowGroups dans le même fichier.

MSEC et autres éléments de sécurité

On commence par supprimer les terminaux (tty) accessibles depuis la console (étant dédié, on n'a pas besoin de 6 ttys). Pour ce faire, il suffit de commenter les lignes 2-6 suivantes dans le fichier /etc/inittab (attention, ne pas commenter les runlevels!).

... # Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty tty1 #2:2345:respawn:/sbin/mingetty tty2 #3:2345:respawn:/sbin/mingetty tty3 #4:2345:respawn:/sbin/mingetty tty4 #5:2345:respawn:/sbin/mingetty tty5 #6:2345:respawn:/sbin/mingetty tty6 ...

On va maintenant régler MSEC. Cet outil est extrêmement puissant et agile. Il permet d'ajuster des paramètres de sécurité de votre système de manière à réaliser, pour votre utilisation, le meilleur compromis entre aisance d'utilisation et sécurité (voir http://club.mandriva.com/xwiki/bin/view/KB/SecureSmsec). On installe MSEC :

 urpmi msec python

MSEC admet des niveaux de sécurité de 1 (pas de politique de sécurité) à 5 (paranoïaque), le niveau 4 étant celui recommandé pour un serveur internet. Je vais montrer comment régler le niveau 5, qui nécessite d'autoriser explicitement tous les services.

Pour éviter de mauvaises surprises, on vérifie bien que sshd est autorisé dans le fichier /etc/host.allow qui doit contenir la ligne :

... sshd: xxx.xxx.xxx.xxx ...

Pour élever le niveau de sécurité de msec à 5, il suffit de taper la commande suivante :

msec -o log=stderr 5

A ce niveau ci, la plupart des services ne sont pas démarrés par défaut lors du démarrage du système. Il faut donc les activer manuellement et les autoriser explicitement dans /etc/hosts.allow.

On est paranoïaque, mais on autorise quand même sshd (toujours utile !) :

chkconfig --add sshd

Tiens, au passage, nous allons lister les services autorisés au démarrage (au niveau 3) :

chkconfig --list

et on désactive tous les services qui ne serviront à rien (donc moins de failles de sécurité) :

chkconfig --del alsa
chkconfig --del haldaemon
chkconfig --del sound

On va maintenant autoriser le ping qui permet toujours de voir le serveur et donc de savoir s'il est disponible en ligne ... Dans le fichier /etc/security/msec/level.local (qu'on créé pour l'occasion), on ajoute les commandes :

from mseclib import * set_security_conf('MAIL_USER', 'USER') accept_icmp_echo (yes) enable_pam_wheel_for_su(no)

où USER est le nom de l'utilisateur que vous utiliserez pour vous connecter à EGroupWare (voir ci-dessous).

Voilà pour le système de base.

Pour aller plus loin, vous pouvez lire une documentation plus complète sur http://wiki.mandriva.com/fr/MSEC_L%27utilitaire_Mandriva_de_gestion_de_la_s%C3%A9curit%C3%A9_du_syst%C3%A8me

Configurer le parefeu (firewall SHOREWALL)

Un ensemble de scripts permettent de configurer le parefeu disponible sous tout linux. Ce système s'appelle Shorewall. Nous allons le configurer et mettre en place le parefeu Mandriva.

La configuration propre à chaque serveur sera détaillée dans les sections correspondantes.

Dans un premier temps, on installe sous root le paquetage associé :

urpmi shorewall

et là, on peut être bloqué(!!!!). Durant le processus d'installation, shorewall a pu être démarré sans être configuré. Bon, pas de panique, il y a encore le système de secours (?).

- Si vous êtes bloqué : On se logue sous root comme indiqué, (en prenant éventuellement soin auparavant de supprimer la clé ssh du serveur dans .ssh/known_hosts). On monte la partition /etc.

- sinon, on continue la procédure. On aura juste alors à redémarrer le serveur.

Dans les deux cas les quelques fichiers du répertoire /etc/shorewall seront modifiés :

/etc/shorewall/zones

...
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw  firewall
net ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

/etc/shorewall/interfaces

... #ZONE INTERFACE BROADCAST OPTIONS net eth0 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

/etc/shorewall/policy

... #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL fw all DROP info net all DROP info #LAST LINE -- DO NOT REMOVE

/etc/shorewall/rules

... #SECTION RELATED SECTION NEW Ping/ACCEPT all fw Ping/ACCEPT fw all SSH/ACCEPT all fw # Autorisation de réaliser des FTPs depuis le FireWall FTP/ACCEPT fw all HTTP/ACCEPT fw all HTTPS/ACCEPT fw all #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

On peut alors :

- redémarrer Shorewall service shorewall restart.

- ou sortir et redémarrer le serveur en mode normal, en utilisant l'interface du fournisseur. On se reconnecte quelques minutes plus tard (ne pas oublier de supprimer la clé dans .ssh/known_hosts!).

On n'oubliera pas de rajouter le service au démarrage :

chkconfig --add shorewall

Mettre en place les quotas

La mise en place de quota est nécessaire pour limiter le débordement d'un utilisateur ou d'un site sur l'espace disque qui peut être requis pour d'autres utilisateurs ou des programmes. C'est toujours une bonne idée de les activer. Cela permet de contraindre les utilisateurs à un espace d'une certaine taille maximale, et laisse donc l'espace des autres utilisateurs globalement toujours accessible à condition que l'espace utilisateur maximal soit alloué.

On commence comme toujours par installer le logiciel.

urpmi quota

On édite alors la table des partitions pour transformer en :

/etc/fstab

/dev/sda8 /home ext3 defaults,usrquota,grpquota 0 2

On effectue alors les opérations suivantes pour le répertoire /home :

Il faut commencer par créer deux fichiers vides qui contiendront les données systèmes sur les quotas de la partition :

touch /home/aquota.user /home/aquota.group

On sécurise l'accès aux fichiers créés (seul root pourra lire le fichier ou le modifier) :

chmod 600 /home/aquota.*

Pour monter le répertoire /home avec les nouveaux paramètres :

mount -o remount /home/

On peut alors créer le contenu des fichiers de quotas créés dans /home :

quotacheck -vug /home

Après quelques temps, on active maintenant les quotas pour le répertoire /home :

quotaon -vug /home

Pour créer les quotas d'un utilisateur user sur le système de fichier /home :

setquota -u USER taille_totale max nb_fichiers max2 /home/

taille_totale étant la taille maximale que user pourra utiliser, max la taille physique maximale pouvant être allouée par user (supérieur au précédant), nb_fichiers le nombre de fichiers au maximum que user pourra créer, max2 le nombre de fichiers physiques au maximum pour user.

On peut utiliser la même procédure pour installer les quotas sur une autre partition (/tmp par exemple).

Pour vérifier les quotas d'un utilisateur :

quota USER

Détecter les rootkits

On installe les deux paquetages :

urpmi rkhunter chkrootkit

Pour utiliser le premier :

rkhunter --update
rkhunter -c --report-mode --quiet

On utilise chkrootkit :

chkrootkit

On peut maintenant industrialiser en utilisant un script qui sera exécuté tous les jours. Pour ce faire, on créé le fichier /etc/cron.daily/rootkits qui contient :

#!/bin/sh ( rkhunter --versioncheck rkhunter --update rkhunter --cronjob --report-warnings-only chkrootkit -V chkrootkit ) | /bin/mail -s 'Le journal des rootkits' root

Puis, on autorise son exécution :

 chmod a+rx /etc/cron.daily/rootkits

Comme on le voit, le rapport sera envoyé à root par mail. Quand Postfix sera configuré, celui-ci sera transmis à l'utilisateur de votre choix.

Installer un système de détection d'intrusion (IDS - Prelude ou Snort)

Prelude est un logiciel qui permet de détecter des intrusions sur un système, un réseau, etc. Il fonctionne de manière répartie : des capteurs (snort, prelude-lml, samhain, ... distribués sur plusieurs machines repèrent les attaques potentielles en analysant les trames réseau sur plusieurs sous-réseaux et en analysant les fichiers log de plusieurrs machines. Un "manager" (prelude-manager regroupe et analyse les informations des capteurs en tenant une base de données à jour. L'interface web (prewikka sera installée juste après le serveur web.

Nous installerons prelude de manière locale au serveur dédié. Je vous conseille de configurer le manager du serveur pour qu'il renvoi l'information à un manager qui se situera sur votre serveur domestique, de manière à traiter les attaques dans leur globalité.

Installer Prelude

Dans cette partie, on installe les logiciels de base.

On installe les paquetages :

urpmi prelude preludedb-mysql

On créé l'utilisateur et le groupe prelude pour éviter de faire fonctionner les composantes de prelude avec les droits super-utilisateur.

mkdir /var/log/prelude/
groupadd -g 90 prelude
useradd -d /var/log/prelude/ -u 90 -s /bin/false -g 90 prelude
chown -R prelude:prelude /var/log/prelude/
chown -R prelude:prelude /var/lib/prelude

On créé la base de données qui servira à stocker l'information nécessaire pour prelude :

/usr/bin/mysqladmin create prelude -p
echo "GRANT ALL PRIVILEGES ON prelude.* TO prelude@'localhost' IDENTIFIED BY 'motdepasseprelude';" | /usr/bin/mysql -h localhost -p
/usr/bin/mysql -h localhost -u prelude prelude -p < /usr/share/libpreludedb/classic/mysql.sql

Le mot de passe motdepasseprelude doit être choisi. Pour changer le mot de passe, vous pouvez toujours passer par phpMyAdmin ou par la ligne de commande :

echo "SET PASSWORD FOR prelude@'localhost'=PASSWORD('motdepasseprelude');" | /usr/bin/mysql -h localhost -p

Installer Prelude-Manager

On installe les paquetages :

urpmi prelude-manager prelude-manager-db-plugin

On corrige quelques petits défauts de Mandriva (/var/spool/prelude-manager/scheduler indispensable et non créé !) et on change l'utilisateur des fichiers et dossiers utilisés par prelude-manager :

chown prelude:prelude /var/run/prelude-manager/
mkdir -p /var/spool/prelude-manager/scheduler
chown -R prelude:prelude /var/spool/prelude-manager/

On ajoute un profil pour prelude-manager :

prelude-adduser add prelude-manager --uid 90 --gid 90

On modifie la configuration de prelude-manager :

/etc/prelude-manager/prelude-manager.conf

... user = prelude group = prelude ... # The type of database (mysql/pgsql). type = mysql # Host the database is listening on. host = localhost # Port the database is listening on. port = 3306 # Name of the database. name = prelude # Username to be used to connect the database. user = prelude # Password used to connect the database. pass = motdepasseprelude ... [TextMod] logfile = stderr logfile = /var/log/prelude/prelude.log ...

On peut alors démarrer le service (et l'ajouter aux services démarrés lors du boot) :

service prelude-manager start
chkconfig --add prelude-manager

On va maintenant s'assurer que prelude-manager est accessible en local (pour accepter les connexions des capteurs locaux) :

/etc/hosts.allow

... prelude-manager:127.0.0.1 ...

Et hops ...

Installer Prelude-LML

Prelude-LML permet d'analyser les logs d'une machine. Il est également possible d'installer une instance de Prelude-LML sur chaque machine d'un réseau et de renvoyer tous les logs à une machine ce qui permettrai de monitorer l'ensemble...

urpmi prelude-lml

On ajoute un profil pour prelude-lm :

prelude-adduser register prelude-lml "idmef:w admin:r" localhost --uid 90 --gid 90

La commande demande un mot de passe qu'il faut obtenir de prelude. Pour ce faire, il faut se connecter en tant que root au serveur dans une autre console et tapper :

prelude-adduser registration-server prelude-manager

La commande vous affiche le mot de passe à saisir dans l'autre console sur la ligne " generated one-shot password is "XXX" ". Copier le puis revenez à cette fenêtre pour accepter l'enregistrement. Sur la première fenêtre, vous devriez voir apparaitre " prelude-lml registration to 127.0.0.1 successful. ".

TODO Configuration des logs à surveiller

On démarre le service et on ajoute le service à la liste des services lancés au démarrage du serveur :

service prelude-lml start
chkconfig --add prelude-lml

Installer Snort

urpmi snort-bloat snort-prelude+flexresp snort-community-rules

On configure SNORT :

/etc/snort/snort.conf

... var HOME_NET [192.168.1.0/24] ... profile = snort # # Snort priority to IDMEF severity mappings: # high < medium < low < info # # These are the default mapped from classification.config: # info = 4 # low = 3 # medium = 2 # high = anything below medium # # output alert_prelude output alert_prelude: profile=snort ...

TODO Meilleure configuration

On ajoute un profil pour snort en suivant la même méthode que pour prelude-lm :

prelude-adduser register snort "idmef:w admin:r" 127.0.0.1 --uid 90 --gid 90

La commande demande un mot de passe qu'il faut obtenir de prelude. Pour ce faire, il faut se connecter en tant que root au serveur dans une autre console et tapper :

prelude-adduser registration-server prelude-manager

La commande vous affiche le mot de passe à saisir dans l'autre console sur la ligne " generated one-shot password is "XXX" ". Copier le puis revenez à cette fenêtre pour accepter l'enregistrement. Sur la première fenêtre, vous devriez voir apparaitre " snort registration to 127.0.0.1 successful. ".

Finalement ...

service snort restart
chkconfig --add snort

Pour aller plus loin : http://www.snort.org/

Installer Samhain

Encore un capteur ... Un puissant capteur qui remplce tripwire. Il permet de faire du monitoring de fichier et donc détecte les changements opérés.

urpmi samhain

Puis, on configure la sortie vers prelude :

/etc/samhainrc

... [log] ... PreludeSeverity = crit ... [Misc] ... PreludeProfile = samhain ...

On va pouvoir rajouter le profil dans prelude en suivant la même méthode que celle décrite ci-dessus :

prelude-adduser register samhain "idmef:w admin:r" 127.0.0.1 --uid 90 --gid 90

On se connecter en tant que root au serveur dans une autre console et on saisit la commande :

prelude-adduser registration-server prelude-manager

La commande vous affiche le mot de passe à saisir dans l'autre console sur la ligne " generated one-shot password is "XXX" ". Copier le puis revenez à cette fenêtre pour accepter l'enregistrement. Sur la première fenêtre, vous devriez voir apparaitre " samhain registration to 127.0.0.1 successful. ".

Finalement ...

service samhain restart
chkconfig --add samhain

Pour aller plus loin : http://la-samhna.de/samhain/manual/index.html

Installer Sancp

Sancp permet de récupérer des statistiques sur le trafic réseau avec pour objectif l'audit, l'analyse historique et la découverte d'activités réseau. Tout un programme ...

Installation :

urpmi sancp

On va pouvoir rajouter le profil dans prelude en suivant la même méthode que celle décrite ci-dessus :

prelude-adduser register sancp  "idmef:w" localhost --uid sancp --gid sancp

TODO configuration SANCP.

On se connecter en tant que root au serveur dans une autre console et on saisit la commande :

prelude-adduser registration-server prelude-manager

La commande vous affiche le mot de passe à saisir dans l'autre console sur la ligne " generated one-shot password is "XXX" ". Copier le puis revenez à cette fenêtre pour accepter l'enregistrement. Sur la première fenêtre, vous devriez voir apparaitre " sancp registration to 127.0.0.1 successful. ".

Finalement ...

service sancp restart
chkconfig --add sancp

Pour aller plus loin : http://www.metre.net/files/sancp.README

Aller plus loin

Pour aller plus loin, je vous conseille d'installer un manager sur les réseaux locaux et sur toutes les machines que vous voulez surveiller et de centraliser toutes les réponses sur un manager central qui se situerait sur votre serveur domestique. Seuls ce serveur aurait accès à Prewikka pour consulter tous les logs et toutes les alertes des tous les sous réseaux et de toutes les machines, et de votre serveur dédié. Handy :) !

Création d'un répertoire système

On va maintenant créer un répertoire dans lequel les différentes bases de données seront stockées. La partition qui l'abritera sera la partition /home, ce qui permettra de diposer d'une place variable. De plus, si on fait exception des fichiers de configuration, TOUTES les données à archiver automatiquement seront dans le même répertoire...

mkdir /home/system
chmod -R a+x /home/system

Vous remarquerez qu'à chaque fois que MSEC effectue ses opérations de sécurité, les droits du répertoire /home/system sont repositionnés à rwx------. Pour éviter ce comportement, il faut ajouter la ligne suivante au fichier /etc/security/msec/perm.local (ou créer ce fichier contenant l'unique ligne suivante) :

/home/system/ root.root 701

Configuration du réseau

Configuration du réseau et du nom de machine

/etc/sysconfig/network

Pour nommer la machine :

NETWORKING=YES HOSTNAME=dedie DOMAINNAME=principal.com

Pour permettre la résolution de nom en local, sans passer par un serveur DNS :

/etc/hosts

127.0.0.1 localhost dedie dedie.principal.com

Redémarrer le réseau avant de continuer :

service network restart

Configuration du service de réseau privé virtuel (VPN IPSEC)

Bien qu'il soit possible de n'utiliser que les IPSEC tools, j'ai utilisé la paquetage OpenSwan qui facilite grandement la chose et surtout qui n'est pas bloquant en cas de panne. Si vous n'utilisez pas ce paquetage, on peut rajouter l'autre méthode...

On commence par configurer shorewall pour qu'il accepte les connexions IPSEC (http://www.shorewall.net/IPSEC.htm). Dans la suite, on considère que sss.sss.sss.sss est l'adresse du serveur, xxx.xxx.xxx.xxx est l'adresse internet (publique) de la passerelle vers le réseau local et le réseau local est 192.168.1.0/24. On ne s'intéresse pas ici à la configuration de la passerelle. J'utilise dans mon cas un routeur-firewall avec VPN intégré assez facile à configurer avec son interface WEB.

/etc/shorewall/zones

... vpn0 ipsec net ipv4 fw firewall ...

/etc/shorewall/tunnels

... ipsec net xxx.xxx.xxx.xxx ...

/etc/shorewall/policy

... vpn0 all DROP info fw all DROP info net all DROP info ...

/etc/shorewall/hosts

vpn0 eth0:192.168.1.0/24

On redémarre le parefeu :

service shorewall restart

Pour être capable de se connecter en ssh depuis le VPN, on ajoute dans le fichier /etc/hosts.allow :

sshd: xxx.xxx.xxx.xxx,192.168.1.0/24

Je vous déconseille d'enlever la connexion depuis l'hôte original sous peine de problème en cas de panne du VPN.

Maintenant, on installe le serveur VPN, qui s'appelle OpenSwan .

urpmi openswan

Ajouter à /etc/openswan/ipsec.conf :

... # Add connections here conn DedieLocal # Le nom de la connexion type=tunnel #tunnel ou transport # Left security gateway, subnet behind it, nexthop toward right. left=xxx.xxx.xxx.xxx leftsubnet=192.168.1.0/24 # Right security gateway, subnet behind it, nexthop toward left. right=%defaultroute pfs=yes keyexchange=ike authby=secret auth=esp esp=3des-sha1 # les deux algorithmes de codage, l'un pour la clé, l'autre pour le tunnel. auto=start ...

/etc/openswan/ipsec.secrets

192.168.1.0/24: PSK "ma phrase secrète connue de moi seul"

Et c'est tout ! Du côté passerelle, on s'assurera juste que les algorithmes de cryptographie sont les mêmes. D'ailleurs, si la passerelle fonctionne sous Mandriva, on pourra utiliser exactement les 2 mêmes fichiers !

Pour démarrer le serveur :

service ipsec start

Bon, là, la ligne de commande devrait être bloquée... On peut vérifier que tout se passe bien depuis l'autre côté. On peut se reconnecter via ssh, connexion qui sera encapsulée dans un tunnel crypté...

On peut bien entendu ajouter autant de réseaux privés que l'on veut.

Pour lancer le serveur à chaque démarrage :

chkconfig --add ipsec

Service de synchronisation d'horloge (NTPD) : toujours à l'heure

Par quoi va t'on commencer ... On installe le paquetage qui contient un service de synchronisation d'horloge pour le système (celui-ci s'appelle NTPD) :

urpmi ntpd

On configure NTPD avec /etc/ntpd.conf

server 127.127.1.0 # local clock server 0.fr.pool.ntp.org server 1.fr.pool.ntp.org server 2.fr.pool.ntp.org

(j'ai utilisé ces serveurs pour configurer ma machine locale, de manière à ce que mon serveur réseau et ma machine personnelle soient à peu près synchrones).

On crée un accès à travers Shorewall :

/etc/shorewall/rules

... NTP/ACCEPT fw net ...

On redémarre le service de parefeu :

service shorewall restart

et on démarre le service de synchronisation d'horloge :

service ntpd start

Pour rajouter ntpd au démarrage :

chkconfig ntpd on

Configuration du serveur de noms (DNS - BIND)

En mode master seulement.

On commence par installer Bind, le logiciel de DNS le plus utilisé (!!) :

urpmi bind

Passons à la configuration :

On édite /etc/named.conf pour y ajouter :

... zone "localhost" IN { type master; file "master/localhost.zone"; allow-update { none; }; }; zone "mon_net.org" IN { type master; file "master/mon_net.org.public.zone"; allow-update { none; }; }; ...

Puis, il vous faut créer le fichier /var/lib/named/var/named/master/mon_net.public.org.zone avec les déclarations publiques :

$ORIGIN principal.com. $TTL 86400 @ IN SOA dns1.principal.com. mail.principal.com. ( 2007030603 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS dedie.principal.com. principal.com. IN MX 10 mail.principal.com. IN MX 30 mxsec1.mon_hebergeur.com. dedie IN A sss.sss.sss.sss mon_local IN A xxx.xxx.xxx.xxx mail IN CNAME dedie dns1 IN CNAME dedie www IN CNAME dedie

Finalement, on change la résolution de nom et on indique les DNS dans le fichier /etc/resolv.conf :

search principal.com nameserver 127.0.0.1 nameserver nssec.monhebergeur.fr

Maintenant, on peut démarrer le serveur :

service named restart

le lancer à chaque démarrage :

chkconfig --add named

et le tester :

nslookup dedie.principal.com
nslookup google.com

Pour le moment, le serveur DNS n'est pas référent sur le net. Il vous faut aller modifier les DNS de référence pour votre domaine chez votre registrar et saisir comme DNS pour votre domaine :

sdXXX.monhebergeur.fr
nssec.monhebergeur.fr

On peut répéter les étapes ci-dessus pour chaque domaine hébergé.

Service LAMP

Configuration du serveur HTTP (Apache) et de PHP

On commence par ... installer les paquetages ! (sisi)

urpmi apache apache-mod_php php-pear

Configurer Apache dépend de l'utilisation que l'on veut en faire. On veut configurer un serveur qui contiendra plusieurs sites distincts (différenciés par leur nom et partageant la même adresse IP) en plus d'un intranet qui sera disponible seulement depuis le VPN.

La configuration de base est la suivante :

On commence par éditer /etc/httpd/conf/httpd.conf, qui est le fichier de configuration central d'Apache .

On renseigne explicitement le nom d'hôte par défaut ou l'adresse IP.

... ServerName www.principal.com:80 ...

Pour le moment, le nom utilisé par défaut est celui fournit par le client, ce qui veut dire que les applications webs réservées pour l'intranet (webmin, phpMyAdmin, phpLDAPAdmin, ...) sont accessibles depuis tous les domaines hébergés. Nous voulons éviter ce comportement pour finalement en contrôler leur accès !

... UseCanonicalName On ...

Pour permettre l'accès à divers outils d'Apache (consultation des options, du statut, exécution de scripts privés) depuis le réseau local privilégié :

... <Directory "/var/www/protected-cgi-bin"> ... #allow from .your_domain.com Allow from 192.168.1.0/24 </Directory> ... <IfModule mod_status.c> <Location /server-status> ... #Allow from .your_domain.com Allow from 192.168.1.0/24 </Location> <IfModule mod_info.c> <Location /server-info> ... #Allow from .your_domain.com Allow from 192.168.1.0/24 </Location> </IfModule> ...

C'est finit pour /etc/httpd/conf/httpd.conf.

On va maintenant configurer le parefeu en ajoutant les règles permettant d'autoriser les connexions à Apache. Pour cela, il faut éditer le fichier /etc/shorewall/rules et ajouter les lignes :

...
HTTP/ACCEPT all fw
HTTPS/ACCEPT all fw
...

Maintenant, on peut démarrer le service en tapant depuis une console :

service shorewall restart
service httpd restart

Pour vérifier que tout est en place, on peut ouvrir un webbrowser et se rendre au site www.principal.com (cela suppose bien entendu que vous ayez déjà configuré votre registrar). Là, la page devrait afficher "It Works!".

On peut lancer le service à chaque démarrage :

chkconfig --add httpd

Configuration du service de base de donnée (MySQL)

Installer MySQL

urpmi MySQL php-mysqli

Sans commentaire.

On déplace le répertoire de données dans /home/system :

mv /var/lib/mysql /home/system/
mkdir /var/lib/mysql
chown mysql:mysql /var/lib/mysql
chmod a+x /var/lib/mysql

On change le fichier de configuration en accord:

/etc/my.cnf

... datadir = /home/system/mysql ... tmpdir = /tmp/ ...

On démarre le service

service mysqld start

On va maintenant sécuriser l'installation. MySQL est livré avec un petit utilitaire qui permet de le faire.

mysql_secure_installation

Il n'y a pas de mot de passe root pour le moment, alors il suffit de taper Entrée à la première question. On répond par oui (y) à toutes les autres questions, sauf à celle dans laquelle on demande de saisir le mot de passe root. Celui-ci DOIT être différent du mot de passe root du serveur, être compliqué et long.

Le service de base de données est maintenant opérationnel et sécurisé (!).

Par défaut, les connexions internet ne sont pas admises par la MySQL, qui n'accepte que des connexions via sockets locales. Nous pouvons changer ce comportement seulement si nous en avons besoin... Ce qui n'est pas le cas ici, vu que seules les applications locales auront accès à la base.

Pour démarrer MySQL au boot :

chkconfig --add mysqld

Installer phpMyAdmin

On va installer une application web qui permet d'accéder à la base de données et de l'administrer depuis un explorateur internet. Cette application s'appelle phpMyAdmin. On commence par installer le paquetage :

urpmi phpmyadmin

On prépare alors le fichier de configuration et quelques répertoires de travail de phpMyAdmin.

cp /etc/phpmyadmin/config.default.php /var/www/phpMyAdmin/config.inc.php
mkdir /var/www/phpmyadmin/upload
mkdir /var/www/phpmyadmin/save
mkdir /var/www/phpmyadmin/tmp
chown apache:apache /var/www/phpmyadmin/upload/
chown apache:apache /var/www/phpmyadmin/save/
chown apache:apache /var/www/phpmyadmin/tmp/

On édite alors le fichier de configuration /var/www/phpmyadmin/config.inc.php en y changeant les lignes suivantes :

... $cfg['blowfish_secret'] = 'une longue séquence de caractères aléatoires'; ... $cfg['Servers'][$i]['connect_type'] = 'socket'; $cfg['Servers'][$i]['extension'] = 'mysqli'; ... $cfg['UploadDir'] = './upload'; $cfg['SaveDir'] = './save'; $cfg['TempDir'] = './tmp'; ...

Remarquez que nous avons changé le paramètre connect_type pour socket car par défaut, la communication tcp vers mysqld n'est pas autorisée.

On va maintenant restreindre l'accès à phpMyAdmin au réseau local privilégié (cette étape n'est pas obligatoire mais augmente la sécurité) et faire en sorte que la connexion au logiciel soit toujours cryptée (en utilisant SSL). Pour ce faire, on édite le fichier /etc/httpd/conf/webapps.d/phpmyadmin.conf pour modifier la clause Allow from ALL et décommenter les lignes qui permettent la redirection systématique vers une connexion SSL :

... <Directory /var/www/phpmyadmin> Allow from 192.168.1.0/24 </Directory> ... # Uncomment the following lines to force a redirect to a working # SSL aware apache server. This serves as an example. # <IfModule mod_ssl.c> <LocationMatch /phpmyadmin> Options FollowSymLinks RewriteEngine on RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R] </LocationMatch> </IfModule> ...

Pour tester, on ouvre un explorateur et on se rend a : www.principal.com/phpmyadmin . Là on se logue et on réalise quelques manipulations...

(Pour sauvegarder la base de données : %>mysqldump [options] --all-databases [options] http://dev.mysql.com/tech-resources/articles/mysql_intro.html http://dev.mysql.com/doc/refman/5.0/en/replication.html)

La fréquentation de votre site (AWstats)

On commence par installer les paquetages:

urpmi awstat perl-Geo-IP perl-net-xwhois

On charge quelques fichiers pour le bon fonctionnement de GeoIp, le petit logiciel qui permet de transformer une adresse IP en localisation géographique :

wget http://www.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
gunzip GeoLiteCity.dat.gz
mv GeoLiteCity.dat /usr/share/GeoIP/
chmod a+r /usr/share/GeoIP/*

On modifie/corrige la configuration par défaut de mandriva (localisation géographiques des clients, etc) :

/etc/awstats/awstats.conf

... SiteDomain="principal.com" ... HostAliases="localhost 127.0.0.1 REGEX[myserver\.com$]" ... LoadPlugin="geoip GEOIP_STANDARD /pathto/GeoIP.dat" ... LoadPlugin="geoip_city_maxmind GEOIP_STANDARD /usr/share/GeoIP/GeoLiteCity.dat" ... LoadPlugin="hostinfo" ...

On autorise à consulter awstats uniquement depuis 192.168.1.2 :

/etc/httpd/conf/webapps.d/awstats.conf

... <Directory /var/www/awstats> Options ExecCGI AddHandler cgi-script .pl DirectoryIndex awstats.pl Allow from 192.168.1.2 </Directory> ...

Maintenant, on va corriger le script qui sera exécuter tous les jours:

!/bin/sh

/var/www/awstats/awstats.pl -config=awstats.conf -update > /dev/null chown apache:apache /var/lib/awstats/* En effet, la commande génère un fichier appartenant à root qui ne peut être lu par Apache et l'installation de Mandriva ne fonctionne pas par défaut. On ajoute juste à la fin du script la commande qui permet de changer de propriétaire.

Pour tester, on commence par générer une première fois les données : /etc/cron.daily/awstats

Puis, on redémarre Apache :

service httpd restart

Finalement, rendez-vous à www.principal.com/awstats pour le log...

Installer Prewikka

Prewikka permet d'accéder aux données analysées et recueillies par Prelude via une interface web.

On commence par installer les paquetages utiles :

urpmi mod_python prewikka

Puis, on configure la base de données stockée dans MySQL.

/usr/bin/mysqladmin create prewikka -p
echo "GRANT ALL PRIVILEGES ON prewikka.* TO prelude@'localhost' ;" | /usr/bin/mysql -h localhost -p
/usr/bin/mysql -h localhost -u prelude prewikka -p < /usr/share/prewikka/database/mysql.sql

Le dernier mot de passe demandé est motdepasseprelude. On va renseigner ce dernier dans le fichier de configuration de Prewikka.

/etc/prewikka/prewikka.conf

... [idmef_database] ... pass: motdepasseprelude ... [database] ... pass: motdepasseprelude ...

On oublie pas de changer le mode d'accès :

chown prelude /etc/prewikka/prewikka.conf
chmod go-r /etc/prewikka/prewikka.conf
chmod a+x /usr/lib/libpreludedb

La dernière commande est pour corriger une petite erreur de mandriva.

On va autoriser le serveur privilégié à accéder à Prewikka en modifiant la fichier de config livré par Mandriva (encore une erreur) : /etc/httpd/conf/webapps.d/prewikka.conf

Alias /prewikka /var/www/prewikka <Directory /var/www/prewikka> Allow from 192.168.1.2 SetHandler mod_python PythonHandler prewikka.ModPythonHandler PythonOption PrewikkaConfig /etc/prewikka/prewikka.conf </Directory>

Maintenant, on re-démarre Apache :

service httpd restart

Puis, rendez-vous avec un explorateur à l'adresse www.principal.com/prewikka . Le login est admin et le mot de passe admin. A modifier à la première utilisation.

Il y a un petit défaut d'installation sur Mandriva. Le style de présentation du site est perdu... Ce qui fait que le site est très difficielement exploitable en l'état. Et je ne sais pas comment le réhabiliter !

Configuration du service d'annuaire (LDAP)

LDAP est un service d'annuaire réseau extrêmement puissant. Il permet de centraliser l'administration des utilisateurs sur un réseau d'entreprise (en incluant la gestion centralisée des habilitations) et offre de nombreuses autres fonctionnalités. Il va nous permettre de tirer pleinement partie de EGroupWare et du réseau "élargit" (incluant tout ou partie des réseaux locaux interconnectés par le VPN) et nous permettre de simplifier l'administration des droits d'accès aux différents services (téléphonie, partage de fichiers,etc).

Cette section demande de connaitre les modes de fonctionnement de LDAP. Je vous conseil de lire quelques tutoriels comme http://en.tldp.org/HOWTO/LDAP-HOWTO/ ou http://julp.developpez.com/freebsd/authentification-ldap/ pour pleinement comprendre le fonctionnement de LDAP. LDAP

Installation et configuration du serveur OpenLDAP

Il est requis dans un premier temps de définir le schéma d'annuaire de manière à ce qu'il soit durable et robuste. Nous sommes alors obligés de bien comprendre le cahier des charges du serveur dédié.

Le serveur dédié héberge :

- un site primaire.

- des sites secondaires.

Nous allons créer la branche des groupes d'utilisateurs par site, en respectant l'arborescence nécessaire au fonctionnement d'EGroupWare 1.4 (qui sera certainement la version incluse dans Mandriva 2008 !!). Dans la configuration du site correspondant au domaine principal.org, nous allons ajouter également les définitions issues du DIT de Mandriva modifié pour cette exercice.

Dans un premier temps, on installe OpenLDAP, qui est le serveur LDAP le plus utilisé.

urpmi openldap-servers
urpmi openldap-clients

On commence par copier la base de donnée dans /home/system :

mv /var/lib/ldap /home/system/

EGroupWare nécessite deux schémas spécifiques pour fonctionner. Ceux-ci peuvent être trouvés dans la distribution EGroupWare. Il est donc nécessaire d'installer EGroupWare à ce stade.

Pour ce faire, j'utilise les sources svn de la 1.4, que j'ai installées en suivant la page http://www.egroupware.org/wiki?wikipage=subversion. Pour installer Subversion, opération préalable au téléchargement SVN, vous devez taper la commande urpmi subversion.

Finalement, on copie les schémas dans le répertoire LDAP et on modifie les droits de manière à ce que le serveur LDAP puisse les lire.

cp /var/www/html/egroupware/phpgwapi/doc/ldap/rfc2307bis.schema /etc/openldap/schema/
chmod a+r /etc/openldap/schema/rfc2307bis.schema
cp /var/www/html/egroupware/phpgwapi/doc/ldap/rfc2307bis.schema /etc/openldap/schema/
chmod a+r /etc/openldap/schema/rfc2307bis.schema
cp /var/www/html/egroupware/addressbook/doc/mozillaabpersonalpha.schema /etc/openldap/schema/
chmod a+r /etc/openldap/schema/mozillaabpersonalpha.schema

On va corriger quelques schémas livrés avec Mandriva de façon à ce que tout soit compatible avec le rfc2307bis. On commente les déclarations des attributs uidNumbre et gidNumber de rfc2307bis.schema, ceux-ci étant apparemment déjà déclarés en interne dans OpenLDAP /etc/openldap/schema/rfc2307bis.schema

... #attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' # DESC 'An integer uniquely identifying a user in an administrative domain' # EQUALITY integerMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 # SINGLE-VALUE ) ... #attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' # DESC 'An integer uniquely identifying a group in an # administrative domain' # EQUALITY integerMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 # SINGLE-VALUE ) ...

Dans le schéma kolab livré, un objet n'est pas déclaré : /usr/share/openldap/schema/kolab.schema on commente les lignes correspondant à la déclaration de namedObject

#objectclass ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' # SUP top STRUCTURAL # MAY cn )

On peut maintenant configurer le serveur LDAP. /etc/openldap/slapd.conf. On commente la ligne qui ajoute le schema “nis” et le schema “autofs” et on ajoute la ligne pour gérer le schéma “rfc2307bis”. On spécifie également le nouveau chemin pour le répertoire qui contient la base de donnée :

... #include /usr/share/openldap/schema/nis.schema ... #include /usr/share/openldap/schema/autofs.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/mozillaabpersonalpha.schema ... database bdb suffix "dc=principal,dc=com" directory /home/system/ldap ...

Le serveur est prêt à démarrer. Enfin presque, il faut maintenant un DIT. Un Mandriva DIT ?

urpmi openldap-mandriva-dit

Mandriva vient avec un DIT par défaut hélas incompatible avec le DIT requis pour EGroupWare. Celui-ci et son utilisation sont décrits sur http://wiki.mandriva.com/en/Projects/OpenLDAP_DIT. Les fichiers "template" sont dans le répertoire /usr/share/openldap/mandriva-dit/. Il est assez simple d'en comprendre et modifier la structure. J'ai enrichi quelque peut le DIT de Mandriva de manière à ce qu'il soit compatible avec EGroupWare (ajout d'un niveau o=default qui permettra de gérer d'autres site et renommage de certains points dans l'arbre de manière compatible avec EGroupWare). Les trois fichiers suivants peuvent être utilisés pour remplacer les fichiers du répertoire /usr/share/openldap/mandriva-dit/. Notez que les droits des utilisateurs sur les carnets d'adresses sont ceux de EGroupWare. Les modifications au fichier /etc/openldap/slapd.conf apportées ci-dessus ont également été appliquées au template de ce fichier (mandriva-dit-slapd-template.conf).

Je ne vais pas m'attarder sur ce schéma et je vous encourage vivement à créer le votre. Une fois les modifications de template effectuées (ou les trois fichiers ci-dessus copiés dans le répertoire /usr/share/openldap/mandriva-dit/ du serveur), on lance :

/usr/share/openldap/scripts/mandriva-dit-setup.sh

Ceci permet de déployer le schéma pour un site donné et de démarrer OpenLDAP..

Il faut maintenant ouvrir l'accès au service.

Dans /etc/hosts.allow, on rajoute la ligne :

... slapd: 127.0.0.1

Ceci permet une connexion au serveur LDAP en local uniquement. Pour autoriser une connexion depuis l'extérieur, il faut ajouter l'adresse de l'hôte ou du réseau et ouvrir le port LDAP dans Shorewall. Nous ne le ferons pas ici. LDAP contenant la liste des utilisateurs, il est nécessaire d'agir avec prudence pour le faire !

Pour démarrer le serveur LDAP à chaque démarrage de l'ordinateur :

chkconfig --add ldap

Installer PhpLDAPAdmin

On va continuer par l'installation de PhpLDAPAdmin.

urpmi phpldapadmin

Dans le fichier /etc/phpldapadmin/config.php, il faut remplacer "dc=example,dc=com" par "dc=principal,dc=com".

Nous allons activer SSL automatiquement lors d'une connexion à LDAP Admin de manière à éviter que les mots de passe système et utilisateur ainsi que l'ensemble de l'organisation ne transite en clair. Nous allons de plus restreindre l'accès à PhpLDAPAdmin au réseau local privilégié. Pour ce faire, en transforme /etc/httpd/conf/webapps.d/phpldapadmin.conf pour ressembler à :

Alias /phpldapadmin /var/www/phpldapadmin <Directory /var/www/phpldapadmin> Allow from 192.168.1.0/24 </Directory> # Uncomment the following lines to force a redirect to a working # SSL aware apache server. This serves as an example. # <IfModule mod_ssl.c> <LocationMatch /phpldapadmin> Options FollowSymLinks RewriteEngine on RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R] </LocationMatch> </IfModule>

Ca y est, fini !

service httpd restart

Vous pouvez accéder à PhpLDAPAdmin depuis un explorateur et l'adresse www.principal.com/phpldapadmin.

Régler l'identification système via LDAP (PAM)

PAM est un module d'authentification pour Linux. Il permet de définir les méthodes d'identification sur un système, comme, dans le cas qui nous intéresse ici, l'identification par LDAP.

Nous allons configurer le système de manière à ce que les utilisateurs déclarés dans LDAP puissent se connecter au système (pour échanger des fichiers, etc). Je suppose que nous utilisons ici le DIT définit plus haut.

Pour gérer les comptes depuis LDAP :

urpmi pam_ldap

On va configurer les méthodes d'accès de PAM au serveur LDAP (chemin des utilisateurs, etc). Pour ce faire, on édite /etc/ldap.conf pour modifier les quelques lignes suivantes :

... base dc=principal,dc=com ... rootbinddn uid=LDAP Admin,ou=system accounts,o=default,dc=principal,dc=com ... nss_schema rfc2307bis ... nss_base_passwd ou=accounts,o=default,dc=principal,dc=com?one nss_base_shadow ou=accounts,o=default,dc=principal,dc=com?one nss_base_group ou=groups,o=default,dc=principal,dc=com?one nss_base_hosts ou=hosts,o=default,dc=principal,dc=com?one ...

Dans le fichier /etc/ldap.secret, il faut remplacer la première ligne (qui contient “secret”) par le mot de passe administrateur LDAP.

/etc/nsswitch.conf

... passwd: compat ldap shadow: files ldap nis group: compat ldap hosts: files ldap nis dns wins ...

/etc/pam.d/system-auth

Et finalement on transforme /etc/pam.d/system-auth de manière à ce qu'il ressemble à :

#%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so likeauth nullok #auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so #account sufficient pam_ldap.so password required pam_cracklib.so retry=3 password sufficient pam_unix.so nullok use_authtok md5 shadow #password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 # permet de créer les répertoires utilisateurs session required pam_limits.so session required pam_unix.so #session optional pam_ldap.so

Pour permettre l'utilisation de PAM par SSH, il faut modifier le fichier /etc/ssh/sshd_config :

... #UsePAM yes ...

Puis, pour prendre en compte les modifications, il faut redémarrer SSHD :

service sshd restart

Et voilà ! Pour tester tout ça, on peut créer un utilisateur avec PHPLDAPAdmin et essayer de se connecter via ssh à l'aide de l'identifiant de cet utilisateur.

On commence par créer un groupe dans la sous-arborescence "groups" en utilisant l'option Posix Group - SUSE. Puis, on créé un utilisateur dans le répertoire "accounts" à l'aide de l'option User Account. On peut alors se logger via ssh à l'aide du nouvel identifiant !

Mais ça ne marche pas ... Vous ne pouvez pas vous connecter avec un utilisateur provenant de LDAP ? J'ai effectivement rajouter des commentaires dans les deux derniers fichiersde configuration ci-dessus. Il faut enlever ceux-ci pour que le login LDAP fonctionne. Mais vous devez vous demander si cela est vraiment une bonne idée. Pour ma part, mes utilisateurs d'eGroupWare ne peuvent pas se loger avec un shell, ce qui est bien et sain. Seuls les utilisateurs définis sous UNIX peuvent le faire et ceux-là n'utilisent pas eGroupWare. Ce sont juste des comptes d'administration. Par contre, les noms d'utilisateur LDAP peuvent être utilisés comme les autres pour définir les propriétés des fichiers, etc. C'est la magie UNIX !

Configuration du service Mail

La base : Serveur de Transport vs. Serveur de consultation (SMTP - IMAP - POP3)

Le transport et la réception des mails sont gérés par le protocole SMTP et le protocole SMTPS, version sécurisée du précédent. Ce service est généralement distingué de la consultation des mails.

Deux protocoles sont disponibles pour consulter vos mails :

Le protocole POP3 (et sa variante sécurisée POP3S) permet de gérer la consultation asynchrone. Les mails sont téléchargés sur la machine cliente et leur copie maintenue ou effacée sur le serveur. C'est en général le protocole utilisé par les FAI mettant à disposition du courrier. Bizzarement, les courriers rappatriés n'ont pas l'air d'être cryptés (pas d'utilisation de POP3S), ce qui veut dire qu'il est théotiquement possible d'intercepter et de lire le courrier rappatrié.
Le protocole IMAP perment une consultation synchrone, c'est à dire que votre courrier reste sur le serveur et votre client mail à la manière d'un répertoire partagé. Le protocole gère la notion de répertoires et permet de déplacer, d'effacer, etc, le courrier sur le serveur. Cela offre des avantages comparé à la solution précédente : votre courrier est toujours accessible via internet, et celui-ci est géré en un unique endroit, ce qui vous évite d'avoir à résoudre des problèmes de synchronisation et d'archivage.

Nous utiliserons ici seulement IMAP qui est parfaitement adapté à l'utilisation de notre serveur.

Serveur de transport et réception des courriels POSTFIX

Installation de POSTFIX

POSTFIX permet de gérer l'envoie et la réception de courriels depuis internet.

 urpmi postfix postfix-pcre postfix-ldap

On va maintenant modifier quelques fichiers de configuration :

/etc/postfix/main.cf

... # User configurable parameters # Noms d'hote et de domaine de la machine myhostname = mail.univ-invisible.org mydomain = univ-invisible.org # Domaine ajoute aux noms des expediteurs locaux myorgin = $mydomain # Liste des domaines ou noms de machine pour lesquels la machine est consideree comme etant la destination finale mydestination = $myhostname, $mydomain, localhost, localhost.$mydomain # Interfaces par lesquelles la machine recoit les courriers inet_interfaces = all #inet_interfaces = localhost # Clients pour lequels le relais sera autorise. # machine locale seulement mynetworks_style = host # OU sous reseau definis #mynetworks = 127.0.0.0/8, 192.168.1.0/24 # Definit les destinations vers lesquelles le courrier d'un client hors des reseaus autorises pourra etre transmis. Ici, on autorisera aucune transmission pour eviter d'etre utilise comme relais de spam. On peut decommenter pour autoriser la transmission des destinations finales. relay_domains = #$mydestination #relay_domains = $mydestination # Relai utilise pour la distribution du courrier. Si il n'est pas renseigne, la machine s'occupe elle meme de la distribution #relayhost = # Remise CYRUS-IMAP mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp # Pour la gestion de boite aux lettres CYRUS mailbox_transport = lmtp:$myhostname ... unknown_local_recipient_reject_code = 550 ... smtpd_helo_required = yes disable_vrfy_command = yes smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client opm.blitzed.org, reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, permit smtpd_data_restrictions = reject_unauth_pipelining permit

(Ca ne fonctionne pas encore. où est le paquetage postfix-dbm ?)

Ce fichier inclut les premières mesures contre les spams préconisées dans la documentation fournie (/usr/share/doc/postfix-2.3.8/UCE/postfix-anti-UCE.txt. Le reste de la documentation peut être trouvé dans le répertoire /usr/share/doc/postfix-2.3.8/.

Les fichiers auxquels la configuration précédente fait référence doivent être copiés. Ils sont joints ci-dessous :

Ils doivent être copiés dans le répertoire /etc/postfix. Ils peuvent être modifiés pour s'adapter à votre expérience (j'ai préservé les commentaires, d'autres indications utiles peuvent être trouvées dans /usr/share/doc/postfix-2.3.8/UCE/postfix-anti-UCE.txt).

Il faut "compiler" certains de ces fichiers pour qu'ils soient opérationnels. Ceci ce faite de la manière suivante :

cd /etc/postfix
postmap client_checks
postmap helo_checks
postmap sender_checks

A chaque modification d'un de ces trois fichiers, il faut le recompiler.

On continue la configuration en changeant l'alias de root. En effet, root ne doit JAMAIS consulter de mail, et les messages qui lui sont destinés (envoyés notamment par des services pour indiquer certains problèmes) doivent être transférés.

/etc/postfix/aliases

...

root: USER

... Où USER est l'identifiant de l'utilisateur que vous utiliserez pour vous connecter (définit dans l'annuaire LDAP).

Pour démarrer POSTFIX au démarrage de l'ordinateur :

chkconfig --add postfix

Ouvrir le port de réception SMTP pour recevoir les mails de l'extérieur

Ne continuer qu'après avoir mis en place les filtres de spams et autres pourriels (c.f. section ci-dessous).

/etc/hosts.allow

smtp: all smtps: all

/etc/shorewall/rules

# MAIL SMTP/ACCEPT all fw #Insecure SMTP SMTPS/ACCEPT all fw #SMTP over SSL (TLS) SMTP/ACCEPT fw all #Insecure SMTP SMTPS/ACCEPT fw all #SMTP over SSL (TLS)

On redémarre les services :

 service shorewall restart

On peut tester la configuration en envoyant un mail vers USER@principal.com et en vérifiant que celui-ci est bien arrivé. N'hésitez pas à utiliser la commande tail /var/log/mail/info ou tail -n100 /var/log/syslog pour voir ce qui se passe dans les fichiers. Souvenez-vous que postgrey est actif, ce qui pourra retarder la livraison. Texte gras

Services de consultation des mails à distance

CYRUS

CYRUS permet quant à lui de gérer la consultation de boites mail depuis les clients (protocoles POP et IMAP). eGroupWare permet de tirer pleinement partie de CYRUS, raison pour laquelle nous allons l'utiliser...

On va maintenant installer CYRUS :

urpmi cyrus-imapd cyrus-imapd-utils cyrus-sasl

Le paquetage est bien configuré à une exception. Dans le fichier /etc/cyrus.conf, il faut remplacer la ligne contenant "lmtpunix" par :

... lmtpunix cmd="lmtpd" listen="/var/spool/postfix/var/lib/imap/socket/lmtp" prefork=1 ...

En effet, par défaut POSTFIX est chrooté sous Mandriva (ce qui est bien plus sécurisant) et le chemin indiqué pour CYRUS à l'installation n'en tient pas compte.

Maintenant, on crée le répertoire :

mkdir -p /var/spool/postfix/var/lib/imap/socket/

On vérifie que les droits des répertoires menant à lmtp sont positionnés en lecture et exécution pour tout le monde (pour traverser un répertoire, il est nécessaire d'avoir les droits d'exécution de celui-ci sous UNIX).

Pour moi, le répertoire /var/spool/postfix/var n'avait pas les bons droits. J'ai donc effectué :

chmod a+rx -R /var/spool/postfix/var

Finalement, on change le propriétaire et les droits du répertoire /var/spool/postfix/var/lib/imap et de ses sous répertoires. On peut également le faire après avoir démarré les serveurs de manière à rendre la socket lmtp accessible que pour CYRUS et POSTFIX.

chown -R cyrus:postfix /var/spool/postfix/var/lib/imap/
chmod 0750 -R /var/spool/postfix/var/lib/imap/

Pour pouvoir administrer IMAP, il faut pourvoir se connecter à CYRUS en utilisant l'outil cyradm. Celui-ci se connecte via une socket à IMAP, ce qui est interdit par le niveau de sécurité élevé de Mandriva. Pour l'autoriser, on édite le fichier /etc/hosts.allow. /etc/hosts.allow

... imap: 127.0.0.1 sieve: 127.0.0.1 ...

Il faut créer un mot de passe pour l'utilisateur système cyrus, sinon on ne peut pas se connecter via cyradm.

passwd cyrus

On démarre le tout :

service cyrus-imapd restart
service saslauthd restart
service postfix restart

Le service d'authentification saslauthd est déjà configuré pour utiliser PAM (qui lui utilise ). Il devrait donc fonctionner à ce stade pour les utilisateurs déclarés au niveau du système et les utilisateurs déclarés dans LDAP.

Maintenant, on va pouvoir créer un utilisateur IMAP :

su - cyrus
cyradm localhost

Le mot de passe demandé est celui saisi ci-dessus pour l'utilisateur cyrus.

Dans la console de cyradm, on va créer un utilisateur USER (le même que celui créer pendant le test de ).

cm user.USER
quit

Pour sortit et revenir à l'identifiant root :

exit

Et on teste :

mail USER
subject : toto
toto
<Ctrl-d>
tail /var/log/mail/info
ll /var/spool/imap/u/user/USER/
less /var/spool/imap/u/user/USER/1.

Le fichier 1. qui apparait dans la liste contient bien le message test envoyé. Voilà, reste maintenant à ouvrir le service à l'extérieur... après avoir sécurisé le tout, bien sûr !

Pour démarrer le service IMAP au boot :

chkconfig --add cyrus-imapd
chkconfig --add saslauthd

DOVECOT

TODO

Sécuriser l'accès à la boite mail avec IMAPS

L'objectif est d'ouvrir IMAPS à l'extérieur et ainsi de permettre la consultation des boites mail par n'importe quel programme supportant ce protocole. Ainsi, les utilisateurs qui manipulent leur boîte mail le font via un tunnel sécurisé ce qui leur permettra d'avoir une certaine intimité ... Le mécanisme d'authentification utilisé sera SASL, que l'on a déjà installé ci-dessus.

Variante CYRUS

Dans un premier temps, on va déplacer les boites aux lettres et la base de donnée d'IMAP dans le répertoire /home/system/imap de manière à disposer de plus d'espace pour les boites mail (je n'ai pas trouvé de méthode pour basculer le répertoire d'un utilisateur dans son répertoire personnel !). Dans le cas contraire, il faudrait réserver plus d'espace pour la partition /var, espace qui ne serait utilisé que très partiellement. De la même manière, nous allons déplacer l'ensemble du répertoire /var/lib/imap qui contient notamment la base de données de CYRUS.

mv /var/lib/imap/ /home/system/
mv /var/spool/imap /home/system/imap/spool

On déclare ce changement et quelques autres changements dans le fichier de configuration /etc/imapd.conf :

configdirectory: /home/system/imap partition-default: /home/system/imap/spool/imap servername:mail.principal.com # Nom du serveur lmtpsocket: /var/spool/postfix/var/lib/imap/socket/lmtp notifysocket: /home/system/imap/socket/notify ... sievedir: /home/system/imap/sieve ... lmtp_downcase_rcpt: yes # convertit les lettres en minuscules ... autocreatequota: 10000000 # Fixe les quotas de boite aux lettres en Ko, ivi envirn 10Go

On veut laisser IMAP accessible en local uniquement, désactiver POP3 et POP3s et ouvrir IMAPS à l'extérieur. Pourquoi ne pas utiliser POP ? Pour des raisons de sécurité d'une part, pour gérer l'archivage des boites mail de manière centralisée sans réplication (via POP), pour laisser les mails accessibles depuis n'importe où sur internet... On laisse SIEVE actif, qui permettra de filtrer et classer les mails. Pour ce faire, on transforme le fichier /etc/cyrus.conf :

... # add or remove based on preferences #imap cmd="imapd" listen="imap" prefork=5 imaplocal cmd="imapd" listen="127.0.0.1:imap" prefork=0 imaps cmd="imapd -s" listen="imaps" prefork=1 #pop3 cmd="pop3d" listen="pop3" prefork=3 #pop3s cmd="pop3d -s" listen="pop3s" prefork=1 sieve cmd="timsieved" listen="sieve" prefork=0 ...

Plus loin dans le même fichier, on modifie la ligne contenant "notify" pour qu'elle ressemble à :

... notify cmd="notifyd" listen="/home/system/imap/socket/notify" proto="udp" prefork=1 ...

On peut sauver le fichier.

On ouvre le parefeu et on autorise les connexions au port IMAPS :

/etc/shorewall/rules

IMAPS/ACCEPT vpn0 fw

/etc/hosts.allow

... # imap:127.0.0.1 sieve: 127.0.0.1 imaplocal:127.0.0.1 imaps:127.0.0.1,192.168.1. ...

Et on redémarre le parefeu :

service shorewall restart

Maintenant, vous pouvez configurer votre logiciel de mail favori pour se loger en temps que USER et vérifier que la boite contient bien un message "toto" envoyé par root... Pour le moment, vou remarquerez que vous devez envoyer votre mot de passe en clair sur le réseau ... On va modifier ce comportement !

Variante DOVECOT

TODO

Quelques mots sur SASL

SASL est un service d'authentification réseau qui prend en compte différents méthodes d'authentification chiffrées ou non. Bien que CYRUS soit initialement configuré pour utiliser SASL avec un chiffrement PLAIN (texte clair), le plugin SASL correspondant n'est pas installé par défaut et le mode de chiffrement PLAIN ne fonctionne pas. Il faut donc installer le plugin :

urpmi libsasl2-plug-plain

On redémarre les services :

service saslauthd restart
service cyrus-imapd restart

Pour installer une autre méthode d'authentification (qui devra être aussi supporté par votre logiciel de mail favori), il faut installer le plugin correspondant (commençant par libsasl2-plug-) et modifier la ligne commençant par sasl_mech_list de /etc/imapd.conf de manière a ajouter l'acronyme de la méthode.

Comme j'utilise IMAPS via un tunnel VPN déjà chiffré, je n'ai pas configuré autre chose que PLAIN. Bon, d'accord, j'utilise DIGEST-MD5 qui me permet une bonne protection, même via un tunnel VPN (paranoïa, quand tu nous tiens ;)). Et puis, pour le moment, SASL utilise PAM pour identifier les utilisateurs qui utilise à son tour LDAP et les fichiers systèmes. J'aimerai que seuls les utilisateurs déclarés dans LDAP puissent s'identifier via SASL. Pourquoi ? Comme ça, je suis sûr que les utilisateurs déclarés au niveau du système n'ont pas accès aux services de la machine (courrier, eGroupWare, etc) et je rend la gestion des utilisateurs homogène. Dans le fichier /etc/sysconfig/saslauthd, on modifie les deux lignes suivantes :

... SASL_AUTHMECH=ldap ... SASL_MECH_OPTIONS=/etc/sasl2/sasl-ldap.conf ...

On va maintenant créer le fichier /etc/sasl2/sasl-ldap.conf qui doit contenir :

ldap_servers: ldap://localhost:389/ ldap_bind_dn: uid=Account Admin,ou=System Accounts,o=default,dc=principal,dc=com ldap_bind_pw: mot de passe de Account Admin ldap_search_base: ou=accounts,o=default,dc=principal,dc=com

Et voilà ! Enfin, presque... En effet, l'ancien administrateur de Cyrus était déclaré comme étant cyrus. Mais celui-ci est inaccessible depuis la nouvelle configuration, car cyrus n'est pas déclaré parmi les comptes gérés sous LDAP. Il faut donc créer un nouvel administrateur (en utilisant phpLDAPAdmin, par exemple) et le déclaré comme administrateur de Cyrus. J'utilise le même administrateur pour eGroupWare et Cyrus, qui s'appellera principal-admin. Une fois le compte créés dans ou=accounts,o=default,dc=principal,dc=com, on modifie /etc/imapd.conf :

... admins: chancelier ...

On redémarre les services :

 service saslauthd restart
 service cyrus-imapd restart

et Voilà !

Maintenant, on va configurer DIGEST-MD5, ce qui demande un peu plus de travail. TODO Nous allons installer plusieurs méthodes d'authentification :

urpmi libsasl2-plug-crammd5 libsasl2-plug-login libsasl2-plug-digestmd5 libsasl2-plug-plain

Et on modifie /etc/imapd.conf pour que IMAP accepte toutes ces méthodes :

... sasl_mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 ...

On redémarre les services :

service saslauthd restart
service cyrus-imapd restart

Filtres de virus, de spam, etc (POSTGREY, AMAVISD-NEW, CLAMAV, SPAMASSASSIN)

Les serveur SMTP comme Postfix sont en proie de manière incessante à de nombreuses attaques ou tentatives de spams, d'envoi de virus, etc. Dans le pire des cas, l'hôte du serveur peut être infecté pour se transformer en machine à spams ... enfin, seulement si l'hôte est un windows ;), ou être utilisé pour relayer des spams et mails au contenu douteux (virus ...).

Pour éviter que les utilisateurs de votre serveur de mail ne soient susceptible d'abandonner celui-ci pour cause de pourrissage de boite, il est nécessaire de mettre en oeuvre des logiciels qui vont permettre de filtrer les spams, de supprimer les virus des mails et de ne pas répondre aux sollicitations non régulières des serveurs SMTP externes. La série de logiciels que nous allons installer pourront répondre à ces exigences.

Installation de POSTGREY

POSTGREY permet de systématiquement demander au serveur source une ré-émission d'un mail avant son traitement par le serveur.

On installe le paquetage :

urpmi postgrey

et tout est fait, enfin presque ... On démarre le serveur et on l'ajoute aux services lancés au démarrage.

service postgrey start
chkconfig --add postgrey

Installation de AMAVISD-NEW et de SPAMASSASSIN

AMAVISD-NEW est une interface puissante entre le serveur de mail (POSTFIX ici) et des scrutateurs de contenu (anti-virus et anti-spams).

On installe le paquetage :

urpmi amavisd-new

Cela installe également SPAMASSASSIN, l'anti-spam de référence.

On décommente les lignes suivantes dans le fichier /etc/mail/spamassassin/local.cf :

... required_score 5.0 ... use_bayes 1 ... bayes_auto_learn 1 ...

Ce ne sont juste que quelques tunings, le tout étant déjà configuré.

Après,il y a une petite erreur de configuration à corriger vu que localdomain n'est pas configuré :

/etc/amavisd/amavisd.conf

... $mydomain='mail.principal.com' ... $mydomain='mail.principal.com' ...

Puis, on démarre le serveur et on l'ajoute aux services lancés au démarrage.

service amavisd start
chkconfig --add amavisd

Echanger des fichiers via le VPN (SAMBA)

On va configurer l'échange de fichiers via le VPN. Ceci va permettre notamment d'utiliser une méthode simple pour copier des fichiers sur le serveur. Ces fichiers pourront être accessibles avec eGroupWare depuis n'importe où sur internet.

Configuration de Samba

On commence par installer le paquetage :

urpmi samba-server samba-smbldap-tools

Puis, on configure le serveur lui-même :

/etc/samba/smb.conf

... workgroup = PRINCIPAL ... netbios name = DEDIE ... # Pas besoin d'imprimer sur le dedie... # printcap name = cups # load printers = yes ... # printcap cache time = 60 ... # printing = cups ... # On autorise les ordinateurs du VPN uniquement hosts allow = 192.168.1.0/24 ... encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd ... unix password sync = Yes ... passwd program = /usr/sbin/smbldap-passwd -o %u ... # synchroniser avec le VPN remote browse sync = 192.168.1.255 ... # S'annoncer aux ordinateurs du VPN remote announce = 192.168.1.255 ... local master = no ... # os level = 33 ... domain master = yes ... # preferred master = yes ... add user script = /usr/sbin/smbldap-useradd -m '%u' delete user script = /usr/sbin/smbldap-userdel '%u' add user to group script = /usr/sbin/smbldap-groupmod -m '%u' '%g' delete user from group script = /usr/sbin/smbldap-groupmod -x '%u' '%g' set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u' add group script = /usr/sbin/smbldap-groupadd '%g' && /usr/sbin/smbldap-groupshow %g|awk '/^gidNumber:/ {print $2}' delete group script = /usr/sbin/smbldap-groupdel '%g' ... add machine script = /usr/sbin/smbldap-useradd -w -d /dev/null -c 'Machine Account' -s /bin/false '%u' ... passdb backend = ldapsam:ldap://127.0.0.1/ ... ldap admin dn = uid=Account Admin,ou=system accounts,o=default,dc=principal,dc=com ldap ssl = no ... ldap port = 389 ldap suffix = o=default,dc=univ-invisible,dc=org ... ldap machine suffix = ou=hosts ldap user suffix = ou=accounts ldap group suffix = ou=groups ldap idmap suffix = ou=idmap ... name resolve order = wins lmhosts bcast ... wins support = yes ... #[printers] # comment = All Printers # path = /var/spool/samba # browseable = no # to allow user 'guest account' to print. # guest ok = yes # writable = no # printable = yes # create mode = 0700 # ===================================== # print command: see above for details. # ===================================== # print command = lpr-cups -P %p -o raw %s -r # using client side printer drivers. # print command = lpr-cups -P %p %s # using cups own drivers (use generic PostScript on clients). # If you install drivers on the server, you will want to uncomment this so # clients request the driver # use client driver = yes ... #[print$] # path = /var/lib/samba/printers # browseable = yes # write list = @adm root # guest ok = yes # inherit permissions = yes ... #[pdf-gen] # path = /var/tmp # guest ok = No # printable = Yes # comment = PDF Generator (only valid users) # printing = bsd #print command = /usr/share/samba/scripts/print-pdf file path win_path recipient IP & # print command = /usr/share/samba/scripts/print-pdf "%s" "%H" "//%L/%u" "%m" "%I" "%J" & # lpq command = /bin/true ... [homes] path = /home/univ-invisible.org/home/%u ...

On pourrait pousser plus avant la configuration pour un serveur d'entreprise, pour qu'il puisse gérer par exemple les profils windows itinérants et la connexion centralisée (type Active Directory). Personnellement, j'arrête ici la comptabilité Windows. Si vous voulez réellement utiliser ce genre de connexion, je vous conseil d'utiliser Linux plutôt que Windows comme client (ce qui sera ben plus robuste). Pour notre application, nous n'en avons pas besoin, bien sûr !

Cela devrait donc être bon pour le serveur.

Configuration des SambaLDAP Tools

Il faut maintenant configurer les smbldap-tools.

/etc/smbldap-tools/smbldap.conf

... sambaDomain="PRINCIPAL" ... ldapTLS="0" ... suffix="o=default,dc=principal,dc=com" ... usersdn="ou=accounts,${suffix}" ... computersdn="ou=hosts,${suffix}" ... groupsdn="ou=groups,${suffix}" ... idmapdn="ou=idmap,${suffix}" ... sambaUnixIdPooldn="sambaDomainName=principal,${suffix}" ... userHome="/home/univ-invisible.org/home/%U" ... mailDomain="principal.com" ...

/etc/smbldap-tools/smbldap_bind.conf

... slaveDN="uid=Account Admin,ou=system accounts,o=default,dc=principal,dc=com" slavePw="SECRET" masterDN="uid=Account Admin,ou=system accounts,o=default,dc=principal,dc=com" masterPw="SECRET" ...

N'oubliez pas de définir le mot de passe de Admin account dans LDAP (avec phpLDAPAdmin par exemple).

LDAP est presque prêt... Il faut, comme noté dans http://wiki.mandriva.com/en/Projects/OpenLDAP_DIT#Samba créer les entrées nécessaires dans l'arborescence LDAP. Cela est effectué à l'aide de l'instruction suivante :

smbldap-populate -a Administrator -k 1000 -m 512

Cette instruction ajoute notamment un élément de type sambaDomain dans la sous arborescence de "o=default, dc=principal, dc=com". Il faut lui ajouter la classe sambaUnixIdPool à l'aide de phpLDAPAdmin. Cette classe permet de stocker le prochain identifiant groupe et le prochain identifiant utilisateur qui seront utilisés par les outils de smbldap. Je fixe initialement ces identifiants à 1500 tous les deux, de manière à laisser le fenêtre de 500 à 999 pour la création de comptes non LDAP, puis de 1000 à 1499 pour la création de comptes eGroupWare.

On peut tester la configuration en ajoutant et supprimant un utilisateur : /usr/sbin/smbldap-useradd test puis, après avoir vérifé que tous fonctionnait (pas d'erreur, l'utilisateur apparait dans LDAP), /usr/sbin/smbldap-userdel test.

Les services Webs de base (EGROUPWARE)

On va maintenant installer EGroupWare 1.4. En fait, on l'a déjà fait dans la section LDAP ci-dessus.

La mise en route ...

En suivant la méthode de téléchargement donnée plus haut, le logiciel doit être localisé dans le répertoire /var/www/html/egroupware. On commence par déplacer ce répertoire de façon à ce qu'il soit situé au même endroit que les autres webapps.

mv /var/www/html/egroupware /var/www/

On créé le fichier /etc/httpd/conf/webapps.d/egroupware.conf qui doit contenir :

Alias /egroupware /var/www/egroupware <Directory /var/www/egroupware> Allow from ALL </Directory> # Uncomment the following lines to force a redirect to a working # SSL aware apache server. This serves as an example. # <IfModule mod_ssl.c> <LocationMatch /egroupware> Options FollowSymLinks RewriteEngine on RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R] </LocationMatch> </IfModule>

Après, on ajuste la configuration de PHP dans le fichier /etc/php.ini :

... mbstring.func_overload = 7 ...

On installe un module PHP qui va permettre de gérer l'IMAP.

urpmi php-imap php-mcrypt

Puis, on redémarre le serveur pour que ces changements soient pris en compte :

service httpd restart

Pour la suite, on suit essentiellement la documentation disponible sur le site http://www.egroupware.org/index.php?page_name=wiki&wikipage=AdminDocs . On commence par ajouter les droits en lecture au dossier :

chmod -R a+r /var/www/egroupware

Puis, on ouvre un navigateur internet pour se rendre à www.principal.com/egroupware/setup .

Vous pouvez lancer le test d'installation. Si vous avez suivi scrupuleusement ce tutoriel, cela n'est pas nécessaire.

De retour au Menu principal de configuration, on passe en évitant les tests.

Là, une page de configuration apparait.

Pour configurer proprement, voici les options que j'ai modifié :

Mot de passe En-tête: mot de passe pour le setup.
Limiter l'accès : 192.168.1.2 (seul mon hôte privilégié pourra accéder au setup d'eGroupWare via le VPN).
Activer MCrypt: Oui
Version de MCrypt: 4.4.8
Vecteur d'initialisation MCrypt: Une longue phrase aléatoire à noter...
Mot de passe d'accès à la base de données: mot de passe d'accès à la base de données.
Identifiant de configuration: principal-admin (par exemple).
Mot de passe de configuration: mot de passe de 'principal-admin'.

Puis, on télécharge le fichier créé header.inc.php et on le copie dans /var/www/egroupware avant d'appuyer sur continuer dans l'explorateur. Certains mots de passe sont contenus dans ce fichier. Il faut donc en sécuriser l'accès :

 chown root:apache /var/www/header.inc.php
 chmod ug=r /var/www/header.inc.php

On peut revenir au navigateur et appuyer sur continuer. Là on se loge à la Page de connexion pour la configuration et l'installation avec l'identifiant principal-admin.

Dans un premier temps, eGroupWare va créer sa base de donnée. Pour ce faire, il a besoin de votrenom de connexion et mot de passe d'administration de votre base MySQL. Saisissez les et creez la base. Puis, revérifier votre installation. Vous pouvez alors Installer toutes les applications. Puis, revérifier votre installation à nouveau.

A ce stade, l' Etape 1 - Gestion simplifiée des applications devrait être terminée. On va maintenant Modifier la configuration actuelle. Une fois arrivé sur la page de configuration, on remarque que les premières options permettent de configurer le répertoire dans lequel les utilisateurs vont stocker leurs documents et le répertoire de sauvegarde d'eGroupWare. On va créer ces répertoires :

mkdir -p /home/principal.com/
mkdir -p /home/principal.com/backup/
chown -R apache:apache /home/principal.com/backup/
chown -R root:apache /home/principal.com/
chmod ug+rw -R /home/principal.com/

On ajoute dans le fichier /etc/security/msec/perm.local la ligne :

... /home/principal.com/ root.apache 771 ...

Les options sont :

Entrez le chemin complet pour les fichiers d'utilisateurs et de groupes.: /home/principal.com/
Entrez le chemin complet vers le répertoire de sauvegarde.: /home/principal.com/backup/

Dans la section Paramètres standard du serveur de messagerie :

Nom d'hôte ou adresse IP du serveur de messagerie POP/IMAP:: 127.0.0.1
Domaine Mail (pour Virtual mail manager)::principal.com
Nom d'hôte ou adresse IP du serveur SMTP::127.0.0.1

Dans la section Authentification / Comptes :

Choisissez quel type d'authentication vous utilisez:: LDAP
Choisissez où vous voulez stocker/récupérer les informations de comptes utilisateurs:: LDAP
ID de compte minimum (p.e. 500 ou 100, etc.) : 1000
ID de compte maximum : 65000
Activer la vérification de la sécurité des mots de passe:: Oui
Les identifiants sont sensibles à la casse:: Oui
Créer automatiquement les enregistrements de comptes pour les utilisateurs authentifiés:: Oui

Je fixe initialement les identifiants utilisateurs à 1000 de manière à laisser le fenêtre de 500 à 999 pour la création de comptes non LDAP.

Dans la section Si vous utilisez LDAP:, si vous utilisez le schéma que j'ai fourni ci-dessus :

Hôte LDAP:: 127.0.0.1
Contexte des comptes LDAP:: ou=accounts,o=default,dc=principal,dc=com
Contexte des comptes LDAP:: ou=groups,o=default,dc=principal,dc=com
Rootdn LDAP (recherche des comptes et modification des mots de passe): uid=EGW Admin,ou=system accounts,o=default,dc=principal,dc=com
Mot de passe root LDAP:: mot de passe pour EGW Admin
Type de cryptage LDAP:: MD5
Voulez-vous gérer les attributs des répertoire d'accueil et du shell de connexion?: Oui
Préfixe par défaut du répertoire d'accueil LDAP (p.e. /home pour /home/utilisateur): /home/users
Shell LDAP par défaut (p.e. /bin/bash): /bin/bash

Dans la section Réglages Mcrypt (nécessite l'extension PHP mcrypt) :

Entrez du texte aléatoirement pour le chiffrement des sessions applicatives:: Un texte aléatoire et long.

On peut alors Enregistrer. On vient de terminer l'étape. Avant de continuer, vous devez renseigner le mot de passe pour l'utilisateur EGW Admin dans le serveur LDAP, crypté à l'aide de MD5. Pour ce faire, vous pouvez utiliser phpLDAPAdmin par exemple.

On peut passer à l'étape Etape 3 - Compte Administrateur.

Identifiant de l'administrateur (login) : L'identifiant de l'administrateur une fois entré dans eGroupWare. Je vous déconseille d'utiliser le même compte pour administrer et utiliser eGroupWare.
Prénom de l'administrateur : Le prénom.
Nom de l'administrateur: Le nom de l'administrateur
Adresse email administrateur: Choisissez une adresse qui n'est pas hbergée sur la machine !!!
Mot de passe du compte administrateur: toto
Réentrer mon mot de passe: toto

On fini par Enregistrer. Les autres étapes sont déjà complètes. Vous aurez éventuellement besoin de revenir à cette page pour ajouter de nouvelles applications. Mais pour le moment, on va se déconnecter et se connecter à eGroupWare en allant dans votre navigateur et en saisissant l'adresse www.principal.com/egroupware .

La première chose à faire est de créer les comptes utilisateurs. Vous pouvez aussi changer le look and feel et sélectionner les applications que vous voulez. Enjoy !

Configuration de sambaadmin dans eGroupWare

Tout l'intérêt de samba va apparaitre avec eGroupWare. En effet, eGroupWare pourra être utilisé pour accéder à des fichiers depuis n'importe quel navigateur internet. Dans les réseaux acceptés, on pourra accéder à ces même fichiers et répertoires à l'aide de Samba, ce qui facilite grandement l'interaction.

De plus, eGroupWare s'occupe de toute la gestion des comptes samba dans LDAP, à condition qu'il est été correctement configuré. Ainsi, lors de la création d'un compte dans eGroupWare, ce compte est automatiquement configuré pour accéder à Samba (définition du mot de passe, etc). De la même manière, on peut configurer les machines hôtes du réseau dans eGroupWare.

Pour configurer eGroupWare (sambaadmin) :

On se connecte à eGroupWare en tant qu'administrateur.
On se rend dans la section Admin, Administration Samba, Configuration du site.

Dans la section Configuration du site, on modifie les entées comme suit :

Chemin pour la commande mkntpwd : /usr/sbin/mkntpwd
Identifiant système (SID) Samba : Entrer le SID retourné par la commande net getlocalsid sur le serveur.
Groupe d'ordinateurs : PRINCIPAL

Vous sauver la configuration...

Maintenant, à chaque création d'utilisateur et changement de mot de passe, la configuration Samba sera effective.

Il faut noter un petit problème que vous rencontrerez : l'utilisation de Samba et du gestionnaire de fichier de eGroupWare n'est pas compatible. En effet, le gestionnaire de fichier utilise les droits d'accès (lecture, écriture, ...) d'Apache, et Samba utilise les droits d'accès de l'utilisateur. Pour remédier au problème, il faudrait que le gestionnaire de fichier ait les droits super-utilisateur ce qui est très dangereux. En effet, on pourrait alors utiliser une éventuelle faille du logiciel pour avoir un accès total à tous les fichiers du serveur. Brrr.

La solution alternative est de forcer le positionnement des droits pour apache dans Samba. TODO

Configuration de felamimail, le gestionnaire de courriel

Il faut se connecter en tant qu'administrateur à eGroupWare, puis se rendre dans Admin->emailadmin->configuration du site.

On choisit le profil par défaut.

Une fenêtre externe s'ouvre dans laquelle il faut saisir les options de configuration en trois parties distinctes :

La partie global :

introduisez votre domaine par défaut : principal.com
Nom de l'entreprise : principal

La partie smtp :

Sélectionner le typedu serveur SMTP : Postfix
Nom ou adresse IP du serveur SMTP : localhost
Port SMTP : 25

Finalement, on configure la partie imap :

Sélectionner le type du serveur IMAP : Cyrus IMAP Server
Nom du serveur IMAP ou adresse IP : localhost
Port IMAP : 25

Activer Sieve : oui
Port Sieve : 2000

Activer la gestion du serveur Cyrus IMAP : oui
Nom d'utilisateur de l'administrateur : Cyrus
Mot de passe : TOTO

L'appliquation est opérationnelle. Quand un nouvel utilisateur se connectera à son mail pour la première fois, sa boite au lettres sera automatiquement créée. Ilest possible de modifier les filtres automatiques de Sieve via eGroupWare sans être expert en programmation. Le tout : un vrai bonheur.

Configuration du carnet d'adresses

Il faut dans un premier temps se connecter en tant qu'administrateur. Puis, il faut se rendre dans Admin->Carnet d'adresse->Configuration du site.

De là, on règle les options de la manière suivante :

Sélectionnez où vous voulez stocker/réceptionner les contacts : LDAP
Hôte LDAP pour les contacts : localhost
Contexte LDAP pour les contacts : o=default,dc=principal,dc=com

La gestion des contacts fonctionne. Vous pouvez tester la configuration ... Ah oui, j'oubliais, vous aurez besoin de configurer pour chaque utilisateur le book dans lequel les contacts seront créés par défaut. De plus, le nom de famille d'un contat doit être obligatoirement saisi.

Mises à jour périodiques de eGroupware

Rien de plus simple ... On édite le fichier /etc/cron.daily/system_update et on rajoute le texte :

... cd /var/www/egroupware ; svn update * ...

That's done.

Aller plus loin

Ceci n'est qu'une ébauche de ce que l'on peut faire avec eGroupWare. Vous pouvez faire bien plus, comme installer un gestionnaire d'album photo (gallerie2), gérer les mails, contacts et rendez-vous à distance via kontact ou thunderbird, synchroniser sur votre palm ou pocket pc, etc.

Serveur de fichiers proftpd

Un lien intéressant vers le site de païou. Pas besoin de réinventer la roue.

La téléphonie (ASTERIX, TEAMSPEEK)

Fonctionnement courant

Ajouter un site

Sauvegarder et restaurer le serveur

Installer un serveur dédié

De Wiki de la communauté Mandriva.

Sommaire

Cas d'utilisation du serveur

Installation et configuration du système de base

Installation du système

Option Raid

Partitionnement d'un serveur

Mise à jour depuis une Mandriva 2006

Le système minimal

Mise à jour de la distribution

Mise à jour automatique

Quelques paquetages bien utiles avant de continuer

Changer le noyau (kernel)

Sécurité, sécurité ...

Sécuriser ssh

MSEC et autres éléments de sécurité

Configurer le parefeu (firewall SHOREWALL)

Mettre en place les quotas

Détecter les rootkits

Installer un système de détection d'intrusion (IDS - Prelude ou Snort)

Installer Prelude

Installer Prelude-Manager

Installer Prelude-LML

Installer Snort

Installer Samhain

Installer Sancp

Aller plus loin

Création d'un répertoire système

Configuration du réseau

Configuration du réseau et du nom de machine

Configuration du service de réseau privé virtuel (VPN IPSEC)

Service de synchronisation d'horloge (NTPD) : toujours à l'heure

Configuration du serveur de noms (DNS - BIND)

Service LAMP

Configuration du serveur HTTP (Apache) et de PHP

Configuration du service de base de donnée (MySQL)

Installer MySQL

Installer phpMyAdmin

La fréquentation de votre site (AWstats)

Installer Prewikka

Configuration du service d'annuaire (LDAP)

Installation et configuration du serveur OpenLDAP

Installer PhpLDAPAdmin

Régler l'identification système via LDAP (PAM)

Configuration du service Mail

La base : Serveur de Transport vs. Serveur de consultation (SMTP - IMAP - POP3)

Serveur de transport et réception des courriels POSTFIX

Installation de POSTFIX

Ouvrir le port de réception SMTP pour recevoir les mails de l'extérieur

Services de consultation des mails à distance

CYRUS

DOVECOT

Sécuriser l'accès à la boite mail avec IMAPS

Variante CYRUS

Variante DOVECOT

Quelques mots sur SASL

Filtres de virus, de spam, etc (POSTGREY, AMAVISD-NEW, CLAMAV, SPAMASSASSIN)

Installation de POSTGREY

Installation de AMAVISD-NEW et de SPAMASSASSIN

Echanger des fichiers via le VPN (SAMBA)

Configuration de Samba

Configuration des SambaLDAP Tools

Les services Webs de base (EGROUPWARE)

La mise en route ...

Configuration de sambaadmin dans eGroupWare

Configuration de felamimail, le gestionnaire de courriel

Configuration du carnet d'adresses

Mises à jour périodiques de eGroupware

Aller plus loin

Serveur de fichiers proftpd

La téléphonie (ASTERIX, TEAMSPEEK)

Fonctionnement courant

Ajouter un site

Sauvegarder et restaurer le serveur

Affichages

Outils personnels

Navigation

Rechercher

Boîte à outils