Ce guide concerne BIG-IP sur TMOS. Vérifiez les noms et les options dans la documentation de votre version.
Le réseau doit permettre d’atteindre la surface d’administration. L’authentification identifie le compte. Son rôle, sa partition et son accès au shell déterminent ensuite les actions permises : un login réussi ne signifie pas accès complet.
Télécharger le schéma en SVG · version claireIdentifier chaque surface d’accès
L’interface de management et les self IP ne représentent pas la même surface. Des services administratifs peuvent être accessibles par certaines self IP selon leurs autorisations. Une règle prévue pour une VIP applicative ne protège pas nécessairement ces accès.
Listez les chemins utilisés par GUI, SSH, API, supervision et communications HA. Définissez les réseaux de gestion autorisés et le mécanisme de contrôle de chaque chemin.
Sources : F5, net self ; F5, sys httpd ; F5, sys sshd.
Port lockdown est une autorisation de services
Port lockdown contrôle les services autorisés sur une self IP. Les choix None, Default, All ou personnalisés doivent être compris selon les services requis, notamment pour la communication entre pairs.
Fermer un service nécessaire à DSC peut produire une panne de synchronisation ou de failover. À l’inverse, Allow All ne constitue pas une stratégie de limitation. Documentez l’autorisation voulue et son périmètre au lieu de choisir le réglage le plus large pour faire disparaître une erreur.
Sources : F5, net self ; F5, cm device.
Rôle, partition et shell sont distincts
Un rôle définit les opérations autorisées. Une partition organise les objets et l’accès administratif. Le shell détermine le type d’accès CLI accordé. Donner un rôle sur une partition ne crée pas un contexte réseau isolé : les route domains remplissent ce rôle réseau.
Un opérateur autorisé à agir sur l’état de membres n’a pas forcément le droit de créer de nouveaux objets. Attribuez le rôle d’après les actions nécessaires, puis vérifiez ces actions avec un compte de test.
Sources : F5, auth user ; F5, auth remote-role.
Authentifier un utilisateur ne définit pas tous ses droits
Une source distante telle que RADIUS ou un annuaire peut authentifier une identité. Les groupes, attributs et mappings de rôles doivent ensuite déterminer les droits effectifs. Le rôle distant par défaut mérite une vérification particulière.
Conservez un accès de récupération maîtrisé. Une erreur de liste autorisée ou de mapping peut verrouiller l’administration ; préparez le contrôle depuis une seconde session et le chemin console approprié avant une modification.
Sources : F5, auth remote-role ; F5, sys httpd.
Inventorier sans afficher les secrets des comptes
Les lectures suivantes visent les services et les mappings. Les valeurs peuvent révéler votre architecture de gestion : partagez les sorties dans un périmètre adapté. Pour les comptes, privilégiez les propriétés de droits nécessaires à l’analyse.
tmsh list sys httpd allow
tmsh list sys sshd allow
tmsh list auth remote-role all-properties
tmsh list net self all-propertiesSources : F5, sys httpd ; F5, sys sshd ; F5, auth remote-role ; F5, net self.
Vérifier autorisation et refus
En laboratoire, testez une lecture autorisée, une modification refusée et un accès depuis un réseau non autorisé. Contrôlez séparément GUI, CLI et objets de partition. Un login réussi n’établit pas que le principe de moindre privilège est respecté.
Sources : F5, auth user ; F5, auth remote-role.
Restreindre l’accès à une publication
Le port lockdown d’une self IP contrôle des services sur cette self IP ; il ne constitue pas une ACL universelle pour les virtual servers. Pour un VS privé, relevez source autorisée, VLAN d’entrée, protocole et port. L’autorisation applicative peut demander en complément une politique APM, un WAF ou un contrôle dans l’application.
Un VS forwarding trop large peut offrir un transport vers des ressources qui n’étaient pas censées être publiées. Distinguez sélection du VS, routage et contrôle d’accès. Vérifiez le refus depuis un réseau extérieur au périmètre ainsi que l’accès attendu depuis le réseau autorisé.
Un certificat client peut contribuer à l’authentification, mais sa présence ne définit pas tous les droits sur les ressources. Contrôlez la chaîne, la révocation lorsque configurée et l’identité autorisée. Un chiffrement TLS sain ne prouve pas que l’accès métier est correctement restreint.
Sources : F5, net self ; F5, ltm virtual ; F5, ltm profile client-ssl.
Sources et portée
Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. 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 — net self · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — sys httpd · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — sys sshd · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — cm device · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — auth user · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — auth remote-role · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — ltm virtual · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
- F5 — ltm profile client-ssl · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
Retrouver le parcours de lecture F5 LTM