Network Services
Explore les services réseau essentiels qui font fonctionner Internet : DNS, DHCP, HTTP, email, FTP et plus encore. Comprends leur fonctionnement et leurs vulnérabilités.
- Comprendre la résolution DNS et ses types d'enregistrements
- Maîtriser le processus DORA du DHCP
- Connaître les méthodes HTTP et la sécurisation HTTPS
- Identifier les protocoles email (SMTP, POP3, IMAP)
- Différencier FTP actif et passif et leurs alternatives sécurisées
🌐 9.1 — DNS (Domain Name System)
Le DNS est le service qui traduit les noms de domaine lisibles par les humains (comme www.google.com) en adresses IP compréhensibles par les machines (comme 142.250.179.68). Sans DNS, tu devrais mémoriser des adresses numériques pour chaque site.
Le DNS, c'est l'annuaire téléphonique d'Internet. Tu cherches le nom d'une personne (nom de domaine) et l'annuaire te donne son numéro (adresse IP). Sans cet annuaire, tu devrais connaître par coeur le numéro de chaque personne que tu veux appeler.
Hierarchie DNS complete
Le DNS est organise en une structure hierarchique arborescente a 4 niveaux. Un nom de domaine complet se lit de droite a gauche (du plus general au plus specifique) :
13 root servers nommes de A a M, chacun gere par un operateur different :
| A — Verisign | B — USC-ISI | C — Cogent | D — U Maryland |
| E — NASA | F — ISC | G — US DoD | H — US Army |
| I — Netnod | J — Verisign | K — RIPE NCC | L — ICANN |
| M — WIDE Project | |||
En realite, ce sont 13 adresses IP (identifiants) derriere lesquelles se cachent des centaines de serveurs physiques repartis dans le monde entier grace a l'anycast. Ils connaissent les adresses de tous les serveurs TLD.
Gerent les domaines de premier niveau. 3 categories principales :
- gTLD (generic) :
.com,.org,.net,.edu,.gov,.info, etc. - ccTLD (country code) :
.fr,.uk,.de,.jp,.ca, etc. - Infrastructure :
.arpa(resolution inverse, ex:in-addr.arpa)
Ils connaissent les serveurs autoritatifs de chaque domaine enregistre dans leur TLD.
Le SLD est le nom de domaine enregistre par l'organisation (ex: google dans google.com, cisco dans cisco.com).
Les serveurs autoritatifs contiennent les enregistrements DNS reels (A, AAAA, MX, etc.) d'un domaine specifique. C'est la source de verite.
Les sous-domaines sont des divisions supplementaires gerees par le proprietaire du domaine : www, mail, ftp, blog, etc.
Exemple : dans www.cisco.com. → www est le subdomain, cisco est le SLD, com est le TLD, . est la racine.
Generalement ton FAI ou un service public comme 8.8.8.8 / 8.8.4.4 (Google), 1.1.1.1 (Cloudflare), ou 9.9.9.9 (Quad9). Il fait le travail de recherche a ta place en interrogeant les serveurs de la hierarchie et met en cache les reponses selon le TTL.
FQDN — Fully Qualified Domain Name
Un FQDN est le nom de domaine complet, incluant tous les niveaux jusqu'a la racine, termine par un point :
Format du message DNS
Chaque message DNS (requete et reponse) a le meme format, compose de 5 sections :
| Section | Description | Present dans |
|---|---|---|
| Header | ID de transaction (16 bits), flags (QR, Opcode, AA, TC, RD, RA, RCODE), compteurs pour chaque section | Requete + Reponse |
| Question | Le nom de domaine recherche (QNAME), le type (QTYPE: A, MX...) et la classe (QCLASS: IN pour Internet) | Requete + Reponse |
| Answer | Les enregistrements de ressource (Resource Records) repondant a la question | Reponse |
| Authority | Les enregistrements NS pointant vers les serveurs autoritatifs pour le domaine | Reponse |
| Additional | Informations supplementaires (ex: adresses IP des serveurs NS mentionnes dans Authority) | Reponse |
Types d'enregistrements DNS
| Type | Nom complet | Role | Format / Exemple |
|---|---|---|---|
| A | Address | Associe un nom a une adresse IPv4 | www.example.com. IN A 93.184.216.34 |
| AAAA | IPv6 Address | Associe un nom a une adresse IPv6 | www.example.com. IN AAAA 2606:2800:220:1::248 |
| MX | Mail Exchange | Indique le serveur de messagerie du domaine. Champ priority (plus petit = prioritaire) | example.com. IN MX 10 mail.example.com.example.com. IN MX 20 mail2.example.com.(10 est plus prioritaire que 20) |
| CNAME | Canonical Name | Alias d'un nom vers un autre nom (le nom canonique). Ne peut pas coexister avec d'autres types pour le meme nom | blog.example.com. IN CNAME www.example.com. |
| NS | Name Server | Indique les serveurs DNS autoritatifs pour une zone | example.com. IN NS ns1.example.com. |
| PTR | Pointer | Resolution inverse (IP vers nom). Utilise le domaine special in-addr.arpa (IPv4) ou ip6.arpa (IPv6) | 34.216.184.93.in-addr.arpa. IN PTR www.example.com. |
| TXT | Text | Texte libre. Utilise pour SPF, DKIM, DMARC, verification de domaine | example.com. IN TXT "v=spf1 include:_spf.google.com ~all" |
| SOA | Start of Authority | Definit les parametres de la zone DNS : serveur primaire, email admin, serial, refresh, retry, expire, minimum TTL | example.com. IN SOA ns1.example.com. admin.example.com. (2024010101 3600 900 604800 86400) |
| SRV | Service Locator | Localise un service specifique. Format : _service._proto.name. TTL IN SRV priority weight port target | _sip._tcp.example.com. IN SRV 10 60 5060 sip.example.com. |
Resolution recursive vs iterative
Recursive Query
Le client demande au resolver recursif de trouver la reponse complete. Le resolver fait tout le travail :
- Le client demande : "Quelle est l'IP de
www.cisco.com?" - Le resolver verifie d'abord son cache local
- Si pas en cache, il interroge le root server → obtient l'adresse du serveur TLD
.com - Le resolver interroge le serveur TLD .com → obtient l'adresse du serveur autoritatif de
cisco.com - Le resolver interroge le serveur autoritatif → obtient l'adresse IP
- Le resolver met en cache la reponse (selon le TTL) et la renvoie au client
Avantage : Simple pour le client, tout le travail est delegue. C'est le mode utilise entre le client et son resolver DNS configure (FAI, 8.8.8.8, etc.).
Iterative Query
Le serveur DNS repond avec la meilleure information qu'il possede. S'il ne connait pas la reponse, il renvoie une referral (reference vers un autre serveur) :
- Le resolver demande au root server → "Je ne sais pas, mais demande au serveur TLD .com (referral)"
- Le resolver demande au serveur TLD .com → "Je ne sais pas, mais demande au serveur autoritatif de cisco.com (referral)"
- Le resolver demande au serveur autoritatif → "Voici l'adresse IP ! (authoritative answer)"
Avantage : Reduit la charge sur les serveurs DNS intermediaires. C'est le mode utilise entre le resolver recursif et les serveurs de la hierarchie DNS.
En pratique : le client fait une requete recursive vers le resolver, et le resolver fait des requetes iteratives vers les serveurs de la hierarchie.
DNS Caching (Mise en cache)
Le DNS utilise intensivement le cache a plusieurs niveaux pour reduire le trafic et accelerer les reponses :
- Cache du navigateur : le navigateur garde en memoire les resolutions recentes (Chrome:
chrome://net-internals/#dns) - Cache de l'OS : le systeme d'exploitation maintient un cache DNS local. Commandes :
ipconfig /displaydns(Windows),systemd-resolve --statistics(Linux) - Cache du resolver recursif : le serveur DNS recursif (FAI, Google DNS) cache les reponses selon le TTL de chaque enregistrement
- Fichier hosts : resolution locale statique (
/etc/hostssur Linux,C:\Windows\System32\drivers\etc\hostssur Windows) — consulte AVANT le DNS
TTL (Time To Live) : chaque enregistrement DNS a un TTL en secondes. Quand le TTL expire, le cache doit re-interroger le serveur autoritatif. Vidage du cache : ipconfig /flushdns (Windows), systemd-resolve --flush-caches (Linux).
Securite DNS
Le DNS n'a pas ete concu avec la securite en tete. Plusieurs extensions et protocoles ont ete developpes pour combler ces faiblesses :
DNSSEC ajoute des signatures cryptographiques aux reponses DNS pour garantir :
- Authenticite : la reponse vient bien du serveur autoritatif
- Integrite : la reponse n'a pas ete modifiee en transit
DNSSEC utilise des enregistrements supplementaires : RRSIG (signature), DNSKEY (cle publique), DS (Delegation Signer), NSEC/NSEC3 (preuve de non-existence).
Limitation : DNSSEC ne chiffre PAS les requetes — il ne fait que signer les reponses. Le contenu reste visible en clair.
DNS over HTTPS encapsule les requetes DNS dans des requetes HTTPS standard (port 443).
- Avantages : chiffrement complet des requetes DNS, difficile a bloquer (meme port que le web), protege la vie privee contre l'ecoute du FAI
- Inconvenients : rend la surveillance reseau plus difficile pour les SOC, peut contourner les politiques de filtrage DNS de l'entreprise
- Providers : Google (
https://dns.google/dns-query), Cloudflare (https://cloudflare-dns.com/dns-query)
DNS over TLS encapsule les requetes DNS dans une connexion TLS sur le port dedie 853.
- Avantages : chiffrement des requetes DNS, port dedie donc plus facile a identifier et gerer pour les administrateurs reseau
- Inconvenients : facile a bloquer (il suffit de bloquer le port 853), moins repandu que DoH
- Difference avec DoH : DoT utilise un port dedie (853), DoH se melange au trafic HTTPS (443). DoT est prefere en entreprise (controlable), DoH est prefere pour la vie privee.
Le DNS tunneling est une technique d'exfiltration de donnees et de Command & Control (C2) qui encode des donnees dans les requetes DNS (sous-domaines) et les reponses (enregistrements TXT).
Exemple : encoded-data.malicious-domain.com — les donnees volees sont encodees dans le sous-domaine.
Indicateurs de detection (IOC) :
- Volume inhabituellement eleve de requetes DNS vers un meme domaine
- Sous-domaines anormalement longs (ex : > 50 caracteres)
- Entropie elevee dans les noms de domaine (caracteres aleatoires)
- Nombreuses requetes TXT (utilisees pour le canal retour)
- Requetes vers des domaines nouvellement enregistres
Defenses : monitoring DNS, limitation du taux de requetes, blocage des requetes vers des domaines suspects, inspection des reponses TXT.
- DNS Cache Poisoning / Spoofing : injection de fausses reponses dans le cache d'un resolver pour rediriger les utilisateurs
- DNS Amplification (DDoS) : utilisation de serveurs DNS ouverts pour amplifier le trafic vers une victime (requete petite → reponse volumineuse)
- DNS Hijacking : modification des enregistrements DNS (compromission du registrar ou du serveur autoritatif)
- DNS Tunneling : exfiltration de donnees et C2 via les requetes/reponses DNS
📋 9.2 — DHCP (Dynamic Host Configuration Protocol)
Le DHCP attribue automatiquement des adresses IP et d'autres paramètres réseau (masque, passerelle, serveur DNS) aux appareils qui se connectent. Sans DHCP, chaque appareil devrait être configuré manuellement.
Le DHCP, c'est comme la réception d'un hôtel. Quand tu arrives, la réception (serveur DHCP) t'attribue un numéro de chambre (adresse IP), te donne le plan de l'hôtel (masque de sous-réseau), t'indique la sortie (passerelle par défaut) et le numéro du concierge (serveur DNS). Tout est automatique.
Le processus DORA — Detail exact
L'attribution d'une adresse IP par DHCP suit 4 etapes, mnemotechnique DORA. DHCP utilise UDP : port 67 (serveur) et port 68 (client) :
Le client envoie un message broadcast sur le reseau : "Y a-t-il un serveur DHCP ici ?"
Source IP : 0.0.0.0 (le client n'a pas encore d'IP)
Dest IP : 255.255.255.255 (broadcast)
Source Port : UDP 68 (client) → Dest Port : UDP 67 (serveur)
Source MAC : adresse MAC du client → Dest MAC : FF:FF:FF:FF:FF:FF
DHCPDISCOVER — Le client inclut son adresse MAC pour s'identifier et peut demander une IP specifique (option 50).
Le serveur DHCP repond avec une proposition d'adresse IP, accompagnee du masque, de la passerelle, du serveur DNS et de la duree du bail.
Source IP : IP du serveur DHCP (ex: 192.168.1.1)
Dest IP : 255.255.255.255 (broadcast, car le client n'a pas encore d'IP) ou unicast vers la MAC du client
Source Port : UDP 67 → Dest Port : UDP 68
DHCPOFFER (ex: "Je te propose 192.168.1.50, masque 255.255.255.0, GW 192.168.1.1, DNS 8.8.8.8, bail 24h")
Plusieurs serveurs DHCP peuvent repondre avec des offres differentes.
Le client accepte une offre en envoyant un broadcast DHCPREQUEST (pour informer TOUS les serveurs DHCP).
Source IP : 0.0.0.0 (toujours pas d'IP confirmee)
Dest IP : 255.255.255.255 (broadcast)
Pourquoi broadcast ? Pour que les autres serveurs DHCP sachent que leur offre a ete refusee et qu'ils peuvent liberer l'IP proposee.
Le message contient l'identifiant du serveur choisi (Server Identifier, option 54).
Le serveur confirme l'attribution et envoie tous les parametres reseau definitifs.
Source IP : IP du serveur DHCP
Dest IP : 255.255.255.255 ou unicast vers le client
DHCPACK — Le client peut maintenant utiliser l'adresse IP pendant la duree du bail (lease).
Si le serveur refuse : il envoie un DHCPNAK et le client recommence le processus DORA.
Le bail DHCP (Lease) — Renouvellement
L'adresse IP n'est pas attribuee pour toujours. Elle est pretee pour une duree definie appelee bail (lease). Le client doit renouveler son bail avant expiration :
| Moment | % du bail | Action | Type |
|---|---|---|---|
| T1 — Renewal | 50% | Le client envoie un DHCPREQUEST unicast directement au serveur DHCP d'origine pour renouveler son bail. Si le serveur repond avec un DHCPACK, le bail est renouvele. | Unicast |
| T2 — Rebinding | 87.5% | Si aucune reponse a T1, le client envoie un DHCPREQUEST broadcast pour trouver N'IMPORTE QUEL serveur DHCP qui peut renouveler son bail. | Broadcast |
| Expiration | 100% | Le bail expire. Le client perd son adresse IP, arrete toute communication reseau et recommence le processus DORA complet. | Reset |
Attaques DHCP et defenses
Un attaquant place un faux serveur DHCP sur le reseau. Ce serveur pirate repond aux requetes DISCOVER avant le serveur legitime et distribue de fausses configurations :
- Fausse passerelle par defaut → tout le trafic passe par l'attaquant (Man-in-the-Middle)
- Faux serveur DNS → redirection vers des sites malveillants (DNS poisoning)
- Faux masque de sous-reseau → isolation du client ou redirection du trafic
L'attaquant envoie des milliers de requetes DHCPDISCOVER avec des adresses MAC usurpees (spoofees) pour epuiser le pool d'adresses IP du serveur DHCP legitime.
- Resultat : plus aucune adresse disponible pour les clients legitimes (deni de service)
- Souvent combinee avec un rogue DHCP server : apres l'epuisement, l'attaquant met en place son propre serveur qui repond a toutes les requetes
- Outil d'attaque courant : Yersinia, Gobbler
Le DHCP Snooping est une fonctionnalite de securite des switches qui protege contre les attaques DHCP :
- Ports trusted (de confiance) : seuls les ports connectes aux serveurs DHCP legitimes sont marques comme "trusted" et peuvent envoyer des DHCPOFFER et DHCPACK
- Ports untrusted : tous les autres ports. Les messages DHCP serveur (Offer, ACK) sont bloques sur ces ports
- DHCP Snooping Binding Table : le switch maintient une table associant les adresses MAC aux adresses IP attribuees. Cette table est utilisee par d'autres mecanismes de securite (Dynamic ARP Inspection, IP Source Guard)
- Rate limiting : limite le nombre de requetes DHCP par port pour prevenir le starvation
🌍 9.3 — HTTP / HTTPS
HTTP (HyperText Transfer Protocol) est le protocole fondamental du Web. Il définit comment les navigateurs et les serveurs web communiquent. HTTPS en est la version sécurisée, chiffrée via TLS.
HTTP, c'est comme envoyer une carte postale : tout le monde peut lire le contenu en transit. HTTPS, c'est comme envoyer une lettre dans une enveloppe scellée : seul le destinataire peut lire le contenu.
Méthodes HTTP
| Méthode | Action | Description | Idempotent ? |
|---|---|---|---|
| GET | Lire | Récupère une ressource (page, image, API) | Oui |
| POST | Créer | Envoie des données au serveur (formulaire, upload) | Non |
| PUT | Remplacer | Remplace entièrement une ressource existante | Oui |
| PATCH | Modifier | Modifie partiellement une ressource | Non |
| DELETE | Supprimer | Supprime une ressource | Oui |
| HEAD | Métadonnées | Comme GET mais sans le corps de la réponse | Oui |
| OPTIONS | Capacités | Liste les méthodes supportées par le serveur | Oui |
Codes de réponse HTTP
2xx — Succès
- 200 OK : requête réussie, réponse renvoyée
- 201 Created : ressource créée avec succès (après un POST)
- 204 No Content : succès, mais pas de contenu à renvoyer
3xx — Redirection
- 301 Moved Permanently : la ressource a été déplacée définitivement
- 302 Found : redirection temporaire
- 304 Not Modified : utilise la version en cache
4xx — Erreur client
- 400 Bad Request : requête mal formée
- 401 Unauthorized : authentification requise
- 403 Forbidden : accès interdit (même avec authentification)
- 404 Not Found : ressource introuvable
- 405 Method Not Allowed : méthode HTTP non supportée
5xx — Erreur serveur
- 500 Internal Server Error : erreur générique du serveur
- 502 Bad Gateway : le serveur intermédiaire a reçu une réponse invalide
- 503 Service Unavailable : serveur surchargé ou en maintenance
- 504 Gateway Timeout : le serveur intermédiaire n'a pas reçu de réponse à temps
HTTPS et TLS Handshake
HTTPS = HTTP + TLS (Transport Layer Security, successeur de SSL). Le processus de connexion securisee se fait via le TLS Handshake, qui differe selon la version :
TLS 1.2 Handshake — 2 allers-retours (2-RTT)
- ClientHello : le navigateur envoie les versions TLS supportees, la liste des cipher suites (algorithmes de chiffrement), un nombre aleatoire (Client Random) et des extensions
- ServerHello : le serveur choisit la version TLS, la cipher suite, et envoie son nombre aleatoire (Server Random)
- Certificate : le serveur envoie son certificat numerique (contenant sa cle publique, signe par une CA)
- ServerKeyExchange : le serveur envoie les parametres pour l'echange de cles (si Diffie-Hellman). Optionnel avec RSA.
- ServerHelloDone : le serveur a fini sa partie
- ClientKeyExchange : le client genere le Pre-Master Secret, le chiffre avec la cle publique du serveur et l'envoie
- ChangeCipherSpec (client) : "A partir de maintenant, tout sera chiffre"
- Finished (client) : premier message chiffre, verifie l'integrite du handshake
- ChangeCipherSpec (serveur) + Finished (serveur) : confirmation
Les deux parties derivent la cle de session symetrique (Master Secret) a partir du Pre-Master Secret + Client Random + Server Random.
TLS 1.3 Handshake — 1 aller-retour (1-RTT)
TLS 1.3 (RFC 8446) est plus rapide et plus securise :
- ClientHello : le client envoie ses parametres ET ses cles publiques Diffie-Hellman (key shares) directement dans le premier message
- ServerHello + Certificate + CertificateVerify + Finished : le serveur repond avec tout en une seule fois. Le handshake est chiffre des ce message.
- Finished (client) : confirmation du client. Le transfert de donnees peut commencer.
Ameliorations de TLS 1.3 vs 1.2 :
- 1 RTT au lieu de 2 (voir 0-RTT pour les reconnexions)
- Suppression des cipher suites obsoletes (RC4, DES, 3DES, MD5, SHA-1, RSA key exchange)
- Forward Secrecy obligatoire : uniquement Diffie-Hellman ephemere (DHE/ECDHE), pas de RSA key exchange
- Handshake chiffre des le ServerHello (seuls ClientHello et ServerHello sont en clair)
- 0-RTT (Early Data) : permet d'envoyer des donnees des le premier message lors d'une reconnexion (risque de replay attack)
Headers HTTP importants pour la cybersecurite
| Header | Direction | Role | Interet securite |
|---|---|---|---|
Host | Requete | Nom de domaine du serveur cible (obligatoire en HTTP/1.1) | Virtual hosting — un serveur peut heberger plusieurs sites |
User-Agent | Requete | Identifie le navigateur/client (type, version, OS) | Detection de bots, fingerprinting, identification de malware C2 |
Content-Type | Les deux | Type MIME des donnees (text/html, application/json, multipart/form-data) | Prevention des attaques MIME-type confusion |
Authorization | Requete | Identifiants d'authentification (Bearer token, Basic base64) | Si intercepte en HTTP (port 80), les credentials sont compromis |
Set-Cookie | Reponse | Definit un cookie sur le navigateur (session, preferences) | Flags importants : Secure, HttpOnly, SameSite |
X-Forwarded-For | Requete | IP originale du client (ajoutee par les proxies/load balancers) | Peut etre usurpe (spoofed) — ne jamais s'y fier seul pour l'authentification |
Referer | Requete | URL de la page d'ou vient la requete | Fuite d'information, peut reveler des URLs sensibles |
Server | Reponse | Identifie le logiciel serveur (Apache, Nginx, IIS) | Information disclosure — facilite le ciblage d'exploits |
Strict-Transport-Security | Reponse | Force le navigateur a n'utiliser que HTTPS (HSTS) | Protege contre le downgrade HTTP et le SSL stripping |
X-Content-Type-Options | Reponse | Valeur nosniff — empeche le MIME-type sniffing | Protege contre l'execution de scripts deguises en images/CSS |
📧 9.4 — Services Email (SMTP, POP3, IMAP)
L'email repose sur plusieurs protocoles qui travaillent ensemble pour envoyer, transmettre et recevoir des messages.
L'email fonctionne comme le courrier postal : SMTP est le facteur qui collecte et livre le courrier entre les bureaux de poste. POP3 est le fait d'aller chercher ton courrier et de le ramener chez toi (il disparaît de la boîte). IMAP, c'est comme avoir une boîte postale au bureau de poste où tu peux consulter ton courrier sans le prendre.
Les 3 protocoles email
SMTP — Simple Mail Transfer Protocol
Rôle : Envoyer et transmettre les emails entre serveurs.
- Port 25 : communication entre serveurs de messagerie (relay)
- Port 587 : soumission d'email depuis un client (avec authentification)
- Port 465 : SMTPS (SMTP over SSL/TLS, obsolète mais encore utilisé)
SMTP ne gère que l'envoi. Pour recevoir, il faut POP3 ou IMAP.
POP3 — Post Office Protocol v3
Rôle : Télécharger les emails du serveur vers le client.
- Port 110 : POP3 non chiffré
- Port 995 : POP3S (POP3 over SSL/TLS)
Par défaut, POP3 télécharge et supprime les emails du serveur. Les messages ne sont accessibles que depuis l'appareil qui les a téléchargés.
Adapté pour : un seul appareil, connexion lente, espace serveur limité.
IMAP — Internet Message Access Protocol
Rôle : Consulter les emails en les laissant sur le serveur.
- Port 143 : IMAP non chiffré
- Port 993 : IMAPS (IMAP over SSL/TLS)
IMAP synchronise les emails entre le serveur et le client. Les messages restent sur le serveur et sont accessibles depuis plusieurs appareils.
Adapté pour : accès multi-appareils, gestion de dossiers sur le serveur.
Processus d'envoi et réception d'un email
📂 9.5 — FTP, TFTP et alternatives sécurisées
FTP (File Transfer Protocol) est le protocole classique de transfert de fichiers sur le réseau. Il utilise deux connexions : une de contrôle (port 21) et une de données (port 20 ou dynamique).
Mode actif vs mode passif
FTP Active Mode
- Le client se connecte au serveur sur le port 21 (contrôle)
- Le client indique au serveur sur quel port il écoute pour les données
- Le serveur initie la connexion de données depuis le port 20 vers le port du client
Problème : le serveur initie une connexion entrante vers le client. Les firewalls côté client bloquent souvent cette connexion entrante.
FTP Passive Mode
- Le client se connecte au serveur sur le port 21 (contrôle)
- Le client envoie la commande
PASV - Le serveur ouvre un port aléatoire (>1023) et communique ce port au client
- Le client initie la connexion de données vers le port indiqué
Avantage : toutes les connexions sont initiées par le client → compatible avec les firewalls et NAT.
Commandes FTP courantes
| Commande | Description |
|---|---|
USER / PASS | Authentification (login/mot de passe) |
LIST | Lister les fichiers du répertoire courant |
RETR | Télécharger (retrieve) un fichier |
STOR | Envoyer (store) un fichier sur le serveur |
CWD | Changer de répertoire (change working directory) |
QUIT | Fermer la connexion |
PASV | Activer le mode passif |
TFTP — Trivial File Transfer Protocol
Version simplifiée de FTP : pas d'authentification, pas de listing de répertoires, utilise UDP (port 69). Utilisé principalement pour :
- Le démarrage réseau (PXE boot)
- Le transfert de fichiers de configuration sur des équipements réseau (routeurs, switches)
- La mise à jour de firmware
Alternatives sécurisées
| Protocole | Port | Sécurité | Description |
|---|---|---|---|
| SFTP | 22 | SSH | FTP over SSH — transfert chiffré via un tunnel SSH |
| SCP | 22 | SSH | Secure Copy — copie sécurisée de fichiers via SSH |
| FTPS | 990 | TLS/SSL | FTP over SSL/TLS — FTP avec chiffrement TLS |
🔧 9.6 — Services réseau de support (NTP, Syslog, SNMP)
Ces services ne transportent pas de données utilisateur, mais sont essentiels au bon fonctionnement et à la surveillance du réseau.
Role : Synchroniser les horloges de tous les equipements reseau. Utilise UDP port 123. Precision typique : quelques millisecondes sur un LAN, dizaines de millisecondes sur Internet.
Hierarchie des strates (Stratum Levels) :
| Stratum | Description | Exemple |
|---|---|---|
| 0 | Sources de reference (horloge atomique, GPS, radio). Ce ne sont pas des serveurs NTP mais des horloges de reference connectees directement aux serveurs stratum 1 | Horloge atomique au cesium, recepteur GPS |
| 1 | Serveurs connectes directement a une source stratum 0. Ce sont les serveurs de temps primaires | time.nist.gov, pool.ntp.org serveurs primaires |
| 2 | Serveurs synchronises avec des serveurs stratum 1. Servent de reference pour les reseaux d'entreprise | Serveurs NTP d'entreprise, FAI |
| 3-15 | Chaque niveau est synchronise avec le niveau precedent. La precision diminue a chaque saut | Equipements reseau (routeurs, switches, PCs) |
| 16 | Non synchronise — l'horloge est consideree comme invalide | Equipement deconnecte du reseau NTP |
Pourquoi NTP est critique en cybersecurite :
- Les logs doivent avoir des horodatages coherents pour la correlation d'evenements dans un SIEM
- Les certificats TLS ont des dates de validite — une horloge decalee peut invalider des certificats
- L'authentification Kerberos tolere un decalage de seulement 5 minutes
- Les investigations forensiques necessitent une chronologie precise entre tous les equipements
- TOTP (mots de passe a usage unique bases sur le temps) depend d'une horloge precise
Attaque NTP : l'NTP amplification est une attaque DDoS qui exploite la commande monlist pour amplifier le trafic (reponse beaucoup plus grande que la requete). Desactiver monlist et utiliser NTPv4 avec authentification.
Role : Centraliser les logs (journaux) de tous les equipements reseau vers un serveur Syslog unique. Ports : UDP 514 (traditionnel), TCP 514 (fiable), TCP 6514 (Syslog over TLS, securise).
8 niveaux de severite Syslog (0-7) :
| Niveau | Mot-cle | Description | Mnemotechnique |
|---|---|---|---|
| 0 | Emergency | Systeme inutilisable | Every Alley Cat Eats Wild Nuts In December (0 = le plus critique, 7 = le moins critique) |
| 1 | Alert | Action immediate requise | |
| 2 | Critical | Conditions critiques (ex: panne hardware) | |
| 3 | Error | Conditions d'erreur (ex: erreur d'interface) | |
| 4 | Warning | Avertissements (ex: seuil de memoire atteint) | |
| 5 | Notice | Evenements normaux mais significatifs (ex: changement d'etat d'interface) | |
| 6 | Informational | Messages informatifs (ex: transaction completee) | |
| 7 | Debug | Messages de debogage (tres verbeux, pour le troubleshooting) |
Facilities Syslog (source du message) :
Chaque message syslog a une facility qui identifie la source : kern (0 - noyau), user (1), mail (2), daemon (3), auth (4), syslog (5), lpr (6), news (7), local0-local7 (16-23, usage personnalise). La priorite = facility x 8 + severite.
Format d'un message Syslog (RFC 5424) :
Dans cet exemple : priorite 134 = facility 16 (local0) x 8 + severite 6 (informational).
En cybersecurite : les logs centralises sont essentiels pour :
- Detection d'intrusions : le SIEM (Security Information and Event Management) analyse les logs centralises
- Investigation forensique : reconstitution de la chronologie d'un incident
- Conformite reglementaire : conservation des logs (PCI-DSS, HIPAA, RGPD)
- Correlation d'evenements : relier des evenements de sources differentes (firewall, IDS, serveurs, etc.)
Rôle : Surveiller et gérer les équipements réseau à distance. Utilise UDP ports 161 (requêtes) et 162 (traps/notifications).
Composants :
- SNMP Manager : station de gestion qui interroge les agents
- SNMP Agent : logiciel sur l'équipement surveillé
- MIB (Management Information Base) : base de données des variables surveillables (CPU, mémoire, bande passante, etc.)
Versions :
| Version | Authentification | Chiffrement | Recommandation |
|---|---|---|---|
| SNMPv1 | Community string (texte clair) | Non | Obsolète, ne pas utiliser |
| SNMPv2c | Community string (texte clair) | Non | Encore courant mais peu sûr |
| SNMPv3 | Username + mot de passe hashé | Oui (DES/AES) | Recommandé |
public pour lecture, private pour écriture) sont un risque de sécurité majeur. Toujours les changer !
🔬 9.7 — Lab : Interroger le DNS
Utilise le terminal simulé ci-dessous pour pratiquer les commandes nslookup et dig. Essaie de retrouver les adresses IP et les enregistrements DNS de différents domaines.
nslookup [domaine]— résolution DNS simplenslookup -type=[A|MX|NS|TXT|AAAA] [domaine]— requête par type d'enregistrementdig [domaine]— requête DNS détailléedig [domaine] [type]— requête DNS par type (A, MX, NS, TXT, AAAA)help— afficher les commandes disponiblesclear— effacer le terminal
📝 9.8 — Quiz de révision
Points cles du Module 9
- DNS : hierarchie Root (13 serveurs A-M) → TLD (gTLD, ccTLD) → SLD → Subdomain. FQDN = nom complet termine par un point. Message DNS = Header + Question + Answer + Authority + Additional
- Enregistrements DNS : A (IPv4), AAAA (IPv6), MX (mail + priority), CNAME (alias), NS (serveur de noms), PTR (reverse), TXT (SPF/DKIM), SOA (autorite de zone), SRV (localisation de service)
- DNS : resolution recursive (client→resolver) vs iterative (resolver→serveurs). DNS caching avec TTL a chaque niveau. Securite : DNSSEC (signatures), DoH (port 443), DoT (port 853), detection du DNS tunneling
- DHCP (UDP 67/68) : processus DORA — Discover (broadcast) → Offer (unicast/broadcast) → Request (broadcast) → Acknowledge (unicast/broadcast). Bail : renewal a 50% (T1, unicast), rebinding a 87.5% (T2, broadcast), expiration a 100%
- Attaques DHCP : Rogue server (MitM), Starvation (epuisement du pool). Defense : DHCP Snooping (ports trusted/untrusted, binding table, rate limiting)
- HTTP (port 80) : methodes GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Codes : 2xx succes, 3xx redirect, 4xx client error, 5xx server error. Headers critiques : Host, User-Agent, Authorization, Set-Cookie, X-Forwarded-For
- HTTPS (port 443) = HTTP + TLS. TLS 1.2 = 2-RTT (ClientHello → ServerHello → Certificate → KeyExchange → Finished). TLS 1.3 = 1-RTT, forward secrecy obligatoire, cipher suites obsoletes supprimees
- Email : SMTP (envoi, ports 25/587/465), POP3 (telecharge + supprime, 110/995), IMAP (synchronise, 143/993). POP3 = 1 appareil, IMAP = multi-appareils
- NTP (UDP 123) : stratum 0 (horloge atomique) → 1 → 2 → ... → 15 (16 = non synchronise). Critique pour logs, certificats, Kerberos
- Syslog (UDP 514) : 8 niveaux de severite (0-Emergency a 7-Debug), facilities (kern, auth, local0-7...), format RFC 5424. Priorite = facility x 8 + severite
- SNMP (UDP 161/162) : toujours utiliser SNMPv3 (chiffre) et changer les community strings par defaut