Les fichiers de logs sur Debian
Aller à la navigation
Aller à la recherche
Le wiki : Accueil - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack
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 /var/log/exim4/paniclog ne serait pas vide sur un système Debian / Ubuntu. exim paniclog /var/log/exim4/paniclog has non-zero size error
Erreur rencontrée numéro une
# 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 n'est pas de supprimer ce fichier pour qu'il soit recréé car il serait retiré de la journalisation. sudo rm /var/log/exim4/paniclog # La solution consiste à forcer la sauvegarde du fichier journal avec la commande de logrotate : sudo logrotate -f -v /etc/logrotate.d/exim4-paniclog
# La deuxième solution est de vider le fichier paniclog : sudo bash echo "" > /var/log/exim4/paniclog
# Redémarrer Exim4 : sudo systemctl restart exim4
Erreur rencontrée numéro deux
# Depuis la mise à jour vers Debian Bullseye, le fichier paniclog indique les lignes suivantes à répétition : 2021-09-07 23:31:31 1mIca4-005mPZ-Lp == www-data@vps178370 R=local_user T=mail_spool defer (-1): Tainted '/var/mail/www-data' (file or directory name for mail_spool transport) not permitted
# Vider le fichier paniclog manuellement : cd /var/log/exim4 sudo bash echo "" > paniclog # Éditer le fichier pour supprimer l'espace restant. nano paniclog # Actualiser logrotate : logrotate -f -v /etc/logrotate.d/exim4-paniclog
# Le fichier continue d'être renseigné par des erreurs du même format : 2021-09-07 23:31:31 1mIca4-005mPZ-Lp == www-data@vps178370 R=local_user T=mail_spool defer (-1): Tainted '/var/mail/www-data' (file or directory name for mail_spool transport) not permitted
# Reconfigurer Exim4 ne change rien : sudo dpkg-reconfigure exim4-config
# # Ajout de la ligne www-data dans la redirection des mails pour tenter de corriger l'erreur en redirigeant les messages de apache vers la boîte mail. # sudo nano /etc/email-addresses # www-data:mail@visionduweb.com # # Redémarrer Exim4 : # sudo systemctl restart exim4 # # Ne semble pas suffire à corriger le problème de paniclog.
# Compter les mails en queue :
sudo exim -bpc
# Supprimer les mails en queue :
exim -qff
# Forcer la suppression des mails en queue :
exim -bpru | awk {'print $3'} | xargs exim -Mrm
# Vider les fichiers de log de Exim4 : cd /var/log/exim4 sudo echo ""> mainlog sudo echo ""> paniclog # Redémarrer Exim4 : sudo systemctl restart exim4 # La suppression des mails en queue semble stopper l'écriture de logs dans le fichier paniclog. A vérifier.
# Il n'est pas certain qu'il ait été vraiment nécessaire de revisiter la configuration de Exim4. # Le problème rencontré est lié à la montée en version de Buster vers Bullseye : # - aux règles Fail2ban qui génèrent des erreurs à désactiver, # - au mieux, appliquer le changement de Iptables par nftables, ou, au minimum, mettre à jour Iptables sur Debian Bullseye.
# Facultatif. # Éditer les données Gecos, le nom complet des utilisateurs www-data et root, avec la commande chfn, et renseigner " service " dans le nom complet. chfn www-data chfn root
# On ne peut pas lire le mail de root puisque root ne fait normalement pas parti du groupe mail. # Si vous ne redirigez pas le courrier pour root via /etc/aliases vers un compte non privilégié, le courrier sera remis à /var/mail/mail avec les autorisations 0600 et le propriétaire mail:mail. cat /etc/group | grep mail mail:x:8: # Tentative pour la sortie des mails de Fail2ban : sudo nano /etc/aliases ... # Rediriger les mails de root vers un utilisateur non privilégié : debian:mail@visionduweb.com www-data:mail@visionduweb.com root:debian
# Si on regarde les groupes : cat /etc/group # Le groupe mail ne renvoie vers aucun utilisateur : mail:x:8: # Il devrait être de la forme : mail:x:8:debian ou mail:x:8:contact
# Prendre en compte la modification des alias des adresses mails locales : sudo newaliases
# Vérifier la modification des alias des adresses mails locales : sudo exim -bt root Address rewritten as: mail@visionduweb.com R: dnslookup for mail@visionduweb.com mail@visionduweb.com router = dnslookup, transport = remote_smtp host postmaster.visionduweb.com [194.146.224.64] MX=10 sudo exim -bt debian Address rewritten as: g2pc@visionduweb.com R: dnslookup for g2pc@visionduweb.com g2pc@visionduweb.com router = dnslookup, transport = remote_smtp host postmaster.visionduweb.com [194.146.224.64] MX=10 sudo exim -bt www-data R: system_aliases for www-data@vps178370 R: dnslookup for g2pc@visionduweb.com g2pc@visionduweb.com <-- www-data@vps178370 router = dnslookup, transport = remote_smtp host postmaster.visionduweb.com [194.146.224.64] MX=10 # Le mail affiché pour apache n'est pas le bon, je le modifie depuis le fichier des mails des utilisateurs /etc/email-addresses : sudo nano /etc/email-addresses debian:mail@visionduweb.com www-data:mail@visionduweb.com root:mail@visionduweb.com
# Prendre en compte la modification des mails avec la même commande que précédemment : sudo newaliases
# Tester la configuration d'exim : sudo exim -bV # Tester une adresse mail local : sudo exim -bt user1 # Tester une adresse mail distante : sudo exim -bt adresse-mail
# Envoyer un mail de test : echo "`date` Test de configuration d'exim4 pour redirection de mails locaux vers adresse mail externe" | mail -s "test" [user ou adresse mail] # Les utilisateurs debian et www-data envoient bien vers g2pc@visionduweb.com et root vers mail@visionduweb.com # Le premier problème est que d'après ma configuration, tous les utilisateurs devraient renvoyer vers mail@visionduweb.com # Le second problème est que les mails d'alertes de Fail2ban ne sont toujours pas réceptionnés.
# Dans le cas d'une configuration Exim4 dans un seul fichier, il faut modifier le fichier /etc/exim4/exim4.conf.template vers la ligne 1834 : begin rewrite www-data@* mail@visionduweb.com FfrsTtcb debian@* mail@visionduweb.com FfrsTtcb root@* mail@visionduweb.com FfrsTtcb # Comme pour toute modification de la configuration, exécuter update-exim4.conf puis redémarrer Exim : cd /etc/exim4 sudo update-exim4.conf # Redémarrer Exim4 pour prendre en compte les modifications, si systemd est utilisé : sudo systemctl restart exim4.service
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
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
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
Linux Password Enforcement with PAM : http://deer-run.com/~hal/linux_passwords_pam.html
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
NAVIGATION
PARTICIPER ET PARTAGERBienvenue sur le wiki de Amis SH. 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 Amis SH vous permet de poser vos questions. Consulter le site amis-sh.fr pour installer votre propre serveur web. Améliorer le contenu des pages avec vos retours depuis l'onglet discussion. Ce contenu ne doit pas servir à nuire à autrui ou à un système informatique. Protéger votre système Linux ou Windows avec cette page dédiée à la sécurité. |
SOUTENIR CE WIKISoutenir 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 NUMERIQUEObtenir gratuitement de la monnaie numérique : Miner de la cryptomonnaie. |