Forums d'entraide informatique - Astuces - Conseils

Surveillez l'activité de
votre serveur
La mise en œuvre d'une machine serveur dédiée sur Internet peut paraître aisée avec les distributions modernes et facile à maintenir. Cependant, personne n'est à l'abri de
problèmes, en particulier lorsqu'une machine est publiquement accessible par des milliers d'utilisateurs potentiels. Un système Unix comme GNU/Linux dispose d'un mécanisme puissant et fiable pour garder une trace de toutes activités sur une machine : les journaux système.
Installé avec n'importe quelle distribution, le service sysklogd permet d'enregistrer l'activité sur une machine, de manière organisée et grandement configurable. sysklogd est composé de deux pro- grammes démons. Le premier, syslogd, est chargé de la gestion des requêtes qui lui sont envoyées par toutes les applications du système. Ce démon est une version évoluée de l'utilitaire Berkeley du même nom. Le second, klogd est pour sa part chargé de l'aspect "Noyau" ; il gérera tous les messages en provenance du programme le plus important du système et celui qui a le plus de droit sur la machine : le noyau Linux.
Les deux démons fonctionnent de concert sur un système GNU/Linux. Nous ne parlerons ici que de syslogd, car ce qui nous occupe est principalement le fonctionnement des applications serveurs (Apache, Exim, qpopper, proftpd. etc.). Toutes ces applications utilisent syslogd pour archiver les infor- mations sur ce qu'elles font, comment elles le font et qui leur demande de le faire. C'est dans les journaux de syslogd, les syslogs que vous trouverez tout cela.
Attention. klogd n'en est pas moins important, car étant donné les informations qu'il manipule, vous avez tout intérêt à le surveiller. Cela aussi bien sur une machine serveur que cliente. klogd archive les messages en fonction de leur priorité. Ces priorités vont de 7 à 0 et tout ce qui est d'une priorité entre 3 et 1 est très important. Enfin, la priorité 0 est utili- sée pour les situations véritablement critiques. Dans ce cas, l'utilisateur, même averti, se contentera d'une prière pour St Kernel et sera sans doute forcé de faire usage de l'interrupteur d'alimentation. Les messages de klogd après traitement sont envoyés à syslogd.
syslogd utilise deux types de catégorie pour désigner les informations. Dans un premier temps, une infor- mation est désignée par sa priorité ou, en d'autres termes, son importance (ici listée par ordre croissant) :
debug : simples informations de débogage info : messages d'informations simples
notice : messages significatifs mais "normaux" warning : messages d'alerte, quelque chose de louche se passe
error : messages d'erreur
crit : une situation critique se présente
alert : messages d'alerte, ici l'intervention humaine est demandée, et le plus rapidement possible
emerg : le système devient instable/inutilisable
En plus d'un classement par priorité, syslogd orga- nise les messages en fonction de leur type. On parle alors de "facilités" fournies par syslogd. Voici les facilités disponibles :
•    authpriv pour tout ce qui traite de la sécuri- té et de l'authentification
•    cran pour ce qui est en rapport avec les tâches régulières (système cron et at)
•    daemor_ pour les messages provenant des démons en fonctionnement
•    kern pour les messages du kernel (provenant de klogd)
•    local() à local7 pour les informations locales. On peut parler de facilité personnalisable pour les applications locales du système.
•    ipr pour ce qui est relatif au système d'impres- sion
•    mail pour ce qui concerne les mails
•    news pour ce qui est en rapport avec les news USENET
•    syslog pour les informations relatives au fonctionnement de syslogd lui-même
•    user pour les informations génériques sur les utilisateurs
•    uucp pour ce qui concerne le système UUCP
Une fois cette double classification assimilée, vous serez prêt à personnaliser le comportement de sys- logd via son fichier de configuration.
kern.*
mail.warn
*.*;auth,authpriv.none auth,authpriv.*
Dans leur ordre d'apparition, ces lignes définissent tous les messages utilisant la facilité kernel quelle que soit leur priorité
•    les messages concernant la facilité mail d'un niveau warn et supérieur ;
•    tous les messages de toutes facilités et de toutes priorités et les messages se rapportant à la sécurité qui ne possèdent pas de priorité et supé- rieurs. auth et authpriv sont équivalents ;
•    enfin, tous les messages concernant la sécuri- té quelle que soit la priorité.
Nous l'avons dit plus haut, en temps normal, les priorités spécifiées ne sont qu'une limite. Il est cependant possible de ne définir qu'une seule priori- té (ni plus importante. ni moins) en ajoutant le signe d'égalité (=-) avant la priorité définie. Le point d'exclamation permet également d'ajouter une négation.
En ce qui concerne le champ d'action, c'est-à-dire la seconde partie d'une ligne de syslog.conf, il s'agit d'un fichier journal. Mais ne vous y trompez pas, un fichier journal, ou logfile, n'est pas nécessaire- ment un véritable fichier. Le premier caractère du champ d'action détermine le type de "fichier".
Si le champ d'action débute par un / (comme /var/log/machin. log), les messages sont enregis- trés dans le fichier spécifié. Si le champ débute par un signe -, syslogd ne synchronisera pas le fichier après chaque message. Le problème dans ce cas est une perte potentielle d'information si un problème bloquant survient immédiatement après l'enregistre- ment du fichier. En contrepartie, cette possibilité vous permettra d'économiser grandement des res- sources, en particulier avec des démons très (trop ?) bavards. Enfin, le symbole I vous permettra de redi- riger les messages vers un tube nommé ou une
console (/dev/tty10).
Enfin, syslogd dispose d'une fonctionnalité très intéressante sur bien des points. Elle consiste à pou- voir envoyer les messages à un autre syslogd fonc- tionnant sur un autre hôte. Au premier abord. ceci offre une facilité dans la surveillance d'un parc de serveurs. Toute l'activité système de plusieurs ser- veurs étant enregistrée sur une seule et même machine, il devient aisé d'administrer la chose. L'autre gros avantage concernant cette fonctionna- lité est du point de vue sécuritaire. En effet, un pira- te ayant pris tout ou partie d'une machine cherche- ra à effacer ses traces. Si les journaux sont déportés, il devra prendre le contrôle de la machine archivant l'activité. Or. justement, on prendra soin de ne faire tourner aucun autre serveur sur cette machine, offrant ainsi le minimum de points d'entrée au vilain. Il est de plus possible d'utiliser un tunnel chiffré entre les serveurs et la machine d'archivage afin que le pira- te ne puisse pas écouter l'activité des serveurs qui cir- cule en temps normal en clair sur le réseau.
Rotation des logs
Archiver l'activité de tous les services d'une ou plu- sieurs machine(s) est quelque chose de très prudent. Cependant, lorsqu'un serveur met à disposition des
syslog.conf
Comme la totalité des fichiers de configuration concernant le fonctionnement général du système, le fichier de configuration de syslogd est placé dans
/etc SOUS le nom syslog . conf.
Dans ce fichier, les lignes vides (blanches) et celles
débutant par un dièse (#) ne sont pas prises en
iti compte. Le # est utilisé pour ajouter des commentaires. Les autres lignes sont des directives pour sys- logd. Elles sont composées de deux parties séparées par un espace (caractère espace ou tabulation). La première partie est le champ sélecteur permettant de définir la priorité et la facilité concernée, la seconde partie est le champ d'action. C'est ici que nous indiquerons que faire des informations (mes- sages) désignées par le champ de sélection.
Le champ sélecteur utilise les priorités et les facilités décrites plus haut en utilisant leur nom et en les séparant d'un point. De plus, un caractère "joker" est utilisé, c'est le *. Il servira à désigner n'importe quelle facilité ou priorité selon l'endroit où il est placé par rapport au point séparateur. Vous pouvez également utiliser la virgule pour spécifier plusieurs facilités pour une même priorité. De plus. un point- virgule peut être utilisé pour spécifier plusieurs champs de sélection pour une seule action. Il ne faut également pas perdre de vue que les priorités spécifiées dans le champ de sélection définissent normalement une limite égale ou supérieur.
Voyons quelques exemples concrets tirés du fichier de configuration par défaut d'une distribution Debian :
services de mail. HTTP, FTP, etc., les journaux sys- tème arrivent vite à prendre une place considérable sur le système de fichiers. Dans le cas qui nous occupe depuis le Hors série 9, votre serveur est sans doute une petite configuration et l'espace disque est peut-être limité. Il nous faut donc trouver une solu- tion pour ne pas perdre des informations impor- tantes, tout en économisant de la place. La solution existe, c'est la rotation des logs.
Le principe est le suivant : en temps normal, un fichier log grossit au fil du temps de manière plus ou moins régulière. Plutôt que de ne conserver qu'un seul exemplaire de chaque fichier log, nous archivons à intervalle régulier ces fichiers et en commençons un nouveau. Nos fichiers désignés dans la configuration de syslogd ne contiendront ainsi que les informations les plus récentes, les anciens messages étant regroupés dans des archives compressées.
L'utilitaire habituellement mis en œuvre pour ce type de mécanisme est logrotate. Celui-ci est appelé régulièrement depuis le crontab et utilise un fichier de configuration unique. Avec une distribution Debian, logrotate est appelé quotidiennement par anacron (une alternative au cron classique). Vous trouverez dans /etc/cron.daily un script shell nommé logrotate contenant /usr/sbin/logro- tate /etc logrotate.conf. Il s'agit de l'appel à la commande de rotation des logs avec, en para- mètre. le fichier de configuration à utiliser.
La périodicité utilisée dans le crontah n'est pas capita- le si ce n'est qu'elle doit être plus courte que la période entre deux rotations de logs. En effet, le fichier de configuration logrotate.conf contient une directive spécifiant la fréquence de rotation : weekly
Le fichier de configuration se compose de deux grandes parties. Dans un premier temps, nous avons les directives de configuration globales qui s'appli- quent à tous les fichiers logs. Ces directives sont habituellement placées en début de fichier de confi- guration. Ensuite arrivent les paramètres spécifiques de chaque fichier log s'ils sont différents des para- mètres globaux. Pour définir des directives spécifiques à un fichier log, on utilise la syntaxe suivante :
/chemin/vers/ f ichier . log {
directive directive
directive
Tout ce qui se trouve entre II ne concernera que ce fichier. Les paramètres non définis dans cette por- tée seront remplacés par les valeurs des paramètres globaux. Voyons directement un exemple avec notre
fichier /var/log/messages
/var/log/messages {
rotate 10 weekly
postrotate
/sbin/killall -HUP syslogd
endscript
Cette portion de paramètre concerne /var/log/messages. Nous spécifions que la rota- tion de ce log doit se faire 10 fois avant sa suppres- sion définitive (rotate 10). Nous spécifions égale- ment que la rotation se fera une fois par semaine (weekly). En réalité, weekly définit une rotation si le jour de la semaine actuelle est inférieur au jour de la semaine de la rotation précédente ou si plus d'une semaine s'est écoulée entre les deux rotations. Normalement, avec un appel quotidien à loarota- te depuis la crontab, la rotation aura lieu tous les premiers jours de la semaine.
postrotate et endscript permettent de lancer une commande après la rotation du fichier log mais avant que l'ancienne version du fichier log ne soit supprimée. Ici, nous redémarrons syslogd afin de ne pas perdre un seul message durant l'opération de copie/suppression.
Nous pourrions également ajouter la ligne suivante dans la portée de /var/log/messages
mail kkun@kkpart.fr
Dans ce cas, la rotation suppressive (la dernière qui déclenche la suppression du dernier fichier log), est remplacée par l'envoi d'un mail contenant ce log à la personne désignée par kkun@kkpart . fr. Cela ajoute, en quelque sorte, une sécurité supplémentai- re étant donné que l'archivage définitif se fera sur une machine sans doute différente. Cette option, combinée à l'exportation des messages syslogd vers une autre machine (sur laquelle tourne logrotate), vous assurera une relative sécurité.
Arrêtons là nos explications qui, je pense, sont suffisantes pour garder un œil sur les logs système de manière sûre. Vous trouverez des informations plus précises dans les pages de manuel et dans les documentations officielles des différents utilitaires.