Ce guide concerne BIG-IP sur TMOS. Les noms et options doivent être confrontés à la documentation de votre version.
Identifier 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.
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 — 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.
Retrouver le parcours de lecture F5 LTM