Guide complet débutant → professionnel — Cisco ASA 5500-X · Firepower FTD · FMC · AnyConnect · IPS Snort 3

Table des matières

Partie 1 — Cisco ASA

Introduction & modèles ASA
Premiers pas : CLI & ASDM
Interfaces & niveaux de sécurité
NAT & PAT sur ASA
ACL & politique de sécurité
VPN Site-à-Site & AnyConnect
Haute disponibilité Active/Standby

Partie 2 — Migration ASA → FTD

ASA vs FTD — Différences fondamentales
Processus de migration

Partie 3 — Cisco Firepower FTD

Architecture FMC + FTD
Politiques de contrôle d’accès (ACP)
IDS/IPS avec Snort 3
VPN sur FTD
Supervision & événements

Partie 4 — Configuration avancée & sécurisation

Object-groups & objets nommés
Logging avancé & syslog
AAA & authentification RADIUS / Active Directory
Inspection applicative — Modular Policy Framework (MPF)
Gestion des certificats & PKI pour AnyConnect
Troubleshooting — diagnostics concrets
Plan d’adressage IP — réseau d’entreprise multi-sites
Durcissement (Hardening) — Cisco ASA & FTD
SSL/TLS Decryption Policy (FTD)
File Policy & AMP — blocage de malware (FTD)
Identity Policy & Cisco ISE (FTD)
Haute disponibilité FTD (Active/Standby)

PARTIE 1 — CISCO ASA

1. Introduction & modèles ASA

Le Cisco ASA (Adaptive Security Appliance) est le firewall physique le plus déployé en entreprise depuis plus de 15 ans. Il combine firewall stateful, VPN concentrateur et protection applicative dans un seul équipement.

Gamme ASA 5500-X

Modèle	Débit FW	Sessions	Contextes	Cible
ASA 5506-X	750 Mbps	50 000	2	TPE / Agences
ASA 5508-X	1 Gbps	100 000	2	PME
ASA 5516-X	1,8 Gbps	250 000	2	PME+
ASA 5525-X	2 Gbps	500 000	20	Entreprise
ASA 5545-X	3 Gbps	750 000	50	Entreprise
ASA 5555-X	4 Gbps	1 000 000	100	Grande entreprise

ℹ️ Info — Les modèles 5500-X supportent le module FirePOWER Services (SFR) permettant d’activer les fonctions IPS/IDS sans remplacer l’équipement. C’est souvent le premier pas vers FTD.

Fig. 1.1 — Architecture réseau d’entreprise avec Cisco ASA en border firewall

2. Premiers pas : CLI & ASDM

L’ASA se configure via deux interfaces : la CLI (ligne de commande, recommandée en production) et ASDM (interface graphique Java, pratique pour les débutants).

Accès initial console

! Connexion série console (9600 baud, 8N1)
! Login par défaut : pas de mot de passe

ciscoasa> enable
Password: (vide par défaut)
ciscoasa# configure terminal
ciscoasa(config)#

Hiérarchie des modes CLI

ciscoasa>              ← Mode User EXEC (lecture seule)
ciscoasa# enable       ← Mode Privileged EXEC
ciscoasa# conf t       ← Mode Global Configuration
ciscoasa(config-if)#   ← Mode Interface
ciscoasa(config-crypto-map)# ← Mode sous-configuration

Configuration de base indispensable

! Nom d'hôte et domaine
ciscoasa(config)# hostname FW-PARIS-01
ciscoasa(config)# domain-name entreprise.local

! Mot de passe enable chiffré
ciscoasa(config)# enable password C1sc0S3cur3! encrypted

! Utilisateur local avec privilèges
ciscoasa(config)# username admin privilege 15 password C1sc0@dmin!

! Désactiver HTTP, activer HTTPS pour ASDM
ciscoasa(config)# http server enable
ciscoasa(config)# http 192.168.1.0 255.255.255.0 inside
ciscoasa(config)# no http server enable  ! désactiver HTTP clear

! SSH sur interface management
ciscoasa(config)# crypto key generate rsa modulus 2048
ciscoasa(config)# ssh 192.168.1.0 255.255.255.0 inside
ciscoasa(config)# ssh version 2
ciscoasa(config)# aaa authentication ssh console LOCAL

! NTP
ciscoasa(config)# ntp server 192.168.1.10 source inside

! Sauvegarde
ciscoasa# write memory

⚠️ Attention — Ne jamais laisser le mot de passe enable vide en production. Configurer SSH v2 uniquement — SSHv1 est vulnérable.

Fig. 2.1 — Hiérarchie des modes CLI Cisco ASA

3. Interfaces & niveaux de sécurité

Le concept fondamental de l’ASA est le security-level (0 à 100). Par défaut, le trafic circule librement du niveau haut vers le niveau bas, et est bloqué dans l’autre sens.

Règle des security-levels

Security-level 100 (Inside)  →  Peut accéder à 50 et 0  ✓
Security-level 50  (DMZ)     →  Peut accéder à 0         ✓
Security-level 0   (Outside) →  Ne peut accéder à rien    ✗

Configuration des interfaces

! Interface Outside (WAN)
FW-PARIS-01(config)# interface GigabitEthernet0/0
FW-PARIS-01(config-if)# nameif outside
FW-PARIS-01(config-if)# security-level 0
FW-PARIS-01(config-if)# ip address 203.0.113.1 255.255.255.252
FW-PARIS-01(config-if)# no shutdown
FW-PARIS-01(config-if)# description "Liaison FAI"

! Interface Inside (LAN)
FW-PARIS-01(config)# interface GigabitEthernet0/1
FW-PARIS-01(config-if)# nameif inside
FW-PARIS-01(config-if)# security-level 100
FW-PARIS-01(config-if)# ip address 192.168.1.1 255.255.255.0
FW-PARIS-01(config-if)# no shutdown

! Interface DMZ
FW-PARIS-01(config)# interface GigabitEthernet0/2
FW-PARIS-01(config-if)# nameif dmz
FW-PARIS-01(config-if)# security-level 50
FW-PARIS-01(config-if)# ip address 10.0.10.1 255.255.255.0
FW-PARIS-01(config-if)# no shutdown

! Vérification
FW-PARIS-01# show interface ip brief
FW-PARIS-01# show nameif

ℹ️ Info — Si deux interfaces ont le même security-level, le trafic entre elles est bloqué par défaut. Utiliser same-security-traffic permit inter-interface pour l’autoriser si nécessaire.

Fig. 3.1 — Logique des security-levels : flux autorisés et bloqués par défaut

4. NAT & PAT sur ASA

L’ASA supporte plusieurs types de NAT. En entreprise, on utilise principalement le PAT dynamique (overload) pour l’accès Internet et le NAT statique pour les serveurs en DMZ.

NAT dynamique (PAT) — Inside vers Internet

! Définir l'objet réseau LAN
FW-PARIS-01(config)# object network LAN_INSIDE
FW-PARIS-01(config-network-object)# subnet 192.168.1.0 255.255.255.0
FW-PARIS-01(config-network-object)# nat (inside,outside) dynamic interface

! Même chose pour les serveurs internes
FW-PARIS-01(config)# object network SERVERS
FW-PARIS-01(config-network-object)# subnet 10.0.20.0 255.255.255.0
FW-PARIS-01(config-network-object)# nat (inside,outside) dynamic interface

NAT statique — Serveur Web en DMZ

! Exposer un serveur web DMZ sur l'IP publique port 443
FW-PARIS-01(config)# object network WEB_SERVER_DMZ
FW-PARIS-01(config-network-object)# host 10.0.10.10
FW-PARIS-01(config-network-object)# nat (dmz,outside) static 203.0.113.5

! NAT statique port forwarding (port 443 uniquement)
FW-PARIS-01(config)# object network WEB_HTTPS
FW-PARIS-01(config-network-object)# host 10.0.10.10
FW-PARIS-01(config-network-object)# nat (dmz,outside) static 203.0.113.5 service tcp 443 443

! Vérification
FW-PARIS-01# show nat
FW-PARIS-01# show xlate

ℹ️ Info — Sur ASA 8.3+, la syntaxe NAT a changé (object-based NAT). Les commandes ci-dessus sont valables pour ASA 8.3 et supérieur — vérifiez votre version avec show version.

5. ACL & politique de sécurité

Les ACL sur ASA filtrent le trafic entrant sur une interface. Elles complètent les security-levels pour un contrôle granulaire.

Création d’ACL

! ACL pour autoriser HTTPS depuis Internet vers serveur DMZ
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 203.0.113.5 eq 443
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 203.0.113.5 eq 80

! Autoriser VPN AnyConnect entrant
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit udp any host 203.0.113.1 eq 443

! Bloquer explicitement le reste (implicite mais bonne pratique de logger)
FW-PARIS-01(config)# access-list OUTSIDE_IN extended deny ip any any log

! Appliquer l'ACL sur l'interface outside (sens entrant)
FW-PARIS-01(config)# access-group OUTSIDE_IN in interface outside

ACL entre DMZ et Inside

! Autoriser le serveur web DMZ à contacter la DB interne
FW-PARIS-01(config)# access-list DMZ_TO_INSIDE extended permit tcp host 10.0.10.10 host 10.0.20.5 eq 3306
FW-PARIS-01(config)# access-list DMZ_TO_INSIDE extended deny ip any any log
FW-PARIS-01(config)# access-group DMZ_TO_INSIDE in interface dmz

! Vérification
FW-PARIS-01# show access-list
FW-PARIS-01# show access-list OUTSIDE_IN

🔐 Sécurité — Toujours terminer une ACL par un deny ip any any log explicite. Cela permet de logger les paquets bloqués, indispensable pour l’audit et la détection d’incidents.

Fig. 5.1 — Logique de traitement des ACL sur interface Outside

6. VPN Site-à-Site & AnyConnect

L’ASA est un excellent concentrateur VPN. Il supporte IPsec site-à-site pour relier les sites entre eux et AnyConnect SSL VPN pour le télétravail.

IPsec Site-à-Site (IKEv2)

! Phase 1 — IKEv2 Policy
FW-PARIS-01(config)# crypto ikev2 policy 10
FW-PARIS-01(config-ikev2-policy)# encryption aes-256
FW-PARIS-01(config-ikev2-policy)# integrity sha256
FW-PARIS-01(config-ikev2-policy)# group 14
FW-PARIS-01(config-ikev2-policy)# prf sha256
FW-PARIS-01(config-ikev2-policy)# lifetime seconds 86400

! Phase 2 — IPsec Transform Set
FW-PARIS-01(config)# crypto ipsec ikev2 ipsec-proposal PROP-AES256
FW-PARIS-01(config-ipsec-proposal)# protocol esp encryption aes-256
FW-PARIS-01(config-ipsec-proposal)# protocol esp integrity sha-256

! Crypto Map
FW-PARIS-01(config)# crypto map VPN_MAP 10 match address ACL_VPN_LYON
FW-PARIS-01(config)# crypto map VPN_MAP 10 set peer 198.51.100.1
FW-PARIS-01(config)# crypto map VPN_MAP 10 set ikev2 ipsec-proposal PROP-AES256
FW-PARIS-01(config)# crypto map VPN_MAP interface outside

! ACL trafic intéressant (Paris ↔ Lyon)
FW-PARIS-01(config)# access-list ACL_VPN_LYON extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

! Activer IKEv2 sur outside
FW-PARIS-01(config)# crypto ikev2 enable outside

! Vérification
FW-PARIS-01# show crypto ikev2 sa
FW-PARIS-01# show crypto ipsec sa

AnyConnect SSL VPN (Télétravail)

! Pool d'adresses pour les clients VPN
FW-PARIS-01(config)# ip local pool VPN_POOL 172.16.10.1-172.16.10.254 mask 255.255.255.0

! Activer AnyConnect
FW-PARIS-01(config)# webvpn
FW-PARIS-01(config-webvpn)# enable outside
FW-PARIS-01(config-webvpn)# anyconnect image disk0:/anyconnect-win-4.x.pkg 1
FW-PARIS-01(config-webvpn)# anyconnect enable

! Group policy
FW-PARIS-01(config)# group-policy GP_ANYCONNECT internal
FW-PARIS-01(config-group-policy)# vpn-tunnel-protocol ssl-client
FW-PARIS-01(config-group-policy)# split-tunnel-policy tunnelspecified
FW-PARIS-01(config-group-policy)# split-tunnel-network-list value ACL_SPLIT

! Tunnel group
FW-PARIS-01(config)# tunnel-group ANYCONNECT_USERS type remote-access
FW-PARIS-01(config-tunnel-general)# address-pool VPN_POOL
FW-PARIS-01(config-tunnel-general)# default-group-policy GP_ANYCONNECT

! Vérification
FW-PARIS-01# show vpn-sessiondb anyconnect

ℹ️ Info — Le split tunneling permet aux clients VPN d’envoyer uniquement le trafic destiné au réseau interne dans le tunnel, le reste va directement sur Internet. Cela réduit la charge sur le firewall mais diminue le contrôle de sécurité.

Fig. 6.1 — Architecture VPN ASA : IPsec site-à-site + AnyConnect télétravail

7. Haute disponibilité Active/Standby

En production, l’ASA se déploie toujours en paire Active/Standby. En cas de panne du nœud actif, le standby prend le relais en moins de 30 secondes avec les mêmes sessions actives.

Prérequis HA

2 ASA identiques (même modèle, même version IOS)
Un câble Failover dédié (Gi0/3 recommandé)
IPs distinctes par nœud + IP virtuelle partagée (comme CARP sur pfSense)

Configuration Active (nœud principal)

! Activer le failover
FW-PARIS-01(config)# failover
FW-PARIS-01(config)# failover lan unit primary
FW-PARIS-01(config)# failover lan interface FAILOVER GigabitEthernet0/3
FW-PARIS-01(config)# failover lan enable
FW-PARIS-01(config)# failover key cisco123secure

! IPs de failover
FW-PARIS-01(config)# failover interface ip FAILOVER 10.255.255.1 255.255.255.252 standby 10.255.255.2

! IPs standby pour chaque interface
FW-PARIS-01(config)# interface GigabitEthernet0/0
FW-PARIS-01(config-if)# ip address 203.0.113.1 255.255.255.252 standby 203.0.113.2
FW-PARIS-01(config)# interface GigabitEthernet0/1
FW-PARIS-01(config-if)# ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2

Configuration Standby (nœud secondaire)

! Sur le nœud secondaire — configuration minimale
FW-PARIS-02(config)# failover lan unit secondary
FW-PARIS-02(config)# failover lan interface FAILOVER GigabitEthernet0/3
FW-PARIS-02(config)# failover lan enable
FW-PARIS-02(config)# failover key cisco123secure
! Le reste de la config est synchronisé automatiquement depuis le primaire

! Vérification HA
FW-PARIS-01# show failover
FW-PARIS-01# show failover state
! Forcer un basculement (test)
FW-PARIS-01# no failover active

✅ Bon à savoir — En mode Active/Active, les deux ASA traitent du trafic simultanément (nécessite plusieurs contextes). En Active/Standby, un seul traite le trafic — plus simple à opérer et recommandé pour la majorité des entreprises.

Fig. 7.1 — Architecture HA ASA Active/Standby avec synchronisation des états

PARTIE 2 — MIGRATION ASA → FTD

8. ASA vs FTD — Différences fondamentales

La migration d’ASA vers FTD (Firepower Threat Defense) est un changement de paradigme important. FTD unifie ASA et FirePOWER Services dans un seul OS managé via FMC (Firepower Management Center).

Critère	Cisco ASA	Cisco FTD
Gestion	CLI / ASDM	FMC (centralisé) ou FDM (local)
Politique firewall	ACL par interface	ACP (Access Control Policy)
Inspection	Stateful basique	NGFW — DPI, App-ID, URL filtering
IPS	Module SFR optionnel	Snort 3 intégré natif
VPN	CLI complet	Supporté mais moins flexible
NAT	Très flexible (CLI)	Supporté via FMC
Logging	Syslog / ASDM	FMC + Syslog + eStreamer
Contextes multiples	Oui (multi-context)	Non (single context)
Courbe d’apprentissage	Moyenne	Plus élevée (FMC)

⚠️ Point critique — FTD ne supporte pas toutes les fonctionnalités ASA. Les contextes multiples, certaines options NAT avancées et quelques fonctionnalités VPN ne sont pas disponibles sur FTD. Auditer la config ASA avant toute migration.

Fig. 8.1 — Comparaison architecturale ASA vs FTD

9. Processus de migration

Cisco fournit un outil officiel gratuit : Cisco Firepower Migration Tool (FMT) qui automatise la conversion des configs ASA vers FTD.

Étapes de migration

Audit — Inventorier les fonctionnalités ASA utilisées (contextes, VPN, NAT avancé)
Export — Exporter la config ASA : more system:running-config > tftp://...
Analyse — Utiliser le FMT pour analyser les incompatibilités
Conversion — Le FMT génère les objets, ACL et politiques FTD équivalents
Import — Importer dans FMC et valider manuellement
Test — Valider en environnement de préproduction
Bascule — Migrer en production avec plan de rollback

! Fonctionnalités ASA NON supportées sur FTD (à traiter manuellement)
- Multi-context mode
- Botnet Traffic Filter
- Unified Communications (Phone Proxy)
- Certain NAT hairpinning configs
- TLS proxy
- IOS-based VPN (EasyVPN, DMVPN)

⚠️ Attention — Toujours prévoir un plan de rollback avec la config ASA sauvegardée. Une migration FTD ratée en prod peut couper l’accès Internet de toute l’entreprise.

PARTIE 3 — CISCO FIREPOWER FTD

10. Architecture FMC + FTD

Le FMC (Firepower Management Center) est le cerveau centralisé qui gère un ou plusieurs équipements FTD. Il fournit les politiques de sécurité, les mises à jour de signatures et la visibilité réseau.

Déploiement FMC

! FMC est un appliance physique ou virtuel (VMware/KVM)
! Modèles physiques : FMC 1000, FMC 2500, FMC 4500
! FMC virtuel : FMCv (jusqu'à 25 FTD managés)

! Accès initial FMC
URL: https://<IP_FMC>
Login: admin
Password: Admin123 (à changer immédiatement)

! Enregistrer un FTD dans FMC
Sur le FTD (CLI) :
> configure manager add <IP_FMC> <clé_registration> <IP_FTD>

Sur FMC : Devices > Device Management > Add Device
- Host: <IP_FTD>
- Registration Key: <même clé>
- Group: Production

Fig. 10.1 — Architecture FMC centralisé gérant plusieurs FTD multi-sites

11. Politiques de contrôle d’accès (ACP)

L’Access Control Policy remplace les ACL de l’ASA. Elle est bien plus puissante : elle peut filtrer par application, utilisateur, URL, géolocalisation en plus des IPs et ports classiques.

Structure d’une ACP

FMC > Policies > Access Control > New Policy

Nom: ACP_ENTREPRISE
Default Action: Block All Traffic (recommandé)

! Règles (ordre = priorité)
Rule 1: Allow_HTTPS_Outbound
  - Source: LAN_NETWORKS
  - Destination: Any
  - Application: SSL, HTTP
  - Action: Allow + Log

Rule 2: Allow_DNS
  - Source: LAN_NETWORKS
  - Destination: DNS_SERVERS
  - Port: DNS (53)
  - Action: Allow

Rule 3: Allow_VPN_AnyConnect
  - Source: Any
  - Destination: FTD_OUTSIDE_IP
  - Port: HTTPS (443)
  - Action: Allow

Rule 4: DMZ_to_DB
  - Source: WEB_SERVER_DMZ
  - Destination: DB_SERVER
  - Port: MySQL (3306)
  - Action: Allow + IPS Inspection

! Default: Block All (log)

ℹ️ Info — Contrairement aux ACL ASA, les règles ACP peuvent embarquer de l’inspection IPS (Snort), du filtrage URL et de l’identification applicative directement dans la règle. C’est la force du NGFW.

12. IDS/IPS avec Snort 3

FTD intègre Snort 3 nativement, le moteur IPS open-source le plus utilisé au monde. Il analyse le trafic en profondeur et peut bloquer les attaques en temps réel.

Configuration d’une politique IPS

FMC > Policies > Intrusion > Create Policy

Nom: IPS_ENTREPRISE
Base Policy: Balanced Security and Connectivity
  (Connectivity over Security = moins de faux-positifs)
  (Security over Connectivity = plus strict)

! Activer dans une règle ACP
Rule > Inspection Tab:
  Intrusion Policy: IPS_ENTREPRISE
  Variable Set: Default-Set (adapter les $HOME_NET)

Variables critiques à configurer

FMC > Objects > Object Management > Variable Sets

$HOME_NET     = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
$EXTERNAL_NET = !$HOME_NET
$HTTP_SERVERS = 10.0.10.0/24  (serveurs DMZ)
$SQL_SERVERS  = 10.0.20.5/32  (serveur DB)
$DNS_SERVERS  = 192.168.1.10/32

⚠️ Attention — Comme pour Suricata sur pfSense, commencer en mode Detect Only (IDS) avant de passer en Inline (IPS bloquant). Analyser les faux-positifs pendant 2 semaines minimum avant d’activer le blocage.

Fig. 12.1 — Pipeline d’inspection Snort 3 intégré dans FTD

13. VPN sur FTD

FTD supporte les VPN Site-à-Site IKEv2 et AnyConnect Remote Access configurables via FMC.

VPN Site-à-Site via FMC

FMC > Devices > VPN > Site To Site > + Topology

Nom: VPN_PARIS_LYON
Type: Point to Point
IKE Version: IKEv2

Endpoint A: FTD-PARIS
  - Interface: Outside
  - IP: 203.0.113.1
  - Network: 192.168.1.0/24

Endpoint B: FTD-LYON (ou équipement tiers)
  - IP: 198.51.100.1
  - Network: 192.168.2.0/24

! IKEv2 Settings
Encryption: AES-256
Integrity: SHA-256
PRF: SHA-256
DH Group: 14

! IPsec Settings
Encryption: AES-256-GCM
PFS: Group 14

AnyConnect Remote Access VPN

FMC > Devices > VPN > Remote Access > + New

! Connection Profile
Name: ANYCONNECT_ENTERPRISE
Protocol: SSL + IKEv2

! AAA — Authentification
Authentication: RADIUS / AD via ISE
  (ou certificat PKI pour MFA)

! Address Pool
IPv4 Pool: 172.16.10.0/24

! Split Tunneling
Traffic destined to: 192.168.0.0/16, 10.0.0.0/8
  → Tunnel
Reste → Internet direct

! Déployer sur FTD-PARIS
Deploy > FTD-PARIS-01

ℹ️ Info — Pour une sécurité maximale, combiner AnyConnect avec Cisco ISE (Identity Services Engine) pour l’authentification MFA et le contrôle de posture (vérifier que le PC est à jour avant d’autoriser la connexion VPN).

14. Supervision & événements

FMC centralise tous les événements de sécurité. Pour une supervision complète en entreprise, coupler FMC avec un SIEM externe.

Tableaux de bord FMC essentiels

FMC > Overview > Dashboards
  - Summary Dashboard     : vue globale trafic + événements
  - Network Dashboard     : top talkers, protocoles, géo
  - Threat Dashboard      : intrusions, malware, IOC

FMC > Analysis > Connections > Events
  → Filtrer : Action = Block, dernières 24h
  → Export CSV pour analyse SIEM

FMC > Analysis > Intrusions > Events
  → Trier par Impact Flag (1 = critique)
  → Corrélation avec adresses internes

Export Syslog vers SIEM

FMC > System > Logging > Syslog Servers
  - IP: 10.0.10.50 (SIEM / Graylog)
  - Port: 514 UDP
  - Facility: LOCAL4

! Activer les logs sur les règles ACP
Rule > Logging:
  Log at Beginning: Yes
  Log at End: Yes
  Send Connection Events to: Syslog

Fig. 14.1 — Écosystème de supervision FMC : SIEM, Talos, alertes et corrélation multi-sites

15. Object-groups & objets nommés

Pourquoi c’est indispensable ?

Imaginez qu’on vous demande de trouver et modifier la règle qui autorise l’accès au serveur de paie dans une ACL de 200 lignes remplies d’adresses IP brutes comme 10.0.20.47. Impossible à lire, impossible à auditer, et la moindre erreur de frappe peut ouvrir un trou de sécurité.

Les object-groups sont la solution : on donne un nom lisible à chaque IP, réseau ou port, puis on écrit les ACL avec ces noms. Résultat : une règle qui dit permit tcp any DMZ_SERVERS WEB_PORTS se comprend immédiatement, même six mois plus tard.

Étape 1 — Créer les objets individuels (hosts & subnets)

On commence par déclarer chaque serveur et réseau qui compte dans notre infrastructure. À faire une seule fois, avant d’écrire la moindre ACL.

! ── SERVEURS DMZ ──────────────────────────────────────────
FW-PARIS-01(config)# object network WEB_SERVER
FW-PARIS-01(config-network-object)# host 10.0.10.10
FW-PARIS-01(config-network-object)# description "Serveur web Apache - DMZ Paris"

FW-PARIS-01(config)# object network MAIL_SERVER
FW-PARIS-01(config-network-object)# host 10.0.10.11
FW-PARIS-01(config-network-object)# description "Serveur mail Postfix - DMZ Paris"

FW-PARIS-01(config)# object network DNS_SERVER_DMZ
FW-PARIS-01(config-network-object)# host 10.0.10.12
FW-PARIS-01(config-network-object)# description "DNS public - DMZ Paris"

! ── SERVEURS INTERNES ────────────────────────────────────
FW-PARIS-01(config)# object network DB_SERVER
FW-PARIS-01(config-network-object)# host 10.0.20.5
FW-PARIS-01(config-network-object)# description "Serveur MySQL - LAN interne"

FW-PARIS-01(config)# object network AD_SERVER
FW-PARIS-01(config-network-object)# host 192.168.1.10
FW-PARIS-01(config-network-object)# description "Controleur de domaine AD"

FW-PARIS-01(config)# object network RADIUS_PRIMARY
FW-PARIS-01(config-network-object)# host 192.168.1.50
FW-PARIS-01(config-network-object)# description "Serveur NPS/RADIUS principal"

! ── RÉSEAUX (SUBNETS) ────────────────────────────────────
FW-PARIS-01(config)# object network LAN_PARIS
FW-PARIS-01(config-network-object)# subnet 192.168.1.0 255.255.255.0
FW-PARIS-01(config-network-object)# description "LAN utilisateurs Paris"

FW-PARIS-01(config)# object network LAN_LYON
FW-PARIS-01(config-network-object)# subnet 192.168.2.0 255.255.255.0
FW-PARIS-01(config-network-object)# description "LAN utilisateurs Lyon"

FW-PARIS-01(config)# object network DMZ_SUBNET
FW-PARIS-01(config-network-object)# subnet 10.0.10.0 255.255.255.0
FW-PARIS-01(config-network-object)# description "Zone DMZ Paris"

Étape 2 — Créer les objets service (ports)

! Ports web
FW-PARIS-01(config)# object service HTTP
FW-PARIS-01(config-service-object)# service tcp destination eq 80

FW-PARIS-01(config)# object service HTTPS
FW-PARIS-01(config-service-object)# service tcp destination eq 443

FW-PARIS-01(config)# object service SMTP
FW-PARIS-01(config-service-object)# service tcp destination eq 25

FW-PARIS-01(config)# object service SMTPS
FW-PARIS-01(config-service-object)# service tcp destination eq 465

FW-PARIS-01(config)# object service MYSQL_PORT
FW-PARIS-01(config-service-object)# service tcp destination eq 3306

FW-PARIS-01(config)# object service RDP
FW-PARIS-01(config-service-object)# service tcp destination eq 3389

Étape 3 — Regrouper en object-groups

Un object-group rassemble plusieurs objets du même type sous un seul nom. C’est ici que la magie opère.

! ── GROUPE : tous les serveurs exposés en DMZ ────────────
FW-PARIS-01(config)# object-group network DMZ_SERVERS
FW-PARIS-01(config-network-object-group)# description "Serveurs accessibles depuis Internet"
FW-PARIS-01(config-network-object-group)# network-object host 10.0.10.10
FW-PARIS-01(config-network-object-group)# network-object host 10.0.10.11
FW-PARIS-01(config-network-object-group)# network-object host 10.0.10.12
! → Si un nouveau serveur arrive en DMZ, on l'ajoute ici.
! → TOUTES les ACL qui utilisent ce groupe s'appliquent
!   automatiquement au nouveau serveur. Zéro oubli.

! ── GROUPE : tous les sites de l'entreprise ──────────────
FW-PARIS-01(config)# object-group network ALL_SITES
FW-PARIS-01(config-network-object-group)# description "Tous les LAN internes (Paris + Lyon + Marseille)"
FW-PARIS-01(config-network-object-group)# network-object 192.168.1.0 255.255.255.0
FW-PARIS-01(config-network-object-group)# network-object 192.168.2.0 255.255.255.0
FW-PARIS-01(config-network-object-group)# network-object 192.168.3.0 255.255.255.0

! ── GROUPE : ports web (HTTP + HTTPS) ────────────────────
FW-PARIS-01(config)# object-group service WEB_PORTS tcp
FW-PARIS-01(config-service-object-group)# description "Ports web standard"
FW-PARIS-01(config-service-object-group)# port-object eq 80
FW-PARIS-01(config-service-object-group)# port-object eq 443
FW-PARIS-01(config-service-object-group)# port-object eq 8080

! ── GROUPE : ports mail ───────────────────────────────────
FW-PARIS-01(config)# object-group service MAIL_PORTS tcp
FW-PARIS-01(config-service-object-group)# description "Ports messagerie"
FW-PARIS-01(config-service-object-group)# port-object eq 25
FW-PARIS-01(config-service-object-group)# port-object eq 465
FW-PARIS-01(config-service-object-group)# port-object eq 587
FW-PARIS-01(config-service-object-group)# port-object eq 993

Étape 4 — Écrire les ACL avec les groupes

Comparez ces deux versions qui font exactement la même chose :

! ❌ Version sans object-groups — impossible à maintenir
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 10.0.10.10 eq 80
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 10.0.10.10 eq 443
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 10.0.10.11 eq 80
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 10.0.10.11 eq 443
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 10.0.10.11 eq 25
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any host 10.0.10.11 eq 465
! ... et ainsi de suite pour chaque serveur × chaque port

! ✅ Version avec object-groups — lisible, maintenable, auditable
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any object-group DMZ_SERVERS object-group WEB_PORTS
FW-PARIS-01(config)# access-list OUTSIDE_IN extended permit tcp any object WEB_SERVER object-group MAIL_PORTS
FW-PARIS-01(config)# access-list OUTSIDE_IN extended deny ip any any log

! Flux DMZ → DB interne (le serveur web accède à la BDD)
FW-PARIS-01(config)# access-list DMZ_TO_INSIDE extended permit tcp object WEB_SERVER object DB_SERVER eq 3306
FW-PARIS-01(config)# access-list DMZ_TO_INSIDE extended deny ip any any log

! Appliquer les ACL
FW-PARIS-01(config)# access-group OUTSIDE_IN in interface outside
FW-PARIS-01(config)# access-group DMZ_TO_INSIDE in interface dmz

Vérification

! Lister tous les objets
FW-PARIS-01# show object-group

! Détail d'un groupe spécifique
FW-PARIS-01# show object-group id DMZ_SERVERS

! Voir comment un objet est utilisé dans les ACL
FW-PARIS-01# show object-group id DMZ_SERVERS | include access-list

! Compter les hits sur chaque règle ACL
FW-PARIS-01# show access-list OUTSIDE_IN

ℹ️ Convention de nommage — En entreprise, adoptez une convention dès le début et ne la changez jamais. Par exemple : SITE_RÔLE_TYPE → PARIS_WEB_HOST, CORP_ADMIN_SUBNET, STD_HTTPS_PORT. Une convention claire transforme une config de 500 lignes en quelque chose de lisible.

Fig. 15.1 — Object-groups : simplifier et maintenir les ACL en production

16. Logging avancé & syslog

Pourquoi configurer le logging correctement ?

Un firewall sans logs exploitables, c’est comme une caméra de surveillance sans enregistrement : inutile après un incident. En pratique, le logging sert à trois choses : détecter les attaques en temps réel, investiguer après un incident et prouver la conformité (PCI-DSS, ISO 27001 exigent une rétention de 90 jours minimum).

Par défaut sur l’ASA, le logging est désactivé ou limité au buffer local qui disparaît au redémarrage. Il faut le configurer explicitement.

Les 8 niveaux de sévérité — lequel choisir ?

Niveau	Nom	Ce qu’on y voit	En prod ?
0	Emergencies	Système inutilisable	✅ toujours
1	Alerts	Intervention immédiate	✅ toujours
2	Critical	Crash, panne matérielle	✅ toujours
3	Errors	Erreurs de config, refus d’auth	✅ toujours
4	Warnings	Tentatives suspectes, near-miss	✅ recommandé
5	Notifications	Connexions VPN, changements d’état	✅ recommandé
6	Informational	Trafic accepté/refusé, NAT	✅ niveau prod standard
7	Debugging	Tout, absolument tout	❌ lab uniquement

⚠️ Règle d’or — En production, utilisez le niveau 6 (informational) vers le SIEM. Le niveau 7 (debugging) peut saturer le CPU du firewall et déclencher une coupure de service.

Étape 1 — Configurer le logging sur l’ASA

! ── ACTIVATION DE BASE ───────────────────────────────────
FW-PARIS-01(config)# logging enable

! Horodatage précis — OBLIGATOIRE pour corréler les logs
! Sans timestamp, impossible de savoir quand un événement s'est passé
FW-PARIS-01(config)# logging timestamp
FW-PARIS-01(config)# logging device-id hostname
! → Chaque ligne de log contiendra : "FW-PARIS-01: Mar 13 2026 14:32:01 ..."

! ── BUFFER LOCAL (secours si SIEM indisponible) ──────────
! 1 Mo de buffer — les logs les plus récents sont conservés
FW-PARIS-01(config)# logging buffered informational
FW-PARIS-01(config)# logging buffer-size 1048576

! ── SYSLOG VERS SIEM EXTERNE (Graylog/Splunk) ───────────
! 10.0.10.50 = IP de votre serveur Graylog sur la DMZ
FW-PARIS-01(config)# logging host inside 10.0.10.50
FW-PARIS-01(config)# logging trap informational
! facility 16 = local0 (convention Cisco)
FW-PARIS-01(config)# logging facility 16

! Deuxième destination syslog (redondance)
FW-PARIS-01(config)# logging host inside 10.0.10.51

! ── LOGGING SUR LES ACL ──────────────────────────────────
! Sans le mot "log" à la fin, les deny ne génèrent aucun log !
! interval 1 = logguer au maximum 1 fois par seconde (évite le flood)
FW-PARIS-01(config)# access-list OUTSIDE_IN extended deny ip any any log interval 1

! Logger aussi les connexions établies (utile pour les audits)
FW-PARIS-01(config)# logging flow-export-v9 enable

! ── NE PAS FAIRE EN PROD ─────────────────────────────────
! logging console debugging  ← saturation CPU garantie
! logging monitor 7          ← idem via terminal monitor

Étape 2 — Lire et interpréter les logs

! Afficher le buffer local (les derniers logs)
FW-PARIS-01# show logging

! Filtrer uniquement les connexions refusées
FW-PARIS-01# show logging | include Deny
FW-PARIS-01# show logging | include denied

! Filtrer par IP source suspecte
FW-PARIS-01# show logging | include 1.2.3.4

! Exemple de log typique à savoir lire :
! %ASA-4-106023: Deny tcp src outside:1.2.3.4/54321
!   dst inside:192.168.1.100/22 by access-group "OUTSIDE_IN"
!
! Décodage :
! ASA-4     → niveau 4 (Warning)
! 106023    → ID du message syslog (consultable sur cisco.com)
! Deny tcp  → protocole refusé
! src outside:1.2.3.4/54321 → source : IP:port
! dst inside:192.168.1.100/22 → destination : IP:port
! access-group "OUTSIDE_IN" → l'ACL qui a bloqué

! Vider le buffer local (après analyse)
FW-PARIS-01# clear logging buffer

! Voir les stats de logging
FW-PARIS-01# show logging statistics

Étape 3 — Configurer Graylog pour recevoir les logs ASA (optionnel)

Si vous n’avez pas encore de serveur Graylog, voici les étapes minimales pour en avoir un opérationnel rapidement sur Ubuntu Server :

# Sur le serveur Ubuntu (10.0.10.50)
# 1. Installer Java (prérequis)
sudo apt install -y openjdk-17-jre-headless

# 2. Installer MongoDB (base de données Graylog)
wget -qO - https://www.mongodb.org/static/pgp/server-6.0.asc | sudo apt-key add -
echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse" \
  | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list
sudo apt update && sudo apt install -y mongodb-org
sudo systemctl enable --now mongod

# 3. Installer OpenSearch (moteur de recherche)
# → Suivre la doc officielle Graylog pour la version courante

# 4. Installer Graylog
wget https://packages.graylog2.org/repo/packages/graylog-5.2-repository_latest.deb
sudo dpkg -i graylog-5.2-repository_latest.deb
sudo apt update && sudo apt install -y graylog-server

# 5. Configurer /etc/graylog/server/server.conf
# password_secret= (générer avec: pwgen -N 1 -s 96)
# root_password_sha2= (echo -n "MotDePasse" | sha256sum)

# 6. Démarrer Graylog
sudo systemctl enable --now graylog-server
# Interface web disponible sur http://10.0.10.50:9000

# 7. Dans Graylog : System > Inputs > Launch new input
# Type: Syslog UDP, Port: 514, Bind address: 0.0.0.0
# → Les logs de l'ASA arrivent automatiquement

ℹ️ Info — Une fois Graylog configuré, créez des alertes automatiques : par exemple, si plus de 100 deny viennent de la même IP en moins d’une minute, c’est probablement un scan de ports. Graylog peut envoyer un email ou un webhook Slack en temps réel.

17. AAA & authentification RADIUS / Active Directory

Pourquoi ne pas utiliser de comptes locaux ?

Par défaut, les administrateurs s’authentifient sur l’ASA avec un compte local (username admin password ...). Le problème : si 5 admins partagent ce compte, impossible de savoir qui a fait quoi. Si un admin quitte l’entreprise, il faut aller changer le mot de passe sur chaque équipement réseau manuellement. Et s’il y a 50 switches et firewalls, bonne chance.

La solution professionnelle : RADIUS + Active Directory. Un seul endroit pour gérer les comptes, les groupes et les droits. L’accès est révoqué en désactivant le compte AD, tout est journalisé centralement.

Architecture de la solution

Admin SSH → ASA → RADIUS (NPS sur Windows Server) → Active Directory
                     ↓
              Valide : username dans AD ?
              Membre du groupe "FW_Admins" ?
              → Access-Accept ou Access-Reject

Étape 1 — Préparer Active Directory

Avant de toucher au firewall, créer les éléments nécessaires dans AD.

Sur le contrôleur de domaine (Windows Server) :

# Ouvrir "Active Directory Users and Computers"

# 1. Créer une OU dédiée aux comptes réseau
OU: Corp > IT > Reseau > Comptes_Firewall

# 2. Créer les groupes de sécurité
Groupe: GRP_FW_ADMINS        → accès complet au firewall (privilege 15)
Groupe: GRP_FW_READONLY      → accès lecture seule (privilege 5)
Groupe: GRP_VPN_USERS        → autorisés à se connecter via AnyConnect

# 3. Créer les comptes utilisateurs
Utilisateur: fw-admin1   → membre de GRP_FW_ADMINS
Utilisateur: fw-readonly → membre de GRP_FW_READONLY
Utilisateur: john.doe    → membre de GRP_VPN_USERS

Étape 2 — Installer et configurer NPS (Windows Server)

NPS (Network Policy Server) est le serveur RADIUS intégré à Windows Server. Il fait le lien entre l’ASA et Active Directory.

# Sur Windows Server (192.168.1.50)
# 1. Installer le rôle NPS
Server Manager > Add Roles and Features
  → Network Policy and Access Services
  → Network Policy Server ✓
  → Cliquer Install

# 2. Ouvrir NPS (Network Policy Server) dans les outils d'administration

# 3. Enregistrer NPS dans Active Directory
  Clic droit sur "NPS (Local)" → Register server in Active Directory
  → Valider : NPS peut maintenant lire les attributs AD

# 4. Déclarer l'ASA comme client RADIUS
NPS > RADIUS Clients and Servers > RADIUS Clients > New
  Friendly name:   ASA-FW-PARIS-01
  Address (IP):    192.168.1.1    ← IP de l'interface inside de l'ASA
  Shared secret:   Rad1usS3cr3t! ← même secret que dans la config ASA
  Confirmer:       Rad1usS3cr3t!
  → OK

# Répéter pour l'ASA de Lyon (si applicable)
  Friendly name:   ASA-FW-LYON-01
  Address (IP):    192.168.2.1
  Shared secret:   Rad1usS3cr3t!

Étape 3 — Créer les politiques NPS

Deux politiques : une pour les admins full-access, une pour les admins read-only.

# ── POLITIQUE 1 : Admins full-access (privilege 15) ────
NPS > Policies > Network Policies > New

  Nom: POLICY_FW_ADMINS
  
  Conditions:
    User Groups: GRP_FW_ADMINS  ← membres de ce groupe AD seulement
    NAS Port Type: Virtual (VTY) ← connexions SSH
  
  Access Permission: Access granted ✓
  
  Settings > RADIUS Attributes > Standard:
    Service-Type: Login ✓
  
  Settings > RADIUS Attributes > Vendor Specific > Add:
    Vendor: Cisco
    Attribute: cisco-av-pair
    Value: shell:priv-lvl=15   ← privilege 15 = accès complet
  
  → Finish

# ── POLITIQUE 2 : Admins read-only (privilege 5) ────────
NPS > Policies > Network Policies > New

  Nom: POLICY_FW_READONLY
  
  Conditions:
    User Groups: GRP_FW_READONLY
    NAS Port Type: Virtual (VTY)
  
  Access Permission: Access granted ✓
  
  Settings > RADIUS Attributes > Vendor Specific > Add:
    Vendor: Cisco
    Attribute: cisco-av-pair
    Value: shell:priv-lvl=5    ← privilege 5 = lecture seule

# ── POLITIQUE 3 : Refuser tout le reste ─────────────────
NPS > Policies > Network Policies > New

  Nom: POLICY_DENY_ALL
  Conditions: (aucune condition spécifique)
  Access Permission: Access denied ✓
  → Cette règle attrape tout ce qui n'est pas dans les groupes ci-dessus

Étape 4 — Configurer l’ASA côté RADIUS

Maintenant que NPS est prêt, on configure l’ASA pour l’utiliser.

! ── DÉCLARER LE GROUPE DE SERVEURS RADIUS ────────────────
FW-PARIS-01(config)# aaa-server RADIUS_CORP protocol radius
FW-PARIS-01(config-aaa-server-group)# accounting-mode simultaneous

! Serveur RADIUS principal (NPS sur Windows Server)
FW-PARIS-01(config)# aaa-server RADIUS_CORP (inside) host 192.168.1.50
FW-PARIS-01(config-aaa-server-host)# key Rad1usS3cr3t!
FW-PARIS-01(config-aaa-server-host)# timeout 10
FW-PARIS-01(config-aaa-server-host)# retry-interval 3

! Serveur RADIUS secondaire (NPS sur le DC secondaire)
FW-PARIS-01(config)# aaa-server RADIUS_CORP (inside) host 192.168.1.51
FW-PARIS-01(config-aaa-server-host)# key Rad1usS3cr3t!
FW-PARIS-01(config-aaa-server-host)# timeout 10

! ── ACTIVER L'AUTHENTIFICATION AAA ──────────────────────
! SSH : essaye RADIUS d'abord, puis fallback LOCAL si RADIUS injoignable
FW-PARIS-01(config)# aaa authentication ssh console RADIUS_CORP LOCAL

! WebGUI ASDM : idem
FW-PARIS-01(config)# aaa authentication http console RADIUS_CORP LOCAL

! Enable password (passage en mode privilégié)
FW-PARIS-01(config)# aaa authentication enable console RADIUS_CORP LOCAL

! ── ACCOUNTING : tracer toutes les actions admin ─────────
! Chaque commande tapée est enregistrée dans NPS/AD
FW-PARIS-01(config)# aaa accounting command RADIUS_CORP
FW-PARIS-01(config)# aaa accounting ssh console RADIUS_CORP

! ── COMPTE LOCAL DE SECOURS (OBLIGATOIRE) ────────────────
! Si NPS tombe, ce compte permet de reprendre la main
! Le mot de passe DOIT être dans un coffre-fort (Passbolt, etc.)
FW-PARIS-01(config)# username fw-breakglass privilege 15 password Br3@kGl@ss2026!

Étape 5 — Tester avant de valider

Ne jamais fermer votre session SSH actuelle avant d’avoir testé ! Si la config RADIUS est mauvaise et que vous fermez la session, vous pouvez vous retrouver lockout.

! Test depuis l'ASA — sans ouvrir une nouvelle session
FW-PARIS-01# test aaa-server authentication RADIUS_CORP inside host 192.168.1.50 username fw-admin1 password MonMotDePasse
! Résultat attendu : INFO: Authentication Successful

! Test avec un mauvais mot de passe — doit échouer
FW-PARIS-01# test aaa-server authentication RADIUS_CORP inside host 192.168.1.50 username fw-admin1 password mauvaismdp
! Résultat attendu : ERROR: Authentication Rejected

! Vérifier les statistiques
FW-PARIS-01# show aaa-server RADIUS_CORP
! Regarder : Requests Sent, Responses Received, Successes, Errors

! Si errors > 0 : vérifier le shared secret et la connectivité UDP 1812
FW-PARIS-01# ping inside 192.168.1.50

Étape 6 — Configurer RADIUS pour AnyConnect VPN

! Authentification VPN via AD (les utilisateurs VPN s'authentifient
! avec leur login Windows)
FW-PARIS-01(config)# tunnel-group ANYCONNECT_USERS general-attributes
FW-PARIS-01(config-tunnel-general)# authentication-server-group RADIUS_CORP
FW-PARIS-01(config-tunnel-general)# accounting-server-group RADIUS_CORP
FW-PARIS-01(config-tunnel-general)# default-group-policy GP_ANYCONNECT

! Autorisation : récupérer les attributs AD via RADIUS
! (permet d'assigner des VLANs ou ACLs différents par groupe AD)
FW-PARIS-01(config-tunnel-general)# authorization-server-group RADIUS_CORP
FW-PARIS-01(config-tunnel-general)# authorization-required

! Dans NPS, créer une politique VPN_USERS :
! Condition: User Groups = GRP_VPN_USERS
! Attribute: Tunnel-Type = Virtual (PPP) ou L2TP
! Access: Granted

Erreurs courantes et solutions

Symptôme	Cause probable	Solution
`Authentication Rejected`	Shared secret incorrect	Vérifier que le secret est identique dans NPS et ASA
`No response from server`	UDP 1812 bloqué	Vérifier l’ACL entre l’ASA et le serveur NPS
`Authentication Rejected` après bon mdp	Utilisateur pas dans le bon groupe AD	Vérifier l’appartenance au groupe dans AD
Privilege 1 au lieu de 15	Attribut cisco-av-pair absent	Recheck la politique NPS → Vendor Specific Attributes
Timeout puis fallback LOCAL	NPS injoignable	Vérifier que le service NPS est démarré sur Windows

🔐 Sécurité — Le compte fw-breakglass doit avoir un mot de passe unique, complexe, différent de tous les autres. Le stocker dans un coffre-fort dédié (Passbolt, CyberArk, ou même une enveloppe scellée physique pour les environnements critiques). Auditer son utilisation : toute connexion avec ce compte doit déclencher une alerte immédiate.

Fig. 17.1 — Architecture AAA : authentification centralisée ASA via RADIUS et Active Directory

18. Inspection applicative — Modular Policy Framework (MPF)

Pourquoi inspecter les protocoles applicatifs ?

Un firewall stateful classique voit que le port 53 est ouvert pour le DNS. Mais il ne regarde pas ce qu’il y a dans la requête DNS. Un attaquant peut utiliser le DNS pour exfiltrer des données de votre réseau (DNS tunneling) — chaque requête DNS contient un morceau de données encodé, et la réponse sert de canal de retour. Sans inspection applicative, l’ASA laisse passer tout ça sans broncher.

Le MPF (Modular Policy Framework) corrige ça : il inspecte le contenu des protocoles et peut bloquer les comportements anormaux.

Les 3 briques du MPF

class-map      → "quel trafic ?"  (identifier ce qu'on veut inspecter)
policy-map     → "quoi faire ?"   (inspecter, dropper, rate-limiter)
service-policy → "où appliquer ?" (interface ou global)

Configuration complète pas à pas

! ── ÉTAPE 1 : Classe de trafic par défaut ───────────────
! "inspection_default" identifie les protocoles standards
! C'est la class-map fournie par Cisco, on l'utilise telle quelle
FW-PARIS-01(config)# class-map inspection_default
FW-PARIS-01(config-cmap)# match default-inspection-traffic
! Cette classe inclut automatiquement : DNS, FTP, HTTP, SMTP,
! ICMP, SIP, H.323, TFTP, SNMP, SQL*Net, etc.

! ── ÉTAPE 2 : Politique d'inspection HTTP ────────────────
! On crée une sous-politique spécifique au HTTP
FW-PARIS-01(config)# policy-map type inspect http HTTP_STRICT
FW-PARIS-01(config-pmap)# parameters
! Bloquer les requêtes non conformes à la RFC HTTP
FW-PARIS-01(config-pmap-p)# protocol-violation action drop-connection log
! Limiter la taille des corps de requêtes (anti-upload massif)
FW-PARIS-01(config-pmap-p)# body-match-maximum 8192
! Bloquer les encodages d'URL qui contournent les ACL
FW-PARIS-01(config-pmap-p)# no request-method post

! ── ÉTAPE 3 : Politique d'inspection DNS ─────────────────
! Protection contre le DNS tunneling
FW-PARIS-01(config)# policy-map type inspect dns DNS_STRICT
FW-PARIS-01(config-pmap)# parameters
! Taille max d'une réponse DNS : 512 octets standard, 4096 avec EDNS
! Le DNS tunneling utilise des réponses anormalement grandes
FW-PARIS-01(config-pmap-p)# message-length maximum 512
! Bloquer les requêtes DNS vers des domaines suspects (optionnel)
FW-PARIS-01(config-pmap-p)# id-randomization

! ── ÉTAPE 4 : Policy globale — tout assembler ────────────
FW-PARIS-01(config)# policy-map global_policy
FW-PARIS-01(config-pmap)# class inspection_default
! Inspecter FTP — gère le mode actif/passif automatiquement
! (sans inspection FTP, le mode passif ne fonctionne pas à travers un NAT)
FW-PARIS-01(config-pmap-c)# inspect ftp
! Inspecter SMTP — bloque les commandes dangereuses (VRFY, EXPN)
FW-PARIS-01(config-pmap-c)# inspect smtp
! Inspecter DNS avec notre politique stricte
FW-PARIS-01(config-pmap-c)# inspect dns DNS_STRICT
! Inspecter ICMP — permet les réponses ICMP de traverser le firewall
FW-PARIS-01(config-pmap-c)# inspect icmp
! Inspecter HTTP avec notre politique stricte
FW-PARIS-01(config-pmap-c)# inspect http HTTP_STRICT
! Inspecter SIP/VoIP si vous avez de la téléphonie IP
FW-PARIS-01(config-pmap-c)# inspect sip
! Inspecter NetBIOS/NBSS (Windows file sharing)
FW-PARIS-01(config-pmap-c)# inspect netbios

! ── ÉTAPE 5 : Appliquer la politique ─────────────────────
! "global" = s'applique à toutes les interfaces dans les deux sens
FW-PARIS-01(config)# service-policy global_policy global

! Si vous voulez appliquer uniquement sur l'interface outside :
! FW-PARIS-01(config)# service-policy global_policy interface outside

Vérification et monitoring

! Vue d'ensemble de toutes les politiques actives
FW-PARIS-01# show service-policy

! Statistiques d'inspection HTTP (combien de connexions, violations)
FW-PARIS-01# show service-policy inspect http

! Statistiques DNS
FW-PARIS-01# show service-policy inspect dns

! Connexions actuellement inspectées
FW-PARIS-01# show conn detail | include HTTP

! Voir les drops liés à l'inspection
FW-PARIS-01# show asp drop | include inspect

ℹ️ Cas concret — DNS tunneling — Sans l’inspection DNS, un attaquant ayant compromis un poste interne peut utiliser des requêtes DNS pour exfiltrer 1 fichier toutes les 30 secondes vers un serveur externe, indéfiniment, sans déclencher aucune alerte firewall classique. L’option message-length maximum 512 réduit drastiquement ce risque car les tunnels DNS nécessitent de longues réponses encodées en base64.

19. Gestion des certificats & PKI pour AnyConnect

Pourquoi les certificats auto-signés sont inacceptables en prod ?

Quand AnyConnect se connecte à un firewall avec un certificat auto-signé, le client voit un avertissement de sécurité. L’utilisateur clique sur “Accepter quand même” — et c’est exactement le comportement qu’exploitent les attaques de type man-in-the-middle. Si les utilisateurs sont habitués à accepter les avertissements, un vrai attaquant peut facilement intercepter le VPN.

Il y a deux solutions : une CA Windows interne (gratuite, pour les flottes d’entreprise maîtrisées) ou un certificat public (payant, pour les accès depuis des machines non gérées).

Option A — Utiliser la CA Windows interne (recommandé en entreprise)

Étape 1 — Installer les rôles CA sur Windows Server

# Sur Windows Server (contrôleur de domaine ou serveur dédié)
# Server Manager > Add Roles and Features

Rôles à installer :
  ✓ Active Directory Certificate Services (AD CS)
    → Certification Authority
    → Certificate Enrollment Web Service  ← pour SCEP
    → Network Device Enrollment Service (NDES) ← pour SCEP sur équipements réseau

# Lors de la configuration AD CS :
Setup Type:    Enterprise CA (pas Standalone)
CA Type:       Root CA (si première CA) ou Subordinate CA
Key length:    4096 bits (RSA) ou P-384 (ECDSA)
Hash:          SHA-256
CA Name:       CA-ENTREPRISE-PARIS
Validity:      10 ans pour la Root CA

# Activer IIS si pas déjà fait (pour SCEP)
Server Manager > Add Roles > Web Server (IIS)

Étape 2 — Configurer NDES (intermédiaire SCEP)

NDES est la passerelle qui permet à l’ASA de demander automatiquement un certificat via SCEP, sans intervention humaine.

# Dans Server Manager > AD CS > Configure Active Directory Certificate Services
  ✓ Network Device Enrollment Service

# Compte de service NDES (créer dans AD) :
Utilisateur: svc-ndes
Groupe: IIS_IUSRS

# URL SCEP générée automatiquement :
# http://ca.entreprise.local/certsrv/mscep/mscep.dll
# → C'est l'URL qu'on utilisera dans la config ASA

# Tester l'accès SCEP depuis un navigateur :
# http://ca.entreprise.local/certsrv/mscep/mscep.dll?operation=GetCACert
# → Doit retourner le certificat de la CA (pas d'erreur)

Étape 3 — Configurer l’ASA pour demander un certificat via SCEP

! ── GÉNÉRER LA PAIRE DE CLÉS RSA ────────────────────────
! À faire en premier — la clé privée ne quitte jamais l'ASA
FW-PARIS-01(config)# crypto key generate rsa label RSA_FW_PARIS modulus 2048
! Résultat attendu :
! INFO: The name for the keys will be: RSA_FW_PARIS
! Keypair generation process begin. Please wait...

! ── CRÉER LE TRUSTPOINT (profil de certificat) ───────────
FW-PARIS-01(config)# crypto ca trustpoint CA_CORP
! URL du service SCEP sur votre serveur Windows
FW-PARIS-01(config-ca-trustpoint)# enrollment url http://ca.entreprise.local/certsrv/mscep/mscep.dll
! Identité du certificat (ce qui apparaîtra dans le certificat)
FW-PARIS-01(config-ca-trustpoint)# subject-name CN=fw-paris-01.entreprise.local,OU=IT,O=Entreprise,C=FR
! FQDN = nom DNS du firewall (doit correspondre à l'URL AnyConnect)
FW-PARIS-01(config-ca-trustpoint)# fqdn fw-paris-01.entreprise.local
! Utiliser la clé RSA générée ci-dessus
FW-PARIS-01(config-ca-trustpoint)# keypair RSA_FW_PARIS
! Vérifier la révocation via la CRL de la CA Windows
FW-PARIS-01(config-ca-trustpoint)# revocation-check crl

! ── RÉCUPÉRER LE CERTIFICAT RACINE DE LA CA ──────────────
! L'ASA télécharge le certificat de la CA pour pouvoir lui faire confiance
FW-PARIS-01(config)# crypto ca authenticate CA_CORP
! L'ASA affiche le certificat et demande confirmation
! Do you accept this certificate? [yes/no]: yes
! → Le certificat racine est maintenant stocké dans l'ASA

! ── DEMANDER LE CERTIFICAT POUR L'ASA ────────────────────
FW-PARIS-01(config)# crypto ca enroll CA_CORP
! L'ASA envoie une CSR (Certificate Signing Request) à la CA via SCEP
! Résultat attendu :
! % Start certificate enrollment ..
! % Certificate request successfully submitted.
! % The certificate enrollment is pending approval from the CA.
! (sur une Enterprise CA, c'est auto-approuvé)

! ── ASSIGNER LE CERTIFICAT À ANYCONNECT ──────────────────
! Le certificat est utilisé pour sécuriser les connexions VPN
FW-PARIS-01(config)# ssl trust-point CA_CORP outside

! ── VÉRIFICATION ─────────────────────────────────────────
FW-PARIS-01# show crypto ca certificates
! Doit afficher :
! Certificate
!   Status: Available
!   Certificate Serial Number: xxxx
!   Subject Name: CN=fw-paris-01.entreprise.local
!   Validity Date:
!     start date: 13:00:00 UTC Mar 13 2026
!     end   date: 13:00:00 UTC Mar 13 2028
!   Associated Trustpoints: CA_CORP

FW-PARIS-01# show ssl
! Doit afficher : outside: CA_CORP

Étape 4 — Distribuer le certificat racine aux postes clients

Pour qu’AnyConnect ne montre aucune alerte, les postes clients doivent faire confiance à votre CA. Sur un domaine AD, c’est automatique via GPO.

# Sur le contrôleur de domaine :
# Group Policy Management > Default Domain Policy > Edit
# Computer Configuration > Windows Settings > Security Settings
# > Public Key Policies > Trusted Root Certification Authorities
# > Import... → sélectionner le fichier .cer de votre CA
# Apply

# Résultat : tous les postes du domaine font automatiquement
# confiance à votre CA → AnyConnect ne montre aucune alerte

Option B — Importer un certificat public (accès depuis l’extérieur)

Si des utilisateurs se connectent avec des appareils non gérés (téléphones perso, PC hors domaine), il faut un certificat émis par une CA publique reconnue (DigiCert, Sectigo, Let’s Encrypt).

# ── ÉTAPE 1 : Générer une CSR sur l'ASA ─────────────────
FW-PARIS-01(config)# crypto key generate rsa label RSA_PUBLIC_VPN modulus 2048

FW-PARIS-01(config)# crypto ca trustpoint CERT_PUBLIC
FW-PARIS-01(config-ca-trustpoint)# enrollment terminal   ← on entre la CSR manuellement
FW-PARIS-01(config-ca-trustpoint)# subject-name CN=vpn.entreprise.com,O=Entreprise,C=FR
FW-PARIS-01(config-ca-trustpoint)# fqdn vpn.entreprise.com
FW-PARIS-01(config-ca-trustpoint)# keypair RSA_PUBLIC_VPN

! Générer la CSR (Certificate Signing Request)
FW-PARIS-01(config)# crypto ca enroll CERT_PUBLIC
! L'ASA affiche un bloc de texte commençant par :
! -----BEGIN CERTIFICATE REQUEST-----
! MIICvDCCAaQCAQAwXzELMAkGA1UEBhMCRlIx...
! -----END CERTIFICATE REQUEST-----
! → Copier ce bloc et le soumettre à votre fournisseur de certificat

# ── ÉTAPE 2 : Après réception du certificat (.pfx/.p12) ─
# Le fournisseur vous envoie un fichier .pfx qui contient :
# - Votre certificat signé
# - La chaîne de CA intermédiaires
# - Votre clé privée (protégée par un mot de passe)

! Copier le fichier .pfx sur un serveur TFTP de votre réseau interne
! puis importer dans l'ASA :
FW-PARIS-01(config)# crypto ca import CERT_PUBLIC pkcs12 tftp://192.168.1.10/vpn-cert.pfx
! Enter the passphrase for the PKCS12 file: MotDePasseDuPFX

! Assigner à l'interface outside pour AnyConnect
FW-PARIS-01(config)# ssl trust-point CERT_PUBLIC outside

! Vérifier
FW-PARIS-01# show crypto ca certificates CERT_PUBLIC

Surveiller l’expiration des certificats

Un certificat expiré = tous les utilisateurs VPN déconnectés simultanément au moment de l’expiration. C’est une des interruptions de service les plus embarrassantes et les plus évitables.

! Vérifier les dates d'expiration
FW-PARIS-01# show crypto ca certificates | include end date

! Exemple de résultat :
! end date: 13:00:00 UTC Mar 13 2028
! → Créer une alerte dans votre SIEM/supervision 60 jours avant

! Script de renouvellement automatique (via SCEP, CA interne uniquement)
FW-PARIS-01(config)# crypto ca trustpoint CA_CORP
FW-PARIS-01(config-ca-trustpoint)# auto-enroll 70 regenerate
! → L'ASA renouvelle automatiquement le certificat quand il reste 30% de durée

🔐 Sécurité — Ne jamais exporter la clé privée de l’ASA (la commande crypto ca export avec clé privée). Si un attaquant obtient votre clé privée, il peut usurper votre VPN et intercepter toutes les connexions AnyConnect sans que les clients voient la moindre alerte.

20. Troubleshooting — diagnostics concrets

Méthodologie — ne jamais commencer au hasard

Face à un problème de connectivité à travers l’ASA, la démarche est toujours la même, dans cet ordre :

1. Est-ce que le paquet arrive sur l'ASA ?      → packet-tracer / capture
2. L'ACL le bloque-t-elle ?                     → show access-list + packet-tracer
3. Le NAT est-il correctement configuré ?        → show xlate / show nat
4. Le routage est-il correct ?                  → show route
5. Y a-t-il une inspection qui bloque ?         → show asp drop

Outil 1 — packet-tracer (indispensable)

packet-tracer simule un paquet sans l’envoyer réellement. Il vous dit exactement quelle phase bloque et pourquoi, sans toucher au trafic de production.

! ── SYNTAXE ──────────────────────────────────────────────
! packet-tracer input <interface-entrée> <proto> <ip-src> <port-src> <ip-dst> <port-dst>

! ── CAS 1 : Un utilisateur Internet n'arrive pas sur le serveur web ──
FW-PARIS-01# packet-tracer input outside tcp 1.2.3.4 12345 203.0.113.5 443

! Résultat typique si tout est OK :
! Phase 1: ROUTE-LOOKUP        Subtype: Resolve Egress Interface  Result: ALLOW
! Phase 2: ACCESS-LIST         Result: ALLOW  access-group OUTSIDE_IN
! Phase 3: NAT                 Result: ALLOW  static (dmz,outside) 203.0.113.5 → 10.0.10.10
! Phase 4: FLOW-CREATION       Result: ALLOW
! Result: input-interface: outside
!         output-interface: dmz
!         Action: allow

! Résultat si l'ACL bloque :
! Phase 1: ROUTE-LOOKUP        Result: ALLOW
! Phase 2: ACCESS-LIST         Result: DROP   Implicit Rule
! Result: Action: drop  Drop-reason: (acl-drop) Flow is denied by configured rule

! → Diagnostic immédiat : l'ACL OUTSIDE_IN n'autorise pas ce flux
! → Solution : ajouter la règle permit pour ce trafic

! ── CAS 2 : Un client LAN n'accède pas à Internet ────────
FW-PARIS-01# packet-tracer input inside tcp 192.168.1.100 54321 8.8.8.8 443

! Si NAT manquant :
! Phase 3: NAT                 Result: DROP
! Drop-reason: (nat-no-xlate-to-pat-pool) Untranslated packet

! → Diagnostic : le PAT n'est pas configuré pour ce réseau source
! → Solution : vérifier object network LAN_PARIS + nat (inside,outside) dynamic interface

! ── CAS 3 : VPN AnyConnect ne s'établit pas ──────────────
FW-PARIS-01# packet-tracer input outside tcp 5.6.7.8 12345 203.0.113.1 443

! Si ça passe mais VPN échoue quand même → problème d'authentification
! → Vérifier : show aaa-server RADIUS_CORP statistics

Outil 2 — captures de paquets

Quand packet-tracer ne suffit pas (problème intermittent, protocole complexe), on capture le vrai trafic.

! ── CAPTURER LE TRAFIC D'UNE IP SUSPECTE ────────────────
! Commencer la capture AVANT de reproduire le problème
FW-PARIS-01# capture CAP_DEBUG interface outside match ip host 1.2.3.4 any

! Reproduire le problème (tenter la connexion qui échoue)

! Afficher la capture
FW-PARIS-01# show capture CAP_DEBUG
! Résultat typique :
!    1: 14:32:01.123456 1.2.3.4.54321 > 203.0.113.5.443: S (SYN)
!    2: 14:32:01.123789 203.0.113.5.443 > 1.2.3.4.54321: S A (SYN-ACK)
!    3: 14:32:01.124012 1.2.3.4.54321 > 203.0.113.5.443: A (ACK)
! → La connexion TCP s'établit correctement côté réseau

! Si on ne voit que des SYN sans SYN-ACK :
! → Le paquet arrive mais la réponse ne repart pas → problème de routage retour

! ── CAPTURER SUR DEUX INTERFACES SIMULTANÉMENT ───────────
! Utile pour voir si le paquet entre mais ne sort pas
FW-PARIS-01# capture CAP_IN  interface outside match ip host 1.2.3.4 any
FW-PARIS-01# capture CAP_OUT interface dmz    match ip host 10.0.10.10 any
! → Si CAP_IN reçoit le paquet mais CAP_OUT est vide :
!    le problème est DANS l'ASA (ACL, NAT, inspection)

! ── EXPORTER VERS WIRESHARK ──────────────────────────────
! Pour une analyse approfondie avec filtres et décodage protocole
FW-PARIS-01# copy /pcap capture:CAP_DEBUG tftp://192.168.1.10/debug.pcap
! Ouvrir debug.pcap dans Wireshark → analyse graphique complète

! ── NETTOYAGE (toujours faire après) ─────────────────────
FW-PARIS-01# no capture CAP_DEBUG
FW-PARIS-01# no capture CAP_IN
FW-PARIS-01# no capture CAP_OUT

Outil 3 — show asp drop (les drops invisibles)

asp drop montre les paquets que l’ASA silencieusement jette sans les loguer dans les ACL. C’est souvent là que se cachent les problèmes mystérieux.

FW-PARIS-01# show asp drop

! Exemple de résultat révélateur :
! Frame drop:
!   Invalid TCP flags (invalid-tcp-hdr-flags)          452
!   TCP RST/FIN out of order (tcp-rst-fin-ooo)          38
!   Flow is denied by configured rule (acl-drop)       1204
!   No valid adjacency (no-adjacency)                    12  ← problème de routage
!   NAT failed (nat-no-xlate-to-pat-pool)                5  ← PAT manquant

! Si vous voyez des "acl-drop" en masse → regarder les ACL
! Si "nat-no-xlate" → un réseau source n'a pas de règle NAT
! Si "no-adjacency" → table de routage incomplète ou interface down

! Remettre les compteurs à zéro après analyse
FW-PARIS-01# clear asp drop

Outil 4 — diagnostics système courants

! ── VÉRIFIER L'ÉTAT GÉNÉRAL ──────────────────────────────
! Uptime, version, licence
FW-PARIS-01# show version

! État des interfaces (toutes doivent être "up up")
FW-PARIS-01# show interface ip brief
! Interface         IP-Address      OK? Method Status Protocol
! GigabitEthernet0/0  203.0.113.1   YES  manual up     up
! GigabitEthernet0/1  192.168.1.1   YES  manual up     up
! GigabitEthernet0/2  10.0.10.1     YES  manual up     up
! Si une interface est "down down" → câble ou module défectueux
! Si "up down" → problème de négociation (speed/duplex)

! Performances CPU et mémoire
FW-PARIS-01# show cpu usage
! CPU Usage: 8% 1 sec, 6% 5 sec, 5% 1 min
! Si CPU > 80% en continu → possible attaque DDoS ou debug oublié

FW-PARIS-01# show memory
! Si mémoire > 90% → redémarrage possible → investiguer les connexions

! ── CONNEXIONS ACTIVES ────────────────────────────────────
! Nombre total de connexions
FW-PARIS-01# show conn count
! 1842 in use, 8921 most used

! Connexions d'une IP spécifique (ex: un user qui a des problèmes)
FW-PARIS-01# show conn address 192.168.1.100
! TCP outside 1.2.3.4:443 inside 192.168.1.100:54321, idle 0:00:03, ...

! ── VPN ──────────────────────────────────────────────────
! Résumé des sessions VPN actives
FW-PARIS-01# show vpn-sessiondb summary
! Sessions : 12 AnyConnect, 3 IPsec LAN-to-LAN

! Détail d'une session AnyConnect spécifique
FW-PARIS-01# show vpn-sessiondb anyconnect filter name john.doe@entreprise.local

! État des tunnels IPsec (site-à-site)
FW-PARIS-01# show crypto ikev2 sa
FW-PARIS-01# show crypto ipsec sa

! ── ACL — COMPTER LES HITS ───────────────────────────────
! Chaque règle a un compteur de hits — utile pour savoir si une règle est utilisée
FW-PARIS-01# show access-list OUTSIDE_IN
! access-list OUTSIDE_IN line 1 extended permit tcp any object-group DMZ_SERVERS ...
!   hitcnt=45872    ← cette règle a été matchée 45872 fois
! access-list OUTSIDE_IN line 2 extended deny ip any any log
!   hitcnt=1247     ← 1247 connexions ont été bloquées

! Si une règle a hitcnt=0 depuis des jours → elle est peut-être inutile
! Remettre les compteurs à zéro pour commencer une nouvelle observation
FW-PARIS-01# clear access-list counters OUTSIDE_IN

Guide de dépannage rapide — symptômes courants

Symptôme	Commande de diagnostic	Cause probable
Un user ne passe pas le firewall	`packet-tracer input inside tcp ...`	ACL ou NAT manquant
Serveur web inaccessible depuis Internet	`packet-tracer input outside tcp ...`	ACL OUTSIDE_IN ou NAT statique
VPN AnyConnect “connexion échouée”	`show vpn-sessiondb anyconnect` + `show logging`	Auth RADIUS ou certificat
Tunnel IPsec ne monte pas	`show crypto ikev2 sa`	IKEv2 policy mismatch ou ACL
Performances dégradées	`show cpu` + `show asp drop`	DDoS, debug oublié, ou table de connexions pleine
Pings qui passent mais TCP non	`show conn` + capture	Inspection TCP qui bloque (MPF)
“Travaille mais lent”	`show interface` → chercher errors/drops	Problème négociation réseau

⚠️ Règle absolue — Ne jamais activer debug crypto isakmp 255 ou debug crypto ipsec 255 en production sans être prêt à le couper dans les 30 secondes. Ces debugs génèrent tellement de sortie qu’ils peuvent crasher l’ASA. Toujours utiliser undebug all après usage.

Fig. 20.1 — Pipeline packet-tracer : identifier la phase exacte qui bloque le trafic

21. Plan d’adressage IP — réseau d’entreprise multi-sites

Ce tableau est le référentiel commun utilisé dans l’ensemble de la série de guides (Firewall, Routeurs, Switches). Tous les exemples de configuration s’appuient sur ce plan.

Site	Rôle	Réseau	VLAN	Equipement
Paris HQ	LAN Users	192.168.1.0/24	10	ASA FW-PARIS-01
Paris HQ	DMZ Servers	10.0.10.0/24	20	ASA FW-PARIS-01
Paris HQ	Servers internes	10.0.20.0/24	30	ASA FW-PARIS-01
Paris HQ	Management OOB	172.16.0.0/24	99	ASA FW-PARIS-01
Paris HQ	VPN AnyConnect pool	172.16.10.0/24	—	ASA FW-PARIS-01
Paris HQ	WAN (FAI)	203.0.113.0/30	—	Interface Outside
Lyon Agence	LAN Users	192.168.2.0/24	10	ASA FW-LYON-01
Lyon Agence	Servers	10.0.21.0/24	30	ASA FW-LYON-01
Lyon Agence	WAN (FAI)	198.51.100.0/30	—	Interface Outside
Marseille	LAN Users	192.168.3.0/24	10	FTDv ESXi
Marseille	Servers	10.0.22.0/24	30	FTDv ESXi
Marseille	WAN (FAI)	203.0.113.4/30	—	Interface Outside
Inter-sites	Failover ASA Paris	10.255.255.0/30	—	Câble dédié
Inter-sites	VPN IPsec Paris↔Lyon	—	—	Tunnel logique
Inter-sites	VPN IPsec Paris↔Marseille	—	—	Tunnel logique

ℹ️ Info — Ce plan respecte la convention RFC 1918 pour les adresses privées. Les adresses WAN utilisées (203.0.113.x, 198.51.100.x) sont des adresses de documentation RFC 5737 — à remplacer par vos vraies IPs FAI en production.

22. Durcissement (Hardening) — Cisco ASA & FTD

Domaine	Action	Priorité
Authentification	AAA centralisé RADIUS + fallback LOCAL	🔴 CRITIQUE
Accès WebGUI / ASDM	Restreindre aux IPs MGMT uniquement	🔴 CRITIQUE
SSH	Version 2 uniquement, clé RSA 2048+, timeout 5 min	🔴 CRITIQUE
Certificats	PKI d’entreprise ou CA public — jamais auto-signé	🔴 CRITIQUE
ACL	deny ip any any log en fin de chaque ACL	🔴 CRITIQUE
Protocoles	Désactiver Telnet, HTTP, SNMP v1/v2	🟠 ÉLEVÉ
SNMP	SNMPv3 avec authPriv (auth + chiffrement)	🟠 ÉLEVÉ
NTP	Source NTP interne authentifiée (MD5/SHA)	🟠 ÉLEVÉ
Logging	Syslog vers SIEM externe, rétention 90 jours min	🟠 ÉLEVÉ
Passwords	Chiffrement type 8 (PBKDF2) ou type 9 (scrypt)	🟠 ÉLEVÉ
Mises à jour	Patch ASA/FTD régulier, tester en lab avant	🟡 STANDARD
Sauvegarde config	Export chiffré quotidien vers serveur TFTP/FTP sécurisé	🟡 STANDARD
Timeout sessions	exec-timeout 5 sur toutes les lignes	🟡 STANDARD
Bannière	banner login avec mention légale	🟡 STANDARD

Commandes de durcissement essentielles

! Chiffrement passwords (type 8 = PBKDF2)
FW-PARIS-01(config)# password encryption aes
FW-PARIS-01(config)# key config-key password-encrypt MonMasterKey!

! Bannière légale obligatoire
FW-PARIS-01(config)# banner login "Accès réservé au personnel autorisé. Toute connexion non autorisée est un délit."

! Timeout sessions (5 min)
FW-PARIS-01(config)# console timeout 5
FW-PARIS-01(config)# ssh timeout 5

! Désactiver les services inutiles
FW-PARIS-01(config)# no snmp-server enable traps
FW-PARIS-01(config)# no service tcp-small-servers
FW-PARIS-01(config)# no service udp-small-servers

! SNMPv3 sécurisé
FW-PARIS-01(config)# snmp-server group SNMPV3_GROUP v3 priv
FW-PARIS-01(config)# snmp-server user snmp_admin SNMPV3_GROUP v3 auth sha AuthPass123! priv aes 128 PrivPass456!
FW-PARIS-01(config)# snmp-server host inside 10.0.10.50 version 3 priv snmp_admin

! Vérification globale de la sécurité
FW-PARIS-01# show run | include password
FW-PARIS-01# show run | include snmp
FW-PARIS-01# show run | include banner
FW-PARIS-01# show run | include timeout

Fig. 22.1 — Roue de durcissement Cisco ASA/FTD — réduction de la surface d’attaque

23. SSL/TLS Decryption Policy (FTD)

Le trafic HTTPS représente aujourd’hui plus de 90% du trafic web. Sans déchiffrement TLS, l’IPS Snort 3 est aveugle sur ce trafic. La SSL Policy permet à FTD d’inspecter le trafic chiffré.

Fonctionnement du déchiffrement TLS

FMC > Policies > SSL > New Policy

Nom: SSL_DECRYPT_POLICY

! Règle 1 — Ne pas déchiffrer les sites bancaires et médicaux
Rule 1: No-Decrypt-Sensitive
  - URL Category: Financial Services, Health and Medicine
  - Action: Do Not Decrypt

! Règle 2 — Ne pas déchiffrer les mises à jour OS
Rule 2: No-Decrypt-Updates
  - Application: Windows Update, Apple Update
  - Action: Do Not Decrypt

! Règle 3 — Déchiffrer le reste du trafic HTTPS sortant
Rule 3: Decrypt-Outbound
  - Source: LAN_NETWORKS
  - Destination: any
  - Port: HTTPS (443)
  - Action: Decrypt (Resign) ← utilise le certificat CA interne

! Assigner la SSL Policy à l'ACP
FMC > Policies > Access Control > Edit ACP
Advanced > SSL Policy: SSL_DECRYPT_POLICY

⚠️ Attention juridique — Le déchiffrement TLS implique une interception des communications. En France, cela requiert une information préalable des utilisateurs (mention dans la charte informatique) et ne peut s’appliquer aux sessions personnelles si elles sont distinguables. Consultez votre DPO avant déploiement.

24. File Policy & AMP — blocage de malware (FTD)

La File Policy permet à FTD d’analyser les fichiers en transit et de les soumettre à Cisco AMP (Advanced Malware Protection) pour détection de malware.

FMC > Policies > Files > New File Policy

Nom: FILE_POLICY_ENTREPRISE

! Règle 1 — Bloquer les exécutables malveillants connus
Rule 1:
  Application Protocol: HTTP, HTTPS (après déchiffrement)
  File Type: Executables (PE, ELF, Mach-O)
  Action: Block Malware
  Store Files: Malware (pour analyse forensique)

! Règle 2 — Logger les PDFs et Office
Rule 2:
  File Type: PDF, Office Documents
  Action: Detect Files
  Store Files: Malware + Unknown

! Activer dans une règle ACP
Rule ACP > Inspection Tab:
  File Policy: FILE_POLICY_ENTREPRISE
  Intrusion Policy: IPS_ENTREPRISE

! Vérification dans FMC
FMC > Analysis > Files > File Events
FMC > Analysis > Files > Malware Events

25. Identity Policy & Cisco ISE (FTD)

L’Identity Policy permet d’associer les règles ACP à des utilisateurs Active Directory plutôt qu’à des adresses IP. C’est la fonctionnalité NGFW qui fait la vraie différence par rapport à un firewall classique.

Architecture ISE + FTD

! ISE collecte l'identité des utilisateurs via :
- Active Directory (login Windows → ISE → FMC)
- Authentification 802.1X (switches)
- VPN AnyConnect (ISE comme RADIUS)
- Portail captif ISE

! FMC > Policies > Identity > New Policy
Nom: IDENTITY_POLICY

Rule 1: AD_Authentication
  - Realm: AD_ENTREPRISE (connexion LDAP configurée)
  - Active Authentication: Kerberos (transparent pour Windows)
  - Passive Authentication: User-Agent (ASA)
  - Action: Active Authentication

! Utilisation dans les règles ACP
Rule ACP:
  Users: AD_GROUPE_FINANCE  (au lieu d'une IP !)
  Destination: SERVERS_FINANCE
  Action: Allow

Rule ACP:
  Users: AD_GROUPE_IT
  Destination: any
  Action: Allow + IPS Inspection

! Vérification
FMC > Analysis > Users > Active Sessions

ℹ️ Info — Avec ISE + FTD, si un utilisateur change de poste, ses droits d’accès le suivent automatiquement. Plus besoin de mettre à jour des ACL basées sur des IPs — la politique suit l’identité, pas la machine.

26. Haute disponibilité FTD (Active/Standby)

La HA sur FTD fonctionne différemment de l’ASA. Elle se configure via FMC et non via CLI.

! Sur FMC : Devices > Device Management > Add High Availability
Type: Firewall High Availability

Primary FTD:   FTD-PARIS-01
Secondary FTD: FTD-PARIS-02

! Interfaces de HA
Failover Link: dedicated interface (ex: Management1/1)
State Link: même interface ou dédiée

! IPs de HA (configurées dans FMC)
Primary Failover IP:   10.255.0.1/30
Secondary Failover IP: 10.255.0.2/30

! IPs Standby pour chaque interface data
Outside: Standby IP 203.0.113.2/30
Inside:  Standby IP 192.168.1.2/24
DMZ:     Standby IP 10.0.10.2/24

! Déployer la configuration HA
FMC > Deploy > Deploy All

! Vérification depuis FTD CLI
> show high-availability config
> show high-availability state

ℹ️ Info — Contrairement à l’ASA, la configuration HA FTD est entièrement gérée via FMC. Ne pas tenter de configurer la HA via CLI FTD — cela peut désynchroniser FMC. Le déploiement FMC synchronise automatiquement toute la configuration vers le nœud secondaire.

Fig. 26.1 — Architecture HA FTD Active/Standby pilotée par FMC

Cisco®, ASA®, Firepower®, AnyConnect®, FMC®, ISE® et AMP® sont des marques déposées de Cisco Systems, Inc. Ce tutoriel est fourni à des fins éducatives.