Sécurité des Protocoles de Routage

La sécurité du plan de contrôle est souvent négligée — pourtant un attaquant capable d'injecter des routes ou de hijacker une session BGP contrôle le trafic du réseau entier. Cette page couvre les mécanismes de protection disponibles sur IOS XE, protocole par protocole.

⚠️ Vecteurs d'attaque sur le plan de contrôle

Attaque	Protocole ciblé	Impact
Route Injection	OSPF, EIGRP, BGP, IS-IS	Redirection du trafic, blackhole, MitM
Neighbor Spoofing	OSPF, EIGRP, BGP	Fausse adjacence, injection LSA/Update
Session Hijacking	BGP (TCP 179)	Détournement de session établie
TTL Exploitation	BGP, OSPF	Forger des paquets depuis un AS distant
Route Flap / DoS	BGP, OSPF	Instabilité, CPU spike, convergence storm
Prefix Hijacking	BGP	Annonce de préfixes légitimes depuis un AS illégitime

MÉCANISMES Arsenal de protection disponible sur IOS XE

🔑 Authentification

MD5 / HMAC-SHA

Valide que le voisin est légitime. MD5 sur OSPF/BGP, HMAC-SHA-256 sur EIGRP named mode, key chains pour la rotation des clés.

⏱️ TTL Security / GTSM

Generalized TTL Security Mechanism

RFC 5082 — impose un TTL minimum sur les paquets reçus. Un attaquant distant ne peut pas forger un paquet avec TTL=255. Disponible sur OSPF, BGP, EIGRP.

🚧 Filtrage de préfixes

Prefix-list / Route-map

Contrôle ce qui est annoncé et accepté. Limite l'impact d'une injection ou d'un hijacking. Critique sur BGP en particulier.

🔇 Passive Interface

Suppression des Hellos

Sur les interfaces sans voisin routeur (accès utilisateur, DMZ), désactiver l'envoi de Hellos empêche toute tentative d'adjacence non autorisée.

📊 Max-Prefix

Protection contre les route bombs

BGP uniquement — limite le nombre de préfixes acceptés depuis un peer. Protection contre les annonces accidentelles ou malveillantes de tables de routage complètes.

🌐 RPKI

Resource Public Key Infrastructure

Validation cryptographique de l'origine des préfixes BGP via des ROA (Route Origin Authorization). Protège contre le prefix hijacking à l'échelle Internet.

SYNTHÈSE Matrice de protection par protocole

Protocole	Authentification	GTSM/TTL	Passive Interface	Filtrage	Max-Prefix
OSPF v2	✓ MD5 / SHA	✓ TTL Security	✓	✓ distribute-list	—
EIGRP	✓ MD5 / HMAC-SHA	✓ TTL Security	✓	✓ distribute-list	—
BGP	✓ MD5	✓ TTL Security	N/A	✓ prefix-list / route-map	✓ maximum-prefix
IS-IS	✓ MD5 / HMAC	—	✓	✓ distribute-list	—

💡 Bonne pratique universelle

Combiner authentification + GTSM + passive-interface sur toutes les interfaces sans voisin routeur. Ce trio couvre 95% des vecteurs d'attaque sur le plan de contrôle sans impact sur les performances.

OSPFv2 supporte trois types d'authentification et le GTSM. L'authentification peut être configurée au niveau de la zone (area) ou de l'interface — l'interface a priorité sur l'area.

01 Types d'authentification OSPF

Type	Valeur	Sécurité	Usage
Null	Type 0	Aucune	Défaut — aucune protection
Simple Password	Type 1	Faible	Mot de passe en clair dans les paquets OSPF
MD5	Type 2	Bon	Hash MD5, key-id pour rotation, recommandé minimum
SHA / HMAC	Cryptographic	Meilleur	Via key chain + crypto algorithm, IOS XE 15.4+

02 Authentification MD5 — par Area

Configuration — niveau area (appliqué à toutes les interfaces OSPF de l'area)

! Étape 1 : activer MD5 sur l'area dans le processus OSPF
router ospf 1
  area 0 authentication message-digest

! Étape 2 : configurer la clé MD5 sur chaque interface OSPF
interface GigabitEthernet0/0
  ip ospf message-digest-key 1 md5 MonMotDePasse

Le key-id (ici 1) doit correspondre entre les deux voisins. Plusieurs key-id peuvent coexister pour permettre la rotation sans coupure d'adjacence.

03 Authentification MD5 — par Interface

Configuration — niveau interface (surcharge le paramètre area)

interface GigabitEthernet0/1
  ip ospf authentication message-digest
  ip ospf message-digest-key 1 md5 CleInterface

⚠️ Priorité interface vs area

Si ip ospf authentication est configuré sur l'interface, il écrase le paramètre défini dans router ospf / area X authentication. Pratique pour avoir une exception sur une interface spécifique.

04 Authentification SHA avec Key Chain

Configuration — HMAC-SHA-256 via key chain (IOS XE recommandé)

! Étape 1 : définir la key chain
key chain OSPF-KEYS
  key 1
    key-string MaCleSecrete2026
    cryptographic-algorithm hmac-sha-256

! Étape 2 : appliquer sur l'interface
interface GigabitEthernet0/0
  ip ospf authentication key-chain OSPF-KEYS

La key chain permet la rotation des clés sans interruption d'adjacence grâce aux paramètres accept-lifetime et send-lifetime.

05 GTSM — TTL Security

Generalized TTL Security Mechanism — RFC 5082

Le routeur n'accepte les paquets OSPF que si leur TTL est ≥ 255 - hops. Un attaquant sur un réseau distant ne peut pas forger un TTL=255 (décrémenté à chaque saut).

! Configuration par interface
interface GigabitEthernet0/0
  ip ospf ttl-security hops 1

! Pour désactiver sur une interface (si area-wide activé)
interface GigabitEthernet0/1
  ip ospf ttl-security disable

! Configuration au niveau du processus (toutes les interfaces)
router ospf 1
  ttl-security all-interfaces hops 1

hops 1Voisin directement connecté — TTL reçu doit être ≥ 254

hops 2Voisin à 2 sauts — TTL reçu doit être ≥ 253

ImpactAucun sur les performances — traitement purement au niveau IP

⚠️ Compatibilité GTSM + Virtual Links

Sur les virtual links OSPF (qui traversent plusieurs zones), le TTL peut être inférieur à la valeur attendue. Ajuste hops ou désactive GTSM sur les interfaces concernées.

06 Passive Interface

Suppression des Hellos sur les interfaces sans voisin routeur

router ospf 1
  ! Option 1 : passive par défaut, activer seulement sur les interfaces routeur
  passive-interface default
  no passive-interface GigabitEthernet0/0
  no passive-interface GigabitEthernet0/1

  ! Option 2 : passive sur des interfaces spécifiques
  passive-interface GigabitEthernet0/2  ! interface accès utilisateurs
  passive-interface Loopback0

L'interface reste dans OSPF (annonce son préfixe) mais n'envoie/reçoit plus de Hellos — aucune adjacence possible sur cette interface.

07 Vérification

Commandes show / debug

! Vérifier l'auth configurée par interface
show ip ospf interface GigabitEthernet0/0
  → "Message digest authentication enabled"
  → "Youngest key id is 1"

! Voir les clés actives
show key chain

! Vérifier GTSM
show ip ospf neighbor detail
  → "TTL security enabled, TTL value 1"

! Debug (temporaire, production avec précaution)
debug ip ospf adj

EIGRP supporte deux modes d'authentification selon la configuration : MD5 en classic mode et HMAC-SHA-256 en named mode. Le named mode est recommandé pour les nouveaux déploiements.

01 Authentification MD5 — Classic Mode

Étape 1 — Définir la Key Chain

key chain EIGRP-KEYS
  key 1
    key-string MaCleEIGRP
    ! Optionnel : durée de validité pour rotation
    send-lifetime 00:00:00 Jan 1 2026 infinite
    accept-lifetime 00:00:00 Jan 1 2026 infinite

Étape 2 — Appliquer sur l'interface

interface GigabitEthernet0/0
  ip authentication mode eigrp 100 md5
  ip authentication key-chain eigrp 100 EIGRP-KEYS

Le 100 correspond au numéro de l'AS EIGRP. Les deux commandes sont obligatoires.

02 Authentification HMAC-SHA-256 — Named Mode

Configuration en named mode (recommandé CCIE)

router eigrp CAMPUS         ! nom du virtual-instance
  address-family ipv4 unicast autonomous-system 100
    af-interface GigabitEthernet0/0
      authentication mode hmac-sha-256
      authentication key-chain EIGRP-KEYS
    exit-af-interface

    ! Passive interface en named mode
    af-interface GigabitEthernet0/2
      passive-interface
    exit-af-interface

✓ HMAC-SHA-256

Algorithme plus robuste que MD5. Résiste aux attaques par collision. Disponible uniquement en named mode.

⚠️ Interop Classic ↔ Named

Un routeur en classic mode MD5 et un en named mode HMAC-SHA-256 ne peuvent pas s'authentifier mutuellement. Migrer les deux côtés en même temps.

03 GTSM — TTL Security

TTL Security en named mode

router eigrp CAMPUS
  address-family ipv4 unicast autonomous-system 100
    af-interface GigabitEthernet0/0
      ttl-security hops 1
    exit-af-interface

Même logique que pour OSPF — TTL reçu doit être ≥ 255 - hops.

04 Rotation des Clés

Rotation sans interruption d'adjacence via lifetimes

key chain EIGRP-KEYS
  key 1
    key-string AncienneClé
    accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Jun 30 2026
    send-lifetime   00:00:00 Jan 1 2026 23:59:59 Jun 30 2026
  key 2
    key-string NouvelleClé
    accept-lifetime 00:00:00 Jun 1 2026 infinite
    send-lifetime   00:00:00 Jul 1 2026 infinite

Pendant la période de chevauchement (1-30 juin), les deux clés sont acceptées — zéro interruption d'adjacence lors du changement de clé.

05 Vérification

show ip eigrp neighbors
show key chain
show eigrp address-family ipv4 interfaces detail
  → "Authentication mode is HMAC-SHA-256, key-chain is EIGRP-KEYS"

! Vérifier les erreurs d'auth
show ip eigrp traffic  → "Auth errors"
debug eigrp packets    ! temporaire seulement

BGP est le protocole le plus exposé — sessions TCP publiques, préfixes annoncés à l'échelle Internet. Sa sécurisation combine authentification MD5, GTSM, filtrage de préfixes et max-prefix.

01 Authentification MD5

Configuration — neighbor password

router bgp 65001
  neighbor 10.0.0.2 remote-as 65002
  neighbor 10.0.0.2 password MaCléBGP

Le mot de passe est intégré dans le checksum TCP MD5 (RFC 2385). La session TCP ne s'établit pas si les deux côtés n'ont pas le même mot de passe.

⚠️ MD5 sur BGP ≠ protection totale

L'auth MD5 protège contre le session hijacking mais pas contre le prefix hijacking (un AS légitime qui annonce les mauvais préfixes). Combiné avec max-prefix et prefix-list obligatoire.

02 GTSM — TTL Security

Protection contre les attaques depuis des AS distants

router bgp 65001
  ! eBGP — peer directement connecté (1 hop)
  neighbor 203.0.113.1 ttl-security hops 1

  ! iBGP via loopback (multihop nécessaire)
  neighbor 10.10.10.2 ttl-security hops 2

  ! eBGP multihop classique (sans GTSM)
  neighbor 203.0.113.5 ebgp-multihop 3

⚠️ ttl-security incompatible avec ebgp-multihop

ttl-security et ebgp-multihop sont mutuellement exclusifs. Pour un peer eBGP multihop, utiliser uniquement ebgp-multihop avec une valeur précise.

03 Max-Prefix — Protection contre les route bombs

Limiter les préfixes acceptés depuis un peer

router bgp 65001
  ! Coupure de session si > 1000 préfixes reçus
  neighbor 203.0.113.1 maximum-prefix 1000

  ! Warning à 80%, coupure à 100%
  neighbor 203.0.113.1 maximum-prefix 1000 80

  ! Warning seulement, pas de coupure
  neighbor 203.0.113.1 maximum-prefix 1000 80 warning-only

  ! Restart automatique après N minutes
  neighbor 203.0.113.1 maximum-prefix 1000 80 restart 5

Si la session est coupée par max-prefix, elle doit être réactivée manuellement avec clear ip bgp 203.0.113.1 (sauf avec restart).

04 Filtrage de Préfixes

Prefix-list + route-map en inbound/outbound

! Définir les préfixes autorisés en entrée (depuis le peer)
ip prefix-list PEER-IN permit 192.0.2.0/24
ip prefix-list PEER-IN permit 198.51.100.0/24

! Définir les préfixes annoncés en sortie (vers le peer)
ip prefix-list PEER-OUT permit 203.0.113.0/24

router bgp 65001
  neighbor 203.0.113.1 prefix-list PEER-IN  in
  neighbor 203.0.113.1 prefix-list PEER-OUT out

💡 Bonne pratique — BGP peer filtering

Toujours appliquer un filtre inbound et outbound sur les sessions eBGP. En inbound : whitelist des préfixes légitimes du peer. En outbound : whitelist de vos propres préfixes uniquement.

05 RPKI — Validation de l'origine des préfixes

Resource Public Key Infrastructure — RFC 6811

RPKI permet de valider cryptographiquement qu'un AS est bien autorisé à annoncer un préfixe via des ROA (Route Origin Authorization).

! Configuration du validateur RPKI (RTR protocol)
router bgp 65001
  bgp rpki server tcp 192.168.1.100 port 3323 refresh 600

! Politique de validation
router bgp 65001
  bgp bestpath prefix-validate allow-invalid  ! accepter les invalides (logging)
  ! ou
  bgp bestpath prefix-validate disable         ! désactiver la validation

! Vérification
show bgp ipv4 unicast 192.0.2.0/24
  → "rpki validation-state: valid"
show bgp rpki servers
show bgp rpki table

ValidPréfixe annoncé par l'AS autorisé dans le ROA

InvalidAS origin ≠ ROA — probable hijacking

Not foundPas de ROA — ni valide ni invalide

06 Vérification

show ip bgp neighbors 203.0.113.1
  → "BGP MD5 password configured"
  → "TTL security: enabled, 1 hops"
  → "Maximum prefixes: 1000 80%"

show ip bgp summary
show ip prefix-list
show bgp rpki servers

IS-IS transporte ses PDU directement sur la couche 2 (non routables), ce qui le rend naturellement moins exposé que les protocoles IP. L'authentification reste néanmoins essentielle en environnement CCIE.

01 Niveaux d'authentification IS-IS

Niveau	PDU concernés	Usage
Interface	IIH (Hello)	Authentifie la formation d'adjacence
Area (L1)	L1 LSP, CSNP, PSNP	Authentifie l'échange de la LSDB intra-area
Domain (L2)	L2 LSP, CSNP, PSNP	Authentifie l'échange de la LSDB inter-area

Pour une protection complète, les trois niveaux doivent être configurés.

02 Authentification MD5 — Key Chain

Étape 1 — Définir la key chain

key chain ISIS-KEYS
  key 1
    key-string MaCleISIS
    cryptographic-algorithm hmac-md5

Étape 2 — Authentification des LSP (area et domain)

router isis CORE
  ! Authentification area (L1)
  authentication mode md5 level-1
  authentication key-chain ISIS-KEYS level-1

  ! Authentification domain (L2)
  authentication mode md5 level-2
  authentication key-chain ISIS-KEYS level-2

Étape 3 — Authentification des Hellos (interface)

interface GigabitEthernet0/0
  isis authentication mode md5
  isis authentication key-chain ISIS-KEYS

03 Passive Interface

router isis CORE
  passive-interface Loopback0
  passive-interface GigabitEthernet0/3  ! interface accès

04 Vérification

show isis neighbors detail
  → vérifier state = UP avec auth

show isis database detail
  → LSP présents dans la LSDB

show clns interface GigabitEthernet0/0
  → "Authentication enabled"

show key chain

⚠️ Ordre de migration IS-IS

Activer l'authentification IS-IS sur tous les routeurs en même temps — ou utiliser la commande authentication send-only transitoirement pour éviter de casser les adjacences pendant la migration.