Le paquet logcheck dans Debian est divisé en trois paquets logcheck (le programme principal), logcheck-database (une base de données d'expressions rationnelles pour le programme) et logtail (affiche les lignes du journal qui n'ont pas encore été lues). Le comportement par défaut sous Debian (dans /etc/cron.d/logcheck) est que logcheck est exécuté toutes les heures et une fois après le démarrage.

Cet outil peut être assez utile s'il est personnalisé correctement pour alerter l'administrateur d'événements système inhabituels. logcheck peut être complètement personnalisé pour envoyer des courriers selon les événements récupérés des journaux et qui sont dignes d'attention. L'installation par défaut inclut des profils pour des événements ignorés et des violations de règles pour trois configurations différentes (station de travail, serveur et paranoïaque). Le paquet Debian contient un fichier de configuration /etc/logcheck/logcheck.conf, qui définit à quel utilisateur sont envoyés les vérifications. Il permet également aux paquets qui fournissent des services d'implémenter de nouvelles règles dans les répertoires: /etc/logcheck/cracking.d/_paquet_, /etc/logcheck/violations.d/_paquet_, /etc/logcheck/violations.ignore.d/_paquet_, /etc/logcheck/ignore.d.paranoid/_paquet_, /etc/logcheck/ignore.d.server/_paquet_ et /etc/logcheck/ignore.d.workstation/_paquet_. Cependant, peu de paquets le font actuellement. Si vous avez une règle qui peut être utile à d'autres utilisateurs, veuillez l'envoyer comme un rapport de bogue sur le paquet approprié (comme un bogue de gravité wishlist). Pour obtenir plus de renseignements, veuillez consulter /usr/share/doc/logcheck/README.Debian.

Le meilleur moyen de configurer logcheck est d'éditer son fichier de configuration principal /etc/logcheck/logcheck.conf après l'avoir installé. Modifiez l'utilisateur par défaut (root) à qui seront envoyés par courrier les comptes-rendus. Vous devriez également y positionner le niveau de compte-rendu. logcheck-database a trois niveaux de compte-rendu de verbosité croissante: station de travail, serveur, paranoïaque. «serveur» étant le niveau par défaut, «paranoïaque» n'est recommandé que pour les machines de haute sécurité ne faisant fonctionner qu'aussi peu de services que possible et «station de travail» est pour les machines relativement protégés et non critiques. Si vous désirez ajouter de nouveaux fichiers journaux, ajoutez-les simplement à /etc/logcheck/logcheck.logfiles. Celui-ci est configuré pour une installation de syslog par défaut.

Une fois fait, vous pouvez vouloir vérifier les courriers envoyés, pour les quelques premiers jours, semaines ou mois. Si estimez recevoir des messages indésirables, ajoutez simplement l'expression rationnelle (consultez regex(7) et egrep(1)) qui correspond à ces messages au fichier /etc/logcheck/ignore.d.niveau_de_compte-rendu /local. Essayez de faire correspondre à la ligne entière du journal. Des détails sur l'écriture des règles sont expliqués dans /usr/share/doc/logcheck-database/README.logcheck-database.gz. C'est un processus d'affinement perpétuel; une fois que les messages envoyés sont toujours pertinents, vous pouvez considérer que l'affinement est terminé. Notez que si logcheck ne trouve rien de pertinent dans le système, il ne vous enverra pas de courrier même s'il fonctionne (donc, vous pouvez ne recevoir de courrier qu'une fois par semaine si vous êtes chanceux).

Debian livre une configuration standard de syslog (dans /etc/syslog.conf) qui archive les messages dans les fichiers appropriés en fonction de la facilité du système. Vous devriez être familier avec cela; jetez un œil au fichier syslog.conf et à la documentation si vous ne l'êtes pas. Si vous avez l'intention de maintenir un système sécurisé, vous devriez être conscient de l'endroit où les journaux sont envoyées ainsi ils ne sont pas perdus dans la nature.

Par exemple, envoyer des messages à la console est également utile pour de nombreux systèmes de production. Mais pour de nombreux systèmes semblables il est également important d'ajouter une nouvelle machine qui servira de serveur de journalisation (il reçoit les journaux de tous les autres systèmes).

Le courrier du superutilisateur devrait être pris en considération également, de nombreux contrôles de sécurité (comme snort) envoient des alertes dans la boîte aux lettres du superutilisateur. Celle-ci pointe généralement sur le premier utilisateur créé sur le système (vérifiez /etc/aliases). Veillez à envoyer le courrier du superutilisateur à un endroit où il sera lu (soit localement soit à distance).

Il y a d'autres comptes et alias «rôles» sur le système. Sur un petit système, le plus simple est probablement de s'assurer que tous ces alias pointent vers le compte du superutilisateur, et que les messages à destination du superutilisateur sont retransmis vers la boîte aux lettres personnelle de l'administrateur système.

FIXME : Il serait intéressant de dire comment un système Debian peut envoyer/recevoir des messages SNMP relatifs à des problèmes de sécurité (jfs). Voir: snmptragfmt, snmp et snmpd.

Un loghost est un hôte qui recueille les données des syslog à travers le réseau. Si l'une de vos machines est piratée, l'intrus n'est pas capable de dissimuler ses traces, à moins qu'il ne pirate également le loghost. Par conséquent, le loghost devrait être particulièrement sécurisé. Faire d'une machine un loghost est simple. Il suffit juste de démarrer le syslogd avec:

syslogd -r

et un nouveau loghost est né. De façon à rendre cela permanent dans Debian, éditez /etc/default/syslogd et changez la ligne

SYSLOGD=""

par

SYSLOGD="-r"

Ensuite, configurez les autres machines afin qu'elles envoient les données au loghost. Ajoutez une entrée comme celle qui suit dans /etc/syslog.conf:

  facilité.niveau           @votre_loghost

Consultez la documentation pour savoir ce qu'on peut utiliser à la place de facilité et niveau (ils ne devraient pas être mot pour mot comme cela). Si vous voulez tout archiver à distance, il suffit d'écrire:

  *.*                       @votre_loghost

dans syslog.conf. Archiver à distance ainsi que localement est la meilleure solution (le pirate peut estimer avoir couvert ses traces après la suppression des fichiers de journalisation locaux). Consultez les pages de manuel syslog(3), syslogd(8) and syslog.conf(5) pour toutes informations complémentaires.

Il est important de décider non seulement comment les alertes sont utilisées, mais aussi qui y accède, c'est-à-dire qui peut lire ou modifier les fichiers de journalisation (en absence d'hôte d'archivage). Les alertes de sécurité que l'attaquant peut modifier ou désactiver sont de peu de valeur en cas d'intrusion. Vous devez également prendre en compte que les fichiers de journalisation peuvent révéler un grand nombre d'informations à propos du système à un intrus s'il y a accès.

Certaines permissions de fichiers de journalisation ne sont pas parfaites après l'installation (mais, bien sûr, cela dépend vraiment de vos règles de sécurité locales). Premièrement /var/log/lastlog et /var/log/faillog n'ont pas besoin d'être lisibles par les utilisateurs normaux. Dans lastlog, vous pouvez voir qui s'est connecté récemment, et dans faillog, vous voyez un résumé des connexions qui ont échouées. L'auteur recommande de faire un chmod 660 sur les deux fichiers. Faites un tour rapide des fichiers de journalisation et décidez avec beaucoup d'attention quels fichiers de journalisation vous rendez lisible ou modifiable par un utilisateur avec un UID différent de 0 et un autre groupe que «adm» ou «root». Vous pouvez facilement vérifier cela sur le système avec:

  #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
  (voir à quels utilisateurs appartiennent les fichiers de /var/log)
  #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
  (voir à quels groups appartiennent les fichiers de /var/log)
  # find /var/log -perm +004
  (fichiers lisibles par tout utilisateur)
  #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
  (fichiers appartenant à des groupes autres que root ou adm)

Pour personnaliser la façon dont les fichiers de journalisation sont créés, vous devez probablement personnaliser le programme qui les génère. Cependant, si le fichier de journalisation est archivé, vous pouvez personnaliser le comportement de la création et de l'archivage.