Questions d'entretien Networking

En grande partie non. Le nom d'hôte de destination est envoyé en clair dans l'extension SNI du ClientHello de TLS, et votre requête DNS le révèle généralement aussi, de sorte qu'un FAI ou un réseau peut voir QUEL site vous visitez même en HTTPS — il ne peut simplement pas lire le chemin ni le contenu. Le ClientHello chiffré (ECH) et le DNS-over-HTTPS peuvent combler cette faille, mais ils ne sont pas universels. « HTTPS cache tout » est l'idée fausse.

Non. Le mode privé/incognito empêche seulement le navigateur local d'enregistrer l'historique, les cookies et les données de formulaire après la session — il ne change rien au chemin réseau. Votre FAI, le proxy de votre employeur, le résolveur DNS et les sites où vous vous connectez voient encore votre activité. L'erreur est « incognito = invisible » ; en réalité c'est de la confidentialité face aux autres utilisateurs du même appareil, pas de l'anonymat face au réseau.

Non. Toute la plage 127.0.0.0/8 est réservée au bouclage, donc 127.0.0.2, 127.1.1.1, et ainsi de suite résolvent toutes vers l'hôte local. C'est crucial pour le SSRF et le contournement de listes d'autorisation — un attaquant peut utiliser 127.0.0.2 ou d'autres encodages pour esquiver un contrôle naïf « bloquer 127.0.0.1 » — et pour lier plusieurs services locaux. (En IPv6, le bouclage est l'unique adresse ::1.)

Non. Une MAC est attribuée par le fabricant (OUI plus identifiant de l'appareil) et « gravée », mais pratiquement chaque système d'exploitation permet de la remplacer en logiciel (macchanger, ip link set address). Les adresses MAC sont donc usurpables et ne doivent pas servir à l'authentification — le filtrage MAC est faible, et les téléphones randomisent désormais leur MAC par confidentialité. « Permanente et unique » est l'idée fausse.

Non. Le NAT (et le PAT) associe des adresses privées à une IP publique et, par effet de bord, rejette les connexions entrantes non sollicitées car aucune correspondance n'existe pour elles. Ce n'est pas une politique de sécurité — pas d'inspection, pas de règles, pas de journalisation — et la traversée de NAT, le hole punching et le C2 initié en sortie passent sans problème. Le NAT est un outil d'adressage ; il vous faut un vrai pare-feu. « NAT = pare-feu » est l'idée fausse.

Question piège : il n'existe pas de port unique pour traceroute. Le traceroute Unix classique envoie des datagrammes UDP vers des ports élevés et improbables à partir de 33434 environ, avec un TTL croissant ; le tracert de Windows utilise plutôt ICMP Echo. Il fonctionne en lisant les messages ICMP Time Exceeded que renvoient les routeurs à l'expiration du TTL, et non en visant un port réservé. Et ICMP lui-même n'a aucun port.

Non. Un VPN chiffre le trafic jusqu'au serveur VPN et masque votre IP à la destination, mais le fournisseur peut voir et journaliser votre activité, et les connexions, cookies et l'empreinte du navigateur vous identifient toujours. Cela déplace la confiance de votre réseau local/FAI vers l'opérateur du VPN — c'est de la confidentialité vis-à-vis du réseau local, pas de l'anonymat. Tor et une discipline opérationnelle stricte sont d'autres outils pour un autre objectif.

SSLv3, TLS 1.0 et RC4 sont cassés ou obsolètes et permettent des attaques par rétrogradation et déchiffrement ; désactivez-les donc et exigez TLS 1.2 ou 1.3 avec des suites de chiffrement robustes et à confidentialité persistante, en acceptant la rare perte de très vieux clients. Les laisser actifs par compatibilité maintient la faiblesse exploitable. Ajouter un second certificat ou passer à un certificat auto-signé ne supprime pas les protocoles faibles, et l'auto-signé nuit à la confiance sans corriger la cryptographie.

Le périmètre PCI DSS couvre les systèmes qui stockent, traitent ou transmettent les données de titulaires de cartes, plus tout système qui leur est connecté ou peut les affecter ; une segmentation réseau efficace isole donc l'environnement des données de cartes (CDE) et exclut du périmètre les systèmes sans rapport, réduisant coût, effort et risque. Chiffrer tous les serveurs ne définit aucune frontière et les systèmes connectés restent dans le périmètre ; ajouter des pare-feu partout sans cible n'est pas de la segmentation si cela ne restreint ni ne valide les flux de données ; et cesser de lire les numéros de carte à voix haute relève de l'hygiène, pas d'un contrôle de périmètre. La réponse systémique est de maîtriser où vivent les données de cartes et ce qui peut les atteindre.

Utilisez des services réseau simulés ou un egress étroitement surveillé et non attribuable, pour étudier le comportement du C2 sans révéler votre vraie IP à l'attaquant ni laisser l'hôte recevoir des commandes nuisibles. Interagir depuis l'IP de l'entreprise alerte l'opérateur et risque un vrai dommage. Ponter le sandbox au LAN invite à la propagation. Désactiver les logs jette les données d'analyse. Contrôlez le réseau pour observer sans exposer ni être instrumentalisé.

Comme les pare-feu évaluent les règles de haut en bas, une large règle any/any près du haut court-circuite toutes les règles en dessous et autorise tout le trafic — le pare-feu cesse en pratique d'imposer quoi que ce soit. Remplacez-la par des règles explicites de moindre privilège pour les flux réellement nécessaires, ordonnées pour que les autorisations et refus spécifiques prennent effet, et terminez par un refus par défaut. La qualifier d'efficace est faux, la déplacer en bas peut encore masquer le refus par défaut, et la renommer ne change rien à ce qu'elle autorise.

La confiance fondée sur l'emplacement réseau signifie qu'un seul point d'appui à l'intérieur ouvre un large déplacement latéral — un identifiant VPN hameçonné et l'attaquant est « à l'intérieur ». Le zero trust supprime la confiance implicite : chaque accès est authentifié, autorisé et réévalué en continu selon l'identité et la posture de l'appareil, avec moindre privilège et segmentation (NIST SP 800-207). Un second VPN ou un VPN élargi ne fait qu'étendre le même problème de confiance plate, et faire confiance au LAN plutôt qu'au VPN répète l'erreur initiale.

Les ports d'administration ouverts à tout Internet sont scannés et attaqués par force brute en quelques minutes ; la solution consiste à réduire la surface d'attaque : restreindre l'ingress du security group à des CIDR d'administration connus ou au VPN, ou supprimer entièrement l'entrant à l'aide d'un bastion ou de SSM Session Manager. Déplacer SSH sur un port non standard est une sécurité par l'obscurité que les scanners contournent trivialement. Un mot de passe plus fort ne réduit pas la surface exposée et n'arrête pas le credential stuffing. Se fier à un pare-feu hôte ignore la surface d'attaque que le security group annonce ouvertement à Internet.

Les règles d'engagement excluent généralement le déni de service en production, et un plantage non planifié cause un dommage réel à l'activité et peut annuler la mission. Vérifiez d'abord le périmètre ; si une preuve de concept destructrice n'est pas autorisée, prouvez la vulnérabilité par des moyens plus sûrs et documentez clairement l'impact probable. Lancer l'exploit pour une capture d'écran est imprudent. Le lancer à répétition pour des « métriques de fiabilité » multiplie la panne. Le passer sous silence cache au client un risque sérieux et exploitable.

Ce qui compte, c'est l'impact : un identifiant de service réutilisé ou surprivilégié qui débloque l'admin du domaine ou des systèmes critiques est le constat qui compte, alors testez la réutilisation et cartographiez les privilèges et le chemin de mouvement latéral. Casser d'abord tous les autres hashs est une perte de temps qui retarde l'essentiel. Changer le mot de passe du compte de service est destructeur, casse la production et alerte les défenseurs. Envoyer un identifiant actif en clair par e-mail est en soi une exposition et une mauvaise hygiène opérationnelle.

L'autorisation définit la mission : tester hors du périmètre convenu est potentiellement illégal et viole les règles d'engagement, aussi tentante que soit la cible. Documentez ce que vous avez vu, arrêtez-vous et obtenez l'accord écrit du client avant d'aller plus loin. Exploiter pour « plus de constats » ne justifie jamais un accès non autorisé. L'exploiter discrètement en pensant ne pas être pris est à la fois contraire à l'éthique et un délit, et étendre le périmètre vous-même prive le client de son consentement éclairé.

Une RCE non authentifiée sur un serveur exposé sur Internet relève de l'urgence : réduisez la fenêtre d'exposition par un déploiement testé, en staging ou progressif, et ajoutez des contrôles compensatoires (restreindre l'accès, règles WAF) en attendant. Attendre la fenêtre trimestrielle laisse un trou exploitable comme un ver ouvert des semaines. Patcher à l'aveugle en production en heures ouvrées sans test risque une panne et un rollback raté. Se fier au pare-feu périmétrique ne sert à rien — le service est déjà exposé et l'exploit n'a besoin d'aucun identifiant.

Les réseaux plats permettent à un seul appareil invité compromis d'atteindre directement les systèmes les plus précieux. Segmentez par niveau de confiance et appliquez un trafic à moindre privilège entre les zones pour contenir et surveiller les déplacements latéraux. Un pare-feu de bordure ne fait rien pour le trafic est-ouest entre des hôtes déjà à l'intérieur. Re-adresser les serveurs financiers est de la sécurité par l'obscurité qu'un simple scan déjoue. L'antivirus est une couche de détection, pas un substitut au contrôle architectural d'isolement des systèmes sensibles.

Les renouvellements manuels échouent, alors éliminez le problème par l'ingénierie avec un renouvellement ACME automatisé et une surveillance d'expiration qui alerte plusieurs jours à l'avance. Un rappel d'agenda, c'est le processus manuel qui a déjà échoué. Un certificat auto-signé à longue durée brise la confiance publique et viole les limites de durée modernes (les AC plafonnent la validité à ~398 jours, et cela baisse encore). Désactiver TLS échange une coupure de disponibilité contre une perte catastrophique de confidentialité et d'intégrité.

Des requêtes TXT à fort volume et forte entropie, ou de longs sous-domaines vers un seul domaine, sont une signature classique de tunneling DNS / C2-exfiltration : des données sont passées en douce dans le DNS pour échapper au filtrage de sortie. Capturez un échantillon de requêtes pour analyse, sinkholez ou bloquez le domaine pour couper le canal, et pivotez vers l'hôte pour trouver le processus responsable. L'écarter comme du cache normal ou un site lent laisse passer une exfiltration en cours. Redémarrer le serveur DNS ne fait rien contre le poste compromis et perturbe juste la résolution de noms.

La Cyber Kill Chain modélise une intrusion en sept étapes séquentielles : reconnaissance, militarisation, livraison, exploitation, installation, commande et contrôle (C2), et actions sur les objectifs. Les défenseurs associent des détections et des contrôles à chaque étape ; comme les étapes sont séquentielles, briser un seul maillon — bloquer l'e-mail de phishing, tuer le C2 — perturbe toute l'attaque. Cela pousse à détecter tôt plutôt qu'à la seule intrusion finale.

L'exfiltration DNS encode des données volées dans des requêtes DNS (par ex. de longs labels de sous-domaine envoyés à un serveur autoritaire contrôlé par l'attaquant), en abusant du fait que le DNS est presque toujours autorisé en sortie et souvent non surveillé. Détectez-la par des anomalies : volume de requêtes anormalement élevé vers un domaine, sous-domaines longs / à forte entropie, nombreux sous-domaines uniques par domaine parent, abus d'enregistrements TXT/NULL, et requêtes vers des domaines récemment enregistrés ou rares.

SPF publie quelles IP peuvent envoyer du courrier pour un domaine. DKIM ajoute une signature cryptographique pour que le destinataire puisse vérifier que le message n'a pas été altéré et provient bien du domaine. DMARC relie les résultats SPF/DKIM à l'en-tête From: visible via l'« alignement », dit aux destinataires quoi faire en cas d'échec (none/quarantine/reject) et envoie des rapports. SPF et DKIM seuls ne protègent pas le From que voit l'utilisateur — c'est DMARC qui l'impose.

Un honeypot est un système ou service leurre sans usage métier légitime, délibérément exposé pour attirer les attaquants. Comme rien de bénin ne devrait jamais le toucher, toute interaction est une alerte hautement fiable. Les honeypots à faible interaction émulent des services à peu de frais ; ceux à forte interaction sont de vrais systèmes qui livrent une intel plus riche mais comportent plus de risque. Les honeytokens sont la même idée appliquée à de faux identifiants, fichiers ou enregistrements. Valeur : détection précoce, peu de faux positifs et threat intelligence.

La défense en profondeur superpose des contrôles multiples, variés et indépendants à travers les personnes, les processus et la technologie, afin que la défaillance d'un seul contrôle n'entraîne pas de compromission. Elle suppose que chaque contrôle finira par échouer et utilise la redondance et la variété pour ralentir, détecter et contenir un attaquant.

Partez d'une image de base minimale et de confiance (distroless ou slim) pour réduire la surface d'attaque, analysez les images à la recherche de CVE connues dans la CI et dans le registre, épinglez et vérifiez les empreintes (digests) des images, exécutez avec un utilisateur non-root et évitez d'intégrer des secrets. Signez les images et imposez des politiques d'admission pour que seules les images analysées et signées s'exécutent. Reconstruisez régulièrement pour que les couches de base corrigées se propagent.

Le RBAC contrôle ce que les identités peuvent faire sur l'API Kubernetes — les Roles et ClusterRoles accordent des verbes sur des ressources, liés à des sujets via des RoleBindings — et doit suivre le moindre privilège, en évitant cluster-admin et les wildcards. Les politiques réseau contrôlent le trafic pod-à-pod, qui est autorisé par défaut jusqu'à ce que vous appliquiez un default-deny puis permettiez explicitement les flux requis. Ensemble, ils limitent le rayon d'impact si un pod ou un jeton est compromis.

CloudTrail enregistre chaque appel API dans le compte — qui a fait quoi, quand, d'où — vous donnant la piste d'audit faisant autorité pour les investigations et la conformité. GuardDuty est un service géré de détection des menaces qui analyse CloudTrail, les flux VPC et les journaux DNS pour faire remonter des découvertes comme l'exfiltration d'identifiants ou le minage de cryptomonnaie. CloudTrail est la source de vérité que vous devez protéger ; GuardDuty transforme cette télémétrie en alertes exploitables.

Les security groups sont des pare-feux à état attachés aux instances/ENI : ils n'ont que des règles d'autorisation, et le trafic de retour d'un flux autorisé est automatiquement permis. Les network ACL sont des filtres sans état à la frontière du sous-réseau : ils ont des règles ordonnées d'autorisation et de refus, et vous devez autoriser explicitement le trafic de retour sur les ports éphémères. Les security groups sont le contrôle principal ; les NACL ajoutent des garde-fous grossiers au niveau du sous-réseau, comme bloquer une plage d'IP.

La confidentialité persistante parfaite (PFS) signifie que chaque session dérive une clé unique d'un échange de clés éphémère jeté ensuite. Si un attaquant vole plus tard la clé privée à long terme du serveur, il ne peut toujours pas déchiffrer le trafic capturé précédemment, car cette clé n'a jamais servi à dériver les clés de session. Cela s'obtient avec un Diffie-Hellman éphémère (DHE/ECDHE).

Le client et le serveur se mettent d'accord sur un secret partagé en un seul aller-retour grâce au Diffie-Hellman éphémère (ECDHE). Le ClientHello transporte les groupes pris en charge et un key share ; le serveur répond avec son key share et son certificat, les deux parties dérivent les mêmes clés, et les données applicatives circulent immédiatement, avec la confidentialité persistante par défaut.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants afin que, si l'un échoue, les autres protègent encore l'actif. Elle suppose qu'aucun contrôle n'est parfait — par exemple en combinant pare-feu, segmentation réseau, protection des terminaux, MFA, moindre privilège et chiffrement, plutôt que de se fier au seul périmètre.

Un IDS (système de détection d'intrusion) surveille le trafic et lève des alertes mais ne bloque pas — il est généralement hors bande. Un IPS (système de prévention d'intrusion) se place en ligne dans le chemin du trafic et peut activement rejeter ou bloquer le trafic malveillant. L'IPS prévient, mais un faux positif peut casser du trafic légitime.

TCP est orienté connexion et fiable : il utilise une poignée de main en trois temps, garantit une livraison ordonnée et retransmet les paquets perdus. UDP est sans connexion et rapide, sans garantie de livraison, d'ordre ni de congestion. On utilise TCP pour l'exactitude (web, e-mail, transfert de fichiers) et UDP pour le trafic sensible à la vitesse (DNS, VoIP, streaming, jeux).

Un pare-feu contrôle le trafic entre zones réseau en l'autorisant ou en le refusant selon des règles. Un pare-feu sans état évalue chaque paquet isolément par rapport aux règles ; un pare-feu à état suit l'état des connexions pour autoriser le trafic de retour des sessions qu'il a permises. Les pare-feu nouvelle génération ajoutent la connaissance de la couche applicative.

Ni l'un ni l'autre. ARP est un protocole de couche 2 (couche liaison) encapsulé directement dans une trame Ethernet, et non dans un paquet IP. Comme il ne circule jamais sur IP, il ne peut utiliser ni TCP ni UDP, qui sont des transports de couche 4 nécessitant IP en dessous. Le rôle d'ARP est de résoudre une adresse IP connue en l'adresse MAC correspondante sur le même segment de réseau local.

Filtré. Un port filtré rejette silencieusement le paquet, donc le scanner n'obtient aucune réponse et doit attendre un délai d'expiration : il n'apprend rien sur l'existence même de l'hôte, et le scan est considérablement ralenti. Un port fermé renvoie un RST TCP, qui confirme que l'hôte est vivant et répond, offrant gratuitement à l'attaquant une valeur de reconnaissance.

Pas à lui seul. HTTPS empêche le MITM uniquement quand la validation du certificat est strictement appliquée et que le client atteint le site en HTTPS dès le départ. Si une AC malveillante est de confiance (proxy d'entreprise, racine installée par un logiciel malveillant), si l'utilisateur passe outre les avertissements de certificat, ou si du SSL stripping rétrograde la connexion vers HTTP avant le démarrage de TLS, un attaquant peut toujours se placer au milieu.

HTTPS n'est pas un protocole à part entière : c'est du HTTP ordinaire circulant dans un tunnel TLS chiffré. SSL est l'ancien nom : SSL 2.0/3.0 sont les prédécesseurs obsolètes et non sécurisés de TLS, qui les a remplacés (TLS 1.0 à 1.3). Quand les gens disent « certificat SSL » ou « SSL », ils désignent presque toujours en réalité TLS.

Question piège : ping n'utilise aucun port. Il s'exécute sur ICMP, un protocole de couche 3 qui repose directement sur IP. Les ports n'existent que dans les protocoles de couche 4 comme TCP et UDP, donc ICMP (et donc ping) n'en a aucun. ICMP utilise à la place des champs de type et de code, par ex. Echo Request type 8 et Echo Reply type 0.

Trois. Le client envoie un SYN, le serveur répond par un SYN-ACK combiné (un seul paquet qui à la fois accuse réception du SYN du client et envoie le propre SYN du serveur), et le client termine par un ACK. L'astuce est que SYN-ACK est un seul paquet, pas deux, donc le total est de trois — exactement ce que désigne « en trois temps ».

Le Zero Trust abandonne l'hypothèse selon laquelle être à l'intérieur du réseau vous rend digne de confiance. Chaque requête vers une ressource est authentifiée et autorisée pour elle-même — en vérifiant l'identité, l'état de santé de l'appareil et le contexte — par un point de décision de politique, accordant un accès au moindre privilège par session. Il n'y a pas de zone interne de confiance ; l'emplacement réseau d'une requête n'est qu'un signal, pas un laissez-passer.

PTES définit sept phases : pré-engagement (périmètre, règles d'engagement, autorisation), collecte de renseignements (OSINT, reconnaissance), modélisation des menaces, analyse de vulnérabilités, exploitation, post-exploitation (pivotement, données de valeur, persistance) et reporting. La structure rend les missions reproductibles, défendables et liées au risque métier plutôt qu'à du hacking improvisé. Le pré-engagement et le reporting sont les phases que les juniors sous-estiment.

Un pentest vise une large couverture — trouver autant de vulnérabilités que possible dans une cible délimitée. Une red team est une émulation d'adversaire pilotée par objectif : choisir un but (par ex. atteindre les données les plus précieuses), émuler les TTP d'un acteur de menace précis, rester furtif pour tester la détection et la réponse, et éviter le scan bruyant. La red team mesure l'équipe bleue et toute l'organisation, pas seulement l'actif ; les deux exigent des règles d'engagement strictes et une autorisation.

La gestion des vulnérabilités est une boucle continue : découvrir les actifs et vulnérabilités (scan, inventaire d'actifs), prioriser selon le risque réel (CVSS plus exploitabilité, exposition et criticité des actifs — des frameworks comme EPSS et SSVC aident), remédier ou atténuer, vérifier la correction et rapporter sur les tendances et les SLA. Le scan est la partie facile ; la discipline est de prioriser et de boucler la boucle pour que le risque baisse réellement avec le temps.

SSH utilise TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS le 53 (UDP et TCP), RDP TCP 3389 et SMB TCP 445. Connaître les ports réservés permet de lire la sortie d'un scan, d'écrire des règles de pare-feu et de trier les alertes rapidement — un service sur son port attendu plutôt qu'inattendu est un signal immédiat.

Un résolveur stub demande un nom à un résolveur récursif. S'il n'est pas en cache, le résolveur récursif parcourt la hiérarchie : il interroge un serveur racine (qui pointe vers le TLD), le serveur TLD (qui pointe vers les serveurs autoritaires du domaine) et enfin le serveur autoritaire, qui détient l'enregistrement réel. La réponse est mise en cache en chemin selon son TTL. Le DNS utilise le port 53 — UDP pour la plupart des requêtes, TCP pour les volumineuses.

Un proxy direct se place devant les clients et émet des requêtes sortantes en leur nom — pour le contrôle de sortie, le filtrage, la mise en cache et l'anonymat. Un proxy inverse se place devant les serveurs et reçoit les requêtes entrantes en leur nom — pour la répartition de charge, la terminaison TLS, la mise en cache et comme façade de sécurité pour un WAF. Le sens vers lequel il fait face, côté client ou côté serveur, est la distinction clé.

Traceroute découvre les routeurs entre vous et une destination en exploitant le champ TTL. Il envoie des paquets avec TTL=1, puis 2, puis 3, et ainsi de suite. Chaque routeur décrémente le TTL ; quand le TTL atteint zéro, ce routeur rejette le paquet et renvoie un message ICMP Time Exceeded, révélant son adresse. En augmentant le TTL, traceroute cartographie chaque saut dans l'ordre jusqu'à atteindre la destination.

Le NAT (Network Address Translation) réécrit l'IP source et/ou destination à mesure que les paquets franchissent une frontière, mappant généralement des adresses internes privées vers des publiques. Le PAT (Port Address Translation, ou NAT overload) étend cela en traduisant aussi les ports, laissant de nombreux hôtes internes partager une seule IP publique — chaque flux distingué par son port. Le PAT est ce que les routeurs domestiques et de bureau utilisent pour placer tout un LAN derrière une seule adresse.

Le modèle OSI divise le réseau en sept couches, chacune ajoutant une responsabilité : Physique (bits sur le câble), Liaison de données (trames et adressage MAC), Réseau (routage IP), Transport (TCP/UDP, ports, fiabilité), Session (gestion des connexions), Présentation (encodage, chiffrement, compression) et Application (protocoles comme HTTP). Chaque couche encapsule celle au-dessus à mesure que les données descendent la pile.

Un sous-réseau est une subdivision logique d'un réseau IP. Le masque de sous-réseau marque quels bits d'une adresse IP forment la partie réseau et quels bits forment la partie hôte — par exemple, /24 (255.255.255.0) signifie que les 24 premiers bits identifient le réseau et les 8 derniers les hôtes. Le découpage contrôle comment le trafic est routé et permet de segmenter un réseau en domaines de diffusion plus petits.

TCP ouvre une connexion en trois étapes. Le client envoie un SYN avec un numéro de séquence initial, le serveur répond par un SYN-ACK (accusant réception du numéro du client et envoyant le sien), et le client renvoie un ACK. Après cet échange, les deux parties se sont accordées sur les numéros de séquence de départ et la connexion est établie pour une livraison fiable et ordonnée des octets.

TCP est orienté connexion : il fait une poignée de main, numérote les octets, retransmet les pertes et contrôle la congestion, offrant une livraison fiable et ordonnée au prix de la latence et du surcoût. UDP est sans connexion et fonctionne en mode envoyer-et-oublier — pas de poignée de main, pas de retransmission, pas d'ordonnancement. Utilisez TCP quand l'exactitude compte (web, e-mail, transfert de fichiers) et UDP quand la vitesse prime sur la perfection (DNS, VoIP, jeux, vidéo).

Le modèle TCP/IP a quatre couches — Liaison, Internet, Transport et Application — et décrit le fonctionnement réel d'Internet. OSI en a sept. Elles correspondent étroitement : la couche Application de TCP/IP absorbe les couches Application, Présentation et Session d'OSI ; sa couche Liaison combine les couches Physique et Liaison de données d'OSI. OSI est la meilleure référence pour l'enseignement et le dépannage ; TCP/IP est la suite de protocoles réellement mise en œuvre.

Un VLAN (réseau local virtuel) partitionne logiquement un commutateur physique en domaines de diffusion de couche 2 distincts, de sorte que des appareils sur des VLAN différents ne peuvent pas se joindre directement, même sur le même matériel. Il est étiqueté par un marqueur 802.1Q sur les liens de trunk. La valeur de sécurité est la segmentation : isoler le trafic des utilisateurs, des serveurs, des invités et de l'IoT limite la portée des diffusions et le mouvement latéral, le trafic inter-VLAN étant forcé de passer par un routeur ou un pare-feu où la politique est appliquée.

Un VPN crée un tunnel chiffré au niveau réseau/OS, de sorte que tout le trafic d'un appareil y est routé et protégé de bout en bout — utilisé pour l'accès distant sécurisé. Un proxy opère au niveau applicatif, relayant le trafic d'applications ou de protocoles spécifiques sans nécessairement le chiffrer. Les grandes différences sont la portée (tout l'appareil vs par application) et le fait qu'un VPN chiffre par conception alors que de nombreux proxys ne le font pas.

Une DMZ (zone démilitarisée) est un segment réseau situé entre l'Internet non fiable et le réseau interne de confiance, hébergeant des services exposés au public comme les serveurs web, mail et DNS. Les règles de pare-feu laissent Internet atteindre la DMZ mais restreignent fortement l'accès de la DMZ au réseau interne. Le but est le confinement : si un serveur public est compromis, l'attaquant reste coincé dans la zone tampon plutôt que d'atterrir dans le LAN.

On commence par un scan complet des ports TCP, puis on énumère en profondeur chaque service ouvert — bannières, versions, identifiants par défaut, accès anonyme et contenu web — avant de toucher au moindre exploit. La plupart des machines tombent grâce à une énumération minutieuse, pas à des exploits astucieux, ce qui est le cœur de l'état d'esprit « try harder ».

Le scan nmap par défaut ne couvre que les 1000 ports les plus courants, donc un service sur un port haut serait entièrement manqué. Le schéma efficace est un scan SYN rapide des 65535 ports d'abord, puis un scan ciblé de versions et de scripts par défaut uniquement sur les ports trouvés ouverts.

Utilisez l'hôte compromis comme relais vers le sous-réseau inaccessible. Mettez en place une redirection de port pour un service unique, ou un proxy SOCKS dynamique (SSH -D ou chisel) et routez vos outils à travers lui avec proxychains, pour que votre machine d'attaque atteigne les hôtes internes via le pivot.

Pour SMB, énumérez les partages, vérifiez l'accès anonyme/session null, listez les utilisateurs et identifiez la version pour les CVE connues. Pour SNMP, essayez les community strings par défaut comme « public » et parcourez la MIB pour extraire noms d'utilisateurs, processus en cours, logiciels installés et détails réseau.

La reconnaissance passive recueille des informations sans interagir directement avec les systèmes de la cible — OSINT, enregistrements DNS, transparence des certificats. La reconnaissance active touche la cible, comme le balayage de ports ou la capture de bannières, ce qui est plus bruyant mais donne plus de détails.

Un test d'intrusion passe par le pré-engagement (cadrage et règles d'engagement), la reconnaissance, le balayage et l'énumération, l'exploitation, la post-exploitation et le reporting. Chaque phase alimente la suivante, et le reporting est le moment où la valeur est réellement livrée au client.

Le pivoting transforme un hôte compromis en relais pour atteindre des segments internes vers lesquels votre machine ne peut pas router. Vous utilisez le port forwarding, un proxy SOCKS sur votre canal C2 (par ex. Chisel, le forwarding dynamique SSH) ou un routage par agent, puis vous lancez des outils à travers ce tunnel pour attaquer le sous-réseau suivant.

Énumérez d'abord : privilèges actuels, droits sudo, binaires SUID/SGID, tâches cron, fichiers inscriptibles dans le PATH, version du noyau et identifiants stockés. Puis exploitez le chemin le plus simple et fiable — souvent une règle sudo mal configurée ou un GTFOBin SUID — avant de recourir à un exploit du noyau.

Un bind shell ouvre un port d'écoute sur la cible et attend que vous vous y connectiez. Un reverse shell fait que la cible se connecte en sortie vers un écouteur que vous contrôlez. Les reverse shells l'emportent généralement car le trafic sortant contourne les règles de pare-feu entrantes et le NAT.

Un scan de vulnérabilités est un inventaire automatisé, en largeur, des faiblesses potentielles, souvent avec des faux positifs. Un test d'intrusion est mené par un humain : il valide les trouvailles, les enchaîne et démontre un impact métier réel par une exploitation effective.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants pour que, si l'un échoue, les autres protègent encore l'actif. Aucun contrôle n'est supposé parfait, on empile donc des mesures préventives, de détection et de réponse sur les couches réseau, hôte, application et données.

Réduire la surface d'attaque (supprimer paquets et services inutilisés), imposer SSH par clé uniquement sans connexion root, maintenir le système à jour, exécuter un pare-feu en deny-par-défaut n'exposant que les ports nécessaires, appliquer le moindre privilège via sudo et les permissions de fichiers, activer auditd et la journalisation centralisée, et ajouter la surveillance d'intégrité ainsi qu'un MAC comme SELinux ou AppArmor.

La segmentation divise un réseau en zones isolées pour qu'une intrusion dans l'une ne puisse pas atteindre librement les autres, limitant le mouvement latéral. Le zero trust va plus loin : il supprime entièrement la confiance implicite fondée sur l'emplacement réseau, en authentifiant et autorisant chaque requête où qu'elle provienne — la microsegmentation est l'un des moyens de l'implémenter.

Une PKI est le système de CA, de certificats et de politiques qui lie les clés publiques aux identités. Pour valider un certificat de serveur, un client construit une chaîne jusqu'à une racine de confiance, vérifie chaque signature, contrôle les dates de validité et le nom d'hôte, confirme l'usage de la clé, et vérifie la révocation via CRL ou OCSP.

Presque tout passe par le DNS, donc les logs DNS révèlent des menaces que d'autres sources manquent : le beaconing de command-and-control (rappels réguliers vers un domaine), le tunneling et l'exfiltration DNS (gros volume de sous-domaines longs et encodés), et les domaines générés algorithmiquement (DGA). On les détecte via des motifs comme la régularité des requêtes, l'entropie, les types d'enregistrement et le volume, plutôt que par une seule résolution suspecte.