Aller au contenu

Administration Unix - CM séance 19

18. Services réseau (suite)

18.3. La gestion des logs

Les logs désignent des journaux d'événements d'un système informatique.

Ils sont traditionnellement stockés dans /var/log/.

18.3.1. Le système de logs syslog

Syslog définit un protocole et des outils pour fournir un service de logs.

Il a été développé dans les années 1980 par Eric Allman pour le projet Sendmail, puis est devenu la solution de journalisation standard sur les systèmes Unix.

Syslog est caractérisé par plusieurs éléments :

  • Plusieurs RFC :

    RFC 3164    The BSD syslog protocol
RFC 3195    Reliable Delivery for syslog
RFC 5424    The Syslog Protocol
RFC 5425    TLS Transport Mapping for Syslog
RFC 5426    Transmission of Syslog Messages over UDP
...

    Voir https://en.wikipedia.org/wiki/Syslog#Internet_standard_documents

  • Plusieurs programmes (et leurs implémentations, éventuellement sous la forme d'un serveur qui écoute sur le réseau).

  • Des fichiers dans lesquels les logs sont stockés.

  • Des librairies.

  • Les messages peuvent être émis par des programmes en local, ou des machines à distance.

  • L'enregistrement des messages sera réalisé en local, dans des fichiers (habituellement dans le répertoire /var/log), mais il peut aussi être dans une base de données ou sur une machine distante.

Dans le cas d'un enregistrement dans des fichiers, il loguera des messages sous la forme :

Mar 17 15:50:27 localhost NetworkManager[1571]: <info> (eth1): DHCPv4 changed
Mar 17 15:50:28 localhost dhclient: Listening on LPF/eth1/80:00:60:0f:e8:00
Mar 17 15:50:28 localhost dhclient: Sending on   LPF/eth1/80:00:60:0f:e8:00

Un événement est constitué par 3 éléments : facility, severity et un message.

  • facility est un canal qui est fonction de leur origine :

     0       KERN            messages du noyau
 1       USER            messages au niveau user
 2       MAIL            gestion des mails
 3       DAEMON          démons système
 4       AUTH            messages de sécurité/autorisations
 5       SYSLOG          messages internes générés par syslogd
 6       LPR             gestion des impressions
 7       NEWS            gestion des news
 8       UUCP            gestion uucp
 9       CRON            démon cron
10       AUTHPRIV        messages privés de sécurité/autorisations
11       FTP             démon ftp
16-23    LOCAL0-LOCAL7   réservés pour usage local

  • severity est un drapeau qui concerne leur gravité :

    0   Emerg (emergency)   Système inutilisable
1   Alert               Une intervention immédiate est nécessaire
2   Crit (critical)     Erreur critique pour le système
3   Err (error)         Erreur de fonctionnement
4   Warning             Avertissement
5   Notice              Événement normal méritant d'être signalé
6   Info                Pour information seulement
7   Debug               Message de mise au point

  • le message lui-même qui est un texte, par exemple

    dhclient: Sending on   LPF/eth1/80:00:60:0f:e8:00

On verra plus loin l'utilisation de facility et severity.

18.3.2. Le projet syslog-ng

Ce programme a vu le jour en 1998, développé par Balázs Scheidler.

Il est distribué sous plusieurs formes (open source, ou propriétaire avec des modules supplémentaires et un support).

Il étend le protocole syslog de base avec de nouvelles fonctionnalités telles que :

  • un filtrage basé sur le contenu ;
  • la connexion directe à une base de données.

Le fichier de configuration est /etc/syslog-ng/syslog-ng.conf. Il est complètement différent du fichier de configuration de syslog. Il comprend 5 mots clé :

Options     les options génériques du programme

Source      permet de définir comment il reçoit les informations 
            (écouter en local, sur le réseau, surveiller tel fichier, etc).

Destination permet de définir la destination des messages (écrire dans un 
            fichier, sur le réseau vers la machine untel en tcp, etc).

Filter      permet de définir des filtres sur le contenu des messages 
            (seulement les messages de warning, pas les messages de tel 
            programme, etc).

Log         ce sont ces directives qui permettent aux filtres d'agir sur 
            des sources, et de renvoyer tout cela vers des destinations :
            c'est ici que l'on dit explicitement à syslog-ng d'agir.

Par exemple :

options {
    time-reap(30);      # timeout fichier idle
    mark-freq(10);      # durée entre 2 msg MARK (alive)
    keep-hostname(yes);
};
source s_local {
    system(); internal();
};
source s_network {
    syslog(transport(tcp));
};
destination d_logs {
    file(
        "/var/log/syslog-ng/logs.txt"
        owner("root")
        group("root")
        perm(0777)
        );
    };
log {
    source(s_local); source(s_network); destination(d_logs);
};
Voir :
man syslog-ng.conf
https://www.syslog-ng.com/products/open-source-log-management/

18.3.3. Le projet rsyslog

Le démon rsyslogd (reliable and extended syslogd) est développé depuis 2004 par Rainer Gerhards. Il était installé par défaut sur les systèmes Debian (remplacé depuis par systemd-journal).

Par rapport à syslog-ng :

  • les plus :
    • la retenue des messages en mémoire tampon ;
    • le protocole RELP (Reliable Event Loggin Protocol) ;
    • des fichiers de configuration compatibles avec syslog ;
  • les moins :
    • ne permet pas de surveiller directement un fichier ;
    • le format des fichiers de configuration est moins souple.

La configuration se fait par les fichiers :

  • /etc/rsyslog.conf
  • /etc/rsyslog.d/*

(sur certains systèmes tout est dans rsyslogd.conf).

Le fichier rsyslog.conf contient

  • des déclarations de modules :

    module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
...
# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")
...
# Enable non-kernel facility klog messages
$KLogPermitNonKernelFacility on

  • des directives globales :

    $FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
...
$WorkDirectory /var/spool/rsyslog
...
# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf

Les fichiers de rsyslog.d/ définissent des règles :

  • /etc/rsyslog.d/20-ufw.conf :

    # enregistre les messages du firewall ufw dans un fichier
:msg,contains,"[UFW " /var/log/ufw.log
...

  • /etc/rsyslog.d/50-default.conf :

    auth,authpriv.*            /var/log/auth.log
*.*;auth,authpriv.none    -/var/log/syslog
#cron.*                    /var/log/cron.log
#daemon.*                 -/var/log/daemon.log
kern.*                    -/var/log/kern.log
#lpr.*                    -/var/log/lpr.log
mail.*                    -/var/log/mail.log
#user.*                   -/var/log/user.log
mail.err                   /var/log/mail.err
*.emerg                    :omusrmsg:*
local7.*                   /var/log/boot.log  # centos8: msg de boot
...

La partie gauche concerne les règles sur les canaux et les gravités (facility.severity).

La partie droite de la règle est la destination. Cela peut être :

  • un fichier : il sera écrit immédiatement, ou mis dans un tampon s'il est précédé d'un tiret ;
  • un tube nommé, une console ;
  • une destination réseau, sous la forme @machine (transmission en UDP) ou @@machine (en TCP) ;
  • une liste d'utilisateurs (:omusrmsg:* signifie tous les users logués) ;
  • ^programme_à_exécuter pour passer le message à un programme ou un script ;
  • ~ : supprime les messages ;
  • etc.
Voir :
man rsyslogd.conf
https://www.rsyslog.com/

18.3.4. Systemd journal

Installé par défaut sur Debian depuis la version 12.

Les événements sont mémorisés dans le répertoire /var/log/journal :

$ tree /var/log/journal
/var/log/journal
└── 881e856bde44475f9d7cb824ea20fa1d
    ├── system@420f1aeb05934779b9df68b32b8eb90e-0000000000000001-00061b1bd31170a2.journal
    ├── system@420f1aeb05934779b9df68b32b8eb90e-0000000000000422-00061b1bd3304acc.journal
    ...
    ├── system.journal
    ├── user-1000@302e8eaf4ccb451abca9f56710c2fd45-000000000000d249-00062661a194d9ab.journal
    ├── user-1000@302e8eaf4ccb451abca9f56710c2fd45-000000000000f383-000626c7503e34a0.journal
    ├── user-1000.journal
    ...
1 directory, 100 files

Pour voir les logs on utilise la commande journalctl :

  • journalctl affiche tous les logs ;
  • journalctl -p err affiche les logs ayant une severity donnée ;
  • journalctl -u ssh affiche les logs pour une unité systemd ;
  • journalctl -t sudo affiche les logs pour une commande donnée ;
  • journalctl -u NetworkManager --since "1 hour ago" affiche les messages dans la dernière heure ;
  • journalctl -n 10 affiche les 10 dernières lignes ;
  • journalctl -f affiche les nouveaux logs en continu.

Voir man journalctl.

Les logs peuvent être configurés dans /etc/systemd/journald.conf, voir man.journald.conf :

[Journal]
SystemMaxUse=500M
SystemMaxFileSize=100M

Il est possible d'utiliser quand même rsyslog. Pour cela,

  • installer le paquet rsyslog ;
  • rajouter dans /etc/systemd/journald.conf l'option ForwardToSyslog=yes (semble être activée par défaut).

18.3.5. Programmes annexes

Le programme logger permet de générer un message de log.

Exemple :

  • dans un terminal, affichage dynamique de la fin de syslog

    $ tail -f /var/log/syslog

  • dans un autre terminal :

    $ logger -p local3.info -- "Voici un message"

Il permet de tester un système de logs.

Par exemple :

$ logger "Message1"
$ logger -p local3.info "Message2"
$ logger -p mail.warning "Message3"
$ grep "Message[123]" /var/log/* 2>/dev/null
/var/log/mail.log:Mar 17 14:29:51 tesla thiel: Message3
/var/log/syslog:Mar 17 14:29:08 tesla thiel: Message1
/var/log/syslog:Mar 17 14:29:36 tesla thiel: Message2
/var/log/syslog:Mar 17 14:29:51 tesla thiel: Message3

Remarque : avec systemd-journal, on peut obtenir les logs ainsi (-g grep avec expression régulière, -q mode quiet) :

$ journalctl -g "Message[123]" -q
mars 21 11:14:26 localhost thiel[18801]: Message1
mars 21 11:26:49 localhost thiel[18901]: Message2
mars 21 11:27:01 localhost thiel[18902]: Message3

$ journalctl -g "Message[123]" -q -p warning
mars 21 11:27:01 localhost thiel[18902]: Message3

$ journalctl -g "Message[123]" -q --facility=mail
mars 21 11:27:01 localhost thiel[18902]: Message3

Le programme logrotate permet de gérer la rotation des logs via une crontab (les fichiers sont automatiquement compressés et numérotés).

  • la rotation est indépendante du système qui recueille les messages (rsyslog ou syslog-ng).

  • la configuration se fait via les fichiers

    • /etc/logrotate.conf
    • /etc/logrotate.d/*

    elle permet de spécifier la périodicité, combien on garde de versions numérotées (par défaut 5), si on compresse les fichiers, etc.

Pour systemd-journal, la rotation des logs se fait différement (configuré dans /etc/systemd/journalct.conf) avec les directives Compress, MaxRetentionSec, MaxFileSec ; on peut aussi forcer une rotation avec journalctl --rotate.

La commande dmesg affiche les messages spécifiques au noyau.

Pour voir les messages en direct : dmesg -w

Des programmes permettent d'effectuer des tris de logs et de la recherche, d'effectuer des analyses quotidiennes et d'envoyer les résultats par mail, d'afficher des rapports ou des tableaux de bord dans une page web :

18.4. Pare-feux

18.4.1. Introduction

Un pare-feu (uk: firewall) est un service chargé de filtrer le trafic entrant ou sortant à partir de règles.

Un pare-feu peut être local, virtuel, ou tourner sur une machine dédiée :

  • local : sur la machine physique ; des logiciels existent pour tous les OS, voire des distributions dédiées ;
  • virtuel : dans une VM, avec du routage ;
  • machine dédiée :
    • il y a de nombreux constructeurs ; les machines pouvant être très puissantes, avec de l'apprentissage, etc (Cisco, Nortel, PaloAlto, ...)
    • la plupart utilisent un OS dérivé de Linux ; certaines sont basées sur un BSD, sur Windows, ou encore sur un OS spécifique.

18.4.2. Sous Linux en local

Sous Linux, la plupart des pare-feux s'appuient sur le module netfilter du noyau (module développé par Rusty Russel depuis 1998).

L'interface pour gérer les règles de netfilter est en général iptables (du même auteur) pour IPv4, sous la forme d'une famille de commandes iptables-*, et ip6tables (commandes ip6tables-*) pour IPv6.

Dans les versions antérieures du noyau (de 2.1 à 2.4), les pare-feux s'appuyaient sur ipchains (du même auteur), et avant cela sur ipfw (depuis 1.1, porté depuis FreeBSD).

La gestion des règles iptables peut être complexe, c'est pourquoi il existe de nombreux front-end pour simplifier la tâche. Par ailleurs, la tendance actuelle est que iptables soit remplacé par le projet nftables.

Dans la suite nous présentons le front-end UFW.

18.4.3. Configuration simple avec UFW

UFW signifie Uncomplicated Firewall. Il peut s'appuyer indifférement sur iptables ou nftables.

UFW se présente sous la forme d'une commande ufw avec un certain nombre d'options. Il existe également une version graphique gufw. Les paquets correspondants sont ufw et gufw.

La configuration se fait principalement en ligne de commandes ; voici une configuration typique :

  • Par défaut on interdit toutes les connexions entrantes, et on autorise toutes les connexions sortantes :

    $ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

  • Ensuite on autorise les connexions ssh entrantes :

    $ sudo ufw allow ssh

    Si le port de sshd n'est pas 22, mais par exemple 10022, on écrira plutôt

    $ sudo ufw allow ssh 10022/tcp

  • Pour le moment le firewall est inactif :

    $ sudo ufw status
État : inactif

    On active le pare-feu (nécessaire uniquement lorsqu'on vient d'installer le paquet) :

    $ sudo ufw enable
Le pare-feu est actif et lancé au démarrage du système

  • On peut ensuite lister les règles actives :

    $ sudo ufw status numbered
État : actif

     Vers                       Action      De
     ----                       ------      --
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 22/tcp (v6)                ALLOW IN    Anywhere (v6)

L'option numbered affiche le numéro de chaque règle, ce qui permet par exemple de supprimer une règle :

$ sudo ufw delete 2

Les modifications effectuées avec ufw sont permanentes ; la commande les stocke dans les fichiers /etc/ufw/*.rules.

Les différents fichiers dans /etc/ufw/ et /etc/ufw/applications.d/ contiennent tout un ensemble de règles qui viennent avec l'installation du paquet. Pour les afficher :

$ sudo ufw show raw
...
$ sudo ufw app list
Applications disponibles :
  CUPS
  OpenSSH
$ sudo ufw app info CUPS
...

Par exemple, pour autoriser le serveur multimédia UMS, on rajoutera le fichier

$ cat /etc/ufw/applications.d/ums 
[UMS]
title=Universal Media Server, an UPnP server
description=UMS is a free UPnP server
ports=9000/udp|9001:9002/tcp|5001/tcp

puis on exécutera les commandes :

$ sudo ufw app update UMS
$ sudo ufw allow UMS

Selon la charge du réseau, les fichiers de logs peuvent rapidement se remplir avec des messages de blocage du pare-feux. On peut arrêter les logs du pare-feux avec ufw logging off (et les rétablir si besoin avec ufw logging on). On peut aussi configurer cron pour qu'il exécute logrotate plus souvent, et configurer la taille max des logs pour logrotate.

Les différentes possibilités de UFW sont décrites dans ces documents :

18.4.4. Compléments

UFW demeure néanmoins assez simpliste, et pour des scénarios plus sophistiqués il faudra revenir à des règles iptables ou nftables, ou utiliser un front-end plus élaboré.

Par exemple, le front-end firewalld offre la possibilité :

  • de gérer des règles pour de nombreux backends (iptables, nftables, ebtables, ipset, ...),
  • de déclarer des zones de confiance,
  • de distinguer la configuration permanente de celle donnée au runtime,
  • de commander le pare-feux via le D-Bus, et donc de permettre une intégration complète avec le Desktop.

De plus dans firewalld, de nombreux éléments sont prédéfinis, il y a un langage riche de configuration, et une interface graphique est fournie. firewalld est installé par défaut sur CentOS, et disponible sur de nombreuses distributions, dont Debian et Ubuntu. Pour tester : systemctl status firewalld ; firewall-cmd --help.

Il existe des outils complémentaires, tels que fail2ban, voir le wiki d'installation pour Ubuntu : cet outil analyse les logs, et est capable de rajouter automatiquement des règles iptables ou nftables pour bannir des IPs, par exemple au bout de 10 échecs de connexion ssh.

Une possibilité intéressante est le port knocking, qui est une méthode permettant de modifier le comportement d'un firewall en temps réel pour provoquer l'ouverture d'un port suite au lancement préalable d'une suite de connexions sur des ports distincts dans un certain ordre. Exemple sur le wiki Ubuntu.