\documentclass[a4paper,11pt]{report} \input{../includes/headers_global.tex} \def\sitename{Debian GNU/Linux } \def\shorttitre{Securité} \def\titre{Debian Lenny - Éléments de sécurisation} \def\autheur{Matthieu Vogelweith} \def\subject{Éléments de sécurisation d'un serveur Debian GNU/Linux 5.0 (Lenny)} \def\keywords{Debian, Linux, Matthieu, Vogelweith, Serveur, Lenny, Kernel, chkrootkit, lynis, rkhunter, security} \input{../includes/headers.tex} \begin{document} \renewcommand{\bibname}{R\'ef\'erences} \begin{titlepage} \maketitle \end{titlepage} \chapter*{Résumé} \input{../includes/licence.tex} \tableofcontents \chapter{Les bases} \section{Un système minimal} - Le script necessaire installé. \section{Système de messagerie} - reception des alertes mails \section{Pare feu} En complément des éléments indiqués dans cette page, il est indispensable de protéger la machine par un pare feu adapté aux services qui tournent sur la machine. La mise en place d'un pare feu basé sur Shorewall est détaillée dans le document suivant : \cite{firewall}. \chapter{Surveillance des journaux} \section{Logcheck} La surveillance des journaux est essentielle pour apprécier l'état d'un système. Cette surveillance est par contre très complexe dans le sens ou il faut arriver à détecter simplement les messages critiques des messages d'informations. Pour cela il existe plusieurs outils qui vont "épurer" les journaux automatiquement pour ne remonter que les informations qui nécessite une attention particulière. Parmi eux on peut distinguer Logcheck \cite{logcheck} qui est à la fois très puissant et très souple dans sa configuration. L'installation se fait avec la commande suivante : \vspace{1em} \begin{lstlisting} # aptitude install logcheck logcheck-database \end{lstlisting} \vspace{1em} Le paquet supplémentaire \textbf{logckeck-database} installé avec la commande ci-dessus fournit un ensemble de règles permettant de filtrer les journaux. Pour chaque service, il fournit une ou plusieurs expression régulières qui excluent les informations "non critique" des journaux. \section{Personnalisation} Il est tout a fait possible d'ajouter de nouvelles règles pour affiner le traitement des journaux. Par exemple, on peut estimer qu'il n'est pas intéressant de recevoir les lignes indiquant que Shorewall a "DROPPER" un paquet. Pour cela, il suffit de créer un fichier /etc/logcheck/ignore.d.server/shorewall contenant la ligne suivante : \vspace{1em} \begin{lstlisting} ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel: \[[ 0-9\.]*\] Shorewall:[[:alnum:]]+:DROP:IN= \end{lstlisting} \vspace{1em} Ainsi, les journaux seront conservés dans le syslog mais ne seront pas reportés par logcheck dans l'alerte. Par ailleurs, voici un fichier contenant quelques règles utiles pour affiner le traitement des journaux que l'on peut mettre dans un fichier /etc/logcheck/ignore.d.server/custom : \cite{logcheck_custom} \chapter{Les mises à jour de sécurité} \section{Mises à jour APT} Dans /etc/apt/sources.lists : \vspace{1em} \begin{lstlisting} # Security updates deb http://security.debian.org/ lenny/updates main contrib non-free \end{lstlisting} \vspace{1em} Faire des mises à jour journalières, aidé par exemple de cron-apt. \section{Checkrestart} Après une mise à jour de sécurité, il est important de vérifier que tous les services impactés par ces mises à jour ont bien été redémarrés. Lors de la mise à jour d'une library par exemple, il est possible que des services utilisent encore l'ancienne version de la library jusqu'a ce qu'ils soient redémarrés. Pour détecter ce type de problèmes, le paquet \textbf{debian-goodies} fournit l'utilitaire \textbf{checkrestart} qui va rechercher tous les services utilisant une version obsolète d'un librairie : \vspace{1em} \begin{lstlisting} # aptitude install debian-goodies # checkrestart Found 12 processes using old versions of upgraded files (1 distinct program) (1 distinct packages) Of these, 1 seem to contain init scripts which can be used to restart them: The following packages seem to have init scripts that could be used to restart them: apache2-mpm-prefork: 27676 /usr/sbin/apache2 31279 /usr/sbin/apache2 30910 /usr/sbin/apache2 5565 /usr/sbin/apache2 2047 /usr/sbin/apache2 26909 /usr/sbin/apache2 25558 /usr/sbin/apache2 25991 /usr/sbin/apache2 30891 /usr/sbin/apache2 30628 /usr/sbin/apache2 31289 /usr/sbin/apache2 31288 /usr/sbin/apache2 These are the init scripts: /etc/init.d/apache2 restart \end{lstlisting} \vspace{1em} Dans l'exemple ci-dessus, checkrestart a détecté que Apache utilise une version obsolète d'un fichier mis à jour par APT. Après un redémarrage d'Apache, le commande reportera : \vspace{1em} \begin{lstlisting} # checkrestart Found 0 processes using old versions of upgraded files \end{lstlisting} \vspace{1em} \section{Cron-apt} Cron-APT est un outil qui permet de mettre à jour la liste des paquets disponibles et de télécharger les paquets à mettre à jour. L'outil permet d'exécuter de manière automatique n'importe qu'elle commande apt-get ou aptitude et de fournir un rapport sur l'exécution de la commande. Attention, utiliser cron-apt pour installer automatiquement les mises à jour est très dangereux ! La configuration de base permet de mettre à jour la liste des paquets toutes les nuits et de télécharger les nouveaux paquets de manière a accélérer la procédure de mise à jour qui sera faite manuellement par un administrateur. L'installation se fait tout simplement avec la commande suivante : \vspace{1em} \begin{lstlisting} # aptitude install cron-apt \end{lstlisting} \vspace{1em} Par défaut, cron-apt fait déjà bien le boulot mais on peut modifier un peu la configuration pour utiliser \textbf{aptitude} au lieu de \textbf{apt-get} par exemple. Toute la configuration se fait dans le fichier /etc/cron-apt/config : \vspace{1em} \begin{lstlisting} APTCOMMAND=/usr/bin/aptitude MAILTO="root" MAILON="upgrade" \end{lstlisting} \vspace{1em} De cette façon, l'utilisateur \textbf{root} recevra un mail à chaque fois qu'un paquet dispose d'une mise à jour dans les dépôts officiels ou de sécurité. \section{La liste de diffusion Security} Cron-APT permet d'être notifié à chaque nouvelle mise à jour disponible. Si l'on désire être prévenu en temps réél et obtenir plus de détails sur les mises à jours, un bon point de départ est de s'inscrire sur le liste de diffusion \textbf{debian-security-announce} \cite{debianSecurityAnnounce}. \chapter{Intégrité du système} \section{Présentation} \section{debsums} \vspace{1em} \begin{lstlisting} # aptitude install debsums \end{lstlisting} \vspace{1em} \vspace{1em} \begin{lstlisting} # debsums_init \end{lstlisting} \vspace{1em} \vspace{1em} \begin{lstlisting} # debsums | grep -v OK \end{lstlisting} \vspace{1em} Lancement en cron.daily ? \section{rkhunter} - Installation de rkhunter \cite{rkhunter} \vspace{1em} \begin{lstlisting} # aptitude install rkhunter \end{lstlisting} \vspace{1em} - Modification de la configuration pour correspondre à la configuration SSH réalisée ci-dessous. Dans /etc/rkhunter.conf : \vspace{1em} \begin{lstlisting} ALLOW_SSH_ROOT_USER=no \end{lstlisting} \vspace{1em} - Mise à jour des bases \vspace{1em} \begin{lstlisting} # rkhunter --update # rkhunter --propupd \end{lstlisting} \vspace{1em} \section{integrit} - Installation de integrit \cite{integrit} \vspace{1em} \begin{lstlisting} # aptitude install integrit \end{lstlisting} \vspace{1em} - Configuration dans /etc/integrit/integrit.conf \vspace{1em} \begin{lstlisting} root=/ known=/var/lib/integrit/known.cdb current=/var/lib/integrit/current.cdb !/dev !/sys !/home !/proc !/tmp !/var \end{lstlisting} \vspace{1em} - Initialisation : \vspace{1em} \begin{lstlisting} # integrit -C /etc/integrit/integrit.conf -u # mv /var/lib/integrit/current.cdb /var/lib/integrit/known.cdb # integrit -C /etc/integrit/integrit.conf -c \end{lstlisting} \vspace{1em} - Dans /etc/integrit/integrit.debian.conf \vspace{1em} \begin{lstlisting} CONFIGS="/etc/integrit/integrit.conf" \end{lstlisting} \vspace{1em} Cron executée tous les jours. \chapter{Sécurité des services} \section{Généralités} De manière générale, tous les services qui offrent un accès extérieur doivent être l'objet d'une attention particulière. L'idée première est de ne laisser transiter aucune information sensible en clair sur le réseau. Pour cela, la plupart des services proposent maintenant un support SSL qui permet de chiffrer les communications et de s'assurer de l'identité du service distant. Par ailleurs, les différents services offrent souvent la possibilité d'être exécutés avec un utilisateur dédié. Cette fonctionnalité permet de cloisonner chaque service et doit être utilisée aussi souvent que possible pour limiter la portée d'une eventuelle corruption. \section{SSH} Le serveur \textbf{ssh} permet d'obtenir un contrôle total sur une machine et est un outil quasiment indispensable pour administrer les serveurs distants. Les possibilités offertent par ce service étant très vastes, une attention particulière doit être accordée lors de sa configuration. Initialement cette configuration est déjà complètement fonctionnelle, on peut simplement modifier quelques options pour améliorer la sécurité dans le fichier /etc/ssh/sshd\_config : \vspace{1em} \begin{lstlisting} PermitRootLogin no X11Forwarding no AllowUsers admin \end{lstlisting} \vspace{1em} Bien entendu, les modifications seront prises en compte après un re-démarrage du service : \vspace{1em} \begin{lstlisting} # /etc/init.d/ssh restart \end{lstlisting} \vspace{1em} Notons qu'avec la configuration ci-dessus, seul l'utilisateur admin pourra se connecter en SSH. Afin de lutter de manière efficace contre les attaques en "brute force", il est également possible de limiter le nombre de connexion SSH réalisée par secondes. Cette configuration doit être réalisée avec une macro shorewall commen indiqué dans le document dédié à ce service \cite{firewall}. \clearpage \nocite{*} \bibliographystyle{unsrt} \bibliography{\jobname} %\ifpdf %\else %\chapter{Vos commentaires} %\fi \end{document}