Installer un serveur dédié

Un article de Wiki de la communauté Mandriva.

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 tutorial 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 tutorial 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 tutoriaux 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 tutorial 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 tutorial, qui pourrait laisser le système vulnérable à certaines attaques. Donc, n'utiliser ce tutorial 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 La téléphonie (ASTERIX, TEAMSPEEK)
13 Fonctionnement courant
- 13.1 Ajouter un site
- 13.2 Sauvegarder et restaurer le serveur

[modifier] 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...).

[modifier] Installation et configuration du système de base

[modifier] 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/en/Tools/urpmi .

[modifier] Option Raid

TODO

[modifier] 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.

[modifier] 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.

[modifier] 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.

[modifier] 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

[modifier] 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

[modifier] Quelques paquetages bien utiles avant de continuer

urpmi bash-completion 
urpmi vim-enhanced

[modifier] 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.

[modifier] 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...

[modifier] 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.

[modifier] 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

[modifier] 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

[modifier] 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

[modifier] 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.

[modifier] 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é.

[modifier] 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

[modifier] 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 ...

[modifier] 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

[modifier] 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

Finalement ...

service snort restart
chkconfig --add snort

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

[modifier] 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

Finalement ...

service samhain restart
chkconfig --add samhain

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

[modifier] 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

Finalement ...

service sancp restart
chkconfig --add sancp

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

[modifier] 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 :) !

[modifier] 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

[modifier] Configuration du réseau

[modifier] 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

[modifier] 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

[modifier] 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

[modifier] 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é.

[modifier] Service LAMP

[modifier] 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

[modifier] Configuration du service de base de donnée (MySQL)

[modifier] 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

[modifier] 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)

[modifier] 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...

[modifier] 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 !

[modifier] 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 tutoriaux comme http://en.tldp.org/HOWTO/LDAP-HOWTO/ ou http://julp.developpez.com/freebsd/authentification-ldap/ pour pleinement comprendre le fonctionnement de LDAP. LDAP

[modifier] 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

[modifier] 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.

[modifier] 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 !

[modifier] Configuration du service Mail

[modifier] 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.

[modifier] Serveur de transport et réception des courriels POSTFIX

[modifier] 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