FortiGate : comprendre la correspondance des politiques firewall

Une politique s’applique à une communication caractérisée par ses interfaces d’entrée et de sortie, ses adresses, son service, sa planification et éventuellement l’identité. Commencez par une matrice de flux : client, destination, protocole et besoin métier. Cela évite une règle dont les objets sont corrects mais trop larges.

Le sens important est celui de l’initiation. Une politique client vers serveur traite une session initiée par le client et les réponses qui lui appartiennent. Si le serveur doit initier une autre communication vers le client, ce besoin doit être examiné comme un nouveau sens d’initiation.

FortiGate examine les critères de correspondance des politiques. Si aucune politique configurée ne correspond, le trafic est refusé. Pour comprendre une autorisation ou un refus, retrouvez les valeurs réellement vues par le firewall, notamment les interfaces et les adresses dans le contexte des traductions.

L’ordre des règles compte lorsqu’un même flux peut correspondre à plusieurs politiques. Ne déduisez pas l’ordre d’examen de la seule valeur du Policy ID : confrontez l’affichage de séquence et l’identifiant présent dans les événements. Une règle spécifique placée après une règle plus large peut ne pas donner le résultat attendu.

Une action accept autorise le traitement prévu par la politique. Les profils de sécurité, la traduction de source et les paramètres de journalisation sont d’autres dimensions. L’existence d’une politique accept ne signifie pas que l’antivirus ou l’inspection SSL attendus soient actifs.

En mode profile-based, vérifiez les profils réellement attachés à la règle et leur cohérence avec le mode flow ou proxy. Pour une modification de laboratoire, notez l’état précédent et observez une nouvelle session représentative ; une ancienne session peut conserver un contexte différent de celui que vous souhaitez examiner.

Préparez trois cas : la communication nécessaire, une destination voisine non autorisée et un service non prévu. Relevez l’adresse, le port et la politique de chacun. Cette comparaison montre si les critères limitent réellement le périmètre plutôt que d’autoriser tout un réseau par commodité.

Le dépannage commence alors par une question précise : mauvaise politique, absence de route, mauvaise identité ou action d’un profil ? Les journaux et le suivi du flux donnent des éléments complémentaires. Corriger une règle sans avoir identifié la décision observée peut simplement masquer le problème.

Écrire la matrice de flux d’un client vers un serveur web. Définir les objets nécessaires et les événements à consulter pour vérifier que la politique correspond au besoin.

Pour terminer, formulez votre résultat attendu, les observations relevées et une hypothèse alternative si le résultat diffère. Conservez la version du produit et le contexte de test avec vos notes de laboratoire.