Chapitre 1.1 - Architecture reseau et surfaces d'attaque
Module 1 : Fondamentaux et paysage des menaces Niveau : Intermediaire a Avance | Temps de lecture estime : 45-60 min
Table des matieres
- Les modeles OSI et TCP/IP - Un prisme securite
- Topologie reseau et schemas d'architecture
- Decomposition de la surface d'attaque
- Protocoles et leurs faiblesses inherentes
- Cartographie de la surface d'attaque avec des outils
- Diagramme d'architecture
1. Les modeles OSI et TCP/IP - Un prisme securite
La plupart des ingenieurs apprennent le modele OSI comme une abstraction academique. En securite, il devient un vocabulaire precis pour localiser ou se produit une attaque, ce qu'elle affecte, et quels controles peuvent l'attenuer.
Couches OSI avec les classes d'attaques
| Couche | Nom | Exemples de protocoles | Classes d'attaques principales |
|---|---|---|---|
| 7 | Application | HTTP, DNS, SMTP, FTP | SQLi, XSS, injection de commandes, abus de protocole |
| 6 | Presentation | TLS, SSL, MIME | Suppression SSL, usurpation de certificat, attaques d'encodage |
| 5 | Session | NetBIOS, RPC, SMB | Detournement de session, attaques par rejeu |
| 4 | Transport | TCP, UDP, SCTP | SYN flood, scan de ports, detournement de session TCP |
| 3 | Reseau | IP, ICMP, OSPF, BGP | Usurpation IP, tunneling ICMP, detournement BGP, injection de route |
| 2 | Liaison de donnees | Ethernet, ARP, 802.1Q | Usurpation ARP, inondation MAC, saut de VLAN |
| 1 | Physique | Cuivre, Fibre, Radio | Attaques par derivation, brouillage, implants materiels |
Correspondance TCP/IP vs. OSI
Le modele TCP/IP (ce sur quoi internet fonctionne reellement) condense le modele OSI a 7 couches en 4 couches. Les deux modeles sont utiles - TCP/IP pour l'implementation, OSI pour l'attribution precise des attaques.
Modele OSI Modele TCP/IP
────────────────────── ──────────────────────
7. Application ┐
6. Presentation ├──────→ 4. Application
5. Session ┘
────────────────────── ──────────────────────
4. Transport ──────→ 3. Transport (TCP/UDP)
────────────────────── ──────────────────────
3. Reseau ──────→ 2. Internet (IP)
────────────────────── ──────────────────────
2. Liaison ┐
1. Physique ├──────→ 1. Acces reseau
┘
Pourquoi cela compte pour l'offense et la defense : Un paquet traverse toutes les couches a l'entree et toutes les couches a la sortie. Un attaquant a la Couche 2 (usurpation ARP) peut intercepter le trafic destine a la Couche 7 (HTTPS) - le chiffrement n'aide pas si le routage est compromis.
2. Topologie reseau et schemas d'architecture
2.1 Architecture perimetre classique (heritee)
Le modele original de securite reseau suppose une coquille dure et un interieur souple - "faire confiance a tout ce qui est a l'interieur du pare-feu." Ce modele est considere comme inadapte aux environnements modernes mais reste largement deploye et toujours exploite.
Internet
│
[Pare-feu]
│
[DMZ : Serveurs web, Relai de messagerie, DNS]
│
[Pare-feu interne]
│
[LAN d'entreprise]
├── Postes de travail
├── Serveurs de fichiers
└── Controleurs de domaine
Faille fondamentale : Une fois qu'un attaquant a franchi le perimetre (hameconnage, vol d'identifiants VPN, chaine d'approvisionnement), il dispose d'une liberte de mouvement lateral quasi illimitee sur un reseau plat.
2.2 Architecture segmentee / Defense en profondeur
Les reseaux modernes durcis utilisent la segmentation pour contenir les mouvements lateraux. Chaque zone a des limites de confiance explicites.
| Zone | Contenu | Niveau de confiance | Controles |
|---|---|---|---|
| DMZ exposee sur internet | Serveurs web, proxys inverses, WAF | Non fiable | Filtrage strict entree/sortie |
| Niveau applicatif | Serveurs d'applications, APIs | Semi-fiable | Micro-segmentation est-ouest |
| Niveau donnees | Bases de donnees, stockages de fichiers | Restreint | Connexions sur liste blanche uniquement |
| Plan de gestion | Hotes bastion, IPAM, surveillance | Privilegie | AMF, serveurs de saut, PAM |
| Zone OT/ICS | SCADA, automates, capteurs | Isole | Separation physique ou passerelle unidirectionnelle |
| LAN utilisateurs | Postes de travail | Faible confiance | NAC, EDR, isolation VLAN |
2.3 Architecture cloud-native
Dans les environnements IaaS/PaaS, la surface d'attaque change fondamentalement :
- Pas de perimetre physique - le plan de controle est une API
- L'identite devient le nouveau perimetre - les roles IAM trop permissifs sont aussi dangereux que des ports de pare-feu ouverts
- Infrastructure ephemere - les actifs apparaissent et disparaissent ; l'inventaire traditionnel des actifs echoue
- Modele de responsabilite partagee - le fournisseur cloud securise l'infrastructure, vous securisez tout ce qui est dessus
Vecteurs d'attaque uniques au cloud :
- Abus du service de metadonnees (SSRF ->
http://169.254.169.254/latest/meta-data/iam/security-credentials/) - Compartiments S3 / Azure Blob / objets GCS exposes publiquement
- Roles IAM trop permissifs attaches a des instances de calcul
- Registres de conteneurs non securises
- Serveur API Kubernetes expose (port 6443)
3. Decomposition de la surface d'attaque
Une surface d'attaque est la totalite des points differents (vecteurs d'attaque) ou un utilisateur non autorise peut essayer d'entrer dans un environnement ou d'en extraire des donnees.
3.1 Les trois categories de surface
Surface d'attaque reseau Tout ce qui est accessible sur un reseau : ports ouverts, services exposes, infrastructure de routage, points d'acces sans fil, points de terminaison VPN, APIs cloud.
Surface d'attaque logicielle Tout logiciel qui traite des entrees externes : applications web, APIs, middleware, pilotes, services OS, firmware, bibliotheques.
Surface d'attaque humaine Personnes et processus : cibles d'hameconnage, cibles de vishing, menaces internes, controles d'acces mal configures accordes aux humains.
3.2 Methodologie d'enumeration de la surface d'attaque
Phase 1 : Reconnaissance passive
└── OSINT : WHOIS, Shodan, Censys, journaux de transparence des certificats
└── Enumeration DNS : sous-domaines, MX, SPF, DMARC, enregistrements DKIM
└── Offres d'emploi (revelent la pile technologique), fuites GitHub, LinkedIn
Phase 2 : Scan actif
└── Decouverte d'hotes : ICMP, ARP, sondes TCP/UDP
└── Scan de ports : SYN TCP, UDP, fingerprinting de services
└── Detection OS : analyse TTL, fingerprinting de pile TCP
Phase 3 : Enumeration de services
└── Recuperation de bannieres : infos de version, mauvaises configurations
└── Exploration web : points de terminaison, parametres, formulaires
└── Decouverte d'authentification : portails de connexion, cles API dans le JS
Phase 4 : Cartographie des vulnerabilites
└── Correlation CVE par rapport aux versions decouvertes
└── Identification des faiblesses de configuration
└── Cartographie des relations de confiance (AD, IAM cloud, routes reseau)
3.3 Metriques de surface d'attaque
| Metrique | Description | Pourquoi c'est important |
|---|---|---|
| Surface d'attaque totale | Nombre de services exposes x sensibilite | Plus grande = plus d'opportunites pour les attaquants |
| Reduction de surface | Services desactives vs. total disponible | Principe de moindre exposition |
| Fenetre d'exposition | Temps pendant lequel un service vulnerable est accessible | La velocite de correction compte |
| Profondeur d'accessibilite | Sauts depuis internet jusqu'a l'actif sensible | Moins de sauts = risque plus eleve |
4. Protocoles et leurs faiblesses inherentes
De nombreux protocoles internet fondamentaux ont ete concus a une epoque ou les participants au reseau etaient de confiance. Leurs faiblesses sont architecturales, pas des bugs d'implementation - elles ne peuvent pas etre "corrigees", seulement attenuees en superposant des controles dessus.
4.1 ARP - Protocole de resolution d'adresse
Objectif : Resout les adresses IP en adresses MAC sur un segment de reseau local.
Faiblesse : ARP est sans etat et non authentifie. N'importe quel hote peut diffuser une reponse ARP non sollicitee affirmant posseder n'importe quelle adresse IP. Il n'existe aucun mecanisme de verification.
Attaque : Usurpation ARP / Empoisonnement ARP
Flux normal :
Hote A (10.0.0.10) -> "Qui a 10.0.0.1 ?" -> La passerelle repond avec son MAC
Flux empoisonne :
L'attaquant envoie une reponse ARP non sollicitee : "10.0.0.1 est a AA:BB:CC:DD:EE:FF"
L'hote A met a jour son cache ARP -> tout le trafic vers la passerelle passe maintenant par l'attaquant
# L'attaquant utilise arpspoof (suite dsniff) pour empoisonner le cache ARP
# Activer le transfert IP d'abord pour eviter de supprimer le trafic de la victime
echo 1 > /proc/sys/net/ipv4/ip_forward
# Empoisonner la victime (10.0.0.10) pour qu'elle croie que l'attaquant est la passerelle (10.0.0.1)
arpspoof -i eth0 -t 10.0.0.10 10.0.0.1
# Dans un second terminal : empoisonner la passerelle pour qu'elle croie que l'attaquant est la victime
arpspoof -i eth0 -t 10.0.0.1 10.0.0.10
Attenuations :
- Inspection ARP dynamique (DAI) sur les commutateurs geres - valide les paquets ARP par rapport a une table de liaisons DHCP snooping
- Entrees ARP statiques pour les hotes critiques
- Authentification par port 802.1X
- Les canaux chiffres (TLS) reduisent l'impact meme lorsqu'un MITM est etabli
4.2 DNS - Systeme de noms de domaine
Objectif : Resout les noms d'hotes en adresses IP en utilisant un systeme hierarchique distribue.
Faiblesse : Le DNS classique (port 53 UDP) n'a pas d'authentification. Les reponses peuvent etre usurpees, mises en cache ou interceptees. Le trafic DNS est egalement en texte clair - chaque recherche de domaine fuit des informations.
| Attaque | Mecanisme | Impact |
|---|---|---|
| Empoisonnement du cache DNS | Injecter des enregistrements A forges dans le cache du resolveur | Rediriger les utilisateurs vers une IP controlee par l'attaquant |
| Detournement DNS | Modifier les parametres DNS sur le routeur ou l'hote | Redirection complete du trafic |
| Tunneling DNS | Encoder le trafic C2 dans les requetes/reponses DNS | Canal covert contournant les pare-feux |
| Attaque NXDOMAIN | Inonder le resolveur de requetes de domaines inexistants | DoS sur le resolveur |
| Transfert de zone DNS | La requete AXFR revele toutes les donnees de zone | Reconnaissance reseau |
# Verifier si un serveur DNS autorise les transferts de zone (mauvaise configuration)
dig axfr @ns1.target.com target.com
# Interroger tous les types d'enregistrements DNS (reconnaissance)
dig any target.com +noall +answer
# Verifier le deploiement DNSSEC
dig +dnssec target.com A
# Detecter le trafic de tunneling DNS (rechercher des sous-domaines anormalement longs)
# Normal : www.google.com (15 caracteres)
# Tunnel : aGVsbG8gd29ybGQ.c2VjcmV0.attacker.com (payload encode)
Attenuations :
- DNSSEC - signe cryptographiquement les enregistrements DNS (previent l'empoisonnement du cache)
- DNS over HTTPS (DoH) ou DNS over TLS (DoT) - chiffre les requetes
- Limitation du taux de reponse (RRL) - limite les taux de requetes suspects
- Bloquer les transferts de zone sauf vers les serveurs de noms secondaires autorises
4.3 ICMP - Protocole de messages de controle internet
Objectif : Protocole de diagnostic et de signalement d'erreurs. Ping (type 8/0), traceroute, messages d'inatteignabilite.
Faiblesse : ICMP est souvent trop permis car "le ping doit fonctionner." Les attaquants l'exploitent pour la reconnaissance et les canaux couverts.
| Type ICMP | Nom | Abus |
|---|---|---|
| 0 / 8 | Echo Reply / Request | Decouverte d'hotes, fingerprinting OS via TTL |
| 3 | Destination inatteignable | Cartographie reseau - revele quels hotes/ports sont filtres |
| 11 | Temps depasse | Traceroute - cartographie la topologie reseau |
| 5 | Redirection | Attaque de redirection ICMP - modifier les tables de routage |
# Balayage ping avec fping (beaucoup plus rapide que le ping sequentiel)
fping -a -g 10.0.0.0/24 2>/dev/null
# Fingerprinting OS via TTL dans la reponse ping
# Linux : TTL=64, Windows : TTL=128, Cisco IOS : TTL=255
ping -c1 10.0.0.1 | grep ttl
# Detection du tunneling ICMP : rechercher les grands payloads ICMP
# Ping normal : 32-56 octets
# En tunnel : le champ data ICMP contient du trafic encode, souvent 1000+ octets
tcpdump -i eth0 'icmp and greater 100' -nn
# Bloquer les attaques de redirection ICMP (Linux)
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
4.4 TCP - La poignee de main en trois voies et ses faiblesses
La poignee de main TCP cree un etat sur le serveur avant que le client prouve sa legitimite - c'est par conception et c'est la cause profonde des attaques SYN flood.
Poignee de main TCP normale :
Client ---- SYN -----> Serveur (Le serveur alloue une entree de connexion semi-ouverte)
Client <-- SYN-ACK -- Serveur
Client ---- ACK -----> Serveur (Connexion etablie, etat promu)
Attaque SYN Flood :
Attaquant -- SYN (IP src usurpee) --> Serveur (Le serveur alloue une entree, attend)
Attaquant -- SYN (IP src usurpee) --> Serveur (Une autre entree allouee)
Attaquant -- SYN (IP src usurpee) --> Serveur (Le backlog se remplit...)
[SYN-ACK va vers l'IP usurpee, ne recoit jamais de ACK]
[Backlog du serveur epuise - connexions legitimes refusees]
# Simuler un SYN flood (environnement de test uniquement - necessite root)
hping3 -S --flood -V -p 80 10.0.0.1
# Detecter un SYN flood : surveiller les connexions semi-ouvertes massives
ss -ant | grep SYN_RECV | wc -l
# Seuil : >500 entrees SYN_RECV indique generalement une inondation
# Attenuer : activer les SYN cookies (Linux) - le serveur n'alloue pas d'etat jusqu'a reception du ACK
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Verifier le parametre SYN cookie actuel
sysctl net.ipv4.tcp_syncookies
5. Cartographie de la surface d'attaque avec des outils
5.1 Nmap - Le scanner de reference
Nmap est la norme pour la reconnaissance reseau. Comprendre ses types de scans est essentiel pour l'offense (savoir ce que l'on peut trouver) et la defense (savoir ce que les attaquants voient).
# Decouverte d'hotes uniquement - pas de scan de ports (rapide, discret)
nmap -sn 192.168.1.0/24
# Scan SYN (scan furtif) - ne complete pas la poignee de main TCP, moins susceptible d'etre journalise
# Necessite root/admin
sudo nmap -sS -p 1-65535 10.0.0.1
# Detection de version de service + detection OS + scripts par defaut
sudo nmap -sV -O -sC 10.0.0.1
# Scan agressif (combine -O -sV -sC --traceroute) - tres bruyant
nmap -A 10.0.0.1
# Scan UDP - lent mais critique ; de nombreux services fonctionnent sur UDP (DNS 53, SNMP 161, TFTP 69)
sudo nmap -sU --top-ports 100 10.0.0.1
# Sortie de scan dans tous les formats (normal, XML, grepp-able)
nmap -sV 10.0.0.0/24 -oA resultats_scan
# Evasion de pare-feu : fragmenter les paquets (contourner les filtres de paquets simples)
nmap -f 10.0.0.1
# Usurper l'IP source (necessite d'etre sur le chemin pour recevoir les reponses)
nmap -S ip_usurpee -e eth0 10.0.0.1
# Scan de scripts : executer un script NSE specifique
nmap --script=vuln 10.0.0.1
nmap --script=smb-vuln-ms17-010 10.0.0.1 # Verification EternalBlue
5.2 Masscan - Scan a l'echelle internet
Masscan est concu pour la vitesse - il peut scanner l'integralite d'IPv4 en moins de 6 minutes. Utile pour les grandes plages internes ou pour comprendre l'exposition globale.
# Scanner toute la plage /16 pour le port 443 a 10 000 paquets/seconde
masscan 10.0.0.0/16 -p443 --rate=10000
# Scanner les ports courants sur une plage
masscan 10.0.0.0/8 -p22,80,443,8080,8443 --rate=50000 -oL resultats.txt
# Exclure des plages specifiques du scan
masscan 10.0.0.0/8 -p80 --excludefile exclusions.txt
5.3 Netcat et recuperation de bannieres
La recuperation de bannieres consiste a se connecter a un service et a lire ce qu'il renvoie. Les bannieres revelent souvent le nom du logiciel, la version et l'OS - tous utiles pour la correlation CVE.
# Recuperation manuelle de banniere via netcat
nc -nv 10.0.0.1 22 # Banniere SSH
nc -nv 10.0.0.1 25 # Banniere SMTP
nc -nv 10.0.0.1 80 # HTTP (envoyer la requete manuellement)
# Recuperation de banniere HTTP
echo -e "HEAD / HTTP/1.0\r\n\r\n" | nc 10.0.0.1 80
# Utiliser curl pour obtenir les en-tetes du serveur
curl -I http://10.0.0.1
# Recuperer la banniere FTP
nc -nv 10.0.0.1 21
# Supprimer la banniere (certains services) : utiliser l'option -n dans netcat pour desactiver le DNS, reduisant la detection
5.4 Tableau recapitulatif de la surface d'attaque - Services exposes courants
| Port | Service | Vulnerabilites courantes | Action recommandee |
|---|---|---|---|
| 21 | FTP | Identifiants en texte clair, connexion anonyme | Desactiver ; remplacer par SFTP |
| 22 | SSH | Identifiants faibles, versions obsoletes (CVE-2023-38408) | Auth par cle uniquement, restreindre les IPs sources |
| 23 | Telnet | Texte clair - jamais acceptable | Desactiver immediatement |
| 25 | SMTP | Relai ouvert, enumeration d'utilisateurs, degradation STARTTLS | Soumission authentifiee uniquement |
| 53 | DNS | Transfert de zone, empoisonnement du cache, tunneling | Restreindre AXFR, activer DNSSEC |
| 80 | HTTP | Vulnerabilites des applications web, texte clair | Rediriger vers HTTPS, WAF |
| 161 | SNMP | Chaines de communaute par defaut (public/private) | Desactiver v1/v2c ; utiliser SNMPv3 |
| 389 | LDAP | Liaison nulle, exposition des identifiants, injection LDAP | Exiger l'auth, utiliser LDAPS (636) |
| 443 | HTTPS | Problemes de configuration TLS, validation de cert | Imposer TLS 1.2+, HSTS |
| 445 | SMB | EternalBlue (MS17-010), attaques par relai | Desactiver SMBv1, pare-feu externe |
| 3389 | RDP | BlueKeep (CVE-2019-0708), attaques par identifiants | AMF, NLA, restreindre au VPN |
| 5432 | PostgreSQL | Identifiants par defaut, execution de code a distance | Lier a localhost, pare-feu |
| 6443 | API K8s | Acces non authentifie, mauvaise configuration RBAC | Exiger l'auth, reseau prive |
| 8080 | HTTP Alt | Identique a 80, souvent staging/dev expose | Ne jamais exposer les serveurs de dev publiquement |
6. Diagramme d'architecture
Le diagramme ci-dessous illustre une architecture reseau segmentee avec les vecteurs d'attaque annotes a chaque frontiere.
Annotations des vecteurs d'attaque
| # | Vecteur | Couche | Attenuation |
|---|---|---|---|
| 1 | Scan de ports / enumeration de services | L3-L4 | Regles pare-feu, port knocking, alerte IDS sur les patterns de scan |
| 2 | Usurpation ARP (initie / apres pivot) | L2 | DAI, 802.1X, canaux chiffres |
| 3 | Empoisonnement du cache DNS | L7 (App) | DNSSEC, DoT/DoH, DNS split-horizon |
| 4 | Relai ouvert SMTP / injection d'en-tete | L7 (App) | SMTP authentifie, SPF/DKIM/DMARC |
| 5 | Mouvement lateral via AD/Kerberos | L7 (App) | Segmentation reseau, PAM, defenses contre le Kerberoasting |