Un log d’accès est un fichier qui enregistre tous les événements liés à des applications client et l’accès des utilisateurs à une ressource sur un ordinateur. Il peut notamment s’agir de logs d’accès à un serveur web, de logs de commandes FTP ou de logs de requêtes de base de données.
La gestion des logs d’accès est une tâche essentielle des administrateurs système. Les développeurs de logiciels, les ingénieurs opérationnels et les analystes en sécurité utilisent les logs d’accès pour surveiller le fonctionnement de leur application, les personnes qui y accèdent et les événements qui se déroulent en arrière-plan. Les logs d’accès peuvent aider les équipes informatiques à mettre au jour les anomalies, à détecter les menaces et à identifier les problèmes de capacité.
En général, tous les logs d’accès ont un certain nombre d’informations en commun, par exemple :
- Date et heure de l’accès du client
- Adresse IP ou nom d’hôte du client
- Nom de l’utilisateur
- Statut ou gravité de l’événement
- Succès ou échec de l’opération
- Tout message pertinent
Dans cet article, nous verrons pourquoi les logs d’accès sont importants. Nous passerons également en revue les différents types de logs d’accès, ainsi que leur emplacement, leur contenu et les différents paramètres de configuration.
Types de logs d’accès
On peut classer les logs d’accès en trois grandes catégories :
- Logs d’activité
- Logs d’accès au serveur
- Logs d’erreurs
Logs d’activité
Un log d’activité enregistre toutes les actions exécutées par un utilisateur au cours d’une session, telles que l’exécution de commandes, la consultation d’URL ou l’accès à des fichiers. Voici quelques exemples de logs d’activité :
- Log de requêtes générales MySQL
- Log d’activité Azure
- Log d’accès au serveur web Apache
- Logs d’audit Active Directory
Logs d’accès au serveur
Les logs d’accès au serveur contiennent des informations sur les connexions des utilisateurs et leurs demandes de ressources. Contrairement aux logs d’activité, ils ne contiennent pas d’informations détaillées sur les opérations effectuées par l’utilisateur. En voici quelques exemples :
- Lastlog Linux
- Log de sécurité Windows
- Log d’accès au serveur AWS S3
- Log d’accès au serveur Oracle Directory Server
- Audits des connexions à SQL Server
Logs d’erreurs
Les logs d’erreurs contiennent des informations de diagnostic sur les erreurs système et d’applications survenues pendant les sessions client et servent à les résoudre. En voici quelques exemples :
Pour simplifier les choses, cet article se concentre sur les logs d’accès aux serveurs web. En général, ces logs contiennent les trois types d’informations (accès et activités des utilisateurs et erreurs de requête).
Pourquoi capturer les logs d’accès ?
La capture et l’analyse des logs d’accès à un serveur web sont utiles pour les administrateurs système.
Ces logs indiquent la disponibilité et l’intégrité des applications web, ce qui permet d’accélérer la résolution des erreurs. Si le log d’accès affiche un nombre élevé d’erreurs HTTP 404, cela indique que des utilisateurs tentent d’accéder à une ou plusieurs pages inexistantes ou que le site utilise des URL erronées.
Un log d’accès permet également de résoudre les erreurs critiques. Par exemple, un nombre élevé d’erreurs 5xx indique que le serveur web présente des erreurs internes probablement liées au plantage d’une partie du site. L’examen plus en détail du log d’erreurs d’un serveur web peut permettre d’obtenir des informations complémentaires.
Les logs d’accès aux serveurs web présentent également de l’intérêt pour les équipes de marketing numérique. Grâce aux entrées du log, ces équipes sont en mesure d’identifier les pages du site que les utilisateurs consultent et depuis lesquelles ils demandent des informations, remplissent des formulaires, téléchargent des fichiers ou cliquent sur des liens. Toutes ces informations permettent d’affiner le profilage des utilisateurs et d’optimiser le moteur de recherche.
Les ingénieurs SecOps utilisent les logs d’accès aux serveurs web pour détecter les comportements inhabituels ou les anomalies. Par exemple, un pic inattendu de requêtes HTTP GET depuis une plage spécifique d’adresses IP peut être le signe d’une attaque par déni de service distribué (DDoS) depuis plusieurs ordinateurs compromis. Si un serveur web est configuré pour n’accepter que le trafic HTTP/HTTPS en provenance d’un pare-feu d’application web, l’arrivée de requêtes HTTP directes depuis d’autres adresses IP peut révéler un accès non autorisé.
Que contient un log d’accès ?
En général, un log d’accès à un serveur web contient les informations suivantes :
| Date et heure | Date et heure d’accès au site ou à la page, qui peuvent être exprimées en UTC ou dans le fuseau horaire du serveur web |
| Adresse IP source | Adresse IP de l’ordinateur du client |
| IP de destination | Adresse IP du serveur web |
| Nom complet du domaine de destination | Nom de domaine entièrement qualifié du serveur web |
| Port de destination | Port demandé sur le serveur web. Il s’agit généralement du port 80 (port par défaut pour HTTP) ou 443 (port par défaut pour HTTPS), ou de tout autre port, en fonction de celui utilisé par le site web. |
| Protocole | Protocole réseau d’accès client, par exemple HTTP 1.1 |
| Nom de l’utilisateur | Utilisateur accédant au site web (s’il est anonyme, le nom est remplacé par un trait d’union) |
| Ressource | Page ou élément faisant l’objet de la requête |
| Méthode HTTP | Méthode de requête HTTP utilisée (par exemple, GET, POST, etc.) |
| Code d’état HTTP | Code d’état renvoyé par le serveur web (par exemple, 200 OK, 404 Page non trouvée, etc.) |
| Requête URI | Demande de l’application envoyée au site web dans le cadre de la requête HTTP |
| Référent HTTP | Adresse IP ou URL ayant dirigé le client vers ce site web |
| Agent utilisateur HTTP | Type et version du navigateur du client |
| Octets reçus | Nombre d’octets en provenance du client reçus par le serveur web |
| Octets envoyés | Nombre d’octets envoyés par le serveur web au client |
L’extrait suivant d’un log d’accès au serveur web Apache montre un aperçu des différents champs :
116.35.41.41 - - [21/May/2022:11:22:41 +0000] "GET /aboutus.html HTTP/1.1" 200 6430 "http://34.227.9.153/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15"
Dans cet exemple, le log d’accès montre une requête client reçue de l’adresse IP 116.35.41.41 le 21 mai 2022 à 11h22, heure locale du serveur. Le client a accédé à la page aboutus.html du répertoire racine du site web. Le code d’état HTTP était 200 (ce qui indique que la requête du client a abouti), et l’adresse du site web référent est http://34.227.9.153/. L’utilisateur a utilisé le navigateur Safari d’Apple et le serveur web a envoyé 6 430 octets au client lorsqu’il lui a présenté la page.
L’agrégation des données fournies par le log d’accès permet d’obtenir les informations suivantes :
- Nombre de visiteurs uniques par page ou de pages uniques consultées par un visiteur
- Géolocalisation des visiteurs du site
- Parties du site les plus souvent consultées
- Requêtes client les plus utilisées
- Nombre total de codes d’état HTTP différents
Où trouver les logs d’accès ?
L’emplacement du log d’accès à un serveur web dépend du système d’exploitation et du serveur web lui-même.
Par exemple, l’emplacement par défaut du log d’accès au serveur web Apache dans les systèmes RHEL est le suivant : /var/log/httpd. Dans les systèmes Debian comme Ubuntu, l’emplacement est le suivant : /var/log/apache2.
Par défaut, le log d’accès Nginx se trouve dans le répertoire /var/log/nginx pour les systèmes RHEL et Debian.
L’emplacement par défaut du log d’accès pour le service IIS (Internet Information Service) exécuté sur un serveur Windows est le suivant : %SystemDrive%\inetpub\logs\LogFiles\W3SVC, où %SystemDrive% correspond généralement à C:\ et site_id à l’ID du site web hébergé sur le serveur IIS.
Différentes méthodes permettent aux administrateurs de lire les logs d’accès aux serveurs web. Un administrateur du site peut par exemple établir une connexion SSH avec la console du serveur web pour les systèmes Linux et utiliser des commandes telles que cat, tail et grep pour lire le fichier. Parfois, les webmasters doivent utiliser le panneau de commande du fournisseur d’hébergement (par exemple, cpanel) pour ouvrir et lire le log d’accès.
Comment configurer des logs d’accès
Comme pour la plupart des paramètres, il est possible de définir les propriétés d’un log d’accès à un serveur web dans son fichier de configuration. L’emplacement du fichier de configuration principal d’un serveur web dépend de ce dernier et du système d’exploitation. Voici une liste de ces emplacements :
| Serveur web | Système d’exploitation | Fichier de configuration principal |
|---|---|---|
| Apache | RHEL | /etc/httpd/conf/httpd.conf |
| Apache | Debian | /etc/apache2/apache2.conf |
| Nginx | RHEL | /etc/nginx/nginx.conf |
| Nginx | Debian | /etc/nginx/nginx.conf |
| IIS | Windows Server | %WinDir%\System32\Inetsrv\Config\ApplicationHost.config |
Voici la liste des principaux paramètres d’un log d’accès, quel que soit le serveur web :
- Emplacement du log
- Format du log
- Niveau de journalisation
- Rotation des logs
L’emplacement du log d’accès peut être différent pour chacun des sites web hébergés sur le serveur web. Par exemple, dans Apache, la commande suivante définit l’emplacement du log d’accès au serveur :
CustomLog "/var/log/httpd2/access_log" common
Elle peut être remplacée par la commande suivante pour un VirtualHost :
<VirtualHost *:80> ServerName www.mysite.com ServerAlias test.com DocumentRoot /var/www/html/test.com ErrorLog /var/log/httpd/mysite.com/error_log CustomLog /var/log/httpd/mysite.com/access_log combined </VirtualHost>
La configuration du format d’un log d’accès spécifie les champs à inclure dans les entrées du log. Le format d’un log d’accès peut être common ou combined. Voici un exemple de configuration :
LogFormat "%h %l %u %t \"%r\" %>s %b" common
Où :
%hest le nom de l’hôte distant%lindique le nom de connexion distant en provenance d’identd (si disponible)%uest l’ID d’utilisateur du client (si disponible)%test la date à laquelle la requête a été reçue%rest la première ligne de la requête HTTP%>sest le code d’état HTTP renvoyé par le serveur web%best la taille en octets de la ressource renvoyée
Pour savoir comment utiliser le module de log personnalisé pour configurer votre propre format de log d’accès, consultez la documentation Apache.
Le niveau de journalisation et la rotation des logs sont deux autres paramètres de configuration des logs d’accès Apache. Le niveau de journalisation vous permet d’inclure uniquement des événements spécifiques dont le niveau de gravité est égal ou supérieur à un seuil déterminé. Ces niveaux de gravité peuvent être debug, info, notice, warn, error, crit, alert, emerg et tout niveau compris entre trace1 et trace8. Plus le niveau de journalisation est bas, plus les entrées du log sont nombreuses. Dans l’extrait suivant, nous configurons le log d’accès pour qu’il n’enregistre que les messages d’avertissement et de niveau supérieur.
LogLevel warn
Cette commande peut être contournée pour Apache VirtualHosts.
Vous pouvez définir la rotation des logs Apache à l’aide de l’utilitaire Linux logrotate ou du programme rotatelog d’Apache.
Journalisez toutes vos données et répondez à toutes les questions – gratuitement
Falcon LogScale Community Edition (anciennement Humio) offre une plateforme moderne et gratuite de gestion des logs pour le cloud. Exploitez l’ingestion des données de streaming pour bénéficier d’une visibilité instantanée sur les systèmes distribués, de même que détecter et résoudre les incidents.
Falcon LogScale Community Edition, disponible instantanément et gratuitement, inclut les fonctionnalités suivantes :
- Ingestion de jusqu’à 16 Go de données par jour
- Durée de rétention de 7 jours
- Aucune carte de crédit n’est requise
- Accès continu sans période d’essai
- Journalisation sans index, alertes en temps réel et tableaux de bord en direct
- Accès à notre place de marché et à nos packages, y compris aux guides de création de nouveaux packages
- Formation et collaboration avec une communauté active
