Ce guide travaille les concepts du 401. Les produits, licences et interfaces doivent être vérifiés dans le périmètre des versions citées.
Identifier le trafic réellement évalué
AFM traite des politiques de sécurité réseau. Leur effet dépend du contexte auquel elles sont associées et du chemin de trafic. Une règle bien écrite dans une politique non appliquée ne protège pas le service. Commencez par relever source, destination, protocole, port et objet de publication.
Le programme 401 demande de choisir puis d’appliquer des contrôles adaptés. Ce guide utilise les concepts AFM documentés ; l’interface et les capacités doivent être vérifiées dans votre version et votre licence. Ne confondez pas règle réseau et validation du contenu applicatif par un WAF.
Sources : F5, Policies and Rules ; F5, Blueprint 401 — Security Solution Expert.
Lire la politique et ses références
Les règles et listes permettent de décrire des ensembles de flux et des actions. Examinez l’ordre, les conditions et les éventuels objets réutilisés. Une liste de ports ne doit pas être interprétée hors de son protocole, et une liste d’adresses peut concerner un réseau plus large que prévu.
Parcourez les contextes concernés et leurs politiques, puis vérifiez le comportement par défaut et les interactions documentées. La décision ne se réduit pas nécessairement à la première règle que vous voyez dans un écran. Consignez les références qui établissent le résultat pour votre version.
Sources : F5, Policies and Rules.
Définir les preuves d’application
Préparez un flux autorisé, un flux explicitement refusé et un flux hors de l’exception. Associez les journaux au contexte et à la règle appropriés. Une connexion refusée ne prouve pas à elle seule qu’AFM l’a bloquée : routage, écoute et disponibilité du serveur peuvent également intervenir.
Une politique en préparation et une politique appliquée ne doivent pas être confondues. Vérifiez le mécanisme d’évaluation disponible dans votre version avant de conclure à une mitigation. Après changement, contrôlez les parcours légitimes et prévoyez le retrait de la règle ajoutée.
| Cas | Question de diagnostic |
|---|---|
| Autorisé | Le parcours complet fonctionne-t-il ? |
| Refusé | Quel contexte et quelle règle décident ? |
| Exception | La portée est-elle aussi étroite que prévu ? |
| Panne | Le refus persiste-t-il sans l’hypothèse de filtrage ? |
Sources : F5, Policies and Rules ; F5, Detecting and Mitigating DoS/DDoS Attacks on Protected Objects.
Exercice : une règle présente mais sans effet
Un administrateur ajoute un refus mais le service reste accessible. Relevez le contexte d’association, l’ordre des règles, la condition et la source réellement observée. Ne modifiez pas simultanément plusieurs politiques pour obtenir un refus.
Le compte rendu doit expliquer le flux, le contexte et la décision qui le traite. Pour une panne de connexion, utilisez aussi une capture ciblée. Pour un volume anormal, poursuivez avec la protection DoS.
Sources : F5, Policies and Rules.
Sources et portée
Références consultées le . Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.
- F5 — Policies and Rules · Chapitre AFM, périmètre de versions indiqué par F5 · consulté le 3 octobre 2026.
- F5 — Blueprint 401 — Security Solution Expert · Blueprint 401.102019 · consulté le 3 octobre 2026.
- F5 — Detecting and Mitigating DoS/DDoS Attacks on Protected Objects · Chapitre AFM, dont 17.1.0 et 17.5.0 · consulté le 3 octobre 2026.
Retrouver le parcours de lecture F5 401