Sécurité des réseaux — mise en œuvre

Hardening pragmatique du périmètre, du LAN, du Wi‑Fi et des accès distants — segmentation, filtrage, visibilité et résilience.

Objectif et principes

Pourquoi durcir ? Pour réduire l’exposition (ingress/egress), contenir les mouvements est‑ouest, et voir ce qui se passe (journaux/flows). Un réseau bien segmenté transforme une intrusion en incident contenu.

Comment ? Par la défense en profondeur (L2→L7), le moindre privilège réseau (par défaut deny), la standardisation (baselines d’équipements) et l’automatisation (IaC/Ansible/Netconf). Chaque règle est justifiée (risque) et vérifiable (contrôle).

Règles d’or
  • Bloquer par défaut, autoriser explicitement, journaliser les exceptions.
  • Segmenter selon les flux métiers réels, pas selon l’organigramme.
  • Automatiser la configuration, sauvegarder et vérifier la dérive.

Sommaire rapide

Méthode en 6 étapes

  1. Cartographier les actifs et flux (nord‑sud/est‑ouest), dépendances DNS/NTP/DHCP.
  2. Choisir l’architecture : segmentation L3/L7, microsegmentation, ZTNA/bastions.
  3. Réduire l’exposition : périmètre minimal, egress filtering, ports fermés par défaut.
  4. Contrôler l’accès : ACL/pare‑feu, 802.1X/NAC, listes d’autorisation par application.
  5. Visibilité : journaux syslog, NetFlow/IPFIX, DNS logs, IDS/IPS/NDR.
  6. Maintenir : MCO, sauvegardes de conf, patchs, détection de dérive, tests réguliers.

Segmentation & pare‑feu

Pourquoi

Limiter la propagation et restreindre chaque zone à ses usages légitimes. La microsegmentation réduit les déplacements latéraux.

Comment

  • L3/L7 : VLANs/VRF pour l’isolement L3 ; politiques L7 par application sur NGFW.
  • Modèle : par défaut deny, autoriser seulement les flux documentés.
  • Cloud : Security Groups/NACL en deny‑all + listes d’autorisation minimales.

Exemples

# nftables — politique par défaut deny
nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0; policy drop }'
nft 'add rule inet filter input ct state established,related accept'
nft 'add rule inet filter input iif lo accept'

# Cisco IOS‑XE — ACL restrictive
ip access-list extended APP-WEB
 permit tcp any host 10.10.10.20 eq 443
 deny   ip any any log
interface GigabitEthernet0/0
 ip access-group APP-WEB in

Filtrage egress & accès Internet

  • Egress par défaut « deny », n’ouvrir que les destinations nécessaires (FQDN ou plages IP).
  • Proxy web explicite, filtrage URL/SSL selon politique, journalisation complète.
  • DNS d’entreprise : résolveurs internes, filtrage domaines malveillants, logs.

Contrôles rapides

# Tester résolution et sortie
nslookup repo.example.com $CORP_DNS
curl -I https://repo.example.com
# Vérifier qu’un flux interdit est bloqué
curl -m 5 https://site-non-autorise.tld || echo "Bloqué (attendu)"

Accès distants — VPN / ZTNA

  • MFA systématique, évaluation de posture (EDR, chiffrement disque) avant accès.
  • Split‑tunnel réduit ou interdit selon sensibilité ; DNS internal only.
  • ZTNA : accès applicatif par identité/appareil plutôt que réseau complet.

Bonnes pratiques

  • IPsec/IKEv2 ou TLS modernes, suites fortes, certificats courts.
  • Journaliser par utilisateur et application, pas seulement par IP.
  • Limiter les sous‑réseaux accessibles, pas de « any any » sur le pool VPN.

Wi‑Fi d’entreprise

  • WPA3‑Enterprise (EAP‑TLS si possible), PMF/MFP activé, 802.1X sur tous les SSID pro.
  • SSID invités isolé (VLAN/VRF dédiés), client isolation, egress strict.
  • Détection de points d’accès rogues et désactivation WPS.

Exemples de posture

# Contrôleur — aperçu (conceptuel)
show wlan summary
show ap rogue summary
show radius statistics

DNS / DHCP / NTP

  • DNS : validation DNSSEC, blocage malwares, logs de requêtes ; DoT/DoH interne si requis.
  • DHCP : DHCP snooping, réservations pour serveurs, pas de serveurs « sauvages ».
  • NTP : sources internes, authentification si possible, pare‑feu dédié.

Contrôles

# DNSSEC
dig +dnssec +ad anssi.fr @corp-dns | grep "ad flag"
# DHCP snooping (Cisco)
show ip dhcp snooping
# NTP
chronyc sources -v

Routage & BGP

  • BGP sécurisé : TTL‑security, MD5/TCP‑AO, max‑prefix, filtrage bogons, RPKI.
  • OSPF/ISIS authentifiés, zones bien définies, pas d’adjacences non maîtrisées.
  • CoPP/CP‑Protect pour la protection du plan de contrôle.

Exemples

# Cisco — BGP avec TTL‑security et max‑prefix
router bgp 65001
 neighbor 203.0.113.1 remote-as 65002
 neighbor 203.0.113.1 password 7 
 neighbor 203.0.113.1 ttl-security hops 2
 neighbor 203.0.113.1 maximum-prefix 50 90 restart 5

# JunOS — RPKI (conceptuel)
set routing-options validation group RPKI session 198.51.100.10
set policy-options policy-statement ORIGIN-VALIDATION term VALID from protocol bgp

Durcissement des équipements

  • Plan d’admin isolé (OOB/VRF), accès SSHv2/HTTPS uniquement, listes d’IP autorisées.
  • AAA centralisé (RADIUS/TACACS+), accounts nominatifs, RBAC, session logs.
  • SNMPv3 seulement, désactiver Telnet/HTTP/legacy, bannières légales.
  • Syslog/NTP vers sources internes, images signées, Secure Boot quand dispo.

Exemples

# Cisco IOS‑XE — management durci
ip ssh version 2
ip http server disable
line vty 0 4
 transport input ssh
 access-class MGMT-ACL in

# JunOS — SNMPv3
set snmp v3 usm local-engine user netadmin authentication-sha auth-password "***"
set snmp v3 usm local-engine user netadmin privacy-aes128 priv-password "***"

Visibilité & télémétrie

  • Centraliser syslog, activer NetFlow/sFlow/IPFIX, DNS logs, proxy/mail logs.
  • NDR/IDS/IPS aux points clés ; SPAN/mirror pour analyses ponctuelles.
  • Alertes sur changements de configuration et écarts à la baseline.

Annexes — Check‑lists express

Périmètre/Datacenter

  • Politiques par défaut deny (ingress/egress), règles documentées et journalisées.
  • Zones/VRF séparées (utilisateurs, serveurs, admin, invités, IoT).
  • IPS/NDR au périmètre et entre zones sensibles.
  • Backup de configurations chiffrées, versionnées et test de restauration.

Accès/LAN

  • 802.1X + VLAN d’isolement par défaut ; DHCP snooping, DAI, Port‑Security.
  • SNMPv3, SSH uniquement ; désactiver services hérités.
  • Syslog/NTP centralisés ; CoPP sur équipements de couche 3.

Wi‑Fi

  • WPA3‑Enterprise (EAP‑TLS), PMF activé ; invités isolés ; détection de rogues.
  • Puissances/chaînes calibrées ; AP à jour ; contrôleur redondé.

Cloud/SD‑WAN

  • VPC/VNet segmentés ; Security Groups/NACL en deny‑all par défaut.
  • PrivateLink/Endpoints pour services managés ; Bastion/SSM pour admin.
  • Flow Logs activés, exportés au SIEM ; pare‑feu virtuels entre sous‑réseaux sensibles.

Contrôles de conformité automatisables

Commandes exemples pour valider l’application des points clés.

Linux (appliance/pare‑feu)

# Politiques par défaut
sudo nft list ruleset | sed -n '1,100p'
# Services d’admin
ss -lntp | egrep ':(22|443) '
# Journalisation
sudo ls -l /var/log | head

Cisco IOS‑XE

show ip access-lists
show running-config | include ip ssh|ip http|snmp-server|logging host
show ip dhcp snooping
show policy-map control-plane

JunOS

show configuration system services | display set
show configuration snmp | display set
show firewall

DNS/NTP

dig +dnssec +ad example.com @corp-dns
chronyc sources -v

Hygiène réseau — règles essentielles (adaptées des 42 règles ANSSI)

Uniquement la partie réseau. Chaque règle expose le pourquoi et le comment, avec déclinaisons Périmètre, LAN/Datacenter, Cloud/SD‑WAN, Wi‑Fi.

Commencez par une baseline d’équipements (Cisco/Juniper/Forti/Aruba), versionnez la configuration (Git), mesurez la conformité et corrigez via automatisation (Ansible/Netconf/API).

  1. Règle 01 — Inventorier actifs et flux

    Pourquoi : sans inventaire/topologie, impossible de segmenter ni filtrer. Comment : CMDB/NetBox, découverte passive (NetFlow) et mapping des dépendances.

    • Périmètre : carte des entrées/sorties, IP publiques, services exposés.
    • LAN/DC : inventaire commutateurs/VRF/VLAN, liaisons et MTU.
    • Cloud/SD‑WAN : VPC/VNet, peering, routes, SG/NACL.
    • Wi‑Fi : contrôleurs, AP, SSID, bandes et canaux.

  2. Règle 02 — Baselines de configuration

    Pourquoi : homogénéité = moins d’erreurs. Comment : modèles par rôle (core, distribution, accès, FW, WLC) avec bannières, AAA, SNMPv3, NTP, syslog.

    • Périmètre : modèles NGFW/edge avec politiques par défaut deny.
    • LAN/DC : gabarits L2/L3, CoPP, spanning‑tree guard.
    • Cloud/SD‑WAN : modules IaC pour SG/NACL/route tables.
    • Wi‑Fi : profils SSID (EAP‑TLS), PMF, QoS.

  3. Règle 03 — Minimiser services d’admin

    Pourquoi : réduire la surface. Comment : SSH/HTTPS seulement, IP autorisées, VRF/plan OOB dédié.

    • Périmètre : pas d’admin depuis Internet ; bastion obligatoire.
    • LAN/DC : ACL management, AAA centralisé.
    • Cloud/SD‑WAN : APIs restreintes, clés courtes.

  4. Règle 04 — Comptes nominatifs & AAA

    Pourquoi : traçabilité. Comment : TACACS+/RADIUS, RBAC selon rôle, pas de comptes partagés.

    • Périmètre : logs d’admin vers SIEM, MFA via bastion.
    • LAN/DC : session timeout, commandes autorisées par rôle.

  5. Règle 05 — Authentification forte admin

    Pourquoi : comptes à haut impact. Comment : MFA, bastions, certificats pour API.

    • Périmètre : accès via jump/PAW ; pas d’admin depuis postes non gérés.
    • Cloud/SD‑WAN : SSO + MFA sur consoles et API.

  6. Règle 06 — Postes/bastions d’admin dédiés

    Pourquoi : réduire l’attaque par le poste. Comment : PAW verrouillés, segments d’admin dédiés.

    • LAN/DC : réseau d’admin isolé, interconnexion minimale.

  7. Règle 07 — 802.1X/NAC

    Pourquoi : contrôler qui se connecte. Comment : 802.1X, VLAN d’isolement, évaluation de posture.

    • Accès : 802.1X sur ports filaires, MAB en dernier recours.
    • Wi‑Fi : EAP‑TLS, règles par rôle (Dynamic VLAN).

  8. Règle 08 — Segmentation L3/L7

    Pourquoi : limiter l’est‑ouest. Comment : VRF/VLAN, ACL, microsegmentation applicative.

    • Périmètre : DMZ dédiées ; pas de sauts latéraux.
    • LAN/DC : ACL entre VLAN ; NGFW est‑ouest pour zones sensibles.
    • Cloud : SG/NACL stricts ; Security Appliances.

  9. Règle 09 — Pare‑feu par défaut « deny »

    Pourquoi : éviter les « ouvertures » involontaires. Comment : deny all + allow list.

    • Périmètre : ingress limité ; egress filtré.
    • LAN/DC : politiques inter‑VLAN minimales.
    • Cloud : SG/NACL deny‑all puis règles ciblées.

  10. Règle 10 — Chiffrement des flux

    Pourquoi : protéger en transit. Comment : TLS/IPsec/MACsec selon couche.

    • WAN : IPsec entre sites ; MACsec sur liaisons critiques.
    • Périmètre : TLS fort, HSTS, ciphers modernes.

  11. Règle 11 — Journalisation réseau

    Pourquoi : détecter/ enquêter. Comment : syslog, flow logs, DNS logs, horodatage synchronisé.

    • Edge : logs NAT/ACL ; niveaux adaptés.
    • Cloud : VPC Flow Logs activés et exportés.

  12. Règle 12 — Mises à jour/patchs équipements

    Pourquoi : réduire la fenêtre d’exploitation. Comment : versions supportées, fenêtres de maintenance, rollback prêt.

    • WLC/FW : planifier en cluster, maintien du service.

  13. Règle 13 — Boot sécurisé & images signées

    Pourquoi : bloquer les implants bas niveau. Comment : images signées, vérification à l’amorçage.

    • Edge/SD‑WAN : vérification d’intégrité à chaque upgrade.

  14. Règle 14 — Egress filtering

    Pourquoi : limiter C2/exfiltration. Comment : listes d’autorisation, proxy, DNS filtré.

    • Périmètre : blocage par défaut ; exceptions tracées.
    • Cloud : egress via NAT/Proxy contrôlé.

  15. Règle 15 — Passerelles web/mail

    Pourquoi : vecteurs majeurs. Comment : filtrage URL, sandbox, SPF/DKIM/DMARC.

    • Périmètre : inspection SSL selon politique ; respect de la vie privée.

  16. Règle 16 — IoT/Invités isolés

    Pourquoi : appareils peu maîtrisés. Comment : VLAN/VRF dédiés, egress limité, pas d’accès interne.

    • Wi‑Fi : SSID séparé, client isolation.

  17. Règle 17 — DNS sécurisé

    Pourquoi : pivot de l’accès. Comment : DNSSEC, blocage domaines malveillants, journalisation.

    • Périmètre : refuser DNS direct vers Internet.
    • Cloud : résolveurs managés + logs.

  18. Règle 18 — Protocoles hérités

    Pourquoi : vulnérables. Comment : Telnet/HTTP/SNMPv1/2c off, SSHv2/HTTPS/SNMPv3 only.

    • LAN : LLMNR/mDNS limités aux besoins.

  19. Règle 19 — Protections L2

    Pourquoi : attaques locales. Comment : DHCP snooping, DAI, Port‑Security, BPDU‑Guard, Root‑Guard.

    • Accès : ports non utilisés en shutdown dans VLAN parking.

  20. Règle 20 — IDS/IPS/NDR

    Pourquoi : détecter comportements anormaux. Comment : sondes aux points clés, règles/ML, intégration SIEM.

    • DC : inspection est‑ouest des zones critiques.

  21. Règle 21 — Sauvegardes de configuration

    Pourquoi : reprise rapide. Comment : backups chiffrés, versionnés, tests de restauration.

    • Tous équipements : export auto quotidien + après changement.

  22. Règle 22 — Conformité & remédiation auto

    Pourquoi : éviter la dérive. Comment : contrôle périodique et correction via Ansible/NetConf.

    • Cloud : politiques IaC validées en CI.

  23. Règle 23 — Cloisonnement L7

    Pourquoi : limiter impact applicatif. Comment : pare‑feu applicatif, règles par identités.

    • DC : WAF pour apps exposées, segmentation par service.

  24. Règle 24 — WAN/SD‑WAN durcis

    Pourquoi : contrôle centralisé sensible. Comment : certificats courts, liste d’autorités maîtrisée, politiques cohérentes.

    • Edge : tunnels IPsec, QoS sans contournement sécurité.

  25. Règle 25 — Wi‑Fi WPA3‑EAP‑TLS

    Pourquoi : robustesse d’auth. Comment : certificats appareils, PMF, segmentation stricte.

    • Invités : portail captif, isolation, egress limité.

  26. Règle 26 — DNS logging & IoC

    Pourquoi : détection précoce. Comment : collecter requêtes/réponses, corréler aux IoC.

    • Edge : blocage immédiat des domaines malveillants.

  27. Règle 27 — Control‑Plane Policing

    Pourquoi : protéger l’équipement. Comment : limites de taux, ACL mgmt, file d’attente dédiée.

    • Core : CoPP class‑map/policy‑map, monitoring.

  28. Règle 28 — BGP/OSPF sécurisés

    Pourquoi : éviter détournements. Comment : auth, TTL‑security, RPKI, prefix‑lists stricts.

    • Edge : max‑prefix et filtrage bogons toujours.

  29. Règle 29 — NAT maîtrisé

    Pourquoi : réduire exposition. Comment : pas d’entrées par défaut, traductions documentées.

    • Périmètre : pas de DNAT global ; WAF/Reverse‑proxy privilégiés.

  30. Règle 30 — Accès distants contrôlés

    Pourquoi : porte d’entrée majeure. Comment : MFA, posture, périmètre limité, logs par utilisateur.

    • ZTNA : accès applicatif plutôt que L3.

  31. Règle 31 — QoS sans contournement

    Pourquoi : éviter l’abus DSCP. Comment : remarking aux bords, files hiérarchisées.

    • WAN : classes définies, pas d’EF arbitraire.

  32. Règle 32 — IPv6 sécurisé

    Pourquoi : surfaces nouvelles. Comment : RA‑Guard, DHCPv6‑Guard, firewalling symétrique avec IPv4.

    • LAN : SLAAC maîtrisé, pas de dual‑stack non filtré.

  33. Règle 33 — Plan d’admin isolé

    Pourquoi : réduire l’attaque sur l’équipement. Comment : VRF/OOB, ACL mgmt, bastions.

    • Tous : pas d’admin depuis réseaux utilisateurs.

  34. Règle 34 — IPAM & réservations

    Pourquoi : éviter conflits et dérives. Comment : IPAM central, réservations, DHCP contrôlé.

    • DC : adresses d’admin/loopback réservées et documentées.

  35. Règle 35 — Télémétrie moderne

    Pourquoi : supervision efficace. Comment : SNMPv3, NetFlow/IPFIX, gNMI/gRPC selon vendor.

    • Cloud : Flow Logs, metrics managées.

  36. Règle 36 — Réseau cloud sécurisé

    Pourquoi : périmètre diffus. Comment : VPC isolés, SG/NACL stricts, endpoints privés, bastions.

    • Logs : VPC Flow Logs vers SIEM, GuardDuty/Defender activés.

  37. Règle 37 — Principes Zero Trust

    Pourquoi : réduire la confiance implicite. Comment : identité/appareil au cœur des décisions d’accès.

    • Microsegmentation : agents/labels pour règles fines.

  38. Règle 38 — Exposition publique maîtrisée

    Pourquoi : Internet est hostile. Comment : WAF, DDoS, rate‑limit, headers sécurité.

    • CDN : cache, TLS offload contrôlé, IP source masquées.

  39. Règle 39 — Chaîne de conf/IaC

    Pourquoi : erreurs humaines. Comment : revue de code, tests, secrets scannés, approbations.

    • CI/CD réseau : déploiements progressifs, rollback.

  40. Règle 40 — Résilience & continuité

    Pourquoi : panne ou attaque. Comment : redondance, HA, tests de bascule, inventaire de remplacements.

    • FW/WLC : HA actif/actif ou actif/standby testé.

  41. Règle 41 — Sites distants/Invités

    Pourquoi : peu maîtrisés. Comment : politiques homogènes, isolement L2, NAT local, survie en autonomie.

    • SD‑WAN : politiques héritées, journaux centralisés.

  42. Règle 42 — Vérification périodique

    Pourquoi : maintenir la posture. Comment : audits de conf, scans externes, tests d’intrusion réseau.

    • Score de conformité > 95 % ; écarts corrigés par automation.

Indicateurs à suivre

  • Taux de règles « deny‑all » aux frontières et de flux autorisés documentés.
  • Couverture 802.1X/PMF, DHCP snooping/DAI activés, Wi‑Fi invités isolés.
  • Flow logs/syslog centralisés et corrélés ; temps moyen de correction des dérives.

Ressources

  • ANSSI — Guides d’hygiène et de configuration des équipements réseaux
  • CIS Benchmarks — Cisco IOS, JunOS, FortiOS, Palo Alto, Aruba/HP
  • NIST SP 800‑207 — Zero Trust Architecture
  • BCP‑38/84 — Ingress/Egress Filtering (IETF)
  • MANRS / RPKI — Bonnes pratiques de routage