Eléments de réponse du DS2 du 16 Avril 2020 à 21H

Question 1 - Distinction des sources d'un analyseur de logs

Pour analyser efficacement les traces d'un réseau ou d'un système, il est crucial d'identifier la provenance de chaque log. Le format et les informations contenues dans les messages permettent de distinguer leur origine :

Un log provenant d'un pare-feu (Firewall)

Les journaux générés par un pare-feu se distinguent par l'indication précise de la règle (ou de l'entrée dans la table de filtrage) qui a provoqué l'action sur le paquet (généralement un blocage ou un rejet).

Exemple de log de pare-feu :

List 102 denied icmp 192.168.0.200 -> 192.168.13.122

Explication : Ici, une requête "ping" (protocole ICMP) provenant de l'adresse IP 192.168.0.200 à destination de 192.168.13.122 a été bloquée. La mention List 102 indique que c'est la règle numéro 102 de la table du pare-feu qui a déclenché ce blocage.

Un log provenant d'un IDS (Intrusion Detection System)

Les traces générées par un système de détection d'intrusions (comme Snort) se caractérisent par la présence d'une signature. Le log indique quelle règle issue de sa base de données (Signature_DB) a permis de classer le paquet comme malveillant ou corrompu, souvent encadrée par des balises spécifiques comme [**].

Exemple de log d'IDS :

[**] IDS024 –RPC- portmap-request-ttdbserv [**]

Explication : L'identifiant IDS024 représente le numéro de l'infraction dans la base de signatures. Ce log signale une tentative illégale d'appel de procédure à distance (RPC).

Un log provenant du service syslogd

Les journaux systèmes gérés par syslogd sur les machines Unix/Linux se remarquent par la présence du numéro de processus (PID - Process ID) associé au service qui a été sollicité (et potentiellement exploité par un attaquant).

Exemple de log syslogd :

May 23 09:30:00 ARCH inetd[1000]:telnet[1020] from 192.168.1.24 40000

Explication : Ce log montre qu'une connexion a eu lieu le 23 mai à 09h30. Le processus qui a servi cette requête (ici telnet) porte le PID 1020. Ce processus est lui-même un processus enfant piloté par le super-démon inetd, dont le PID est 1000.

Question 2 - Les étapes d'analyse des logs

L'analyse de logs après un incident de sécurité suit une méthodologie structurée en plusieurs étapes pour comprendre, qualifier et répondre à l'attaque.

1. Délimiter les traces à analyser : Les fichiers de logs étant souvent très volumineux, la première étape consiste à filtrer et extraire uniquement les lignes jugées pertinentes pour l'incident en cours.
2. Déterminer la source de la trace : Il faut identifier le système ou l'équipement qui a généré chaque log (par exemple Snort, un pare-feu, un serveur web). Pour un IDS comme Snort, les traces sont généralement identifiables par la balise [**] Infraction [**].
3. Évaluer la probabilité d'usurpation d'adresse (Spoofing) : Il est indispensable de s'assurer que l'adresse IP source figurant dans les logs appartient bien à l'attaquant et n'a pas été falsifiée (spoofée) pour masquer sa véritable origine ou impliquer une machine tierce.
4. Décrire l'attaque (le "Quoi ?") : Identifier le but recherché par l'attaquant. Par exemple, l'agresseur cherche-t-il à découvrir la version du service DNS (BIND) tournant sur le serveur ?
5. Déterminer le mécanisme d'attaque (le "Comment ?") : Expliquer la méthode technique employée par le pirate pour parvenir à ses fins (par exemple, l'utilisation d'une requête DNS inverse).
6. Corréler les événements : Comparer les traces avec des bases de données d'attaques connues (comme celles du site www.sans.org). Cela permet de vérifier si cette attaque est une campagne globale touchant d'autres organismes ou une attaque ciblée.
7. Chercher l'évidence d'être ciblé : Déterminer si l'attaque visait spécifiquement votre organisation. Un balayage (scan) de l'intégralité de vos adresses IP publiques suggère généralement une attaque opportuniste, prouvant que vous n'êtes pas une cible spécifique, mais plutôt une victime aléatoire d'un scan de masse.
8. Évaluer la sévérité de l'attaque : Attribuer une note globale (généralement entre -10 et +10) pour quantifier la gravité de l'incident. Cette note se calcule selon la formule suivante : Sévérité = (Criticalité + Gravité) - (Défense Système + Défense Réseau)
   • Criticalité : L'importance et la valeur de la ressource visée.
   • Gravité (Lethality) : Le niveau d'agressivité et de dangerosité de l'attaquant.
   • Défense Système : Les protections locales actives sur la machine cible.
   • Défense Réseau : Les protections périmétriques (pare-feu, IDS) en place.
9. Émettre des recommandations : Si le score de sévérité est positif (> 0), cela indique que l'attaque présente un danger réel et que les défenses ont été ou pourraient être insuffisantes. Des actions correctives doivent être proposées pour renforcer la sécurité et éviter qu'une attaque similaire ne réussisse à l'avenir.

Question 3 - Notion d'adresse IP Spoofée

Définition

Une adresse IP est dite spoofée (usurpée) si l'attaquant modifie l'en-tête de ses paquets réseau pour y placer une adresse IP source qui ne correspond pas à la sienne, mais qui appartient réellement à une autre machine.

Cas permettant de conclure à un IP spoofing

Cas 1 : "Flood attacks" (attaques par inondation) Lorsqu'un agresseur lance une attaque par déni de service (par exemple un SYN Flood), il se déguise souvent en utilisant de multiples adresses IP sources différentes et aléatoires pour envoyer une multitude de paquets simultanément vers la victime. Exemple avec TCPdump :

02:58:01 victime.dom.com > 171.30.67.23.2348 : R:0:0(0) ack 6747198802 win 0
02:58:11 victime.dom.com > 171.32.07.21.1408 : R:0:0(0) ack 6747198802 win 0

La victime répond à de très nombreuses adresses IP différentes dans un laps de temps extrêmement court, ce qui est caractéristique de paquets dont la source a été générée aléatoirement (spoofée).

Cas 2 : Non-respect du protocole TCP (Three-way handshake anomal) Le processus normal de connexion TCP (SYN, SYN/ACK, ACK) n'est pas respecté. Si une cible répond (SYN/ACK) à une adresse IP spoofée, la machine légitime possédant cette adresse IP recevra un acquittement pour une connexion qu'elle n'a jamais initiée. Elle répondra donc immédiatement par un paquet de réinitialisation (R pour RST) pour clore cette connexion anormale. Exemple de logs :

18:34:35.015536 middle.man.com.135 > target.box.com.135: SF 1763821839:1763821839(0) win 512 (ttl 64, id 39426)
18:34:35.015965 target.box.com.135 > middle.man.com.135: S 18827712:18827712(0) ack 1763821840 win 8576 <mss 1460> (DF) (ttl 128, id 56975)
18:34:35.016097 middle.man.com.135 > target.box.com.135: R 1763821840:1763821840(0) win 0 (ttl 128, id 2073)

Dans cette trace, target.box.com répond à une requête avec un drapeau S (SYN/ACK). Mais middle.man.com, qui est l'adresse usurpée et non le véritable attaquant, ne comprend pas cette réponse. Elle met donc fin à l'échange avec un drapeau R (RST). C'est une preuve classique de spoofing.

Question 4 - Exemples d'attaques sur les ports

L'exploitation de services vulnérables ou mal configurés déclarés dans /etc/services peut mener à des attaques. Voici deux exemples :

Exemple 1 : Déni de service par boucle réseau (Ports 7 et 19)

• Le port 7 correspond au service echo (qui renvoie exactement ce qu'on lui envoie).
• Le port 19 correspond au service chargen (qui génère un flux continu de caractères). Un attaquant peut forger un paquet en indiquant l'adresse IP de la cible à la fois en source et en destination, avec le port 19 en source et le port 7 en destination. Cela crée une boucle infinie entre les deux services, entraînant rapidement une saturation de la mémoire et de la bande passante (attaque par déni de service).

Exemple 2 : Collecte d'informations (Port 79)

• Le port 79 correspond au service finger. L'usage de ce port permet à un attaquant de lancer des requêtes pour obtenir des informations sensibles sur les utilisateurs du système (noms de connexion, heures de dernière connexion, inactivité, etc.). C'est typiquement une attaque de type "Probing" (reconnaissance).

Question 5 - Ciblage des éléments du système et classification des attaques

Vulnérabilités et attaques par élément ciblé

Différents éléments d'un système Unix/Linux peuvent être détournés de leur usage initial :

• finger (Port 79) : Service permettant d'obtenir des informations sur les utilisateurs. L'attaquant l'utilise pour faire de la reconnaissance et de la collecte de données (Probing).
• rlogin : Service de connexion à distance (Remote login). L'attaquant cherche à exploiter des faiblesses d'authentification pour obtenir un accès de l'extérieur vers la machine cible.
• cron : Planificateur de tâches. Si un attaquant parvient à éditer la crontab, il peut programmer l'exécution d'une attaque, d'un script malveillant ou d'une porte dérobée (backdoor) dans le futur.
• filesystem : Le système de fichiers. L'attaque consiste souvent à créer une multitude de petits fichiers vides dans le but de saturer la table des inodes. Une fois la table saturée, le système ne peut plus créer de nouveaux fichiers, même s'il reste de l'espace disque.
• ps : Commande de gestion des processus. Un attaquant (ou un script fou) peut causer un déni de service en envoyant un signal de terminaison brutal aux processus critiques via la commande kill -9 PID.
• inetd : Le super-démon réseau. L'attaque vise à modifier le fichier de configuration /etc/inetd.conf pour y injecter un accès illégitime permanent (backdoor).
• su : Commande de substitution d'utilisateur. L'objectif est d'exploiter une faille locale pour qu'un utilisateur standard parvienne à élever ses privilèges jusqu'à obtenir les droits de super-utilisateur (Root).
• unixt-trust : Les relations de confiance entre machines Unix (souvent gérées par les fichiers .rhosts). Un attaquant compromettra ce fichier pour profiter de l'authentification automatique (trust) et rebondir d'une machine à l'autre sans fournir de mot de passe.
• syslogd : Le démon de journalisation. L'attaquant modifiera le fichier syslogd.conf pour stopper l'enregistrement des événements ou rediriger les logs ailleurs, effaçant ainsi les traces de son intrusion.
• SUID : L'attribut de fichier "Set Owner User ID". Un attaquant cherchera à placer ce bit sur l'un de ses propres scripts ou programmes, lui donnant ainsi le pouvoir de l'exécuter avec les privilèges du propriétaire du fichier (souvent ROOT).

Classification des attaques selon leur sévérité (Catégories)

Selon le document de référence, ces attaques peuvent être classées dans les grandes catégories de sécurité suivantes, de la reconnaissance jusqu'à la compromission totale :

• Probing (Sondage/Reconnaissance) :
  • Service ciblé : finger (et implicitement ps si utilisé pour la simple observation des processus de façon malveillante, bien que le document le lie au DoS via kill -9).
• R2L (Remote to Local - d'une machine distante vers un accès local) :
  • Service ciblé : rlogin (tentative de gagner un accès depuis le réseau).
• U2R (User to Root - élévation de privilèges d'un utilisateur simple vers administrateur) :
  • Service ciblé : su (et l'abus de SUID mentionné plus haut).
• DoS (Denial of Service - Déni de service) :
  • Services ciblés : ps (fermeture brutale des processus vitaux), filesystem (saturation des inodes).

Méthode

Face à une épreuve d'analyse de traces et de sécurité réseau, la méthode de travail est primordiale :

1. Apprendre à lire les logs : Un log n'est pas une simple ligne de texte, c'est une structure. Repérez toujours l'horodatage, le protocole (TCP/UDP/ICMP), les adresses IP (Source -> Destination), les ports, et le composant logiciel responsable de la ligne (kernel, snort, inetd).
2. Connaître les ports historiques : Les services Unix classiques (port 7, 19, 79, 514) sont des cibles d'examen fréquentes. Connaître leur fonction nominale permet de comprendre immédiatement comment ils peuvent être détournés.
3. Mémoriser la classification des attaques : Les typologies canoniques telles que Probing, DoS, R2L (Remote to Local) et U2R (User to Root) structurent la gravité d'un incident. Face à une vulnérabilité, demandez-vous systématiquement : "D'où part l'attaquant, et quel niveau de droit obtient-il à la fin ?".
4. Rester collé aux données : Lorsqu'une question vous donne une trace réseau, justifiez toujours votre explication en citant explicitement les flags (S, R, SF) ou les adresses IP visibles dans l'énoncé. L'usurpation d'identité (spoofing) se prouve en lisant l'incohérence des flags TCP, pas en devinant l'intention du hacker.