Création d'un serveur de journal centralisé sécurisé avec syslog-ng et Stunnel

Skip to Content Sun and Oracle Channel Sun How to Buy Log In United States [Change] English

BigAdmin System Administration Portal

Article de fond

Print-friendly Version

Submit Content | Check BigAdmin Bucks

Création d'un serveur de journal centralisé sécurisé avec syslog-ng et Stunnel

Amy Rich, septembre 2004

Sommaire :

Installation de Stunnel
Création des fichiers de certificat pour syslog-ng sur Stunnel
Configuration de Stunnel pour utilisation avec syslog-ng
Installation de syslog-ng
Configuration de syslog-ng
Ressources

Les administrateurs de système UNIX connaissent bien le démon syslog, mais les informations qu'il recueille demeurent souvent non traitées si personne ne signale de problème. Sur n'importe quel site comptant plus qu'une poignée de machines, personne ne consacre de temps à se connecter et vérifier plusieurs fichiers journal chaque jour, ni même chaque mois. Les scripts automatisés qui peuvent établir une corrélation entre ces machines sont difficiles à écrire car il doivent accéder à chaque machine individuellement. Pour soulager la charge de traitement automatique et manuel des données, de nombreux sites mettent en oeuvre un serveur de journal central qui collecte les données pour toutes les machines (de préférence exécutant NTP pour faciliter la corrélation heure/date) sur un réseau, y compris les serveurs UNIX, les bureaux Windows et Mac, et même l'équipement de réseau tel que routeurs et commutateurs. La journalisation centralisée est assez légère avec la plupart des démons d'origine UNIX syslog, mais syslogd est peu différent des versions antérieures et présente quelques inconvénients.

Le démon UNIX standard syslog transporte les messages au clair sur UDP, ce qui signifie que tout le monde peut capter des données potentiellement sensibles. Le modèle facility.level est également assez restrictif, et les fichiers par défaut /etc/syslog.conf fournis avec la plupart des systèmes d'exploitation négligent de journaliser de nombreux messages susceptibles d'intéresser les administrateurs. L'analyse des journaux de façon sensée pour la lecture humaine ou l'exploration de données automatisée n'est pas une mince affaire. Le démon UNIX syslog ne permet pas facilement de partager les fichiers journaux par hôte ou de rapprocher les messages du journal par expression régulière, par exemple. Par conséquent, la plupart des serveurs de journal centralisés utilisant de démon syslog d'origine finissent avec des fichiers journaux monolithiques qui sont traités uniquement après que les processus syslogd les aient fermés.

Par conséquent, la plupart des sites qui centralisent la journalisation finissent aussi par remplacer le démon syslog d'origine par quelque chose de plus sûr et de plus souple, comme Metalog, msyslog ou similaire. L'un des remplaçants appréciés desyslog est un programme open source intitulé syslog-ng. Une entreprise peut exécuter syslog-ng sur chaque hôte UNIX ou uniquement sur le serveur syslog proprement dit. Si syslog-ng est exécuté uniquement sur l'hôte du journal, les clients envoient les données par le port UDP 514 comme à l'accoutumée, mais une organisation et une manipulation de meilleure qualité du journal peuvent être accomplies sur le serveur.

L'avantage d'exécuter syslog-ng sur chaque hôte UNIX réside dans la possibilité de crypter le canal de journalisation avec IPSec ou l'utilitaire Stunnel de sorte que les données soient illisibles pour le sniffer ordinaire. En l'associant à Stunnel comme mécanisme de transport, l'entreprise dispose d'une méthode sécurisée pour centraliser les messages de journal provenant de tous les hôtes UNIX voulus pour traitement plus approfondi. Dans le cas de syslog-ng, Stunnel fonctionne en acceptant les connexions du journal sur un port local, en les intégrant à des sessions SSL, puis en les redirigeant vers un port sécurisé sur l'hôte distant du journal. Le processus stunnel sur l'hôte distant du journal décrypte ensuite la session SSl et renvoie les informations au serveur syslog sur le port standard. Une fois sur le serveur de journal, l'organisation et l'analyse des fichiers journaux intervient, en utilisant la souplesse de syslog-ng.

Ci-dessus je couvre l'installation et la configuration de syslog-ng et de Stunnel sur des machines exécutant le système d'exploitation Solaris 8 (édition pour plate-forme SPARC), mais la procédure s'applique aussi généralement aux versions plus anciennes et plus récentes du SE Solaris, aussi bien sur les plates-formes SPARC et x86. Chacune des machines de référence examinée ci-dessous est livrée avec OpenSSL, tcp wrappers, le /dev/urandom patch Solaris 8, et l'environnement de développement GNU (gcc, et ainsi de suite) et plusieurs autres packages de freeware. La machine jouant le rôle de serveur de journal a également été minutieusement renforcée, car elle peut stocker des informations sensibles et liées à la sécurité issues de toutes les machines du réseau. Ces machines machines de référence résident toutes sur le sous-réseau 192.168.1, et l'adresse IP du serveur de journal est 192.168.1.10.

Installation de Stunnel

La première étape pour mettre en place un serveur de journal sécurisé consiste à installer Stunnel sur le serveur et sur chaque client. Stunnel peut aussi être utilisé avec le démon syslog d'origine (au lieu de remplacer syslog par syslog-ng), mais nous n'obtiendrions pas la souplesse recherchée. Dans les instructions qui suivent, je configure et je construis stunnel pour l'exécuter avec son propre utilisateur et groupe, et "chrooted" à son propre répertoire privé. Pour cela, créez d'abord le groupe et l'utilisateur stunnel (UID et GID aléatoires) :

/usr/sbin/groupadd -g 122 stunnel
/usr/sbin/useradd -c stunnel -d /nonexistent -m -g 122 -u 122 stunnel

Accédez maintenant à la source Stunnel, décompressez-la et configurez-la. Sur ces hôtes spécifiques, les certificats OpenSSL sont conservés dans/usr/local/etc/openssl/certs, et je souhaite garder le répertoire doc dans/usr/local avec d'autres installations locales. Je définis également localstatedir sur /var/run/stunnel, car il est inutile que cette information persiste après une réinitialisation ; je veux aussi qu'elle soit dans le répertoire chrooted.

wget http://www.stunnel.org/download/stunnel/src/stunnel-4.05.tar.gz
tar zxf stunnel-4.05.tar.gz
cd stunnel-4.05

./configure --localstatedir=/var/run/stunnel \
 --with-pem-dir=/usr/local/etc/openssl/certs --datadir=/usr/local

make
make install

Création des fichiers de certificat pour syslog-ng sur Stunnel

Le processus d'installation de Stunnel crée un certificat auto-signé que vous pouvez choisir d'utiliser. Étant donné que j'exécute ma propre autorité de certificat et que je n'exécuterai Stunnel que pour syslog-ng, je génère et signe mes propres certificats dédiés à syslog-ng. Pour des informations plus détaillées sur la configuration de vos propres CA et certificats de signature, consultez SSL certificates HOWTO.

Supposant que vous êtes désigné comme votre propre CA, ou que vous remettrez les demandes de certificat à un CA publiquement reconnu, créez un fichier pem pour le serveur :

openssl req -new -days 3650 -nodes -config stunnel.cnf -out serverreq.pem \
 -keyout syslog-ng-server.pem

Créez également un fichier pem correspondant pour chaque client :

openssl req -new -days 3650 -nodes -config stunnel.cnf -out clientreq.pem \
 -keyout syslog-ng-client.pem

Signez chaque fichier pem avec le CA local, ou faites-les signer par un CA public. J'utilise le script sign.sh qui accompagne la distribution apache mod_ssl :

sign.sh /tmp/serverreq.pem 
sign.sh /tmp/client1req.pem 
sign.sh /tmp/client2req.pem
sign.sh /tmp/client3req.pem

Les fichiers crt qui en résultent comprennent les certificats pour chacun des fichiers pem correspondants. Le serveur exige le fichier pem du serveur, syslog-ng-server.pem, avec la clé privée et le certificat (copié depuis le fichier /tmp/serverreq.pem.crt) du serveur :

Il exige également un fichier pem client, syslog-ng-client.pem, avec uniquement les certificats (issus des fichiers crt) du CA signataire et de chaque client (cet exemple suppose trois clients syslog-ng) :

Chacun des clients a besoin de son propre certificat et de sa clé privée dans un fichier pem, syslog-ng-client.pem :

Chaque client a également besoin d'un fichier pemsyslog-ng-server.pem, contenant seulement les certificats du serveur et du CA signataire :

Sur chaque machine, vérifiez que seule la racine puisse lire les fichiers de certificat pour des raisons de sécurité :

chmod 400 /usr/local/etc/openssl/certs/syslog-ng-*
chown root:other /usr/local/etc/openssl/certs/syslog-ng-*

Configuration de Stunnel pour utilisation avec syslog-ng

Sur le serveur, créez un fichier de configuration Stunnel dédié à syslog-ng, /usr/local/etc/stunnel/stunnel.conf, contenant des informations similaires à celles présentées ci-dessous. Ce fichier d'exemple spécifie le cert/la clé local(e) et les certificats du serveur, l'utilisateur et le groupe stunnel et le répertoire chroot. La valeur verify de 3 garantit questunnel vérifiera la paire avec le certificat installé localement. Stunnel laisse la vérification désactivée par défaut ; il est donc important de l'activer ici. La dernière section du fichier de configuration spécifie le numéro de port pour la session SSL intégrée et le port IP où les connexions sont acceptées et redirigées. Le port 514 est le port syslog standard, et 5140 est un port inutilisé choisi au hasard. Pour des informations plus détaillées et des options de configuration, ne manquez pas de lire les pagesstunnel du manuel.

cert = /usr/local/etc/openssl/certs/syslog-ng-server.pem
CAfile = /usr/local/etc/openssl/certs/syslog-ng-client.pem
chroot = /var/run/stunnel
pid = /run/stunnel.pid
setuid = stunnel
setgid = stunnel
verify = 3
[5140]
   accept = 192.168.1.10:5140
   connect = 127.0.0.1:514

Sur chaque client, le fichier dédié à syslog-ng, /usr/local/etc/stunnel/stunnel.conf contient des directives similaires au fichierstunnel.conf du serveur. Les valeurs cert et CAfile et les valeursaccept et connect sont échangées, et la directive client est ajoutée :

client = yes
cert = /usr/local/etc/openssl/certs/syslog-ng-client.pem
CAfile = /usr/local/etc/openssl/certs/syslog-ng-server.pem
chroot = /var/run/stunnel
pid = /run/stunnel.pid
setuid = stunnel
setgid = stunnel
verify = 3
[5140]
   accept = 127.0.0.1:514
   connect = 192.168.1.10:5140

Stunnel est désormais configuré, et nous sommes prêts pour l'installation et la configuration de syslog-ng. Si vous souhaitez tester Stunnelà ce stade, configurez-le pour utiliser à la place un autre port TCP ou service, comme IMAP ou telnet, comme indiqué dans la page exemples stunnel.

Installation de syslog-ng

La version stable de syslog-ng exige tout d'abord l'installation, ou au moins la construction, de la bibliothèque libol. Téléchargez, décompressez et installez la bibliothèque comme indiqué ici :

wget http://www.balabit.com/downloads/libol/0.3/libol-0.3.14.tar.gz
tar zxf libol-0.3.14.tar.gz
cd libol-0.3.14

./configure
make
make install

Extrayez maintenant la source pour syslog-ng et décompressez, configurez et installez-le. Pendant la configuration, j'ajoute également la prise en charge detcp wrappers car il est installé et je l'utilise activement pour d'autres démons :

wget http://www.balabit.com/downloads/syslog-ng/1.6/src/syslog-ng-1.6.5.tar.gz
tar zxf syslog-ng-1.6.5.tar.gz
cd ../syslog-ng-1.6.5

./configure --enable-tcp-wrapper
make
make install

Veillez à ouvrir les ports appropriés dans les filtres de paquets et/ou tcp wrappers. Le serveur doit accepter les connexions des clients sur le port TCP 5140, et sur le port UDP 514 si l'hôte du journal accepte également les messages syslog non cryptés. Pour prendre en charge la syntaxe étendue de tcp wrappers, ajoutez ce qui suit à /etc/hosts.deny sur le serveur :

syslog-ng : LOCAL 127.0.0.1 192.168.1. : ALLOW

Et ceci sur le client, à /etc/hosts.deny:

syslog-ng : LOCAL 127.0.0.1 : ALLOW

Créez maintenant un script de démarrage stunnel/syslog-ng, /etc/init.d/syslog-ng, qui sera exécuté à l'initialisation sur chaque machine. Le script ci-dessous est basé sur le script de démarrage syslog pour le SE Solaris 8, et il effectue aussi un savecore en plus de démarrer stunnel et syslog-ng :

#!/sbin/sh
#

case "$1" in
'start')
	if [ -f /usr/local/etc/syslog-ng/syslog-ng.conf -a -x \
             /usr/local/sbin/syslog-ng ]; then
		#
		# Before syslogd starts, save any messages from previous
		# crash dumps so that messages appear in chronological order.
		#
		/usr/bin/savecore -m
		if [ -r /etc/dumpadm.conf ]; then
			. /etc/dumpadm.conf
			[ "x$DUMPADM_DEVICE" != xswap ] && \
			    /usr/bin/savecore -m -f $DUMPADM_DEVICE
		fi
		#
                # Start stunnel so logs are sent encrypted
                #
                if [ -f /usr/local/etc/stunnel/stunnel.conf \
                     -a -x /usr/local/sbin/stunnel ]; then
                   echo "Starting stunnel"
                   mkdir -p /var/run/stunnel/run
                   chown stunnel:stunnel /var/run/stunnel/run
		   /usr/local/sbin/stunnel 
                   echo "Starting syslog-ng"
                   /usr/local/sbin/syslog-ng 
                fi
	fi
	;;

'stop')
	if [ -f /var/run/syslog-ng.pid ]; then
		syspid=`/usr/bin/cat /var/run/syslog-ng.pid`
		[ "$syspid" -gt 0 ] && kill -15 $syspid && \
                echo "Killed syslog-ng"
	fi
        if [ -f /var/run/stunnel/run/stunnel.pid ]; then
                syspid=`/usr/bin/cat /var/run/stunnel/run/stunnel.pid`
                [ "$syspid" -gt 0 ] && kill -15 $syspid && \
                echo "Killed stunnel"
        fi

	;;

*)
	echo "Usage: $0 { start | stop }"
	exit 1
	;;
esac

Supprimez les liens avec le démarrage desyslog natif de Solaris et fermez les scripts avant de les remplacer par les liens vers les nouveaux scripts syslog-ng :

rm /etc/rc*.d/???syslog
ln -s /etc/init.d/syslog-ng /etc/rc0.d/K40syslog-ng
ln -s /etc/init.d/syslog-ng /etc/rc1.d/K40syslog-ng
ln -s /etc/init.d/syslog-ng /etc/rc2.d/S74syslog-ng
ln -s /etc/init.d/syslog-ng /etc/rcS.d/K40syslog-ng

Configuration de syslog-ng

La souplesse desyslog-ngréside dans son fichier de configuration. Les directives de configuration importantes pour la manipulation du journal sont source, filter, destination et log. Les directivesSource indiquent l'origine des messages du journal, locaux et distants. Les directives Filter permettent de séparer les messages de journal en fonction du site, du niveau/de la priorité, du nom du programme, du nom de l'hôte ou du rapprochement avec une expression régulière. La destination peut être des fichiers, des tubes, des flux et des datagrammes, des connexions UDP ou TCP, des ttys ou un programme. La directive log est une collection des directives source, filter et destination qui définit comment un message de journal correspondant est traité. Une étude de toutes les directives disponibles se trouve dans le manuel de référence syslog-ng, et différents exemples sont présentés dans syslog-ng FAQ.

Les exemples suivants montrent des fichiers journaux stockés sur chaque hôte local dans /var/log ainsi que sur le serveur de journal central/var/log/clients/$YEAR/$MONTH/$HOST. Le /usr/local/etc/syslog-ng/syslog-ng.conf suivant sur l'hôte du journal prend en charge les messages du l'hôte local, des hôtes stunnel cryptés et des hôtes UDP standard (comme les routeurs et les commutateurs qui ne peuvent pas utiliser stunnel). Les filtres sont basés sur le site et le niveau, une correspondance de nom de programme ou une combinaison du tout.

# Options
options {
          use_fqdn(yes);
          sync(0);
          keep_hostname(yes);
          chain_hostnames(no);
	  create_dirs(yes);
        };

# Sources of syslog messages (both local and remote messages on the server)
source s_local   { 
                   sun-streams("/dev/log" door("/etc/.syslog_door")); 
                   internal();
                 };
source s_stunnel { 
                   tcp(ip("127.0.0.1")
                   port(514)
                   max-connections(1));
                 };

source s_udp     { udp(); };

# Level Filters
filter f_emerg   { level (emerg);            };
filter f_alert   { level (alert .. emerg);   };
filter f_crit    { level (crit .. emerg);    };
filter f_err     { level (err .. emerg);     };
filter f_warning { level (warning .. emerg); };
filter f_notice  { level (notice .. emerg);  };
filter f_info    { level (info .. emerg);    };
filter f_debug   { level (debug .. emerg);   };

# Facility Filters
filter f_kern   { facility (kern);   };
filter f_user   { facility (user);   };
filter f_mail   { facility (mail);   };
filter f_daemon { facility (daemon); };
filter f_auth   { facility (auth);   };
filter f_syslog { facility (syslog); };
filter f_lpr    { facility (lpr);    };
filter f_news   { facility (news);   };
filter f_uucp   { facility (uucp);   };
filter f_cron   { facility (cron);   };
filter f_local0 { facility (local0); };
filter f_local1 { facility (local1); };
filter f_local2 { facility (local2); };
filter f_local3 { facility (local3); };
filter f_local4 { facility (local4); };
filter f_local5 { facility (local5); };
filter f_local6 { facility (local6); };
filter f_local7 { facility (local7); };

# Custom Filters
filter f_user_none     { not facility (user);                     };
filter f_kern_debug    { filter (f_kern) and filter (f_debug);    };
filter f_daemon_notice { filter (f_daemon) and filter (f_notice); };
filter f_mail_crit     { filter (f_mail) and filter (f_crit);     };
filter f_mesg          { filter (f_kern_debug) or 
                         filter (f_daemon_notice) or 
                         filter (f_mail_crit);                    };
filter f_authinfo      { filter (f_auth) or program (sudo);       };

# Destinations: local files, the console, and the client files
destination l_authlog  { file ("/var/log/authlog");   };
destination l_messages { file ("/var/log/messages");  };
destination l_maillog  { file ("/var/log/maillog");   };
destination l_ipflog   { file ("/var/log/ipflog");    };
destination l_imaplog  { file ("/var/log/imaplog");   };
destination l_syslog   { file ("/var/log/syslog");    };

destination l_console  { file ("/dev/console");       };

destination r_authlog  { file
  ("/var/log/clients/$YEAR/$MONTH/$HOST/authlog");    }; 
destination r_messages { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/messages");   }; 
destination r_maillog  { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/maillog");    }; 
destination r_ipflog   { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/ipflog");     }; 
destination r_imaplog  { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/imaplog");    }; 
destination r_console  { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/consolelog"); }; 
destination r_syslog   { file
  ("/var/log/clients/$YEAR/$MONTH/$HOST/syslog");     };
destination r_fallback { file
  ("/var/log/clients/$YEAR/$MONTH/$HOST/$FACILITY-$LEVEL"); };

# Log statements
# Local sources
log { source (s_local); filter (f_authinfo)  destination (l_authlog);  };
log { source (s_local); filter (f_mail);     destination (l_maillog);  };
log { source (s_local); filter (f_local0);   destination (l_ipflog);   };
log { source (s_local); filter (f_local1);   destination (l_imaplog);  };
log { source (s_local); filter (f_syslog);   destination (l_syslog);   };
log { source (s_local); filter (f_emerg); filter (f_user_none); 
                                             destination (l_console);  };
log { source (s_local); filter (f_mesg);  filter (f_user_none);
                                             destination (l_messages); }; 

# All sources, since we want to archive local and remote logs
log { source (s_local); source (s_stunnel); filter (f_authinfo);
     destination (r_authlog);   };
log { source (s_local); source (s_stunnel); filter (f_mail);
     destination (r_maillog);   };
log { source (s_local); source (s_stunnel); filter (f_local0);
   destination (r_ipflog);      };
log { source (s_local); source (s_stunnel); filter (f_local1);
   destination (r_imaplog);     };
log { source (s_local); source (s_stunnel); filter (f_syslog);
   destination (r_syslog);      };
log { source (s_local); source (s_stunnel); filter (f_emerg); 
      filter (f_user_none);
      destination (l_console);  };
log { source (s_local); source (s_stunnel); filter (f_mesg);
   filter (f_user_none);
      destination (l_messages); };

Dans cet exemple de client, syslog-ng.conf, les filtres demeurent identiques, mais beaucoup des autres parties de la configuration changent pour refléter l'état du client ou sont supprimées :

# Options
options { 
          sync(0);
          use_fqdn(yes);
        };

# Sources of syslog messages (only local on clients)
source s_local { 
                 sun-streams("/dev/log" door("/etc/.syslog_door")); 
                 internal();
               };

# Destinations: local files, the console, and the remote syslog server
destination l_authlog  { file ("/var/log/authlog");   };
destination l_messages { file ("/var/log/messages");  };
destination l_maillog  { file ("/var/log/maillog");   };
destination l_ipflog   { file ("/var/log/ipflog");    };
destination l_imaplog  { file ("/var/log/imaplog");   };
destination l_console  { file ("/dev/console");       };
destination l_syslog   { file ("/var/log/syslog");    };
destination stunnel    { tcp ("127.0.0.1", port(514)); };

# Level Filters
filter f_emerg   { level (emerg);            };
filter f_alert   { level (alert .. emerg);   };
filter f_crit    { level (crit .. emerg);    };
filter f_err     { level (err .. emerg);     };
filter f_warning { level (warning .. emerg); };
filter f_notice  { level (notice .. emerg);  };
filter f_info    { level (info .. emerg);    };
filter f_debug   { level (debug .. emerg);   };

# Facility Filters
filter f_kern   { facility (kern);   };
filter f_user   { facility (user);   };
filter f_mail   { facility (mail);   };
filter f_daemon { facility (daemon); };
filter f_auth   { facility (auth);   };
filter f_syslog { facility (syslog); };
filter f_lpr    { facility (lpr);    };
filter f_news   { facility (news);   };
filter f_uucp   { facility (uucp);   };
filter f_cron   { facility (cron);   };
filter f_local0 { facility (local0); };
filter f_local1 { facility (local1); };
filter f_local2 { facility (local2); };
filter f_local3 { facility (local3); };
filter f_local4 { facility (local4); };
filter f_local5 { facility (local5); };
filter f_local6 { facility (local6); };
filter f_local7 { facility (local7); }; 

# Custom Filters
filter f_user_none     { not facility (user);                     };
filter f_kern_debug    { filter (f_kern) and filter (f_debug);    };
filter f_daemon_notice { filter (f_daemon) and filter (f_notice); };
filter f_mail_crit     { filter (f_mail) and filter (f_crit);     };
filter f_mesg          { filter (f_kern_debug) or 
                         filter (f_daemon_notice) or 
                         filter (f_mail_crit);                    };
filter f_authinfo      { filter (f_auth) or program (sudo);       };

# Log statements
# Log things locally
log { source (s_local); filter (f_authinfo); destination (l_authlog);  };
log { source (s_local); filter (f_mail);     destination (l_maillog);  };
log { source (s_local); filter (f_local0);   destination (l_ipflog);   };
log { source (s_local); filter (f_local1);   destination (l_imaplog);  };
log { source (s_local); filter (f_syslog);   destination (l_syslog);   };
log { source (s_local); filter (f_emerg); filter (f_user_none); 
                                             destination (l_console);  };
log { source (s_local); filter (f_mesg); filter (f_user_none);
                                             destination (l_messages); }; 

# Log everything remotely via stunnel
log { source (s_local);                      destination (stunnel);    };

D'autres utilisations avancées de syslog-ng comprennent l'envoi de messages du journal directement à un logiciel d'exploration de données, à des bases de données, à la messagerie ou à l'imprimante, en fonction de l'importance du message. Vous pouvez aussi envoyer des messages du journal de haute priorité à un fichier qui peut être surveillé par un analyseur de journal en temps réel comme swatch, logsurfer, Log Tool ou Logwatch. Les possibilités d'exploration et de surveillance des données automatisées sont étendues, car les entrées de journal peuvent être organisées et traitées de différentes manières.