Analyse de logs - Historique des versions

Justine le 22 juin 2022 à 11:37

2022-06-22T11:37:56Z

← Version précédente		Version du 22 juin 2022 à 11:37
Ligne 1 :		Ligne 1 :
			[[Category:linux]]
			[[Category:windows]]
	=Définitions=		=Définitions=

Justine : /* PowerShell */

2020-02-05T09:29:02Z

PowerShell

← Version précédente		Version du 5 février 2020 à 09:29
Ligne 448 :		Ligne 448 :
	Get-Eventlog -Index 123456 # Voir un message particulier		Get-Eventlog -Index 123456 # Voir un message particulier
	Get-Eventlog -Message "erreur" #Chercher dans le contenu des messages		Get-Eventlog -Message "erreur" #Chercher dans le contenu des messages
			Get-Eventlog -Newest 100 -LogName "Application" -EntryType Error #Un peu plus pratique
	</syntaxhighlight>		</syntaxhighlight>

Justine le 13 septembre 2019 à 09:04

2019-09-13T09:04:11Z

← Version précédente		Version du 13 septembre 2019 à 09:04
Ligne 439 :		Ligne 439 :
	**Classification : application d'un tag. Ex : application du tag authentification portail captif pour les messages de l'hôte portail-captif.local avec la catégorie syslog auth		**Classification : application d'un tag. Ex : application du tag authentification portail captif pour les messages de l'hôte portail-captif.local avec la catégorie syslog auth
	**Mise à la corbeille des messages connus sans intérêts (définis préalablement)		**Mise à la corbeille des messages connus sans intérêts (définis préalablement)

			== PowerShell ==

			Connaître les commandes PowerShell de base servant à analyser les logs peut être utile :

			<syntaxhighlight lang="powershell">
			Get-Eventlog <journal> #Voir l'intégralité du journal
			Get-Eventlog -Index 123456 # Voir un message particulier
			Get-Eventlog -Message "erreur" #Chercher dans le contenu des messages
			</syntaxhighlight>

Justine : /* Catégories Syslog */

2019-06-30T15:27:13Z

Catégories Syslog

← Version précédente		Version du 30 juin 2019 à 15:27
Ligne 142 :		Ligne 142 :
	Outre les niveaux de gravité, les messages sont orientés en fonction de leur origine, dont les codes sont regroupés suivant 24 types :		Outre les niveaux de gravité, les messages sont orientés en fonction de leur origine, dont les codes sont regroupés suivant 24 types :

			<nowiki>
	Numéro de catégorie Usage		Numéro de catégorie Usage
	0 kernel messages		0 kernel messages
Ligne 167 :		Ligne 168 :
	22 local use 6		22 local use 6
	23 local use 7		23 local use 7
			</nowiki>

	Les catégories n° 16 à 23 (local use) sont "personnalisables". On pourra par exemple définir que les logs d'un site apache en particulier utilise la facilité local4. C'est en somme une sorte de raccourci d'écriture, on sait que local4 = site machin.		Les catégories n° 16 à 23 (local use) sont "personnalisables". On pourra par exemple définir que les logs d'un site apache en particulier utilise la facilité local4. C'est en somme une sorte de raccourci d'écriture, on sait que local4 = site machin.

Justine : /* Sévérité Syslog */

2019-06-30T15:26:52Z

Sévérité Syslog

← Version précédente		Version du 30 juin 2019 à 15:26
Ligne 123 :		Ligne 123 :
	La sévérité d'un message Syslog correspond au degré d'urgence du message. Les 8 sévérités existantes sont définies par les RFC :		La sévérité d'un message Syslog correspond au degré d'urgence du message. Les 8 sévérités existantes sont définies par les RFC :

			<nowiki>
	Numéro de sévérité Usage		Numéro de sévérité Usage
	0 Emergency : system is unusable		0 Emergency : system is unusable
Ligne 132 :		Ligne 133 :
	6 Informational : informational messages		6 Informational : informational messages
	7 Debug : debug-level messages		7 Debug : debug-level messages
			</nowiki>

	Plus grande est la sévérité, moins le message est "grave".		Plus grande est la sévérité, moins le message est "grave".

Justine le 30 juin 2019 à 15:24

2019-06-30T15:24:05Z

← Version précédente		Version du 30 juin 2019 à 15:24
Ligne 341 :		Ligne 341 :
	[https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx Encyclopédie des logs Windows]		[https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx Encyclopédie des logs Windows]
	[[Fichier:Logswin.png\|sans_cadre]]		[[Fichier:Logswin.png\|sans_cadre]]

			=Centralisation et analyse des logs=
			==Principes==
			Centraliser les logs, c'est :

			#collecter les évènements des différents équipements en un point unique
			#Analyser et corréler les logs de l'ensemble du SI
			#Mettre en place des tableau de bord/alertes pour résoudre les pannes/améliorer les performances du SI
			#Archiver les logs/anonymiser à des fins de conservations (obligations légales, etc)

			[[Fichier:Logcent.png\|sans_cadre]]

			==La collecte des logs==
			[[Fichier:Logcoll.png\|sans_cadre]]

			Les logs peuvent être envoyés au serveur central par le daemon syslog au format syslog, mais certaines solutions d'analyse de log s'appuie sur un agent spécialisé à déployer sur chaque équipement à collecter.

			Les logs peuvent être alors "préparés directement" à la source. Les messages peuvent être remis en forme selon des critères personnels et inclure des informations complémentaires.

			Quelque soit la méthode (syslog ou agent), il est possible de filtrer les messages transmis depuis la source, et ainsi choisir de ne pas transmettre certains messages inutiles (synchronisation DFS-R réussie par exemple, il n'est pas utile de savoir qu'un fichier créé par un agent sur le serveur A a correctement été répliqué sur le serveur B. Le nombre de message de réussite de synchronisation peut être conséquent - plusieurs milliers par heure -, occuper de la place inutilement sur les serveurs de logs, accaparer de la bande passante et des ressources serveurs. Il est plus utile de savoir quand la réplication s'est mal passée).

			==Analyser et corréler==
			Pour pouvoir analyser et corréler les logs, il est souvent nécessaire d'extraire les parties intéressantes des messages, comme l'identifiant (nom d'utilisateur, adresse IP, adresse MAC, etc)

			===Extraction des champs d'intérêt===
			L'extraction des champs peut se faire par différentes méthodes (expressions régulières, filtres Grok, etc). L'utilisation d'un grand nombre de ces filtres peut provoquer des baisses significatives de performance.

			Les agents collecteurs permettent aussi de préparer les messages à la source et de les formater sous la forme ATTRIBUT : VALEUR. L'extraction des champs est alors automatique à la réception et le traitement est accéléré.

			===Analyse des évènements===
			Avant l'analyse des messages, il est nécessaire de :

			*extraire les champs d'intérêt
			*tagguer/catégoriser les messages
			*supprimer les messages inutiles

			L'analyse des événements consiste à mettre en place des rapports regroupant un ensemble d'indicateurs.
			Ces rapports seront regroupés dans des tableaux de bord.

			La production des rapports couvre cinq domaines majeurs :
			*Analyse de la Sécurité du Réseau (qui tente d’accéder au réseau?)
			* Analyse des Événements Systèmes (qui reconfigure le firewall ? Qu’est ce qui a changé?)
			*Productivité des employés (quels sont les sites les plus visités, à quelle heure?)
			*Performance du réseau (qui ou quelle application utilise, le plus, la bande passante?)
			*Respect des lois et règlements (est-t-on conforme à CNIL, LSF, HADOPI, SOX, etc?)

			LEs intérêts de ces rapports :
			*Résolution d’incidents et Audits des systèmes informatiques
			*Diminution du nombre des incidents
			*Amélioration du délai de traitement des incidents
			*Sécurisation, Fiabilisation, et meilleure disponibilité du SI
			*Respect du cadre législatif en vigueur :
			**Obligation de rétention des traces d’utilisation des services internet.
			**Obligation de communiquer les traces sur réquisition judiciaire (PSA)
			**Responsabilité pénale de la personne morale et des dirigeants de l’entreprise : Pénalement sanctionnée (Art. 226-17 C. pénal) La mise en œuvre d’un traitement sans précautions utiles est passible de cinq ans d'emprisonnement et de 300 000 euros d'amende (amende quintuplée pour les sociétés)

			Exemples :
			[[Fichier:Logex.png\|vignette]]

			==Alertes et tableaux de bord==

			Alertes

			*Notifications par email, snmp trap, ...
			*Selon des critères tels que mot-clef, regex, source, nb de répétitions, …

			Ex : envoi d'un mail lorsque 10 tentatives de connexion ont échoué avec le compte root

			Reporting/Tableaux de bord
			Un tableau de bord est un ensemble de rapports, comme on a par exemple avec Graylog.

			==Recommandations==
			===Techniques===
			*Lors du dimensionnement des serveurs d'analyse de logs (rôle stockage des logs), l’estimation de l’espace de stockage nécessaire à la conservation des journaux est indispensable
			*Il est recommandé de ne pas effectuer de traitement sur les journaux avant leur transfert
			*Les horloges des équipements doivent être synchronisées
			*Il est recommandé d’utiliser des protocoles d’envoi de journaux basés sur TCP pour fiabiliser le transfert de données entre les machines émettrices et les serveurs centraux

			===Sécurité===
			*Les journaux doivent être automatiquement exportés sur une machine physique différente de celle qui les a générés, en temps réel de préférence
			*La transmission des logs doit être chiffrée (voir par exemple le rfc5425 - [https://tools.ietf.org/html/rfc5425 TLS Transport Mapping for Syslog])
			*Signer et horodater les journaux dès leur création permet d’assurer leur intégrité et d’accroître leur valeur probatoire
			*Il faut conserver une copie des traces brutes pour garder leur valeur juridique

			===Usage===
			*Il est recommandé d’adopter une arborescence pour le stockage des journaux d’événements
			*Si la taille ou la typologie du système d’information le nécessite, une approche hiérarchique pour l’organisation des serveurs de collecte doit être retenue
			*Une politique de rotation des journaux d’évènements doit être formalisée et mise en œuvre sur l’ensemble des équipements du système de journalisation
			*La durée de conservation des fichiers de journaux étant soumise à des contraintes légales et réglementaires, il convient d’en prendre connaissance pour définir les moyens techniques nécessaire à l’archivage des journaux
			*A la réception des messages :
			**Normalisation de la date (ex : JJ/MM/AAAA HH:mm:ss)
			**Indexation des champs d'intérêts : extraction de l'adresse IP grâce à une regex par exemple
			**Classification : application d'un tag. Ex : application du tag authentification portail captif pour les messages de l'hôte portail-captif.local avec la catégorie syslog auth
			**Mise à la corbeille des messages connus sans intérêts (définis préalablement)

Justine : /* Les logs sous Windows */

2019-06-30T15:08:45Z

Les logs sous Windows

← Version précédente		Version du 30 juin 2019 à 15:08
Ligne 339 :		Ligne 339 :

	=Les logs sous Windows=		=Les logs sous Windows=
			[https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx Encyclopédie des logs Windows]
	[[Fichier:Logswin.png\|sans_cadre]]		[[Fichier:Logswin.png\|sans_cadre]]

Justine le 30 juin 2019 à 15:08

2019-06-30T15:08:14Z

← Version précédente		Version du 30 juin 2019 à 15:08
Ligne 337 :		Ligne 337 :

	On retrouvera par exemple dans le fichier /home/elerf/user.log, les messages provenant de lʼhôte zarafa contenant la chaîne de caractères user.		On retrouvera par exemple dans le fichier /home/elerf/user.log, les messages provenant de lʼhôte zarafa contenant la chaîne de caractères user.

			=Les logs sous Windows=
			[[Fichier:Logswin.png\|sans_cadre]]

Justine : /* Le daemon Syslog-NG */

2019-06-30T15:06:48Z

Le daemon Syslog-NG

← Version précédente		Version du 30 juin 2019 à 15:06
Ligne 259 :		Ligne 259 :

	==Le daemon Syslog-NG==		==Le daemon Syslog-NG==
			[https://wikirell.innertech.ovh/images/4/4d/Syslog-ng-ose-guide-admin.pdf Documentation officielle]
	~~<pdf>Fichier~~:Syslog-ng-ose-guide-admin.pdf~~</pdf>~~

	Syslog-ng est le syslog nouvelle génération. Il offre plus de souplesse et permet de rediriger les journaux vers une autre machine. Son utilisation est très répandue.		Syslog-ng est le syslog nouvelle génération. Il offre plus de souplesse et permet de rediriger les journaux vers une autre machine. Son utilisation est très répandue.

Justine le 30 juin 2019 à 15:05

2019-06-30T15:05:55Z

← Version précédente		Version du 30 juin 2019 à 15:05
Ligne 215 :		Ligne 215 :
	on trouve ensuite la partie STRUCTURED-DATA d'un côté et la valeur nulle '-' de l'autre		on trouve ensuite la partie STRUCTURED-DATA d'un côté et la valeur nulle '-' de l'autre
	*le message au format libre : 'su root' failed for lonvick on /dev/pts/8		*le message au format libre : 'su root' failed for lonvick on /dev/pts/8

			===Le protocole syslog===
			''''Par défaut, syslog utilise le port UDP 514''''
			La RFC5426 décrit le transport des messages Syslog au travers UDP. Cette description n'a pas d'intérêt pour ce cours. Ce qui nous intéresse ici, c'est le format des messages Syslog, pas vraiment son transport au travers UDP (on verra par la suite qu'il vaut mieux privilégier TCP pour des raisons de fiabilité).

			=Les logs sous Linux=
			==Emplacements==
			À ajouter, mais je peux déjà citer de tête /var/log

			==Logrotate==
			Le service logrotate permet de faire une rotation des logs. Suivant les paramètres, les logs sont archivés pendant un certain temps, puis supprimés au-delà.

			On retrouve un fichier par application dont les logs doivent tournés. Par exemple, pour mysqld, le fichier de rotation des logs sera celui-ci : /etc/logrotate.d/mysql-server

			<nowiki>
			/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
			daily!#Le script est exécuté tous les jours
			rotate 7! #7 fichiers seront gardés, soit 7 jours de log
			missingok! #Ne pas tenir compte des fichiers manquants
			create 640 mysql adm! #Des fichiers seront créés avec mysql comme proprio, adm comme groupe et des droit à 640 (lecture-écriture pour le proprio; lecture pour le groupe)
			compress #compresser les fichiers créés (autre que le fichier de log du jour)
			sharedscripts #Permet d’executer qu’une seule fois le script logrotate par rotation

			postrotate #Script post rotation // Commande externe
			test -x /usr/bin/mysqladmin \|\| exit 0
			# If this fails, check debian.conf!

			MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"

			if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
			# Really no mysqld or rather a missing debian-sys-maint user?
			# If this occurs and is not a error please report a bug.
			if killall -q -s0 -umysql mysqld; then
			exit 1
			fi
			else
			$MYADMIN flush-logs
			fi
			endscript
			}
			</nowiki>
			La première ligne de ce fichier précise quels sont les fichiers à traiter pour la rotation(/var/log/mysql.log ; /var/log/mysql/mysql.log et /var/log/mysql/mysql-slow.log). Chaque ligne est accompagnée de son explication.

			==Le daemon Syslog-NG==

			<pdf>Fichier:Syslog-ng-ose-guide-admin.pdf</pdf>

			Syslog-ng est le syslog nouvelle génération. Il offre plus de souplesse et permet de rediriger les journaux vers une autre machine. Son utilisation est très répandue.

			Syslog-ng fonctionne sur le modèle suivant : source des logs > filtre > destination.

			Les messages sont traités par source et envoyés à destination en fonction de filtres.

			===Sources des logs===
			Les sources de syslog-ng peuvent être :
			*un pipe unix
			*un fichier spécial tel que /proc/kmsg sous linux
			*un fichier
			*un port tcp ou udp

			Elles sont écrites de la manière suivante dans le fichier de configuration de syslog-ng (/etc/syslog-ng/syslog-ng.conf) :

			<nowiki>
			source s_all {
			# message generated by Syslog-NG
			internal();
			# standard Linux log source (this is the default place for the syslog()
			# function to send logs to)
			unix-stream("/dev/log");
			# messages from the kernel
			file("/proc/kmsg" log_prefix("kernel: "));
			# use the following line if you want to receive remote UDP logging messages
			# (this is equivalent to the "-r" syslogd flag)
			# udp();
			}
			</nowiki>

			===Filtres===
			Les filtres permettent de trier les journaux en fonction de divers paramètres tels que le programme qui émet les logs, des expressions régulières, la facilité ou encore le niveau de gravité.
			Ils sʼécrivent de la façon suivante :
			<nowiki>
			filter f_cron { facility(cron); };
			filter f_daemon { facility(daemon); };
			filter f_kern { facility(kern); };
			filter f_lpr { facility(lpr); };
			filter f_mail { facility(mail); };
			filter f_news { facility(news); };
			filter f_user { facility(user); };
			filter f_uucp { facility(uucp); };
			filter f_duser { match(user) and host(zarafa); };
			</nowiki>

			La dernière ligne récupère les messages de lʼhôte zarafa contenant le mot user.

			===Destination des logs===
			Les destinations dans syslog-ng peuvent être de diverses formes :
			*un fichier
			*un pipe
			*une socket unix
			*une commande
			*un port udp ou tcp
			*et même un terminal

			<nowiki>
			destination df_syslog { file("/var/log/syslog"); };
			destination df_cron { file("/var/log/cron.log"); };
			destination df_daemon { file("/var/log/daemon.log"); };
			destination df_kern { file("/var/log/kern.log"); };
			destination df_lpr { file("/var/log/lpr.log"); };
			destination df_mail { file("/var/log/mail.log"); };
			destination df_user { file("/var/log/user.log"); };
			destination dp_xconsole { pipe("/dev/xconsole"); };
			destination d_user { file("/home/elerf/user.log" owner("root")); };
			</nowiki>

			===Règles d'enregistrement===
			Syslog-ng-ose-guide-admin.pdf
			Les règles dʼenregistrement dans syslog-ng sont préfixées par log. Elles permettent de traiter les messages de bout en bout. Source ; filtre ; destination.

			log { source(s_all); filter(f_duser); destination(d_user); };
			log { source(s_all); filter(f_auth); destination(df_auth); };

			On retrouvera par exemple dans le fichier /home/elerf/user.log, les messages provenant de lʼhôte zarafa contenant la chaîne de caractères user.

Analyse de logs - Historique des versions

Justine le 22 juin 2022 à 11:37

Justine : /* PowerShell */

Justine le 13 septembre 2019 à 09:04

Justine : /* Catégories Syslog */

Justine : /* Sévérité Syslog */