Gestion des logs

De Analyse Développement Hacking
Sauter à la navigation Sauter à la recherche
Naviguer dans ce wiki : Accueil du wiki - Objectifs - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack
Consulter le site : Accueil du site - Annuaire - Blog - Forum - Outils - Utilisateur     Consulter le Redmine : Accueil du Redmine

Sommaire

Gestion des logs

Adiscon

Rsyslog et Loganalyzer.png.
Exemple d'installation de Rsyslog et de LogAnalyzer depuis une machine virtuelle GNU/Linux Mint Tara.
Adiscon Rsyslog.
Adiscon LogAnalyzer.

Auditd

Auditd est fourni pour l'audit du système.
Au démarrage, les règles de /etc/audit.rules sont lues par ce service.
Il est responsable de l'écriture des enregistrements d'audit sur le disque.
Vous pouvez ouvrir le fichier /etc/audit.rules et apporter des modifications telles que l'emplacement du journal de configuration du fichier d'audit et d'autres options.
# Avec auditd, vous pouvez répondre aux questions suivantes :
Événements de démarrage et d'arrêt du système (Redémarrage / Arrêt).
Date et heure de l'événement.
L'utilisateur responsable pour l'événement (Par exemple, en essayant d'accéder au fichier / path/to/topsecret.dat).
Type d'événement (éditer, accéder, supprimer, écrire, mettre à jour le fichier et les commandes).
Succès ou échec de l'événement.
Enregistre les événements qui modifient la date et l'heure.
Découvrez qui a apporté des modifications pour modifier les paramètres réseau du système.
Enregistrez les événements qui modifient les informations utilisateur / groupe.
Voir qui a apporté des modifications à un fichier...
Consulter le tutoriel suivant qui explique comment activer et utiliser le service auditd : https://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html

Botify

Site officiel : https://www.botify.com

CCZE

Lire les logs du système en couleur.
CCZE.

Consulter les logs du journal

journalctl -xn
journalctl
journalctl -u network.service
journalctl -u ssh.service
journalctl -f
journalctl -k
# Chercher des expressions spécifiques :
journalctl -xe | grep ssh
journalctl -xe | grep sshd |grep "Invalid user"
journalctl -xe | grep postfix |grep "connect from unknown"
journalctl -xe | grep sshd |grep "Invalid user" | awk '{print $10}'
journalctl -xe | grep postfix |grep "lost connection after AUTH from" |awk '{print $11}' |sort -u
# Commandes complémentaires :
Ok-ko.png : https://www.linuxtricks.fr/wiki/wiki.php?title=utiliser-journalctl-les-logs-de-systemd
Ok-ko.png : https://www.binsp.net/?post/journald-la-gestion-des-journaux

dmesg

Dmesg : dmesg.fr
Lancer la commande dmesg pour obtenir des informations complémentaires sur d'éventuelles erreurs.
Plus d'informations : https://manpages.debian.org/jessie/manpages-fr-extra/dmesg.1.fr.html

Logwatch

# Rester informé sur l'état du serveur en envoyant les logs par mail avec Logwatch.
# Si une connexion FTP ou SSH indésirable apparaît dans les rapports, des contres mesures pourront être lancées.
# Installer Logwatch :
sudo apt-get install logwatch
# Vérifier que Logwatch fonctionne :
logwatch
# Éditer le fichier de configuration /etc/cron.daily/000logwatch pour paramétrer l'envoie automatique des informations de Logwatch par mail.
sudo nano /etc/cron.daily/000logwatch
# Remplacer la ligne :
/usr/sbin/logwatch --output mail
# Par :
/usr/sbin/logwatch --mailto mon@adresse.mail --detail high
# Pour pouvoir envoyer les mails, un serveur mail doit être configuré sur le serveur distant.
# Si aucun autre serveur mail que celui installé par défaut sur Debian n'a été installé, installer le paquet mailutils permettra d’envoyer des mails.
Source complémentaire : https://www.informatiweb-pro.net/admin-systeme/linux/12--debian-ubuntu-detecter-les-attaques-effectuees-contre-votre-serveur-grace-a-logwatch.html
Source complémentaire : Logcheck : http://logcheck.org

Oncrawl

Payant de 10 à 250 euros mensuellement.
Site officiel : https://fr.oncrawl.com

OSSEC

Site officiel : http://www.ossec.net

Picviz

Picviz est un applicatif qui utilise les fichiers log générés par diverses sources telles Apache, Netfilter, ..., va concevoir des graphiques au format png permettant une vue plus synthétique et plus compréhensible des données contenues dans ces fichiers log, erreurs, anomalies...
Source : https://doc.ubuntu-fr.org/picviz

Screaming frog log analysis

Site officiel : https://www.screamingfrog.co.uk/log-file-analyser/

Syslog-ng

Centraliser les logs avec syslog-ng.
Source : https://doc.ubuntu-fr.org/syslog-ng
Pour se tenir informé de ce qui se passe sur votre serveur et système tout entier, installer syslog-ng.
apt install syslog-ng

Syslog-ng - Configuration de quelques programmes

Fail2ban
# Éditer le fichier /etc/fail2ban/fail2ban.conf :
logtarget = SYSLOG
Apache 2
# Éditer le fichier /etc/apache2/apache2.conf :
ErrorLog syslog:local7
PHP
# Éditer le fichier /etc/php5/apache2/php.ini :
log_errors = On
error_log = syslog

Watussi box

Site officiel : https://box.watussi.fr

Fichiers de logs

Introduction

Configurer la journalisation et l'audit pour collecter toutes les tentatives de piratage.
L'analyse des fichiers de logs est également utile pour découvrir une mauvaise configuration logicielle qui pourrait ouvrir votre système à diverses attaques.
Les fichiers de logs suivants se trouvent dans le dossier /var/log/ depuis un système GNU/Linux Debian.
Le fichier de configuration généraliste est /etc/rsyslog.conf
# Recharger pour appliquer les changements de configurations :
su -
service rsyslog reload
Consulter les pages de manuel syslogd, syslog.conf et logrotate.
Consulter les articles liés à la journalisation :
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/

alternatives.log

.

apache2

Un dossier contenant les logs de 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 grep 'login.php' /var/log/apache2/access.log
sudo egrep -i "denied|error|warn" /var/log/apache2/access.log
sudo tail -f /var/log/apache2/error.log
sudo grep 'warning' /var/log/apache2/error.log
sudo tail -f /var/log/apache2/other_vhosts_access.log
sudo grep 'login' /var/log/apache2/other_vhosts_access.log

access.log

Les accès qui génèrent des requêtes vers le serveur Apache2.

error.log

Les erreurs rencontrées par Apache2.

other_vhosts_access.log

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

Exemples d'erreurs rencontrées

Internal dummy connection
L'erreur suivante 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.

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

SNI et hostname
[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.

apt

Un dossier contenant les logs de apt.

auth.log

Le fichier auth.log est le journal des authentifications.
Les droits par défaut semble être chmod 640 et chown root:adm
Si aucune ligne n'est écrite, vérifier dans le fichier /etc/rsyslog.conf que les règles suivantes soient décommentées :
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
Relancer le service rsyslog et le fichier auth.log sera renseigné.
systemctl restart rsyslog.service
Complément d'informations pour configurer Rsyslog : 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.

boot

Fichier de log de démarrage de la machine de bureau Linux Mint.

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.
# La souris fonctionne à nouveau correctement.
# Je tente un acpi=on
# Même résultat, 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"
# Une demande d'issue est ouverte sur le forum francophone de Linux Mint : 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.

btmp

Le journal btmp garde la trace des tentatives de connexion infructueuses.
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

cloud-init.log

.

cloud-init-output.log

.

cron-dropbox.log

Un fichier de log personnalisé créé par l'administrateur du serveur, qui va conserver les messages suites aux sauvegardes externes effectuées par une tâche cron vers le cloud DropBox.
Erreur rencontrée depuis syslog (Il me semble.) :
/bin/sh: 1: cannot create /var/log/cron-dropbox.log: Permission denied
Le propriétaire et le groupe du fichier cron-dropbox.log ont été changés pour l'utilisateur de debian.
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

daemon.log

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 d'erreurs rencontrées

Deprecated option RSAAuthentication

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

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

denyhosts.service: PID file /run/denyhosts.pid not readable (yet?) after start: No such file or directory
Vous devez 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.
Je redémarre Denyhosts avec sudo, pour voir si cela est suffisant : sudo /etc/init.d/denyhosts restart

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

warning: unable to include '/etc/proftpd/tls.conf
Dans cet exemple, il m'était impossible de charger la configuration TLS.
J'avais alors commenté l'option depuis le fichier de configuration de ProFTPd.

dbconfig-common

Un dossier contenant les logs de dbconfig-common.

debug

.

denyhosts

.

dpkg.log

Derniers paquets installés.

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

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

installer

Un dossier contenant les logs de installer.

kern.log

.

lastlog

.

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

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.

proftpd

Un dossier contenant les logs de proftpd.

mail

.

messages

.

mysql

Un dossier contenant les logs de mysql.
Par défaut, le fichier de logs ne semble pas se remplir.

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.

private

Un dossier contenant les logs de private.

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

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
Par défaut, le module pam_tally2 est déjà installé sur la plupart des distributions Linux et est contrôlé par le paquet PAM lui-même.
Notes sur pam_tally2 :
Ce module 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.
Fichier de configuration : https://www.systutorials.com/docs/linux/man/5-pam.conf/
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
Le paquet pam_tally2 a été écrit par Tim Baverstock et Tomas Mraz.
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/

user.log

.

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

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

Informations complémentaires pour gérer ses logs

Vérifier les logs du boot

Dernier boot :
journalctl -b
Les logs kernel depuis le dernier boot :
journalctl -b -k
Seulement les erreurs depuis le dernier boot :
journalctl -b -p err
ou
journalctl -b -p 3
On peut changer la priorité recherchée (-p) comme suit :
0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug

Signer ses logs

Signer ses logs : http://linux-attitude.fr/post/signer-ses-logs

Utiliser pastebin pour partager les logs de votre machine

Utiliser pastebin pour partager les logs de votre machine avec d'autres administrateurs système.
inxi -Fxxxzc0 |pastebin
sudo rfkill list all |pastebin
dmesg |pastebin

Utiliser pastebin pour partager les logs de vos noyaux avec d'autres administrateurs système.
dpkg -l linux-image* | pastebin

Sous Debian Stretch, le message suivant est affiché :
/usr/bin/pastebinit:42: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5
 release = platform.linux_distribution()[0].lower()
/usr/bin/pastebinit:413: DeprecationWarning: pasteURLopener style of invoking requests is deprecated. Use newer urlopen functions/methods
 url_opener = pasteURLopener()

Le lien vers le fichier en ligne partagé sur pastebin sera tout de même affiché :
http://paste.debian.net/1068315/
# Installer pastebinit comme solution alternative.
sudo apt-get install pastebinit
# Générer un lien vers pastebin pour exporter le contenu d'un fichier.
pastebinit fichier.txt

Partager un rendu visuel de ses logs sur son site

AWStats

AWStats : Installation, Configuration and Reporting : https://awstats.sourceforge.io/docs/awstats_setup.html

Notes complémentaires à reprendre

# La plupart des attaquants ne sont pas intéressés par les données sur une machine.
# C’est la machine elle-même qui les intéresse.
/var/log/fail2ban.log permet de savoir si fail2ban tourne dans le vide ou pas. Il faut avoir une ligne Jail 'sshd' started.
Code : Tout sélectionner.
Jail 'sshd' started
Remonter une attaque et trouver la faille avec les logs de Apache2
linuxfr.org/news/remonter-une-attaque-et-trouver-la-faille-avec-les-logs-d-apache2
Surveiller les connexions en lisant régulièrement le fichier de log /var/log/auth.log
Logs du firewall
Logs d'accès ssh
IPtables SSH se trouve dans /var/log/secure
IPtables ProFTPD se trouve dans /var/log/proftpd/proftpd.log
Logs du système
Logs secure : www.dsfc.net/infrastructure/securite/tentatives-intrusion-serveur-web-linux/
Le pirate exploite une faille d'un site php et utilise le système pour spammer
Logs dans le serveur mail avec les logs de postfix.
Logs dans les logs du serveur web (Peut-être plus compliqué à identifier).
Vérifier le cas d'une mauvaise configuration de postfix qui serait en open relay permettant à n'importe qui d'envoyer massivement du spam.
Tester rapidement le domaine ou l'ip du serveur mail : mxtoolbox.com/diagnostic.aspx
Ajout de fichiers sur le serveur
Des logs dans /tmp (téléchargement d'un code perl ou php stocké sur place).
Si le pirate a trouvé le mot de passe d'un compte
Il a pu se connecter par exemple en SSH on trouve des logs dans /var/log/auth.log sauf si le pirate a effacé les traces.
Vérifier alors si le pirate a ajouté une clé publique lui permettant de se reconnecter malgré un changement de mots de passe.
Les clés publiques sont contenues dans le fichier $HOME/.ssh/authorized_keys
# D'une façon générale, les logs se situent 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

Bibliographie

Aller plus loin avec les logs

Belaïd MOUNSI de la liste Debian user french propose une solution pas forcément évidente à mettre en oeuvre mais efficace une fois mise en place : Le triplet "Elasticsearch, Logstach et Kibana".
Par contre, c'est très gourmand en ressources, pour une machine personnelle ça ne semble pas nécessaire : https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
Autres façons de rechercher des logs spécifiques dans votre système GNU/Linux : https://wiki.debian-fr.xyz/Consulter_les_logs_:_quoi,_o%C3%B9_et_comment_chercher_%3F
Des logs, des logs, oui mais des logs amis : http://linux-attitude.fr/post/des-logs-des-logs-oui-mais-des-logs-amis
Lire et modifier l’historique d’accès : http://linux-attitude.fr/post/lire-et-modifier-l-historique-d-acces
Logs locaux et distants : http://linux-attitude.fr/post/logs-locaux-et-distants
Log de l’historique : http://linux-attitude.fr/post/log-de-lhistorique

NAVIGATION

PARTICIPER ET PARTAGER

Vous êtes sur le wiki de Vision du Web.
Les pages présentées sur le wiki évoluent tous les jours.
Certaines recherches sont peu abouties et incluent des erreurs.
Pour participer sur le wiki, créer un compte utilisateur en haut à droite.
La recherche interne du wiki permet de trouver le contenu qui vous intéresse.
Les informations présentes sur ce wiki sont issues d'une recherche personnelle.
Identifiez-vous pour poser vos questions sur la page de discussion de VisionDuWeb.
Améliorer le contenu des pages en faisant des propositions depuis l'onglet discussion.
Les informations du wiki ne doivent pas servir à nuire à autrui ou à un système informatique.
De nombreux outils gratuits sont listés et disponibles dans la boîte à outils de Vision du web.
D'autres pages du wiki peuvent correspondre à vos attentes. La liste de toutes les pages du wiki.

VALORISER LE WIKI

Valoriser le contenu partagé sur 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.
Consulter le miroir du wiki depuis Planet Hoster : Le miroir du wiki version du 12 Juillet 2019.