Configuration BIG-IP

BIG-IP

• (Exemple de domaine de routage 0)

Toutes les commandes ci-dessous sont exécutées dans tmsh sur BIG-IP. Adaptez les noms d’objets et les adresses IP selon vos besoins.

Pour la configuration générale des tunnels GRE sur BIG-IP, consultez Configuring a GRE Tunnel Using BIG-IP. Pour la configuration initiale du routage avec le Cloud, consultez K000147949.

tmsh

tmsh

[root@bigip:Active]# tmsh
root@(bigip)(cfg-sync Standalone)(Active)(/Common)(tmos)#

IP locales externes

Points de terminaison GRE

Ce sont les adresses IP de chaque unité BIG-IP utilisées comme points de terminaison du tunnel GRE, généralement sur le VLAN externe. Chaque unité possède sa propre IP locale externe non flottante (traffic-group-local-only) :

BIG-IP-A :

tmsh

create net self xc-ddos-v4-self-a \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_A_OUTER_V4x/24

create net self xc-ddos-v6-self-a \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_A_OUTER_V6x/64

BIG-IP-B :

tmsh

create net self xc-ddos-v4-self-b \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_B_OUTER_V4x/24

create net self xc-ddos-v6-self-b \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_B_OUTER_V6x/64

Tunnels GRE

Chaque tunnel relie une unité BIG-IP à un point de terminaison du centre d’épuration Cloud. Créez deux tunnels par unité (un vers chaque centre d’épuration géolocalisé), pour un total de quatre tunnels logiques au sein de la paire HA :

Tunnel C1-T1 — BIG-IP-A vers xCENTER_1x :

tmsh

create net tunnels tunnel xc-ddos-c1t1-v4 \
  local-address xBIGIP_A_OUTER_V4x \
  profile gre \
  remote-address xXC_C1_OUTER_V4x

create net tunnels tunnel xc-ddos-c1t1-v6 \
  local-address xBIGIP_A_OUTER_V6x \
  profile gre \
  remote-address xXC_C1_OUTER_V6x

Tunnel C2-T1 — BIG-IP-A vers xCENTER_2x :

tmsh

create net tunnels tunnel xc-ddos-c2t1-v4 \
  local-address xBIGIP_A_OUTER_V4x \
  profile gre \
  remote-address xXC_C2_OUTER_V4x

create net tunnels tunnel xc-ddos-c2t1-v6 \
  local-address xBIGIP_A_OUTER_V6x \
  profile gre \
  remote-address xXC_C2_OUTER_V6x

Tunnel C1-T2 — BIG-IP-B vers xCENTER_1x :

tmsh

create net tunnels tunnel xc-ddos-c1t2-v4 \
  local-address xBIGIP_B_OUTER_V4x \
  profile gre \
  remote-address xXC_C1_OUTER_V4x

create net tunnels tunnel xc-ddos-c1t2-v6 \
  local-address xBIGIP_B_OUTER_V6x \
  profile gre \
  remote-address xXC_C1_OUTER_V6x

Tunnel C2-T2 — BIG-IP-B vers xCENTER_2x :

tmsh

create net tunnels tunnel xc-ddos-c2t2-v4 \
  local-address xBIGIP_B_OUTER_V4x \
  profile gre \
  remote-address xXC_C2_OUTER_V4x

create net tunnels tunnel xc-ddos-c2t2-v6 \
  local-address xBIGIP_B_OUTER_V6x \
  profile gre \
  remote-address xXC_C2_OUTER_V6x

Les noms des tunnels (xc-ddos-c1t1-v4, etc.) sont arbitraires ; utilisez votre propre convention de nommage.

Définir le MTU du tunnel

L’encapsulation GRE ajoute une surcharge (24 octets pour l’en-tête externe IPv4, 44 octets pour l’en-tête externe IPv6). Sans MTU explicite, les paquets proches de 1500 octets seront fragmentés ou rejetés. Définissez le MTU du tunnel pour tenir compte de la surcharge d’encapsulation :

tmsh

modify net tunnels tunnel xc-ddos-c1t1-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c1t1-v6 mtu 1456
modify net tunnels tunnel xc-ddos-c1t2-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c1t2-v6 mtu 1456
modify net tunnels tunnel xc-ddos-c2t1-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c2t1-v6 mtu 1456
modify net tunnels tunnel xc-ddos-c2t2-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c2t2-v6 mtu 1456

MTU de chemin

Les valeurs ci-dessus supposent un MTU de chemin de 1500 octets sur le réseau externe. Ajustez si le MTU de votre chemin amont est inférieur. Assurez-vous que les messages ICMP « destination inaccessible / fragmentation nécessaire » (type 3, code 4) ne sont pas bloqués sur un équipement intermédiaire afin que la découverte du MTU de chemin (PMTUD) fonctionne correctement.

Anti-usurpation GRE (ACL amont)

GRE (protocole IP 47) ne fournit pas d’authentification. Toute personne qui connaît la paire d’IP externes peut injecter du trafic dans le tunnel. Appliquez des ACL sur le routeur ou le pare-feu amont pour restreindre le GRE entrant aux seules adresses IP source des centres d’épuration Cloud attendus :

Cisco IOS

! Example upstream router ACL (Cisco IOS style)
ip access-list extended ALLOW-XC-GRE
  permit gre host xXC_C1_OUTER_V4x host xBIGIP_A_OUTER_V4x
  permit gre host xXC_C2_OUTER_V4x host xBIGIP_A_OUTER_V4x
  permit gre host xXC_C1_OUTER_V4x host xBIGIP_B_OUTER_V4x
  permit gre host xXC_C2_OUTER_V4x host xBIGIP_B_OUTER_V4x
  deny   gre any host xBIGIP_A_OUTER_V4x log
  deny   gre any host xBIGIP_B_OUTER_V4x log

Note

Adaptez la syntaxe à votre plateforme de routeur. Le même principe s’applique aux ACL IPv6 pour les tunnels GRE IPv6. Les IP externes de BIG-IP-A (xBIGIP_A_OUTER_V4x) et de BIG-IP-B (xBIGIP_B_OUTER_V4x) doivent toutes deux être autorisées comme destinations GRE.

IP locales internes (peering BGP)

Attribuez des adresses IP internes (à l’intérieur du tunnel GRE) qui établiront la session BGP avec le Cloud. Le paramètre allow-service doit inclure tcp:179 (BGP) pour que la session de peering s’établisse. L’ajout d’icmp:any sur les IP locales internes active la PMTUD et les tests d’accessibilité à travers le tunnel :

Tunnel C1-T1 — BIG-IP-A vers xCENTER_1x :

tmsh

create net self xc-ddos-c1t1-inner-v4 \
  vlan xc-ddos-c1t1-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T1_INNER_V4x/30

create net self xc-ddos-c1t1-inner-v6 \
  vlan xc-ddos-c1t1-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T1_INNER_V6x/64

Tunnel C2-T1 — BIG-IP-A vers xCENTER_2x :

tmsh

create net self xc-ddos-c2t1-inner-v4 \
  vlan xc-ddos-c2t1-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T1_INNER_V4x/30

create net self xc-ddos-c2t1-inner-v6 \
  vlan xc-ddos-c2t1-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T1_INNER_V6x/64

Tunnel C1-T2 — BIG-IP-B vers xCENTER_1x :

tmsh

create net self xc-ddos-c1t2-inner-v4 \
  vlan xc-ddos-c1t2-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T2_INNER_V4x/30

create net self xc-ddos-c1t2-inner-v6 \
  vlan xc-ddos-c1t2-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T2_INNER_V6x/64

Tunnel C2-T2 — BIG-IP-B vers xCENTER_2x :

tmsh

create net self xc-ddos-c2t2-inner-v4 \
  vlan xc-ddos-c2t2-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T2_INNER_V4x/30

create net self xc-ddos-c2t2-inner-v6 \
  vlan xc-ddos-c2t2-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T2_INNER_V6x/64

BGP

Utilisez imish pour configurer BGP pour le domaine de routage 0.

Configuration par unité

La configuration BGP imish est locale à chaque unité BIG-IP. Chaque unité configure uniquement les voisins de ses propres tunnels :

• BIG-IP-A configure les voisins C1-T1 et C2-T1.
• BIG-IP-B configure les voisins C1-T2 et C2-T2.

Le router-id doit être unique par unité (utilisez l’IP locale externe propre à chaque unité).

1. Entrez dans imish pour le domaine de routage 0 :

   bash

   tmsh run /util imish -r 0

2. Entrez en mode privilégié et en mode de configuration :

   imish

   localhost.localdomain[0]> enable
   localhost.localdomain[0]# configure terminal

3. Exemple de configuration BGP :

Remplacer les valeurs de substitution

• xCUSTOMER_ASNx — votre ASN public enregistré auprès de l’ARIN (ou d’un RIR équivalent). Un ASN public est obligatoire pour le DDoS routé, car le Cloud annoncera vos préfixes à l’échelle mondiale. Un ASN privé (64512-65534 / 4200000000-4294967294) n’est acceptable que si le SOC prend explicitement en charge le peering avec ASN privé pour votre déploiement.
• xF5_XC_ASNx — ASN Cloud (fourni par le SOC).
• xBGP_PASSWORDx — le mot de passe BGP MD5 convenu (ou correspondant au « secret par défaut » de la Console). Ne réutilisez jamais ce mot de passe pour d’autres services.

BIG-IP-A (router-id xBIGIP_A_OUTER_V4x, voisins C1-T1 + C2-T1) :

imish

router bgp xCUSTOMER_ASNx
  no synchronization
  bgp log-neighbor-changes
  no auto-summary
  bgp router-id xBIGIP_A_OUTER_V4x
  bgp graceful-restart restart-time 120
  redistribute kernel route-map route-to-cloud-ipv4

  neighbor cloud peer-group
  neighbor cloud remote-as xF5_XC_ASNx
  neighbor cloud description cloud-peer-group
  neighbor cloud password xBGP_PASSWORDx
  neighbor cloud timers 10 30
  neighbor cloud soft-reconfiguration inbound
  neighbor cloud version 4
  neighbor cloud capability graceful-restart
  neighbor cloud send-community
  neighbor cloud ttl-security hops 1
  neighbor cloud maximum-prefix 10 warning-only
  neighbor cloud prefix-list deny-all in
  neighbor cloud prefix-list route-to-cloud-ipv4 out

  neighbor xXC_C1_T1_INNER_V4x peer-group cloud
  neighbor xXC_C1_T1_INNER_V4x description cloud-c1-t1-v4

  neighbor xXC_C2_T1_INNER_V4x peer-group cloud
  neighbor xXC_C2_T1_INNER_V4x description cloud-c2-t1-v4

  address-family ipv6
    redistribute kernel route-map route-to-cloud-ipv6
    neighbor cloud activate
    neighbor cloud soft-reconfiguration inbound
    neighbor cloud capability graceful-restart
    neighbor cloud prefix-list deny-all6 in
    neighbor cloud prefix-list route-to-cloud-ipv6 out
    neighbor xXC_C1_T1_INNER_V6x peer-group cloud
    neighbor xXC_C1_T1_INNER_V6x description cloud-c1-t1-v6
    neighbor xXC_C2_T1_INNER_V6x peer-group cloud
    neighbor xXC_C2_T1_INNER_V6x description cloud-c2-t1-v6
  exit-address-family

ip prefix-list deny-all deny 0.0.0.0/0 le 32
ip prefix-list route-to-cloud-ipv4 permit xPROTECTED_PREFIX_V4x

ipv6 prefix-list deny-all6 deny ::/0 le 128
ipv6 prefix-list route-to-cloud-ipv6 permit xPROTECTED_PREFIX_V6x

ip route xPROTECTED_NET_V4x xPROTECTED_MASK_V4x null0 201
ipv6 route xPROTECTED_PREFIX_V6x null0 201

route-map route-to-cloud-ipv4 permit 10
  match ip address prefix-list route-to-cloud-ipv4
  set origin igp

route-map route-to-cloud-ipv6 permit 10
  match ipv6 address prefix-list route-to-cloud-ipv6
  set origin igp

BIG-IP-B (router-id xBIGIP_B_OUTER_V4x, voisins C1-T2 + C2-T2) :

imish

router bgp xCUSTOMER_ASNx
  no synchronization
  bgp log-neighbor-changes
  no auto-summary
  bgp router-id xBIGIP_B_OUTER_V4x
  bgp graceful-restart restart-time 120
  redistribute kernel route-map route-to-cloud-ipv4

  neighbor cloud peer-group
  neighbor cloud remote-as xF5_XC_ASNx
  neighbor cloud description cloud-peer-group
  neighbor cloud password xBGP_PASSWORDx
  neighbor cloud timers 10 30
  neighbor cloud soft-reconfiguration inbound
  neighbor cloud version 4
  neighbor cloud capability graceful-restart
  neighbor cloud send-community
  neighbor cloud ttl-security hops 1
  neighbor cloud maximum-prefix 10 warning-only
  neighbor cloud prefix-list deny-all in
  neighbor cloud prefix-list route-to-cloud-ipv4 out

  neighbor xXC_C1_T2_INNER_V4x peer-group cloud
  neighbor xXC_C1_T2_INNER_V4x description cloud-c1-t2-v4

  neighbor xXC_C2_T2_INNER_V4x peer-group cloud
  neighbor xXC_C2_T2_INNER_V4x description cloud-c2-t2-v4

  address-family ipv6
    redistribute kernel route-map route-to-cloud-ipv6
    neighbor cloud activate
    neighbor cloud soft-reconfiguration inbound
    neighbor cloud capability graceful-restart
    neighbor cloud prefix-list deny-all6 in
    neighbor cloud prefix-list route-to-cloud-ipv6 out
    neighbor xXC_C1_T2_INNER_V6x peer-group cloud
    neighbor xXC_C1_T2_INNER_V6x description cloud-c1-t2-v6
    neighbor xXC_C2_T2_INNER_V6x peer-group cloud
    neighbor xXC_C2_T2_INNER_V6x description cloud-c2-t2-v6
  exit-address-family

ip prefix-list deny-all deny 0.0.0.0/0 le 32
ip prefix-list route-to-cloud-ipv4 permit xPROTECTED_PREFIX_V4x

ipv6 prefix-list deny-all6 deny ::/0 le 128
ipv6 prefix-list route-to-cloud-ipv6 permit xPROTECTED_PREFIX_V6x

ip route xPROTECTED_NET_V4x xPROTECTED_MASK_V4x null0 201
ipv6 route xPROTECTED_PREFIX_V6x null0 201

route-map route-to-cloud-ipv4 permit 10
  match ip address prefix-list route-to-cloud-ipv4
  set origin igp

route-map route-to-cloud-ipv6 permit 10
  match ipv6 address prefix-list route-to-cloud-ipv6
  set origin igp

Explication des paramètres BGP clés :

• timers 10 30 — Keepalive toutes les 10 s, durée de maintien de 30 s. La valeur par défaut (60 / 180) est trop lente pour le basculement lors d’une mitigation DDoS. Coordonnez les valeurs des minuteries avec le SOC afin qu’elles correspondent des deux côtés.
• ttl-security hops 1 — Active GTSM (RFC 5082). Étant donné que les sessions BGP sont en saut unique sur le tunnel GRE, cela empêche l’usurpation BGP distante en exigeant un TTL = 255 sur les paquets BGP entrants.
• maximum-prefix 10 warning-only — Mesure de défense en profondeur. Même si la liste de préfixes entrants refuse toutes les routes, cela génère un avertissement si le pair envoie des préfixes de manière inattendue.
• redistribute kernel — Injecte les routes statiques null0 dans BGP via la route-map. Une alternative consiste à utiliser des instructions network explicites (ex. network xPROTECTED_PREFIX_V4x), qui sont plus précises car seul le préfixe exact est annoncé indépendamment des autres routes du noyau. Les deux approches fonctionnent ; redistribute kernel avec une route-map stricte est présenté ici pour plus de flexibilité.

BFD (Bidirectional Forwarding Detection)

Si votre version de BIG-IP prend en charge BFD sur les tunnels GRE, activez-le pour une détection de défaillance en moins d’une seconde :

neighbor cloud fall-over bfd

BFD offre une convergence plus rapide que les seuls minuteries keepalive BGP. Confirmez la prise en charge de BFD avec votre version de BIG-IP et le SOC avant l’activation.

Les routes statiques null0 avec une distance administrative plus élevée (201) garantissent que les préfixes existent dans la table de routage du noyau, afin qu’ils puissent être redistribués vers le Cloud via BGP sans affecter le routage normal en dehors des conditions d’attaque. Si le préfixe protégé existe déjà dans la table de routage provenant d’une autre source avec une distance administrative inférieure, la route null0 ne sera pas active et la redistribution pourra échouer — vérifiez avec show ip route après la configuration.