Guillaume Auffray Nicolas Palix Samuel Serre. TP Intégrité des services et des données

Transcription

1 EI5 IR Guillaume Auffray Nicolas Palix Samuel Serre TP Intégrité des services et des données

2 1. Présentation L'objectif de ce TP est de manipuler des outils de vérification d'intégrité des services et des données. Le TP est organisé en deux parties : - Manipulation de l'outil Tripwire qui permet de gérer une base de données de signatures de fichiers afin de vérifier si ceux-ci n'ont pas été corrompus. - Manipulation de l'outil rdist qui permet de distribuer des données et les synchroniser sur plusieurs machines 2. Tripwire 2.1. Installation TRIPWIRE Voici la procédure à suivre pour installer tripwire sur une distribution DEBIAN : Mettre à jour la liste des sources pour la commande apt-get : Fichier /etc/apt/source.list Ajouter les lignes suivantes : deb unstable/non-us main deb-src unstable/non-us main Lancer les commandes suivantes : apt-get update apt-get install tripwire Les différents fichiers installés se situent dans les répertoires suivants : Fichiers de configuration /etc/tripwire/ Binaires de tripwire /usr/sbin/ Base de donnée /var/lib/tripwire/ (Il est recommandé de la stocker sur un média en RO) Documentation /usr/share/doc/tripwire/readme.debian Pour solliciter l aide en ligne du logiciel : tripwire -help Installer Tripwire 2.2. Configuration TRIPWIRE./twinstall.sh tripwire -init rm txcfg.txt twpol.txt (optionnel sur DEBIAN) Configurer Tripwire 2.3. Exporter les fichiers de configuration et de règles Génération du fichier de configuration : twadmin -print-cfgfile > twcfg.txt Génération du fichier de règles : twadmin -print-polfile > twpol.txt Générer les fichiers de configuration et de règles Tripwire ESISAR 2/9

3 2.4. Modifier la configuration et les politiques de vérification Objectif : Définir quels fichiers Tripwire doit vérifier Voila la procédure à adopter : 1. Extraire les fichiers de configuration et de politique de vérifications en fichier texte twadmin -print-cfgfile > twcfg.txt twadmin -print-polfile > twpol.txt 2. Modifier le fichier twpol.txt et/ou twcfg.txt 3. Re-signer les fichiers modifiés (prise en compte des modifications) twdmin -create-cfgfile -cfgfile /etc/tripwire/tw.cfg -site-keyfile site.key /etc/tripwire/twcfg.txt twadmin -create-polfile -cfgfile /etc/tripwire/tw.cfg -site-keyfile site.key /etc/tripwire/twpol.txt 4. Réinitialiser la base de données tripwire -init 2.5. Vérification de l intégrité des fichiers Objectif : Vérifier si des fichiers ont été modifiés depuis la prise du dernier snapshot. Commande : tripwire - check Il est également possible de faire une vérification d intégrité limitée à quelques fichiers : 1. Si le fichier de politique de vérifications contient une règle spécifique : ( ) { } rulename = "ma_regle", severity = 50 /sbin/e2fsck -> $(SEC_CRIT); /bin/cp -> $(SEC_CRIT); /usr/tmp -> $(SEC_INVARIANT); /etc/csh.cshrc -> $(SEC_CONFIG); ESISAR 3/9

4 2. On peut utiliser l'une des commandes suivantes: tripwire --check /bin/cp /usr/tmp Utilisation d'une règle spécifique tripwire --check --rule-name "ma_regle" Avec les règles dont la sécurité est > 40 tripwire --check --severity 40 Exercices : - Ajoutez un fichier fichier.txt dans le répertoire /tmp - Ajoutez une règle pour ajouter ce fichier dans la base de données des signatures - Initialisez la base (voir section 2.4) - Générez le premier rapport - Modifiez le fichier /tmp/fichier.txt - Relancez la commande de vérification d'intégrité des fichiers et noter les différences - Remettez à jour la base pour prendre en compte ces modifications (section 2.4) - Relancez une nouvelle fois la génération du rapport. Que constate-t-on? 2.6. Vérification de fichiers en lecture seule Il peut être judicieux de stocker la base de données tripwire sur un média en lecture seule, ceci dans un but sécuritaire. Personne ne pourra alors venir modifier cette base de données. Remarque : Avant de copier tripwire sur CDROM, il faut être certain que le binaire est lié à ses librairies statiquement et non dynamiquement (il ne dépend alors d'aucune librairie partagée qui aurait pu être modifiée par une personne mal intentionnée). Cette vérification peut se faire avec la commande suivante : ldd /usr/sbin/tripwire Rédiger la procédure à suivre. 1. Copier les clés locales et distantes et le binaire tripwire sur le média en question. 2. Générer le fichier de configuration en mode texte (voir la section correspondante). 3. Editer le fichier de configuration et modifier les paramètres suivants: ROOT=/mnt/cdrom SITEKEYFILE=/mnt/cdrom/site.key LOCALKEYFILE=/mnt/cdrom/local.key 4. Signer le fichier de configuration tripwire (voir la section correspondante) 5. Régénérer la base de données tripwire sur le CDROM (par exemple) /mnt/cdrom/tripwire --init 6. Effectuer une vérification ESISAR 4/9

5 2.7. Vérification d'intégrité distante Pour améliorer la sécurité, il peut être intéressant de copier les fichiers importants de tripwire sur une autre machine non reliée au réseau physiquement. Ceci permettrait d'éviter qu'une personne malveillante ne modifie ces fichiers là. Pour cela, il faut : Stocker les clés et le binaire tripwire sur cette machine distante (utiliser rsync pour vérifier que l'original et la copie sont identiques, ceci par un tunnel sécurisé ssh). Remarque : Il n'est pas nécessaire de stocker la base de données sur la machine distante. La sécurité est assurée par la clé locale stockée sur la machine distante. - Utilisez l'espace libre du disque pour créer une nouvelle partition - Copiez la base de données tripwire sur cette nouvelle partition - Utiliser la commande chattr pour verrouiller la base en lecture seule. - Vérifiez que tout fonctionne en effectuant une vérification d'intégrité Le code à exécuter sur la machine locale est le suivant : #!/bin/sh REMOTE_MACHINE=trippy RSYNC='/usr/bin/rsync -a --progress --rsh=/usr/bin/ssh' SAFE_DIR=/usr/local/tripwire/${REMOTE_MACHINE} VITAL_FILES="/usr/sbin/tripwire /etc/tripwire/site.key /etc/tripwire/${remote_machine}-local.key" mkdir $SAFE_DIR for file in $VITAL_FILES do $RSYNC ${REMOTE_MACHINE}:$file $SAFE_DIR/ done Vérifier que la copie de ces trois fichiers s est bien déroulée (machine distante) : #!/bin/sh cd $SAFE_DIR rm -f log for file in $VITAL_FILES do base=`basename $file` $RSYNC -n ${REMOTE_MACHINE}:$file. fgrep -x "$base" >> log done if [ -s log ] ; then echo 'Security alert!' else ssh ${REMOTE_MACHINE} -l root /usr/sbin/tripwire --check fi ESISAR 5/9

6 3. Rdist 3.1. Présentation de Rdist Rdist est un programme ayant pour but de maintenir des copies identiques de fichiers sur plusieurs machines. Il préserve le groupe, le propriétaire, le mode et la date de modification des fichiers et peut mettre à jour les programmes qui sont en cours d exécution. Rdist lit les commandes du fichier intitulé «distfile» pour faire les mises à jour des fichiers et/ou des répertoires. Si «distfile» est -, l entrée standard est utilisé Installation La manipulation est simple, il suffit juste d utiliser la commande : # apt-get install rdist 3.3. Commandes essentielles de Rdist -F Do not fork any child rdist processes. All clients are updated sequentially. -f distfile Set the name of the distfile to use to be distfile. If distfile is specified as ``-'' (dash) then read from standard input (stdin). -l logopts Set local logging options. See the section MESSAGE LOGGING for details on the syntax for logopts. -L logopts Set remote logging options. logopts is the same as for local logging except the values are passed to the remote server (rdistd). See the section MESSAGE LOGGING for details on the syntax for logopts. DISTFILES The distfile contains a sequence of entries that specify the files to be copied, the destination hosts, and what operations to perform to do the updating. Each entry has one of the following formats. <variable name> `=' <name list> [ label: ] <source list> `->' <destination list> <command list> [ label: ] <source list> `::' <time_stamp file> <command list> The first format is used for defining variables. The second format is used for distributing files to other hosts. The third format is used for making lists of files that have been changed since some given date. The source list specifies a list of files and/or directories on the local host which are to be used as the master copy for distribution. The destination list is the list of hosts to which these files are to be copied. Each file in the source list is added to a list of changes if the file is out of date on the host which is being updated (second format) or the file is newer than the time stamp file (third format). The command list consists of zero or more commands of the following format. `install' <options> opt_dest_name `;' `notify' <name list> `;' `except' <name list> `;' `except_pat' <pattern list>`;' `special' <name list> string `;' `cmdspecial' <name list> string `;' ESISAR 6/9

7 3.4. Prise en main de Rdist Objectif : Prise en main basique de Rdist avec 2 ordinateurs - Créer un fichier de test sur le serveur - Installer ce fichier de test sur le client en utilisant rdist - Modifier le fichier de test - Lancer la commande d'installation - Relancer la commande et comparer les résultats On créer le fichier de test /root/test (commande touch par exemple). L installation du fichier de test sur le poste client se fait à l aide de la commande : # rdist -P /usr/bin/ssh -F -f <distfile> Le fichier <distfile> contient par exemple les instructions suivantes : HOSTS = (barcelone milan sparte) FILES = (/root/test) inst: ${FILES} -> ${HOSTS} install; On modifie le fichier de test : # cat > test <<EOF Ceci est un test! EOF Puis on relance la commande d installation. On constate que le fichier a été copié sur le client. On relance la commande d installation. On constate que le fichier n est plus mis à jour car il n a pas été modifié Diffusion des mots de passe & des comptes Objectif : Diffuser les mots de passe et les comptes sur les machines clientes du réseau - Créer un fichier de distfile <comptes> sur le serveur - Ce fichier doit déployer les fichiers /etc/passwd et /etc/shadow vers le client - Il faut écraser la copie du client si elle diffère. On créer le fichier de test /root/comptes qui contient les lignes suivantes : HOSTS = (barcelone milan sparte) FILES = (/etc/passwd /etc/shadow) inst: ${FILES} -> ${HOSTS} install; L installation des fichiers sur le poste client se fait à l aide de la commande : # rdist -P /usr/bin/ssh -F -f /root/comptes ESISAR 7/9

8 3.6. Sécurisation de la procédure avec SSH Objectif : On veut supprimer la demande de mot de passe mais ne pas utiliser le fichier /etc/hosts.equiv. On veut pour cela utiliser le système de clé fournit par SSH. On utilisera donc une clé privée sans mot de passe. - Créer une clé pour SSH et la définir comme clé d'identité pour le compte administrateur - Déployer la clé publique sur le client (Utiliser Rdist!) - Modifier la configuration du client pour prendre en compte cette clé - Redémarrer le service SSH de la machine cliente On génére la paire de clés avec la commande ssh-keygen t dsa On modifie la configuration du serveur ssh sur les clients en ajoutant la ligne : AuthorizedKeysFile %h/.ssh/id_dsa.pub On modifie la configuration du client ssh sur le serveur en ajoutant la ligne : IdentityFile ~/.ssh/id_dsa On utilise la commande rdist avec le fichier suivant pour déployer la clé publique et la configuration HOSTS = (barcelone milan sparte) FILES = (/root/.ssh/id_dsa.pub /etc/ssh/sshd_config) inst: ${FILES} -> ${HOSTS} install; On utilise la commande /etc/init.d/ssh restart pour le redémarrage du service 3.7. Amélioration Objectif : On veut à présent limiter l'exécution de Rdist lorsque la copie du serveur a été modifiée (par la commande passwd par exemple). On utilise pour cela la troisième syntaxe du distfile présentée dans la man page. - Ecrire une nouvelle section (label) dans le distfile pour vérifier les modifications de fichier /etc/passwd - Ecrire un script sur le serveur qui lance la section de test puis la section de distribution si le fichier a été modifié. - Configurer Rdist pour la gestion des logs en utilisant syslogd. On crée un fichier time stamp, touch /root/passwd-stamp On ajoute la ligne suivant au fichier distfile comptes check: /etc/passwd :: /root/passwd-stamp La vérification des modifications du fichier sur le poste serveur se fait à l aide de la commande : # rdist -P /usr/bin/ssh -F -f /root/comptes check On ajoute la gestion du journal avec l ajout de l option suivante : # rdist l syslog=all -P /usr/bin/ssh -F -f /root/comptes check Exercice facultatif : - Mettre en place le script en tâche de fond avec le gestionnaire cron ESISAR 8/9

9 3.8. Déploiement dynamique d'applications Objectif : On veut que les modifications majeures sur les comptes utilisateurs (ajout et suppression) soient prise en compte par kdm. - Créer un nouveau compte sur le serveur dans le groupe users - Modifier le distfile de la question 3.5 pour que la commande "/etc/init.d/kdm restart 2> /dev/null &" soit exécutée lorsque le fichier /etc/passwd est mis à jour. - Tester votre nouveau fichier distfile et observer le client Remarque : Prendre soin que personne n'est connecté sur la console graphique. On ajoute un nouveau compte : adduser ingroup users test On ajoute la ligne suivante à la fin du fichier distfile comptes précédent special /etc/passwd "/etc/init.d/kdm restart 2> /dev/null &"; On observe le redémarrage du gestionnaire de login et la prise en compte du nouveau compte. Ceci n est le cas que si le fichier passwd a été mis à jour. Toutes les sessions ouvertes sont closes Pour occuper les trop rapides Objectif : On veut gérer un cluster de serveur Apache. - Installer Apache sur le client - Créer un fichier distfile pour exporter le site et la configuration du serveur - Redémarrer le service Apache en cas de modification de la configuration On crée le fichier distfile suivant : HOSTS = (barcelone milan sparte) FILES = (/etc/apache/ /var/www/) inst: ${FILES} -> ${HOSTS} install; special /etc/apache/httpd.conf "/etc/init.d/apache restart 2> /dev/null &"; 4. Liens Pour Tripwire : deb unstable/non-us main deb-src unstable/non-us main Pour Integrit : Pour AIDE : ESISAR 9/9