Distribution EOLE

{{toc}}

h1. Gestion des journaux

Les objectifs fondamentaux de la journalisation sont les suivants :

* conserver l'information en vue d'établir des diagnostics de panne et d'incidents de sécurité,

* conserver l'information en vue de statistiques d'utilisation,

* conserver l'information par contrainte légale.

Les écueils à éviter sont les suivants :

* saturation de la partition stockant les journaux,

* compromission des informations des journaux par application de droits d'accès inadaptés.

Ces objectifs et écueils guident la politique de journalisation à mettre en œuvre. Les contraintes les plus fortes sont l'obligation légale de conserver l'information et le risque de saturation du support de stockage. Les journaux, ou partie de journaux, concernés par l'obligation légale doivent être traités prioritairement. Les autres doivent s’accommoder de la contrainte d'espace de stockage.

h2. Recommandations de l'ANSSI (2 décembre 2013)

Voici les recommandations issues du guide "Recommandations de sécurité pour

la mise en œuvre d’un système de journalisation" accessible à l'adresse http://www.ssi.gouv.fr/fr/bonnes-pratiques/recommandations-et-guides/

Elles s'accompagnent de l'état des lieux pour la distribution EOLE.

h3. Recommandation 1

Utiliser des systèmes et des applicatifs disposant nativement d’une fonctionnalité de jour-

nalisation est primordial. La prise en compte de cette fonction doit se faire lors de toute

démarche de conception et de développement.

h3. Recommandation 2

L’horodatage doit être activé pour l’ensemble des évènements afin de permettre une

meilleure exploitation des journaux.

*EOLE*

Tous les journaux passant par rsyslog sont horodatés. Cependant, la date est au format "legacy" et n'est pas aussi précise qu'elle pourrait l'être.

h3. Recommandation 3

Les horloges des équipements doivent être synchronisées sur plusieurs sources de temps

internes cohérentes entre elles. Ces sources pourront elles-mêmes être synchronisées sur

plusieurs sources fiables externes, sauf pour les réseaux isolés.

*EOLE*

Aucune mesure particulière n'est prise pour s'assurer de disposer d'horloges synchronisées sur l'ensemble d'un parc surveillé.

Le serveur ntp par défaut est sur Internet.

Au MEDDE, la politique de déploiement s'appuie sur des serveurs ntp internes permettant la synchronisation des équipements d'un même parc.

h3. Recommandation 4

Lors du dimensionnement des équipements, l’estimation de l’espace de stockage nécessaire

à la conservation locale des journaux est indispensable.

*EOLE*

Le partitionnement n'est pas conditionné à l'utilisation du module. Le volume de la partition montée sur /var est variable selon les modules :

* 2.3 :

  * *amon* : 700 1500 *-1* ext4

  * *scribe* : 3000 6000 *9000* ext4

  * *horus* : 3000 9000 *15000* ext4

  * *sphynx* : 700 1500 *-1* ext4

  * *seshat* : 2048 2048 *-1* ext4

  * *zephir* : 700 1500 *-1* ext4

  * *amonecole* : 8096 15360 *20480* ext4

  * *amonhorus* : 8096 15360 *20480* ext4

  * *amonecole-eclair* : 8096 15360 *20480* ext4

  * *zephirlog* : 10240 10240 *-1* ext4

* 2.4 :

  * *amon* : 700 1500 *-1* ext4

  * *scribe* : 3000 6000 *9000* ext4

  * *horus* : 3000 9000 *15000* ext4

  * *sphynx* : 700 1500 *-1* ext4

  * *seshat* : 2048 1024 *-1* ext4

  * *zephir* : 700 1500 *-1* ext4 

  * *amonecole* : 8096 15360 *20480* ext4

  * *amonhorus* : 8096 15360 *20480* ext4

  * *amonecole-eclair* : 8096 15360 *20480* ext4

  * *zephirlog* : 10240 10240 *-1* ext4

  * *sentinelle* : 2048 20480 *-1* ext4

  * *thot* : 2048 20480 *-1* ext4

De plus, il n'y a pas une partition spécifique pour le point de montage /var/log excepté pour le module *sentinelle* en 2.3.

h3. Recommandation 5

Les journaux doivent être automatiquement exportés sur une machine physique différente

de celle qui les a générés.

*EOLE*

L'export des journaux passant par rsyslog peut être automatisé.

h3. Recommandation 6

Les journaux de l’ensemble des équipements du système d’information doivent être trans-

férés sur un ou plusieurs serveurs centraux dédiés.

*EOLE*

La disponibilité des divers protocoles mis en œuvre permet de centraliser les journaux de tous les équipements d'un réseau a priori.

L'envoi depuis une même machine ne peut toutefois pas être réparti sur plusieurs serveurs centraux.

h3. Recommandation 7

Si le parc d’équipements qui génère des journaux est important, le serveur central devra

être redondé afin d’accroître la disponibilité du service de collecte de journaux.

*EOLE*

Pas de mécanisme de redondance prévu pour le serveur de centralisation des journaux à ce stade.

h3. Recommandation 8

Si la taille ou la typologie du système d’information le nécessite, une approche hiérarchique

pour l’organisation des serveurs de collecte doit être retenue.

*EOLE*

Une approche hiérarchique est possible, tous les modules pouvant émettre et réceptionner les journaux.

Cependant, l'identification de l'émetteur primaire peut poser problème : l'option de routage des messages choisie pour raison de performance n'identifie que le dernier serveur de la chaîne de transmission.

Le problème de performance observé avec l'option qui permet d'identifier l'émetteur est dû à des requête dns nombreuses.

h3. Recommandation 9

Si le contexte le permet, un transfert en temps réel des journaux sur les serveurs centraux

doit être privilégié.

*EOLE*

Ce fonctionnement est permis

h3. Recommandation 10

Il est recommandé de ne pas effectuer de traitement sur les journaux avant leur transfert.

*EOLE*

Le seul traitement (à ma connaissance) qui intervient est l'anonymisation des logs de surfs ; ce traitement ne touche pas aux journaux originaux.

h3. Recommandation 11

Il est recommandé d’utiliser des protocoles d’envoi de journaux basés sur TCP pour fia-

biliser le transfert de données entre les machines émettrices et les serveurs centraux.

*EOLE*

En envoi depuis un module EOLE, seuls les protocoles connectés sont autorisés dans l'interface de configuration : RELP et TLS over TCP.

Il y a cependant une demande insistante pour permettre l'envoi en UDP.

h3. Recommandation 12

Il est recommandé d’utiliser des protocoles de transfert de journaux qui s’appuient sur des

mécanismes cryptographiques robustes en particulier lorsque les données transitent sur des

réseaux non maîtrisés.

*EOLE*

rsyslog, utilisé pour la transmission des journaux, propose uniquement TLS over TCP.

h3. Recommandation 13

Il est recommandé de bien contrôler la bande passante des flux réseau utilisée pour trans-

férer les journaux d’évènements.

*EOLE*

La distribution n'intègre, actuellement, pas d'outils de qos permettant de gérer la bande passante en fonction du port ou de marquer le paquet concernant l'émission des journaux.

h3. Recommandation 14

Lorsque le besoin de sécurité pour le transfert des journaux est important, il doit se faire

sur un réseau d’administration dédié.

h3. Recommandation 15

S’il n’existe pas de réseaux d’administration dans l’architecture pour accueillir les serveurs

de journalisation, ils doivent être placés dans une zone interne non exposée directement à

des réseaux qui ne sont pas de confiance (par exemple Internet).

h3. Recommandation 16

Une partition disque doit être dédiée au stockage des journaux d’évènements sur les

équipements qui les génèrent ou qui les centralisent.

*EOLE*

Voir recommandation 4 : actuellement, seul le module sentinelle 2.3 prévoit une partition à part pour les logs.

h3. Recommandation 17

Il est recommandé d’adopter une arborescence pour le stockage des journaux d’évènements.

*EOLE*

Une arborescence personnalisable via des filtres rsyslog est proposée dans les modules EOLE.

h3. Recommandation 18

Une politique de rotation des journaux d’évènements doit être formalisée et mise en œuvre

sur l’ensemble des équipements du système de journalisation.

*EOLE*

Une politique de rotation par défaut est utilisée lorsque certains journaux ne bénéficient pas d'une rotation.

h3. Recommandation 19

La durée de conservation des fichiers de journaux étant soumise à des contraintes légales

et réglementaires, il convient d’en prendre connaissance pour définir les moyens techniques

nécessaire à l’archivage des journaux.

*EOLE*

Les journaux du proxy sont les seuls sauvegardés en plus d'être conservés sur la machine pour une durée de 1 an.

h3. Recommandation 20

L’accès aux journaux doit être limité en écriture à un nombre restreint de comptes ayant

le besoin d’en connaître.

*EOLE*

Le répertoire des journaux est la propriété de syslog:adm

h3. Recommandation 21

Les processus de journalisation et de collecte doivent être exécutés par des comptes dis-

posant de peu privilèges.

*EOLE*

rsyslog abandonne les privilèges root (nécessaires pour ouvrir le port 512 udp) et écrit les journaux en tant que syslog.

h3. Recommandation 22

Un outil spécifique doit être utilisé pour une meilleure exploitation des journaux présents

sur les serveurs centraux, la détection d’évènements anormaux en sera facilitée.

*EOLE*

Aucun outil n'est proposé actuellement.

Graylog2, Logstash-elasticsearsh-kibana ont été testés mais non intégrés.

h3. Recommandation 23

Les comptes ayant accès à l’outil de consultation centralisée des journaux doivent être

associés à des rôles prédéterminés.

h3. Recommandation 24

L’espace disque des équipements qui génèrent et stockent les journaux doit être surpervisé.

h2. Contextes de journalisation

La gestion des journaux d'une distribution EOLE est guidée par différents contextes d'utilisation. Un contexte d'utilisation est une topologie réseau particulière de machines, virtuelles ou physiques, à laquelle s'applique une politique de journalisation commune. Les rôles possibles dans un réseau sont :

* une machine émettrice : transmission des journaux à une machine réceptrice ;

* une machine réceptrice : conservation des journaux locaux, réception des journaux de machines émettrices.

Les machines émettrices se déclinent en matériel réseau, machines physiques et conteneurs LXC. Cette distinction introduit une distinction entre les machines réceptrices qui ne gèrent que les conteneurs qu'elles hébergent et celles qui centralisent les journaux de matériels physiques distants. Certains modules de la distribution EOLE se prêtent plus à l'exécution d'un rôle particulier. ZéphirLog, notamment a été créé pour assumer le rôle de machine réceptrice vis-à-vis des autres modules. Cependant, la modularité permet à un autre module de jouer ce rôle. L'utilisation du mode conteneur ou non est plus contraignant sur les rôles par contre.

h3. Solution EOLE en mode non conteneur

Une machine en mode non conteneur est le cas le plus simple :

* un seul environnement d'exécution ;

* la machine peut jouer les rôles de machine émettrice et transmettre ses journaux et de machine réceptrice et recevoir des journaux.

h3. Solution EOLE en mode conteneur

Une machine en mode conteneur amène un autre niveau :

* une hiérarchie d'environnement d'exécution à deux niveaux :

** un maître ;

** des conteneurs ;

* les conteneurs jouent le rôle de machines émettrices et transmettent leurs journaux ;

* les maîtres jouent forcément le rôle de machines réceptrices, au moins vis-à-vis des conteneurs, et peuvent jouer le rôle de machines émettrices et transmettre leurs journaux.

h3. Autre

Le reste du matériel participant au réseau (équipement réseau, machines clientes hors solutions EOLE, etc.) jouent le rôle de machines émettrices dans la structure envisagée.

h2. La problématique de la transmission réseau

Une machine réceptrice peut potentiellement recevoir de plusieurs sources : 

* des conteneurs ;

* des machines distantes pouvant utiliser le protocole RELP ;

* des machines distantes pouvant utiliser le protocole TCP ;

* des machines distantes pouvant utiliser le protocole UDP.

La transmission devant être fiable, le protocole RELP est à privilégier, ainsi que l'usage des queues, essentiellement pour les journaux à valeur légale. Le protocole TCP est encore incontournable pour l'utilisation d'une liaison sécurisée avec GnuTLS. Le protocole UDP est à réserver pour les équipements ne pouvant utiliser le protocole TCP ou RELP.

Il doit être possible de trier les journaux par zone émettrice. Différentes granularités sont envisageables pour définir les zones émettrices. La granularité la plus grossière distingue la zone interne (les conteneurs) de la zone externe.

h2. Les services

Les services prioritaires sont ceux dont les journaux ont une valeur légale et une durée de rétention prévue par la loi.

h2. La configuration de rsyslog dans EOLE

Le service rsyslog est démarré par défaut sur tous les modules EOLE, maître et conteneurs.

La configuration minimale est composée d'une partie commune et de fichiers de configuration rattachés aux différents services.

La stratégie d'agrégation des journaux est décidée à l'instanciation.

h3. La configuration minimale

* Sur le maître, sur un module en mode conteneur ou non conteneur :

** Un dispatcher pour les journaux locaux et conteneurs dans @/var/log/rsyslog/local/<APPLI>/<APPLI>.<SEVERITY>.log@

** Un dispatcher pour les journaux des hôtes réseaux dans @/var/log/rsyslog/remote/<HOSTNAME>/<APPLI>/<APPLI>.<SEVERITY>.log@

* Sur les conteneurs :

** Des règles avec mise en place de queues pour les journaux sensibles

** Une règle globale pour le reste

h3. L'agrégation

L'agrégation des journaux des conteneurs sur le maître est imposée.

Le choix du mode d'agrégation porte sur :

* l'activation de l'envoi : spécification de l'adresse de destination, protocole imposé (RELP), port imposé (20515 ?) ;

* l'activation de la réception :

** réception de clients utilisant RELP : schéma de répartition, liste des adresses des clients, port imposé (20515 ?) ;

** réception de clients utilisant TCP : schéma de répartition, liste des adresses des clients, port imposé (10514 ?) ;

** réception de clients utilisant UDP : schéma de répartition, liste des adresses des clients, port imposé (514) ;

* utilisation du chiffrement : emplacement du certificat.

h3. L'organisation de la configuration (< EOLE 2.3.9)

La lecture séquentielle de la configuration de rsyslog impose une organisation particulière :

* les modules (entrée, sortie) doivent être chargés avant d'être utilisés ;

* les ensembles de règles doivent être spécifiés avant d'être associés aux entrées ;

* les modèles doivent être spécifiés avant d'être utilisés ;

* les messages ne doivent pas être sortis de la chaîne de traitement prématurément.

Plages de fichiers :

00-09 : fichiers EOLE contenant la configuration générique en début de chaîne de traitement

10-19 : fichiers EOLE de règles non-destructrices

20-49 : fichiers de règles personnalisées non-destructrices

50 : seuil d'utilisation de & ~ pour enlever les messages de la file après traitement

50-79 : fichiers de règles personnalisées destructrices

80-98 : fichiers EOLE de règles destructrices

99-general_dispatch.conf

h4. rsyslog.conf

eole-common:source:tmpl/rsyslog.conf

<pre>

$ModLoad imuxsock # provides support for local system logging

$ModLoad immark  # provides --MARK-- message capability

# commented in container (eole-conteneur/lxc_install.sh l.216-7)

$ModLoad imklog   # provides kernel logging support (previously done by rklogd)

$KLogPath /proc/kmsg

$PreserveFQDN on

# utilisation du protocole RELP

%if %%mode_conteneur_actif == 'oui' or %%activer_reception_logs_relp == 'oui'

$ModLoad imrelp

$InputRELPServerRun 20514

%end if

# utilisation du protocole TCP

%if %%activer_reception_logs_tcp == 'oui'

$ModLoad imtcp

# utilisation du chiffrement

%if %%rsyslog_tls == "oui" and (%%rsyslog_envoi_tls == "oui" or %%rsyslog_reception_tls == "oui")

# configuration general pour le chiffrement

$DefaultNetstreamDriver gtls

$DefaultNetstreamDriverCAFile %%rsyslog_ca_file

$DefaultNetstreamDriverCertFile  /etc/ssl/certs/eole.crt

$DefaultNetstreamDriverKeyFile  /etc/ssl/certs/eole.key

# configuration propre a la reception

%if %%rsyslog_reception_tls == "oui"

$InputTCPServerStreamDriverMode 1

$InputTCPServerStreamDriverAuthMode anon

%for %%client_ip in %%adresses_ip_clients_logs_tcp

$InputTCPServerStreamDriverPermittedPeer %%client_ip

%end for

%end if

%end if

$AllowedSender TCP, %%custom_join(%%adresses_ip_clients_logs_tcp, separator=', ')

$InputTCPServerRun 10514

%end if

# utilisation du protocole UDP

%if %%activer_reception_logs_udp == 'oui'

$ModLoad imudp

$AllowedSender UDP, %%custom_join(%%adresses_ip_clients_logs_udp, separator=', ')

$UDPServerRun 514

%end if

###########################

#### GLOBAL DIRECTIVES ####

###########################

#

# Use traditional timestamp format.

# To enable high precision timestamps, comment out the following line.

#

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Filter duplicated messages

$RepeatedMsgReduction on

#

# Set the default permissions for all log files.

#

$FileOwner syslog

$FileGroup adm

$FileCreateMode 0640

$DirCreateMode 0755

$Umask 0022

$PrivDropToUser syslog

$PrivDropToGroup adm

#

# Include all config files in /etc/rsyslog.d/

#

$IncludeConfig /etc/rsyslog.d/*.conf

</pre>

h4. rsyslog.d/

eole-common:source:tmpl/00-aggregation.conf

<pre>

%if %%is_defined('activer_envoi_logs') and %%activer_envoi_logs == 'oui'

%if %%rsyslog_envoi_tls == 'non'

$ModLoad omrelp

%end if

$WorkDirectory /var/log/rsyslog

$ActionQueueType LinkedList

%if %%is_defined('activate_squid_realtime') and %%activate_squid_realtime == 'non'

$ActionQueueDequeueTimeBegin %%squid_heure_debut

$ActionQueueDequeueTimeEnd %%squid_heure_fin

%end if

$ActionQueueFileName relpact

$ActionQueueSaveOnShutdown on

%if %%rsyslog_envoi_tls == 'oui'

$ActionSendStreamDriverAuthMode anon

$ActionSendStreamDriverPermittedPeer %%adresse_ip_serveur_logs

$ActionSendStreamDriverMode 1

:programname, isequal, "squid" @@%%adresse_ip_serveur_logs:10514

$ActionSendStreamDriverAuthMode anon

$ActionSendStreamDriverPermittedPeer %%adresse_ip_serveur_logs

$ActionSendStreamDriverMode 1

:programname, !isequal, "squid"	@@%%adresse_ip_serveur_logs:10514

%else

:programname, isequal, "squid" :omrelp:%%adresse_ip_serveur_logs:20514

:programname, !isequal, "squid" :omrelp:%%adresse_ip_serveur_logs:20514

%end if

%else

# cette machine n'est pas configurée pour transmettre ses logs à une machine distante

%end if

</pre>

eole-common:source:tmpl/00-conteneur.conf

<pre>

$ModLoad omrelp

$WorkDirectory /var/log/rsyslog

$ActionQueueType LinkedList

%if %%is_defined('activate_squid_realtime') and %%activate_squid_realtime == 'non'

$ActionQueueDequeueTimeBegin %%squid_heure_debut

$ActionQueueDequeueTimeEnd %%squid_heure_fin

%end if

$ActionQueueFileName relpact

$ActionQueueSaveOnShutdown on

:programname, isequal, "squid" :omrelp:%%adresse_ip_br0:20514

& ~

*.*	:omrelp:%%adresse_ip_br0:20514

& ~

</pre>

eole-common:source:tmpl/01-templates.conf

<pre>

$template DynLocalDispatch, "/var/log/rsyslog/local/%programname%/%programname%.%syslogseverity-text%.log"

$template DynRemoteDispatch, "/var/log/rsyslog/remote/%hostname:::secpath-replace%/%programname%/%programname%.%syslogseverity-text%.log"

</pre>

eole-common:source:tmpl/10-erreurs.conf

<pre>

*.err  /var/log/syslog

</pre>

20-auth.conf

<pre>

$template DynLocalAuth, "/var/log/rsyslog/local/auth/auth.%syslogseverity-text%.log"

$template DynRemotelAuth, "/var/log/rsyslog/remote/%hostname:::secpath-replace%/auth/auth.%syslogseverity-text%.log"

%if %%activer_reception_logs == 'non'

auth, authpriv.* ?DynLocalAuth

%else

if $syslogfacility-text startswith 'auth' and $fromhost-ip startswith '127' then ?DynLocalAuth

%if %%mode_conteneur_actif == 'oui'

if $syslogfacility-text startswith 'auth' and $fromhost-ip startswith '%%adresse_ip_br0[:-2]' then ?DynLocalAuth

%end if

if $syslogfacility-text startswith 'auth' and not ($fromhost-ip startswith '%%adresse_ip_br0[:-2]' or $fromhost-ip startswith '127') then ?DynRemoteAuth

%end if

</pre>

50-79….conf : les règles personnalisées pour filter les services individuellement sur le modèle de 80-rsyslog.conf

eole-common:source:tmpl/80-rsyslog.conf

<pre>

$template DynLocalRsyslog, "/var/log/rsyslog/local/rsyslog/rsyslog.%syslogseverity-text%.log"

$template DynRemoteRsyslog, "/var/log/rsyslog/remote/%hostname:::secpath-replace%/rsyslog/rsyslog.%syslogseverity-text%.log"

%if %%activer_reception_logs == 'non'

:programname, startswith, "rsyslog" ?DynLocalRsyslog

%else

if $programname startswith 'rsyslog' and $fromhost-ip startswith '127' then ?DynLocalRsyslog

& ~

%if %%mode_conteneur_actif == 'oui'

if $programname startswith 'rsyslog' and $fromhost-ip startswith '%%adresse_ip_br0[:-2]' then ?DynLocalRsyslog

& ~

%end if

:programname, startswith, "rsyslog" ?DynRemoteRsyslog

& ~

%end if

</pre>

eole-common:source:tmpl/99-general_dispatch.conf

<pre>

%if %%activer_reception_logs == 'non'

*.* ?DynLocalDispatch

%else

:fromhost-ip, isequal, "127" ?DynLocalDispatch

& ~

%if %%mode_conteneur_actif == 'oui'

:fromhost-ip, startswith, "%%adresse_ip_brO[:-2]" ?DynLocalDispatch

& ~

%end if

*.* ?DynRemoteDispatch

%end if

</pre>

Actuellement, les services qui disposent de règles spécifiques sont squid, charon, iptables, ufw, smbd, nmbd, named, exim4. Une règle générale peut être ajoutée pour traiter les autres cas. Ces règles personnalisées ne sont pas essentielles sauf dans le cas de fork (exemple de rsyslog qui ajoute le numéro de PID au nom de programme de ses différentes instances). Dans ce cas, il faut une règle avec une expression régulière ou startswith (ou utiliser la facility si elle est univoque).

h3. L'organisation de la configuration (>= EOLE 2.3.9)

La lecture séquentielle de la configuration de rsyslog impose une organisation particulière :

* les modules (entrée, sortie) doivent être chargés avant d'être utilisés ;

* les ensembles de règles doivent être spécifiés avant d'être associés aux entrées ;

* les modèles doivent être spécifiés avant d'être utilisés ;

* les messages ne doivent pas être sortis de la chaîne de traitement prématurément.

Sous-dossiers et fichiers du répertoire /etc/rsyslog.d :

* aggregation/ : contient les règles pour l'envoi des journaux à une machine distante ;

* templates/ : contient les modèles dynamiques (peuvent aussi être placés en en-tête des filtres) ;

* eole_views/ : contient les vues (filtres qui ne sortent pas les messages de la chaîne de traitement) définies par EOLE ;

* custom_views/ : contient les vues (filtres qui ne sortent pas les messages de la chaîne de traitement) définies localement ;

* custom_traps/ : contient les pièges (filtres qui sortent les messages de la chaîne de traitement) définies localement ;

* eole_traps/ : contient les pièges (filtres qui sortent les messages de la chaîne de traitement) définies par EOLE ;

* default_dispatch.conf : filtre générique.

h4. rsyslog.conf

eole-common:source:tmpl/rsyslog.conf@476ca7cd

Le changement porte sur l'inclusion des fragments de configuration et le déplacement de la directive d'import du module omrelp.

<pre>

#  /etc/rsyslog.conf    Configuration file for rsyslog.

#

#                       For more information see

#                       /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html

#

#  Default logging rules can be found in /etc/rsyslog.d/50-default.conf

#################

#### MODULES ####

#################

$ModLoad imuxsock # provides support for local system logging

$ModLoad immark  # provides --MARK-- message capability

# commented in container (eole-conteneur/lxc_install.sh l.216-7)

$ModLoad imklog   # provides kernel logging support (previously done by rklogd)

$KLogPath /proc/kmsg

$PreserveFQDN on

# utilisation du chiffrement

%if %%activer_log_distant == 'oui' and ((%%activer_reception_logs_tcp == 'oui' and %%rsyslog_reception_tls == 'oui' ) or (%%activer_envoi_logs == "oui" and %%rsyslog_envoi_tls == "oui"))

# configuration general pour le chiffrement

$DefaultNetstreamDriver gtls

$DefaultNetstreamDriverCAFile %%rsyslog_ca_file

$DefaultNetstreamDriverCertFile  %%rsyslog_cert_file

$DefaultNetstreamDriverKeyFile  %%rsyslog_privkey_file

%end if

# utilisation du protocole RELP

%if %%mode_conteneur_actif == 'oui' or (%%activer_log_distant == 'oui' and %%activer_reception_logs == 'oui' and %%activer_reception_logs_relp == 'oui')

$ModLoad imrelp

$InputRELPServerRun 20514

%end if

# utilisation du protocole TCP

%if %%activer_log_distant == 'oui' and %%activer_reception_logs == 'oui' and %%activer_reception_logs_tcp == 'oui'

$ModLoad imtcp

# configuration TLS propre a la reception

%if %%rsyslog_reception_tls == "oui"

$InputTCPServerStreamDriverMode 1

$InputTCPServerStreamDriverAuthMode x509/name

$IncludeConfig /etc/rsyslog.d/incoming_peers/*.peers

%end if

$InputTCPServerRun 10514

%end if

# utilisation du protocole UDP

%if %%activer_log_distant == 'oui' and %%activer_reception_logs == 'oui' and %%activer_reception_logs_udp == 'oui'

$ModLoad imudp

$AllowedSender UDP%slurp

%for %%adresse in %%adresses_ip_clients_logs_udp

, %%adresse/%%calc_classe(%%adresse.netmask_client_logs_udp)%slurp

%end for

$UDPServerRun 514

%end if

###########################

#### GLOBAL DIRECTIVES ####

###########################

#

# Use traditional timestamp format.

# To enable high precision timestamps, comment out the following line.

#

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Filter duplicated messages

$RepeatedMsgReduction on

#

# Set the default permissions for all log files.

#

$DirOwner syslog

$DirGroup adm

$FileOwner syslog

$FileGroup adm

$FileCreateMode 0640

$DirCreateMode 0755

$Umask 0022

$PrivDropToUser syslog

$PrivDropToGroup adm

%if %%activer_log_distant == 'oui' and %%activer_envoi_logs == 'oui' and  %%rsyslog_envoi_tls == 'non'

#

# Use omrelp module to send logs.

#

$ModLoad omrelp

%end if

#

# Include config files in /etc/rsyslog.d/

#

$IncludeConfig /etc/rsyslog.d/aggregation/*.conf

$IncludeConfig /etc/rsyslog.d/templates/*.conf

$IncludeConfig /etc/rsyslog.d/eole-views/*.conf

$IncludeConfig /etc/rsyslog.d/custom-views/*.conf

$IncludeConfig /etc/rsyslog.d/custom-traps/*.conf

$IncludeConfig /etc/rsyslog.d/eole-traps/*.conf

$IncludeConfig /etc/rsyslog.d/default_dispatching.conf

</pre>

h4. rsyslog.d/

h5. aggregation

Le répertoire aggregation regroupe les règles pour l'envoi à un serveur distant.

eole-common:source:tmpl/rsyslog_aggregation.conf@476ca7cd

L'import du module omrelp est supprimé (ajouté dans rsyslog.conf) et la possibilité de définir une plage horaire pour l'envoi différé est ajoutée (expérimental).

<pre>

%if %%activer_log_distant == 'oui' and %%activer_envoi_logs == 'oui' and %%envoyer_tous_logs == 'oui'

$WorkDirectory /var/log/rsyslog/queues

$ActionQueueType LinkedList

  %if %%utiliser_rsyslog_plage_envoi_globale == 'oui' and %%rsyslog_plage_globale_heure_debut != '' and %%rsyslog_plage_globale_heure_fin != ''

$ActionQueueSize 10000

$ActionQueueDequeueTimeBegin %%rsyslog_plage_globale_heure_debut

$ActionQueueDequeueTimeEnd %%rsyslog_plage_globale_heure_fin

  %end if

$ActionQueueFileName send_all

$ActionQueueSaveOnShutdown on

  %if %%rsyslog_envoi_tls == 'oui'

$ActionSendStreamDriverAuthMode x509/name

$IncludeConfig /etc/rsyslog.d/outgoing_peers/*.peers

$ActionSendStreamDriverMode 1

*.* @@%%adresse_ip_serveur_logs:10514

  %else

*.* :omrelp:%%adresse_ip_serveur_logs:20514

  %end if

%else

# Cette machine n'est pas configurée pour transmettre ses logs en globalité à une machine distante.

%end if

</pre>

h5. templates

Le dossier templates regroupe les directives template de rsyslog.

eole-common:source:tmpl/rsyslog_templates.conf@476ca7cd

<pre>

$template DynLocalDispatch, "/var/log/rsyslog/local/%programname%/%programname%.%syslogseverity-text%.log"

$template DynRemoteDispatch, "/var/log/rsyslog/remote/%fromhost%/%programname%/%programname%.%syslogseverity-text%.log"

</pre>

eole-common:source:tmpl/rsyslog_errors.conf@476ca7cd

<pre>

*.err  /var/log/syslog

</pre>

h5. eole-views

Le dossier eole-views contient les règles "passantes" élaborées par EOLE.

eole-common:source:tmpl/rsyslog_views_auth.conf@476ca7cd

<pre>

$template DynLocalAuth, "/var/log/rsyslog/local/auth/auth.%syslogseverity-text%.log"

$template DynRemoteAuth, "/var/log/rsyslog/remote/%fromhost%/auth/auth.%syslogseverity-text%.log"

%if %%activer_reception_logs == 'non'

auth, authpriv.* ?DynLocalAuth

%else

if $syslogfacility-text startswith 'auth' and $fromhost-ip startswith '127' then ?DynLocalAuth

 %if %%mode_conteneur_actif == 'oui'

if $syslogfacility-text startswith 'auth' and ($fromhost-ip startswith '%%adresse_ip_br0[:-2]' or $fromhost startswith '%%adresse_ip_br0[:-2]') then ?DynLocalAuth

if $syslogfacility-text startswith 'auth' and not ($fromhost-ip startswith '%%adresse_ip_br0[:-2]' or $fromhost startswith '%%adresse_ip_br0[:-2]' or $fromhost-ip startswith '127') then ?DynRemoteAuth

 %else

if $syslogfacility-text startswith 'auth' and not ($fromhost-ip startswith '%%adresse_ip_br0[:-2]' or $fromhost startswith '%%adresse_ip_br0[:-2]' or $fromhost-ip startswith '127') then ?DynRemoteAuth

 %end if

%end if

</pre>

h5. custom-views

Le dossier custom-views est laissé à la disposition des administrateurs souhaitant insérer des règles "passantes".

Les règles personnalisées pour filtrer les services individuellement suivent le modèle de la précédente.

h5. custom-traps

Le dossier custom-traps est laissé à la disposition des administrateurs souhaitant insérer des règles "non passantes".

Les règles personnalisées pour filtrer les services individuellement suivent le modèle de la suivante.

h5. eole-traps

Le dossier eole-traps contient les règles "non passantes" élaborées par EOLE.

eole-common:source:tmpl/rsyslog_traps_rsyslog.conf@476ca7cd

<pre>

$template DynLocalRsyslog, "/var/log/rsyslog/local/rsyslog/rsyslog.%syslogseverity-text%.log"

$template DynRemoteRsyslog, "/var/log/rsyslog/remote/%fromhost%/rsyslog/rsyslog.%syslogseverity-text%.log"

%if %%activer_reception_logs == 'non'

:programname, startswith, "rsyslog" ?DynLocalRsyslog

%else

if $programname startswith 'rsyslog' and $fromhost-ip startswith '127' then ?DynLocalRsyslog

& ~

%if %%mode_conteneur_actif == 'oui'

if $programname startswith 'rsyslog' and $fromhost-ip startswith '%%adresse_ip_br0[:-2]' then ?DynLocalRsyslog

& ~

%end if

:programname, startswith, "rsyslog" ?DynRemoteRsyslog

& ~

%end if

</pre>

h5. default_dispatching.conf

eole-common:source:tmpl/rsyslog_default_dispatching.conf@476ca7cd

<pre>

:fromhost-ip, startswith, "127" ?DynLocalDispatch

& ~

%if %%mode_conteneur_actif == 'oui'

:fromhost-ip, startswith, "%%adresse_ip_br0[:-2]" ?DynLocalDispatch

& ~

# Use fromhost in addition to fromhost-ip since there are issues

# http://dev-eole.ac-dijon.fr/issues/1204#note-4

:fromhost, startswith, "%%adresse_ip_br0[:-2]" ?DynLocalDispatch

& ~

%end if

:fromhost, isequal, "" ?DynLocalDispatch

& ~

%if %%activer_log_distant == 'oui' and %%activer_reception_logs == 'oui'

*.* ?DynRemoteDispatch

& ~

%end if

</pre>

h4. Couverture des règles

Actuellement, les services qui disposent de règles spécifiques sont squid, charon, iptables, ufw, smbd, nmbd, named, exim4. Une règle générale traite les autres cas. Ces règles personnalisées ne sont pas essentielles sauf dans le cas de fork (exemple de rsyslog qui ajoute le numéro de PID au nom de programme de ses différentes instances). Dans ce cas, il faut une règle avec une expression régulière ou startswith (ou utiliser la facility si elle est univoque).

h3. Utilisation des ensembles de règles

Les règles peuvent être regroupées et les groupes exécutées en fonction de la provenance des messages. La dissociation des ports pour les différentes sources permet d'exécuter des jeux de règles différents pour les messages originaires des conteneurs, de machines distantes ou les messages locaux.

Le protocole RELP ne bénéficie pas de la possibilité d'utiliser les ensembles de règles (la directive pour associer un ensemble donné à une connection RELP n'apparaît que dans la version 6.3.6 : la version prévue pour precise est la 5.8.6).

h2. L'arborescence typique

<pre>

/var/log/syslog

├── local

│   ├── exim

│   │   ├── exim.alert

│   │   ├── exim.info

│   │   └── exim.notice

│   └── smbd

│       ├── smbd.debug

│       └── smbd.info

└── remote

    ├── 10.11.12.13

    │   ├── aaa

    │   │   └── aaa.info

    │   └── ipsec

    │       └── ipsec.error

    ├── 15.16.17.18

    │   ├── apache2

    │   │   └── apache2.error

    │   └── kerberos

    │       └── kerberos.info

    └── sw12-4

        └── aaa

            └── aaa.info

</pre>

h2. Rotation des journaux

h3. Principes de logrotate

* options globales : des options peuvent être définies en début de fichier ;

* -overriding : les fichiers sont lus séquentiellement, celui qui parle en dernier à raison- ;

* gobbling : les règles spécifques peuvent utiliser le wildcard * (problème des redondances de règles cependant.

h3. Mise en œuvre de logrotate

Pour composer avec les contraintes de logrotate, on ajoute .log à la fin de chaque fihier. Cela permet d'utiliser le globbing sur un dossier en excluant les journaux archivés.