Les fichiers de logs sur Debian

De Analyse Développement Hacking
Sauter à la navigation Sauter à la recherche

Glider.png

Le wiki : Accueil - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack

Le site : Accueil du site - Annuaire - Blog - Forum - Outils - Utilisateur
Le FTP : Accueil du FTP - Le privatebin : Accueil du privatebin
Le Redmine : Accueil du Redmine

Sommaire

Les fichiers de logs sur Debian

Introduction

# Configurer la journalisation des logs pour collecter toutes les problématiques ou tentatives de piratage.
# L'analyse des fichiers de logs est utile pour découvrir une mauvaise configuration logicielle qui pourrait ouvrir votre système à diverses attaques.

Fichiers de logs du répertoire /tmp/

En cas de piratage notamment, l'ajout de fichiers sur le serveur peut laisser des logs dans "/tmp" suite au téléchargement d'un code perl ou php stocké dans ce répertoire.

Fichiers de logs du répertoire /var/log/

# Les fichiers de logs suivants se trouvent dans le dossier "/var/log/" depuis un système GNU/Linux Debian.
# Les droits, propriétaire et groupe suivants sont ceux appliqués suite à une nouvelle installation :
-rw-r--r--  1 root root alternatives.log
drwxr-xr-x  2 root root apt
-rw-r-----  1 root adm auth.log
-rw-r--r--  1 root root bootstrap.log
-rw-rw----  1 root utmp btmp
-rw-r--r--  1 root adm cloud-init.log
-rw-r--r--  1 root root cloud-init-output.log
-rw-r-----  1 root adm daemon.log
-rw-r-----  1 root adm debug
-rw-r--r--  1 root root dpkg.log
-rw-r--r--  1 root root faillog
-rw-r-----  1 root adm kern.log
-rw-rw-r--  1 root utmp lastlog
-rw-r-----  1 root adm messages
drwxr-xr-x  2 ntp  ntp ntpstats
drwx------  2 root root private
-rw-r-----  1 root adm syslog
-rw-r-----  1 root adm user.log
-rw-rw-r--  1 root utmp wtmp
# Autre exemple de logs pouvant être présents dans "/var/log" :
/var/log/apparmor
/var/log/apt
/var/log/clean
/var/log/ConsoleKit
/var/log/cups
/var/log/dist-upgrade
/var/log/fsck
/var/log/gdm
/var/log/installer
/var/log/news
/var/log/samba
/var/log/speech-dispatcher
/var/log/unattended-upgrades
/var/log/aptitude
/var/log/boot
/var/log/boot.log
/var/log/bootstrap.log
/var/log/daemon.log
/var/log/debug
/var/log/dmesg.0
/var/log/dpkg.log
/var/log/faillog
/var/log/fontconfig.log
/var/log/gufw_log.txt
/var/log/gufw_log_server.txt
/var/log/jockey.log
/var/log/lastlog
/var/log/lpr.log
/var/log/mail.err
/var/log/mail.info
/var/log/mail.log
/var/log/mail.warn
/var/log/messages
/var/log/pm-powersave.log
/var/log/pycentral.log
/var/log/udev
/var/log/ufw.log
/var/log/user.log
/var/log/Xorg.0.log
/var/log/Xorg.0.log.old
/var/log/Xorg.1.log
/var/log/Xorg.2.log

alternatives.log

# Les logs d'update-alternatives.

apache2

# Un dossier contenant les logs de Apache2.

access.log

# Les accès qui génèrent des requêtes vers le serveur Apache2.
# Les requêtes suivantes peuvent être effectuées pour identifier des risques de sécurité :
sudo tail -f /var/log/apache2/access.log
sudo tail -f /var/log/apache2/other_vhosts_access.log
sudo grep 'login.php' /var/log/apache2/access.log
sudo grep 'login' /var/log/apache2/other_vhosts_access.log
sudo egrep -i "denied|error|warn" /var/log/apache2/access.log

error.log

# Les erreurs rencontrées par Apache2.
# Les requêtes suivantes peuvent être effectuées pour identifier des risques de sécurité :
sudo tail -f /var/log/apache2/error.log
sudo grep 'warning' /var/log/apache2/error.log

Exemples d'erreurs rencontrées dans le fichier error.log

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
# Pour corriger l'erreur :
sudo nano /etc/apache2/apache2.conf
# Ajouter l'adresse IP servant à joindre le serveur :
ServerName "Adresse IP du serveur"
# Le message d'erreur ne sera plus affiché.
# Suite à la configuration du fichier hosts, ci-dessous, je commente cette modification.
# Le message d'erreur ne sera plus affiché.
# Il faudrait malgré tout renseigner le nom du serveur, en ajoutant le nom de domaine, par exemple, dans ce fichier :
sudo nano /etc/apache2/conf.d/fqdn
ServerName nom_de_domaine
# Pourquoi Apache2 n'a-t-il pas trouvé de nom de domaine qualifié ? Deux réponses possibles :
# Si l'on vient d'installer Apache. Il n'y a donc pas de configuration et ce n'est pas étonnant qu'il ne trouve pas de nom.
# Par contre sans aucune configuration Apache aurait dû en trouver au moins un, le hostname de la machine !
# Si le serveur est bien configuré, Apache trouve au moins ce nom et n'affiche pas cette erreur.
# Si l'adresse n'est pas trouvée c'est que la configuration du serveur n'est pas terminée.
# Pour vérifier votre nom de machine / hostname il suffit de taper :
hostname -f
# Cette commande doit vous retourner quelque chose comme :
sousdomaine.domaine.tld
# Si ce n’est pas le cas, il faut configurer votre fichier hosts.
# Exemple sur mon serveur VPS :
# Je commente cette première règle, car, pas convaincu qu'elle soit réellement utile.
# 127.0.1.1      vpsXXXXXX       vpsXXXXXX
# Je place la règle 127.0.0.1 en première position.
127.0.0.1       localhost
# La règle sur le nom du VPS en deuxième position.
127.0.1.1       vpsXXXXXX.ovh.net       vpsXXXXXX

# J'ajoute également les règles IPv6 :
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

# A suivre par la suite. Je n'ai pas eu besoin d'avancer d'avantage la configuration, pour stopper le message d'erreur.
# Comment trouver son nom d'hote pour autoriser Require host dans une règle Apache 2.4 ?
# 127.0.1.1      debian.example.com
# 139.99.173.195 tiger-green.fr www.tiger-green.fr
# 127.0.0.1 visionduweb.fr
Hostname provided via SNI and hostname provided via HTTP are different
[Error] Hostname example.com provided via SNI and hostname www.example.com provided via HTTP are different
# Le message d'erreur indique que le comportement a été correctement bloqué. L'URL tierce suivante explique ce qu'Apache protège en émettant l'erreur.
# Noter que mettre des caractères de soulignement underscore dans les noms d'hôte va à l'encontre des RFC et va certainement provoquer ce type de message d'erreur.
AH02032 Hostname xxx provided via SNI and hostname yyy provided via HTTP have no compatible SSL setup
AH02032 Hostname xxx provided via SNI and hostname yyy provided via HTTP have no compatible SSL setup
# L'attaque est appelée "confusion d'hôte virtuel". Le concept de l'attaque est qu'il est possible d'exploiter une discordance entre le nom de la cible dans la négociation TLS (Renseigné par SNI) et le nom de la cible dans le protocole HTTP (Renseigné par HTTP). En fonction de la configuration du serveur, il peut être utilisé pour emprunter l'identité de sites HTTPS appartenant à d'autres personnes, mais également pour voler des cookies de session...
# Si une configuration utilise SNI pour répartir les demandes sur différents serveurs HTTPS, la vérification supplémentaire effectuée par Apache protège l'utilisateur.
# Ressources complémentaires :
Code error AH02032 : https://security.stackexchange.com/questions/134021/what-kind-of-attack-is-prevented-by-apache2s-error-code-ah02032-hostname-prov
Blocking-resistant communication through domain fronting : https://www.bamsoftware.com/papers/fronting/
Server Name Indication : https://en.wikipedia.org/wiki/Server_Name_Indication
TLS Virtual Host Confusion : https://hackerone.com/reports/501
PDF - Network-based Origin Confusion Attacksagainst HTTPS Virtual Hosting : http://antoine.delignat-lavaud.fr/doc/www15.pdf
Vidéo - The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP : https://youtu.be/mOzAofijqYI
Apache + Passenger - Warning: unable to write to /tmp/passenger.spawn.XXXX
App 4081 output: Warning: unable to write to /tmp/passenger.spawn.XXXXKgHZiS/response/steps/preloader_fork_subprocess/state: No such file or directory @ rb_sysopen - /tmp/passenger.spawn.XXXXKgHZiS/response/steps/preloader_fork_subprocess/state
App 4081 output: Warning: unable to write to /tmp/passenger.spawn.XXXXKgHZiS/response/steps/preloader_fork_subprocess/begin_time: No such file or directory @ rb_sysopen - /tmp/passenger.spawn.XXXXKgHZiS/response/steps/preloader_fork_subprocess/begin_time
App 4081 output: Warning: unable to write to /tmp/passenger.spawn.XXXXKgHZiS/response/steps/preloader_fork_subprocess/end_time: No such file or directory @ rb_sysopen - /tmp/passenger.spawn.XXXXKgHZiS/response/steps/preloader_fork_subprocess/end_time
App 4081 output: 
App 4081 output: Error: Broken pipe
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/preloader_shared_helpers.rb:121:in `write'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/preloader_shared_helpers.rb:121:in `block in handle_spawn_command'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/loader_shared_helpers.rb:380:in `run_block_and_record_step_progress'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/preloader_shared_helpers.rb:120:in `handle_spawn_command'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/preloader_shared_helpers.rb:78:in `accept_and_process_next_client'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/preloader_shared_helpers.rb:167:in `run_main_loop'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/helper-scripts/rack-preloader.rb:207:in `<module:App>'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/helper-scripts/rack-preloader.rb:30:in `<module:PhusionPassenger>'
App 4081 output: /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems/passenger-6.0.2/src/helper-scripts/rack-preloader.rb:29:in `<main>'
App 4081 output: 
[ E 2020-02-11 18:02:01.8790 28991/Tbb age/Cor/App/Implementation.cpp:221 ]: Could not spawn process for application /opt/redmine/unis: A timeout occurred while starting a preloader process.
  Error ID: eb50019e
  Error details saved to: /tmp/passenger-error-91bob8.html
[ E 2020-02-11 18:02:03.3655 28991/T5 age/Cor/Con/CheckoutSession.cpp:276 ]: [Client 1-816] Cannot checkout session because a spawning error occurred. The identifier of the error is eb50019e. Please see earlier logs for details about the error.
[ E 2020-02-11 18:02:03.4960 28991/T5 age/Cor/Con/CheckoutSession.cpp:276 ]: [Client 1-818] Cannot checkout session because a spawning error occurred. The identifier of the error is eb50019e. Please see earlier logs for details about the error.
[ E 2020-02-11 18:02:03.4982 28991/T5 age/Cor/Con/CheckoutSession.cpp:276 ]: [Client 1-819] Cannot checkout session because a spawning error occurred. The identifier of the error is eb50019e. Please see earlier logs for details about the error.
[ E 2020-02-11 18:02:03.5006 28991/T5 age/Cor/Con/CheckoutSession.cpp:276 ]: [Client 1-820] Cannot checkout session because a spawning error occurred. The identifier of the error is eb50019e. Please see earlier logs for details about the error.
[ E 2020-02-11 18:02:03.5034 28991/T5 age/Cor/Con/CheckoutSession.cpp:276 ]: [Client 1-821] Cannot checkout session because a spawning error occurred. The identifier of the error is eb50019e. Please see earlier logs for details about the error.
[ N 2020-02-11 18:14:48.8668 28991/T3 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 4367, application /opt/redmine/unis (production)
[ W 2020-02-11 18:15:48.0588 28991/Tbt age/Cor/App/Gro/ProcessListManagement.cpp:342 ]: Detached process (pid=4367, group=/opt/redmine/unis (production)) didn't shut down within 1 minute. Forcefully killing it with SIGKILL.
Une problématique liée à SELinux ?
Je n'ai pas activé SELinux, cela ne semble donc pas correspondre au problème.
The PassengerAgent must be compiled with the 'USE_SELINUX' macro, otherwise it won't properly activate the right SELinux domain. This is needed in addition to installing the policy.
Our RPMs take care of this automatically. But if you build from source then you have to do this yourself.
###
Temporarily go into SELinux permissive mode
setenforce 0
Restart Apache
sudo service apache2 restart
Start using your Rails application
Walk through SELinux log and generate new SELinux policy module
grep apache2 /var/log/audit/audit.log | audit2allow -M passenger
Install newly created SELinux module
semodule -i passenger.pp
Switch SELinux back into enforcing mode
setenforce 1
Source complémentaire : https://github.com/rharmonson/richtech/wiki/SELinux-&-Building-Security-Modules
###
Temporarily go into SELinux permissive mode
setenforce  0
restart apache
apachectl restart
Use your rails app for a while
allow passenger run with selinux
#if can't find audit2allow, you should install it first
#or you can skip 2 commands below
yum  provides  \*/audit2allow
yum  install  policycoreutils-python
grep httpd  /var/log/audit/audit.log | audit2allow -M passenger
#install newly created selinux module
semodule  -i passenger.pp
Switch selinux back to enforcing mode
setenforce 1
Source : http://www.voidcn.com/article/p-gjzksvsr-ep.html
###
Développer quelques exceptions SELinux via audit2allow pour des applications ruby :
Pour continuer à faire fonctionner SELinux, générer un module SELinux personnalisé pour Phusion Passenger pour toute entrée refusée dans /var/log/audit/audit.log et installer-le.
Exemple :
audit2allow -a -M passenger
This command generated a policy package that can be installed by running :
semodule -i passenger.pp
###
# Vérifier si c'est réellement un problème de SELinux car il ne semble pas être activé.
# D'après la commande suivante, SELinux n'est pas activé :
id -Z
id: --context (-Z) ne fonctionne qu'avec un noyau avec SELinux activé
Le fichier de log /var/log/audit/audit.log n'existe pas.
Définir PassengerSpawnDir pour Apache ?
Aucune idée pour le moment, mais, peut être que cette directive peut être modifier pour répondre à la problématique ?
https://build.opensuse.org/package/view_file/devel:languages:ruby:extensions/rubygem-passenger/rubygem-passenger.changes
Résolution du problème en changeant le propriétaire du dossier redmine
Le /opt/redmine était en root:root
Passer le dossier redmine de façon récursive pour www-data:redmine a réglé le problème et fini les répétitions de problèmes d'écriture de logs.
# 1- Donner tout le dossier redmine à www-data:redmine (Oui, mais ...)
cd /opt
sudo chown -R www-data:redmine redmine/
# 2- Donner certains fichiers concernant les gems et passenger à root:root. (... Voilà!)
# Effectuer les changements suivants en respectant de préférence l'ordre d'application :
cd /opt
sudo chown root:root redmine/
cd /opt/redmine
sudo chown root:root .rvm/
cd /opt/redmine/.rvm
sudo chown root:root gems/
cd /opt/redmine/.rvm/gems
sudo chown root:root ruby-2.4.5@redmine-4.0-stable-prod-unis
cd /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis
sudo chown root:root gems/
cd /opt/redmine/.rvm/gems/ruby-2.4.5@redmine-4.0-stable-prod-unis/gems
sudo chown root:root passenger-6.0.2
# Malgré tout, les fichiers de type /tmp/passenger-error-bNMmcu.html ne semblent pas être écrit sur le serveur.
Les fichiers de type /tmp/passenger-error-bNMmcu.html ne semblent pas être écrit sur le serveur
# Depuis Debian 9 Systemd est configuré pour donner à Apache2 un répertoire /tmp privé.
# Les fichiers temporaires sont nommés de la façon suivante, /tmp/systemd-private-652727091e81431fbb51771e978adf20-apache2.service-V5CzcC/tmp/MY-APPLICATION-messages.log
# Passer la valeur PrivateTmp à false ou commenter la ligne PrivateTmp= :
sudo nano /etc/systemd/system/multi-user.target.wants/apache2.service 
#PrivateTmp=true
# Redémarrer le service systemd :
systemctl daemon-reload
# Redémarrer le service apache2 :
sudo service apache2 restart
# Les fichiers d'erreurs du type /tmp/passenger-error-bNMmcu.html seront correctement écrits dans le répertoire /tmp du système.
# Définition 
PrivateTmp =
Prend un argument booléen.  Si vrai, configure un nouvel espace de noms de système de fichiers pour le
processus exécutés et monte à l'intérieur des répertoires privés / tmp et / var / tmp,
qui ne sont pas partagés par des processus en dehors de l'espace de noms.  Ceci est utile pour
accès sécurisé aux fichiers temporaires du processus, mais rend le partage entre
processus via / tmp ou / var / tmp impossible.  Toutes les données temporaires créées par le service
sera supprimé après l'arrêt du service.  La valeur par défaut est false. 
# Apache et donc PHP, qui fonctionne comme module Apache voient un /tmp différent.
# La solution est d'utiliser un répertoire différent pour stocker vos fichiers ou désactiver PrivateTmp.
# Après avoir redémarré apache2, le programme devrait pouvoir créer des fichiers dans le répertoire /tmp selon les besoins.
# Si vous devez utiliser le système /tmp à la place pour une raison quelconque, modifier le fichier de configuration avec la valeur "PrivateTmp = false". 
# Tenir compte des implications de sécurité de ce changement.
# Le répertoire /tmp peut contenir des informations sensibles et tous les scripts php peuvent alors accéder à ces informations.
# Dans le cas de PHP, définir la valeur sys_temp_dir = "/tmp" du fichier de configuration de php.ini
# Les informations que j'obtiens finalement dans les logs créés du type /tmp/passenger-error-bNMmcu.html ne semblent rien apporter.
# J'ai l'impression que d'avantage de logs sont subsistants dans le répertoire /tmp suite à cette configuration.
# Je rétablis la configuration par défaut.
# Les fichiers de logs du type /tmp/passenger-error-bNMmcu.html ne seront plus écrits.
# Ressources complémentaires :
https://serverfault.com/questions/912094/apache2-saves-files-on-tmp-in-a-system-private-hash-instead-of-just-saving
https://fluca1978.github.io/2018/04/19/ApacheSystemdPrivateTemp.html
https://www.nikrou.net/post/2017/02/23/Mais-o%C3%B9-se-trouve-tmp
https://www.the-art-of-web.com/php/where-is-tmp/
# Ce sujet est ouvert sur le Github de Passenger : https://github.com/phusion/passenger/issues/2252
Checking whether to disconnect long-running connections for process
Checking whether to disconnect long-running connections for process
Déconnecter les connexions de longue durée n'est pas une erreur, mais un avis que Passenger ferme les applications inactives pour économiser de la mémoire.
Si vous ne voulez pas que cela se produise, vous pouvez mettre à zéro passenger_pool_idle_time.
Source : https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#PassengerPoolIdleTime
server certificate does NOT include an ID which matches the server name
# Le certificat du serveur n'inclut pas l'ID correspondant au nom du serveur.
# Cette erreur peut avoir plusieurs méthodes de résolution.
# Le VirtualHost doit avoir un ServerName, et celui-ci doit correspondre au CN du sujet du certificat ou à une entrée DNS du champ subjectAltName du certificat.
# Autre possibilité, ajouter l'écoute du port 443 depuis Debian / Ubuntu, pour Apache2, depuis le fichier suivant :
sudo nano /etc/apache2/ports.conf
# Le plus facile serait de remplacer l'ordre du ServerName depuis le VirtualHost, si le certificat Let's Encrypt a été créé pour l'un ou l'autre en priorité.
ServerName mydomain.com
ServerAlias www.mydomain.com
# Par :
ServerName www.mydomain.com
ServerAlias mydomain.com
# Ajouter le ServerName et ServerAlias au fichier default-ssl dervrait permettre d'éliminer l'erreur.
# On ne peut surement que ajouter un seul ServerName dans le default-ssl ?
# Qu'en est t'il si il y a plusieurs ServerName et ServerAlias sur le serveur ?
# Une autre solution serait d'ajouter les chaînes des certificats dans la configuration de Apache2 ?
sudo nano /etc/apache2/apache2.conf
# A tester :
SSLCertificateFile /etc/letsencrypt/live/domain.ru/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain.ru/privkey.pem
# Dans le cas d'un certificat autosigné, indiquer le bon emplacement des clés :
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
# Faut t'il ajouter le domaine dans /etc/hosts et/ou /etc/hostname ?
# On peut aussi simplement ignorer cet avertissement car il ne devrait pas affecter la validité de l'installation SSL.
# On peut également tester l'adresse sur SSLLABS pour avoir des informamtions complémentaires : https://www.ssllabs.com
Source : https://www.it-swarm.dev/fr/apache-httpd/ssl-apache-le-certificat-du-serveur-ninclut-pas-lid-correspondant-au-nom-du-serveur/962568485/

other_vhosts_access.log

Les logs complémentaires pour les différents VirtualHosts.

Exemples d'erreurs rencontrées

Informations sur l'erreur Internal dummy connection
L'erreur Internal dummy connection est souvent répétée dans les logs du fichier other_vhosts_access.log :
"OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.35 (Debian) Phusion_Passenger/5.0.30 OpenSSL/1.1.1 (internal dummy connection)"
Lorsque le serveur HTTP Apache gère ses processus enfants, il doit trouver un moyen de réactiver les processus en attente de nouvelles connexions. Pour ce faire, il s'envoie une simple requête HTTP à lui-même.
Cette demande apparaîtra dans le fichier access_log avec l'adresse distante définie sur l'interface de bouclage (Généralement 127.0.0.1 ou ::1 si IPv6 est configuré).
Si vous enregistrez la chaîne User-Agent tout comme dans le format de journal combiné, vous verrez la signature du serveur suivie de "Internal dummy connection" sur les serveurs non SSL.
Ces demandes sont parfaitement normales et vous n'avez généralement pas à vous en soucier. Elles peuvent simplement être ignorées.
La documentation d'Apache suggère d'omettre les lignes des journaux en ajoutant les éléments suivants à la configuration d'Apache :
Ajouter env=!loopback à la ligne de CustomLog garantit que les données ne seront pas affichées dans les journaux d'accès.

# Remplacer :
CustomLog logs/access_log combined

# Par :
SetEnvIf Remote_Addr "::1" loopback
SetEnvIf Remote_Addr "127\.0\.0\.1" loopback
CustomLog logs/access_log combined env=!loopback
Une autre règle permet de se débarrasser rapidement de ces requêtes avec un minimum de montée en charge pour Apache2.
Étant donné que vous ne pouvez pas empêcher Apache2 d’envoyer toutes ces demandes à lui-même, le mieux est de répondre à celles-ci de manière à nécessiter le moins de ressources possible.
Les demandes adressées à l'hôte local doivent recevoir immédiatement une requête 403 :
RewriteCond %{HTTP_USER_AGENT} ^.*internal\ dummy\ connection.*$ [NC]
RewriteRule .* - [F,L]
Supprimer la journalisation ne serait pas la meilleure solution technique puisque elle permet de diagnostiquer un problème ou une attaque.
Une autre solution consiste à définir une section VirtualHost au début du fichier de configuration pour intercepter toutes les demandes sur l'interface de bouclage.
Envoyer alors les informations dans un fichier journal différent :
<VirtualHost 127.0.0.1:80 [::1]:80>
 # Catch requêtes locales
 ErrorLog ${APACHE_LOG_DIR}/error_local.log
 Loglevel warn
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Exemple en production.
Source complémentaire : https://cwiki.apache.org/confluence/display/HTTPD/InternalDummyConnection

php_errors.log

# Le fichier php_errors.log est défini dans la configuration de PHP FPM, depuis le fichier /etc/php/7.3/fpm/php.ini et /etc/php/7.3/fpm/php-fpm.conf :
# Le message d'erreur :
WARNING: [pool www] server reached pm.max_children setting (5), consider raising it.
# Éditer la configuration de PHP FPM :
sudo nano /etc/php/7.3/fpm/pool.d/www.conf
# Je décommente la valeur suivante pour voir si l'erreur diminue ou disparaît :
pm.max_requests = 500
# A suivre :
# Voir à configurer correctement le service PHP FPM en fonction de la capacité de RAM du serveur.

redmine.access.log

Les logs d'accès pour redmine installé avec RVM.
Droits appliqués au fichier : root:adm

redmine.error.log

Les logs d'accès pour redmine installé avec RVM.
Droits appliqués au fichier : root:adm

Exemples d'erreurs rencontrées

apt

# Un dossier contenant les logs de apt.
# Tous les paquets installés avec apt-get install.

aptitude

# Les logs d'aptitude.
# Contient toutes les actions demandées, même les abandonnées.

auth.log

# Le fichier auth.log est le journal des authentifications.
# Y est consigné toutes les connexions (réussies ou pas) et la méthode d'authentification utilisée.
# En cas de connexion effectuée par un pirate, une trace de son passage peut être consigné dans ce fichier, sauf si le pirate a effacé les traces de sa visite.
# Vérifier si une clé publique inhabituelle permettant de se connecter au serveur est présente dans le fichier $HOME/.ssh/authorized_keys
# Si aucune ligne n'est écrite, vérifier dans le fichier /etc/rsyslog.conf que les règles suivantes soient renseignées :
auth,authpriv.*                 /var/log/auth.log

# Retirer la journalisation de ces éléments dans syslog :
*.*;auth,authpriv.none          -/var/log/syslog

# Sinon, utiliser la commande suivante à la suite de la première commande pour oublier les informations qui ont été journalisées, pour ne pas les réécrire ailleurs :
& stop
Complément d'informations pour configurer Rsyslog : Configuration de rsyslog pour Adiscon Rsyslog.

Exemples de messages rencontrés

Suite à une connexion réussie au serveur SSH

pam_unix(sshd:session): session opened for user toto by (uid=0)
L'UID n'est pas celle de l'utilisateur. L’UID permet d’identifier le nombre de connexions présentes simultanément sur le service SSH. Ici avec la valeur “0“, aucune connexion hormis la notre n’est active.

Exemples d'erreurs rencontrées

Normal Shutdown, Thank you for playing [preauth]

Ce message est un effet secondaire d'une attaque par Brute force du mot de passe SSH.
Lorsque le client SSH procède à un arrêt de connexion "normal", il envoie un paquet contenant un message.
Lorsque le service SSH reçoit un tel paquet quand il ne l'attend pas, avant que l'utilisateur n'ait réussi à s'authentifier, il enregistre le message.
Même si tout est correctement configuré pour interdire les mots de passe, il est bon de disposer d'une deuxième couche de défense, avec DenyHosts, fail2ban ou encore sshguard.

bind.log

Les logs du serveur de nom bind9, si ils sont activés. 

boot.log

# Contient les informations enregistrées lors du démarrage du système.
# Ce fichier n'est pas activé par défaut.

Exemples d'erreurs rencontrées

Namespace lookup failure, AE_NOT_FOUND

# Le message suivant est affiché durant le boot : ACPI Error : Namespace lookup failure, AE_NOT_FOUND
# Je tente d'avoir plus d'informations sur ce message. Ici, le "Product Name" n'est peut être pas le bon ?
sudo dmidecode | grep -e Date -e Vendor -e Version -e Product | head -n 4
    Vendor: Alienware
    Version: 1.3.10
    Release Date: 12/12/2016
    Product Name: Alienware 17 R3
# Tentative de résolution :
sudo nano /etc/default/grub
# Remplacer :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
# Par :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=off"
# Mettre à jour le grub :
sudo update-grub
sudo update-grub2
# Vérifier les changements :
# Je ne vois pas le paramètre que j'ai ajouté.
cat /proc/cmdline
# Il est pourtant bien présent dans le fichier :
grep acpi /etc/default/grub
# Avec acpi=off les messages d'erreur disparaissent au démarrage, et, un seul message d'erreur est affiché. ( Je n'ai pas eu le temps de le noter. )
# Par contre, la souris tactile ne fonctionne plus, je dois brancher une souris en USB.
# Avec acpi=strict les messages d'erreur sont à nouveau présent, mais, la souris fonctionne à nouveau correctement.
# Avec acpi=on les messages d'erreur sont affichés au démarrage, mais, le système fonctionne.
# Pas de solution pour le moment. Autant rester avec la valeur :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
# Il semble que cette erreur existe depuis longtemps sur de nombreuses machines mais elle a été cachée au démarrage.
# En changeant de Kernel, l'erreur est à nouveau cachée avec le Kernel 5.3.0-19.
# Je n'ai pas réussi à cacher l'erreur par moi même.
# Une demande d'issue avait été ouverte sur le forum francophone de Linux Mint mais restée sans réponse : https://forum-francophone-linuxmint.fr/viewtopic.php?f=20&t=13777&p=156902#p156902

Failed to start Cgroup management daemon" during boot

Le message suivant est affiché durant le boot : Failed to start Cgroup management daemon" during boot
# Lancer la commande suivante pour obtenir plus d'informations : systemctl status cgmanager.service
● cgmanager.service - Cgroup management daemon
  Loaded: loaded (/lib/systemd/system/cgmanager.service; enabled; vendor preset: enabled)
  Active: failed (Result: exit-code) since Thu 2019-08-22 22:42:35 CEST; 2h 20min ago
 Process: 1140 ExecStart=/sbin/cgmanager -m name=systemd (code=exited, status=1/FAILURE)
Main PID: 1140 (code=exited, status=1/FAILURE)
août 22 22:42:35 "hostname" systemd[1]: cgmanager.service: Service hold-off time over, scheduling restart.
août 22 22:42:35 "hostname" systemd[1]: cgmanager.service: Scheduled restart job, restart counter is at 5.
août 22 22:42:35 "hostname" systemd[1]: Stopped Cgroup management daemon.
août 22 22:42:35 "hostname" systemd[1]: cgmanager.service: Start request repeated too quickly.
août 22 22:42:35 "hostname" systemd[1]: cgmanager.service: Failed with result 'exit-code'.
août 22 22:42:35 "hostname" systemd[1]: Failed to start Cgroup management daemon.
# A tord ou à raison, puisqu'il n'est de toute façon pas lancé, je l'ai désactivé du démarrage.
Désactiver Cgroup management daemon.

btmp

# Le journal btmp garde la trace des tentatives de connexion ayant échouées.
# Le contenu du fichier btmp n'est pas intelligible à l'écran, on utilise last afin d'interpréter et d'afficher correctement son contenu.
last -f /var/log/btmp
# Lastb est identique à last, sauf que par défaut, il affiche un journal du fichier /var/log/btmp, qui contient toutes les tentatives de connexion incorrectes. 
# Afficher les 10 principales adresses IP avec des erreurs de connexion :
sudo lastb | awk '{print $3}' | sort | uniq -c | sort -rn | head -10
# Afficher les 10 principaux noms d'utilisateur avec des erreurs de connexion :
sudo lastb | awk '{print $1}' | sort | uniq -c | sort -rn | head -10
# Vider le fichier, en étant root :
>/var/log/btmp

cloud-init.log

.

cloud-init-output.log

.

cron-dropbox.log

# Fichier de log personnalisé.
# Créé par l'administrateur du serveur, ce fichier va conserver la liste des fichiers sauvegardés suite aux sauvegardes effectuées avec un script et une tâche cron vers le cloud DropBox.
/bin/sh: 1: cannot create /var/log/cron-dropbox.log: Permission denied
# Le propriétaire et le groupe du fichier cron-dropbox.log doivent correspondre à l'utilisateur root:root et la tâche cron de sauvegarde doit être lancée depuis le crontab de root.
# L'écriture des logs dans le fichier fonctionne alors correctement.
# Erreur rencontrée depuis cron-dropbox.log :
/bin/sh: 1: /usr/local/bin/Automatisation-sauvegarde-cron.sh: Permission denied
/bin/sh: 1: /usr/local/bin/Automatisation-sauvegarde-serveur-cron.sh: Permission denied
# Les fichiers ne sont pas exécutables, rendre les fichiers exécutables avec la commande suivante :
sudo chmod +x /usr/local/bin/Automatisation-sauvegarde-cron.sh
sudo chmod +x /usr/local/bin/Automatisation-sauvegarde-serveur-cron.sh

cron

# Enregistre les informations du travail cron à chaque fois que le démon cron (ou anacron) commence une tâche.

cups

# Dossier des logs du système d'impression cups.
# Tous les messages de journal relatifs à l'imprimante et à l'impression.

daemon.log

# Journalise les informations provenant de différents services en arrière-plan exécutés sur le système.
# Un daemon, appelé service en français, est un programme qui s'exécute en arrière-plan et qui effectue certaines opérations importantes pour le bon fonctionnement du système.

Exemples de messages rencontrés

DHCPREQUEST DHCPACK bound

dhclient[339]: DHCPREQUEST for xxx.xxx.xxx.xxx on eth0 to xxx.xxx.yy.y port 67
dhclient[339]: DHCPACK of xxx.xxx.xxx.xxx from to xxx.xxx.yy.y
dhclient[339]: bound to xxx.xxx.xxx.xxx -- renewal in 38115 seconds.
# C'est le serveur qui fixe cet intervalle. On est libre de ne pas le respecter.
# Si personne ne fait de renouvellement dans l'intervalle 2*time_lease, le serveur est en droit de penser que le client n'est plus là.
# Il peut donc réassigner l'adresse, et, si c'est un routeur, ne plus accepter les paquets venant de cette adresse.
# Il vaut mieux laisser des baux se renégocier.

Deprecated option RSAAuthentication

# L'option RSAAuthentication est dépréciée pour la connexion au serveur SSH.
/etc/ssh/sshd_config Deprecated option RSAAuthentication
# Modifier le fichier de configuration du serveur SSH.
# Commenter l'option RSAAuthentication.
# RSAAuthentication yes
sudo nano /etc/ssh/sshd_config
Source : Autoriser la connexion SSH par clé RSA.

denyhosts.service: PID file /run/denyhosts.pid not readable

# Il est nécessaire d'exécuter Denyhosts en tant que root pour pouvoir lire les fichiers de journalisation dans le dossier /var/log/ et pour pouvoir mettre à jour le fichier /etc/hosts.deny.
denyhosts.service: PID file /run/denyhosts.pid not readable (yet?) after start: No such file or directory
# Je redémarre Denyhosts avec sudo, pour voir si cela est suffisant :
sudo /etc/init.d/denyhosts restart

denyhosts.service: Can't open PID file /run/denyhosts.pid (yet?) after start: No such file or directory

# Cette erreur est rencontrée avec la version de DenyHosts 2.10-2.
sudo service denyhosts restart
sudo service denyhosts status
# L'erreur suivante est affichée : denyhosts.service: Can't open PID file /run/denyhosts.pid (yet?) after start: No such file or directory
# L'erreur n'est pas affichée si j'arrête DenyHosts et le démarre :
sudo service denyhosts stop
sudo service denyhosts start
sudo service denyhosts status
# Le message d'erreur est également affiché dans /var/log/daemon.log :
sudo tail -150f /var/log/daemon.log
# Redémarrer rsyslog règle le problème :
sudo systemctl restart rsyslog
sudo service denyhosts restart
sudo service denyhosts status
Source : https://bugs.mageia.org/show_bug.cgi?id=23551

warning: unable to include '/etc/proftpd/tls.conf

# Dans cet exemple, il m'était impossible de charger la configuration TLS.
# J'ai du commenter l'option depuis le fichier de configuration de ProFTPd pour pouvoir redémarrer le service.
warning: unable to include '/etc/proftpd/tls.conf

Fail2ban : please update the tmpfiles.d/ drop-in file accordingly

systemd-tmpfiles[15910]: /usr/lib/tmpfiles.d/fail2ban-tmpfiles.conf:1: Line references path below legacy directory /var/run/, updating /var/run/fail2ban → /run/fail2ban; please update the tmpfiles.d/ drop-in file accordingly.
# Éditer le fichier :
sudo nano /usr/lib/tmpfiles.d/fail2ban-tmpfiles.conf
# Remplacer
/var/run/fail2ban
# Par :
/run/fail2ban
# Au redémarrage de Fail2ban, le précédent message ne devrait plus apparaître mais il est remplacé par plusieurs FutureWarning :
fail2ban-server[6474]: /usr/lib/python3/dist-packages/fail2ban/server/failregex.py:115: FutureWarning: Possible nested set at position 2
fail2ban-server[6474]:   self._regexObj = re.compile(regex, re.MULTILINE if multiline else 0)
fail2ban-server[6474]: /usr/lib/python3/dist-packages/fail2ban/server/failregex.py:115: FutureWarning: Possible nested set at position 14
fail2ban-server[6474]:   self._regexObj = re.compile(regex, re.MULTILINE if multiline else 0)
fail2ban-server[6474]: /usr/lib/python3/dist-packages/fail2ban/server/failregex.py:115: FutureWarning: Possible nested set at position 26
fail2ban-server[6474]:   self._regexObj = re.compile(regex, re.MULTILINE if multiline else 0)
fail2ban-server[6474]: /usr/lib/python3/dist-packages/fail2ban/server/failregex.py:115: FutureWarning: Possible nested set at position 1
fail2ban-server[6474]:   self._regexObj = re.compile(regex, re.MULTILINE if multiline else 0)
systemd[1]: Stopped Fail2Ban Service.
systemd[1]: Starting Fail2Ban Service...
systemd[1]: Started Fail2Ban Service.
fail2ban-server[7665]: Server ready
# Par contre, aux redémarrages suivants, les FutureWarning n’apparaîtrons plus.

ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket

systemd[1]: /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
sudo nano /lib/systemd/system/dbus.socket
# Remplacer :
/var/run/dbus/system_bus_socket
# Par :
/run/dbus/system_bus_socket
Source possible de ce bogue : https://gitlab.freedesktop.org/dbus/dbus/-/issues/180

[ERROR] mysqld: Table './mysql/user' is marked as crashed and should be repaired

# [ERROR] mysqld: Table './mysql/user' is marked as crashed and should be repaired
sudo mysql
use mysql;
CHECK TABLE user FAST QUICK;
CHECK TABLE user EXTENDED QUICK;
REPAIR TABLE user;

[ERROR] mysqld: Table './mysql/db' is marked as crashed and should be repaired

[ERROR] mysqld: Table './mysql/db' is marked as crashed and should be repaired
sudo mysql
use mysql;
CHECK TABLE db FAST QUICK;
CHECK TABLE db EXTENDED QUICK;
REPAIR TABLE db;

Invalid command 'analog', perhaps misspelled or defined by a module not included in the server configuration

# Peut d'informations sur l'utilisation de Analog sont disponibles depuis un moteur de recherche.
# Ce message n'est apparu que un court moment lors de mes tests.
# Est-ce que Analog est toujours utilisé sur Linux ?
Invalid command 'analog', perhaps misspelled or defined by a module not included in the server configuration

Starting Clean php session files

# Les messages suivants sont répétés plusieurs fois :
systemd[1]: Starting Clean php session files...
systemd[1]: phpsessionclean.service: Succeeded.
systemd[1]: Started Clean php session files.
# Les messages précédents sont des messages normaux d'effacement des sessions PHP.
# Si pour diverses raisons, on souhaite arrêter ce mécanisme de purge des sessions, utiliser les commandes suivantes :
systemctl stop phpsessionclean.service
systemctl disable phpsessionclean.service
systemctl stop phpsessionclean.timer
systemctl disable phpsessionclean.timer

Failed to connect to API bus: No such file or directory

# Failed to connect to API bus: No such file or directory
# Failed to connect to system bus: No such file or directory.
# Tester cette commande :

sudo dbus-daemon --system
sudo nano daemon.log

dbconfig-common

Un dossier contenant les logs de dbconfig-common.

debug

# Les logs pour le debug.

dmesg

# Les messages du noyau Linux au démarrage.
# Lorsque le système démarre, il imprime un nombre de messages à l'écran qui affiche des informations sur les périphériques matériels que le noyau détecte pendant le processus de démarrage.
# Ces messages sont disponibles dans le tampon du noyau. Chaque fois que le nouveau message arrive, l'ancien message est écrasé.
# Afficher le contenu de ce fichier à l'aide de la commande dmesg.
Plus d'informations : https://manpages.debian.org/jessie/manpages-fr-extra/dmesg.1.fr.html

denyhosts

.

dpkg.log

# Les informations sur les paquets installés ou retirés en utilisant la commande dpkg.

exim4

# Un dossier contenant les logs de exim4.
# Droits du dossier :
drwxr-s---  2 Debian-exim adm        4096 mars  19 19:22 exim4
# Droits des fichiers :
-rw-r-----  1 Debian-exim adm     5 mars  19 19:22 mainlog

paniclog

# L'erreur suivante serait présente à chaque fois que exim4 démarre et que le fichier paniclog ne serait pas vide sur un système Debian / Ubuntu.
exim paniclog /var/log/exim4/paniclog has non-zero size error
# L'origine de ce message d'erreur est généré lorsque je me connecte deux fois au serveur SSH, depuis deux consoles différentes.
# Le premier mail suite à une connexion réussie m'est bien envoyé, avec ce script : Alerte mail lors du login root ou d'un utilisateur.
# Lors d'une seconde connexion avec un nouveau terminal et le même utilisateur, j'obtiens un mail en erreur renvoyé au compte administrateur : 
Mail failure - no recipient addresses
A message that you sent contained no recipient addresses, and therefore no delivery could be attempted.
# Pour résoudre ce problème de exim paniclog /var/log/exim4/paniclog has non-zero size error il faut comprendre pourquoi suite à une double connexion, le second mail n'est pas envoyé.
# En consultant le fichier paniclog on observe l'ajout des lignes suivantes :
nano /var/log/exim4/paniclog
1jJnQp-0006r4-KL 1jJnQp-0006r4-KL no recipients found in headers
1jJnRH-0006rh-6j 1jJnRH-0006rh-6j no recipients found in headers
# La première solution pour ne plus avoir le message de paniclog est de supprimer ce fichier pour qu'il soit recréé :
sudo rm /var/log/exim4/paniclog
# La deuxième solution est de vider le fichier paniclog :
sudo bash
echo "" > /var/log/exim4/paniclog
# Redémarrer Exim4 :
/etc/init.d/exim4 restart

fail2ban.log

# Les Ban/Unban et infos sur le programme Fail2ban si Fail2ban est installé.

faillog

# Ne se lit pas directement. Affiche les dernières erreurs de connexion.
faillog -a
Ok-ko.png Manuel : https://linux.die.net/man/8/faillog

fontconfig.log

# Renseigne sur l'absence de polices utilisées par le système.

fwanalog

# Le répertoire fwanalog est créé dans /var/log suite à l'installation de fwanalog pour surveiller les logs du pare-feu Iptables.
# Ce répertoire contient des images PNG et des fichiers HTML permettant une synthèse du travail mené par Iptables.
# Droits du répertoire fwanalog :
drwxr-x---    2 fwanalog    adm                4096 juin   1 00:00 fwanalog

installer

Un dossier contenant les logs de installer.

iptables.log

# Un fichier personnalisé qui journalise les messages provenant de Iptables.
Exemple pour la rotation d'un nouveau fichier de log iptables.log.

kern.log

# Les informations enregistrées par le noyau.
# Elles sont notamment utiles pour déboguer un noyau personnalisé.
# Le fichier /var/log/kern.log capture tous les messages du noyau pour n'importe quel niveau de journal.
# Ce fichier va également capturer les messages du Firewall Iptables ce qui va lui faire prendre du volume.
# Vérifier si la journalisation des messages du noyau vers le fichier kern.log est activée depuis le fichier "/etc/rsyslog.conf".
kern.*                          -/var/log/kern.log
# Exemple du fichier de configuration rsyslog : Configuration de rsyslog.

lastlog

# Les informations de connexion récente de tous les utilisateurs.
# Il faut utiliser la commande lastlog pour afficher le contenu de ce fichier car ce n'est pas un fichier ascii.

letsencrypt

Un dossier contenant les logs de letsencrypt.
letsencrypt/letsencrypt.log
Droits actuels du dossier letsencrypt :
drwx------  2 UTILISATEUR_LOCAL      UTILISATEUR_LOCAL
Droits actuels des deux fichiers 
-rw-r--r--  1 UTILISATEUR_LOCAL   UTILISATEUR_LOCAL     5136 mars  18 16:41 letsencrypt.log
-rw-r--r--  1 UTILISATEUR_LOCAL   UTILISATEUR_LOCAL        0 mars  17 00:00 letsencrypt-renew.log
# Si la commande sudo n'est pas utilisée, et, que le fichier de log a le droit en écriture avec 664, un message système propose de donner le droit en écriture aux éléments suivants :
Saving debug log to /var/log/letsencrypt/letsencrypt.log
The following error was encountered:
[Errno 13] Permission denied: '/etc/letsencrypt/.certbot.lock'
Either run as root, or set --config-dir, --work-dir, and --logs-dir to writeable paths.
# J'ai remis les droits en 644.
# J'opte pour l'utilisation de la commande sudo pour lancer le renouvellement des certificats depuis crontab.
# Pour permettre à la tâche cron qui lance certbot renew d'écrire dans les logs, ajouter sudo devant la commande de la tâche cron.
01 01 * * * sudo /usr/bin/certbot renew >> /var/log/letsencrypt/letsencrypt-renew.log

mail.log

# Les informations du serveur de messagerie.
sudo nano /var/log/mail.log
# Les droits sur le fichier :
-rw-r-----   1 root        adm                   0 mai   27 18:00 mail.log
# Le service Dovecot, Postfix et Sendmail utilisent ce fichier pour loguer des informations.
# Ce n'est pas le cas pour Exim4 ou PHP qui possèdent leurs propres fichier de journalisation.
# Pour Exim : /var/log/exim4/mainlog (Ce fichier est défini depuis le fichier de configuration de Exim4.)
# Ce fichier va loguer les mails envoyés en ligne de commande.
# Pour PHP : /var/log/php/mail-php.log (Ce fichier est défini depuis le fichier de configuration principale de PHP.)
# Ce fichier va loguer les mails envoyés avec PHP.

messages

# Contient des messages globaux du système, y compris les messages qui sont enregistrés au démarrage.
# Beaucoup de choses sont enregistrées dans /var/log/ messages y compris mail, cron, daemon, kern, auth.

mysql

Dossier contenant les logs de mysql.
Par défaut, le fichier de logs ne semble pas se remplir.
Un paramétrage complémentaire est nécessaire depuis MySQL pour enregistrer les logs suites aux requêtes web.
A faire !

php

Créer le dossier /var/log/php : sudo mkdir /var/log/php
Créer le fichier de log error.log : touch /var/log/php/error.log et touch /var/log/php/mail.log
Tester les logs suite à l'envoi d'un mail : cat /var/log/php/mail.log
Les emplacements pour les logs de PHP sont définis depuis les directives du fichier php.ini de PHP qui permet sa configuration.

php7.2-fpm.log

Exemples d'erreurs rencontrées

NOTICE: php7.2-fpm : error log file re-opened

Cette NOTICE apparaît à chaque fois qu'il y a une rotation des logs.
# Éditer le fichier de configuration de logrotate de php7.2-fpm :
/etc/logrotate.d/php7.2-fpm
# Je n'ai pas encore déterminé d'où provient cette erreur, mais, pour la contourner, j'ai remplacé les trois lignes suivantes :
postrotate
/usr/lib/php/php7.2-fpm-reopenlogs
endscript
# Par celle-ci :
postrotate \
if [ -w /run/php/php7.2-fpm.pid ]; then \
systemctl reload php7.2-fpm.service; \
fi; \
endscript
Ok.png php7.0-fpm : error log file re-opened : https://www.linuxien.fr/index.php?post/2018/10/php7.0-fpm-%3A-error-log-file-re-opened

NOTICE: Not enabling PHP 7.2 FPM by default

NOTICE: To enable PHP 7.2 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.2-fpm
Cette NOTICE apparaît car il est nécessaire d'activer les deux modules proxy_fcgi et setenvif avec la configuration de php7.2-fpm pour l'utiliser.
Il faut également désactiver le module php7.2.
Activer PHP-FPM.

php7.3-fpm.log

Exemples d'erreurs rencontrées

Notice: Undefined index: HTTP_HOST

Got error 'PHP message: PHP Notice: Undefined index: HTTP_HOST
# Depuis cli, la provenance n'est pas identifiée avec HTTP_HOST
$host = ; // Ou $host = FALSE;
if (isset($_SERVER['HTTP_HOST'])) {
  $host = $_SERVER['HTTP_HOST'];
}

private

# Un répertoire contenant les logs de private.

proftpd

# Un dossier contenant les logs de proftpd.
# /var/log/proftpd/proftpd.log

psad

# Un répertoire contenant les logs de psad.
# Pour chaque adresse IP bloquée par le Firewall, un répertoire est créé, un niveau de dangerosité est indiqué, ainsi que les informations whois, et, la copie du mail d'alerte qui aura été envoyé.

redmine

Ce dossier contient les logs de Redmine lors de l'installation avec le paquet du dépôt Debian :
https://wiki.visionduweb.fr/index.php?title=Installer_Redmine_sur_Debian
Cette installation semblait mal effectuée et a été remplacée par une installation avec RVM :
https://wiki.visionduweb.fr/index.php?title=Installer_Redmine_sur_Debian_avec_RVM
# Pour cette nouvelle installation avec RVM, les logs sont stockés dans /var/log/apache2 :
sudo nano /var/log/apache2/redmine.access.log (root:adm)
sudo nano /var/log/apache2/redmine.error.log (root:adm) (Plus rien n'est écrit.)
# Les logs de redmine dans le fichier /log/production.log du projet :
# La rotation des logs n'est pas prise en compte ici ce qui entraîne un fichier de logs bien trop lourd !
# -rwxrwxr-x www-data redmine 176122613 production.log
sudo nano /opt/redmine/canna/log/production.log
sudo nano /opt/redmine/mdp/log/production.log
sudo nano /opt/redmine/unis/log/production.log
sudo nano /opt/redmine/vdw/log/production.log
# Je n'arrive pas à retrouver certains messages d'erreurs avec cette installation de Redmine et RVM.
Retrouver un fichier de log spécifique sur le serveur suite à une erreur.

default

Le dossier contenant les logs de Redmine par défaut.

production.log

Le fichier contenant les logs de Redmine.
Exemples d'erreurs rencontrées
rsyslogd was HUPed
Le message rencontré dans le fichier production.log :
liblogging-stdlog:  [origin software="rsyslogd" swVersion="8.24.0" x-pid="938" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Il est causé par logrotate et peut être ignoré.
Voir "postrotate" dans /etc/logrotate.d/rsyslog
Rsyslogd cesse d'écrire dans les anciens fichiers journaux de logs qui sont alors renommés.
Unable to access log file
Rails Error: Unable to access log file. Please ensure that /usr/share/redmine/instances/default/log/production.log exists and is writable
make it writable for user and group: 
chmod 0664 /usr/share/redmine/instances/default/log/production.log
The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Il suffit de vérifier si le fichier de log est inscriptible en écriture, depuis l'administration de Redmine, dans l'onglet information.
Si il ne l'est pas, ce qui est sûrement le cas puisque l'erreur a été retournée dans les logs du système, donner le droit en écriture.
Ce n'est pas le fichier de log Redmine qui renseigne cette erreur. Peut être un log de Apache2 qui indique le droit manquant (?).
Vérifier les droits des dossiers et des fichiers de Redmine.

syslog

# Tous les messages, hormis les connexions des utilisateurs. Plus complet que /var/log/messages. 
# Consulter les messages de syslog avec un programme comme Adiscon Rsyslog couplé avec Adiscon LogAnalyzer.
# CCZE peut aussi être utilisé pour consulter les messages de syslog, en couleurs.

tallylog

# Fichier de journalisation du nombre d'échecs de connexion :
/var/log/tallylog
# Le paquet pam_tally2 a été écrit par Tim Baverstock et Tomas Mraz.
# Le module pam_tally2 est installé par défaut sur la plupart des distributions Linux et est contrôlé par le paquet PAM.
# Le module pam_tally2 conserve un nombre de tentatives d'accès, peut réinitialiser le nombre de tentatives, peut refuser l'accès si trop de tentatives échouent.
# Exemple :
# Ajouter la ligne suivante à /etc/pam.d/login pour verrouiller le compte après 4 connexions échouées.
# Le compte root sera également verrouillé. Les comptes seront automatiquement déverrouillés après 20 minutes. 
# Le module n’a pas besoin d’être appelé lors de la phase de compte car le login appelle correctement pam_setcred.
auth  required    pam_securetty.so
auth  required    pam_tally2.so deny=4 even_deny_root unlock_time=1200
auth  required    pam_env.so
auth  required    pam_unix.so
auth  required    pam_nologin.so
account  required    pam_unix.so
password required    pam_unix.so
session  required    pam_limits.so
session  required    pam_unix.so
session  required    pam_lastlog.so nowtmp
session  optional    pam_mail.so standard
Ko.png Linux Password Enforcement with PAM : http://deer-run.com/~hal/linux_passwords_pam.html
Ko.png Comment verrouiller et déverrouiller les comptes SSH après un certain nombre de tentatives de connexion échouées : https://www.tecmint.com/use-pam_tally2-to-lock-and-unlock-ssh-failed-login-attempts/
Fichier de configuration : https://www.systutorials.com/docs/linux/man/5-pam.conf/

ulog

# Répertoire présent suite à un test sur la gestion des logs, contenant un fichier vide nommé syslogemu.log
# Ce dossier a sûrement été créé lors de l'installation de ulogd2.

user.log

# Les informations sur tous les journaux de niveau utilisateur.
# Tester l'écriture dans le fichier user.log :
logger This is a test message
# Affiche dans le fichier :
May 27 06:33:00 vps178370 debian: This is a test message

utmp

Le fichier utmp enregistre toutes les connexions actives.
Le contenu du fichier utmp n'est pas intelligible à l'écran, on utilise last afin d'interpréter et d'afficher correctement son contenu.
last -f /var/run/utmp

watchdog

# Le répertoire /etc/log/watchdog est actuellement vide.
# Watchdog est un daemon qui devrait entre autre pouvoir alerter l'administrateur, dans certaines situations.
Configurer le daemon watchdog : https://manpages.debian.org/testing/watchdog/watchdog.conf.5.en.html
Configurer le daemon watchdog : https://www.systutorials.com/docs/linux/man/5-watchdog.conf/
Configurer le daemon watchdog : https://www.crawford-space.co.uk/old_psc/watchdog/watchdog-configure.html

wtmp

# Le fichier wtmp enregistre toutes les connexions et déconnexions.
# Le contenu du fichier wtmp n'est pas intelligible à l'écran, on utilise last afin d'interpréter et d'afficher correctement son contenu.
last -f /var/log/wtmp
# Vider le fichier, en étant root :
>/var/log/btmp

Xorg.x.log

# Les messages du serveur X.
# N'existe pas sur un serveur.
# Le petit x est le N° d'instance du serveur X.

Bibliographie

Ok-ko.png Emplacements des fichiers journaux Linux : https://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/
Ok-ko.png Comment envoyer des journaux à un loghost distant : https://www.cyberciti.biz/tips/log-all-logs-to-central-linux-unix-loghost.html
Ok-ko.png Comment faire pivoter les fichiers journaux : https://www.cyberciti.biz/faq/how-do-i-rotate-log-files/

NAVIGATION

PARTICIPER ET PARTAGER

Bienvenue sur le wiki de Vision du Web.
De nombreuses pages sont partagées sur ce wiki.
Créer un compte utilisateur pour participer sur le wiki.
Les pages présentées sur le wiki évoluent tous les jours.
Certaines recherches sont peu abouties et incluent des erreurs.
Utiliser la recherche interne du wiki pour trouver votre contenu.
La page de discussion de VisionDuWeb vous permet de poser une question.
Utiliser la recherche interne du site pour chercher dans tout le contenu.
Ce contenu ne doit pas servir à nuire à autrui ou à un système informatique.
Protéger votre système Linux ou Windows en lisant la page dédié à la sécurité.
Améliorer le contenu des pages avec vos propositions depuis l'onglet discussion.

SOUTENIR CE WIKI

Soutenir le wiki avec un don en monnaie numérique :
AEON - Bitcoins - Bitcoins Cash - Bitcoins Gold - Bitcore - Blackcoins - Basic Attention Token - Bytecoins - Clams - Dash - Monero - Dogecoins - Ğ1 - Ethereum - Ethereum Classique - Litecoins - Potcoins - Solarcoins - Zcash

OBTENIR DE LA MONNAIE NUMERIQUE

Obtenir gratuitement de la monnaie numérique :
Gagner des Altcoins - Miner des Altcoins.