Réseaux informatiques : les notions nécessaires en cybersécurité

Niveau : débutant.

Prérequis : savoir utiliser un navigateur, ouvrir un terminal et identifier le système d'exploitation de ta machine. Aucune connaissance préalable du modèle OSI, de Wireshark ou de la programmation n'est nécessaire.

L'exercice utilise uniquement l'interface de bouclage de ta machine et un service local que tu démarres toi-même. Il ne nécessite ni scan, ni interception d'un réseau partagé, ni contact avec une cible externe.

Une capture réseau peut contenir des noms, adresses, requêtes, cookies ou autres données sensibles. Si tu utilises ultérieurement un outil de capture, limite l'interface, la durée et le filtre au strict besoin. Ne capture pas les communications d'autres personnes sans autorisation explicite.

Les modèles en couches aident à séparer les responsabilités, mais la compétence utile en cybersécurité consiste à suivre un échange réel. Lorsqu'un navigateur accède à une adresse HTTPS, plusieurs opérations peuvent intervenir : recherche du nom, sélection d'une route, résolution d'un voisin sur le réseau local, transport des données, négociation TLS puis échange HTTP.

Le modèle TCP/IP peut être présenté en quatre ensembles pratiques :

1. Accès au réseau : carte réseau, Wi-Fi ou Ethernet, trames et communication avec les voisins du segment.
2. Internet : adressage IP et acheminement entre réseaux.
3. Transport : TCP, UDP et identification des points de communication avec des ports.
4. Application : DNS, HTTP, SSH, messagerie et autres protocoles utilisés par les logiciels.

Le modèle OSI comporte sept couches et apporte un vocabulaire plus détaillé. Il est utile pour raisonner, mais les protocoles réels ne se rangent pas toujours dans une seule case sans discussion. Il vaut mieux pouvoir dire « cette adresse IP identifie une interface dans ce contexte, ce port désigne une extrémité de transport et cette requête appartient au protocole applicatif » que mémoriser un tableau sans suivre les données.

La cybersécurité ajoute le contexte. Une connexion n'est pas suspecte uniquement parce qu'elle utilise un port inhabituel. Un port courant ne garantit pas non plus que l'application est légitime. Il faut relier l'adresse source, l'adresse destination, le protocole, l'heure, le processus, l'identité, le volume et le comportement attendu.

La RFC 1122 décrit les exigences historiques des hôtes Internet pour les couches de communication. Elle reste une référence conceptuelle, mais certaines parties ont été complétées ou mises à jour par des RFC plus récentes.

Une adresse IP identifie une interface dans un contexte réseau. Elle ne désigne pas nécessairement une personne ni une machine physique unique. Un appareil peut posséder plusieurs interfaces et plusieurs adresses. Une même adresse publique peut aussi représenter plusieurs systèmes placés derrière une traduction d'adresses.

En IPv4, une adresse contient 32 bits. L'écriture 192.0.2.10/24 indique que les 24 premiers bits forment le préfixe réseau. Le /24 correspond au masque 255.255.255.0. Les hôtes dont les adresses appartiennent au même préfixe peuvent généralement communiquer directement au niveau IP si le réseau local et ses politiques le permettent. Une destination située dans un autre préfixe nécessite une route, souvent via une passerelle par défaut.

Les plages IPv4 privées définies par la RFC 1918 sont 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Elles ne sont pas routées comme des adresses publiques sur l'Internet mondial. Elles peuvent être réutilisées dans de nombreux réseaux distincts. Voir 10.0.0.5 dans un journal ne permet donc pas de savoir à quelle organisation ou machine cette adresse appartenait sans le contexte du réseau et de l'heure. Les blocs 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24 sont, eux, destinés aux exemples documentaires.

IPv6 utilise des adresses de 128 bits. Sa notation hexadécimale autorise certaines abréviations, comme la suppression des zéros en tête et l'utilisation unique de :: pour une suite de groupes nuls. La RFC 8200 définit le protocole IPv6. Il ne faut pas traiter IPv6 comme un détail facultatif : un système peut communiquer en IPv6 alors qu'un contrôle ou une analyse ne surveille que l'IPv4.

La table de routage décide de la prochaine étape selon les préfixes disponibles. La route la plus spécifique est généralement préférée. Une route par défaut couvre les destinations pour lesquelles aucune route plus précise n'est connue. Lors d'un diagnostic, relève l'adresse, le préfixe, l'interface, la passerelle éventuelle et la table de routage avant de conclure qu'un problème vient du pare-feu ou de l'application.

Sur un réseau Ethernet IPv4, un hôte qui veut joindre une adresse du même segment doit connaître l'adresse matérielle du voisin. ARP associe une adresse IPv4 à une adresse de couche liaison dans ce contexte local. Pour une destination distante, l'hôte cherche généralement l'adresse matérielle de sa passerelle, pas celle du serveur final. ARP ne traverse pas les routeurs comme une requête IP ordinaire.

IPv6 utilise Neighbor Discovery dans ICMPv6 pour plusieurs fonctions liées aux voisins et aux routeurs. Il ne faut pas le réduire à un simple renommage d'ARP. Un filtrage excessif d'ICMPv6 peut perturber des fonctions nécessaires au réseau IPv6, notamment la découverte des voisins et certains messages indispensables au bon acheminement.

DHCP permet à un client d'obtenir des paramètres comme une adresse, un préfixe, une passerelle et des serveurs DNS. Ces paramètres ont une durée et un périmètre. Une adresse attribuée dynamiquement peut changer, ce qui impose de corréler les journaux DHCP, les heures et les identifiants disponibles lors d'une enquête autorisée. Une adresse observée sans horodatage précis constitue donc une preuve incomplète.

Le DNS associe des noms à différents types de données. Les enregistrements A et AAAA contiennent respectivement des adresses IPv4 et IPv6, mais le DNS gère aussi des alias, serveurs de courrier, serveurs de noms et textes. Une application demande généralement une résolution à un résolveur récursif, qui répond depuis son cache ou poursuit la recherche auprès d'autres serveurs. La terminologie actuelle est consolidée par la RFC 9499.

Il faut distinguer la résolution d'un nom et la connexion au service. Une réponse DNS peut fournir plusieurs adresses sans garantir qu'elles sont joignables. Une application peut utiliser un cache, un fichier local ou un mécanisme de résolution chiffré. Le nom demandé, le type, le code de réponse, le résolveur interrogé et le TTL donnent le contexte nécessaire.

En analyse de sécurité, une requête rare n'est pas automatiquement malveillante. Vérifie le processus à l'origine de la demande, l'utilisateur, la fréquence, les réponses et l'activité qui suit. Une anomalie est un point de départ pour l'enquête, pas une conclusion.

TCP et UDP utilisent des numéros de port pour distinguer les communications de plusieurs applications sur un même hôte. Un port n'est pas une porte physique et ne constitue pas à lui seul un service. Il faut toujours l'associer au protocole de transport, à une adresse et à un état observé. Le port 53 en TCP et le port 53 en UDP représentent deux extrémités distinctes.

Une socket peut être décrite par le protocole, l'adresse locale et le port local. Pour une communication établie, les adresses et ports locaux et distants permettent de distinguer le flux. Un serveur écoute généralement sur une adresse et un port, puis le système crée des états supplémentaires pour les clients. Une écoute sur 127.0.0.1 reste limitée à l'hôte local, tandis qu'une écoute sur toutes les interfaces peut être accessible depuis plusieurs réseaux si le routage et le pare-feu l'autorisent.

TCP fournit aux applications un flux d'octets fiable et ordonné. Il établit un état entre les extrémités, utilise des numéros de séquence, accuse réception de données et retransmet certaines pertes. La RFC 9293 constitue la spécification moderne de TCP. L'établissement d'une connexion ne prouve pas que l'application est saine ni que l'utilisateur est autorisé. Il montre seulement qu'un échange TCP a atteint cet état.

UDP transporte des datagrammes sans fournir les mêmes garanties de connexion, d'ordre ou de retransmission. Une application peut ajouter ses propres mécanismes de fiabilité. DNS, certains usages de DHCP et des protocoles multimédias peuvent employer UDP. L'absence d'un état TCP ne signifie donc pas l'absence d'échange.

Les numéros de port connus donnent un indice, pas une preuve. Un serveur HTTP peut écouter ailleurs que sur 80, et un autre protocole peut utiliser 80. Pour identifier ce qui se passe, croise le port avec le processus, le contenu protocolaire lorsque sa consultation est autorisée, la configuration du serveur et les journaux de l'application.

La traduction d'adresses, ou NAT, modifie certaines informations d'adressage lors du passage entre réseaux. Un routeur domestique traduit couramment plusieurs adresses privées vers une adresse publique. Il maintient un état permettant de renvoyer les réponses au bon hôte interne. Cette traduction complique l'attribution : un journal externe peut ne montrer que l'adresse publique, tandis que le journal du routeur contient l'association temporaire avec l'adresse et le port internes.

NAT et pare-feu ne sont pas synonymes. Un pare-feu applique une politique à des communications selon des informations comme les interfaces, adresses, ports, protocoles, états et parfois identités ou applications. Un pare-feu avec suivi d'état peut autoriser les réponses appartenant à une communication initiée depuis l'intérieur sans accepter de nouvelles connexions entrantes. Il faut connaître le sens du flux et le point où la règle s'applique.

TLS protège les échanges de protocoles applicatifs, notamment HTTPS, contre la lecture et la modification par des intermédiaires, sous réserve d'une validation correcte et de paramètres adaptés. Le chiffrement ne masque pas nécessairement toutes les métadonnées. Les adresses IP, volumes, horaires et certains éléments nécessaires à l'acheminement peuvent rester observables. La visibilité exacte dépend du protocole, de sa version et du point de capture.

Le point d'observation détermine les faits accessibles. Une capture sur le poste voit ce que cette interface reçoit ou émet. Une sonde derrière un NAT voit des adresses différentes d'une sonde placée devant. Un journal applicatif peut connaître l'identité et l'URL, tandis qu'un équipement réseau ne voit parfois qu'un flux chiffré entre deux adresses.

Pour analyser un événement, documente l'emplacement et l'heure du capteur, les interfaces et réseaux concernés, le sens du flux, les éventuelles traductions, le protocole de transport, les ports et les données applicatives réellement visibles. Cette discipline évite de transformer une limite de visibilité en certitude. Si un capteur ne voit pas le contenu chiffré, il ne peut ni confirmer ni exclure une action applicative précise à partir du seul volume.

Cadre légal et technique : réalise cet exercice uniquement sur ta machine. Le serveur est lié à 127.0.0.1, l'adresse de bouclage IPv4. Il n'est pas destiné aux autres appareils. N'utilise pas une autre adresse, ne scanne aucun port et n'élargis pas une éventuelle capture à une interface partagée.

Préparer un contenu local

Crée un dossier vide nommé lab-reseau, place-toi dedans puis crée un fichier index.html contenant uniquement :

<!doctype html>
<title>Laboratoire local</title>
<p>Connexion locale réussie.</p>

Si Python est installé, lance dans ce dossier :

python3 -m http.server 8000 --bind 127.0.0.1

Sous Windows, la commande peut être python -m http.server 8000 --bind 127.0.0.1 selon l'installation. Laisse ce terminal ouvert uniquement pendant l'exercice.

Vérifier l'écoute et créer une connexion

Sous Linux, exécute dans un second terminal :

ss -lnt | grep 8000

Sous PowerShell :

Get-NetTCPConnection -State Listen -LocalPort 8000

Relève l'adresse locale, le port, le protocole et l'état. L'adresse attendue est 127.0.0.1, pas 0.0.0.0 ni une adresse du réseau local. Crée ensuite une requête locale avec curl -v http://127.0.0.1:8000/ ou, sous PowerShell, Invoke-WebRequest http://127.0.0.1:8000/. Observe la requête affichée par le serveur et relève le code HTTP.

Reviens enfin dans le terminal du serveur et utilise Ctrl+C. Relance la commande d'observation. Le port 8000 ne doit plus apparaître en écoute pour ce serveur.

Critère de réussite

L'exercice est réussi si tu peux expliquer pourquoi 127.0.0.1 limite l'échange à la machine, distinguer le port serveur 8000 du port client temporaire, relier l'écoute au processus Python et montrer que l'arrêt du processus supprime l'écoute. Tu dois aussi expliquer pourquoi cette observation locale n'autorise aucune conclusion sur un service distant.

Une erreur fréquente consiste à traiter chaque adresse IP comme l'identité stable d'un utilisateur. Les attributions dynamiques, VPN, proxys, NAT, appareils partagés et changements de réseau rendent cette conclusion fragile. Une adresse devient utile lorsqu'elle est corrélée à l'heure, au capteur, aux journaux d'attribution et au contexte du système.

Evite aussi de confondre nom DNS et adresse IP, de croire qu'un port identifie avec certitude une application, d'oublier de préciser TCP ou UDP, de considérer toute adresse privée comme fiable ou de conclure qu'un service est exposé parce qu'il écoute localement. Analyse IPv4 et IPv6 lorsque les deux sont actifs. Ne désactive pas un pare-feu pour résoudre un problème sans identifier la règle en cause. Ne capture jamais tout le trafic d'un réseau partagé pour un simple exercice.

Pour analyser un flux, utilise une fiche courte :

1. Question : quel échange cherches-tu à expliquer ?
2. Périmètre : quels systèmes, interfaces et horaires sont autorisés ?
3. Source : quel capteur ou journal fournit l'information ?
4. Adressage : quelles adresses, versions IP et éventuelles traductions ?
5. Transport : TCP ou UDP, ports et état disponible ?
6. Application : quel protocole est réellement observé ou seulement supposé ?
7. Contexte : quel processus, utilisateur et comportement attendu ?
8. Limite : quelle information manque ou n'était pas visible ?

Cette méthode s'applique à une commande locale, une capture de laboratoire ou un événement SIEM. Elle ne fournit pas automatiquement une conclusion de sécurité. Elle rend le raisonnement vérifiable et permet de demander la donnée complémentaire pertinente. Une bonne analyse sépare explicitement les faits, les hypothèses et les limites.